Резервное копирование. Incremental или Reverse Incremental?

Довольно-таки часто сталкиваюсь с вопросом, какой вариант резервного копирования лучше выбрать: инкрементальный (incremental) или реверс-инкрементальный (reversed incremental).

Оба варианта поддерживаются Veeam Backup & Replication, и даже есть еще один режим – смешанный (incremental with transform). Вот на примере VBR же и объясню, что к чему, хотя информация общая для всех систем резервного копирования, поддерживающих данные форматы.



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

Точки восстановления. Каждое копирование создает свою точку восстановления. Я уже писал про RTO и RPO (да, в той статье треугольник не раскрыт – напишу когда-нибудь тему про ценообразование решений – так что не очень обращайте на него внимание). Точки восстановления и являются показателем RPO – т.е. чем чаще вы делаете резервное копирование, тем лучше (меньше) показатель RPO, и как результат меньше потерянных данных.  К примеру, при ежедневном копировании, в худшем случае (авария произошла до завершения очередного резервного копирования), вы теряете данные за одни сутки; при ежечасном – только за час (при условии, что копии работоспособны).

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

Ну, и еще поясню. В этой статье под источником (англ. source) я подразумеваю то, что мы резервируем; под приемником или целевой системой хранения (англ. target) – место, куда складываются резервные копии.




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

Забираемые из источника инкременты записываются и хранятся в виде:

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

Проиллюстрирую, как выглядят точки восстановления на временной оси:

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


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


Вот такая картинка для наглядности (после резервного копирования в пятницу обнаружен сбой, произошедший в четверг (до резервного копирования) – последняя работоспособная копия сделана в среду):

Вы можете подумать, что раз в большинстве случаев требуется восстановить данные из последней копии, то предпочтительно всегда создавать реверс-инкрементальные копии. Но давайте посмотрим немного глубже. Вот сравнительная табличка режимов хранения резервных копий в VBR v5. Обратим внимания на строчку «скорость создания инкрементальных копий». Для реверсивно-инкрементальных копий каждый раз создается синтетическая полная копия и отдельно реверс-инкрементальная. Поэтому, это самый медленный режим работы по созданию резервных копий.


Давайте взглянем на влияние на целевое хранилище резервных копий. Количество операций ввода-вывода, при сохранении данных резервной копии.

	Reversed Incremental	Incremental	Incremental w/transform
Инкрементальные копии (ежедневно)	3x I/O (запись + чтение + запись каждого блока)	1x I/O (запись каждого блока)	1x I/O (запись каждого блока)
Полные синтетические копии (еженедельно)		2x I/O (чтение + запись каждого блока полной резервной копии)	4x I/O (чтение + запись + чтение + запись каждого блока)

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



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





Вот несколько рекомендаций:

• Резервное копирование небольшого количества изменяющихся ежедневно данных раз в сутки вне бизнес часов на обычный дисковый массив без дедупликации и без специальных требований по сохранению резервных копий на ленты или репликации данных за пределы площадки – вполне годится реверсивно-инкрементальный способ.
• Резервное копирование больших объемов на дедуплицирующий массив – оптимально использовать стандартный инкрементальный режим.
• Для копирования на удаленные площадки применять репликацию или использовать следующую версию Veeam Backup :)
• В средних инфраструктурах со стандартными часами работы офиса (5 дней), возможно, подойдет смешанный режим инкрементальный с преобразованием в реверс-инкременты.
• Не забывать про возможность использования периодического создания полных копий (например, ежемесячных архивов) – active fulls, если создание синтетических полных копий происходит очень долго.

И добавлю еще несколько моментов по теме.


Какой из данных режимов хранения подойдет для восстановления в режиме Instant VM Recovery?
Чаще всего – любой, если только вы не используете очень медленное хренилище данных с медленным доступом по сети LAN. При IVMR узким местом чаще всего является подключение к хостам ESX (линк). Кроме того, основная нагрузка на чтение блоков, как правило, идет во время загрузки машины. Но в любом случае рекомендую тестировать выбранное решение перед вводом в эксплуатацию.



Почему нет дифференциального (differential) резервного копирования?
Это уже способ копирования, а не только хранения.
Во-первых, дифференциалы занимают много больше на диске: фактически понедельничный блок будет хранится 6 раз, вторничный – 5, и так далее. Во-вторых, такие копии крайне сложно превратить в синтетическую полную копию. В-третьих, VMware CBT (changed blocks tracking) выдает только блоки, изменившиеся с последней копии. В-четвертых, если и забирать блоки, изменившиеся со времени создания последней полной копии, время окна резервного копирования будет увеличиваться каждый день за счет копирования одних и тех же блоков.
То есть, как мы видим, минусов больше, чем плюсов. Есть мнение, что дифференциальное копирования продвигалось производителями систем хранения данных, чтобы можно было продавать больше своих СХД.





Если есть вопросы – задавайте, постараюсь дополнить текст.