Какое ПО и как использовать для полного резервного копирования web-сервера на Ubuntu?
Есть локальный локальный web-сервер на базе Ubuntu. Задача — развернуть систему резервного копирования, которая позволит оперативно восстановить работу боевого сервера с нуля в случае выхода из строя всех жестких дисков. Я рассматриваю следующий вариант: настроить удаленный dedicated-сервер, который будет ночью делать полную ежедневную резеврную копию системы. В случае выхода из строя боевого сервера я хотел бы иметь возможность восстановить работу сервера наиболее простым способом.
Проблема в следующем: легко бекапить и восстанавливать данные, но проблематично устанавливать и настраивать систему таким образом, чтобы новый сервер работал с этими данными также как старый.
Соответственно, нужен вариант backup-системы под ключ. В идеале хотелось бы загрузиться на новом железе с live-системы на флешке, подключиться к backup-серверу и запустить процесс восстановления. То есть максимально упросить процесс востановления.
Прошу вас поделиться опытом настройки и использования подобных систем резервного копирования.
Средний 2 комментария
Чистая система ставится весьма быстро.
Вполне достаточно делать бэкап сайта и настроек веб-сервера, и иметь под рукой список софта с версиями, которые вам нужны.
Тогда быстро ставится новый сервер, ставится софт, восстанавливается бэкап и все.
И это тоже можно автоматизировать обычным баш скриптом.
Согласен. Чистая система ставится быстро, но у меня в наличии очень старый и совсем не чистый сервер, на котором множество неочевидных зависимостей. Поэтому и хотелось бы в качестве компромиссного варианта забекапить всё как есть. В будущем имеет смысл перенести сервер на чистую систему путём проб и ошибок. Сейчас же нужно компромиссное решение, которое поможет создать резервную копию всего сервера.
Вы немного не в том русле пытетесь решить вашу проблему.
Бэкапить целиком разделы машины — это не очень хорошая идея, потому что ломаются не только диски, но и сама система при обновлениях (вы же не будете отказываться от обновлений езопасности, например), могут возникнуть уязвимости и всякие там шифровальщии пошифруют вам тома, да мало ли чего еще может произойти. что бинарный бэкап по какой-то причине не поднимется и придётся вам очень геморрно выковыривать работабщий сервис из бэкапа системы.
Правильный путь — это бэкапить БД и раздел со пользовательской статикой отдельно, а исходники и систему бэкапить не надо. Система должна быть максимально стандартной и чистой, а бэкенд должен развораичваься в докер-контейнерах по апуску компоуз-файла.
Преимуществ много:
— прозрачная понятная и декларативно описанная конфигурация,
— отсутствие зависимостей от хостовой системы,
— толератность к подъёму любого количества стейджинг сереров,
— удобно вести разработку и запускать на машинах разработчиков,
— удобно бесшовно мигрировать на новое железо, когда только начали сыпаться предупреждения от SMART а не когда жареный петух SSD одолбает,
— гораздо эфективнее расходуется место для бэкапов: бэкапятся толкьо данные (БД и файлы),
— вся конфигурация толерантна к системам контроля версий, а значит легче разматывать и решать проблемы,
— вы запросто поднимите запасной или временный сервис где угодно, прежде чем погасите рабочий для какой-то цели,
— можно быстро (одной командой) развернуть временный сервер на любой машине, пока не настроите штатный сервер взамен умершего.
Если хотите максимально упростить работу всем — делайте скрипты оркастрации (с комментариями), которые будут поднимать, опускать, развёртывать, бэкапить и поднимать бэкапы. Через пару лет, когда забудете как там всё устроено, эти скрипты и комментарии сильно сэкономят время.
Не забывайте, что помимо основной конфигурации есть еще SSL-сертификаты, которые имеют свойство «неожиданно» просрачиваться, конфигурация Nginx, которую тоже хорошо бы положить в соответствующем контейнере, и прочее. А ещё есть IP-адреса внутренних DNS и всяких шлюзов, которые могут поменяться, а тупой подъём бэкапа только усугубит ситуацию. Да и на поднятом из бэкапа сервере скорее всего давно не одновлялся сертификат и так просто ваш сайт не заработает.
Короче, нельзя просто так взять и забэкапить винт сервера, чтобы не поиметь проблем при любых обстоятельствах.
Бэкап и восстановление сайта в Linux
Здравствуйте, уважаемые читатели. Сегодня статья на тему: «Бэкап и восстановление сайта в Linux». При наличии веб-сайта на сервере, резервное копирование, это одна из важнейших функций, которую необходимо настроить. Случится может всякое, а потерять «всё нажитое непосильным трудом», перспектива не очень приятная.
Резервное копирование сайта – это создание заархивированной копии файлов, и дампа базы данных сайта, в специально выделенной директории, на том же или удалённом сервере.
Восстановление сайта из резервной копии – это замена файлов, и содержимого базы данных сайта, на предварительно сохранённые копии. После процедуры восстановления, всё содержимое сайта, откатывается на момент создания резервной копии, из которой произведено восстановление.
Чтобы всё было наглядно, в качестве «жертвы» резервного копирования и восстановления, будем использовать веб-приложение OwnCloud, установку которого мы рассматривали в прошлой статье.
Создание Бэкапа файлов сайта
- Чтобы не было путаницы, можно создать инфраструктуру, в которую будет производится резервное копирование.
- Создаём директорию /rezerv, а в ней отдельные директории для резервных копий файлов сайта, и базы данных.
- Создаём директории site и baza.
# mkdir -p /rezerv/site
# mkdir -p /rezerv/baza
- Для создания бэкапа файлов сайта, мы будем использовать утилиту tar.
- Нам нужно создать архив файлов сайта, с понятным для нас названием, чтобы мы в итоге могли понять, что это за копия, и когда она создана.
Команда будет выглядеть так:
# tar -czvf /rezerv/site/backup-`date +"%Y-%m-%d_%H-%M"`.tar.gz -C /var/www/html/ owncloud
— Будет создана заархивированная копия директории owncloud, находящейся в /var/www/html/.
— Созданный архив будет расположен в директории /rezerv/site/.
— Архив будет иметь название вида: backup-дата_время создания.tar.gz
- Отправляем команду в консоль, и проверяем результат.
- В директории /rezerv/site/ появился архив, с настроенным нами названием.
Создание Бэкапа базы данных сайта
- Теперь займёмся созданием резервной копии базы данных, по аналогии с резервной копией файлов сайта.
- Будем использовать утилиту mysqldump.
Команда будет выглядеть так:
# mysqldump -u oblako -p123 oblako | gzip -c > /rezerv/baza/mysql-`date +"%Y-%m-%d_%H-%M"`.sql.gz
— Будет создан дамп базы данных oblako, от имени пользователя oblako, с паролем 123.
— Дамп будет заархивирован и расположен в директории /rezerv/baza/.
— Архив будет иметь название вида: mysql -дата и время создания. sql.gz
- В результате получаем архив с дампом базы данных, и задуманным нами названием.
- Как видите сделать бэкап сайта не так уж и сложно. Кроме того, не требуется каких-то дополнительных компонентов. Всё что нужно, уже есть в системе.
Настройка автоматического бэкапа сайта
- Мы рассмотрели создание бэкапа сайта в ручную, но есть способ автоматизировать этот процесс.
- Для организации автоматического бэкапа сайта, мы будем использовать системный планировщик заданий cron.
- Для добавления задания в cron на CentOS, нам нужно открыть файл /etc/crontab.
- В файле crontab, есть комментарии по правильной настройке выполнения заданий.
- Задание на выполнение ежедневного бэкапа файлов сайта в 2:30 ночи, с настройками использованными нами выше, будет выглядеть так:
#Бэкап сайта 30 2 * * * root /bin/tar -czf /rezerv/site/backup-`date +\%Y-\%m-\%d_\%H-\%M`.tar.gz -C /var/www/html/ owncloud
- А задание на выполнение ежедневного бэкапа базы данных, так же в 2:30 ночи, с настройками использованными нами выше , будет выглядеть так:
#Бэкап базы 30 2 * * * root /bin/mysqldump -u oblako -p123 oblako | /bin/gzip -c > /rezerv/baza/mysql-`date +\%Y-\%m-\%d_\%H-\%M`.sql.gz
Восстановление файлов сайта из бэкапа.
Чем делать бэкап веб-сервера на Ubuntu?
В рамках данного вопроса под «веб-сервером» подразумевается удалённая виртуалка на Ubuntu Server 20.04, где расположены несколько последних релизов нескольких сайтов. Стэк совершенно минимальный — nginx, php-fpm, node, mysql/postgresql.
Никаких панелей управления нет. Всё настраивается по SSH.
Провайдер делает свои бэкапы, но там бэкапится вся виртуалка целиком, в закрытом формате и раз в сутки. Мне бы хотелось софтину, которая забэкапит выбранные директории, заархивирует их, снимет дампы с БД или их реплик, и зальёт мне на удалённый сервер. Или несколько.
Конечно, можно, помучаться и сделать это всё bash скриптами. Но может есть что-то готовое и более элегантное? В идеале вообще с Web-GUI 🙂
Backupninja (скорее всего пакет есть в репозитории Ubuntu). Это почти как самописный скрипт, только его уже написали за вас. Умеет инкрементные бекапы с помощью rdiff-backup и duplicity.
Почему написание скрипта на пару десятков строчек, делающего дифференциальные бэкапы файлов каким-нибудь rdiff-backup `ом и дамп баз данных родными утилитами вы называете мучением?
Более гибко и эффективно, чем так — никакая централизованная система вам не сделает. Централизация/унификация имеет смысл, когда сервисов много и они однотипные. Для ваших же объёмов, на мой взгляд, практичнее именно самописный скрипт.
Перенос сервера, или его восстановление. Вам нужно отдельно хранить или помнить что в вашем скрипте настроено и как. А если у вас 10-20 серверов, это уже становится проблемой. Нужно помнить или хранить этот ваш самописный кусок кода отдельно в GIT — чтобы хотя бы автоматически притянуть его во время установки системы на новый сервер. Хранить конфиг для утилиты, которую вы ставите автоматически на все сервера, и пушить конфиг для этой утилиты через АНСИБЛ — мне кажется то как это должно быть.
И далее, когда у вас не один единственный сервер, сменить пароль ФТП или какие другие настройки — автоматизировать это будет значительно сложнее, чем с единым форматом конфига для утилиты — любой.