Резервное копирование, часть 7: Выводы

Данная заметка завершает цикл о резервном копировании. В ней пойдет речь о логической организации выделенного сервера (или VPS), удобной для резервного копирования, а также будет предложен вариант быстрого восстановления сервера из резервной копии без особых простоев в случае аварии.

Исходные данные

Выделенный сервер чаще всего имеет минимум два жестких диска, служащих для организации RAID массива первого уровня (зеркало). Это нужно для возможности продолжить работу сервера если один диск вышел из строя. Если это обычный выделенный сервер — может быть отдельный аппаратный RAID-контроллер, с активной технологией кэширования на SSD, так что в довесок к обычным жестким дискам может быть подключен один или больше SSD. Иногда предлагаются выделенные сервера, в которых из локальных дисков присутствуют только SATADOM (небольшие диски, конструктивно — флешка, подключаемая в порт SATA), а то и обычная небольшая (8-16гб) флешка, подключаемая в специальный внутренний порт, а данные берутся с СХД, подключенной по выделенной сети хранения данных (Ethernet 10G, FC и т.д.), а бывают выделенные сервера, которые загружаются и напрямую с СХД. Подобные варианты я не буду рассматривать, поскольку в таких случаях задача резервного копирования сервера плавно переходит специалисту, который обслуживает СХД, обычно там есть разные фирменные технологии создания снимков состояния, встроенная дедупликация и прочие радости сисадмина, рассмотренные в предыдущих частях этого цикла. Объем дискового массива выделенного сервера может достигать нескольких десятков терабайт, в зависимости от числа и объема дисков, подключенных к серверу. В случае VPS объемы скромнее: обычно не более 100гб (но бывают и больше), а тарифы на такие VPS легко могут быть дороже самых дешевых выделенных серверов от этого же хостера. У VPS чаще всего диск один, потому что под ним будет СХД (или что-то гиперконвергентное). Иногда у VPS бывает несколько дисков с разными характеристиками, для разных целей:

• небольшой системный — для установки операционной системы;
• большой — хранение пользовательских данных.

При переустановке системы средствами панели управления диск с пользовательскими данными не затирается, а вот системный перезаливается полностью. Также в случае с VPS хостер может предлагать кнопку, делающую снимок состояния VPS (или диска), однако если установить свою операционную систему или забыть активировать нужный сервис внутри VPS — часть данных может быть все равно утеряна. В довесок к кнопке обычно предлагается сервис хранения данных, чаще всего сильно ограниченный. Обычно это учетная запись с доступом по протоколу FTP или SFTP, иногда вместе с SSH, с урезанным shell (к примеру rbash), либо ограничением на запуск команд через authorized_keys (через ForcedCommand).

Выделенный сервер подключен к сети двумя портами со скоростью 1гбитсек, иногда это могут быть карты со скоростью 10гбитсек. У VPS сетевой интерфейс чаще всего один. Чаще всего датацентры не ограничивают скорость сети внутри датацентра, но ограничивают скорость доступа в интернет.

Типовую нагрузку подобного выделенного сервера или VPS составляет веб-сервер, база данных, сервер приложений. Иногда могут быть установлены разные дополнительные вспомогательные сервисы, в том числе для веб-сервера или базы данных: поисковой движок, почтовая система и т.д.

В качестве пространства для хранения резервных копий выступает специально подготовленный сервер, о нем будет подробнее написано дальше.

Логическая организация дисковой системы

Если есть RAID-контроллер, или это VPS с одним диском, а также нет особых предпочтений по работе дисковой подсистемы (к примеру, отдельный быстрый диск для базы данных) — все свободное пространство делится так: создается один раздел, поверх него создается группа томов LVM, в ней создаются несколько томов: 2 небольших одинакового размера, используемых в качестве корневой файловой системы (меняются поочередно при обновлениях для возможности быстрого отката, идея подсмотрена у дистрибутива Calculate Linux), еще один — для раздела подкачки, остальное свободное пространство делится на небольшие тома, используемые в качестве корневой файловой системы для полноценных контейнеров, дисков для виртуальных машин, файловых систем для учетных записей в /home (каждой учетной записи — своя файловая система), файловых систем для контейнеров-приложений.

Важное замечание: тома должны быть полностью самодостаточными, т.е. не должны зависеть как друг от друга, так и от корневой файловой системы. В случае с виртуальными машинами или контейнерами этот момент соблюдается автоматически. Если же это контейнеры приложений или домашние каталоги — стоит подумать о разделении конфигурационных файлов веб-сервера и прочих сервисов таким образом, чтобы максимально убрать зависимости томов между собой. К примеру, каждый сайт работает от своего пользователя, конфигурационные файлы сайта — в домашнем каталоге пользователя, в настройках веб-сервера конфигурационные файлы сайтов включаются не через /etc/nginx/conf.d/.conf, а, к примеру, /home//configs/nginx/*.conf

Если же дисков несколько — можно создать программный массив RAID (и настроить его кэширование на SSD, если есть потребность и возможности), поверх которого собрать LVM по правилам, предложенным выше. Также в этом случае можно использовать ZFS или BtrFS, но тут стоит несколько раз подумать: обе требуют гораздо более серьезного подхода к ресурсам, к тому же ZFS не идет в комплекте с ядром Linux.

Независимо от используемой схемы всегда заранее стоит прикинуть примерную скорость записи изменений на диски, после чего вычислить размер свободного места, которое будет зарезервировано для создания снимков. К примеру, если наш сервер будет писать данные со скоростью 10 мегабайт в секунду, а размер всего массива с данными составляет 10 терабайт — время синхронизации может достигать суток (22 часа — столько будет передаваться такой объем по сети 1гбитсек) — стоит зарезервировать порядка 800 гб. В реальности цифра будет меньше, можно смело разделить ее на число логических томов.

Устройство сервера хранения резервных копий

Главное отличие сервера для хранения резервных копий — большие, дешевые и относительно медленные диски. Поскольку современные HDD уже перешагнули планку в 10тб в одном диске — обязательно применение файловых систем или RAID с контрольными суммами, потому что за время перестройки массива или восстановления файловой системы (несколько суток!) может выйти из строя второй диск из-за повышенной нагрузки. На дисках емкостью до 1тб это было не так чувствительно. Для простоты описания предполагаю, что дисковое пространство разделено на две примерно одинаковые по размеру части (опять же, к примеру, с помощью LVM):

• тома, соответствующие на серверах, используемые для хранения пользовательских данных (на них будет разворачиваться последняя сделанная резервная копия для проверки);
• тома, используемые как репозитории BorgBackup (сюда непосредственно будут попадать данные для резервных копий).

Принцип работы заключается в том, что создаются отдельные тома для каждого сервера под репозитории BorgBackup, куда и будут попадать данные из боевых серверов. Репозитории работают в режиме только добавления, что исключает возможность намеренного удаления данных, а за счет дедупликации и периодической чистки репозиториев от старых резервных копий (остаются годовые копии, ежемесячные за последний год, еженедельные за последний месяц, ежедневные за последнюю неделю, возможно — в особых случаях — ежечасные за последний день: итого 24 + 7 + 4 + 12 + годовые — примерно 50 копий для каждого сервера).
В репозиториях BorgBackup не активируется режим только добавления, вместо этого используется ForcedCommand в .ssh/authorized_keys примерно такого плана:

from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......

По указанному пути размещен скрипт-обертка поверх borg, который, помимо запуска бинарника с параметрами, дополнительно запускает процесс восстановления резервной копии после окончания снятия данных. Для этого скрипт-обертка создает файл-признак рядом с соответствующим репозиторием. Последняя сделанная резервная копия после окончания процесса заливки данных автоматически восстанавливается на соответствующий логический том.

Данная конструкция позволяет периодически чистить ненужные резервные копии, а также не позволяет боевым серверам удалять что-либо на сервере хранения резервных копий.

Процесс резервного копирования

Инициатором резервного копирования выступает сам выделенный сервер или VPS, поскольку такая схема дает больше контроля над процессом резервного копирования со стороны этого сервера. В первую очередь делается снимок состояния активной корневой файловой системы, который монтируется и закачивается с помощью BorgBackup на сервер хранения резервных копий. После окончания снятия данных снимок размонтируется и удаляется.

В случае наличия небольшой базы данных (до 1 гб для каждого сайта) делается дамп базы данных, который сохраняется в соответствующий логический том, туда, где расположены остальные данные этого же сайта, но так, чтобы дамп не был доступен через веб-сервер. Если же базы большие — следует настроить "горячее" снятие данных, к примеру с помощью xtrabackup для MySQL, или работу WAL c archive_command в PostgreSQL. В этом случае база данных будет восстанавливаться отдельно от данных сайтов.

Если применяются контейнеры или виртуальные машины — следует настроить qemu-guest-agent, CRIU или другие, нужные технологии. В остальных случаях дополнительных настроек чаще всего не понадобится — просто создаем снимки логических томов, которые потом обрабатываются аналогично снимку состояния корневой файловой системы. После снятия данных снимки удаляются.

Дальнейшая работа идет на сервере хранения резервных копий:

• проверяется последняя сделанная резервная копия в каждом репозитории,
• проверяется наличие файла-метки, указывающего, что процесс снятия данных завершен,
• выполняется разворачивание данных на соответствующий локальный том,
• удаляется файл-метка

Процесс восстановления работоспособности сервера

Если основной сервер гибнет, то запускается аналогичный выделенный сервер, который загружается с некоторого стандартного образа. Вероятнее всего загрузка будет происходить по сети, однако техник ЦОД, выполняющий настройку сервера, может сразу же скопировать этот стандартный образ на один из дисков. Загрузка происходит в оперативную память, после чего запускается процесс восстановления:

• выполняется запрос на присоединение блочного устройства по iscsinbd или другому схожему протоколу логического тома, содержащего корневую файловую систему погибшего сервера; поскольку корневая файловая система должна быть небольшой — этот этап должен быть завершен за несколько минут. Также производится восстановление загрузчика;
• воссоздается структура локальных логических томов, присоединяются логические тома с сервера резервного копирования с помощью модуля ядра dm_clone: начинается восстановление данных, а изменения записываются сразу же на локальные диски
• запускается контейнер со всеми доступными физическими дисками — полностью восстанавливается работоспособность сервера, но с пониженной производительностью;
• после окончания синхронизации данных логические тома с сервера резервного копирования отсоединяются, контейнер выключается, сервер перезагружается;

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

Приглашаю обсудить предложенный вариант в комментариях, благодарю за внимание!

Автор: Павел

Источник