Воспользуйтесь готовыми решениями под бекап. Просто шифруйте файлы, перед тем как их выложить.
Ну, хз - другие умеют, значит.
Наконец, просто возьмите gnupg (он есть под win) - и зашифруйте файл.
"Сделать мне зашибись" (тм)
Боюсь, даже аллах не знает сколько это стоит - ибо реальный мир выглядит далеко не зашибись... А на практике, настройка сервера (который я далее готов администрировать) - стоит от 40$. Чем больше сервисов, чем сложнее конфигурация - тем дороже.
А сколько будет аккаунтов в ISP? Сколько сайтов? Хотелось бы составить представление о том, нафига он Вам нужен.
Прежде всего, найдите грамотного администратора, который и реализует Вашу хотелку.
Если Вы не понимаете, что "сервер, на котором будут храниться важные данные" - вещь в себе, понятная только Вам, то реализовать такое по данным здесь "советам" будете не в состоянии.
Какие сервисы будут работать на этом "сервере", для чего он будет предназначен? Какая операционная система?
Если Вам нужно просто место для бекапа - так и напишите.
Только ленивый не умеет. Например, вот: http://www.opennet.ru/dev/fsbackup/
Под win тоже есть туча всяких программ. FileZilla вроде такое умеет.
Т.е. Вы разницы принципиально не замечаете?
Физическое повреждение - одно. Откат совершенно корректных действий файловой системы (работа которой _абсолютно_ на подобное не расчитана) - совершенно иное.
Что Вы там собираетесь "настраивать", чтобы "журналирование" смогло помочь какой-нибудь тупоумной блондинке, "случайно" сделавшей rm нужным файлам?
Или "гуру" просто плохо представляет себе что такое журналирование и для чего оно предназначено?
Сервер выключен? Диск с потерянными файлами выдран из него? Или Вы скопировали утилитой dd раздел с файлами куда-то еще?
Раз Вы что-то очумелыми ручками "не трогаете" - это еще не значит, что на раздел с удаленными файлами никто не пишет (может он вообще у Вас один - как обычно местные "одмины" заводят: один корневой раздел, на который пишется _все_, и логи, и каталоги сайтов, и файлы сервера базы данных). И с каждой записью - шансы на восстановление падают.
Значит _Вам_ восстановить это не по силам.
Самый разумный совет: если данные для Вас критичны - скопируйте раздел для последующего восстановления. Или вовсе отложите диск в сторонку. И дальше пусть знающий человек за денюшку попробует для Вас из этого восстановить данные.
Вранье.
В первом вашем посте приведен лишь кусок nginx.conf. Приведите его полностью.
Вот этого, в частности, по конфигу не видно. И аллах ведает - какие еще Вы директивы упустили.
И браузер тоже? Да Вы гений...
Ну вот и ответ Вам. Читать не умеем?
Читаем:
Думаем...
Тред на пять страниц, епт.
Сами придумали, или "нагуглили"?
"Вы все не так поняли", ув. "гуру". Чтобы понять правильно - нужно прекратить случайным образом комбинировать модули апача в надежде на чудо и начать систематически читать родную документацию.
Начать с: http://httpd.apache.org/docs/2.2/caching.html
Менять Вам надо не NS-сервера, а нанять грамотный технический персонал, раз сами не "бум-бум". Для перевода сервера на другой хостинг вам прежде всего потребуется изменить другие DNS-записи (которые кешируются на меньший срок, порядка минут), вовсе не NS-сервера. Можно вообще организовать переход так, что ни одного запроса не потеряете.
А смена NS-серверов с точки зрения ваших пользователей - может и обязана быть абсолютно незаметной.
Ну, я же читаю тред, перед тем как писать - и знаю что автора уже предупредили о потенциальных проблемах с таким решением.
К тому же, наверняка dir_index включен для файловой системы. Вы можете предложить пример потенциальной проблемы на его типе нагрузки - что не вылечит dir_index для (удовлетворившей ТС оценки в) 100 млн. пользователей?
А еще, то что _уже лежит_ - нужно преобразовать к соответствующей логике.
Вот я и говорю, что это не минутное решение, в отличие от изменения формата файловой системы.
