Тормозит сайт и уходят клиенты во время создание резервной копии? Или не получается скачать файлы после создания бэкапа и возникает чувство беспокойства, что сайт и резервная копия лежат в одном месте? Давайте рассмотрим один из применяемых нами способ создания больших резервных копий на удаленном сервере, которые создаются в автоматическом режиме по заданному расписанию.
Особых проблем с резервным копированием небольших сайтов не возникает. Это делается любым более-менее обученным сотрудником далеким от IT с помощью стандартных средств, например, модулей CMS или панелей управления веб-серверами (ISPmanager, cPanel). Продвинутые пользователи хранят копии в отдельном месте, недальновидные – на сервере вместе с сайтом на одном диске.
Еще в начале моей карьеры я размещал сайт на белорусском хостинге. В какой-то момент хостинг переехал на сервер в Москву. Через некоторое время мне нужно было провести работы по изменению части кода на сайте. Посмотрев наличие резервной копии в ISP панели, но не убедившись в ее работоспособности, приступил к запланированным доработкам сайта. Как вы догадываетесь, что-то пошло не так. Я попытался восстановить сайт из резервной копии, но ее в реальности не оказалось. В переписке со службой поддержки получил ответ: «Создание резервной копии забота владельца сайта, ничем помочь не можем». С тех пор делаю бэкапы сам и храню резервные копии физически отдельно от сайтов в нескольких местах.
Реальная проблема возникает когда сайт становится большим и тяжелым. Это часто встречается у интернет-магазинов. В результате во время резервного копирования сервер нагружается и начинает тормозить, т.к. архивирование баз данных и файлов это процесс, требующих значительных ресурсов процессора и памяти. В ситуациях когда много заказов и нужно бэкапить базу данных несколько раз в день возникает ситуация когда предыдущая резервная копия еще не создалась и уже пришло время делать следующую. Бывают случаи, когда из-за большого объема файлов их не удается загрузить из панели управления веб-сервером через браузер.
Исходя из вышеизложенных проблем, мы используем в своей работе систему создания автоматических резервных копий на удаленном сервере по расписанию.
Для реализации описываемого метода понадобится 2 сервера: production и бэкап. Логика их работы следующая:
- файлы с production-сервера автоматически по расписанию инкрементально копируются программой rsync на бэкап-сервер, физически расположенном в другом месте.
- На бэкап-сервере при помощи программы rdiff-backup проводится инкрементальное резервное копирование.
- Автоматически удаляются устаревшие бэкапы.
Команды из видео
1 2 3 4 5 6 7 8 9 | ssh-keygen sudo ssh-copy-id -i ~/.ssh/backup.pub gb@192.168.104.55 sudo ssh -i ~/.ssh/backup gb@192.168.104.55 rsync --delete -e "ssh -i ~/.ssh/bcp" --bwlimit=90000 -zauP root@98.165.77.99:/var/wwww ~/backups/data/test1 >> ~/backups/logs/rsync-db-stb-log.txt 2> ~/backups/logs/rsync-db-stb-error-log.txt rdiff-backup -v5 --print-statistics~/backups/data/test1 ~/backups/incremental/test1 >> ~/backups/logs/rdiff-stb-log.txt 2> ~/backups/logs/rdiff-stb-error-log.txt |
Плюсы способа:
- Отсутствие нагрузки на production-сервере, т.к. все высоконагруженные операции происходят на стороннем сервере.
- Все копии интернет-магазинов хранятся физически отдельно на стороннем сервере.
- Инкрементность процесса – каждый раз копируются не все файлы интернет-магазина, а только те, которые изменились или добавились новые. Это дает экономию времени и дискового пространства бэкап-сервера.
- Настройка виртуального сервера на бесплатном ПО, например, при помощи Oracle VM Virtualbox и Ubuntu Server, а также rsync и rdiff-backup.
Недостатки способа:
- Дополнительное администрирование бэкап-сервера
- Повышенные требования к квалификации администратора системы
Восстановление резервной копии
1 2 3 | rdiff-backup --list-increments ~/backups/incremental/server_5.216.8.189 rdiff-backup --force --restore-as-of 2020-03-06T00:00:02+03:00 ~/backups/incremental/server_5.216.8.189 ~/bkp |
