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

^{сорс картинки [1]}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

P.S.

Более наглядно все рассмотренные выше алгоритмы показаны в Veeam KB-1799 ^[3]:

• KB-1932: Прямой инкрементный и прямой инкрементно-бесконечный ^[4]
• КВ-1933: Реверсивный инкрементный ^[5]
• КВ-1931: Механизм контроля срока хранения цепочки инкрементов (retention policy) ^[6]

Автор: Hromoruk

Источник ^[7]