Преимущества нового метода резервного копирования виртуальных машин перед классическими схемами

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

    Разбираемся под катом.


    Обычный прямой инкрементный метод, как правило, установлен по умолчанию, и потому чаще используется. Он основан на том, что при первом прогоне создается полная резервная копия и далее сохраняется цепь последующих инкрементов. Для того, чтобы повысить надежность такой цепочки резервных копий и сократить время восстановления (оно будет линейно расти по мере роста числа созданных инкрементов), периодически необходимо создавать либо новую полную копию, либо синтетическую. Количество инкрементов, через которое нужно заново создавать полную резервную копию указывается в параметрах схемы резервного копирования. Схематично процесс выглядит вот так:

    прямой инкрементный

    Прямой метод обеспечивает высокую скорость обработки данных (I/O), так как требуется всего одна операция чтения/записи на каждый сохраняемый блок данных. Время создания инкремента и время «жизни» снапшота виртуальной машины невелико, что минимизирует нагрузку на продакшн. Однако, расход емкости СХД будет значительным, из-за хранения избыточного количества данных. Почему?

    На практике, как правило, компании устанавливают политику времени хранения резервных копий (retention policy), регламентирующую количество доступных точек восстановления (полных копий и инкрементов) или календарное время хранения. В таком случае схема прямого резервного копирования должна удовлетворять двум условиям:
    1. Цепочка резервных копий должна быть восстановимой (т.е. включать в себя полную резервную копию и все последующие инкременты. Если удалить часть цепочки, восстановить данные из такой резервной копии будет невозможно)
    2. Количество доступных точек восстановления всегда должно быть не меньше установленного пользователем.

    Предположим, установленный срок хранения 7 дней. Допустим, уже создана полная цепочка из 7 точек восстановления, следующая полная резервная копия и, скажем, еще пара инкрементов к ней. Можно удалить первую цепочку? Нет – если её удалить, останется всего 3 точки восстановления, а это противоречит п. 2 выше. Получается, избавиться от устаревших точек восстановления можно не ранее, чем через 14 дней – отсюда и избыточное хранение.

    Избежать перерасхода дискового пространства позволяет реверсивный инкрементный метод. Механизм создания таких резервных копий немного сложнее: «свежие» инкременты внедряются в первоначально созданный полный бекап, а замещенные таким образом блоки данных из полной копии сохраняются как предшествующие ей.

    реверсивный инкрементный

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

    Впрочем, и в этом алгоритме есть своё «но»: снижается скорость обработки данных и увеличивается время существования снапшота. На каждый сохраняемый блок данных требуется 3 операции чтения/записи: прочитать вытесняемый блок данных из полной копии, записать этот блок на СХД в виде реверсивного инкремента, и затем вписать в полную копию новый блок изменившихся данных. В результате, если система хранения не поддерживает такой уровень производительности, процесс резервного копирования будет займет много времени, а снапшот увеличит нагрузку на производственную среду.

    Как избежать компромиссов


    В Veeam Backup & Replication v8 реализован метод «прямого инкрементно-бесконечного» резервного копирования, который объединяет сильные стороны алгоритмов, рассмотренных выше, и позволяет получить сразу и скорость копирования данных, и быстрое восстановление, и экономное использование СХД.

    При прямом инкрементно-бесконечном методе создается полная копия и цепочка последующих инкрементов, которые хранятся до тех пор, пока не будет достигнут установленный срок хранения (пусть будет N дней). В день N записывается последний инкремент цепочки, и на следующем прогоне задания резервного копирования произойдет следующее:

    • Очередной инкремент запишется как новейшая точка восстановления в цепочке (используя один цикл чтения/записи, как и в прямом инкрементном варианте). При этом, программа резервного копирования автоматически определит, что количество точек восстановления на 1 превышает установленный лимит;
    • Далее, программа установит, что самый старый файл – это полная резервная копия, сохраненная в начале создания цепочки; а самый старый инкремент – второй по очереди в цепочке после первоначальной полной резервной копии (новее, чем полный бекап, на 1 круг заданного цикла резервного копирования);
    • Самый старый инкремент в цепочке будет внедрен в файл полной резервной копии, замещая соответствующие устаревшие блоки данных. Для этой операции потребуется 2 операции чтения/записи: одна для того, чтобы прочитать данные с инкремента и вторая – чтобы записать эти данные в файл полной резервной копии;



    • Файл инкремента удалится из цепочки и его место займет обновленная полная резервная копия. Можно сказать, что самая старая полная копия будет поэтапно «поглощать» инкременты, срок хранения которых истек.



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

    Общее количество циклов чтения/записи останется таким же, как при реверсивном инкрементном резервном копировании, однако, важно то как именно будет проходить обработка данных. Для создания инкремента потребуется только одна операция I/O, а значит, снапшот виртуальной машины будет открыт меньше времени. Оставшиеся 2 операции чтения/записи нужны для того, чтобы обновить файл полной резервной копии, и снапшот при этом уже не задействован. Кроме того, процесс создания новой полной синтетической резервной копии сведется к добавлению одного инкремента, вместо объединения целой цепочки инкрементов, как это происходило бы в случае создания «прямого инкрементного» с полными синтетическими копиями. Процедура «схлопывания» самого древнего инкремента с полной копией будет происходить уже вне окна резервного копирования без нагрузки на производственную среду, а значит, «в окне» можно успеть сделать больше резервных копий (в синтетическом бэкапе объединение блоков происходит в одном окне с созданием резервных копий).

    P.S.


    Более наглядно все рассмотренные выше алгоритмы показаны в Veeam KB-1799:
    Veeam Software
    Продукты для резервного копирования информации

    Comments 11

      0
      KVM бекапит?
        +3
        Если вопрос про Veeam Backup & Replication, то нет, только Hyper-V и ESXi.
        0
        В КВ-1931 не увидел детального описания механизма устаревания, а очень хотелось сравнить с IBM, который тоже умеет incremental forever.
        Впрочем, там хватает нюансов и легко сделать систему с очень плохим RTO.
          0
          Попробуйте посмотреть HelpCenter «Retention Policy» — там более детально описаны эти механизмы для разных схем работы.
            0
            Ткните носом, где там написано когда запускается процесс очистки? Если понимать справку буквально, то он срабатывает при запуске задания резервного копирования, что противоречит написанному в статье:
            будет происходить уже вне окна резервного копирования без нагрузки на производственную среду
              +2
              Ткнуть носом не могу, но могу пояснить, что каждый раз по окончании задания резервного копирования (и не важно успешно ли оно завершилось) программа инициализирует проверку на соответствие политике хранения и после анализа решает, что делать. Таким образом, процесс работает без нагрузки на производственную среду, но все еще относится к самому заданию.
              Приложу скриншот задания, на котором все видно.
              Скрин

                0
                Благодарю, значит всё привязано к задачам.
                0
                Под термином "окно резервного копирования" в статье имелось в виду допустимый диапазон времени, когда бэкап-продукт может нагружать работой производственную СХД.

                Если посмотреть на алгоритм, который по шагам описан здесь: «Retention Policy for Forward Incremental-Forever Backup», то:
                • п.3 (создание инкремента) — выполняется именно на производственной СХД (в частности создается снапшот, копируются данные инкремента, работа со снапшотом завершается) и на этот этап распространяется требование уложиться в «окно резервного копирования»
                • п.4 (transform) — действительно, вы правильно заметили — этот пункт не имеет отдельного расписания, он запускается каждый раз после предыдущего этапа, однако он выполняется исключительно на бэкап-СХД и только если есть устаревшая точка восстановления. Так как этот пункт не затрагивает производственную СХД, то на него НЕ распространяется требование уложиться в «окно резервного копирования» — он может спокойно выйти за его пределы — вот что имелось в виду в статье.


            +2
            Спасибо, теперь в качестве одного из важных критериев системы/утилит резервного копирования буду проверять наличие подобных алгоритмов, а то и правда обидно за избыточное хранение
              0
              Что-то я не пойму, как в описанном случае быть если файл полного бэкапа будет поврежден?
              Т.е. по сути это просто уменьшает количество файлов с инкрементами, так как их дописывает в полный бэкап. Но ведь в таком случае еще больше снижается надежность по сравнению даже с прямым инкрементным методом с одним полный бэкапом. Так как регулярно будут вноситься правки в файл полного бэкапа и соответственно не нулевая вероятность его запороть в процессе обновления.
                +1
                Строго говоря ничего революционного в новом методе нет. Полная «перестраиваемая копия» («синтетическая полная») была придумана уже много лет назад (как только СХД начали применять как бэкап-таргет вместо лент) и реально применяется многими компаниями. Еще более «агрессивным» (по интенсивности модификации данных) ее аналогом является репликация. Просто есть категории клиентов, для которых время восстановления очень важно, и они готовы пойти на небольшое увеличения риска. В любом случае нельзя полагаться лишь на одну резервную копию — нужно использовать «правило 3-2-1», про которое я в свое время написал отдельный пост на Хабре, и тогда можно пренебречь небольшим повышением риска повреждения файла полной копии — от этого не застрахован ни один метод резервного копирования.

              Only users with full accounts can post comments. Log in, please.