Случай в Pixar или еще раз о важности тестирования резервных копий

  • Tutorial
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

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

Ради тестирования восстановления данных не следует подвергать неоправданному риску данные продуктивной сети.

Дополнительные материалы

Veeam Software
137,72
Продукты для резервного копирования информации
Поделиться публикацией

Комментарии 18

    +8
    Первый абзац поражает глубиной безответственности сотрудников и глупостью реализации.
    Я не знаю тонкости записи информации на магнитные ленты, но нельзя просто так взять и не проверить войдет или нет бекап на ленту.
      +3
      Скорее всего когда настраивали систему файлов было гораздо меньше и всё работало.
        +2
        Это само собой, но ведь можно сделать простейшую проверку оставшегося свободного места. Хотя вот это наверно и есть тонкости записи на ленту )
          +24
          «Что б я был такой умный, как моя жена после» © анекдот
          +2
          Почти наверняка так и было. Скрытая опасность автоматизированных систем — они расслабляют. У меня был такой косяк: работала себе спокойно система резервного копирования (на диск, Bacula), всё вроде бы было нормально, бекап в «окно» влезал с запасом, расписание «дед-отец-сын», места было не то чтобы очень много — но хватало. Как вдруг старый «дед» оказался заблокирован (а там был полный, на 700 гигов, бекап), система его удалить не смогла и тупо сделала ещё один файл. Получилось три деда, и перерасход места на носителе — что вскоре вылилось в невозможность впихивания «отца». А не заметил я тупо потому, что привык смотреть на заголовки писем с логами — если BackupOK — то я дальше и не смотрел.
        +1
        А что с Pixar-то в итоге? Восстановили?
          +1
          Да, в ролике об этом говорится.
            0
            Ах ты ж, извините, не подумал, что ролик именно о той ситуации.
          0
          Что меня удивляет в нынешней ситуации — так это некая незаконченность.
          Вот смотрите: есть Гугль, есть Андроид, есть Гугльдрайв. Гугль умеет бэкапить контакты и пароли вайфай. И все. Даже СМСки умирают вместе с телефоном.
          Что мешает сделать последний шаг и добавить регулярный бекап всего телефона в гугльдрайв? Вместо этого в маркете 100500 разной степени кривости приложений, предлагающих этот функционал за деньги.
          Где логика?
            +3
            Может Гугль дает возможность работать сторонним разрабам? Или не хочет связываться с приватностью смс и иных данных?
            Хотя — в iOS бекапится все, и это иногда очень сильно выручает
              +2
              Проблема в том, что андроид без рута не может полноценно бэкапиться и восстанавливаться. Соответственно, гугль не может расчитывать в этом деле на сторонних разработчиков.
              0
              Что мешает сделать последний шаг и добавить регулярный бекап всего телефона в гугльдрайв?


              Зная гугл, это будет ещё один сервис, включенный по умолчанию. И не факт, что с возможностью отключения.
            • НЛО прилетело и опубликовало эту надпись здесь
                +1
                Да, пост изначально был помечен как «tutorial», и поэтому содержит предельно упрощенные примеры. Мы пытаемся писать различный по уровню контент, — например, см. наш предыдущий пост по теме бэкапа и отказоустойчивости сервисов высокой доступности: "Архитектура BigData-инфраструктуры сервиса Pandorama и защита ее данных от сбоев"

                По процитированному примеру — согласен с замечанием о его неясности — у меня оказалось пропущено описание «исходной ситуации». Речь шла о случае, когда в продуктивном сервере установлен один диск, и его отказ влечет необходимость восстановления данных из резервной копии. Backup-сервер — это управляющий сервер продукта резервного копирования. На нем тоже один диск. Речь шла о случае, когда происходит одновременный сбой этих двух дисков — в результате чего продукт резервного копирования не может функционировать и процесс восстановления продуктивной системы будет зависеть от времени восстановления Backup-сервера. Конечно, в реальной системе, скорее всего будет установлен RAID массив (и/или применены другие методы обеспечения отказоустойчивости), и проблема будет носить менее выраженный характер.

                И, в целом, вы очень хорошо сформулировали основную мысль этого примера — я бы только добавил, что еще идея была в том, чтобы показать, что бэкап-инфраструктура должна рассматриваться как часть продуктивной инфраструктуры, так как от нее, в определенных случаях, зависит RTO при восстановлении продуктивной системы.
                • НЛО прилетело и опубликовало эту надпись здесь
                +3
                Кстати, в ролике они немного иначе описывают «спасение» мультфильма — копии оказались у сотрудницы, которая работала из дома по причине недавних родов малыша. Это позволило получить наиболее свежий бэкап. В ролике ничего про то, что несколько месяцев кропотливо сравнивали файлы из разных версий бэкапа!
                • НЛО прилетело и опубликовало эту надпись здесь
                    +4
                    Процесс восстановления в Pixar был подробно описан Oren Jacob в его комментарии к этому же ролику (что приведен выше), на этом ресурсе. См. по ссылке самый верхний комментарий. " I'm the Oren Jacob in the video. Hopefully I can offer some first person color commentary about the video above that might serve to answer the questions here.". Ролик же просто не стали перегружать деталями.

                    В частности, там есть такой момент: "With Galyn's machine now back in the building, we dupe'd that data immediately, then set about the task of trying to verify and validate this tree, which we thought might be about 2 weeks old. We compared Galyn's restoral with a much older one (from 2 months prior) and couldn't determine a clear winner, there were too many inconsistencies. So, instead, we set about the task of assembling what effectively amounted to a new source tree, by hand, one file at a time. The total number of files involved was well into the six figures, but we'll round down to 100,000 for the sake of the rest of this discussion to make the math easier."

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое