Можно ли создавать "моментальные снимки" определенных каталогов ежедневно, которые сохраняются на одном сервере, но в разных папках.
...
для защиты от любых повреждений, вызванных вредоносными скриптами / взломом и т. д.
Да, любой из многих программных инструментов контроля версий, который будет делать именно это.
Я использую Mercurial ("hg"), часто с симпатичным графическим интерфейсом TortoiseHg.
На многих моих серверах существует одна папка (*), возможно, "/var/www/", которая содержит все, что я хочу сделать резервную копию - файлы настроек, шаблоны, пользовательские сценарии cgi-bin на стороне сервера, пользовательский браузер- сторонние .js-скрипты, .html-содержимое и т. д. (Все остальное на машине - это стандартная операционная система и приложения.
Если этот материал будет поврежден, я бы, вероятно, стер его и установил бы последнюю версию, а не пытался вернуться к старой, устаревшей версии, которую я использовал).
Когда я впервые настраиваюсь, я перехожу в эту папку и выполняю одноразовую настройку.
hg init
hg add
hg commit -u dc -m "initial setup"
Строка "init" создает папку «.hg/», в которой когда-нибудь будут храниться сжатые снимки.
(отсюда и название популярного учебника по Mercurial, http://hginit.com/ ).
Строка "add" и строка "commit" по умолчанию сканируют каждый файл, каждый файл в этой папке, независимо от того, насколько глубоко они вложены в подпапки, и помещают (сжатую) копию в эту папку «.hg/». ,
Когда я подозреваю повреждение или другое изменение рабочих файлов (и при условии, что папка «.hg», содержащая все снимки, не повреждена), я печатаю
hg status
который говорит мне, какие именно файлы были изменены, независимо от того, насколько глубоко они вложены в какую-либо подпапку, я набираю
hg diff
который говорит мне, что именно изменилось в каждом файле.
Если мне не нравится то, что я вижу - это злонамеренные изменения, или, чаще, это мои собственные глупые правки, о которых я теперь жалею, что делаю, я печатаю
hg revert --all
отменить все изменения обратно до самого последнего коммита.
Если мне нравится то , что я вижу - я отлажен то , что на самом деле делает это лучше - я типа что - то вроде
hg add
hg commit -u dc -m "tweaked .htaccess so we now have Clean URLs."
с комментарием, который, надеюсь, описывает, почему я сделал эти изменения.
(Существуют способы вернуть только некоторые файлы и зафиксировать только некоторые файлы, и даже способы зафиксировать только некоторые из множества изменений, внесенных в один файл - подробности см. В документации).
Возможно, вы предпочли бы иметь работу cron, которая ежедневно делает что-то вроде
hg add
hg commit -u mr_backup -m "cron automated snapshot of the server."
Сжатый снимок каждой версии, которая когда-либо была принята, остается в папке «.hg/».
Есть команда "hg update", чтобы вернуться к любой подтвержденной версии.
Есть команда "hg diff -r 1:2", чтобы увидеть, что именно изменилось между первым коммитом и вторым коммитом.
более сложные ситуации
(*) Часто есть только одна папка, которую я хочу сохранить ("/var/www/").
Однако иногда возникает более сложная ситуация - файлы, которые я хочу сохранить, разбросаны по разным папкам, и единственная общая папка между ними - корневая папка "/", и я не хочу помещать репозиторий ".hg/" в корневой папке "/.hg/".
Возможно, есть лучший способ справиться с этим, но сейчас я делаю следующее:
- Я создаю специального пользователя с именем "MrBackup", который имеет разрешения только на чтение для всех файлов, для которых я хочу создать резервную копию.
- Я настроил все так, чтобы каждая папка, для которой я хочу создать резервную копию, отображалась как подпапка /home /mr_backup. В настоящее время у меня есть случайная смесь:
- Некоторые файлы на самом деле находятся в домашней папке MrBackup, а затем в другом месте, в котором они "нуждаются", есть мягкая ссылка на них.
- Некоторые файлы имеют жесткую ссылку на них в обоих местах - в том месте, в котором они "должны" находиться, а также где-то в домашней папке MrBackup.
- Сценарий cron периодически копирует некоторые файлы из "живого" местоположения в папку резервной копии в домашней папке MrBackup, возможно, выгружает базу данных SQL с другого сервера в файл дампа в домашней папке MrBackup, а также создает резервную копию самого сценария cron ( "crontab -l> /home/mr_backup/backup/crontab.txt").
- Часто я хочу выполнить резервное копирование почти всего в какой-либо папке P, за исключением подпапки «cache /», резервное копирование которой мне не нужно, поскольку при необходимости она будет автоматически восстановлена. Я использую ".hgignore", чтобы исключить подпапку кеша.
- Затем я использую Mercurial, как указано выше.
- Когда файлы, сгенерированные скриптом cron, выглядят неправильно, после того, как я сделал возврат, мне нужно предпринять некоторые дополнительные шаги, чтобы каким-то образом вернуть "хорошую версию" обратно в "живое" местоположение.
PS: На машине в другом городе, отличном от моего сервера, я иногда запускаю рабочее место TortoiseHg и нажимаю маленькую кнопку, которая за кулисами запускается
hg pull
(и спрашивает у меня пароль Mr Backup), чтобы получить резервную копию всего, что было добавлено в хранилище.
Вместо того, чтобы вносить изменения в рабочий сервер, лучше сделать изменения на другом компьютере, а затем зафиксировать их и
hg push
их на производственный сервер.
Папка «.hg/» продолжает расти - очень медленно, потому что она сохраняет только файлы, которые переходят от одного коммита к другому, и даже эти относительно небольшие наборы изменений сжимаются перед сохранением.
Возможно, есть лучший способ справиться с этим медленным ростом, но сейчас я делаю так:
После того, как я "hg commit" текущую версию, а затем "hg pull" на своем внешнем резервном компьютере, один раз в год я удаляю папку сервера ".hg/" и использую "hg init", чтобы создать новый, новый, пустой Папка ".hg/", а затем я фиксирую текущую версию.
(Последняя версия внешнего хранилища резервных копий 2014 года должна совпадать с первой версией внешнего хранилища резервных копий 2015 года).
