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


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

1. Создание бэкапов вручную

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

Сегодня практика ручного создания бэкапов приводит к низкой надёжности системы резервного копирования. Один из её ключевых показателей – RPO (Recovery Point Objective), становится недопустимо высоким. Он отображает период, за который может произойти невосстановимая потеря данных. Со времени последнего бэкапа до возникновения сбоя оказываются утрачены самые новые и актуальные для текущей работы файлы. Единственный способ снизить потери – делать бэкапы чаще (несколько раз в день), но создавать их так часто вручную просто невозможно.

2. Сохранение бэкапов без их проверки

Наличие резервной копии ещё не гарантирует возможность восстановления из неё.
Процедура создания бэкапов обычно длится долго, и админы не хотят тратить дополнительное время на их проверку. Пренебрежение валидацией резервных копий часто приводит к тому, что последний бэкап по какой-то причине оказывается повреждённым. Тогда показатель RPO ухудшается вдвое, поскольку приходится использовать предыдущий (более старый) бэкап, и хорошо, если он вообще есть.

Поэтому в Acronis Backup (Advanced) проверка резервной копии файлов может выполняться автоматически после создания каждого бэкапа или запускаться по расписанию. Во время проверки имитируется процедура восстановления всех файлов из резервной копии в фиктивную папку. При проверке бэкапа всего диска или тома вычисляется контрольная сумма для каждого блока данных, сохраненного в резервной копии.

3. Перезапись существующих данных при восстановлении из повреждённого бэкапа

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

4. Отсутствие контроля за свободным местом для бэкапа

Эта проблема особенно характерна для ручного создания резервных копий. По мере роста объёма исходных данных для их полного бэкапа требуется всё больше места. В какой-то момент следующая копия не умещается в оставшийся объём, и длительный процесс её создания завершается с ошибкой. Часто такая ситуация вызывает целый каскад новых ошибок. Например, для увеличения свободного места админ может удалить один из прежних бэкапов и по ошибке выбрать не тот. Во избежание подобных ситуаций, в Acronis Backup (Advanced) можно создавать планы резервного копирования и указывать время жизни каждого бэкапа. Старые будут автоматически удаляться после того, как потеряют актуальность.

5. Удаление предыдущей копии бэкапа до того, как будет создана новая

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

Какие из всего сказанного выше можно сделать выводы?

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

Полезные ссылки:
» Вебинары по бэкапу и защите данных
» Демоверсия для бэкапа корпоративных серверов Acronis Backup Advanced

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