Типичные ошибки бэкапа и как их избежать

222

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

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

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

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

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

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

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

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

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

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

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

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

6. Замена бэкапа архивированием или репликацией

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

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

7. Хранение бэкапа и исходных данных вместе

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

8. Использование только одной резервной копии

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

9. Исключение из резервного копирования файлов, сохраняющихся в облаке

Сервисы облачного хранения файлов пользуются растущей популярностью. Многие полагают, что нет смысла записывать в бэкап данные, уже продублированные в облако. Однако сбои в работе облаков также случаются. Однажды ошибка в обновлении приложения «Яндекс.Диск» привела не только к потере данных, но и к удалению системных файлов – компьютеры перестали загружаться. Google Docs иногда сохраняет новые документы «в никуда», Dropbox порой бывает недоступен, а Box сильно тормозит всегда. Поэтому облако – это лишь дополнительное место хранения данных, откуда их также стоит регулярно помещать в собственные бэкапы.

10. Создание бэкапа во время обновления операционной системы

Процесс обновления ОС может нарушить создание бэкапа и привести к его повреждению, особенно если это копия системного раздела или активно используемой базы данных. Раньше во избежание сбоев рекомендовалось замерить типичное время создания бэкапов и запланировать их создание так, чтобы они не пересекались с процедурой обновления ОС. Однако проблема осложняется ещё и тем, что в Windows 10 обновления применяются автоматически. Более современный подход основан на применении технологий теневого копирования. Пока ОС обновляется, бэкап создаётся с теневых блоков файловой системы. В Windows для этого можно использовать службу теневого копирования тома (Volume Shadow Copy – VSS) от Microsoft. В Acronis Backup (Advanced) при её сбое или остановке дополнительно можно использовать модуль SnapAPI, который отвечает за все операции ввода-вывода данных на жестком диске.

Выводы:

  • Схемы бэкапа должны гарантировать низкое время RPO. Вынужденная остановка ИТ-сервисов на несколько часов критична, а на несколько дней – фатальна для современного бизнеса с высокой интенсивностью транзакций (банки, ритейл, телеком-операторы, сервис-провайдеры и многие другие).
  • Создание бэкапов вручную не может считаться надёжным методом и не отвечает текущим потребностям компаний, даже малых и не имеющих развитую ИТ-инфраструктуру.
  • Архивирование, репликация и бэкап – концептуально разные технологии для повышения отказоустойчивости. Их можо использовать совместно, но они не заменяют друг друга.
  • Современные программы для резервного копирования позволяют автоматизировать все процедуры: создание бэкапов по расписанию, их проверку, удаление самых старых копий для очистки места и отправку уведомлений о каждом этапе.
  • Решения Acronis позволяют легко реализовать правило «3-2-1» путём автоматического дублирования бэкапов на дополнительные устройства хранения и в собственное облако.