1998, студия Пиксар.
Производство «Истории игрушек 2» идет полным ходом.
В процессе задействовано более 150 человек.
Размер исходных материалов анимации — 10 ГБ (по тем временам это было очень много).
Каждый день на ленту создается полная резервная копия.
Кассета имеет размер.
4Гб (данные при записи на ленту сжимаются, но, конечно, не до такой степени).
Каждый раз выдается ошибка, но никто этого не замечает, потому что лог-файл находится на той же кассете и записывается в самом конце задания резервного копирования, а поскольку на кассете больше нет места, он имеет размер из 0 байт. Каждую неделю проводится тест восстановления данных, в ходе которого проверяются первые 2000 кадров анимации.
И, конечно же, тест каждый раз проходит успешно.
…И вдруг настал день, когда кто-то на сервере (по ошибке или намеренно) запустил на сервере команду «/bin/rm -r -f *» (или подобную), которая удалила 90% из 100 000 исходных файлов анимации.
.
Один из сотрудников компании, Ларри Катлер, как раз просматривал файлы в папке с исходниками анимации, намереваясь что-то подправить в модели шляпы персонажа Вуди, как вдруг заметил, что в папке осталось всего 40 файлов.
.
потом 4. и через секунду они были там, никого не осталось вообще.
Ларри позвонил в IT и сказал, что " произошла огромная потеря данных ", Ну и что " для восстановления потребуется полная резервная копия.
«Которого, как выяснилось чуть позже, у них не было, несмотря на ежедневное резервное копирование.
Что произошло дальше? «Полный бэкап» по понятным причинам оказался не совсем полным: оказалось, что за последнее время с ленты пропало до 30 000 файлов.
Задача усложнялась тем, что в папке постоянно создавались, удалялись и изменялись файлы, поэтому резервные копии, созданные в разное время, часто содержали разные наборы файлов, а это означало, что их приходилось сравнивать вручную, чтобы определить, что было удалено по плану.
и это исчезло в результате сбоя.
На анализ всех недостающих файлов, уцелевшие версии которых за последние два месяца были разбросаны по инкрементальным и полным резервным копиям, ушло много дней кропотливой ручной работы.
Хотелось бы проанализировать, какие действия необходимо предпринять, чтобы минимизировать проблемы, подобные описанным выше.
Прежде всего, следует различать проверка целостности резервной копии (медиа-тестирование) и тестируем восстановление из резервной копии (тестирование данных).
В первом случае вы проверяете целостность копии только по контрольным суммам блоков данных.
Во втором вы проводите тестирование, отражающее тот или иной смоделированный сценарий индивидуального сбоя или «полномасштабной катастрофы» вашей продуктивной сети.
Рекомендуется регулярно тестировать восстановление из резервных копий.
По мере увеличения размера производственной системы результаты теста восстановления могут измениться.
Например, неделю назад все восстановилось правильно, а потом «вдруг» резервные копии уже не помещались в хранилище, и сообщение об ошибке не было замечено.
Или вы установили новое сетевое приложение, но местоположение его файла не было включено в резервную копию.
Либо систему можно успешно реплицировать методом прямого сопоставления блоков на диск заводской емкости 2 ТБ.
«Прямое сопоставление блоков» означает, что блок данных на исходном диске напрямую сопоставляется (без использования промежуточной таблицы пересылки) с блоком данных на целевом диске.
Но, если в какой-то момент система будет обновлена и емкость исходного диска превысит 2 ТБ, а резервный диск не будет обновлен (это часто происходит из-за того, что инфраструктура производственной системы и инфраструктура резервного копирования имеют разные бюджеты, и, в некоторых случаях, разные администраторы), то этот метод репликации уже не будет работать.
Тест восстановления следует проводить в сеансах, позволяющих приостановить или даже полностью отключить соединение с последующим восстановлением.
В идеале восстановление можно выполнить с ноутбука администратора или с любого компьютера в сети, включая домашний компьютер администратора.
Терминальные соединения позволяют добиться этого, и продукт резервного копирования должен правильно обработать этот сценарий.
Процесс восстановления может занять много часов, поэтому важна гибкость в управлении и мониторинге этого процесса.
Процесс восстановления может потребовать дополнительных действий, которые по каким-либо причинам не могут быть выполнены самим продуктом резервного копирования: например, настройка DNS, запуск сценария базы данных и т. д. При создании заданий резервного копирования администратор вполне может просто забыть об этих шагах из-за «человеческий фактор» (ведь описанные дополнительные действия нужны на этапе восстановления системы, а не на этапе резервного копирования).
Если используется схема резервного копирования с использованием внешнего хранилища резервных копий, то тестирование восстановления должно включать сценарий, в котором необходимо запросить копию из внешнего офиса и физически переместить ее в исходный офис (например, физически принести ленту ).
Помните, что на дорогах бывают пробки, когда вы проверяете соблюдение SLA по РТО .
Должен сказать, что окончательный SLA для РТО определяется не только вами, но и SLA производителей оборудования и программного обеспечения, участвующих в процессе резервного копирования и восстановления.
По этой причине не забывайте о своем резервном сервере.
Если он имеет менее надежное или менее функциональное оборудование или программное обеспечение, чем серверы в продуктивной сети, сервер резервного копирования может выйти из строя во время восстановления, и вы не сможете выполнить соглашение об уровне обслуживания для восстановления.
Например, если в производственной сети есть диски, которые производитель заменяет в течение 1 дня в случае неисправности по премиальной гарантии, а на Резервном сервере имеется диск с обычной гарантией (ремонт в течение 45 дней), то ваш окончательный SLA для производственной сети будет равен 45 дням.
Моделирование угроз в отношении сбоев производственной сети
Чрезвычайно полезно моделировать возможные сценарии отказа продуктивной сети.Модель должна охватывать все сценарии восстановления информации после сбоев.
Например, вы не можете ограничиться сценарием гибели всего диска, так как при тестировании восстановления вы каждый раз будете использовать восстановление из полной резервной копии плюс восстановление из цепочки инкрементных.
Что если будет удален всего один файл на диске, последняя версия которого находится в последней инкрементальной копии? В этом случае использовать полную копию не корректно, и вам достаточно взять последнюю инкрементальную и извлечь из нее нужный файл.
Подобные сценарии также необходимо регулярно проверять.
Примеры угроз для моделирования:
- Физический полный сбой диска
- Удаление отдельного полезного файла
- Заражение файлов вирусом
- Выход из строя контроллера домена Active Directory, DNS-сервера, VPN-сервера, сервера Exchange или другой критической инфраструктуры одновременно с сбоем продуктивного файлового сервера.
- Выход из строя отдельного сервера на основном сайте/офисе и одновременно потеря связи с резервным сайтом/офисом
- Двойной сбой — сбой рабочего сервера, за которым следует сбой резервного сервера, выполняющего восстановление.
Как НЕ тестировать восстановление продуктивной сети
Тестирование восстановления не должно проводиться путем преднамеренного уничтожения данных производственной сети.Например, руководитель одной из компаний в пятницу вечером стер содержимое жесткого диска своего компьютера и попросил ИТ-службу все восстановить к утру понедельника.
Есть несколько причин НЕ делать этого:
- Тестирование восстановления может завершиться неудачно, и реальные данные будут безвозвратно потеряны.
- Тестируется только один сценарий, предполагающий восстановление из полной резервной копии.
- Тестируется только восстановление с одной (последней) точки времени (то есть мы знаем, что по пятницам всё работает, но про другие дни ничего сказать не можем)
- Разумеется, существует и человеческий фактор: сотрудники ИТ-службы воспримут такой сценарий для своей работы крайне негативно.
Потому что никто не любит решать рукотворные проблемы
Подведение итогов
Тестирование восстановления данных следует проводить регулярно, а не просто проверять целостность резервных копий.То есть проверить работоспособность восстанавливаемых систем и наличие в них данных в соответствии с РПО а не просто проверять контрольные суммы блоков данных файлов резервных копий.
Когда производственная сеть расположена в виртуальной среде, продукты резервного копирования, разработанные специально для виртуальной среды, могут сделать процесс проверки данных автоматизированным и прозрачным для администратора, поскольку они позволяют создавать виртуальные тестовые лаборатории-песочницы, изолированные от производственной сети.
Примером такой технологии является Veeam SureBackup Необходимо случайным образом выбирать разные объекты, сценарии сбоев и моменты времени для тестирования: компьютеры в продуктивной сети, точки восстановления разного времени, моделировать сбои разных масштабов, требующие восстановления разных типов (из полной копии, из инкрементальной копии).
, восстановление отдельного файла).
В последнем случае вам нужно случайным образом выбирать файлы для проверки восстановления, а не постоянно восстанавливать один и тот же файл.
Тестирование восстановления данных не должно подвергать данные производственной сети ненужному риску.
Дополнительные материалы
- SureBackup — автоматически проверяет возможность восстановления данных из резервной копии
- Рекомендации по политике резервного копирования и аварийного восстановления
- Виртуальная лаборатория Hyper-V в составе Veeam Backup & Replication v7
- 5 фундаментальных принципов современной защиты данных от сбоев (по-английски)
- Pixar Animation Studios: Pixar случайно удалила «Историю игрушек 2» во время производства?
- Как «Историю игрушек 2» студии Pixar дважды удалили: один раз по техническим причинам, а другой ради ее же блага
-
Разработчик, Не Торопитесь — Будьте Худшим
19 Oct, 24 -
Редактор Фрагментов Кода Для Visual Studio
19 Oct, 24 -
Мозилла Фаерфокс 2.0.0.3
19 Oct, 24 -
Вышла Книга О Джанго
19 Oct, 24
