В этом посте обещал подробнее остановиться на истории с тестированием резервных копий. Сегодня как раз об этом. Чтобы обойтись без неприятных сюрпризов и в без того волнительные моменты потери данных, резервные копии нужно тестировать. Далее речь пойдет не про проверку целостности файлов резервных копий (проверка контрольной суммы блоков данных в файле бэкапа), а о полноценном тестовом восстановлении, когда проверяем работоспособность того, что у нас восстановилось.
Что может быть не так с файлом бэкапа
Помимо случаев, когда поврежден сам файл бэкапа, существует много причин, технических и организационных, почему восстановление из резервной копии может закончиться ошибкой. Остановлюсь на тех, с которыми столкнулся я.
В резервную копию ушли уже поврежденные данные/файлы. На сервере начал сыпаться диск. Мониторинг не отработал. Часть файлов испортилась, но они благополучно забэкапились. Такая проблема неделями может оставаться незамеченной, пока не понадобится открыть нужный файл. В процессе восстановления окажется, что файлы в бэкапе тоже нерабочие.
Неконсистентный бэкап. Такое может случится, когда выбрали неподходящее средство резервного копирования. Например, на виртуальной машине работает база данных, для бэкапа которой администратор решил использовать резервное копирование ВМ без поддержки целостности приложения (application aware backup).
Дело в том, что при своей работе БД активно использует кэш в оперативной памяти, и часть данных находится там. СУБД записывает данные на диск так, чтобы они в любой момент были согласованы между собой, и при внезапном выключении сервера база не превратилась в бесполезный набор байтов. Система резервного копирования записывает данные не мгновенно, и ничего не знает про синхронизацию кэша с файловой системой, поэтому при резервном копировании часть данных может быть записана в неправильном порядке. Тогда после восстановления ВМ мы получим поврежденную базу, части которой не соответствуют друг другу.
При использовании специальных агентов резервного копирования такого не произойдет.
Рабочий бэкап есть, но там не то. Это встречается довольно часто, потому что цикл жизни системы примерно следующий: сделали систему и поставили ее на резервное копирование. Потом рано или поздно поменяли архитектуру системы, добавили/убавили сервера, диски, переименовали, восстановили рядом из бэкапа, а отразить изменения в политике резервного копирования забыли. Вот и получается, что в бэкап идет не то что нужно.
Зачем тестировать
Казалось бы, ответ простой: чтобы удостовериться, что из бэкапа можно восстановиться. Но есть еще пара важных организационных моментов, которые неплохо бы для себя прояснить.
Понимание реального RTO. Умозрительные оценки будут отличаться от реальности. Особенно если весь процесс восстановления не ограничивается разворачиванием данных или приложений из бэкапа. Прежде чем восстанавливаться, нужно понять, что и откуда мы восстанавливаем. После восстановления не всегда система сразу готова к использованию, иногда требуются ручные настройки. После нужно проверить работоспособность восстановленных систем. Если бэкапы хранятся на лентах вне офиса, то нужно понять, как быстро их довезут до вашего офиса. Все это увеличивает время восстановления или часы ко времени восстановления.
Так что если рассматривать весь путь восстановления “от двери до двери”, то скорее всего RTO получится больше, чем просто “чистая” скорость восстановления данных.
Кто и что делает. Во время тестовых восстановлений тестируется не только техника, но и работа людей, процессов, регламентов, если они есть;) Это возможность выявить слабые места, продумать, что вы будете делать, если нужного человека не окажется на месте.
Чем больше людей задействовано в восстановлении, чем нужнее такие боевые учения.
Как тестируем
Частота тестирований. После того как настроили систему резервного копирования, проверьте, хотя бы раз, что у вас там бэкапится, и попробуйте восстановить.
Далее расписание проверок определяет владелец сервиса, например, разработчик, исходя из того, как часто вносятся изменения в приложения/данные, важности тех или иных данных, какие у него есть ресурсы для тестирования.
Различные сценарии аварий и восстановлений из бэкапов. Включите воображение и продумайте различные причины, почему может понадобиться восстановление из резервной копии. Так вы проверите технику, процессы, людей в боевых условиях, а не проведете сферическое в вакууме восстановление. Удобно для этого наметить модели угроз. Как вариант:
- сбой аппаратуры: отказал диск, сервер с исходной информацией;
- программный сбой: неудачное обновление, вирус;
- человеческий фактор: администратор удалил нужный файл.
В каждом из этих случаев восстанавливаться нужно будет в разном объеме: где-то отдельные файлы, а где-то разворачивать все.
Обязательно попробуйте восстановиться удаленно с домашнего компьютера. Ведь сбои происходят не только в рабочие часы.
И еще продумайте действия на пару шагов вперед: что будете делать дальше, если во время восстановления бэкап оказался пшиком или восстановиться не удалось. Если во время тестов выяснилось, что последний бэкап оказался нерабочим, по возможности сделайте новый бэкап вне очереди или предупредите коллег, чтобы они работали с данными максимально бережно до следующего цикла резервного копирования.
Восстанавливаться из разных точек времени. Неизвестно, какие именно бэкапы вам понадобятся, поэтому при тестировании пробуйте восстановиться из разных точек восстановления. Так вы проверите, что у вас в порядке, например, не только пятничный бэкап, но и тот, что вы делаете в среду. Чем обширнее будет выборка, тем меньше поводов переживать за работоспособность резервных копий.
Документирование процедур восстановления. Как-то читал, что в одной конторе используют следующий подход к тестированию восстановления из бэкапа: человеку, который ничего не знает о системе, предлагают сделать все восстановление только по документации, никто из коллег ему не подсказывает. Потом по результатам проверяют, удалось ли восстановиться, и делают выводы об актуальности инструкций. Необязательно идти на такие крайности во время боевых учений, но хорошо бы зафиксировать в регламентах и прочей документации все необходимые действия по восстановлению той или иной системы.
Делается это для этого, чтобы была возможность запустить процесс восстановления, если человек, отвечающий за систему, временно недоступен.
Также нужно позаботиться, чтобы вся необходимая информация для восстановления системы (конфигурационные настройки, лицензионные ключи, пароли) была не только в голове отсутствующего администратора, но продублирована в электронном виде и надежно хранится вдалеке от посторонних глаз.
На всякий случай: тестируем восстановление в отдельной песочнице, не рискуя продуктивом.
Автор: DataLine
