В SF общеизвестно, что ваши резервные копии настолько полезны, насколько вы способны их восстановить. Итак, вы пересмотрели и задокументировали свой график резервного копирования. Вы проверяете журналы и / или получаете уведомления о результатах для каждого задания резервного копирования.
Теперь вы хотите быть уверены, что вас никогда не поймают со спущенными штанами LTO, и вы будете время от времени делать точечное восстановление. Я понимаю, что это будет СУЩЕСТВЕННО варьироваться в зависимости от размера и типов данных, но я хотел бы узнать, как люди справляются с этим. Или это в первую очередь просто вопрос обучения - убедиться, что у вас (или ваших людей) есть опыт в каждом необходимом восстановлении?
У нас много вопросов о том, как восстановить тот или иной тип технологии. Меня больше интересует, как вы убедитесь, что быстрое выздоровление гарантировано.
В зависимости от среды это может быть сложно.
В среде с выделенным сервером было бы наиболее полезно иметь резервную машину, оборудование которой идентично основному. Переведите резервную копию в автономный режим, а затем запустите на ней восстановление, пока она изолирована. Убедившись, что он восстановлен должным образом, убедитесь, что весь процесс должным образом задокументирован. Если вы действительно серьезно настроены, попросите кого-нибудь попробовать следовать вашим инструкциям без посторонней помощи.
Кислотное испытание заключается в замене машины с резервным копированием на основную. Конечно, это не сработает, если вы работаете с данными в реальном времени, которые постоянно меняются. Это также рискованно и не совсем необходимо, но гарантирует, что вы сможете выздороветь с помощью ваших (новых) установленных процедур.
Поскольку у меня нет резервной машины, и я могу позволить себе отключать свой сервер на несколько часов, я делаю следующее:
Я не буду пытаться комментировать среды виртуальных машин. Я знаю о них лишь достаточно, чтобы быть опасным.
Обязательно просматривайте и тестируйте свою систему резервного копирования и восстановления всякий раз, когда вы вносите существенные изменения в свой сервер. Не было бы проблем, стряхнуть пыль с папки 5-летней давности с инструкциями по восстановлению, только чтобы понять:
В заключение, главное - тщательно документировать весь процесс. Запишите это так, чтобы новый сотрудник, который только что начал свою работу на прошлой неделе после школы, мог успешно возобновить работу без посторонней помощи. Тогда проверьте это.
Удачи!
Возможно, я суеверен, но мне очень не нравится программное обеспечение для управляемого резервного копирования, такое как Backup Exec. Для этого требуется собственная база данных, резервная копия которой также требуется, и собственное программное обеспечение, которое также необходимо где-то установить для восстановления. Поэтому, если вы потеряете сервер резервного копирования, вы либо восстанавливаете его из образа, либо перестраиваете, а затем восстанавливаете базу данных, прежде чем сможете восстановить что-либо еще.
Я чувствую себя намного безопаснее со сценарием данные + изображение. Полный образ ОС легко сделать в Linux и OS X. В Windows я обнаружил, что Acronis Universal Restore отлично справляется с отключением полного образа Windows, что я делаю ежеквартально. Затем я восстанавливаю этот образ на другой сервер в автономном режиме. Затем нужно восстановить файлы данных, что не требует Backup Exec, если вы можете запустить что-то вроде rdiff-backup на внешний сервер хранения.
Зная, что у меня есть хорошие изображения и легкодоступные файлы, не спрятанные в контейнере и управляемые базой данных, а также тестирование процесса восстановления на запасном сервере, который у меня есть специально для этой цели, я чувствую себя довольно уверенно в этом процессе.