Я перехожу с VPS на выделенный сервер. К сожалению, большинство выделенных серверов не предоставляют резервных копий сервера, как это делают управляемые VPS, и мне очень нравится спокойствие, когда у меня есть резервная копия всех моих скриптов/файлов, если что-то пойдет не так (такое уже бывало).
Итак, вопрос в том, возможно ли ежедневно создавать «снимки» определенных каталогов, которые сохраняются на одном и том же сервере, но в разных папках.
Понятно, что эти резервные копии не защитят от внешних катастроф. Я больше ищу защиту от любого ущерба, вызванного вредоносными скриптами/взломами и т. д.
решение1
Вероятно, вы ищете что-то вроде Webmin:http://webmin.com/
Это обязательная часть моих настроек сервера CentOS. Он очень прост в установке и делает администрирование сервера легким, особенно резервное копирование. Ознакомьтесь с документацией здесь:http://doxfer.webmin.com/Webmin/FilesystemBackup
решение2
возможно ли создавать «моментальные снимки» определенных каталогов ежедневно, которые сохраняются на том же сервере, но в разных папках. ... для защиты от любых повреждений, вызванных вредоносными скриптами/взломами и т. д.
Да, любой измножество программных средств контроля версийкоторый сделает именно это.
Я использую 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", чтобы исключить подпапку cache.
- Затем я использую Mercurial, как указано выше.
- Если файлы, созданные скриптом cron, выглядят неправильно, после выполнения отката мне нужно предпринять некоторые дополнительные шаги, чтобы каким-то образом вернуть «хорошую версию» обратно в «рабочее» местоположение.
ps: На машине, которая находится в другом городе, нежели мой сервер, я иногда запускаю TortoiseHg Workbench и нажимаю маленькую кнопку, которая за кулисами запускает
hg pull
(и просит меня назвать пароль мистера Бэкапа), чтобы получить внешнюю резервную копию всего, что было передано в репозиторий.
Вместо того, чтобы вносить изменения непосредственно на производственный сервер, обычно лучше внести изменения на какой-то другой машине, а затем зафиксировать их и
hg push
их на производственный сервер.
Папка ".hg/" продолжает расти — очень медленно, потому что в ней сохраняются только файлы,изменятьот одного коммита к другому, и даже эти относительно небольшие наборы изменений сжимаются перед сохранением.
Вероятно, есть лучший способ справиться с этим медленным ростом, но сейчас я делаю следующее:
После того, как я "hg commit" сохраняю текущую версию, а затем "hg pull" сохраняю ее на своей внешней машине для резервного копирования, раз в год я удаляю папку ".hg/" сервера и использую "hg init" для создания новой, новой, пустой папки ".hg/", а затем сохраняю текущую версию. (Последняя версия внешнего репозитория резервных копий 2014 годадолженбыть идентичным первой версии внешнего репозитория резервных копий 2015 года).