@karpo518

Какое ПО и как использовать для полного резервного копирования web-сервера на Ubuntu?

Есть локальный локальный web-сервер на базе Ubuntu. Задача - развернуть систему резервного копирования, которая позволит оперативно восстановить работу боевого сервера с нуля в случае выхода из строя всех жестких дисков. Я рассматриваю следующий вариант: настроить удаленный dedicated-сервер, который будет ночью делать полную ежедневную резеврную копию системы. В случае выхода из строя боевого сервера я хотел бы иметь возможность восстановить работу сервера наиболее простым способом.

Проблема в следующем: легко бекапить и восстанавливать данные, но проблематично устанавливать и настраивать систему таким образом, чтобы новый сервер работал с этими данными также как старый.

Соответственно, нужен вариант backup-системы под ключ. В идеале хотелось бы загрузиться на новом железе с live-системы на флешке, подключиться к backup-серверу и запустить процесс восстановления. То есть максимально упросить процесс востановления.

Прошу вас поделиться опытом настройки и использования подобных систем резервного копирования.
  • Вопрос задан
  • 180 просмотров
Пригласить эксперта
Ответы на вопрос 2
trapwalker
@trapwalker
Программист, энтузиаст
Вы немного не в том русле пытетесь решить вашу проблему.
Бэкапить целиком разделы машины - это не очень хорошая идея, потому что ломаются не только диски, но и сама система при обновлениях (вы же не будете отказываться от обновлений езопасности, например), могут возникнуть уязвимости и всякие там шифровальщии пошифруют вам тома, да мало ли чего еще может произойти. что бинарный бэкап по какой-то причине не поднимется и придётся вам очень геморрно выковыривать работабщий сервис из бэкапа системы.
Правильный путь - это бэкапить БД и раздел со пользовательской статикой отдельно, а исходники и систему бэкапить не надо. Система должна быть максимально стандартной и чистой, а бэкенд должен развораичваься в докер-контейнерах по апуску компоуз-файла.
Преимуществ много:
- прозрачная понятная и декларативно описанная конфигурация,
- отсутствие зависимостей от хостовой системы,
- толератность к подъёму любого количества стейджинг сереров,
- удобно вести разработку и запускать на машинах разработчиков,
- удобно бесшовно мигрировать на новое железо, когда только начали сыпаться предупреждения от SMART а не когда жареный петух SSD одолбает,
- гораздо эфективнее расходуется место для бэкапов: бэкапятся толкьо данные (БД и файлы),
- вся конфигурация толерантна к системам контроля версий, а значит легче разматывать и решать проблемы,
- вы запросто поднимите запасной или временный сервис где угодно, прежде чем погасите рабочий для какой-то цели,
- можно быстро (одной командой) развернуть временный сервер на любой машине, пока не настроите штатный сервер взамен умершего.

Если хотите максимально упростить работу всем -- делайте скрипты оркастрации (с комментариями), которые будут поднимать, опускать, развёртывать, бэкапить и поднимать бэкапы. Через пару лет, когда забудете как там всё устроено, эти скрипты и комментарии сильно сэкономят время.
Не забывайте, что помимо основной конфигурации есть еще SSL-сертификаты, которые имеют свойство "неожиданно" просрачиваться, конфигурация Nginx, которую тоже хорошо бы положить в соответствующем контейнере, и прочее. А ещё есть IP-адреса внутренних DNS и всяких шлюзов, которые могут поменяться, а тупой подъём бэкапа только усугубит ситуацию. Да и на поднятом из бэкапа сервере скорее всего давно не одновлялся сертификат и так просто ваш сайт не заработает.

Короче, нельзя просто так взять и забэкапить винт сервера, чтобы не поиметь проблем при любых обстоятельствах.
Ответ написан
Комментировать
CityCat4
@CityCat4
//COPY01 EXEC PGM=IEBGENER
Если это виртуалка - проще бэкапить ее целиком через соответствующий софт
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы