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

01. 11. 2016

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

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, который отвечает за все операции ввода-вывода данных на жестком диске.

Выводы

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