company_banner

Резервное копирование, часть 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 или другие, нужные технологии. В остальных случаях дополнительных настроек чаще всего не понадобится — просто создаем снимки логических томов, которые потом обрабатываются аналогично снимку состояния корневой файловой системы. После снятия данных снимки удаляются.


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


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

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


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


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

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



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

    • +16
    • 4,8k
    • 7
    Southbridge
    566,12
    Обеспечиваем стабильную работу серверов
    Поделиться публикацией

    Комментарии 7

      0
      можно использовать ZFS или BtrFS, но тут стоит несколько раз подумать: обе требуют гораздо более серьезного подхода к ресурсам, к тому же ZFS не идет в комплекте с ядром Linux.

      Я бы сказал, zfs требует более серьезного подхода к настройке. Ну не идет она в комплекте с ядром Linux и что из того? Вообще, а что ИДЁТ в комплекте с ядром?
      В современных дистрибутивах поддержка zfs ставится в 2 команды. Вообще без проблем.


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

      А вы могли бы расскрыть это предложение? Т.е я понимаю о чем примерно хотелось тут сказать, но сформулировано крайне странно и смешано несколько разных проблем в одну кучу.


      И да, "несколько суток" восстановления будет обеспечено с железным RAID (примерно как и инициализация), программные raid имеют представление о ФС, поэтому в том числе могут восстанавливать только реально используемое место, а не тупо зеркалировать байт-в-байт.


      В целом, тема хранилищ сложная и уже давно всё придумано — облачных хранилищ дофига и больше, выбирай на любой вкус. Их надёжность будет в 99.9 случаях выше, чем то, что будет навелосипежено по такой статье (не обижайтесь).

        0
        А вы могли бы расскрыть это предложение? Т.е я понимаю о чем примерно хотелось тут сказать, но сформулировано крайне странно и смешано несколько разных проблем в одну кучу.

        От диска ожидается бесконечная надежность, если кратко. В реальных условиях это не так, поскольку есть ошибки чтения, пропускаемые всеми компенсационными механизмами и алгоритмами коррекции. С ростом объема дисков растет число этих ошибок, причем зависимость от объема не совсем линейная (сильнее растет). ЕМНИП я это читал в отчетах по статистике жестких дисков от BackBlaze, а также была рекомендация старшего коллеги: на нескольких дисках объемом от 1тб лучше применять raid6 или raidz2+.


        В целом, тема хранилищ сложная и уже давно всё придумано — облачных хранилищ дофига и больше, выбирай на любой вкус. Их надёжность будет в 99.9 случаях выше, чем то, что будет навелосипежено по такой статье (не обижайтесь).

        Никаких обид, все верно написано! Но есть товарищи, выбирающие быстро и дешево из быстро-дешево-качественно, эта схема хоть как-то позволяет компенсировать их выбор.

          0
          Из опыта — 12 дисков HGST/WD 8 тб. Контроллер Dell perc 830. Raid 5 — ребилд 12 часов.
          И никакого лишнего ахтунга…
            0

            А вы смелый =) Либо не знаете о проблемах R5 с большими дисками.
            И время ребилда, безусловно, зависит от нагрузки. Если кроме ребилда никто с массивом не работает, то в принципе поверю в 12ч. Но в продакшене такие массивы редкость. Разве что архивный сервер какой.

              0
              Разве что архивный сервер какой.

              Ну об этом и статья…
              И о бэкап сервере и говорю.
                0

                Ну и как бы неприятно потерять бэкап сервер, не? :)

            0

            Бесконечной надёжности от диска вряд ли ожидает даже новичок в нашем деле =)
            Но не суть. Верно, с ростом объема сталкиваемся с bite error rate (BER). Ваш коллега тоже прав насчет r6/raidz2+. Но в статье вы пишите немного по другому: что во время ребилда может выйти из строя еще один диск И что нужно использовать фс/raid с контрольными суммами.
            Но это оба не верно. =)
            Выход из строя еще одного диска во время ребилда:
            а) это совсем другая проблема и вообще говоря она не зависит от объема. С объемом несколько растет вероятность, но не он причина.
            б) R5 — это тоже уровень с контрольными суммами, но он не спасает при отказе второго диска в ребилде.
            в) Строго говоря от этой проблемы можно защититься и тройным зеркалом, без каких-либо контрольных сумм. Вопрос цены.


            А вот raid6 или raidz2/z3 действительно спасают И от выхода из строя второго(и третьего — для z3) диска при ребилде, И от пойманной ошибки чтения с живых дисков при ребилде. Это разные случаи. Диск может быть жив, но при чтении будет получена ошибка.


            Кстати, раз пошла такая пьянка — это вот почему ZFS'ный RaidZ1 круче своего железного аналога R5 — при ошибке ребилда R5 ВЕСЬ ваш массив говорит гудбай, без вариантов.
            В случае с Z1 ZFS знает какой блок диска чему соответствует в ФС, поэтому при некоторой доле везения будут потеряны 1 или несколько файлов, но пул останется жив. Конечно, тоже неприятно, но, согласитесь, это на порядки лучше случая "всё или ничего" =)


            Вообще, про ZFS пора писать статью...

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое