Data Domain на бэкап-таргете: объём хранения упал в 12 раз

Несколько лет назад мы собирали схему дедупликации своими руками - rsync с хардлинками, скрипты ротации снимков. Работало, экономило место, но только на уровне целых файлов. Базы данных, образы виртуальных машин, почтовые ящики - для них схема с хардлинками не помогала почти ничем. В 2005-м мы написали, что блочная дедупликация выиграет с разгромным счётом, как только станет доступна по цене. Похоже, это время наступило.

Мы развернули устройство Data Domain в инфраструктуре одного из клиентов как бэкап-таргет. Итог через несколько недель работы: объём хранимых резервных копий сократился в 12 раз. Там, где раньше с трудом помещалась месячная история бэкапов, сейчас лежит три месяца с запасом.

Что такое Data Domain и почему это другое

Data Domain - это специализированное устройство хранения с встроенной блочной дедупликацией. Для программы резервного копирования оно выглядит как обычный NFS или CIFS-ресурс, куда можно писать бэкапы. Но внутри происходит другое: входящий поток данных разбивается на блоки фиксированного размера, для каждого блока считается хэш. Если такой блок уже хранится - записывается только ссылка. Уникальный блок - записывается один раз.

Это принципиально отличается от того, что делали мы с rsync и хардлинками. Хардлинки работают на уровне файлов: если файл не изменился - хранится один раз. Но если файл изменился хотя бы немного - хранится заново полностью. Data Domain видит внутрь файла. Образ виртуальной машины, в котором изменилось 2% блоков, займёт именно 2% нового места, а не весь образ целиком.

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

Как выглядит на практике

У клиента - несколько физических хостов с виртуальными машинами, база данных, Exchange. Бэкапы шли на обычный дисковый массив. Место заканчивалось быстро: полные копии виртуалок раз в неделю, инкременты каждую ночь. История в месяц - это приблизительно потолок, дальше начинали чистить старые копии.

Data Domain встал как дополнительный бэкап-таргет - сначала параллельно со старым массивом, чтобы сравнить. Потом старый массив отключили за ненадобностью.

Степень дедупликации зависит от данных. Что увидели:

• Полные копии виртуалок - дедупликация очень агрессивная. Виртуалки с одной базовой ОС делятся огромным количеством одинаковых блоков. Несколько Windows Server 2003 с похожим набором ПО - почти весь объём хранится один раз.
• Инкременты - дедупликация выше, чем можно ожидать. Ночной инкремент содержит только изменённые блоки, и большая часть из них пересекается с блоками, уже хранящимися от предыдущих копий.
• Базы данных - хорошо, но менее впечатляюще, чем виртуалки. Транзакционные изменения дают много уникальных блоков.
• Exchange - очень хорошо. Почтовые данные содержат много повторяющихся структур.

Суммарная степень дедупликации по всему потоку вышла около 12:1. Цифра неожиданная, но данные в отчёте Data Domain показывают именно это.

Что изменилось в регламенте

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

Это меняет не только количество хранимых копий, но и то, что можно с ними делать. Можно хранить ежедневные полные бэкапы виртуалок вместо схемы полный-плюс-инкременты - и это не приводит к взрыву объёма. Полный бэкап на каждую дату проще восстанавливать: не надо собирать цепочку полного и нескольких инкрементов.

Это то, о чём мы думали ещё когда переходили с ленты на диск: главное, чтобы проверка восстановления была быстрой и понятной. С Data Domain и ежедневными полными копиями это стало проще.

Что не бесплатно

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

Отдельный вопрос - производительность записи. Data Domain должен успевать считать хэши и проверять дубликаты в реальном времени. На практике скорость записи заметно ниже, чем у обычного дискового массива. Если бэкап-окно у клиента очень жёсткое - надо считать, влезет ли поток с дедупликацией в нужное время.

У нас влезает. Ночное окно используется примерно на 60% - есть запас.

Итог

Блочная дедупликация на уровне бэкап-таргета - это реальная технология, которая работает именно так, как написано в документации. 12:1 - не маркетинг, а измеренная цифра на конкретной инфраструктуре. Для виртуализованных сред с похожими гостевыми ОС она будет выглядеть примерно так же или даже лучше.

Для инфраструктуры, которую мы ведём в рамках сопровождения, Data Domain пока рассматриваем как вариант для клиентов с достаточным масштабом виртуализации. Для мелких конфигураций схема на rsync или обычном дисковом таргете закрывает задачу дешевле. Но разрыв в удобстве - ощутимый.