Копии царя Соломона
Копии царя Соломона
http://win.www.osp.ru/lan/lan_6_97/source/121.html
Тот, кто с истовым упорством создает резервные копии,
еще не может быть уверен в безопасности своих данных.
Уильям Вонг
По нашему глубокому убеждению, только безумный администратор не установит в своей системе устройство резервного копирования. Никому из нас и в голову не придет эксплуатировать производственную сеть, не разработав хотя бы стратегии резервного копирования файлов. Однако суровая правда жизни состоит в том, что даже регулярное изготовление резервных копий отнюдь не означает, что информацию при необходимости удастся восстановить.
В стародавние времена на всех файловых серверах использовались носители на магнитной ленте одного и того же стандартного размера. Сегодня мы имеем четырех- и восьмимиллиметровые кассеты формата DAT Travan, а также кассеты формата DLT (Digital Linear Tape) и недавно появившегося формата AIT (Advanced Intelligent Tape). Нет недостатка и в форматах дисков: оптические, магнитооптические, Compact Disc Recordable, Compact Disc Rewritable, DVD (Digital Versatile Disc). Все эти носители различаются между собой по емкости, скорости записи, возможности случайной выборки данных (некоторые допускают только последовательный доступ) и, что наиболее важно, по надежности и сроку службы. Даже самый емкий и быстрый носитель абсолютно бесполезен, если он не работает должным образом.
Выбирая носитель для системы резервного копирования, администратору следует принимать во внимание целый ряд факторов, в частности срок службы, надежность и взаимозаменяемость. К счастью, все современные носители и оборудование имеют очень высокие показатели по перечисленным нами параметрам, и именно поэтому системы резервного копирования пользуются такой популярностью. Но, как известно, нет в мире совершенства: носитель имеет свойство в конце концов изнашиваться, а взаимозаменяемость не всегда оказывается идеальной особенно в том, что касается совместимости с предыдущими версиями.
В линейных ленточных носителях, таких как DLT или Travan, магнитная лента протягивается вдоль магнитной головки один раз. Такие ленты обычно выдерживают 10 000 протяжек от одного конца до другого, что соответствует от 100 до 300 операций резервного копирования. Объем данных, копируемых за один раз, большого значения не имеет, поскольку лента всегда начинает протягиваться с начала, поэтому в результате 300-кратного считывания небольшого файла лента изнашивается ровно так же, как и после 300 операций полного восстановления данных. Ленточные носители с винтовой разверткой (например, лентопротяжные устройства на базе четырехмиллиметровых кассет стандарта DAT) дают еще больший износ, поскольку здесь лента протягивается вдоль головки несколько раз.
В лентопротяжных устройствах с линейной и винтовой разверткой используются различные методы записи данных на физический носитель. В некоторых системах имеется еще и серводорожка, которая облегчает позиционирование головок чтения/записи, снижая тем самым механический износ и компенсируя небольшие отличия, существующие между разными устройствами записи.
Благодаря удачным инженерным решениям, некоторые технологии резервного копирования оказываются более надежными в смысле совместимости, чем другие. Одним из часто применяемых способов здесь является повышение прочности носителей и самой ленты. Что касается DAT, то тут критическим компонентом является накопитель. В линейных системах (например, Travan) кассеты делаются более прочными, а нижняя платформа более жесткой. Это позволяет улучшить протяжку и снизить допуск на дорожку.
Иметь надежные устройства и носители - еще не значит избавиться от проблем. Давайте обсудим, как данные с источника (жесткого диска сервера или клиентской станции) попадают туда, куда надо (устройство хранения на магнитной ленте). Во-первых, для некоторых приложений (например, баз данных) резервное копирование и восстановление данных надо проводить в реальном времени. Даже восстановление файлов может оказаться непростой задачей, если аппаратная платформа источника данных отличается от целевой платформы. Другая проблема - найти резервную копию нужной версии восстанавливаемого файла; когда резервное копирование производится по частям, решение этой задачи может оказаться непростым делом.
Базы данных и подобные им приложения работают в непрерывном режиме. Резервное копирование файлов данных часто можно производить без остановки приложения, а вот восстанавливать данные в таком режиме возможно далеко не всегда. Связано это с тем, что восстановление файлов с последующим перезапуском приложения, как правило, не приводит к ожидаемому результату, а если файлы подверглись модификации в процессе резервного копирования, копия не будет соответствовать желаемому состоянию файлов.
Так что же делать? Приложение можно закрыть, и только после этого выполнить резервное копирование; кроме того, вы можете также воспользоваться интегрируемым с приложением продуктом для резервного копирования. Последний способ редко применим к заказным приложениям, однако большинство популярных баз данных и многие почтовые программы в настоящее время поддерживаются всеми основными производителями программного обеспечения резервного копирования. Например, все большее число производителей включают поддержку Microsoft Exchange Server и Lotus Notes.
В подобных ситуациях выборочное восстановление как нельзя кстати, поскольку при восстановлении после аварий перестройку (rebuild) и запуск базы данных необходимо осуществить как можно скорее. Полное восстановление привело бы к изменению конфигурации. Если данные пришлось восстанавливать из-за ошибки в программном обеспечении, то вместе с данными можно воспроизвести и саму проблему.
Схожая проблема возникает при резервном копировании данных работающих приложений. Хорошая программа повторит попытку скопировать файл, если с первого захода сделать этого не удалось из-за того, что файл был занят другой программой. Повторная попытка обычно осуществляется по окончании резервного копирования; иногда программа может отложить операцию на еще более позднее время и будет пытаться осуществить ее до тех пор, пока не исчерпается допустимое число попыток или попытка не будет успешной. Первый вариант предпочтительнее, поскольку ожидание успешной попытки, особенно при возникновении большого числа конфликтов, может сильно затянуться.
Не стоит забывать и о различиях между платформами. Представим себе, что данные изначально копировались с файловых серверов на платформах Macintosh, Windows NT или OS/2, а восстановить их надо на файловый сервер под управлением NetWare. При работе с некоторыми программами резервного копирования требуется, чтобы источник данных и место их назначения работали на одной и той же платформе, и здесь надо обязательно следить за тем, чтобы в организации имелась хотя бы одна машина для каждой из платформ, данные с которой записаны на магнитные ленты. Это может оказаться не так-то просто: представим себе, что данные копировались с компьютера под NetWare 3.11 или Windows NT 3.1, а потом компания решила отказаться от использования этих платформ.
Некоторые продукты допускают копирование с одной платформы на другую, однако при этом часть данных из-за принятых ограничений на платформе, куда осуществляется копирование, иногда теряется: имя файла может оказаться обрезанным или часть файловых атрибутов может пропасть и т. д. Например, в системах для Macintosh имена файлов состоят из двух частей - ветви ресурсов и ветви данных; обе эти части не всегда корректно транслируются в унитарный формат, используемый на большинстве ПК под DOS. Проблемы межплатформенного обмена могут возникнуть даже при переходе с одной операционной системы на другую (например, с NetWare на Windows NT Server), а также в гетерогенных сетях, где резервное копирование данных приходится выполнять с разнородных рабочих станций.
Задача восстановления системных баз данных возникает также при необходимости дистанционного восстановления рабочих станций и серверов. Проблемы тут точно такие же, поэтому следует убедиться, что селективное восстановление данных возможно. Советуем также попытаться проверить его на практике: нет ничего хуже, чем повторно установить рабочую станцию и восстановить остальные данные, а потом обнаружить, что системная база данных содержит искаженную информацию.
Хорошо это или плохо, но непосредственно с системными базами данных работают (и понимают их) далеко не все пользователи и даже не все администраторы. Например, нахождение содержащейся в Registry информации о рабочих станциях под Windows 95 и определение подлежащих восстановлению фрагментов - задача, как минимум, непростая.
Чем сложнее конфигурация сервера, тем необходимее восстановление после аварий. Полное восстановление сервера может занять очень много времени, а время - деньги. Если для того, чтобы просто взглянуть на резервные копии на ленте, необходимо повторно установить операционную систему и ленточный накопитель, то вся работа по восстановлению системы вполне может растянуться на целый день, а то и больше.
Продукты поддержки восстановления после аварий, например Storage Manager for Windows NT and NetWare компании Seagate Software и Replica (для тех же платформ) от Stac, состоят из одного или более загрузочных дисков, содержащих необходимую информацию для начальной конфигурации программного обеспечения восстановления после аварий. На магнитных лентах находится резервная копия восстанавливаемой системы, а также поддержка установки сетевой операционной системы и программное обеспечение резервного копирования на ленту (две последние программы обычно записываются на входящий в комплект поставки CD-ROM). В процессе восстановления данных с гибких дисков считывается конфигурационная и управляющая информация, необходимая для восстановления данных. Лента содержит основную часть информации о конфигурации системы, а также обычные файлы. В теории процедура восстановления после аварии должна занимать столько же времени, сколько и простая установка сервера и полное восстановление данных с магнитной ленты.
Процедура восстановления после аварии обычно предусматривает установку сервера в минимальной конфигурации с последующим использованием специальной дискеты для восстановления после аварии. В результате, поддержка восстановления с магнитной ленты и основные функции операционной системы оказываются возобновлены. Следующий этап - восстановление данных с магнитной ленты. Если для восстановления используется система с той же конфигурацией, что и у системы, с которой изначально изготавливались резервные копии (или просто та же система), то нормальную работу можно начинать, как правило, тут же. В противном случае вполне вероятно, что некоторые параметры конфигурации системы понадобится настроить. Например, если сетевые адаптеры другие, то надо будет удалить старые и поставить новые драйверы. В больших организациях восстановление после аварий необходимо порою осуществлять через сеть. Эта процедура напоминает описанную, с той только разницей, что магнитная лента находится на сетевом сервере резервного копирования.
Компании, у которой в данный момент нет программного обеспечения поддержки восстановления после аварии, стоит задуматься о поиске такого решения. Вообще, принятые процедуры восстановления после аварии следует периодически подвергать переоценке, а соответствующие системы поддержки, если таковые имеются, тестировать (делать это надо не реже раза в год). При чтении материалов, предоставленных производителем, может сложиться впечатление, что восстановить данные после аварии легко и просто. Тем не менее всегда могут возникнуть какие-то неожиданности, и в таких ситуациях администратору сети крайне неприятно будет ощущать на своем затылке тяжелое дыхание генерального директора, с нетерпением ожидающего запуска сети. Поэтому всякий раз при установке нового сервера имеет смысл испытать на нем аварийные дискеты и ленты от другого сервера. Эксперимент может получиться захватывающий!
Резервное копирование выполняется ежедневно или еженедельно, но восстанавливать данные приходится редко. Проверка процедур восстановления данных и системы после аварии может оказаться скучным занятием, но обойтись без этого нельзя. Иначе придется объяснять багровым от злости начальникам и пользователям, почему их данные пропали.
Нашел и подготовил Александр Запольскис
E-mail: leshy@nestor.minsk.by - титульная страница
http://win.www.osp.ru/lan/lan_6_97/source/121.html
Тот, кто с истовым упорством создает резервные копии,
еще не может быть уверен в безопасности своих данных.
Уильям Вонг
По нашему глубокому убеждению, только безумный администратор не установит в своей системе устройство резервного копирования. Никому из нас и в голову не придет эксплуатировать производственную сеть, не разработав хотя бы стратегии резервного копирования файлов. Однако суровая правда жизни состоит в том, что даже регулярное изготовление резервных копий отнюдь не означает, что информацию при необходимости удастся восстановить.
В стародавние времена на всех файловых серверах использовались носители на магнитной ленте одного и того же стандартного размера. Сегодня мы имеем четырех- и восьмимиллиметровые кассеты формата DAT Travan, а также кассеты формата DLT (Digital Linear Tape) и недавно появившегося формата AIT (Advanced Intelligent Tape). Нет недостатка и в форматах дисков: оптические, магнитооптические, Compact Disc Recordable, Compact Disc Rewritable, DVD (Digital Versatile Disc). Все эти носители различаются между собой по емкости, скорости записи, возможности случайной выборки данных (некоторые допускают только последовательный доступ) и, что наиболее важно, по надежности и сроку службы. Даже самый емкий и быстрый носитель абсолютно бесполезен, если он не работает должным образом.
Выбирая носитель для системы резервного копирования, администратору следует принимать во внимание целый ряд факторов, в частности срок службы, надежность и взаимозаменяемость. К счастью, все современные носители и оборудование имеют очень высокие показатели по перечисленным нами параметрам, и именно поэтому системы резервного копирования пользуются такой популярностью. Но, как известно, нет в мире совершенства: носитель имеет свойство в конце концов изнашиваться, а взаимозаменяемость не всегда оказывается идеальной особенно в том, что касается совместимости с предыдущими версиями.
В линейных ленточных носителях, таких как DLT или Travan, магнитная лента протягивается вдоль магнитной головки один раз. Такие ленты обычно выдерживают 10 000 протяжек от одного конца до другого, что соответствует от 100 до 300 операций резервного копирования. Объем данных, копируемых за один раз, большого значения не имеет, поскольку лента всегда начинает протягиваться с начала, поэтому в результате 300-кратного считывания небольшого файла лента изнашивается ровно так же, как и после 300 операций полного восстановления данных. Ленточные носители с винтовой разверткой (например, лентопротяжные устройства на базе четырехмиллиметровых кассет стандарта DAT) дают еще больший износ, поскольку здесь лента протягивается вдоль головки несколько раз.
В лентопротяжных устройствах с линейной и винтовой разверткой используются различные методы записи данных на физический носитель. В некоторых системах имеется еще и серводорожка, которая облегчает позиционирование головок чтения/записи, снижая тем самым механический износ и компенсируя небольшие отличия, существующие между разными устройствами записи.
Благодаря удачным инженерным решениям, некоторые технологии резервного копирования оказываются более надежными в смысле совместимости, чем другие. Одним из часто применяемых способов здесь является повышение прочности носителей и самой ленты. Что касается DAT, то тут критическим компонентом является накопитель. В линейных системах (например, Travan) кассеты делаются более прочными, а нижняя платформа более жесткой. Это позволяет улучшить протяжку и снизить допуск на дорожку.
Иметь надежные устройства и носители - еще не значит избавиться от проблем. Давайте обсудим, как данные с источника (жесткого диска сервера или клиентской станции) попадают туда, куда надо (устройство хранения на магнитной ленте). Во-первых, для некоторых приложений (например, баз данных) резервное копирование и восстановление данных надо проводить в реальном времени. Даже восстановление файлов может оказаться непростой задачей, если аппаратная платформа источника данных отличается от целевой платформы. Другая проблема - найти резервную копию нужной версии восстанавливаемого файла; когда резервное копирование производится по частям, решение этой задачи может оказаться непростым делом.
Базы данных и подобные им приложения работают в непрерывном режиме. Резервное копирование файлов данных часто можно производить без остановки приложения, а вот восстанавливать данные в таком режиме возможно далеко не всегда. Связано это с тем, что восстановление файлов с последующим перезапуском приложения, как правило, не приводит к ожидаемому результату, а если файлы подверглись модификации в процессе резервного копирования, копия не будет соответствовать желаемому состоянию файлов.
Так что же делать? Приложение можно закрыть, и только после этого выполнить резервное копирование; кроме того, вы можете также воспользоваться интегрируемым с приложением продуктом для резервного копирования. Последний способ редко применим к заказным приложениям, однако большинство популярных баз данных и многие почтовые программы в настоящее время поддерживаются всеми основными производителями программного обеспечения резервного копирования. Например, все большее число производителей включают поддержку Microsoft Exchange Server и Lotus Notes.
В подобных ситуациях выборочное восстановление как нельзя кстати, поскольку при восстановлении после аварий перестройку (rebuild) и запуск базы данных необходимо осуществить как можно скорее. Полное восстановление привело бы к изменению конфигурации. Если данные пришлось восстанавливать из-за ошибки в программном обеспечении, то вместе с данными можно воспроизвести и саму проблему.
Схожая проблема возникает при резервном копировании данных работающих приложений. Хорошая программа повторит попытку скопировать файл, если с первого захода сделать этого не удалось из-за того, что файл был занят другой программой. Повторная попытка обычно осуществляется по окончании резервного копирования; иногда программа может отложить операцию на еще более позднее время и будет пытаться осуществить ее до тех пор, пока не исчерпается допустимое число попыток или попытка не будет успешной. Первый вариант предпочтительнее, поскольку ожидание успешной попытки, особенно при возникновении большого числа конфликтов, может сильно затянуться.
Не стоит забывать и о различиях между платформами. Представим себе, что данные изначально копировались с файловых серверов на платформах Macintosh, Windows NT или OS/2, а восстановить их надо на файловый сервер под управлением NetWare. При работе с некоторыми программами резервного копирования требуется, чтобы источник данных и место их назначения работали на одной и той же платформе, и здесь надо обязательно следить за тем, чтобы в организации имелась хотя бы одна машина для каждой из платформ, данные с которой записаны на магнитные ленты. Это может оказаться не так-то просто: представим себе, что данные копировались с компьютера под NetWare 3.11 или Windows NT 3.1, а потом компания решила отказаться от использования этих платформ.
Некоторые продукты допускают копирование с одной платформы на другую, однако при этом часть данных из-за принятых ограничений на платформе, куда осуществляется копирование, иногда теряется: имя файла может оказаться обрезанным или часть файловых атрибутов может пропасть и т. д. Например, в системах для Macintosh имена файлов состоят из двух частей - ветви ресурсов и ветви данных; обе эти части не всегда корректно транслируются в унитарный формат, используемый на большинстве ПК под DOS. Проблемы межплатформенного обмена могут возникнуть даже при переходе с одной операционной системы на другую (например, с NetWare на Windows NT Server), а также в гетерогенных сетях, где резервное копирование данных приходится выполнять с разнородных рабочих станций.
Задача восстановления системных баз данных возникает также при необходимости дистанционного восстановления рабочих станций и серверов. Проблемы тут точно такие же, поэтому следует убедиться, что селективное восстановление данных возможно. Советуем также попытаться проверить его на практике: нет ничего хуже, чем повторно установить рабочую станцию и восстановить остальные данные, а потом обнаружить, что системная база данных содержит искаженную информацию.
Хорошо это или плохо, но непосредственно с системными базами данных работают (и понимают их) далеко не все пользователи и даже не все администраторы. Например, нахождение содержащейся в Registry информации о рабочих станциях под Windows 95 и определение подлежащих восстановлению фрагментов - задача, как минимум, непростая.
Чем сложнее конфигурация сервера, тем необходимее восстановление после аварий. Полное восстановление сервера может занять очень много времени, а время - деньги. Если для того, чтобы просто взглянуть на резервные копии на ленте, необходимо повторно установить операционную систему и ленточный накопитель, то вся работа по восстановлению системы вполне может растянуться на целый день, а то и больше.
Продукты поддержки восстановления после аварий, например Storage Manager for Windows NT and NetWare компании Seagate Software и Replica (для тех же платформ) от Stac, состоят из одного или более загрузочных дисков, содержащих необходимую информацию для начальной конфигурации программного обеспечения восстановления после аварий. На магнитных лентах находится резервная копия восстанавливаемой системы, а также поддержка установки сетевой операционной системы и программное обеспечение резервного копирования на ленту (две последние программы обычно записываются на входящий в комплект поставки CD-ROM). В процессе восстановления данных с гибких дисков считывается конфигурационная и управляющая информация, необходимая для восстановления данных. Лента содержит основную часть информации о конфигурации системы, а также обычные файлы. В теории процедура восстановления после аварии должна занимать столько же времени, сколько и простая установка сервера и полное восстановление данных с магнитной ленты.
Процедура восстановления после аварии обычно предусматривает установку сервера в минимальной конфигурации с последующим использованием специальной дискеты для восстановления после аварии. В результате, поддержка восстановления с магнитной ленты и основные функции операционной системы оказываются возобновлены. Следующий этап - восстановление данных с магнитной ленты. Если для восстановления используется система с той же конфигурацией, что и у системы, с которой изначально изготавливались резервные копии (или просто та же система), то нормальную работу можно начинать, как правило, тут же. В противном случае вполне вероятно, что некоторые параметры конфигурации системы понадобится настроить. Например, если сетевые адаптеры другие, то надо будет удалить старые и поставить новые драйверы. В больших организациях восстановление после аварий необходимо порою осуществлять через сеть. Эта процедура напоминает описанную, с той только разницей, что магнитная лента находится на сетевом сервере резервного копирования.
Компании, у которой в данный момент нет программного обеспечения поддержки восстановления после аварии, стоит задуматься о поиске такого решения. Вообще, принятые процедуры восстановления после аварии следует периодически подвергать переоценке, а соответствующие системы поддержки, если таковые имеются, тестировать (делать это надо не реже раза в год). При чтении материалов, предоставленных производителем, может сложиться впечатление, что восстановить данные после аварии легко и просто. Тем не менее всегда могут возникнуть какие-то неожиданности, и в таких ситуациях администратору сети крайне неприятно будет ощущать на своем затылке тяжелое дыхание генерального директора, с нетерпением ожидающего запуска сети. Поэтому всякий раз при установке нового сервера имеет смысл испытать на нем аварийные дискеты и ленты от другого сервера. Эксперимент может получиться захватывающий!
Резервное копирование выполняется ежедневно или еженедельно, но восстанавливать данные приходится редко. Проверка процедур восстановления данных и системы после аварии может оказаться скучным занятием, но обойтись без этого нельзя. Иначе придется объяснять багровым от злости начальникам и пользователям, почему их данные пропали.
Нашел и подготовил Александр Запольскис
E-mail: leshy@nestor.minsk.by - титульная страница
Компьютерная газета. Статья была опубликована в номере 07 за 1998 год в рубрике интернет :: копилка ресурсов
