Решил завести рубрику: современные методы резервного копирования.
Каждый год в этой сфере появляются новые решения, упрощающие создание и обслуживание бэкапов. Именно о них я и буду здесь рассказывать, надеясь быть кому-то полезным.

Начну с определений и понятия «призрачные копии»

Резервные копии – универсальная страховка от большинства айтишных проблем. Однако их наличие ещё не гарантирует возможности восстановления данных. Известная поговорка гласит, что системные администраторы делятся на два типа: тех, кто не проверяет бэкапы и тех, кто уже проверяет их регулярно. Теоретически по содержанию копия ничем не отличается от оригинала, но на практике она может оказаться повреждена по самым разным причинам. Наиболее распространённая из них – человеческий фактор.

«Призрачная копия», такое явление еще называют «битый архив», это термины резервной копии, изначально созданной с ошибкой. Файлы внутри такой копии присутствуют, но корректно восстановить их не получается по разным причинам, например некорректный бэкап приложений Microsoft (базы данных Exchange, SQL, SharePoint), в котором база данных находится в несогласованном состоянии. При восстановлении такой базы, воспользоваться ей не получится.

Изначально работа с бэкапами требовала множества ручных операций, поэтому их создание и обслуживание до сих пор многие воспринимают как необходимое зло. Совсем недавно админу каждый раз было нужно проверять состояние хранилища, удалять на нём неактуальные копии, а на клиентских машинах – временные файлы, старые дампы и прочий мусор. Затем оценивать свободное место, вводить пароль для шифрования и проверять, что копия успешно создалась. Основные этапы отнимали много времени, из-за чего проверкой часто жертвовали.

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

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

Современные программы выполняют не только создание, но и обслуживание резервных копий. Они умеют дублировать их (например, в облако), автоматизируют все возможные шаги, а минимум ручных операций помогают выполнить при помощи интерактивных модулей – мастеров настройки. В них уже записаны типовые конфигурации и шаблоны задач. Их остаётся только выбрать и слегка подредактировать с учётом специфики работы компании и её ИТ-инфраструктуры.
Например, если полная резервная копия не может быть создана за отведённое время, то можно выбрать одну из схем с цепочкой версий. Тогда каждый последующий бэкап будет выполняться быстрее, поскольку в него дописываются только новые и изменившиеся данные. Ускоряет создание бэкапов и способ их представления как блоков данных. За счёт пропуска повторяющихся блоков (механизмов дедупликации) новые программы для резервного копирования также экономят место в хранилище и время, требуемое на каждую операцию.

Интерактивные режимы в новом софте для бэкапа сведены к разумному минимуму. Основные задачи выполняются по созданной схеме, а любые отклонения в ней становятся известны сразу. Как минимум, администратор получает оповещение о сбоях по электронной почте. Продвинутые программы позволяют заранее указать последовательность действий при возникновении ошибок. К примеру, если дисковое хранилище оказалось недоступно, то можно повторить попытку соединения заданное число раз. Если же проблема осталась – админ получит подробный отчёт. Начиная с одиннадцатой версии в Acronis Backup & Recovery появилась функция автоматического создания плана восстановления. Он содержит пошаговые инструкции, которые направляются администратору.

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

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

Плюс такого метода в том, что время на проверку экономится в разы. Её можно выполнять автоматически и без необходимости вводить пароль. Минус заключается в меньшей надёжности. В редких случаях ошибка может произойти на этапе обработки метаданных, а коллизии хеш-функций перестали быть чисто теоретической проблемой из-за увеличения объёма данных. Однако это гораздо лучше, чем не проверять копии вообще.
Вместе с объёмом данных растёт и вероятность других ошибок, поэтому по мере масштабирования СХД приходится использовать качественно новые способы их обнаружения и устранения. Продукты корпоративного класса отличаются не только типом лицензии, но и применяемыми алгоритмами. Однако проблема «призрачных копий» может возникать не только из-за программных сбоев или человеческого фактора. Есть целый ряд аппаратных причин их появления.

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

Выводы всего вышеперечисленного:

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

Так же на эту тему можно послушать мои вебинары «Бэкап и защита данных».

Не забывайте бэкапиться, друзья!