Содержание
  Введение
Предварительное планирование
Ежедневный обзор логов процесса резервного копирования
Защита базы данных резервного копирования или каталога
Ежедневное определение временного окна резервного копирования
Локализация и сохранение "внешних" систем и томов
Максимально возможная централизация и автоматизация резервного копирования
Создание и поддержка открытых отчетов, отчетов об открытых проблемах
Резервное копирование должно быть включено в процесс контроля изменений системы
Консультации с вендорами
Резервное копирование
Разные данные - разные подходы к резервному копированию
Операционная система
Прикладное программное обеспечение
Программы для резервного копирования: купить или разработать
Типы резервного копирования
Полные копии
Добавочные копии
Разностные копии
Резервный носитель
Лента
Диск
Сеть
Хранение резервных копий
Вопросы восстановления
Восстановление на "голом" компьютере
Проверка копий

Введение

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

Предварительное планирование

Резервное копирование является стратегическим компонентом защиты данных (существует также зеркалирование, снэпшоты и репликация данных). Но важнейшим, фундаментальным элементом всей стратегии хранения данных должно стать планирование резервного копирования.
Все компоненты инфраструктуры резервного копирования должны учитываться в процессе планирования, а все приложения, серверы и тенденции увеличения емкости первичных хранилищ данных не должны оставаться без внимания. Очень часто изменения в среде не принимаются во внимание. Это может вызвать сбои и оказать пагубное воздействие на работу системы резервного копирования.
Кроме того, правильное планирование позволяет составить более полное представление о потребностях и особенностях работы приложений с точки зрения защиты данных. Приложения баз данных, где присутствуют разделенные "зеркала" и приложения, работающие в файловой среде, в которой нет дополнительной защиты данных, требуют разных стратегий и подходов к резервному копированию. Аналогично, большое корпоративное приложение, развернутое на нескольких серверах и предполагающее сложную взаимозависимость данных для обеспечения последующего восстановления, будет требовать соответствующей синхронизации резервного копирования.
Установление жизненного цикла и календаря операций
Эффективная работа системы резервного копирования требует ежедневного успешного выполнения определенных заданий. Однако есть не менее важные задания, которые выполняются еженедельно, ежемесячно, ежеквартально и ежегодно. Задания с коротким циклом в большей степени являются тактическими, а задания с большим циклом - стратегическими. В среде эффективного резервного копирования все задания должны быть задокументированы и выполняться согласно расписанию.
Ежедневные задачи являются основой, с которой хорошо знакомы системные администраторы. К ним относятся:
мониторинг заданий;
отчеты о сбоях и успешном выполнении;
анализ и разрешение проблем;
манипуляции с лентами и управление библиотекой;
расписание выполнения заданий.
В случае еженедельных, ежемесячных и других операций надо обращать внимание на:
анализ производительности;
тенденции изменения объемов и планирование этих изменений;
рассмотрение и анализ методики резервного копирования;
проверку возможности восстановления;
планирование развития архитектуры. Определяем ежедневные, еженедельные и ежемесячные задания.
Документируем их, и убеждаемся, что они выполняются и генерируют отчеты в полном соответствии с расписанием. Все эти временные файлы нельзя упускать из виду. Храниться они будут долго, пройдет год, завершится годовой цикл. Поначалу это покажется неудобным, но потом появится понимание, как оптимизировать среду (или окажется, что среда резервного копирования уже оптимизирована).

Ежедневный обзор логов процесса резервного копирования

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

Защита базы данных резервного копирования или каталога

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

Ежедневное определение временного окна резервного копирования

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

Локализация и сохранение "внешних" систем и томов

ПО резервного копирования предоставляет некоторые отчеты о ежедневных сессиях резервного копирования. Рассматривать только их и полагаться только на них рискованно. ПО резервного копирования генерирует отчеты только об известных ему серверах. Сложные среды часто имеют "внешние" системы, системы, которые участвуют в работе, но не включены в схему резервного копирования. Это происходит по разным причинам. Купленная неким подразделением система и оказавшаяся вне поля зрения IT-подразделения некоторое время может работать с собственным резервным копированием. Но рано или поздно возможен сбой, приводящий к потере данных. Тогда специалисты IT-подразделения получают запрос восстановления данных на системе, о которой им ничего не известно. Как правило, такие системы попадают в поле зрения службы IT, слишком поздно. Решение этой проблемы может оказаться трудоемким и займет массу времени. Потребуется регулярный просмотр и мапирование новых сетевых адресов в узлы (ноды), фильтрация не связанных с задачей адресов (дополнительные сетевые карты, сетевые устройства, принтеры и т.д.), идентификация местоположения и владельцев таких узлов и внесение соответствующих изменений в политику резервного копирования (в этом случае объемы данных, подлежащих сохранению, увеличатся). Также важно регулярное предоставление отчетов владельцам системы и приложений о том, что на самом деле сохраняется, а что - нет.

Максимально возможная централизация и автоматизация резервного копирования

Ключом к успешной защите данных является их целостность. Но это не значит, что со всеми данными требуется обходиться одинаково. Наоборот - одинаково надо обращаться с данными, сходными по объему и важности для компании. Проблема "внешних" систем, о которой шла речь чуть выше, как раз является примером нарушения целостности данных, возникающего из-за нецентрализованного управления резервным копированием. Нередко операции резервного копирования для Windows - и Unix-серверов происходят независимо. Такая организация могла предшествовать сетевому хранению. Помимо того что это неэффективно, подобная организация предполагает разные наборы процедур и разные стратегии резервного копирования для разных платформ. Определять ценность данных таким образом неправильно.
По географическим соображениям функции резервного копирования могут быть действительно распределены по удаленным офисам, но, принимая во внимание качество современных коммуникаций, выгода от такой децентрализации весьма небольшая. По мере увеличения сложности инфраструктуры резервного копирования для выполнения повторяющихся операций желательно применять средства автоматизации.
Возьмем, к примеру, трудоемкую задачу ежедневного изучения журналов (логов) выполнения операций. Автоматизация позволит генерировать сигналы тревоги при появлении в логах заранее определенных ошибок. Верно и обратное: автоматизация поможет накапливать повторяющиеся в логах ошибки. Если в логах увидеть одну ошибку SCSI, это то же самое, что увидеть их тысячу.
Просмотр всех одинаковых ошибок - занятие утомительное, способное отбить охоту к ежедневному изучению логов вообще. Если правильно определить выполняемую задачу и ожидаемый результат - средства автоматизации, несомненно, смогут избавить от части утомительной работы.

Создание и поддержка открытых отчетов, отчетов об открытых проблемах

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

Резервное копирование должно быть включено в процесс контроля изменений системы

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

Консультации с вендорами

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

Резервное копирование

Резервное копирование выполняется для того, чтобы можно было:
Восстанавливать отдельные файлы
Восстанавливать целиком файловые системы.
Первый вариант позволяет удовлетворить типичный запрос на восстановление файла, когда пользователь случайно удаляет файл и просит восстановить его из последней копии. Конкретные обстоятельства могут несколько различаться, но вообще это самое распространённое применение резервного копирования.
Второй вариант спасает от худшего кошмара системного администратора, когда по какой-либо причине, то, что не так давно было функционирующей частью центра данных, превращается просто в безжизненную груду железа, пластика и кремния. В итоге вы потеряли все программы и данные, которые накапливали вместе с пользователями не один год. Предполагается, что у вас всё скопировано. Но так ли это?
И если это так, вы можете всё восстановить?

Разные данные - разные подходы к резервному копированию

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

Частота изменения данных очень важна для разработки процедуры резервного копирования. Тому есть две причины:
Резервная копия - это не больше чем снимок копируемых данных. Это отражение данных в определённый момент времени.
И чем чаще меняются данные, тем чаще следует выполнять их резервное копирование.
Системные администраторы, хорошо понимающие, как работают их компьютеры, пользователи и приложения, могут быстро распределить типы данных по разным категориям. Но чтобы вам было легче начать, ниже приведено несколько примеров:

Операционная система

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

Прикладное программное обеспечение

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

Программы для резервного копирования: купить или разработать

Чтобы выполнять резервное копирование, прежде всего, нужно иметь подходящую программу. Эта программа должна не только уметь делать простые копии данных на резервные носители, но и хорошо подходить для сотрудников вашей организации и требований бизнеса. Оценивая программы для резервного копирования, следует обратить внимание на:
Возможности выполнения резервного копирования по расписанию
Управление размещением, циклами копий и использованием носителей
Взаимодействие с операторами (и/или автоматическими устройствами смены носителей), когда требуется определённый носитель
Возможности, облегчающие поиск носителя с определённой копией заданного файла.
Как вы могли заметить, настоящее решение для резервного копирования должно не только сбрасывать биты и байты на резервный носитель.
Придя к этому, многие системные администраторы рассматривают одно из двух решений:
Приобретение коммерческого решения
Разработка своими силами системы резервного копирования с нуля (возможно, с применением одной или нескольких технологий с открытым кодом)
Каждый подход имеет свои положительные и отрицательные стороны. Учитывая сложность задачи, самостоятельно разработанное решение, скорее всего, в чём-то будет уступать коммерческому (например, в управлении носителями, или не будет иметь всеобъемлющей документации или технической поддержки). Однако для некоторых организаций это может быть не важно.
Коммерческое решение, скорее всего, будет более функционально, но оно также может быть слишком универсальным и сложным для текущих нужд организации. И всё-таки, эта универсальность может позволить вам оставаться с одним решением, даже когда ваша организация растёт.
Как вы могли понять, чёткого подхода к выбору системы резервного копирования нет. Можно лишь порекомендовать вам учесть при выборе следующие моменты:
Заменить систему резервного копирования непросто, внедрив её однажды, вы будете использовать её продолжительное время. Хотя бы потому, что у вас будут архивные копии, которые вы должны иметь возможность прочитать. Замена системы резервного копирования означает, что вы должны либо где-то оставить первоначальную систему (чтобы обращаться к архивным копиям), либо преобразовать архивные копии в формат, совместимый с новой системой.
В зависимости от выбранной системы резервного копирования, преобразование архивных копий может быть довольно простым (хотя и длительным) и заключаться в обработке копий уже существующей программой, или очень трудоёмким и потребовать изучения форматов копий и написания специальной программы.
Эта система должна быть абсолютно надежной - она должна в точности копировать всё, что должна, и тогда, когда должна.
И когда придёт время восстанавливать данные, будь то один файл или вся файловая система, система восстановления также должна быть надёжна на 100%.

Типы резервного копирования

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

Полные копии

Резервное копирование, о котором шла речь в начале этого раздела, называется полным. Полная копия - это копия, при которой на резервный носитель сохраняется каждый файл. Как было сказано ранее, если копируемые данные никогда не меняются, все создаваемые полные копии будут одинаковыми.
Это объясняется тем фактом, что при создании полной копии не проверяется, был ли файл изменён со времени последнего копирования, и таким образом, на носитель записывается все файлы, вне зависимости от того, были они изменены или нет.
Вот почему полные копии не делаются постоянно - все файлы уже записаны на резервный носитель. При полном копировании, даже если ничего не меняется, используется большой объём резервного носителя. Ежедневное копирование 100 гигабайт данных, когда возможно, изменяются только 10 мегабайт, противоречит здравому смыслу, вот почему были придуманы добавочные копии.

Добавочные копии

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

Разностные копии

Разностные копии похожи на добавочные тем, что они включают только изменённые файлы. Однако разностные копии являются накопительными - другими словами, при разностном копировании файл, изменённый однажды, будет включаться во все последующие разностные копии (имеется в виду до следующей, полной копии).
Это значит, что каждая разностная копия содержит все файлы, изменённые со времени последней полной копии, что позволяет выполнить полное восстановление, восстановив только последнюю полную и последнюю разностную копию.
Стратегия резервного копирования с разностными копиями обычно похожа на стратегию с добавочными копиями: за одним периодическим полным копированием следует несколько более частых разностных.
Эффект такого использования разностных копий заключается в том, что со временем разностные копии обычно немного вырастут (если в интервале времени между полными копиями меняются разные файлы). Таким образом, разностные копии находятся где-то между добавочными и полными с точки зрения использования резервных носителей и скорости копирования, а также быстроты восстановления одного файла и всей файловой системы (так как приходится просматривать/восстанавливать меньше копий).
Учитывая все эти характеристики, разностные копии заслуживают внимательного изучения.

Резервный носитель

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

Лента

Лента была первым широко используемым съёмным носителем для хранения данных. Её преимуществами является невысокая стоимость самого носителя и достаточно большой объём. Однако, лента имеет и ряд недостатков - она может порваться, а доступ к данным на ленте по определению последователен.
Это означает, что необходимо внимательно следить за использованием лент (и прекращать использование лент, отработавших своё), и что поиск нужного файла на ленте может быть длительным занятием.
С другой стороны, лента - один из наиболее недорогих носителей для хранения данных, а её надёжность проверена временем. Это значит, что для создания ленточной библиотеки приличного объёма, вам не придётся потратить большую часть своего бюджета, и вы сможете полагаться на неё и сегодня, и в будущем.

Диск

В прошлом диски никогда не использовались в качестве резервного носителя. Однако цена хранения на дисках упала до той отметки, когда в некоторых случаях хранение резервных копий на дисках имеет смысл.
Главной причиной для использования дисков в качестве резервных носителей может быть скорость. Это самые быстрые носители данных из существующих. Скорость может быть важна, если в вашем центре данных для резервного копирования отводится небольшое окно, а объём копируемых данных велик.
Но дисковое хранилище - не идеальный резервный носитель по ряду причин:
Диски обычно не являются съёмными. Один их главных факторов эффективной стратегии резервного копирования заключается в хранении резервных копий вне вашего центра данных, в каком-то удалённом хранилище. Резервная копия рабочей базы данных, хранящаяся на диске в полуметре от самой базы данных - это не резервная, а просто копия. И такие копии будут не очень полезны, если ваш центр данных и всё, что в нём находится (включая ваши копии), будет повреждён или разрушен при неблагоприятном стечении обстоятельств.
Диски стоят дорого (по крайней мере, по сравнению с другими резервными носителями). Бывают ситуации, когда деньги на самом деле не играют роли, но в любых других обстоятельствах тратить деньги на диски для хранения резервных копий - значить хранить меньше копий, если общая стоимость хранения копий должна быть низкой. Чем меньше копий, тем меньше избыточность, которая может быть полезна, если какая-то копия по какой-либо причине не прочитается.
Диски очень уязвимы к внешним воздействиям. И даже если вы потратите дополнительные деньги на съёмные жёсткие диски, их уязвимость может быть проблемой. Если вы уроните жёсткий диск, вы потеряете свою резервную копию. Можно приобрести специальные корпуса, которые могут сократить (но не полностью исключить) эту угрозу, но это ещё больше увеличит стоимость и без того дорогостоящего решения.
Диски - это не архивный носитель. И даже если предположить, что вы смогли преодолеть все остальные проблемы, связанные с резервным копированием на диски, вам следует учесть следующее. Многие организации по юридическим требованиям должны хранить данные в течение определённых периодов времени. Шансов прочитать данные с 20-летней ленты намного больше, чем с 20-летнего диска. Например, возникает вопрос, будет ли у вас необходимое оборудование, чтобы подключить старый диск к компьютеру? Ещё один момент, который следует учесть - диск намного сложнее картриджа диска. И когда мотор 20-летней давности должен будет раскрутить 20-летние дисковые пластины и над ними должны будут "парить" 20-летние головки чтения/записи, какова вероятность, что всё это будет исправно работать, пролежав без движения 20 лет?
Но несмотря на всё вышесказанное, тем не менее, бывают ситуации, когда копирование на диске может иметь смысл. В следующем разделе мы узнаем, как такие диски можно сочетать с сетевыми технологиями для реализации вполне жизнеспособного (разве что дорогого) решения резервного копирования.

Сеть

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

Хранение резервных копий

Когда резервные копии сделаны, что должно произойти дальше? Очевидный ответ на этот вопрос - эти копии должны быть сохранены. Однако, совсем не так очевидно, что именно следует хранить - и где.
Чтобы ответить на эти вопросы, мы должны сначала учесть обстоятельства, при которых будут использоваться резервные копии. Можно выделить три основные ситуации:
Восстановление отдельных файлов по запросу пользователей
Глобальное восстановление при чрезвычайной ситуации
Архивное хранилище скорее всего никогда не потребуется
К сожалению, между первой и второй ситуацией существуют несовместимые противоречия. Когда пользователь удаляет файл случайно, он хочет возвратить его немедленно. Следовательно, резервный носитель должен быть не дальше нескольких метров от компьютера, на котором должны быть восстановлены данные.
В случае чрезвычайных ситуаций необходимо будет выполнить полное восстановление одного или нескольких компьютеров в вашем центре данных, а если произошедшая катастрофа будет иметь физический характер, она разрушит не только ваши компьютеры, но и все резервные копии, хранящиеся рядом. Вы окажетесь в ужасном положении.
Вопрос архивного хранилища менее спорный - вероятность того, что вы воспользуйтесь им, довольно мала, поэтому если резервный носитель хранится далеко от центра данных, это не должно быть проблемой.
Для решения этих разных задач могут быть выбраны различные подходы, в зависимости от потребностей организации. Первый возможный подход заключается в хранении копий за несколько дней у себя на месте, а затем переносить эти копии в более безопасное удалённое хранилище, когда будут созданы новые ежедневные копии.
Другой подход заключается в поддержке двух наборов носителей:
Набор носителей в центре данных, используемый исключительно для восстановления отдельных данных по запросу
Набор носителей для удалённого хранения и восстановления в случае чрезвычайных ситуаций
Конечно, наличие двух наборов подразумевает необходимость делать все резервные копии дважды или копировать их. Это можно сделать, но двойное резервное копирование может занять много времени, а для копирования резервных копий могут потребоваться несколько устройств для работы с резервными копиями (и возможно, выделить для копирования отдельный компьютер.
Сложность для системного администратора заключается в выдерживании баланса между удовлетворением нужд пользователей и наличием резервных копий на случай наихудших ситуаций.

Вопросы восстановления

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

Восстановление на "голом" компьютере

Выражением "восстановление на голом компьютере" системные администраторы описывают процесс восстановления полной копии системы на компьютере, на котором нет абсолютно никаких данных - ни операционной системы, ни приложений, ничего.
Вообще можно выделить два основных подхода к восстановлению на голом компьютере:
Переустановка, за которой следует восстановление
Здесь базовая операционная система устанавливается таким же образом, как и на совершенно новый компьютер. Когда операционная система установлена и правильно настроена, оставшиеся диски можно подключить и отформатировать, и восстановить все копии с резервных носителей.
Диски для восстановления системы
Диск для восстановления системы - это загрузочный носитель некоторого рода (обычно CD-ROM), который содержит минимальное системное окружение и позволяет выполнять самые основные административные задачи. Окружение восстановления содержит необходимые утилиты для разбиения на разделы и форматирования дисков, драйверы устройств, необходимые для обращения к устройству с резервными копиями, и программы, необходимые для восстановления данных с резервных носителей.

Проверка копий

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