В моей работе резервные копии имеют на удивление низкий приоритет. Стратегия резервного копирования была реализована некоторое время назад, и с тех пор предполагается, что с резервными копиями все в порядке. Если вы спросите системных администраторов, они скажут, что все зарезервировано.
Но затем, когда вы запрашиваете КОНКРЕТНУЮ резервную копию, в половине случаев их там нет:
Несколько недель назад катастрофа была очень близка к тому, что один из серверов потерял слишком много RAID-дисков. К счастью, одного диска было достаточно, чтобы скопировать данные, если вы попытаетесь это сделать много раз.
Но даже после этой катастрофы я не могу убедить системных администраторов исправить ситуацию. Так что мне интересно, какие советы, как открыть людям глаза? Мне кажется, мы идем по краю обрыва.
Вы всегда должны исправлять эти вещи сверху.
Поддерживается ли и понимается ли текущая стратегия резервного копирования руководством? Если нет, то бесполезно.
Исполнительному руководству необходимо знать о проблемах и о том, какие риски связаны с этим (потеря финансовых данных, которые вам необходимо предоставить на законных основаниях, чтобы выжить, или данных о клиентах, на сбор которых потребовались годы?), И взвесить это при принятии решения о действиях или принятии решения. позволять кому-то (например, вам) действовать.
Если вы не можете добраться до руководства, попробуйте бизнес-контролеры или другие финансовые должности, где поиск данных и их целостность имеют большое значение для отчетов компании. Они, в свою очередь, при необходимости могут «запустить бурю» ...
С чего начать? Это катастрофа ждет своего часа. Основная задача системного администратора - обеспечить резервное копирование и восстановление данных. Все остальное вторично. Нет, если нет, но.
Вот несколько вещей, которые вы можете сделать:
Отслеживайте KPI для восстановлений. Должна быть возможность составить отчет, показывающий, сколько запросов на восстановление было успешным. Все, что меньше 100%, следует тщательно исследовать. Менеджмент любит отчеты, и это неопровержимое доказательство.
Должны быть задокументированы процедуры для всех операций резервного копирования и восстановления, включая все системы и их стратегию резервного копирования, ротацию лент, расписания, пути эскалации, тестовое восстановление и т. Д. Попросите их увидеть.
Поговорите с менеджером системных администраторов и выскажите свои опасения. Вооружитесь доказательством того, что восстановление не работает. Если нет радости иди выше.
Серьезно - поднимите шум. Подобные вещи могут разрушить компанию.
Предлагайте (как минимум) ежегодные тесты аварийного восстановления. Работа, необходимая для успешного выполнения теста, должна выявить недостатки.
Там, где я работаю, у нас есть действительно хороший ИТ-отдел, каждый год они собираются из каждого офиса по всей Европе и проводят «праздник восстановления» на арендованных серверах в центре обработки данных, эффективно моделируя, что произойдет, если однажды сотрудники придут на работу и найдут офис сгорел ночью.
Вовлеките в это большого босса, напомните ему, что если случится катастрофа, в этом году у него не будет бонуса (или того хуже!), Поэтому, возможно, было бы разумно организовать подобное мероприятие по восстановлению после аварии. Это не займет много времени и не потребует больших затрат - администраторов отправляют со своими удаленными резервными лентами и просят предоставить им идентичную офисную среду.
Затем расслабьтесь и наблюдайте, как ИТ становится лучше - как только руководство поймет, что данные компании находятся в опасной близости от безвозвратной потери, полетят искры (от ракет, которые будут стратегически размещены в указанных администраторах)
Легко обвинить админов, однако Оскар прав: эти вещи управляются сверху. Если руководство не будет тратить деньги на создание резервных копий в приоритете, то системным администраторам обычно не везет, и они делают все возможное, используя имеющиеся у них ресурсы.
Ключевым моментом, если вы один из тех неудачливых администраторов - а я был в этой лодке для некоторых взаимодействий с клиентами - является то, что вы убедитесь, что руководство регулярно информируется и подтверждается документально, что это риск для бизнеса.
Моя стратегия - постоянно ломать голову над проблемами. Если вы сделаете это, иногда проблемы будут решены, но в основном это так, что тот, кому я сообщаю, не может спрятаться за отговоркой «Меня никогда не информировали». Как консультант я обычно могу пойти лучше. Я могу заставить своих начальников проинформировать более старшее руководство, чем я, о существовании уязвимости. Это распространяет вину вокруг или, по крайней мере, фокусирует ее на более высоком уровне, чем я.
В то же время вы должны быть изобретательны и упорно трудиться, чтобы свести к минимуму риски с любыми ресурсами клиент может предоставить.
Хотя в некоторых случаях администраторы могут быть виноваты, руководство всегда несет ответственность: либо за знание риска и недостаточные меры для его снижения, либо за найм людей, которые не предупреждают их об этих рисках.
Я отвечаю за около 200 серверов, расположенных на северо-западе Великобритании, и это, очевидно, слишком много, чтобы проверять вручную.
Я настраиваю резервное копирование так, чтобы по завершении он запускал сценарий (VBScript), который просматривает журнал резервного копирования, определяет, сработало ли резервное копирование или нет, и записывает запись в центральную базу данных с результатом резервного копирования. Затем в головном офисе я запускаю сценарий, который запрашивает эту базу данных и представляет мне список сайтов, на которых либо резервная копия сообщила об ошибке, либо не было отчета с сайта.
В конечном итоге, когда я сажусь за свой стол, у меня есть список всех сайтов, на которых мне нужно проверить резервную копию.
Суть всего в том, что по умолчанию предполагается, что резервное копирование не удалось, и резервное копирование считается работающим только в том случае, если мой VBScript не обнаружил ошибок. и написал этот вывод я в свою базу данных. Это гарантирует, что сбои резервного копирования не останутся незамеченными.
Некоторые из серверов используют Backup Exec, некоторые NTBackup, а некоторые просто копируют свои файлы на другой сервер по сети. Неважно, какой тип резервного копирования делают серверы, так как мой VBScript легко настроить для проверки на наличие ошибок. Мой сценарий на самом деле довольно простой, он просто открывает отчет о резервном копировании в виде текстового файла и greps для таких фраз, как «не удалось смонтировать», «переполнена лента», «ошибка CRC» и т. Д. Я уверен, что профессиональный программист сделает шикарная работа. Однако все это просто и надежно, и оно проактивно в том смысле, что я вижу отчет об отказе резервного копирования, хочу я или нет, и я не заметил бы ошибки, только если бы я сознательно решил проигнорировать отчет.
JR
PS 99% сбоев резервного копирования происходят из-за того, что пользователи забыли сменить резервную ленту. Разве вы не любите лузеры :-)
Резервная копия, которая не протестирована, не является резервной копией вообще.