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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У вас нет бюджета на покупку специального оборудования для восстановления?

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

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

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

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

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

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