1998 год, Студия Pixar. Полным ходом идет создание «Истории игрушек 2». В процессе участвует более 150 человек. Размер исходных материалов анимации составляет 10 ГБ (по тем временам это очень много). Каждый день строится полный бэкап на ленту. Кассета имеет размер… 4ГБ (данные при записи на ленту сжимаются, но, конечно, не до такой степени). Каждый раз выдается ошибка, но этого никто не замечает, потому что лог-файл располагается на этой же кассете и пишется в самом конце бэкап-задания, а, поскольку места на кассете уже нет, он имеет размер 0 байт. Каждую неделю проводится тестовое восстановление данных, в ходе которого проверяются первые 2000 кадров анимации. И, конечно, каждый раз тест проходит успешно.
… А потом вдруг наступил день, когда кто-то из сотрудников (ошибочно или намеренно) запустил на сервере команду "/bin/rm -r -f *" (или аналогичную), которая удалила 90% из 100,000 файлов исходников анимации. Один из сотрудников компании, Ларри Катлер, как раз просматривал файлы папки с исходниками анимации, собираясь откорректировать что-то в модели шляпы персонажа Вуди, как вдруг он заметил, что файлов в папке осталось всего 40… потом 4… а еще через секунду их там не осталось вовсе. Ларри позвонил в ИТ службу и сообщил, что "произошла масштабная потеря данных", и что "восстановление потребует полную резервную копию..." Которой, как выяснилось чуть позже, у них не было, несмотря на ежедневный бэкап.
Что произошло потом? «Полная резервная копия», по понятным причинам, оказалась не совсем полной: оказалось, что на ленту последнее время не попадало до 30,000 файлов. Задача усложнялась тем, что в папке происходили постоянные создания, удаления, и изменения файлов, поэтому резервные копии, созданные в разное время, часто содержали различающиеся наборы файлов, в силу чего их нужно было вручную сопоставлять, чтобы выявлять, что было удалено планово, а что исчезло в результате сбоя. Потребовалось много дней кропотливой ручной работы по анализу всех недостающих файлов, уцелевшие версии которых были разбросаны в инкрементальных и полных резервных копиях за последние два месяца.
Хотелось бы проанализировать: какие действия нужно предпринимать, чтобы минимизировать проблемы, подобные описанным выше.
Прежде всего следует различать тестирование целостности резервной копии (media testing) и тестирование восстановления из резервной копии (data testing). В первом случае вы проверяете только целостность копии по контрольным суммам блоков данных. Во втором вы проводите тестирование, отражающее тот или иной моделируемый сценарий отдельного сбоя или «полномасштабной катастрофы» вашей продуктивной сети.
Тестирование восстановления из резервных копий рекомендуется производить регулярно
По мере того, как продуктивная система растет в размере, результаты теста восстановления могут меняются. Например, неделю назад все корректно восстанавливалось, а потом «вдруг» резервные копии перестали умещаться в хранилище, а сообщение об ошибке не заметили. Или установили новое сетевое приложение, а его файловое расположение не попало в резервную копию. Или система может успешно реплицироваться блочным методом прямого отображения на диск, имеющий заводскую емкость в 2ТБ. «Прямое отображение блоков» означает, что блоку данных на исходном диске прямым образом (без использования промежуточной таблицы переадресации) сопоставляется блок данных на целевом диске. Но, если в какой-то момент будет проведен апгрейд системы, и емкость исходного диска превысит 2ТБ, а бэкап диск не будет обновлен (такое часто происходит, потому что инфраструктура продуктивной системы и инфраструктура резервного копирования имеют разные бюджеты, и, в ряде случаев, разных администраторов), то такой метод репликации перестанет работать.
Тест восстановления следует проводить в сессиях, допускающих приостановку или даже полный разрыв соединения, с последующим восстановлением. Идеально, чтобы восстановление можно было производить с ноутбука администратора, или с любого компьютера в сети, включая домашний компьютер администратора. Терминальные соединения вполне позволяют этого добиться, а продукт резервного копирования должен корректно отрабатывать этот сценарий. Процесс восстановления может занять много часов, и гибкость в управлении и мониторинге за этим процессом является важным параметром.
В процессе восстановления могут потребоваться дополнительные шаги, которые не могут быть выполнены по каким-то причинам самим продуктом резервного копирования: например, настройка DNS, запуск скрипта базы данных и т.д. При создании заданий резервного копирования администратор вполне может просто забыть про эти шаги из-за «человеческого фактора» (ведь описываемые дополнительные шаги нужны на фазе восстановления системы, а не на фазе создания резервной копии).
Если применяется схема бэкапа с использованием внеофисного хранения резервных копий, то тестирование восстановления должно включать сценарий, когда потребуется запросить копию из внешнего офиса и физически переместить ее в оригинальный офис (например, физически привезти кассету). Помните, что на дорогах бывают пробки, когда будете проверять уложились ли вы в SLA по RTO.
Надо сказать, что итоговое SLA по RTO определяется не только вами, но и SLA производителей оборудования и программного обеспечения, которое задействованы в процессе резервного копирования и восстановления. По этой причине, не забудьте про свой Backup-сервер. Если на нем установлено менее надежное или менее производительное аппаратное или программное обеспечение, чем на серверах продуктивной сети, Backup-сервер может вас подвести в момент восстановления, и вы не сможете выполнить SLA по восстановлению. Например, если в продуктивной сети стоят диски, которые производитель в случае сбоя по премиум-гарантии меняет за 1 сутки, а на Backup-сервере стоит диск с обычной гарантией (ремонт в течение 45 дней), то ваш итоговый SLA по продуктивной сети будет равен 45 дням.
Моделирование угроз в части сбоев продуктивной сети
Крайне полезно промоделировать возможные варианты сбоев продуктивной сети. Модель должна охватывать все сценарии восстановления информации после сбоев. Например, нельзя ограничиться сценарием гибели всего диска, так как при тестировании восстановления вы будете каждый раз задействовать восстановление из полной резервной копии плюс восстановление из цепочки инкрементальных. А что если будет удален всего лишь один файл на диске, причем последняя версия которого находится в последней инкрементальной копии? В этом случае полную копию задействовать не правильно, и нужно взять лишь последнюю инкрементальную и извлечь из нее нужный файл. Такие сценарии тоже нужно регулярно проверять. Примеры угроз, подлежащих моделированию:
- Физический полный сбой диска
- Удаление отдельного полезного файла
- Вирусное поражение файлов
- Сбой контролера домена Active Directory, DNS сервера, VPN сервера, Exchange сервера или другой критической инфраструктуры одновременно со сбоем на продуктивном файл сервере
- Сбой отдельного сервера в основном сайте/офисе и, одновременно, исчезновение связи с сайтом/офисом резервного копирования
- Двойной сбой – сбой продуктивного сервера с последующим выходом из строя сервера резервного копирования, который выполняет восстановление
Подробнее о моделировании угроз можно почитать пост "Модель угроз в защите данных от сбоев".
Как НЕ надо делать тестирование восстановления продуктивной сети
Не следует выполнять тестирование восстановления, используя намеренное уничтожение данных продуктивной сети. Например, руководитель одной из компаний вечером в пятницу стирал содержимое своего жесткого диска своего компьютера и просил IT службу к утру понедельника все восстановить. Причин так НЕ делать несколько:
- Тестирование восстановления может закончиться не удачно, и реальные данные будут безвозвратно потеряны
- Тестируется только один сценарий, предполагающий восстановление из полной резервной копии
- Тестируется только восстановление из одной (последней) точки времени (то есть мы знаем, что по пятницам все работает, но про остальные дни сказать нечего не можем)
- Не нужно говорить, что есть еще и человеческий фактор: сотрудники IT службы будут крайне негативно воспринимать такой сценарий своей работы. Так как никому не нравится исправлять искусственно созданные проблемы
Подводя итог
Нужно регулярно проводить тестирование восстановления данных, а не простое тестирование целостности резервных копий. То есть проверять работоспособность восстановленных систем и наличие в них данных, в соответствии с RPO, а не просто проверять контрольные суммы блоков данных файлов резервных копий. В случае, когда продуктивная сеть находится в виртуальной среде, продукты резервного копирования, созданные специально для виртуальной среды, позволяют сделать процесс проверки данных автоматизированным и прозрачным для администратора, так как они позволяют создавать виртуальные тестовые лаборатории-песочницы, изолированные от продуктивной сети. Пример такой технологии — Veeam SureBackup®
Нужно случайным образом выбирать для проверки разные объекты, сценарии сбоев и временные точки: компьютеры продуктивной сети, разные по времени точки восстановления, моделировать разные по масштабам сбои, требующие восстановление разных типов (из полной копии, из инкрементальной копии, восстановление отдельного файла). В последнем случае нужно случайным образом выбирать файлы для тестирования восстановления, а не восстанавливать все время один и тот же файл.
Ради тестирования восстановления данных не следует подвергать неоправданному риску данные продуктивной сети.
Дополнительные материалы
- SureBackup – автоматическая проверка возможности восстановления данных из резервной копии
- Рекомендации по политике резервного копирования и восстановления после сбоев
- Виртуальная Лаборатория для Hyper-V в составе Veeam Backup & Replication v7
- 5 фундаментальных принципов современной защиты данных от сбоев (на англ. яз.)
- Pixar Animation Studios: Did Pixar accidentally delete Toy Story 2 during production?
- How Pixar’s Toy Story 2 was deleted twice, once by technology and again for its own good
Автор: sysmetic
