Резервное копирование. Теория и практика. Краткое изложение. Журнал резервного копирования пример

Резервное копирование. Теория и практика. Краткое изложение::Журнал СА 11.2010

Рубрика: БИТ. Бизнес & Информационные технологии /  Бэкап

Facebook Twitter Мой мир Вконтакте Одноклассники Google+

 АЛЕКСЕЙ БЕРЕЖНОЙ, системный администратор. Главные направления деятельности: виртуализация и гетерогенные сети. Еще одно увлечение помимо написания статей – популяризация бесплатного ПО

Резервное копированиеТеория и практика. Краткое изложение

Чтобы организовать систему резервного копирования наиболее эффективно, нужно выстроить настоящую стратегию сохранения и восстановления информации

Резервное копирование (или, как его еще называют, бэкап – от английского слова «backup») является важным процессом в жизни любой ИТ-структуры. Это парашют для спасения в случае непредвиденной катастрофы. В то же время резервное копирование используется для создания своего рода исторического архива бизнес-деятельности компании на протяжении определенного периода ее жизни. Работать без бэкапа – все равно, что жить под открытым небом – погода может испортиться в любой момент, а спрятаться негде. Но как его правильно организовать, чтобы не потерять важных данных и не потратить на это фантастические суммы?

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

В данной статье речь пойдет как раз об обратном: основное внимание уделено общим понятиям, а технические средства будут затронуты только в качестве примеров. Это позволит абстрагироваться от аппаратного и программного обеспечения и ответить на два главных вопроса: «Зачем мы это делаем?», «Можем ли мы это делать быстрее, дешевле и надежнее?».

Цели и задачи резервного копирования

В процессе организации резервного копирования ставятся две основные задачи: восстановление инфраструктуры при сбоях (Disaster Recovery) и ведение архива данных в целях последующего обеспечения доступа к информации за прошлые периоды.

Классическим примером резервной копии для Disaster Recovery является образ системной партиции сервера, созданный программой Acronis True Image.

Примером архива может выступить ежемесячная выгрузка баз данных из «1С», записанная на кассеты с последующим хранением в специально отведенном месте.

Есть несколько факторов, по которым отличают резервную копию для быстрого восстановления от архива:

• Период хранения данных. У архивных копий он достаточно длительный. В некоторых случаях регламентируется не только требованиями бизнеса, но и законодательно. У копий для аварийного восстановления он сравнительно небольшой. Обычно создают одну или две (при повышенных требованиях к надежности) резервные копии для Disaster Recovery c максимальным интервалом в сутки-двое, после чего они перезаписываются свежими. В особо критичных случаях возможно и более частое обновление резервной копии для аварийного восстановления, например, раз в несколько часов.
• Быстрота доступа к данным. Скорость доступа к длительно хранящемуся архиву в большинстве случаев не критична. Обычно необходимость «поднять данные за период» возникает в момент сверки документов, возврата к предыдущей версии и т.д., то есть не в аварийном режиме. Другое дело – аварийное восстановление, когда необходимые данные и работоспособность сервисов должны быть возвращены в кратчайшие сроки. В этом случае скорость доступа к резервной копии является крайне важным показателем.
• Состав копируемой информации. В архивной копии обычно содержатся только пользовательские и бизнес-данные за указанный период. В копии, предназначенной для аварийного восстановления, помимо этих данных, содержатся либо образы систем, либо копии настроек операционной системы и прикладного программного обеспечения, а также другой информации, необходимой для восстановления.

Иногда возможно совмещение этих задач. Например, годовой набор ежемесячных полных «снимков» файлового сервера, плюс изменения, сделанные в течении недели. В качестве инструмента для создания такой резервной копии подойдет True Image.

Самое главное – четко понимать, для чего делается резервирование. Приведу пример: вышел из строя критичный SQL-сервер по причине отказа дискового массива. На складе есть подходящее аппаратное обеспечение, поэтому решение проблемы состояло только в восстановлении программного обеспечения и данных. Руководство компании обращается с понятным вопросом: «Когда заработает?» – и неприятно удивляется, узнав, что на восстановление уйдет целых четыре часа. Дело в том, что на протяжении всего срока службы сервера регулярно осуществлялось резервное копирование исключительно баз данных без учета необходимости восстановить сам сервер со всеми настройками, включая программное обеспечение самой СУБД. Попросту говоря, наши герои сохраняли только базы данных, а про систему забыли.

Приведу другой пример. Молодой специалист на протяжении всего периода своей работы создавал посредством программы ntbackup одну-единственную копию файлового сервера под управлением Windows Server 2003, включая данные и System State [1] в общую папку другого компьютера. По причине дефицита дискового пространства эта копия постоянно перезаписывалась. Через некоторое время его попросили восстановить предыдущий вариант многостраничного отчета, который был поврежден при сохранении. Понятное дело, что, не имея архивной истории с выключенным Shadow Copy [2], он не смог выполнить этот запрос.

На заметку Shadow Copy, дословно – «теневая копия». Обеспечивает создание мгновенных копий файловой системы таким образом, что дальнейшие изменения оригинала никак не оказывают на них влияния. С помощью данной функции возможно создавать несколько скрытых копий файла за определенный период времени, а также на лету резервные копии файлов, открытых для записи. За работу Shadow Copy отвечает служба Volume Copy Shadow Service. System State, дословно – «состояние системы». Копирование System State создает резервные копии критических компонентов операционных систем семейства Windows. Это позволяет восстановить инсталлированную ранее систему после разрушения. При копировании System State происходит сохранение реестра, загрузочных и других важных для системы файлов, в том числе для восстановления Active Directory, Certificate Service database, COM+Class Registration database, SYSVOL-директории. В ОС семейства UNIX непрямым аналогом копирования System State является сохранение содержимого каталогов /etc, /usr/local/etc и других необходимых для восстановления состояния системы файлов.

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

При небольших объемах данных и не очень сложной ИТ-инфраструктуре можно попытаться совместить обе эти задачи в одной, например, делать ежедневное полное копирование всех дисковых разделов и баз данных. Но все же лучше различать две цели и подбирать под каждую из них правильное средство. Соответственно под каждую задачу используется свой инструмент, хотя есть и универсальные решения, как тот же пакет Acronis True Image [3] или программа ntbackup [4]

Понятно, что, определяя цели и задачи резервного копирования, а также решения для реализации, необходимо исходить из требований бизнеса.

При реализации задачи аварийного восстановления можно использовать разные стратегии.

В одних случаях необходимо прямое восстановление системы на «голое железо» (bare metal). Это можно выполнить, к примеру, с помощью программы Acronis True Image в комплекте с модулем Universal Restore. В этом случае конфигурацию сервера удается вернуть в строй за очень короткий срок. Например, раздел с операционной системой в 20 Гб вполне реально поднять из резервной копии за восемь минут (при условии, что архивная копия доступна по сети 1 Гб/с).

В другом варианте целесообразнее просто «вернуть» настройки на только что проинсталлированную систему, как, например, копирование в UNIX-подобных системах конфигурационных файлов из папки /etc и других (в Windows этому приблизительно соответствует копирование и восстановление System State). Конечно, при таком подходе сервер введется в работу не ранее, чем будет проинсталлирована операционная система и восстановлены необходимые установки, что займет гораздо более длительный срок. Но в любом случае решение, каким быть Disaster Recovery, проистекает из потребностей бизнеса и ресурсных ограничений.

Принципиальное отличие резервного копирования от систем избыточного резервирования

Это еще один интересный вопрос, который хотелось бы затронуть. Под системами избыточного резервирования оборудования подразумевается внесение некоторой избыточности в аппаратное обеспечение с целью сохранения работоспособности в случае внезапного выхода из строя одного из компонентов. Прекрасный пример в данном случае – RAID-массив (Redundant Array of Independent Disks). В случае отказа одного диска можно избежать потери информации и безопасно произвести замену, сохранив данные за счет специфичной организации самого дискового массива (подробнее о RAID читайте в [5]).

Мне доводилось слышать фразу: «У нас очень надежное оборудование, везде стоят RAID-массивы, поэтому резервные копии нам не нужны». Да, конечно, тот же самый RAID-массив убережет данные от разрушения при выходе из строя одного жесткого диска. Но вот от повреждения данных компьютерным вирусом или от неумелых действий пользователя это не спасет. Не спасет RAID и при крахе файловой системы в результате несанкционированной перезагрузки.

Кстати Важность отличия резервного копирования от систем избыточного резервирования следует оценивать еще при составлении плана копирования данных, касается ли это организации или домашних компьютеров. Спросите себя, зачем вы делаете копии. Если речь идет о резервном копировании, то подразумевается сохранение данных при случайном (умышленном) действии. Избыточное резервирование дает возможность сохранить данные, в том числе и резервные копии, при выходе оборудования из строя. Сейчас на рынке появилось множество недорогих устройств, обеспечивающих надежное резервирование с помощью RAID-массивов или облачных технологий (например, Amazon S3). Рекомендуется использовать одновременно оба вида резервирования информации. Андрей Васильев, генеральный директор компании Qnap Россия

Приведу один пример. Бывают случаи, когда события развиваются по следующему сценарию: при выходе диска из строя происходит восстановление данных за счет механизма избыточности, в частности, с помощью сохраненных контрольных сумм. При этом наблюдается значительное снижение быстродействия, сервер подвисает, управление практически потеряно. Системный администратор, не видя другого выхода, перезагружает сервер холодным перезапуском (попросту говоря, нажимает на «RESET»). В результате такой перегрузки «по живому» возникают ошибки файловой системы. Самое лучшее, чего можно ожидать в этом случае, – длительная работа программы проверки диска в целях восстановления целостности файловой системы. В худшем варианте придется попрощаться с файловой системой и озадачиться вопросом, откуда, как и в какие сроки можно восстановить данные и работоспособность сервера.

У вас не получится избежать резервного копирования и при наличии кластерной архитектуры. Отказоустойчивый кластер, по сути, сохраняет работоспособность вверенных ему сервисов при выходе из строя одного из серверов. В случае вышеперечисленных проблем, таких как, вирусная атака или повреждение данных из-за пресловутого «человеческого фактора», никакой кластер не спасет.

Единственное, что может выступить в качестве неполноценной замены резервного копирования для Disaster Recovery, – наличие зеркального резервного сервера с постоянным реплицированием данных с основного сервера на резервный (по принципу Primary  Standby). В этом случае при выходе из строя основного сервера его задачи будут подхвачены резервным, и даже не придется переносить данные. Но такая система является довольно дорогостоящей и трудоемкой при организации. Не забываем еще про необходимость постоянной репликации.

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

И уж, конечно, никакая система избыточного резервирования не решит задачу ведения архива данных в течение определенного периода.

Понятие «окно бэкапа»

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

Выход при решении этих вышеописанных проблем напрашивается сам собой: перенести запуск процесса создания копий на неактивный период времени, когда взаимное влияние резервного копирования и других работающих систем будет минимально. Этот временной период называется «окно бэкапа». Например, для организации, работающей по формуле 8х5 (пять восьмичасовых рабочих дней в неделю), таким «окном» обычно являются выходные дни и ночные часы.

Для систем, работающих по формуле 24х7 (всю неделю круглосуточно), в качестве такого периода используется время минимальной активности, когда нет высокой нагрузки на серверы.

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

Чтобы избежать излишних материальных затрат при организации резервного копирования, а также по возможности не выходить за рамки окна бэкапа, разработано несколько технологий backup, которые применяют в зависимости от конкретной ситуации.

Полное резервное копирование (или Full backup)

Является главным и основополагающим методом создания резервных копий, при котором выбранный массив данных копируется целиком. Это наиболее полный и надежный вид резервного копирования, хотя и самый затратный. В случае необходимости сохранить несколько копий данных общий хранимый объем будет увеличиваться пропорционально их количеству. Для предотвращения подобного расточительства используют алгоритмы сжатия, а также сочетание этого метода с другими видами резервного копирования: инкрементным или дифференциальным. И, конечно, полное резервное копирование незаменимо в случае, когда нужно подготовить резервную копию для быстрого восстановления системы с нуля.

Инкрементное копирование

В отличие от полного резервного копирования в этом случае копируются не все данные (файлы, сектора и т.д.), а только те, что были изменены с момента последнего копирования. Для выяснения времени копирования могут применяться различные методы, например, в системах под управлением операционных систем семейства Windows используется соответствующий атрибут файла (архивный бит), который устанавливается, когда файл был изменен, и сбрасывается программой резервного копирования. В других системах может использоваться дата изменения файла. Понятно, что схема с применением данного вида резервного копирования будет неполноценной, если время от времени не проводить полное резервное копирование. При полном восстановлении системы нужно провести восстановление из последней копии, созданной Full backup, а потом поочередно «накатить» данные из инкрементных копий в порядке их создания.

Для чего используется этот вид копирования? В случае создания архивных копий он необходим, чтобы сократить расходуемые объемы на устройствах хранения информации (например, сократить число используемых ленточных носителей). Также это позволит минимизировать время выполнения заданий резервного копирования, что может быть крайне важно в условиях, когда приходится работать в плотном графике 24х7 или прокачивать большие объемы информации.

У инкрементного копирования есть один нюанс, который нужно знать. Поэтапное восстановление возвращает и нужные удаленные файлы за период восстановления. Приведу пример. Допустим, по выходным дням выполняется полное копирование, а по будням инкрементное. Пользователь в понедельник создал файл, во вторник его изменил, в среду переименовал, в четверг удалил. Так вот при последовательном поэтапном восстановлении данных за недельный период мы получим два файла: со старым именем за вторник до переименования, и с новым именем, созданным в среду. Это произошло потому, что в разных инкрементных копиях хранились разные версии одного и того же файла, и в итоге будут восстановлены все варианты. Поэтому при последовательном восстановлении данных из архива «как есть» имеет смысл резервировать больше дискового пространства, чтобы смогли поместиться в том числе и удаленные файлы.

Дифференциальное резервное копирование

Отличается от инкрементного тем, что копируются данные с последнего момента выполнения Full backup. Данные при этом помещаются в архив «нарастающим итогом». В системах семейства Windows этот эффект достигается тем, что архивный бит при дифференциальном копировании не сбрасывается, поэтому измененные данные попадают в архивную копию, пока полное копирование не обнулит архивные биты.

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

Но дифференциальное копирование значительно проигрывает инкрементному в экономии требуемого пространства. Так как в каждой новой копии хранятся данные из предыдущих, суммарный объем зарезервированных данных может быть сопоставим с полным копированием. И, конечно, при планировании расписания (и расчетах, поместится ли процесс бэкапа во временное «окно») нужно учитывать время на создание последней, самой «толстой», дифференциальной копии.

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

Рассмотрим какие бывают схемы резервного копирования.

Децентрализованная схема

Ядром этой схемы является некий общий сетевой ресурс (см. рис. 1). Например, общая папка или FTP-сервер. Необходим и набор программ для резервного копирования, время от времени выгружающих информацию с серверов и рабочих станций, а также других объектов сети (например, конфигурационные файлы с маршрутизаторов) на этот ресурс. Данные программы установлены на каждом сервере и работают независимо друг от друга. Несомненным плюсом является простота реализации этой схемы и ее дешевизна. В качестве программ копирования подойдут штатные средства, встроенные в операционную систему, или программное обеспечение, такое как СУБД. Например, это может быть программа ntbackup для семейства Windows, программа tar для UNIX-like операционных систем или набор скриптов, содержащих встроенные команды SQL-сервера для выгрузки баз данных в файлы резервных копий. Еще одним плюсом является возможность использования различных программ и систем, лишь бы все они могли получить доступ к целевому ресурсу для хранения резервных копий.

Рисунок 1. Децентрализованная схема резервного копирования

Минусом является неповоротливость этой схемы. Так как программы установлены независимо друг от друга, то и настраивать приходится каждую по отдельности. Довольно тяжело учитывать особенности расписания и распределять временные интервалы, чтобы избежать конкуренции за целевой ресурс. Мониторинг также затруднен, процесс копирования с каждого сервера приходится отслеживать отдельно от других, что в свою очередь может привести к высоким трудозатратам.

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

Централизованное резервное копирование

В отличие от предыдущей схемы в этом случае используется четкая иерархическая модель, работающая по принципу «клиент-сервер». В классическом варианте на каждый компьютер устанавливаются специальные программы-агенты, а на центральный сервер – серверный модуль программного пакета. Эти системы также имеют специализированную консоль управления серверной частью. Схема управления выглядит следующим образом: с консоли создаем задания для копирования, восстановления, сбора информации о системе, диагностики и так далее, а сервер дает агентам необходимые инструкции для выполнения указанных операций.

Именно по такому принципу работает большинство популярных систем резервного копирования, таких как Symantec Backup Exec, CA Bright Store ARCServe Backup, Bacula и другие (см. рис. 2).

Рисунок 2. Централизованная схема резервного копирования

Помимо различных агентов для большинства операционных систем существуют разработки для резервного копирования популярных баз данных и корпоративных систем, например, для MS SQL Server, MS Exchange, Oracle Database и так далее.

Для совсем небольших компаний в некоторых случаях можно попробовать упрощенный вариант централизованной схемы резервного копирования без применения программ-агентов (см. рис. 3). Также эта схема может быть задействована, если не реализован специальный агент для используемого ПО резервного копирования. Вместо этого серверный модуль будет использовать уже существующие службы и сервисы. Например, «выгребать» данные из скрытых общих папок на Windows-серверах или копировать файлы по протоколу SSH c серверов под управлением UNIX-систем. Данная схема имеет весьма существенные ограничения, связанные с проблемами сохранения файлов, открытых для записи. В результате подобных действий открытые файлы будут либо пропущены и не попадут в резервную копию, либо скопированы с ошибками. Существуют различные методы обхода данной проблемы, например, повторный запуск задания с целью скопировать только ранее открытые файлы, но нет ни одного надежного. Поэтому такая схема подходит для применения только в определенных ситуациях. Например, в небольших организациях, работающих в режиме 5х8, с дисциплинированными сотрудниками, которые сохраняют изменения и закрывают файлы перед уходом домой. Для организации такой усеченной централизованной схемы, работающей исключительно в среде Windows, неплохо подходит ntbackup. При необходимости использовать подобную схему в гетерогенных средах или исключительно среди UNIX-компьютеров я рекомендую посмотреть в сторону Backup PC (см. [7]).

Рисунок 3. Упрощенная централизованная схема резервного копирования

Иногда организуют смешанную схему резервного копирования (см. рис. 4). Например, с серверов, для которых есть в наличии программы-агенты резервного копирования, данные собираются посредством этих агентов. Для всех остальных ресурсов используется децентрализованная схема, то есть когда локальные программы складывают копии данных на некий общий ресурс сервера с установленным агентом, и далее посредством этого агента информация заносится в общее хранилище резервных копий.

Рисунок 4. Смешанная схема резервного копирования

Что такое off-site?

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

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

Копирование данных в другое расположение по сетевому каналу. Например, с использованием VPN-туннеля через Интернет [8]. Плюсом в этом случае является то, что нет нужды везти куда-то носители с информацией, минусом – необходимость использования достаточного широкого канала (как правило, это весьма недешево) и защиты передаваемых данных (например, с помощью того же VPN). Возникающие сложности передачи больших объемов данных можно значительно снизить, используя алгоритмы сжатия или технологию дедупликации [9].

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

***

Мы разобрали основные моменты при организации резервного копирования. В следующей части будут рассмотрены методические рекомендации и приведены практические примеры для создания эффективной системы резервного копирования.

1. Описание резервного копирования в системе Windows, в том числе System State – http://www.datamills.com/Tutorials/systemstate/tutorial.htm.
2. Описание Shadow Copy – http://ru.wikipedia.org/wiki/Shadow_Copy.
3. Официальный сайт Acronis – http://www.acronis.ru/enterprise/products.
4. Описание ntbackup – http://en.wikipedia.org/wiki/NTBackup.
5. Бережной А. Оптимизируем работу MS SQL Server. //Системный администратор, №1, 2008 г. – С. 14-22 (http://samag.ru/archive/article/797).
6. Бережной А. Организуем систему резервного копирования для малого и среднего офиса. //Системный администратор, №6, 2009 г. – С. 14-23 (http://samag.ru/archive/article/2020).
7. Маркелов А. Linux на страже Windows. Обзор и установка системы резервного копирования BackupPC. //Системный администратор, №9, 2004 г. – С. 2-6 (http://samag.ru/archive/article/332).
8. Описание VPN – http://ru.wikipedia.org/wiki/VPN.
9. Дедупликация данных – http://en.wikipedia.org/wiki/Data_deduplication.

Facebook

Twitter

Мой мир

Вконтакте

Одноклассники

Google+

samag.ru

Типовой регламент резервного копирования данных

Содержание:

Термины

1. ГСА — группа системных администраторов, реализующие развитие и устранение ошибок в информационной системе заказчика.2. ГТП — группа технической поддержки — группа сотрудников, реализующие техническую поддержку сотрудников заказчика.3. ИТ система — набор аппаратных и программных средств компании заказчика, реализующие технологию совместной работы работников заказчика.4. Заявка — запрос работника предприятия в службу тех. поддержки на решение технической проблемы.5. Ресурс файлового сервера — это каталог на файловом сервере, для хранения данных с той целью, которой указано в заявки на реализацию данного ресурса.6. ИС «Helpdesk» — ИС, реализующая обработку и прием заявок работников заказчика.7. ИСМ — информационная система мониторинга ИТ системы заказчика.8. ЭЦП — электронная цифровая подпись.9. GPG — ПО для шифрования и ЭЦП информации.

Общее

Регламент реализации резервного копирования или восстановление информации и программ, которые хранятся на серверах ИТ-системы заказчика создан с целью:

• установления алгоритма резервирования информации для дальнейшего восстановление работоспособности системы при полной или частичной потери данных, связанных с отказами или сбоями программного или аппаратного обеспечения, ошибками пользователями и тд
• установления алгоритма восстановление данных при необходимости
• установление работы ответственных лиц, связанных с резервным копированием или восстановлением данных

Регламент определяет следующие действия:

• резервное копирование
• хранение резервных копий
• контроль такого копирования
• частичное или полное восстановление информации и программ

Резервное копирование работает со следующими типами информации:

• Персональные данные пользователей
• Данные нужные для восстановление серверов и СУБД
• личные профили сотрудников в сети
• рабочие копии установочных элементов ПО на АРМ (автоматизированное рабочее место)
• Информация автоматизированных систем

Носителям данных которые имеют резервные копии имеют гриф конфиденциальности.

Порядок резервного копирования

Резервное копирование в информационной системе реализуется на основе следующих аспектов:

• Объем и состав копируемой информации, периодичность проведения (табл.1)
• максимальный срок хранение резерв. копий — 1 месяц.
  • хранение 3-х следующих архивов
  • архив двух предыдущих дней в неделе
  • архив сделанный в текущую ночь
  • архив на 1-е число текущего месяца

Система резервного копирования должна поддерживать производительность, нужную для сохранения данных в установленные сроки с указанной периодичностью. Методика реализации резервного копирования показана в Методике резервного копирования (см. ниже).

Если выявлены попытки несанкционированного доступа к резервным данным, или нарушения процесса резервного копирования, выявивший сообщает служебной запиской службу информационной безопасности предприятия.

Контроль результатов резервного копирования

Контроль результатов всех мероприятий резервного копирования реализуется ответственным должностным лицом, указанным в табл.2 в срок до 17 часов рабочего дня. При обнаружении ошибок, лицо сообщает в ГТП до 18 часов текущего рабочего дня. На период времени, когда система резервного копирования не работает, должен реализовываться алгоритм ежедневного копирования данных, которая подлежит резервированию.

Ротация носителей резервной копии

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

Таблица 1 — Список резервируемых данных

# Адрес хранения данных Описание

1	\\server\SystemState	Состояние контроллера домена
2	\\server\c$	Системный диск контроллера домена
3	\\server\e$	файл-сервер, где находятся персональные данные пользователей и отделов

Таблица 2 — Список лиц ответственных за резервное копирование

# Роль ФИО ответственного сотрудника

1	Начальная настройка системы резервного копирования (реализация: расписаний, меда-сетов, оповещений). Запуск системы
2	Изменение настроек системы резервного копирования
3	Анализ логов резервного копирования, реализация ротирования носителей, анализ в нужде изменений настроек резерв. копирования
4	Ротировка носителей, проверка резервной копии, реализация хранения резервной копии вне предприятия на случай ЧП

Методика резервного копирования

Для реализации системы резервного копирования используется программное обеспечение фирмы ____ версии ___. с учетом пропускной способности каналов, объема резервируемых данных, реализуется оптимальная реализация резервного копирования. Для оптимизации расходов на систему резервного копирования, запись резервной копии реализуется на жесткий диск.

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

Конфигурация всех серверов одинакова. Для снижения общей нагрузки на информационную систему все процедуры по резервированию данных нужно проходить в ночное время. Есть три набора резервных копий:

• Ежедневная копия. Записывается ежесуточно, кроме ночи на субботу и ночи на среду. Срок хранения — сутки. Запись реализуется на съемный диск. Этот диск по отдельному расписанию выносится за пределы офиса или предприятия.
• Недельная копия. Записывается в ночь на субботу и на ночь среду. Срок хранения — субботняя копия — до следующей среды, вторичная копия — до субботы. Хранится на сервере.
• Месячный набор. Пишутся данные на первое число текущего месяца. Срок хранения — месяц. Хранится на сервере.

Есть три разных источника данных, подлежащей резервированию:

• Данные, хранимые в Exchange Server
• Данные, хранимые в файловой системе ОС
• Базы данных

Для резервного копирования данных, хранимой в Exchange Server, общие папки и почтовые ящики, используют ПО _____ с установленным Exchange агентом, с помощью которого создаются задания на реализацию резервного копирования данных, которые находятся на хранилищах сервера.

infoprotect.net

404 Not Found

• Город
  • Паспорт города
    • История
    • Символика
    • Структура, полномочия администрации города Ставрополя
    • Приоритеты
  • Жизнь города
    • Фотогалерея
    • Новости города
    • Анонсы и события
    • Мероприятия комитета культуры
  • Безопасность
    • Телефоны доверия
    • Защита населения
    • Служба спасения
    • Общественная безопасность
      • Отдел по противодействию терроризма и взаимодействию с правоохранительными органами
      • Отдел по вопросам национально-культурного развития на территории города Ставрополя
    • Защита персональных данных
      • Документы, регламентирующие защиту персональных данных
    • Отдел надзорной деятельности по городу Ставрополю управления надзорной деятельности и профилактической работы Главного управления МЧС России по СК
    • Безопасность дорожного движения
  • Открытые данные
    • Открытый бюджет для граждан
    • Генеральный план
    • ГКУ "Центр занятости населения города Ставрополя"
  • Социальная сфера
    • Образование
    • Социальная защита
    • Cоциальные программы и проекты
    • Меры социальной поддержки населения и порядок их предоставления
      • Основная информация
      • Новости комитета
      • Меры социальной поддержки населения и порядок их предоставления
      • Государственные и муниципальные услуги в электронном виде
      • Общие данные
      • Cоциальные программы и проекты
      • Форма обратной связи с гражданами по вопросам неформальной занятости
      • Антикоррупционная деятельность
      • Перечень проверок
      • Сведения о доходах, об имуществе и обязательствах имущественного характера муниципальных служащих комитета
      • Кадровый резерв для замещения вакантных должностей в комитете труда и социальной защиты населения администрации города Ставрополя
      • Показатели деятельности комитета
      • Защита персональных данных
    • Информация для населения
    • Общие данные
    • Пенсионный фонд
    • Форма обратной связи с гражданами по вопросам неформальной занятости
    • Реестр социально ориентированных НКО – получателей поддержки, за счет средств местного бюджета
    • Советы ветеранов города Ставрополя
      • Городской Совет Ветеранов
      • Совет Ветеранов Ленинского района
      • Совет Ветеранов Октябрьского района
      • Совет Ветеранов Промышленного района
  • Торговля и муниципальный заказ
    • Кадровое обеспечение
  • ЖКХ
    • Азбука ЖКХ
    • Информация для населения
    • План проведения плановых проверок юр.лиц и ИП
    • Конкурс "Лучшая управляющая организация в г.Ставрополе"
    • Реестр ТСЖ и ЖСК
    • Реестр управляющих организаций, получивших лицензию
    • Реестр управляющих компаний
    • Развитие жилищно-коммунального хозяйства
    • Консультация граждан по жилищным вопросам
    • График плановых отключений горячей воды
    • Пассажирские перевозки города
    • Формирование современной городской среды
    • Дорожное хозяйство города
    • Благоустройство и санитарная очистка города
    • Ресурсоснабжение города
    • Озеленение города
    • Переселение граждан из аварийного жилищного фонда
    • Учет граждан, нуждающихся в жилых помещениях
    • Обеспечение жильем молодых семей в городе Ставрополе
    • Информация о результатах внутренних и внешних проверок органа местного самоуправления
    • Приватизация жилищного фонда в г.Ставрополе
  • СМИ города
  • Консультации для граждан
  • Международное и межрегиональное сотрудничество
    • Межмуниципальное сотрудничество
    • Сотрудничество с международными, общероссийскими, региональными объединениями муниципальных образований и другими организациями
    • English version
  • Документы территориального планирования
• Экономика
  • Экономика
  • Документы стратегического планирования
  • Информация для предпринимателей
  • Взаимодествие со Ставропольстат
  • Взаимодействие с налоговыми органами
  • Список крупных предприятий города
  • Инвестиционная деятельность
  • Общественные обсуждения проектов документов
  • Туризм
    • Гостиницы
    • Турагенства
    • Перечень объектов культурного наследия
    • Интересные места города Ставрополя
    • Информация о состоянии туристической отрасли в городе Ставрополе
    • Инвестиционные проекты в сфере туризма
  • Внедрение стандарта развития конкуренции
• Администрация
  • Глава города Ставрополя Джатдоев Андрей Хасанович
    • Отдел учета и отчетности
    • Комитет правового обеспечения деятельности
    • Управление кадровой политики
    • Отдел пресс-службы
    • Отдел приема граждан
    • Организационный отдел
  • Первый заместитель главы администрации
    • Комитет градостроительства
      • Глава города Ставрополя Джатдоев Андрей Хасанович
      • Первый заместитель главы администрации Толбатов Андрей Владимирович
      • Первый заместитель главы администрации Мясоедов Александр Александрович
      • Заместитель главы администрации Середа Татьяна Викторовна
      • Заместитель главы администрации Алпатов Денис Валерьевич
      • Заместитель главы администрации Савельева Татьяна Васильевна
    • Комитет экономического развития
    • Комитет финансов и бюджета
    • Комитет муниципального заказа и торговли
    • Многофункциональный центр предоставления государственных и муниципальных услуг в городе Ставрополе
    • Управление международных и межрегиональных связей
  • Первый заместитель главы администрации Мясоедов Александр Александрович
    • Комитет городского хозяйства
    • Администрация Ленинского района
      • Глава района
      • Микрорайоны
      • Органы охраны правопорядка и законности
      • Районные организации и предприятия
      • Типовые формы заявлений
      • Резерв управленческих кадров
      • Конкурс на замещение вакантной должности муниципальной службы
      • Противодействие коррупции
      • Информационный раздел
      • Новости и события
      • Новые новости
      • ТИК Ленинского района
      • Территориальное общественное самоуправление
      • График приема граждан
      • Районные конкурсы
    • Администрация Октябрьского района
      • Глава района
      • Органы охраны правопорядка и законности
      • Микрорайоны
      • Новости Октябрьского района
      • Совет ветеранов Октябрьского района
      • Районные организации и предприятия
      • Резерв управленческих кадров
      • Конкурс на замещение вакантной должности муниципальной службы
      • Территориальное общественное управление
      • Антикоррупционная деятельность
      • Типовые формы заявлений
      • ТИК Октябрьского района г. Ставрополя
      • Информационный раздел
    • Администрация Промышленного района
      • Глава района
      • Советы микрорайонов
      • Органы охраны правопорядка и законности
      • Районные организации и предприятия
      • Опека и попечительство
      • Типовые формы заявлений
      • Резерв управленческих кадров
      • Информационный раздел
      • Новости Промышленного района
      • Новые новости Промышленного района
      • Конкурс на замещение вакантной должности муниципальной службы
      • Территориальное общественное управление
      • Антикоррупционная деятельность
    • Комитет по управлению муниципальным имуществом
  • Заместитель главы администрации Середа Татьяна Викторовна
    • Отдел социальных программ и проектов
    • Комитет труда и социальной защиты населения
      • Основная информация
      • Новости комитета
      • Меры социальной поддержки населения и порядок их предоставления
      • Государственные и муниципальные услуги в электронном виде
      • Общие данные
      • Cоциальные программы и проекты
      • Форма обратной связи с гражданами по вопросам неформальной занятости
      • Антикоррупционная деятельность
      • Перечень проверок
      • Сведения о доходах, об имуществе и обязательствах имущественного характера муниципальных служащих комитета
      • Кадровый резерв для замещения вакантных должностей в комитете труда и социальной защиты населения администрации города Ставрополя
      • Показатели деятельности комитета
      • Защита персональных данных
    • Комитет образования
    • Комитет культуры и молодежной политики
    • Комитет физической культуры и спорта администрации города Ставрополя
  • Заместитель главы администрации Алпатов Денис Валерьевич
    • Комитет общественной безопасности
    • Комитет по делам гражданской обороны и чрезвычайным ситуациям
  • Заместитель главы администрации
    • Комитет информационных технологий
    • Управление делопроизводства и архива
      • Управление делопроизводства и архива
      • Архивный отдел
    • Муниципальное казенное учреждение «Хозяйственное управление администрации города Ставрополя»
• Функции
  • Муниципальные услуги
  • Муниципальный контроль
    • Муниципальный контроль в сфере торговли
    • Муниципальный контроль в сфере установления цен
    • Муниципальный контроль в сфере распространения наружной рекламы
    • Муниципальный лесной контроль
    • Муниципальный контроль в сфере озеленения
    • Муниципальный контроль в сфере дорог
    • Муниципальный жилищный контроль
    • Муниципальный земельный контроль
  • Антикоррупционная деятельность
    • Противодействие коррупции
    • Нормативные правовые и иные акты в сфере противодействия коррупции
    • Антикоррупционная экспертиза
    • Методические материалы
    • Формы документов, связанных с противодействием коррупции, для заполнения
    • Сведения о доходах, расходах, об имуществе и обязательствах имущественного характера
    • Комиссия по соблюдению требований к служебному поведению и урегулированию конфликта интересов
    • Обратная связь для сообщений о фактах коррупции
  • Результаты проверок
  • Подведомственные организации
  • Кадровое обеспечение
    • Нормативно-правовые акты по вопросам проведения конкурса и отбора в кадровый резерв
    • Порядок поступления на муниципальную службу
    • Вакансии
    • Кадровые резервы
    • Объявления о проведении отбора претендентов в кадровый резерв
    • Результаты проведения отбора претендентов в кадровый резерв
    • Объявления о проведении конкурсов
    • Результаты проведения конкурсов
    • Аттестация
    • Награждения
      • Нормативно-правовые акты по вопросам награждения
      • Архив награждений
  • Нормотворческая деятельность
    • Нормативные правовые акты
    • Проекты нормативных правовых актов
    • Проекты муниципальных программ
      • Нормативные правовые акты
      • Проекты нормативных правовых актов
      • Проекты муниципальных программ
      • Общественные обсуждения проектов правовых актов
      • Порядок обжалования правовых актов главы города Ставрополя, администрации города Ставрополя и ее должностных лиц
      • Оценка регулирующего воздействия
      • Информация о результатах мониторинга нормативных правовых актов администрации города Ставрополя
    • Общественные обсуждения проектов правовых актов
      • Нормативные правовые акты
      • Проекты нормативных правовых актов
      • Проекты муниципальных программ
      • Общественные обсуждения проектов правовых актов
      • Порядок обжалования правовых актов главы города Ставрополя, администрации города Ставрополя и ее должностных лиц
      • Оценка регулирующего воздействия
      • Информация о результатах мониторинга нормативных правовых актов администрации города Ставрополя
    • Порядок обжалования правовых актов главы города Ставрополя, администрации города Ставрополя и ее должностных лиц
      • Нормативные правовые акты
      • Проекты нормативных правовых актов
      • Проекты муниципальных программ
      • Общественные обсуждения проектов правовых актов
      • Порядок обжалования правовых актов главы города Ставрополя, администрации города Ставрополя и ее должностных лиц
      • Оценка регулирующего воздействия
      • Информация о результатах мониторинга нормативных правовых актов администрации города Ставрополя
      • Сведения о судебных постановлениях по делам о признании недействующими правовых актов, изданных главой города Ставрополя
    • Оценка регулирующего воздействия
    • Экспертиза действующих нормативных правовых актов
    • Информация о результатах мониторинга нормативных правовых актов администрации города Ставрополя
      • Нормативные правовые акты
      • Проекты нормативных правовых актов
      • Проекты муниципальных программ
      • Общественные обсуждения проектов правовых актов
      • Порядок обжалования правовых актов главы города Ставрополя, администрации города Ставрополя и ее должностных лиц
      • Оценка регулирующего воздействия
      • Информация о результатах мониторинга нормативных правовых актов администрации города Ставрополя
  • Документы и отчеты органов администрации
    • Документы органов администрации
  • Аукционы и конкурсы

• Важные ссылки
  • Куда обратиться
    • Интернет-приемная (создать обращение)
    • Информация о порядке записи на прием
    • Установленные формы обращений
    • Обзоры обращений граждан
  • Прием граждан
  • Народный контроль Ставропольского края
  • Канал прямой связи инвесторов с руководством города Ставрополя
  • Торговый реестр
  • Внимание, розыск!
• Сервисы
  • Интерактивные карты
  • Для арендаторов земель и муниципального имущества

    Сервис для арендаторов земель/помещений (КУМИ)

  • Канал прямой связи инвесторов с руководством города Ставрополя
  • Ставрополь глазами горожан
  • Экстремальный маршрут
  • Опросы
• Онлайн - опросы

xn--80ae1alafffj1i.xn--p1ai

НОУ ИНТУИТ | Лекция | Служба резервного копирования

Аннотация: В этой лекции вводятся понятия, и разбираются на примерах темы архивирования и восстановления системы. При архивировании и восстановлении системы используются стандартные утилиты Windows Server 2003. Приводятся задачи сетевого администратора связанные с сохранением, архивированием информации, и ее последующем восстановлении

Ни один носитель информации не является абсолютно надежным, из строя может выйти любое устройство хранения данных, и данные могут быть потеряны. Кроме аппаратных сбоев возможна также потеря данных по причине действия вредоносных программ (вирусы, "троянские кони" и т.д.). А самая распространенная причина порчи или удаления данных — ошибки пользователей (как обычных, так и администраторов), которые могут по ошибке удалить или перезаписать не тот файл.

По этой причине возникает необходимость регулярного создания резервных копий информации — файлов с документами, баз данных и состояния операционной системы.

Системы семейства Windows Server имеют встроенный инструмент создания резервных копий — утилиту ntbackup. Данная утилита позволяет сохранять резервные копии на самых различных носителях — ленточных накопителях, магнитооптических дисках, жестких дисках (как на локальных дисках данного сервера, так и на сетевых ресурсах, размещенных на других компьютерах сети). В версии системы Windows 2003 реализован механизм т.н. теневых копий ( Shadow Copy ), который заключается в том, что в начале процедуры архивации система делает моментальный "снимок" архивируемых файлов и уже после этого создает резервную копию из этого снимка. Данная технология позволяет архивировать файлы, которые в момент запуска утилиты ntbackup были открыты пользователями.

Сетевой администратор должен совместно с пользователями определить те данные, которые нужно регулярно архивировать, спланировать ресурсы, необходимые для создания резервных копий, составить расписание резервного копирования, настроить программу резервного копирования и планировщик заданий для автоматического создания резервных копий. Кроме этого, в задачу сетевого администратора входит также регулярное тестирование резервных копий и пробное восстановление данных из резервных копий (чтобы вовремя обнаружить возникающие проблемы в создании резервных копий).

В данном разделе описаны технологии создания резервных копий средствами системы Windows Server, даны рекомендации по планированию и настройке службы резервного копирования.

12.1 Архивирование и восстановление файловых ресурсов

Базовые понятия службы резервного копирования

Системы семейства Windows не содержат компоненты резервного копирования в смысле системной службы ( service ). Все операции по созданию резервных копий и восстановлению данных осуществляются утилитой ntbackup. Эту утилиту можно запустить из Главного меню системы (кнопка " Пуск " — " Все программы " — " Стандартные " — " Служебные " — " Архивация данных "), а можно запустить более быстро из командной строки (кнопка " Пуск " — " Выполнить " — " ntbackup " — кнопка " ОК "). При первом запуске утилиты рекомендуем убрать галочку у поля " Всегда запускать в режиме мастера ".

Рассмотрим основы резервного копирования файловых ресурсов.

Каждый файл, хранящийся на диске компьютера, независимо от типа файловой системы, имеет атрибут archive, который в Свойствах файла отображается как " Файл готов для архивирования " (откройте Свойства файла и нажмите кнопку " Другие "). Если в Свойствах файла вручную убрать галочку у этого атрибута, то при любом изменении в файле операционная система автоматически снова установит этот атрибут. На использовании изменений данного атрибута основаны все используемые в системе Windows методики резервного копирования.

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

Утилитой ntbackup можно создавать резервные копии различных типов. Рассмотрим их отличительные особенности и различные варианты их применения.

Обычный (Normal)

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

Разностный (Differential)

При выполнении Разностного архивирования утилита ntbackup из файлов, отмеченных для архивирования, архивирует только те, у которых установлен атрибут " Файл готов для архивирования ", при этом данный атрибут не очищается. Использование Обычного и Разностного архивирования позволяет сэкономить пространство на носителях с резервными копиями и ускорить процесс создания ежедневных копий. Например, если раз в неделю (как правило, в выходные дни) создавать Обычные копии, а в течение недели ежедневно (как правило, в ночное время) — Разностные, то получается выигрыш в объеме носителей для резервного копирования. При такой комбинации архивирования "Обычный + Разностный" процесс восстановления данных в случае утери информации потребует выполнения двух операций восстановления — сначала из последней Полной копии, а затем из последней Разностной резервной копии.

Добавочный (Incremental)

При выполнении Добавочного архивирования утилита ntbackup из файлов, отмеченных для архивирования, архивирует только те, у которых установлен атрибут " Файл готов для архивирования ", при этом данный атрибут очищается. Использование Обычного (раз в неделю по выходным) и Добавочного (ежедневно в рабочие дни) архивирования также позволяет сэкономить пространство на носителях с резервными копиями и ускорить процесс создания ежедневных копий. Но процесс восстановления данных при использовании комбинации "Обычный + Добавочный" уже будет выполняться иначе: в случае утери информации для восстановления данных потребуется сначала восстановить данные из последней Полной копии, а затем последовательно из всех Добавочных копий, созданных после Полной копии.

Копирующий (Copy)

При таком типе архивирования утилита ntbackup заархивирует все отмеченные файлы, при этом атрибут " Файл готов для архивирования " остается без изменений.

Ежедневный (Daily)

Ежедневный тип архивирования создает резервные копии только тех файлов, которые были модифицированы в день создания резервной копии.

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

Разработка и реализация стратегии резервного копирования

Понятие плана архивации

Создание и реализация плана архивации и восстановления информации — непростая задача. Сетевому администратору надо определить, какие данные требуют архивации, как часто проводить архивацию и т. д.

При создании плана ответьте на следующие вопросы:

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

Для построения правильной и эффективной системы резервного копирования необходимо детально изучить и задокументировать все файловые ресурсы, используемые в компании, а затем тщательно спланировать стратегию резервного копирования и реализовать ее в системе. Для планирования стратегии необходимо ответить на следующие вопросы:

• какие именно ресурсы будут архивироваться;
• минимальный промежуток времени для восстановления данного ресурса при возникновении аварии;
• какой объем данных будет архивироваться;
• какова емкость носителей для хранения резервных копий и скорость записи на эти носители;
• сколько времени будет занимать архивирование каждого ресурса;
• как часто будет производиться архивация каждого ресурса;
• если резервные копии записываются на ленты, то как часто будет производиться перезапись лент;
• по какому графику будет производиться тестовое восстановление данных.

При ответе на эти вопросы будет спланирована потребность в количестве и емкости накопителей и устройств для выполнения резервных копий, требования к пропускной способности сети для создания резервных копий, график выполнения резервного копирования, план восстановления на случай аварии.

Выбор архивных устройств и носителей

Определив, какие данные и как часто архивировать, можно выбрать аппаратные средства архивации и необходимые носители. Инструментов для архивации данных множество. Одни быстрые и дорогие, другие — медленные и надежные. Выбор подходящего оборудования для организации зависит от многих факторов.

• Емкость — количество регулярно архивируемых данных. Справится ли оборудование с нагрузкой в отведенное время?
• Надежность аппаратных средств и носителей. Можете ли вы пожертвовать надежностью ради экономии или скорости?
• Расширяемость решения. Удовлетворяет ли ваше решение потребностям роста организации?
• Скорость архивации и восстановления. Можете ли вы пожертвовать скоростью ради снижения стоимости?
• Цена архивации. Приемлема ли она для вашего бюджета?

Типовые решения архивации

Итак, на план архивации влияют емкость, надежность, расширяемость, скорость и цена. Определив, какие из этих факторов наиболее важны для вашей организации, вы примете подходящее решение. Вот некоторые общие рекомендации:

• Ленточные накопители — самые распространенные устройства архивации. Данные хранятся на кассетах с магнитной лентой. Лента относительно недорога, но не особенно надежна: она может помяться или растянуться, с течением времени — размагнититься и перестать считываться. Средняя емкость кассет с лентой варьируется от единиц до десятков Гбайт. По сравнению с другими решениями ленточные накопители довольно медленны. Их достоинство — невысокая цена.
• Накопители на цифровой ленте (digital audio tape, DAT) — пришли на смену традиционным ленточным накопителям. Существует несколько форматов DAT. Наиболее часто используются ленты DLT ( Digital Linear Tape ) и Super DLT. Ленты DLT IV обладают емкостью 35-40 Гбайт без сжатия и 70-80 Гбайт со сжатием. В крупных организациях иногда разумнее применять ленты LTO ( Linear Таре Open ) или AIT ( Advanced Intelligent Tape ). Обычно объем лент LTO составляет 100 Гбайт без сжатия и 200 Гбайт со сжатием. Для лент AIT-3 соответствующие емкости составляют 100 и 260 Гбайт.
• Ленточная библиотека с автозагрузкой — устройство для создания расширенных архивных томов на нескольких лентах, которых хватает для нужд всего предприятия. Ленты набора в процессе архивации или восстановления данных автоматически меняются. В большинстве таких библиотек применяются DAT-ленты. Их главный "минус" — высокая цена.
• Магнитооптические накопители с автозагрузкой подобны ленточным библиотекам, только вместо лент в них используются магнитооптические диски. Цена также очень высока.
• Съемные диски, например Iomega Jazz емкостью 1-2 Гбайт, все чаще используются в качестве устройств архивации. Они обладают хорошей скоростью и удобны в работе, но стоят дороже ленточных или DAT-накопителей.
• Дисковые накопители обеспечивают наивысшую скорость при архивации и восстановлении файлов. Если при архивации на ленту вам потребуются часы, то дисковый накопитель позволяет завершить процесс за несколько минут. К недостаткам дисковых накопителей следует отнести относительно высокую цену.

При установке устройств архивации необходимо указать ОС контроллеры и драйверы, используемые накопителями.

www.intuit.ru

Автоматизация настройки резервного копирования MS SQL с помощью .NET приложения

Я долго созревал, чтобы написать данную статью и выложить свое приложение. Надеюсь вам будет интересно.

О чем данная статья

В ней описан тот способ, как с помощью разработанного мною .NET приложения можно распространять план резервного копирования и проводить все необходимые настройки над БД средствами СУБД с уведомлением администратора о выполнении задач.

По максимум постараюсь описать те нюансы, с которыми мне пришлось столкнуться в ходе разработки приложения и настройки БД. Для описанных ниже задач можно использовать мастер планов обслуживания, но мне больше понравился такой подход. Основное преимущество описанного мною метода, что данный способ можно применять ко всем версиям MS SQL (кроме Express, там немного другой подход). План обслуживания можно переносить, но у вас должна быть соответствующая в версия MS SQL и все равно будет создан Job для запуска плана обслуживания.

Сравнить редакции MS SQL и их функционал вы можете вот здесь. Осторожно: перфекционисты могут испытать жжение и боль при просмотре кода моего приложения, т.к. оно было написано на скорую руку и заточено под решение конкретной задачи.

Кому подойдет данная статья:

• Тем, у кого MS SQL Express и нет возможности запускать с помощью Job задачи
• Тем, кто в ближайшем будущем планирует перейти с MS SQL 2008 на более новую версию и не хочет настраивать зеркалирование БД, а сразу на новой версии настроить AlwaysOn
• Тем, у кого нет средств для поднятия еще резервных серверов и приходится обходиться тем, что есть.
• У кого нет сжатых сроков на время восстановления БД. Главное – это результат
• Кому лень что-то делать
• Просто любопытным людям.

Оглавление:

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

1. Журнал транзакций
2. Разностная копия БД
3. Системные базы данных
4. План бекапирования
5. Общие рекомендации по резервному копированию

Используем приложение

1. Настройка уведомления администратора
2. Дополнительные уведомления для администратора
3. Решение проблем при настройке DatabaseMail
4. Настраиваем резервное копирование с помощью приложения для SQL Standart
5. Настраиваем резервное копирование с помощью приложения для SQL Express
6. Удаление задач из БД
7. Удаление копий БД

Как восстанавливать резервные копии

Список статей хабра, которые я использовал

1. Создание и хранение резервных копий баз данных в MS SQL. Практические советы
2. Построение цепочки восстановлений баз данных MS SQL
3. Настройка Database Mail в MS SQL Server 2005 и старше
4. SQL Server 2008: бэкапим с умом. Часть 1: Теория
5. Всё что вы стеснялись спросить о бэкапах Microsoft SQL Server

Исходники на github для MS SQL Standart и для MS SQL Express Если появится желающие добавить свои мысли в код, принимаю pull request. Готов выслушать конструктивную критику и доработать приложение, если это действительно кому-то нужно будет.

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

Все что описано в теории, вы можете найти самостоятельно. Конфигурации, которые описаны в данном разделе, автоматически будут выполнены моим приложением при настройке резервного копирования. MS SQL Server поддерживает 3 модели резервного копирования.

1. Простую
2. Модель полного восстановление
3. Модель полного восстановления с неполным протоколированием

Я выбрал для приложения модель полного восстановления, т.к. мне необходимо было иметь возможность всегда восстановить последнюю версию БД после любой операции и у меня не было одномоментных массовых операций по вставке данных. Если вы только начинаете и не знаете, как правильно выбрать, вам может помочь вот эта статья Microsoft. Для включения данного режима, необходимо выполнить следующий скрипт ALTER DATABASE [Имя базы данных] SET RECOVERY FULL;

При переключении модели восстановления на полную у нас появится следующие возможности:

1. СУБД перестанет автоматически очищать журнал транзакций . Журнал будет расти до тех пор, пока не будет сделана его резервная копия. Это важный момент, администратору БД необходимо продумать вопрос о плане резервного копирования и очистки журнала. UPD: спасибо за помощь Yggaz
2. Создание разностной резервной копии
3. Создание полной резервной копии

Ниже будут описаны некоторые нюансы, связанные с резервным копирование журналов транзакций и разностный копий. По поводу полного копирования у меня замечаний никаких нет, просто делайте ее периодически и все у вас будет хорошо

1. Журнал транзакций

Журнал транзакций является критическим компонентом базы данных и в случае системного сбоя может потребоваться для приведения базы данных в согласованное состояние.

Преимущества при восстановлении БД с помощью журнала транзакций:

1. восстановление отдельных транзакций;
2. восстановление всех незавершенных транзакций при запуске SQL Server;
3. накат восстановленной базы данных, файла, файловой группы или страницы до момента сбоя и т.д

Рекомендации

1. Вынести на быстрый жесткий диск, чтобы при большом потоке операций не было задержек при записи.
2. Необходимо делать резервные копии журнала транзакций не реже чем каждый час.
3. После создания полной (разностной) копии базы данных, все старые журналы можно удалять, т.к. они теряют свою актуальность.
4. Внимательно следите за размером диска на котором хранятся журналы транзакций, если оно закончится, то записать новые данные в БД будет невозможно, пока не произойдет уменьшение размеров журнала транзакций или не добавиться новый дополнительный файл транзакций.
5. Журнал транзакций необходимо регулярно усекать, чтобы избежать его переполнения. UPD: Как сказал kolu4iy данная операция по усечению слегка сомнительна в плане производительности, т.к. при бэкапирование журнал транзакции очищается внутри и СУБД начинает писать в нем по новой. Однако у вас может возникнуть ситуация, которую описал я в своем комментарии и тогда это вам может пригодиться.
6. Возможна ситуация, когда невозможно сразу сделать усечение журнала. Они описаны в данной статье
7. Для получения информации о состоянии базы данных можно с помощью следующего запроса: select name,log_reuse_wait, log_reuse_wait_desc from sys.databases
8. При необходимости можно получить информацию о последних открытых транзакциях DBCC OPENTRAN (Имя базы данных) WITH TABLERESULTS

Пример SQL скрипта для выполнения резервного копирования журнала транзакции с последующим усечением файла.BACKUP LOG [Имя базы данных] TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL\MSSQL\Backup\[Имя файла].bak' WITH NOFORMAT, NOINIT, NAME = N'Журнал транзакций Резервное копирование', SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO USE [Имя базы данных] GO DBCC SHRINKFILE (N'Имя файла лога БД' , 25) GO Эти же операции можно проделать с помощью SSMS

2.Разностная копия БД

Разностное резервное копирование основано на самой последней предыдущей полной резервной копии данных. В разностной резервной копии сохраняются только те изменения, которые были произведены с момента создания последней полной резервной копии. Рекомендации:

1. Используйте разностные копии БД, если создание полной копии БД занимает большой промежуток времени
2. Периодически делайте полную копию БД, чтобы уменьшить объемы создаваемых разностных копий.
3. После создания полной копии БД, все предыдущие разностные копии теряют свою актуальность.

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

Приведу небольшой пример из практики, почему мы стали использовать разностную копию. Со временем у нашего клиента разрослась база данных до таких размеров, что создание полной резервной копии занимало 8 часов, еще несколько месяцев и возможно к началу рабочего дня не успевало бы завершиться данная операция. После перевода на разностное резервное копирование, мы сократили время с 8 часов до 2-4 минут (в зависимости от дня недели). Раз в неделю мы делали полную копию БД.

Пример SQL для создания резервной разностной копии БД с проверкой копии по завершению (отличается от полного копирования флагом DIFFERENTIAL вместо него нужно использовать NOFORMAT).

declare @pathBackup as varchar(55) set @pathBackup = N'C:\Backup\[Имя файла БД]_' + REPLACE(convert(varchar,GETDATE(), 104),'.','_') + '.bak' BACKUP DATABASE [Имя базы данных] TO DISK = @pathBackup WITH DIFFERENTIAL, NOFORMAT, INIT, NAME = N'Полная База данных Резервное копирование', SKIP, NOREWIND, NOUNLOAD, STATS = 10, CHECKSUM GO declare @backupSetId as int declare @pathBackup as varchar(55) set @pathBackup = N'C:\Backup\[Имя файла БД]_' + REPLACE(convert(varchar,GETDATE(), 104),'.','_') + '.bak' select @backupSetId = position from msdb..backupset where database_name=N'[Имя базы данных]' and backup_set_id=(select max(backup_set_id) from msdb..backupset where database_name=N'[Имя базы данных]') if @backupSetId is null begin raiserror(N'Ошибка верификации. Сведения о резервном копировании для базы данных "[Имя базы данных]" не найдены.', 16, 1) end RESTORE VERIFYONLY FROM DISK = @pathBackup WITH FILE = @backupSetId, NOUNLOAD, NOREWIND GO

3.Системные базы данных

Помимо основной базы и связанных с ней файлов, я настоятельно рекомендую делать копии и системных баз данных. Начнем с того, что рассмотрим какие базы существуют в MS SQL. Их всего 5:

Название	Описание
База данных master	В этой базе данных хранятся все данные системного уровня для экземпляра SQL Server.
База данных msdb	Используется агентом SQL Server для планирования предупреждений и задач.
База данных model	Используется в качестве шаблона для всех баз данных, создаваемых в экземпляре SQL Server. Изменение размера, параметров сортировки, модели восстановления и других параметров базы данных model приводит к изменению соответствующих параметров всех баз данных, создаваемых после изменения.
База данных resource	База данных только для чтения. Содержит системные объекты, которые входят в состав SQL Server. Системные объекты физически хранятся в базе данных Resource, но логически отображаются в схеме sys любой базы данных.
База данных tempdb	Рабочее пространство для временных объектов или взаимодействия результирующих наборов.

Более подробно можете прочитать о них тут и еще вот тут.

Я выбрал резервировать только 2 системные БД:

1. msdb – потому что, там хранятся настроенные задачи и другие
2. master – хранятся все произведенные настройки SQL Server.

Данная информация все равно не сильно критична и ее можно восстановить руками, но зачем тратить лишнее время, когда можно просто взять из резервной копии.

4. План бекапирования

На основе выше описанного составим наш план резервного копирования данных. Он может отличаться от того, что потребуется вам, все зависит от требований к восстановлению БД. Когда я подготавливал план, мне пришлось учесть, что необходимо восстановить данные максимально и потеря данных составляла не больше одного часа.

Мы будем делать следующие резервные копии:

• Полная копия основной БД, чаще чем раз в неделю нет необходимости
• Разностная копия основной БД, каждый день
• Копии журнала транзакций основной БД, каждый час
• Копия системной БД master, раз в неделю
• Копия системной БД msdb, раз в неделю

В итоге у нас получился следующий план резервного копирования данных:

День недели	Время	Действия	Частота	Описание
Понедельник — Пятница	С 8-00 до 21-00	Резервные копии Журнала транзакций	Каждый час	После выполнения резервной копии БД идет сжатие и усечение журнала транзакций
Суббота — Воскресенье	С 8-00 до 18-00
Понедельник – Воскресенье	22-00	Разностная копия основной БД	1 раз в день	После успешного выполнения разностной копии удаляются все старые копии журнала транзакций
Суббота	12-00	Проверка БД	1 раз в день	Проверка БД Дело на целостность.
Суббота	18-00	Создание полной копии БД	1 раз в день	По завершению данной операции идет уведомление на почту.   Если создание резервной копии прошло удачно, удаляется старая полная резервная копия все старые разностные копии все старые журналы транзакций
Понедельник – Воскресенье	23-30	Создание копии системной базы master	1 раз в день	Хранится всегда только последний экземпляр БД
Воскресенье	12-30	Создание копии системной базы msdb	1 раз в месяц	Хранится всегда только последний экземпляр БД

5. Общие рекомендации по резервному копированию

1. Используйте опцию BACKUP WITH CHECKSUM чтобы убедиться, что все прошло хорошо. Недостатком такого решения является то, что для больших баз данных проверка контрольной суммы может серьезно загрузить систему.
2. Не выполняйте резервное копирование файлов на тот же физический диск, на котором хранится база данных или протокол транзакций.
3. Если вы используете MS SQL 2008 или выше, рекомендую вам использовать сжатие резервных копий средствами SQL. Следующий код включит сжатие по умолчанию: USE master; GO EXEC sp_configure ‘backup compression default’, '1'; RECONFIGURE WITH OVERRIDE;
4. держите резервные копии по нескольку дней на случай, если одна из них будет повреждена – старая резервная копия лучше, чем никакой.
5. Используйте DBCC CHECKDB для проверки каждой базы данных перед копированием, это своевременно предупредит вас о надвигающихся проблемах. DBCC CHECKDB ('Имя базы данных') WITH NO_INFOMSGS, ALL_ERRORMSGS; Примечание: на практики мы использовали данную проверку, только перед выполнением полной резервной копии.
6. Выполняйте периодически обновление статистики и реорганизации индексов БД

Используем приложение

Несколько нюансов по приложению:

• Все тексты и запросы в коде вынесены в ресурсы, мне так было проще
• При вводе параметров соединения и других настроек, они сохраняются в файл. Для Express и Standart используются разные файлы (dbStandart, udExpress) в них хранится класс UserData
• Для выполнения некоторых операций могут потребоваться права администратора
• На данный момент не работает соединение с БД под доменной учетной записью
• Программа не обладает суперкрасивым интерфейсом

1. Настройка уведомления администратора

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

Для данной цели используется DatabaseMail MS SQL (для версии Standart и выше) В своем приложение я сделал специальный раздел для автоматизации данной задачи

При нажатии появится форма для заполнения информации необходимой для создания профиля рассылки писем:

Приложение автоматически настроено на стандартный 25 SMTP порт для адреса с которого отправляются письма. При необходимости его можно изменить в процедуре sysmail_add_account_sp Пользователь и пароль требуются на случай, если у почтового сервиса настроена аутентификация.

Имя оператора в системе указывается для того, чтобы у нас нормально создался профиль в DatabaseMail. Пишите любое название, которое будет для вас понятным. Ниже приведен пример заполненной формы.

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

1. Меняются системные параметры MS SQL.
2. Создается DatabaseMail Profile
3. Активируется в SQL Agente профиль
4. Создается DatabaseMail Account
5. Добавляется DatabaseMail Account к Database Mail Profile
6. Создается DatabaseMail Operator

Более подробно описано в следующей статье и, частично, я брал отсюда. Естественно, данные действия можно выполнить с помощью SSMS.

2.Дополнительные уведомления для администратора

В программе предусмотрены 2 задачи, применяемые к БД:

1. проверка целостности БД. Для проверки базы данных использовалась стандартная процедура DBCC CHECKDB.
2. информирование о свободном месте в файловых группах.
3. Вторая задача была реализована с помощью запроса к системной таблице dbo.sysfiles
4. Вот пример данного запроса, который выполнялся к базе:

Select NAME = left(a.NAME,15), a.FILEID, [FILE_SIZE_MB] = convert(decimal(12,2),round(a.size/128.000,2)), [SPACE_USED_MB] = convert(decimal(12,2),round(fileproperty(a.name,'SpaceUsed')/128.000,2)), [FREE_SPACE_MB] = convert(decimal(12,2),round((a.size-fileproperty(a.name,'SpaceUsed'))/128.000,2)) , FILENAME = a.FILENAME From dbo.sysfiles a Ответ с сервера приходит на почту администратора в виде html разметки. Данный синтаксис возможен благодаря следующей стандартной функции MS SQL FOR XML.

Так же пока я искал, как преобразовать в возвращаемый результат выполнения запросов в html текст, наткнулся на следующую страницу, где человек создал целую процедуру для этих целей Настроить эти операции можно с помощью соответствующего пункта в меню программы:

Появиться окно для указания почтового ящика, на который необходимо высылать html текст отчета:

3.Решение проблем при настройке DatabaseMail

В MS SQL 2008 я столкнулся с проблемой при настройке SQL Server Agent. Симптомы следующие, после настройки невозможно запустить SQL Agent. В основном это решается с помощью установки update на SQL сервер.

Убедитесь, что установлен sp1, а потом можно уже ставить обновление.

Если данные обновления не помогают, необходимо скачать fix. Его можно найти на данном сайте конечную ссылку не могу указать сейчас, для того что бы дойти до пакета фикса, нужно будет ответить на ряд вопросов. Если есть проблемы с модулем DatabaseMail. После настройки данного модуля с помощью приложения, необходимо зайти в SQL Agent и просмотреть журнал событий. Если там будут ошибки «невозможно подключиться к почтовому ящику». Значит есть проблема, даже если через проверку отправляется письмо.

Исправляется это следующими манипуляциями:

1. Management Studio — SQL Server Agent — Properties.
2. Alert System
3. Уберите галочку с Enable mail profile
4. Нажмите OК
5. Зайдите снова и поставьте галочку
6. Перезагрузите SQL Server Agent.

Проверьте учетную запись для SQL Agent service. Если это доменная учетная запись измените ее на системную или наоборот. Все должно заработать.

4.Настраиваем резервное копирование с помощью приложения для SQL Standart:

Выбираем версию Standart. Настраиваем уведомления. (см. раздел, настройки уведомления):

Соединяемся с БД, заполняя данные для соединения и указываем БД, для которой будет применяться Job:

Выбираем настройку резервного копирования:

Указываем пути для сохранения копий БД. Если указанные папки не существует, то программа попытается их создать (нужны соответствующие права).

Нажимаем сохранить и базе настраиваются соответствующие задачи. Желательно настроить для каждого бэкапа разные папки, т.к. при удалении будут удаляться все файлы с расширением bak. (см. раздел удаление копий БД)

5.Настраиваем резервное копирование с помощью приложения для SQL Express:

Так как в SQL Express отсутствует SQL Agent, задачу по автоматизации резервного копирования пришлось решить другим путем. В указанной пользователем папке создается bat файле в котором описан SQL запрос, отвечающий за создание резервной копии. В случае необходимости можно редактировать его напрямую. По мимо этого должен работать стандартный планировщик Windows, в нем создается задача, которая будет запускать раз в сутки в указанное время.

Для этого запускаем приложение. Выбираем пункт MS SQL Express:

Появляется форма для заполнения параметров:

Указываем где будет сохраняться наша копия, а также где будет лежать bat файл для создания копии базы (имя файла указывать не надо, оно будет задано автоматически). Далее указываем настройки соединение и время, когда необходимо запускать задачу.

Единственный минус данного подхода в том, что приходится храниться в открытом виде пароль для соединения с БД.

6.Удаление задач из БД.

Если необходимо удалить все задачи из БД (например, захотели изменить пути сохранения БД). Для этого используем соответствующий пункт в меню программы. Из SQL Agent будут удалены все задачи с определенным начальным префиксом (в моем случае King):

7.Удаление копий БД

В некоторых задачах, настроено удаление старых копий БД. Для этого я использую процедуру master.dbo.xp_delete_file. Пример использования: Удалит все файлы с расширением bak из указанной папки, дата создания которых превышает 14 дней. EXECUTE master.dbo.xp_delete_file 0,"E:\backups",N'bak',dateadd(d,-14,getdate()),0; И вот еще один более подробный пример и информация о том, какие параметры принимает данная функция.

Как восстанавливать резервные копии

Из-за нехватки времени модуль восстановления еще не реализован, возможно в будущем я его добавлю, а пока просто кратко опишу как можно будет восстановить базу.

С помощью SQL скрипта. Для восстановления базы данных используется команда RESTORE.

Если необходимо восстановить просто базу из полной копии, то достаточно выполнить следующий скрипт:

RESTORE DATABASE [Имя базы данных] FROM DISK = 'Z:\SQLServerBackups\back.bak' WITH REPLACE В случае, если необходимо восстановить последовательно сначала полную копию, разностные копии и журналы транзакций, тогда необходимо написать следующий SQL скрипт.RESTORE DATABASE TEST_DB –восстанавливаем полную копию FROM test_db_full WITH NORECOVERY; GO RESTORE DATABASE TEST_DB –восстанавливаем разностную копию FROM test_db_diff WITH FILE = 1, NORECOVERY; GO RESTORE LOG TEST_DB –восстанавливаем журнал транзакций №1 FROM test_db_tran_1 WITH FILE = 1, WITH NORECOVERY; GO RESTORE LOG TEST_DB –восстанавливаем журнал транзакций №2 FROM test_db_tran_2 WITH FILE = 1, WITH NORECOVERY; GO RESTORE DATABASE TEST_DB WITH RECOVERY; GO Для восстановления БД можно использовать так же и SSMS.

habrahabr.ru

Журнал и сведения о заголовке резервной копии (SQL Server)

 

Опубликовано: Декабрь 2016

Полный журнал резервных копий и операций восстановления на экземпляре сервера SQL Server хранится в базе данных msdb. В этом разделе рассказывается о таблицах журнала восстановления, а также об инструкциях Transact-SQL, которые используются для доступа к журналам резервного копирования. В этом разделе также обсуждается удобство составления списка файлов базы данных и журнала транзакций и использование данных в заголовке носителя в сравнении с использованием данных в заголовке резервной копии.

В этом разделе:

В этом разделе рассказывается о журнальных таблицах, в которых в системной базе данных msdb хранятся метаданные резервного копирования и восстановления.

Таблица журналаОписание

backupfile;	Содержит по одной строке для каждого файла данных или журнала, подвергаемого резервному копированию.
backupfilegroup	Содержит по одной строке для каждой файловой группы в резервном наборе данных.
backupmediafamily;	Содержит по одной строке для каждого семейства носителей. Если семейство носителей хранится на зеркальном наборе носителей, семейство имеет отдельную строку для каждого зеркала в наборе носителей.
backupmediaset;	Содержит по одной строке для каждого резервного набора носителей.
backupset;	Содержит по одной строке для каждого резервного набора данных.
restorefile;	Содержит по одной строке для каждого восстановленного файла. Это файлы, восстановленные неявно по имени файловой группы.
restorefilegroup;	Содержит по одной строке для каждой восстановленной файловой группы.
restorehistory.	Содержит по одной строке для каждой операции восстановления.

 Примечание

При восстановлении изменяются таблицы журналов резервного копирования и восстановления.

Инструкции восстановления данных соответствуют сведениям, сохраненным в некоторых таблицах журналов резервного копирования.

 Важно

Инструкциям Transact-SQL RESTORE FILELISTONLY, RESTORE HEADERONLY, RESTORE LABELONLY и RESTORE VERIFYONLY требуется разрешение CREATE DATABASE. Тем самым обеспечивается более надежная защита файлов резервных копий и данных, чем в предыдущих версиях. Сведения об этом разрешении см. в разделе GRANT, предоставление разрешений на базу данных (Transact-SQL).

Информационная инструкцияТаблица журнала резервного копированияОписание

RESTORE FILELISTONLY	backupfile;	Возвращает результирующий набор со списком файлов базы данных и журнала, которые содержит указанный резервный набор данных. Дополнительные сведения см. далее в разделе «Составление списка файлов базы данных и журналов транзакций».
RESTORE HEADERONLY	backupset;	Извлекает все данные заголовка резервной копии для всех резервных наборов данных в определенном устройстве резервного копирования. Результатом выполнения RESTORE HEADERONLY является результирующий набор. Дополнительные сведения см. далее в разделе «Просмотр данных заголовка резервной копии».
RESTORE LABELONLY	backupmediaset;	Возвращает результирующий набор, который содержит сведения о резервном носителе в указанном устройстве резервного копирования. Дополнительные сведения см. далее в разделе «Просмотр данных заголовка носителя».

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

• Был утрачен дисковый накопитель, который содержал один или несколько файлов базы данных.

  По списку файлов в резервной копии базы данных можно определить затронутые файлы, затем восстановить эти файлы на другом диске при восстановлении всей базы данных или восстановить только эти файлы и применить любые резервные копии журналов транзакций, созданные со времени резервного копирования базы данных.

• База данных из одного сервера восстанавливается на другом сервере, но на сервере отсутствуют структура каталогов и сопоставление носителей.

  Составление списка файлов в резервной копии позволяет определить затронутые файлы. Например, резервная копия содержит файл, который нужно восстановить на диск E:, но на целевом сервере диск E: отсутствует. При восстановлении этот файл необходимо перенести в другое расположение, например на диск Z:.

При просмотре данных в заголовке носителя отображаются сведения о самом носителе, а не о резервных копиях на нем. К отображаемым сведениям из заголовка носителя относятся имя носителя, описание, имя программы, с помощью которой был создан заголовок носителя, а также дата записи заголовка носителя.

 Примечание

Просмотр данных в заголовке носителя занимает мало времени.

Дополнительные сведения см. далее в разделе «Сравнение данных в заголовках носителя и резервной копии».

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

 Примечание

Просмотр данных в заголовке носителя для магнитных лент большой емкости может занимать длительное время, так как для отображения информации обо всех резервных копиях на носителе необходимо просмотреть весь носитель.

Дополнительные сведения см. далее в разделе «Сравнение данных в заголовках носителя и резервной копии».

Резервные наборы, которые необходимо восстановить

Сведения из заголовка резервной копии можно использовать для определения резервного набора данных, который будет использован в процессе восстановления. Компонент Database Engine нумерует каждый резервный набор данных на резервном носителе. Это позволяет выявить резервный набор данных, подлежащий восстановлению, по его положению на носителе. Например, на следующем носителе содержатся три резервных набора данных.

Чтобы восстановить определенный резервный набор данных, укажите номер позиции резервного набора данных, который нужно восстановить. Например, чтобы восстановить второй резервный набор данных, следует указать «2» в качестве номера резервного набора данных, подлежащего восстановлению.

На следующем рисунке показано отличие между просмотром данных в заголовке носителя и просмотром данных в заголовке резервной копии. Получение заголовка носителя требует извлечения данных только с начала ленты. Получение заголовка резервной копии требует просмотра всей ленты в поисках заголовков всех резервных наборов данных.

 Примечание

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

Дополнительные сведения о просмотре заголовка носителя см. выше в разделе «Просмотр данных заголовка носителя».

Дополнительные сведения о просмотре заголовка резервной копии для всех резервных наборов данных на устройстве резервного копирования см. далее в разделе «Просмотр данных заголовка резервной копии».

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

Удаление старых строк из таблиц журналов резервного копирования и восстановления

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

Просмотр файлов данных и журналов в резервном наборе данных

Просмотр данных в заголовке носителя

Просмотр данных в заголовке резервной копии

Удаление старых строк из таблиц журналов резервного копирования и восстановления

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

Просмотр данных в заголовке носителя

Просмотр данных в заголовке резервной копии

Просмотр файлов в резервном наборе данных

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

BACKUP (Transact-SQL)Наборы носителей, семейства носителей и резервные наборы данных (SQL Server)Устройства резервного копирования (SQL Server)Зеркальные наборы носителей резервных копий (SQL Server)Возможные ошибки носителей во время резервного копирования и восстановления (SQL Server)

msdn.microsoft.com

Windows 2003 Backup

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

Графическое инструментальное средство Windows 2003 Backup предназначено для автоматического и ручного резервного копирования и восстановления файлов, расположенных на разделах файловых систем FAT и NTFS.

Выбор стратегии резервного копирования

 

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

 

Отбор файлов для резервного копирования

По степени важности (а следовательно, и по частоте создания резервных копий) папки и файлы можно разделить на три категории:

-   важные — их резервные копии создаются всегда;

-   полезные — их резервные копии создаются изредка;

-   малозначимые — их резервные копии не создаются никогда.

Отбирая файлы для резервного копирования, учитывайте следующие правила:

-   всегда создавайте резервные копии

o   файлов, жизненно важных для работы Вашей организации;

o   реестров всех главных и резервных контроллеров домена (каждый контроллер домена имеет свою копию базы данных каталогов; резервное копирование реестра контроллера домена предотвращает потерю информации об учетных записях пользователей и защите).

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

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

Выбор типа резервного копирования

Windows 2003 Программа архивации (Backup Utility) предлагает пять вариантов резервного копирования: обычное (normal), копирующее (copy), инкрементальное (incremental), разностное(differential) и ежедневное (daily). Выбор стратегии резервного копирования определяется тем, сколько времени отводится на сохранение данных и каковы требования к скоростям поиска резервных копий и восстановления файлов.

Рисунок  7. Выбор типа архивации

Краткая характеристика перечисленных выше типов резервного копирования приведена в таблице.

Таблица  5. Варианты резервного копирования

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

 

Журналы резервного копирования

Журнал резервного копирования (backup log) — это текстовый файл, в котором регистрируются операции резервного копирования (рис. 8). Он полезен при восстановлении данных. Его можно либо распечатать, либо посмотреть в любом текстовом редакторе. Журнал хранится на диске, поэтому в случае повреждения каталога архива на ленте обратитесь к нему, чтобы найти нужный файл.

Рисунок  8. Журнал резервного копирования

Журнал резервного копирования содержит следующую информацию:

-   дату создания архива;

-   название варианта резервного копирования;

местонахождение накопителя.

  

Шаблон плана резервного копирования

Местонахождение накопителя __ Местонахождение лент_______

Путь к архивируемым файлам и папкам	Ежедневное резервное копирование	Еженедельное резервное копирование (укажите день)

 

Недельное расписание резервного копирования

Понедельник	Вторник	Среда	Четверг	Пятница
Тип копирования	Тип копирования	Тип копирования	Тип копирования	Тип копирования
Лента	Лента	Лента	Лента	Лента
Архив: Да Нет	Архив: Да Нет	Архив: Да Нет	Архив: Да Нет	Архив: Да Нет

 

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

О = Обычное, Д = Инкрементальное, Р = Разностное, К = Копирующее, ЕК = Ежедневное копирование

 

 

Резервное копирование файлов

Программа резервного копирования Windows 2003 выглядит следующим образом. (рис. 9)

Рисунок   9. Окно мастеров архивации

 

Чтобы запустить программу, в меню Start (Пуск) выберите пункты Programs (Программы),Accessories (Стандартные), System Tools (Служебные), Backup (Архивация данных).

 

На рис. 10 представлены мастера архивации. Здесь можно выбрать 3 мастера: мастер архивации, мастер восстановления и мастер аварийного восстановления системы.

Рисунок  10. Окно "Архивация"

 

На рисунке 10 представлено окно архивации. Здесь можно выбрать параметры архивации: объекты архивации и назначение архивации. Можно также выбрать дополнительные параметры архивации (рисунок 11).

Рисунок  11. Окно "Дополнительные параметры архивации"

Рисунок  12. Окно "Восстановление и удаление носителем"

На рисунок 12 представлено окно восстановления управления носителем. Здесь можно выбрать необходимые для восстановления объекты.

Рисунок  13. Окно "Запланированные задания"

 

На рисунок 13 представлено окно планировщика заданий. Здесь можно создать задание архивации, путем вызова мастера архивации (рисунок 14).

Рисунок  14. Мастер архивации

Рисунок 15. Окно "Мастер архивации". Выбор типа архивации.

На рисунок 15 представлены типы архивации: обычный, копирующий, добавочный, разностный, ежедневный. Далее предлагается выбрать время выполнения задания (рисунок 16) и параметры задания (рисунок 17).

Рисунок  16. Окно "Расписание"

Рисунок  17. Окно "Параметры архивации"

 

studfiles.net

---

Смотрите также

• 
  Журнал регистрации завещательных распоряжений
• 
  Журнал неман официальный сайт
• 
  Журнал высокочистые вещества сайт
• 
  Городское обозрение недвижимости журнал
• 
  Бмв сервис лайф журнал
• 
  Архив офтальмологии украины журнал
• 
  Object журнал официальный сайт
• 
  Живой журнал digital angel
• 
  Михаил плетнев живой журнал
• 
  Верстка журнала в publisher
• 
  Алексей замятин живой журнал