Таков путь! Эволюция бэкапов в Timeweb: от rsync до ZFS

    Мы постарались кратко описать путь, который прошла команда Timeweb за 10 лет: от rsync, LVM и DRBD до ZFS. Эта статья будет полезна тем, кто занимается серверной масштабируемой инфраструктурой, планирует делать бэкапы и заботится о бесперебойной работе систем.

    image

    Расскажем о:

    • rsync (remote synchronization)
    • DRBD (Distributed Replicated Block Device)
    • инкрементальные бэкапы под DRBD с помощью LVM
    • DRBD + ThinLVM
    • ZFS (Zettabyte File System)

    rsync и бэкапы до н. э.


    rsync (remote synchronization) — вообще не про бэкапы, строго говоря. Это программа, которая позволяет синхронизировать файлы и каталоги в двух местах с минимизированием трафика. Синхронизация может выполняться и для локальных папок, и для удаленных серверов.

    Достаточно часто rsync применяется для резервного копирования. Мы использовали эту утилиту, когда сайты были проще, а клиентов было значительно меньше.

    Rsync неплохо справлялась с задачей, но самая большая проблема здесь — скорость. Программа очень медленная, она сильно нагружает систему. А с увеличением данных, начинает работать еще дольше.

    Rsync можно применять в качестве технологии бэкапирования, но для совсем небольшого объема данных.

    LVM (logical volume manager) — менеджер логических томов


    Конечно, нам хотелось делать бэкапы быстрее с наименьшей нагрузкой, поэтому мы решили попробовать LVM. LVM позволяет делать снапшоты, даже используя ext 4. Таким образом, мы могли делать бэкапы при помощи снапшота LVM.

    Эта технология использовалась нами недолго. Хоть бэкап и выполнялся быстрее, чем в rsync, но он был всегда полный. А хотелось копировать только изменения, поэтому мы перешли к DRBD.

    DRBD


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

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

    image

    Однако и при таком методе все равно существует недостаток. При синхронизации DRBD сильно нагружает дисковую подсистему. Это значит, что сервер будет работать медленнее. В результате бэкап мешал работе основных сервисов, то есть сайтов пользователей. Мы даже старались делать бэкапы в ночное время, но они иногда просто не успевали завершиться за ночь. Приходилось маневрировать, чередовать бэкапы. Например, сегодня выполняется одна часть серверов, потом другая. Разносили бэкапы в шахматном порядке.

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

    Thin LVM


    В этот момент бизнес поставил задачу сделать 30-дневные бэкапы, и мы решили переходить на thinLVM. Основную проблему это так и не решило! Мы даже не ожидали, что потребуется настолько высокая производительность файловой системы для поддержания тонких снапшотов. Этот опыт был совсем неудачный, и мы отказались в пользу обычных толстых LVM снапшотов.

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

    Продолжаем поиски…

    Было решено попробовать ZFS.

    ZFS


    ZFS — неплохая файловая система, которая имеет множество уже встроенных плюшек. Что при ext 4 достигается путем установки на LVM, подключения DRBD-устройства, то при ZFS это есть по умолчанию. Сама файловая система очень надежная. Отдельно стоит отметить функцию Copy-on-write, эта технология позволяет очень бережно обращаться с данными.

    ZFS позволяет делать снапшоты, которые можно копировать на сторадж, а также автоматизировать резервное копирование. Не нужно ничего придумывать!

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

    Больная тема ZFS — переполнение диска. Эту проблему мы смогли решить путем резервирования пустого пространства. Когда диск переполнен, будут предприняты меры по разгрузке сервера и очистке места.

    После тестирования мы постепенно начали вводить новые сервера, переводить старые сервера на ZFS. Проблем с бэкапами больше нет! Можно делать 30- или 60-дневные бэкапы, хоть бэкапы каждый час. В любом случае сервер не будет испытывать избыточных нагрузок.

    Собрали все данные в таблицах ниже для сравнения бэкапов при использовании различных технологий.

    image

    image

    image

    image

    Что было дальше?


    В планах обновить ZFS до 2 версии OpenZFS 2.0.0. в 2021 году. Мы готовим переход с использованием всех фишек, которые были анонсированы с выходом релиза в начале декабря.

    The Way this is!


    Таков путь мы выбрали для себя! Решаете ли вы похожие проблемы? Будем рады, если поделитесь в комментариях опытом! Надеемся, статья оказалась полезна и, если вдруг перед вами так же стоит задача делать бэкапы с помощью встроенных утилит в Linux, наша история поможет подобрать подходящее решение.
    Timeweb
    VDS, инфраструктура и решения для бизнеса

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

      +2
      Вижу про ФС, про управление томами, снепшоты. А где, собственно, про бекапы, про восстановление? Вот это вот всё....!?
        0
        Евгений, здравствуйте!

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

        Создание бэкапов и их восстановление, как нам кажется, хорошая тема для отдельной статьи. Если вы с нами согласны, дайте знать :) Соберем материал и поделимся подробностями в следующей статье.
          +2
          Простите, но снепшот ФС и его репликация — это только один подход к РК, просто вы делаете его разными средствами. При этом нет ничего про то — какие данные у вас на этих ФС, как приложение к этому бекапу относится, как и что вы из такого бекапа можете восстановить и как быстро. Это статья вообще не про бекап, а про снепшоты, которые мы можете куда то утащить с основного сервера и не более того.
            +1
            Евгений, поскольку мы рассказываем про опыт Timeweb, то подразумевали, что на нашем хостинге хранятся сайты пользователей, базы данных.

            Мы считаем, что тема про восстановление достойна отдельной статьи. В ней бы начали с выбора протокола сетевого доступа к файловым системам, далее рассказали про способ защиты пользовательских данных при подключении и копировании и закончили системой снятия дампов mysql.
        0
        А требования к оперативной памяти разных ФС сравнивали? Про ZFS говорят, что ей нужно много ОЗУ — у вас такое было?

        И ещё по поводу бекапов мне в приниципе интересно, как народ решает вопрос о объеме дисковой системы для бекапов: для каждого условного 1Тб данных, сколько Тб дискового пространства вы резервируете на бекап-сервере?
          +1
          А требования к оперативной памяти разных ФС сравнивали? Про ZFS говорят, что ей нужно много ОЗУ — у вас такое было?

          Размер потребляемой ОЗУ на ARK кэш задается в параметрах модуля zfs_arc_max. В нашем случае он вычислялся эмпирически, чтобы не мешать работе основных сервисов, но при этом давать файловую производительность.

          И ещё по поводу бекапов мне в приниципе интересно, как народ решает вопрос о объеме дисковой системы для бекапов: для каждого условного 1Тб данных, сколько Тб дискового пространства вы резервируете на бекап-сервере?

          Тут все очень индивидуально, так как размер снапшота в ZFS зависит от размера добавленных данных. У нас это 1 к 2 для хранения сроком в 30 дней. То есть на 1 терабайт данных приходится 2 терабайта на бэкап-сервере.
          +2
          А резервные копии через scp!111… 0_o

          А почему не завести NAS с множеством zfs пулов и не делать zfs send | ssh backup@nas zfs recv, выбирая пул на NAS по каким-то признакам, например по группе серверов или имени кластера, если их несколько. И потом слать инкрементальные копии между 2-я snapshot-ами: старым (который уже отправлен) и новым (выполненным сейчас) через тот же send/recv. Для целей автоматизации старый, после передачи, можно грохнуть а новый переименовать в старый…

          И ZFS у вас на Linux?
            +1
            Здравствуйте!
            А почему не завести NAS с множеством zfs пулов и не делать zfs send | ssh backup@nas zfs recv, выбирая пул на NAS по каким-то признакам, например по группе серверов или имени кластера, если их несколько. И потом слать инкрементальные копии между 2-я snapshot-ами: старым (который уже отправлен) и новым (выполненным сейчас) через тот же send/recv. Для целей автоматизации старый, после передачи, можно грохнуть а новый переименовать в старый…

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

            И ZFS у вас на Linux?

            Да, на Linux.
            0
            В «избыточность пространства» для rsync не совсем верно. Совсем не обязательно хранить на каждую точку копию всех данных. Можно хранить одну копию + изменённые файлы.
            В случае ZFS немногим экономнее: одна копия + изменённые блоки. Хранить вообще только изменения не выйдет и тут.

            К тому же, не всегда требуется копировать(да и считывать) всю файловую систему, часто достаточно работать только с данными какого-нибудь приложения, и тут rsync может быть уже намного выгоднее, и по скорости, и по объёму.
              +1

              Довольно много работаю и с rsynс и с zfs. Если коротко, то rsync имеет пожалуй только 1 профит, что он более переносимый. Но если у вас *nix, то проблем нет. Впрочем, через сетевые диски все прелести zfs доступны и для win.
              У zfs много плюшек, перечислять нет смысла, даже на хабре не одна статья была. В мире бесплатных инструментов я не знаю альтернатив. А за большие деньги — Netapp, и Co, там тоже всё есть, но это совсем другой уровень....

              +1

              У XFS с новыми ядрами доступна еще такая штука, как reflink-и. Позволяют быстро создавать копии директорий/файлов, без копирования блоков данных. Новые блоки выделяются только при изменении. Т.е некий такой симбиоз хардлинков и снапшотов, если можно так сказать.
              Около года пользую этот механизм на одном из бэкап серверов и что-то всё больше склоняюсь таки к zfs. В реальности reflink-копирование выполняется далеко не мгновенно, иногда минуты (на нескольких сотнях гб данных). Плюс невозможность оценить реально доступное свободное место, из-за чего вроде бы 85% заполнения, а уже иногда (!) начинаются ошибки no free space on device :(


              Но для не очень крупных бэкапов/горячих копий может для кого-то будет интересной альтернативой.

                0
                reflink — отличная штука, но нужна реально не часто.
                вот пример: сделал ddrescue для 1тб диска, сохранял образ сразу на fs которая поддерживает reflink — btrfs, дальше делаю cp --reflink=always и работаю с копией файла, если надо check disk и всё вот это.
                мне в такой ситуации не нужен снапшот диска, но «снапшот» файла — то что доктор прописал.
                и делается по времени на btrfs это вроде как достаточно быстро.
                  0

                  Да, небольшие файлы быстро, а вот 400гигов бд копируются минуту. Иногда. В общем, штука специфичная, да.
                  Btrfs не готов применять в проде. :)

                +2
                Держать три десятка снапшотов на тонком томе LVM, — это действительно не очень быстро. Я для решения этой проблемы придумал схему, при которой на рабочем массиве держится только один снапшот на каждый тонкий том, который служит для отслеживания изменений с последнего бэкапа. Вот на бэкап устройстве уже действительно много снимков.
                Рабочие и резервные LVM группы отличаются и расположены на различных RAID группах. Если интересны подробности, у меня статья про «LVM и Матрешки» в профиле.

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

                  Что именно у Вас копируется по SCP? Данные из конкретного снапшота, создаваемого на ноде виртуального хостинга? Клиентские приложеньки работают на ФС ZFS и там же создаются снапшоты?

                  Как работает восстановление клиентов в случае сбоя — берётся последний снапшот и наливается на новый/резервный сервер или есть какая-то другая логика?
                    0
                    Евгений, здравствуйте!

                    Попробуем ответить подробно на ваш комментарий.

                    Есть два вида серверов: клиентский и бэкапный. Файловая система, на которых находятся клиентские данные, — ZFS.

                    На клиентском сервере работают клиентские приложения. На бэкапном сервере хранятся бэкапы.

                    Снапшоты делаются на клиентском сервере и копируются на бэкапный сервер.

                    Схема бэкапа достаточно проста:

                    1. На клиентском сервере есть снапшот 1.
                    2. Перед копированием создается снапшот 2.
                    3. Снапшот 1 копируется / импортируется на бэкапный сервер. Для этого могут использоваться разные средства: ssh, scp, netcat и др. В нашем случае используется приложение, построенное на базе ssh.
                    4. По окончании успешного копирования снапшот 1 мержится / удаляется с основными данными, его место занимает снапшот 2.
                    5. При бэкапе переходим к пункту 1.

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

                    Выход дисков из строя отслеживается. Все данные обязательно зеркалируются на разные диски.

                    Все ли понятно объясняли? На все ли вопросы ответили?
                    –1

                    Почему Hetzner умеет делать бэкапы и снапшоты VPS без qemu-agent и прочего обвеса, а вы нет?

                      –1

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

                        +2
                        restic хорош.
                        В разы быстрее rsync, шлет и хранит только изменения.
                          0
                          Срогласен+1
                            0
                            Хорош, но не в разы быстрее, конечно — это явное преувеличение. Я использую и то, и другое: разница в скорости есть, но не такая уж заметная даже.
                            Да и rsync тоже шлёт, и может хранить только изменённые файлы с помощью хардлинков.

                            К тому же, не так уж правильно сравнивать отдельно инструмент для синхронизации и более законченное решение именно для резервного копирования. Скорее тогда с rsnapshot надо сравнивать его и подобными вещами.
                            +1
                            Спасибо, полезно. Сейчас переходим пробуем ZFS

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

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