Лучшие практики для проверки резервных копий?

Это обычная ситуация, когда администратор создает систему для автоматического резервного копирования и забывает ее. Только после сбоя системы администратор замечает, что система резервного копирования была повреждена раньше или резервные копии не могут быть восстановлены из-за какой-либо ошибки, и у него нет текущей резервной копии для восстановления из ... Так, каковы наилучшие методы, чтобы избежать таких ситуаций ??

Проводите пожарные учения ... каждые пару месяцев было бы неплохо сказать, что система XYZ вышла из строя ... затем на самом деле пройти через все действия по ее подключению к новой ВМ и т. Д. И т. Д. Это делает вещи честными и помогает вам поймать ошибки.

режим мыльницы: ВКЛ

Я бы сказал, что это так просто, что резервные копии, которые не проверяются регулярно, бесполезны.

Моя предыдущая работа заключалась в том, что каждая система (производство, тестирование, мониторинг разработки и т. Д.) Должна тестироваться каждые 6 месяцев.

Это была также работа самого младшего администратора, так что документация была актуальной. Младший определяется тем, сколько работы он / она проделал в конкретной системе, иногда (довольно часто на самом деле) это делал «менеджер группы»

У нас было специальное оборудование, предназначенное для этого (один процессор Intel и один IBM / AIX), которое не требовало больших возможностей для всего, кроме дискового пространства, поскольку нам не нужно было запускать что-либо реальное на восстановленном хосте.

Первые несколько раундов проделали огромную работу, но это привело к упорядочению процесса восстановления, который является важной частью резервного копирования.

Поскольку вы, похоже, имеете в виду тот факт, что администратор не замечает, что задание резервного копирования «ломается», и не настолько, чтобы работающее резервное копирование работало некорректно, я бы предложил построить какие-то сценарии мониторинга вокруг резервных копий.

При создании собственного решения для резервного копирования я бы сделал что-то вроде этого:

• Создайте скрипт для резервного копирования ваших данных.
• Выполните тестовое восстановление, чтобы убедиться, что скрипт работает правильно.
• В сценарии или с помощью других средств реализуйте способ отслеживания состояния резервных копий (успех, сбой, выполнено, не выполнено).
• Отслеживайте этот статус отслеживания (электронная почта, база данных, что-то)

Как только все это будет сделано, у вас все будет хорошо. Еще одна вещь, которую нужно сделать, это регулярно выполнять тестовые восстановления. Если у вас есть дополнительное оборудование, чтобы пожертвовать на причину, которая есть.

Там, где я работаю, у нас есть теплый сайт, раз в месяц мы случайным образом выбираем систему или базу данных и заходим на наш теплый сайт и выполняем тестовое восстановление на голом металле, чтобы обеспечить возможность восстановления наших данных.

Честно говоря, если ваши данные очень важны для вас, в ваших интересах было бы инвестировать в какое-то программное обеспечение для управления вашими резервными копиями. Для этого существуют сотни продуктов, от дешевых и простых до корпоративного класса.

Если вы полагаетесь на набор рукописных сценариев, выполняемых в crontab для резервных копий ваших компаний, рано или поздно вы, вероятно, сгорели.

У нас есть 60% -ные «эталонные» версии наших «производственных» систем, мы используем их для окончательного тестирования изменений, мы восстанавливаем «производственные» резервные копии в этих системах - это проверяет резервное копирование, а также гарантирует, что обе среды находятся в шаге друг с другом ,

Один из подходов заключается в том, чтобы задавать периодическое задание «восстановление», например, такое, которое извлекает определенный текстовый файл из самой последней резервной копии и отправляет вам по электронной почте его содержимое. Если это возможно, это должно быть - по крайней мере иногда - с использованием другого поля, отличного от того, которое создавало или резервировало данные, просто для того, чтобы убедиться, что оно будет работать, если вам нужно это сделать. Преимущество состоит в том, что вы можете быть уверены, что ваши механизмы шифрования / дешифрования, сжатия и хранения данных работают.

Это немного сложнее для специализированных резервных копий, таких как электронная почта и серверы баз данных, хотя выполнение некоторого мелкомасштабного восстановления из резервной копии почтового ящика небольшого размера БД или уровня кирпича и проверка содержимого, безусловно, возможны, только чуть более сложный процесс.

Этот подход также не должен заменять периодическое полное восстановление, чтобы гарантировать возможность восстановления данных в случае чрезвычайной ситуации - он просто позволяет вам быть немного более уверенным в целостности своей ежедневной работы по резервному копированию.

Когда я выполняю тестовое восстановление, я не чувствую себя комфортно в момент «это выглядит хорошо, файлы восстанавливаются, кажется, что файл отсутствует, даже если размеры совпадают», или в момент «это выглядит хорошо, я запустил свое приложение. .. не вылетает, отображает некоторые приличные данные ".

Я хочу восстановить сервер / кластер с нуля, а затем фактически использовать его для производства . Не на минуту, не на час, а навсегда . Если вы утверждаете, что восстановление прошло успешно, то нет абсолютно никаких причин не запускать производство. Это не какая-то «грязная» система, о которой стоит забыть. Это система, с которой вы столкнетесь после настоящей катастрофы. Так что, если он проходит «красиво», живите с этим. Подкрепите это следующей ночью. Забудь о оригинале. Вы , вероятно , будете обнаружить некоторые глюки , используя этот подход, и вы будете вынуждены , чтобы исправить все из них . Следующее восстановление той же системы имеет хороший шанс на 100% успешно.

Это включает в себя ваше программное обеспечение для резервного копирования и сервер. Да, вам нужно восстановить их тоже.

Нет бюджета, чтобы купить выделенное оборудование для восстановления?

• Обратите внимание, что вам абсолютно необходим бюджет. В каждом случае напоминайте лицам, принимающим решения, что действительного, на протяжении всего испытания на восстановление еще не было. (И да, собрать доказательства, чтобы прикрыть свою задницу. Трудный мир.)
• В большинстве организаций иногда возникает необходимость в переносе одной системы на другое оборудование, поэтому используйте эту возможность. Всегда выбирайте метод «восстановление из резервной копии» для миграции, делая вид, что вы только что потеряли исходное оборудование. Да, это означает больше простоев, извините за это. По крайней мере, вы будете уверены, что ваша резервная копия полезна.
• Нет миграции? Возможно, вы можете одолжить какое-то оборудование на две недели и выполнить два теста восстановления (восстановить на заемное оборудование, подождать более недели, восстановить с заимствованного на исходное, жить с ним). Обычно, если для какой-то новой системы приобретается новое оборудование, и вы все правильно расставляете, вы можете легко одолжить его, предложив провести его полное тестирование в течение двух недель. Если новое оборудование не на 100% идентично старому, это сделает ваш тест еще лучше. Как вы знаете, если вы получите идентичное оборудование в случае реальной катастрофы?
• Любая новая система внедряется вами в данный момент? Можете ли вы проверить восстановление прямо сейчас? Не используйте дополнительное оборудование, просто перезапишите новую систему, поскольку у вас есть новые знания о том, как ее быстро внедрить. Это работает, если у него еще нет значимых данных. Опять же, перейдите к производству на восстановленной версии, а не на недавно переустановленной версии.

1. Пожарные учения.
2. Политика проверки всех резервных копий каждые 6 месяцев - очень хорошая идея
3. Когда дело доходит до тестирования, вам нужно посмотреть на каждое приложение или систему, для которой вы создаете резервную копию. В идеале, то, что составляет «успешную» или «восстанавливаемую» резервную копию, должно быть указано в описании службы или в SOP (эксплуатационная документация) для вашей резервной копии, наряду с другими деталями, такими как время хранения, bladibla.

Вы, вероятно, обнаружите, что некоторые типы резервных копий можно легко протестировать с помощью сценариев (например, баз данных), в то время как другим требуется ввод вручную (восстановление Active Directory). Автоматизируйте как можно больше этого, убедитесь, что какая-то отчетность существует, и убедитесь, что «кто-то» также выполняет ручные тесты с регулярными интервалами. Изолированная среда (уменьшенная копия prod) облегчит выполнение тестирования восстановления.

Хотя мы не тестируем резервные копии, у нас есть компонент централизованной проверки резервных копий и отчетности в системе, которую мы разработали BackupRadar.com. Не стесняйтесь проверить это, чтобы видеть, помогает ли это с тем компонентом. Он прикрепляет копию писем об успехе / неудаче к политике резервного копирования, а также прикрепляет снимки экрана, если ваше ПО для резервного копирования способно их отправлять.

Спасибо Патрик

Убедитесь, что операции резервного копирования записаны, затем напишите что-нибудь (конечно, на perl), которое анализирует эти журналы в поисках сбоев, перерабатывает их и отправляет как ежедневное электронное письмо.