Cliffhanger: резервные копии правильные ... здесь ... верно?

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

Но затем, когда вы запрашиваете КОНКРЕТНУЮ резервную копию, в половине случаев их нет:

• Диск заполнен
• Сбой ленты
• Похоже, кто-то отключил задание резервного копирования
• Сетевое соединение было простоем
• Мы заказали этот диск несколько лет назад, но финансы не одобрили заказ на покупку
• Файлы повреждены
• Файл содержит неверную базу данных
• Только резервные копии журнала транзакций (бесполезные без полной)

Несколько недель назад произошла катастрофа, когда один из серверов потерял слишком много рейдовых дисков. К счастью, один диск был достаточно любезен, чтобы скопировать данные, если вы пытались много раз.

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

Вы всегда должны исправить эти вещи сверху.

Поддерживается ли и понимается ли текущая стратегия резервного копирования руководством? Если нет, то это бесполезно.

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

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

С чего начать? Это катастрофа, ожидающая случиться. Основная функция Sysadmins - обеспечить резервное копирование и восстановление данных. Все остальное вторично. Нет, если нет, но есть.

Вот несколько вещей, которые вы можете сделать:

1. Отслеживание KPI для восстановления. Должна быть возможность создать отчет, показывающий, сколько запросов на восстановление было успешным. Все, что меньше 100%, должно быть тщательно исследовано. Менеджмент любит отчеты и это неопровержимые доказательства.

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

3. Поговорите с менеджером системных администраторов и озвучьте ваши проблемы. Вооружитесь доказательством того, что восстановление не работает. Если нет радости, иди выше.

Серьезно - поднимите шум. Такие вещи могут разрушить компанию.

Предложить (как минимум) ежегодные тесты аварийного восстановления. Работа, необходимая для успешного выполнения теста, должна выявить недостатки.

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

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

Затем откиньтесь на спинку кресла и наблюдайте за улучшением ИТ - как только руководство поймет, что данные компании находятся в опасной близости от их постоянной потери, возникнут искры (от ракет, которые будут стратегически размещены в указанных администраторах)

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

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

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

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

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

Я отвечаю за около 200 серверов, распределенных по северо-западу Великобритании, и это, очевидно, слишком много, чтобы проверить вручную.

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

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

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

Некоторые из серверов используют Backup Exec, некоторые NTBackup, а некоторые просто копируют свои файлы на другой сервер по сети. Неважно, какой тип резервного копирования делают серверы, так как легко настроить мой VBScript для проверки ошибок. Мой сценарий на самом деле довольно простой, он просто открывает отчет о резервном копировании в виде текстового файла и находит такие фразы, как «не удалось смонтировать», «лента заполнена», «ошибка CRC» и т. Д. И т. Д. Я уверен, что профессиональный программист сделает это. гладкая работа. Однако все это просто и надежно, и оно проактивно в том смысле, что я вижу отчет об ошибке резервного копирования, хочу я этого или нет, и я не смогу заметить ошибку, только если сознательно решил проигнорировать отчет.

JR

PS 99% сбоев резервного копирования связаны с тем, что пользователи забыли сменить ленту резервного копирования. Разве вы просто не любите хулиганов :-)

Резервная копия, которая не проверена, не является резервной копией вообще.