The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

О разработке процедур резервного копирования (backup)


<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>
Ключевые слова: backup,  (найти похожие документы)
From: Santa Claus <http://santa-claus-rpm.livejournal.com>; Date: Mon, 12 Nov 2006 18:21:07 +0000 (UTC) Subject: О разработке процедур резервного копирования Оригинал: http://santa-claus-rpm.livejournal.com/2801.html О разработке процедур резервного копирования, архивирования и восстановления серверов и баз данных. (редакция от 04.04.2006г.) Предисловие от автора Несмотря на внушительный список литературы, приведенный в конце, и огромный практический объем работ, выполненных автором данного произведения, не стоит воспринимать описанное здесь как догму. Толковой литературы подобного рода на русском языке нет вообще. Если вы решитесь организовать процесс так, как надо, то вас ждет большой фронт работ, в том числе и организационных. И это не будет легкой прогулкой, проверено. Автор позиционирует данную работу как квинтэссенцию мирового опыта по данной теме. Термины и определения Примечание. Все термины и определения даны с точки зрения резервного копирования и восстановления. Прикладное программное обеспечение - в совокупности: прикладная СУБД, базы данных (БД), АРМ, исходные тексты АРМ (если есть). Допускается включение в это понятие и среды разработки АРМ (C++ Builder, Java JDK, Eclipse и т.п.), а также различных машин (JRE, .NET и т.п.) необходимых для исполнения псевдокода. Системное программное обеспечение (сервера) - системные данные сервера в совокупности обеспечивающие работоспособность прикладных задач. Включает в себя: * системные данные (таблицы разделов, загрузочную запись, учетные записи пользователей, системный реестр, информация о правах пользователей на системные ресурсы, база данных Active Directory, DNS, DHCP, WINS, таблицы маршрутизации и т.п.); * системное программное обеспечение (файлы самой операционной системы, системные утилиты и программы). Информационный ресурс - информация в электронном виде, включающая в себя как прикладное так и системное ПО, обеспечивающе функционирование данных прикладных задач. Резервное копирование (резервирование) - копирование информационных ресурсов с целью дальнейшего быстрого их восстановления. Различают: * полное резервное копирование (копирование всех файловых систем серверов вместе со всеми системными данными и прикладными задачами), * дифференциальное резервное копирование (только изменения с момента последнего полного резервного копирования), * инкрементальное резервное копирование (изменения с момента последнего резервного копирования). Примечание. Обычно срок хранения резервных копий небольшой (несколько дней), затем более старая копия перезаписывается более новой. Архивирование - копирование информационных ресурсов с первичных носителей на съемные устройства хранения (обычно это магнитные ленты, CD-R/W, DVD, съемные HDD). Основное назначение архивной копии - надежное долговременное хранение данных. При архивировании понятия дифференциального, инкрементального копирования отсутствуют. Далее для краткости под термином "копирование" подразумевается как резервное копирование так и архивирование. Восстановление bare-metal (дословно - "на голое железо", "с нуля") - процесс полной переустановки компьютера после серъезного аварийного отказа. Восстановление может производиться как на те же самые аппаратные средства, так и на аппаратные средства существенно отличающиеся по характеристикам. Подобное восстановление включает в себя: полную переустановку операционной системы и прикладного программного обеспечения, восстановление настроек операционной системы и информации прикладных баз данных. Основные цели разработки В результате разработки по каждому информационному ресурсу должны быть получены и протестированы следующие планы: 1. План резервного копирования, архивирования и восстановления системного ПО. 2. План резервного копирования, архивирования и восстановления прикладного ПО (по каждой прикладной задаче). 3. План восстановления информационного ресурса bare-metal включающий в себя следующие этапы: * первоначальная установка операционной системы сервера из инсталляционных файлов; * настройка операционной системы сервера, в т.ч. запуск и настройка необходимых системных сервисов (Active Directory, DNS, WINS, Samba, SSH и т.п.) * создание групп и пользовательских учетных записей; * установка СУБД из инсталляционных файлов; * настройка параметров СУБД; * установка АРМа из инсталляционных файлов; * создание в прикладной задаче всех пользовательских учетных записей; * восстановление баз данных из архивных и/или резервных копий; * запуск системы и проверка ее работоспособности; * проверка целостности прикладных баз данных. Основные причины по которым необходимо наличие плана восстановления bare-metal следующие: * резервная, архивная копия может отсутствовать: утрачена по причине порчи носителя, утеряна, либо просто не сделана по к.-л. причинам; * сам файл копии может быть поврежден и нечитаем; * копия может быть невосстановимой на другие аппаратные средства. Например, производитель встроил аппаратную защиту в свое ПО. Основные этапы разработки Разработка процедур резервного копирования, архивирования и восстановления информационных ресурсов состоит из следующих основных этапов: 1. Определение приемлемых и не приемлемых потерь данных. Включает: * классификацию информационных ресурсов по степени важности. Для классифицированных данных проще разработать адекватную процедуру копирования. Примечание. Вы не сможете пропустить этот пункт и будете вынуждены постоянно к нему возвращаться, если упустили вначале. Так что лучше отработать его сразу и первым, т.е. так как написано. * выявление данных, которые необходимо дублировать (реплицировать) немедленно, как только они изменились (обычно это особо важные данные); * если возможно, необходимо оценить ущерб от потери данных в денежном эквиваленте; * определение какие ресурсы требуют резервного копирования, а какие - архивирования. Возможно, что нет необходимости выполнять резервное копирование и архивирование некоторых информационных ресурсов. Возможно, что достаточно выполнять резервное копирование, и не выполнять архивирование некоторых информационных ресурсов; * определение допустимого времени восстановления; * определение режима доступности информационных ресурсов (круглосуточно 365 дней в году; в рабочее время с 08:00 до 17:00 в рабочие дни или по какому-либо другому расписанию). 2. Планы полного резервного копирования информационного ресурса в целом. Включают: * По возможности резервное копирование всех файловых систем сервера в целом. Типичная ошибка в некоторых ситуациях: делать копии отдельно системных данных и отдельно прикладных, пользовательских данных, в результате восстановления из таких копий можно получить в целом рассогласованную систему. * Однако, в дополнение к полной копии, все-таки необходимо иметь и отдельную архивную копию баз данных, прикладного ПО, исходных текстов прикладного ПО (если есть). * Имеются ли особые условия создания резервных и архивных копий (например, все пользователи информационного ресурса должны прекратить работу, сервер должен быть переведен в однопользовательский режим, должна быть остановлена или выгружена соответствующая СУБД, некий раздел должен быть перемонтирован в режиме read-only и т.п.). * Разрабатываемая процедура копирования должна иметь как можно большую степень автоматизации. Иначе, если процедура копирования во многом зависит от соблюдения исполнителями определенных правил, которые нельзя реализовать автоматически, то со временем их будут нарушать. 3. Решение организационных вопросов. Распределение обязанностей: * Кто разрабатывает, согласовывает планы копирования, восстановления. И каким образом эти планы доводятся до исполнителей. * Каким образом, кем утвержден план резервирования, архивирования и восстановления. * Если создание копий происходит автоматически, то кто обрабатывает сообщения об ошибках во время копирования. * Кто делает резервные копии, если назначенный исполнитель отсутствует (находится в отпуске и т.п.). * Если исполнитель вынужден, по какой-либо важной причине, контролировать процесс копирования во вторую смену, то кто вместо него будет работать на следующий день. * Кому исполнитель должен доложить о неудачном копировании. Какие еще действия в связи с этим предпринять. * Кто заменяет исполнителя в то время как он вынужден расследовать проблемы копирования или в это время он занимается восстановлением. * Если копирование завершилось неудачно из-за отказа аппаратной части, и какое время потребуется для ремонта, замены - то кто будет взаимодействовать с продавцом техники. * Несут ли пользователи ответственность за копирование и архивирование информации с их собственных ПК. Где это прописано. Технические вопросы: * Кто предоставляет необходимые технические ресурсы для организации резервирования и архивирования. * Организация выделенного помещения для серверов. * Организация хранения носителей копий: температура, влажность, физическая безопасность. Кто, как и чем эти характеристики будет отслеживать. * Через сколько циклов перезаписи машинный носитель (магнитную ленту или CD-RW, DVD) необходимо списывать не дожидаясь его физического отказа. Каков ресурс самого привода. * Для организации быстрого поиска требуемых архивных копий необходима система маркировки съемных носителей информации. * Защищены ли системы копирования по электропитанию. Прочие вопросы: * Какими конкретно документами определяются строки хранения архивных копий. * Дублируется ли информация, хранимая в БД, также и на других не машинных носителях информации (распечатки отчетов, платежные документы, ведомости и т.п.) * Как запускается процесс копирования: автоматически в пакетном режиме или вручную по команде оператора. * Как контролируется процесс копирования: автоматически или вручную оператором. 4. Защита от стихийных и антропогенных бедствий. Включает: * Рассмотрение вопроса о том какие природные катаклизмы происходят в данной географической области (ураганы, наводнения, сильные грозы). * Рассмотрение угрозы возникновения пожара, поджога, затопления, кражи. * Необходимо рассмотрение вопроса о хранении резервных и архивных копий вне серверных помещений вычислительного центра, желательно на другом этаже или в другом здании. 5. Все планы и процедуры копирования должны быть документированы. * Поскольку восстановление после аварии будет всегда проходить в стрессовом режиме, то четкий и хорошо документированный план обязателен. * Документация должна храниться как в бумажном так и в электронном виде (желательно в одном из широкораспространенных форматов HTML, ASCII-text, PDF), свободно доступном для специалистов, ответственных за копирование и восстановление. * Документация должна включать: подробные пошаговые инструкции для восстановления с резервных, архивных копий; описания где копии физически хранятся. * Дополнительно необходимо иметь: подробные пошаговые инструкции восстановления bare-metal, т.е. по первоначальной установке и настройке операционной системы, базы данных Active Directory (для ОС Windows) и т.п., созданию пользовательских учетных записей, распределение прав пользователей, настройка групповых политик (для ОС Windows), маршрутизации, пакетных фильтров и т.д. * Подробные пошаговые инструкции для установки прикладного ПО: СУБД, АРМов и т.д. 1. Обязательное регулярное тестирование планов восстановления. Под тестированием понимается практическая проверка всех планов аварийного восстановления, а также проверка восстановленной системы на работоспособность. Возможно, что на время проведения таких проверок, тестов потребуется дополнительное аппаратное обеспечение, либо виртуальная машина. Примечание. Не требуется воссоздавать, скажем так, реальную нагрузку на сервер или имитировать полные аппаратные средства. Далее: * Необходимо определить периодичность (например, ежегодно) тестирования всех планов восстановления, включая планы восстановления bare-metal, и определить специалистов, ответственных за проведение таких тестов. * Рекомендуется, чтобы тестирование проводилось не теми же самыми специалистами, которые писали планы. * По результатам тестирования восстановления особо важных данных рекомендуется составлять соответствующий протокол. Если требуется, в план восстановления должны вноситься необходимые изменения. * Периодическое тестирование и пересмотр планов восстановления - ключевая часть обеспечения защиты данных. При тестировании (а также ранее при разработке) плана восстановления необходимо также удостовериться, что: * соответствует ли план, процедура копирования современным требованиям сохранности информационных ресурсов; * возможно ли восстановление множества отдельных файлов; * возможно ли восстановление более старой версии файла; * возможно ли полностью пересоздать систему; * возможно ли восстановление БД, если утеряна ее часть, например, один из файлов; * возможно ли полное восстановление БД на другой сервер. 6. Защита информации. * Поскольку копии могут содержать конфиденциальную информацию и могут быть прочитаны любым специалистом, который имеет к ним доступ, необходимо определить - требуется ли дополнительная защита в виде какого-либо шифрования данных сделанных копий. Примечание. Не нужно шифровать все подряд. Это палка о двух концах. Может быть, что вы сами не сможете вспомнить пароль. * Необходимо также определить, содержит ли копия данные, отнесенные к коммерческой тайне предприятия и в этом случае для защиты руководствоваться соответствующими нормативными документами. * Рекомендуется архивные копии делать на съемные носители с однократной записью (CD-R, DVD-R) для защиты копий от несанкционированных модификаций. * Для проверки читаемости носителя, вместе с данными рекомендуется иметь файл, содержащий контрольные суммы (хэши) файлов с данными (например, по алгоритму MD5, SHA1), для последующей автоматической сверки. * Программное обеспечение для резервирования и архивирования должно обладать лицензионной чистотой, во избежание получения невосстановимых копий. Основные вопросы Разработанный план резервирования и восстановления должен отвечать на следующие вопросы: 1. Почему? Действительно ли потеря данных имеет значение. Какой ущерб может быть нанесен в случае аварии. 2. Что? Что конкретно подлежит резервированию, а что - архивированию. 3. Когда? Какое наилучшее время для выполнения копии (окно копирования), обычно - это нерабочее ночное время. Как часто необходимо делать полную резервную копию, а когда инкрементальную. 4. Где? Где физически будут делаться копии, в т.ч. и на съемные носители. Где физически они будут храниться. 5. Кто? Кто обеспечивает необходимые аппаратные средства, установку и настройку программного обеспечения для копирования. 6. Как? Необходимо исследовать различные методы, такие как: репликация, зеркалирование, RAID, хранение данных за пределами вычислительного центра, дублирование аппаратных средств и т.д. Идентификация угроз Каждая разрабатываемая процедура резервного копирования, архивирования и восстановления должна в той или иной мере защищать информационные ресурсы от следующих основных типов угроз (в порядке убывания значимости): 1. Ошибки пользователей (наибольший процент ошибок, по некоторым данным до 40%). Практически единственный способ защиты: архивирование информации с определенной периодичностью и долговоременное хранение копий. 2. Ошибки системных администраторов, особенно при (ре)конфигурации системы. 3. Отказы аппаратуры, в т.ч.: * отказы контроллера жесткого диска; * отказы оперативной памяти; * отказы сетевого оборудования; * отказы блоков питания и т.п. 4. Отказы жестких дисков. Способ защиты: зеркалирование, RAID. 5. Отказы всей системы в целом. Способ защиты: план восстановления bare-metal. 6. Программные ошибки. 7. Электронные взломы, вирусы и кража данных. 8. Стихийные и антропогенные бедствия, в т.ч. пожары, затопления, кражи. Примечание. Список составлен на основании данных, почерпнутых из Интернета. Изучите его внимательнее, посмотрите чего следует опасаться в первую очередь. При разработке плана копирования и восстановления должен рассматриваться самый пессимистический сценарий утраты информационных ресурсов. Некоторые проблемы создания копий При разработке процедур резервирования и восстановления необходимо учитывать некоторые практические аппаратно-программные проблемы. * При записи на ленту, если через несколько лет выйдет из строя накопитель (стриммер), возможно ли будет прочитать копию (ленту) на более новом оборудовании, учитывая, что старых моделей накопителей уже может не быть в продаже. * При записи на CD-R/W, DVD-R/W ни один производитель не называет гарантированный срок хранения таких носителей. По некоторым данным срок хранения может быть от 3 до 20 лет, однако на практике этот срок значительно сокращается из-за пыли, царапин и расслоения. * При выполнении копирования в ОС Windows системными средствами Ntbackup операционная система в которой создавался файл резервного копирования (*.bkf) и операционная система в которой будет проводиться восстановление из этого файла должны быть идентичными со всеми сервиспаками. * При выполнении копирования в ОС Unix, Linux системными средствами tar, cpio, dump существует вероятность того, что в оглавлении архива файл присутствует, но физически в архиве его нет. Подробнее по этим вопросам см. [1] * Существуют проблемы при обработке больших файлов (>2Гб). Критерии выбора ПО для копирования При выборе программного обеспечения для резервирования и архивирования необходимо ответить на следующие вопросы. * Поддерживает ли ПО полностью все программно-аппаратные платформы, используемые на предприятии. * Поддерживает ли ПО копирование т.н. raw-разделов (Oracle, Informix). * Поддерживает ли ПО копирование очень больших файловых систем, больших файлов, файлов с длинными именами, файлов с именами в национальной кодировке. Поддерживается ли сохранение атрибутов файлов, в т.ч. и атрибутов безопасности. * Поддерживается ли копирование множества клиентов на один том одновременно. Поддерживается ли копирование одного клиента на множество томов одновременно. * Обрабатывается ли копирование баз данных, требующих специальных дополнительных процедур (останов, выгрузка СУБД). * Имеется ли возможность управления хранилищем. * Поддерживается ли сжатие данных на стороне клиента (для уменьшения сетевого трафика). * Поддерживается стандартный или уникальный формат хранения данных. Другими словами, можно ли восстановить, прочитать копию стандартными средствами без использования данного ПО. * Насколько сложно ПО при администрировании, есть ли рассылка протоколов копирования по e-mail. * Насколько просто выполняется восстановление из копии. Возможно ли восстановление по сети, восстановление bare-metal. * Насколько хорошо защищены метаданные этого ПО (индекс, база данных копий). * Насколько автоматизированы действия по получению копий. * Может ли ПО проверять состояние копий. * Стоимость. * Имеется ли техподдержка данного ПО. Известный ли это продукт. Порядок внесения изменений Необходимые изменения в планы копирования и восстановления вносятся при: 1. Обнаружении ошибок при тестировании. 2. Изменении конфигурации и настроек сервера (установка нового прикладного или системного ПО, добавление/удаление пользовательских учетных записей, запуск новых системных сервисов, установка новых сетевых интерфейсов, изменения в таблице маршрутизации и т.п.) 3. Изменение конфигурации и настроек прикладного ПО (переход на другую версию и т.п.). Используемая литература * W.Curtis Preston "UNIX Backup and Recovery" O`Reilly, ISBN: 1-56592-642-0 * http://www.microsoft.com "Developing Backup and Restore Procedures" * http://www.microsoft.com "Backup and Restore Solution for Windows 2000" * Microsoft Corp. "Windows 2000 Server Disaster Recovery Guidelines.White Paper." * Brien M. Posey, http://searchtechtarget.techtarget.com "Bare metal restore via Automated System Recovery".

<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>

 Добавить комментарий
Имя:
E-Mail:
Заголовок:
Текст:




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2022 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру