У нас есть сеть для малого бизнеса с несколькими серверами Windows и Backup Exec + ленточной библиотекой LTO4 для их резервного копирования. Мы используем годовой, ежемесячный и еженедельный ротации с удалением лент. Следует также отметить, что мы используем штрих-коды LTO.
Мой вопрос на самом деле таков - какие документы / электронные таблицы / базы данных / и т. Д. Вы используете при ротации резервного копирования для достижения следующих целей:
a) Обеспечьте наличие письменного отчета об ответственности, показывающего, что инженеры проверили журналы резервного копирования, чтобы убедиться, что задания успешно завершаются, лента находится в хорошем состоянии и т. д. (помимо всего прочего, это кажется хорошим способом стимулировать процесс к должны соблюдаться, если люди должны подписать свое имя, чтобы сказать, что они это сделали).
б) Возможность отслеживать, где в настоящее время хранятся все ленты (Backup Exec помогает в этом, но отдельная запись кажется разумной). Также было бы хорошо, если бы эта запись каким-то образом хранилась за пределами объекта, чтобы она была доступна в случае бедствия, такого как пожар в офисе.
c) В случае аварийного восстановления, это не просто ленты, хранящиеся за пределами объекта, но письменная запись, объясняющая, какому заданию соответствуют ленты, с записью, показывающей, что задание было успешно завершено, и т. д.
г) Все остальное, что важно
Короче, контрольный след. Контрольный журнал разработан таким образом, чтобы обеспечить устойчивость к чрезвычайным ситуациям, таким как пожары в офисе.
Люди склонны внедрять собственные решения или есть готовые решения? Вы склонны хранить все на бумаге или у вас есть какой-то электронный метод? Вы ведете какие-либо документы с удаленными кассетами?
Я должен сказать, что у нас уже есть базовая система, но мне интересно посмотреть, что составляет хорошую систему контрольного журнала, в надежде, что я смогу улучшить нашу.
Большое спасибо!
Backup Exec имеет функцию, называемую «хранилище», для отслеживания лент, отправленных за пределы площадки.
а) больше похоже на бюрократическое занятие галочкой.
б) у вас есть две или три записи о том, где находятся ленты: отчеты вашего внешнего поставщика хранилища; Backup Exec / библиотека; и, возможно, ваш собственный список / электронная таблица / база данных.
Одна задача после каждой ротации ленты должна заключаться в их согласовании. Это должно быть сделано с помощью компьютера: введите все записи в файлы (в каком-либо общем формате) и попросите компьютер сравнить их. Наклеивание идентификаторов лент на листе бумаги слишком чревато ошибками.
в) кажется бессмысленным. В случае аварийного восстановления вам необходимо иметь возможность быстро воссоздать вашу резервную копию, поэтому вам потребуются подробные (проверенные и отрепетированные) инструкции для этого и каталогизирующие резервные копии (по крайней мере, ежедневно) на ленте и диске.
Убедитесь, что существует надлежащая (и доступная) запись о том, кто имеет право отзывать ленты из внешнего хранилища. Что будет, если они все в отпуске, когда понадобится?
(а) важен, но не следует оставлять его как проблему процесса для людей. Проверка того, что все это происходит, с соответствующей периодичностью, должна быть одной из функций вашей системы мониторинга.
(б) - это работа программы резервного копирования. Вспомните принцип «одна данность, одно место»; Если ваше программное обеспечение резервного копирования сообщает, что лента находится в одном месте, а другой внутренний процесс сообщает, что лента находится в другом, кому вы поверите? Если ваши внутренние / внешние запросы генерируются автоматически (как и должно быть), полезно сохранить (мягкие) их копии; их всегда можно использовать в качестве аварийной резервной проверки памяти программного обеспечения резервного копирования.
(c) также является задачей программного обеспечения резервного копирования. Любой хороший программный пакет должен иметь встроенную концепцию «восстановления с нуля», которая должна включать восстановление с нуля самого сервера резервного копирования. Моя любимая программа для резервного копирования, bacula, подробно описывает это в их документации, который предполагает, что все было потеряно, кроме стопки лент с удаленными резервными копиями, и что вы приобрели оборудование для замены. В нем говорится, какие инструменты вы бы использовали для индексации лент, как найти самую последнюю резервную копию каталога, как восстановить ее в новый пустой экземпляр bacula и как вы будете восстанавливать клиентов оттуда.
Убедитесь, что ваше программное обеспечение резервного копирования также документирует это. Убедитесь, что процедура работает. Сохраняйте записи об этих тестах.
Что касается пункта (d), я думаю, вы уже рассмотрели большинство важных моментов. Я еще раз повторю, что вам следует часто проверять свои восстановления; не раз в полгода, а минимум раз в месяц. Выберите случайного сотрудника, спросите его, какой файл они не хотели бы потерять; проверьте, что это можно восстановить к их удовлетворению. Спросите случайного ИТ-специалиста, какой сервер он больше всего ненавидит терять; восстановите его в другой ящик и попросите его проверить его работоспособность. Проверяйте свои процедуры DR каждые шесть-двенадцать месяцев в полном объеме. Да, это все стоит; много времени, а также плата за обратный звонок за пределами офиса. Но непроверенные резервные копии и процедуры могут оказаться бесполезными, и, конечно же, на него нельзя положиться.