Системы резервного копирования и восстановления данных: Обзор систем резервного копирования и восстановления данных на мировом и российских рынках – Система резервного копирования / Habr

Содержание

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


Сегодня я хочу затронуть вопрос о некоторых важных принципах процедуры резервного копирования и восстановления после сбоев. В частности будут рассмотрены такие вопросы как:
  1. Взаимосвязь процедур обновлений продуктивной системы и процесса ее резервного копирования
  2. Тестирование восстановления из резервных копий
  3. Взаимодействие бэкап-процесса с элементами сетевой инфраструктуры продуктивной сети
  4. Документирование процедуры восстановления после сбоев


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

Проводите резервное копирование ПЕРЕД обновлением системы

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

Предположим следующий сценарий:

  1. Плановый бэкап проходит в ночь со вторника на среду
  2. До среды система используется в режиме «как обычно»
  3. Вечером в среду система обновляется (устанавливается новая версия системного программного обеспечения). В виду того, что перед установкой release notes были прочитаны не достаточной внимательно, система входит в нестабильное состояние.
  4. Система переустановлена с потерей данных на момент своего состояния во вторник
  5. В четверг пользователи вынуждены пересоздать все данные, созданные за среду

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

Пример:
  1. Полная резервная копия создается по пятницам, в остальные дни создаются инкрементальные копии
  2. В среду было произведено обновление сервера базы данных до новой версии, которое сопровождалось обновлением некоторых общих системных файлов, относящихся к операционной системе
  3. В ночь на четверг была, как обычно, получена инкрементальная резервная копия
  4. В четверг утром произошел критический сбой, потребовавший восстановления системы
  5. Изучив характер сбоя, администратор понимает, что повреждены только системные файлы и для восстановления функционирования системы достаточно было бы восстановить только множество системных фалов (system state), используя последнюю полную резервную копию. Однако, если сделать только это, то обновленная версия сервера базы данных перестанет работать, так как ей требуются более новые версии системных файлов (например, последняя версия .NET Framework), которые были установлены вместе с ним. Это приводит к необходимости продолжать процесс восстановления, просматривая необходимые инкрементальные копии, которые содержат изменения в system state. Это ведет, в конечном счете, к увеличению трудоемкости процесса восстановления и увеличению времени RTO, вплоть до нарушения SLA.

Общую рекомендацию можно сформулировать следующим образом: если кумулятивный объем инкрементальных резервных копий превосходит объем полной резервной копии, рационально сделать внеплановую полную резервную копию.
Проводите полное резервное копирование СРАЗУ после восстановления системы

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

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

Рассмотрим несколько примеров, что из этого может получиться:

  1. Система удачно восстановлена после сбоя, но администратор принимает решение сразу установить самые последние обновления на систему, чтобы потом не прерывать работу пользователей для этих целей. Однако один из патчей некорректно устанавливается, и система рушится. В результате систему опять приходится восстанавливать с нуля.
  2. Произошел критический сбой сервера приложения версии X.1. Система не была затронута сбоем. Администратор решил в процессе восстановления установить новую версию X.2 с установочного диска и восстановить из резервной копии данные приложения и дополнительные программные модули, реализующие специфичную бизнес логику. Однако после восстановления данных и модулей выяснилось, что они не совместимы с новой версией X.2 из-за небольших изменений в логике работы некоторых программных функций и в спецификациях некоторых программных интерфейсов. В результате сервер приложений пришлось восстанавливать сервер приложений версии X.1.
  3. Произошел критический сбой операционной системы версии X. Пользователь не нашел установочный диск версии X (так как эта версия была установлена 3 года назад) и установил версию X+1. У администратора возникла проблема с учетом лицензий, кроме того, одно используемое для работы бизнес приложение оказалось не совместимо с новой версией операционной системы. Систему пришлось переустанавливать.

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

Читайте документацию ПЕРЕД тем как настроить резервное копирование

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

Пример «нюансов» такого рода:

  1. В процессе резервного копирования не сохраняются различные пароли и информация о лицензии. А это означает, что при восстановлении не удастся получить работоспособное приложение или операционную систему, а план восстановления после сбоев в части декларированного RTO окажется сорванным.
  2. Системная конфигурация приложения должна сохраняться по специальной процедуре, отдельной от процедуры бэкапа самих данных
  3. Процедура бэкапа открытых на запись файлов является специальным образом оговоренной в документации (требуется заранее включить определенные настройки в конфигурации приложения).

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

Восстановление системы в компании в общем случае может проводиться администраторами сети, специалистами HelpDesk, и самими пользователями. Последний вариант я рассматривать не буду как характерный лишь для маленьких компаний или для ИТ отрасли. Что же касается специалистов HelpDesk, то обычно они могут решить часто встречающиеся проблемы базового уровня, в том числе восстановление отдельных файлов. Но, если говорить о восстановление системы в целом, то лучше поручить такую задачу человеку с административными полномочиями:
  1. Восстановление может затрагивать задачу включения рабочей станции в домен, а на это нужны полномочия администратора домена
  2. Восстановление системы с нуля может потребовать решения проблем (например, с драйверами для RAID), выходящими за рамки компетенции персонала HelpDesk. Кроме того, более высокая квалификация администраторов позволяет им правильнее приоритизировать выдаваемые системой ошибки, возникающие при восстановлении, откладывая на более поздний срок решение проблем, непосредственно не мешающих задаче скорейшего восстановления работы продуктивной сети.
  3. Могут возникнуть иные проблемы, требующие административных полномочий (пароли на сетевые ресурсы, недоступность сети в целом, проблемы активации из-за настроек корпоративного файервола и т.д.)

Тестирование восстановления должно проводиться регулярно

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

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

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

Документирование процедур стадии восстановления

Аккуратно документируйте процедуру восстановления после сбоев

Нужно избегать двух вещей:
  • Не нужно полагаться целиком и полностью на продукт резервного копирования (в том смысле, что он «если что — восстановит все сам — установил и забыл»). Всегда могут быть такие параметры конфигурации системы (например, статус активации операционной системы, информация о лицензии, или сохраненные учетные записи с паролями к сетевым ресурсам), которые не будут сохранены в резервной копии, или будут приложением намеренно (в рамках защиты от копирования) признаны недействительными при восстановлении (например статус активации). Практически это означает, что всегда нужно иметь под рукой документ по финальному восстановлению работоспособности приложений на случай, если продукт резервного копирования не сможет восстановить все полностью автоматически.
  • Не нужно полагаться на предположение, что любой продукт резервного копирования будет полностью совместим с любой инфраструктурой в мире. Нужно проверить, что продукт совместим с имеющейся аппаратурой и нормально работает в условиях функционирования специфических режимов (например, при выполнении LUN rebinding на SAN или при перестроении тома на RAID-5 массиве). Особые случае поведения продукта и методов обеспечения совместимости подлежат документированию.

Примеры рекомендуемой к созданию документации для случая восстановления после сбоя:
  1. Регулярный автоматизированный дамп конфигурационных настроек, выполняемый, например, с помощью программных продуктов, позволяющих осуществлять версионный контроль настроек и/или контролировать их целостность. Управление версиями конфигураций приложений в принципе является полезным дополнением к системе резервного копирования, так как в ряде случаев позволяет снизить RTO. В отличие от продуктов резервного копирования, продукты контроля версий конфигураций, позволяют не просто сохранить любое изменение в настройках, но (1) согласовывать такие изменения (2) помечать некое устойчивое состояние конфигурации специальными тэгами.
  2. Лицензионные ключи, которые могут потребоваться для повторного ввода после того, как приложения будут восстановленф
  3. Пароли, которые будут нужны на случай восстановления системы, должны быть записаны на листе восстановления в бумажном или электронном виде и храниться в месте ограниченного доступа, в соответствии с политиками безопасности. Это нужно, как минимум, для случая, когда восстановление системы будет производиться другим администратором (например, если первый администратор в отпуске).
  4. Перечисленная выше информация для восстановления должна, в свою очередь, подлежать резервному копированию, в том числе, при необходимости, с копированием в другой офис компании. Эта информация быть максимально надежно защищена от возможного действия вирусов и шпионского программного обеспечения во всех точках хранения.

Что тестировать в рамках проверки процедуры восстановления после сбоев?

Для того, чтобы инструкции, применяемые в процессе восстановления после сбоев, были максимально корректны, нужно проводить «учебные восстановления». В процессе проведения тестирования процесса восстановления нужно обратить внимание по крайней мере на такие вопросы как:
  1. В случае полного разрушения сайта, будут ли резервные копии содержать всю информацию, необходимую для его восстановления?
  2. Как будет проходить процесс восстановления, если главный системный администратор будет недоступен (скажем, будет находится в заграничном отпуске)?
  3. Что произойдет, если окажется поврежденным носитель информации (лента/диск), на котором размещена резервная копия, наиболее подходящая для использования в процессе восстановления?
  4. Что будет в случае т.н. «вторичного сбоя»? То есть, в случае, когда после успешного завершения процесса восстановления, окажется, что восстановленная система не работает?
  5. Укладывается ли время, затраченное на процесс восстановления, в оговоренный SLA? Знают ли вовлеченные в процесс люди о существовании SLA и его параметрах, и принимают ли его во внимание в своей работе?
  6. Как скажется на процесс восстановления отказ инфраструктурных компонентов продуктивной сети (почтовый сервер, сервер мгновенных сообщений, DNS, контролер домена и т.д.)
  7. Качество документации: cможет ли нетренированный администратор восстановить продуктивную систему, следуя письменным инструкциям?
  8. Скорость реакции компании, если причиной разрушения информации стал вирус (любого типа). Специфичность этой угрозы в том, что вирус может исказить данные и приложения, не нарушив при этом их доступность,- в результате чего системы обеспечения отказоустойчивости не зафиксируют сбой, кроме того, настроенные механизмы репликации изменений данных автоматически разнесут эти искажения по остальным репликационным партнерам (или узлам кластера/геокластера).
  9. Зависит ли процесс восстановления от специфичной аппаратуры (которая может выйти из строя в момент восстановления)?
  10. Можно ли провести процесс восстановления полностью удаленно?
  11. Что будет, если будет нарушена работа канала, связывающего бэкап-сайты компании?

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

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

Дополнительно о тестировании резервных копий и о патентованной технологии Veeam SureBackup, можно почитать здесь:

  1. Описание на сайте Veeam: Технология Veeam vPower для VMware
  2. Вебинар: Modern Data Protection for Virtualised Environment
  3. Пост "SureBackup – автоматическая проверка возможности восстановления данных из резервной копии"
  4. Пост "Тестирование восстановления данных из резервных копий"

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

* * *

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

- да, но с некоторыми ограничениями
- без ограничений

Нашли ошибку, напишите нам [email protected] Сделаем информацию доступной вместе.

* * *

ТАБЛИЦА СРАВНЕНИЯ ФУНКЦИОНАЛЬНЫХ ВОЗМОЖНОСТЕЙ ПРОГРАММ ДЛЯ РЕЗЕРВНОГО КОПИРОВАНИЯ

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

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

Резервное копирование приложений и баз данных

Возможность восстановления отдельных объектов и элементов (гранулярное восстановление) приложений и баз данных. Решения отличаются знанием архитектуры и особенностей приложения.

Резервное копирование виртуальных машин

Резервное копирование и восстановление виртуализированных систем на уровне гипервизора или гостевой системы (ВМ).

Установка и управление системой резервного копирования

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

Хранение резервных копий / Операции с хранилищем

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

Функции аварийного восстановления системы резервного копирования (Disaster Recovery)

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

Резервное копирование информации - положения и инструкции для организации

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

Основными тенденциями на 2017-2019 годы мы видим следующие виды резервного копирования:

  • копирование в облако с любых устройств по принципу “подписки” за каждый гигабайт данных с помощью облачных сервисов, которые через предустановленный в систему агент “заливают” копии в облако . Пример тому – Commvault;
  • копирование  в облако с помощью Veaam и подобных продуктов (Acronis/Symantec/HP Data Protector). Требует подготовки провайдера, настройки коннектора между облаком провайдера и “наземной” виртуальной средой;
  • копирование “инхаус” с помощью софтовых решений от производителей NAS систем или выделенных хранилищ корпоративного сектора;
  • распределенный бекап с помощью встроенных в ОС Windows Server решений.

Задачи резервного копирования в организации

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

  • сохранить данные для максимально быстрого восстановления (disaster recovery), если с ИТ-системой компании произошла авария, ее атаковал вирус и т.д. У таких резервных копий сравнительно небольшой период хранения (чаще всего сутки или двое, потом они перезаписываются более новыми), к данным можно получить доступ очень быстро. Копируются пользовательские и бизнес-данные, а также настройки ОС, прикладного ПО и вся информация, необходимая для восстановления работоспособности системы;
  • создать долговременный архив сведений о деятельности компании, к которому можно обратиться при необходимости получить данные за прошедшие периоды. Такие архивы хранятся долго (месяцы и годы), скорость доступа к ним не особенно важна – обычно не страшно, если получение данных займет несколько дней. Хранятся только бизнес-данные и данные пользователей, нет необходимости хранить какую-либо системную информацию.

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

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

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

Резервное копирование VS Избыточное резервирование

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

Пример избыточного резервирования:

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

Такая избыточность повышает надежность системы, однако она не заменяет резервное копирование. Ни RAID-массив, ни кластер никак не обезопасит данные от действия вируса, удаления из-за ошибки пользователя или нарушения файловой системы, так как данные будут затронуты все равно по всей системе, не останется неповрежденной копии для восстановления. К тому же, ни одно из приведенных средств не решит полноценно задачу вести долговременный архив данных компании.

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

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

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

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

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

  • полное резервное копирование – выбранные данные копируются целиком. Самый надежный способ, но требует наибольшего количества ресурсов, места для хранения данных и времени копирования, поэтому в чистом виде применяется редко, обычно комбинируется с другими видами (например, первый раз с системы снимается полная копия, а потом резервируются только внесенные изменения). Позволяет восстановить утраченные данные с нуля быстрее всех остальных видов копирования;
  • инкрементное копирование – записываются только те данные, которые были изменены со времени прошлого бэкапа. Для таких копий требуется значительно меньше памяти, чем при полном копировании, и снимаются они значительно быстрее. Разумеется, при таком подходе необходимо периодически делать и полную резервную копию, при любой аварии систему восстанавливают из такой копии, а затем накатывают на нее все последующие инкрементные копии в хронологическом порядке. Важный момент: инкрементное копирование восстанавливает удаленные файлы и все предыдущие версии файлов, которые изменялись, так что при восстановлении следует предусмотреть дополнительное дисковое пространство на этот случай;
  • дифференциальное резервное копирование – похоже на инкрементное, т.е. копируются только изменения, сделанные с момента последнего полного копирования. Отличие в том, что в каждую последующую копию сохраняются изменения из предыдущей и добавляются новые. Получается, что для восстановления после аварии понадобится только полная копия и последняя из дифференциальных, что значительно сокращает время восстановления. Минусами, по сравнению с инкрементным копированием, являются большой объем копий (иногда сравнимый с полным копированием) и большее время копирования.

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

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

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

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

Место хранения резервных копий

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

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

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

Организационные моменты и человеческий фактор

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

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

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

Аннотация: В этой лекции вводятся понятия, и разбираются на примерах темы архивирования и восстановления системы. При архивировании и восстановлении системы используются стандартные утилиты 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-накопителей.
  • Дисковые накопители обеспечивают наивысшую скорость при архивации и восстановлении файлов. Если при архивации на ленту вам потребуются часы, то дисковый накопитель позволяет завершить процесс за несколько минут. К недостаткам дисковых накопителей следует отнести относительно высокую цену.

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

Об утверждении Порядка резервного копирования и восстановления работоспособности автоматизированных систем информационной инфраструктуры Министерства здравоохранения Российской Федерации, Приказ Минздрава России от 29 апреля 2013 года №272

Об утверждении Порядка резервного копирования и восстановления работоспособности автоматизированных систем информационной инфраструктуры Министерства здравоохранения Российской Федерации



В целях обеспечения сохранности сведений, содержащихся в информационных системах Министерства здравоохранения Российской Федерации,

приказываю:

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

2. Контроль за исполнением настоящего приказа возложить на Департамент информационных технологий и связи (Р.М.Ивакин).

Министр
В.И.Скворцова

Приложение. Порядок резервного копирования и восстановления работоспособности автоматизированных систем информационной инфраструктуры Министерства здравоохранения Российской Федерации

Приложение
к приказу
Министерства здравоохранения
Российской Федерации
от 29 апреля 2013 года N 272

Список терминов и сокращений


Заказчик - Министерство здравоохранения Российской Федерации (далее - Минздрав России).


Исполнитель - Федеральное государственное бюджетное учреждение "Центр информационно-технологической и эксплуатационной поддержки" Министерства здравоохранения Российской Федерации (далее - ФГБУ ЦИТЭП Минздрава России).


ГСА (группа системных администраторов) - группа сотрудников Исполнителя, обеспечивающая устранение сложных неисправностей оборудования и развитие ИТ-инфраструктуры Заказчика.


СТП (служба технической поддержки) - группа сотрудников Исполнителя, обеспечивающая техническую поддержку сотрудников Заказчика.


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


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


Сотрудник службы технической поддержки - сотрудник Исполнителя из числа ГСА.


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


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


Ответственный за информационные ресурсы Заказчика - сотрудник Департамента информационных технологий и связи, принимающий решения о создании новых и изменении существующих ИТ-ресурсов.


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


ИС "Портал учёта заявок" - информационная система, обеспечивающая приём и обработку заявок от сотрудников Минздрава России.


Полный архив - архив информации, содержащий полный набор сохраняемых для копирования данных.


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


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

1. Общие положения


Настоящий Порядок резервного копирования и восстановления работоспособности автоматизированных систем информационной инфраструктуры Министерства здравоохранения Российской Федерации, разработан с целью:

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

2. Определения порядка восстановления информации в случае возникновения такой необходимости.

3. Упорядочения работы должностных лиц Исполнителя и Заказчика, связанной с резервным копированием и восстановлением информации.

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

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

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

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

- полное или частичное восстановление данных и приложений.

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

1. Групповая информация пользователей (общие каталоги департаментов и отделов).

2. Информация, необходимая для восстановления серверов приложений.

3. Содержимое баз данных информационных систем Минздрава России.

4. Информация службы каталогов Microsoft Active Directory.

5. Электронные почтовые ящики пользователей локальной вычислительной сети Минздрава России.

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


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

1. Резервное копирование производится в нерабочее время без учёта праздничных дней, а также переносов рабочих и праздничных дней:

- будние дни - с понедельника по пятницу, в период с 18:00 до 09:00 следующего дня;

- выходные дни - суббота-воскресенье, в период с 09:00 до 09:00 следующего дня.

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

3. Максимальный срок хранения полных архивов - не более 6 месяцев, разностных архивов - не более 14 дней.

Ресурсы, внедряемые в информационную структуру Минздрава России, подлежат резервному копированию на основании утверждаемого директором Департамента информационных технологий и связи списка изменений, внесенного в приложение N 1 к данному Порядку.

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

О выявленных попытках несанкционированного доступа к резервируемой информации, а также иных нарушениях и сбоях, произошедших в процессе резервного копирования, сотрудник ГСА сообщает директору Департамента информационных технологий и связи служебной запиской по факту события в течение одного рабочего дня.

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

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


Контроль результатов всех процедур резервного копирования осуществляется ГСА в срок до 18:00 рабочего дня, следующего за установленной датой выполнения этих процедур, путём анализа отчётов системы резервного копирования.

В случае обнаружения ошибки резервного копирования сотрудник ГСА немедленно сообщает об этом начальнику отдела эксплуатации технической инфраструктуры и обеспечения связью Департамента информационных технологий и связи с целью устранения ошибки до 18:00 текущего рабочего дня. После обнаружения ошибки ГСА принимаются меры по устранению причин ошибки для предотвращения её повторения в течение следующего цикла резервного копирования. При отсутствии существенного влияния резервного копирования на прикладное и системное ПО сервера возможен повторный запуск процедуры резервного копирования.

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


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

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

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

5. Восстановление информации из резервных копий


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

Процедура восстановления информации из резервной копии осуществляется в соответствии с методикой восстановления информации (приложение N 3 к данному Порядку).

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

Приложение N 1. Перечень резервируемой информации

Приложение N 1
к Порядку

Название
информационного
ресурса

Назначение
информационного
ресурса

Адрес размещения
информационного ресурса в локальной сети Минздрава России

Периодичность
резервного
копирования
информационного
ресурса

Автоматизированная информационная системы "Учет кадров"

Оказание услуг по сопровождению автоматизированной информационной системы "Учет кадров" Минздрава России

kadry.minzdrav.localdomain

Полная копия - 1 раз в день

Система по учету и контролю исполнения документов

Оказание услуг по сопровождению системы по учету и контролю исполнения документов Минздрава России

d3.minzdrav.localdomain

Полная копия - 1 раз в день

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

Оказание услуг по сопровождению баз данных системы электронного архива Минздрава России

saperion.minzdrav.localdomain

Инкрементальная копия - ежедневно, Полная копия - 1 раз в неделю

Комплекс
программных средств для ведения бюджетного учета и составления отчетности

Оказание услуг по сопровождению комплекса программных средств для ведения бюджетного учета и составления отчетности для нужд Минздрава России

budget.minzdrav.localdomain

Инкрементальная копия - ежедневно, Полная копия - 1 раз в неделю

Система
"Удостоверяющий центр Минздрава России"

Изготовление сертифицированных ключей электронной подписи

adminVIPnet,
crt.minzdrav.localdomain, ra, ca

Полная копия - 1 раз в день

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

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

proftest.minzdrav.localdomain

Полная копия - 1 раз в неделю

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

Организация процедуры
электронного
согласования
государственных
контрактов,
заключаемых
Минздравом России

docsvision-
test.minzdrav.localdomain
docvisionapp.minzdrav.localdo
main
docvisiondb.minzdrav.localdom
ain
DocVisionDB2.minzdrav.locald
omain

Инкрементальная копия - ежедневно, Полная копия - 1 раз в неделю

Автоматизированная информационно-
аналитическая система "Аверс:Ревизор"

Планирование и учет результатов ревизионной работы подведомственных учреждений Минздрава России

ukrd.minzdrav.localdomain

Полная копия - 1 раз в неделю

Прикладное программное обеспечение учета информации нормативно-правовых актов. Прикладное программное обеспечение учета судебных дел

Учёт судебных дел и нормативно-
правовых актов

sud-med.minzdrav.localdomain

Полная копия - 1 раз в неделю

Система электронной почты Минздрава России

Электронная почта сотрудников Минздрава России

exhange.minzdrav.localdomain, exhange2.minnzdrav.localdomain

Инкрементальная копия - ежедневно. Полная копия -1 раз в неделю

Контроллер домена локальной сети Минздрава России

контроллер домена инфраструктуры сети Минздрава России

minzdrav-dc21-
1.minzdrav.localdomain,
minzdrav-dc3-
l.minzdrav.localdomain,
lotusservl.minzdrav.localdomain

Полная копия -1 раз в неделю

Файл-сервер локальной сети Минздрава России

Файл-сервер Минздрава России (персональные папки пользователей, папки отделов и департаментов)

share.minzdrav.Iocaldomain

Инкрементальная копия - ежедневно. Полная копия - 1 раз в неделю

Комплекс программ для ведения бухгалтерского учёта Минздрава России

Бухгалтерский учёт Минздрава России

lc-app, lc-database

Инкрементальная копия - ежедневно. Полная копия - 1 раз в неделю

Информационная
система
"Государственный
реестр
лекарственных
средств"

Учет лекарственных средств

leksredstva-app
leksredstva-db

Инкрементальная копия - ежедневно. Полная копия - 1 раз в неделю

Приложение N 2. Методика резервного копирования

Приложение N 2
к Порядку


Для организации системы резервного копирования используется программное обеспечение Arcserve Backup 16.1. Основной сервер резервного копирования Symantec Netbackup устанавливается на площадке Рахмановский, д.3, помещение серверной, шкаф N 12. Учитывая пропускные способности каналов и объёмы резервируемых данных, выделенный media-сервер, ПО Arcserve Backup 16.1 устанавливается на площадке ул.Щукинская, д.5, шкаф N 6. В качестве носителей информации выступают:

1. Ленточная библиотека Overland Neo400s - 2 шт.

2. Разделы данных на дисковом хранилище HP 3Par F400, Netapp FAS3240. Схема расположения устройств резервного копирования приведена на рис.1.

Рисунок 1. Схема расположения устройств резервного копирования Минздрава России.



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

Определено три типа резервных копий:

1. Месячная копия. Записывается информация на первое число текущего месяца. Срок хранения информации на носителях составляет 6 месяцев. Хранится на ленточных накопителях, подключенных к серверу резервного копирования Arc1.

2. Недельная копия. Записывается в ночь с субботы на воскресенье, кроме последней недели месяца.

Срок хранения информации на носителях составляет 30 календарных дней. Хранится на сервере резервного копирования Arc2 на разделе с СХД Netapp FAS3240 либо СХД HP 3Par F400.

3. Ежедневная копия. Записывается ежедневно, кроме субботы и воскресенья.

Срок хранения информации на носителях составляет 14 календарных дней. Хранится на сервере резервного копирования Arc2 на разделе с СХД Netapp FAS3240 либо СХД HP 3Par F400.

Приложение N 3. Методика восстановления информации

Приложение N 3
к Порядку



Любое восстановление информации, не связанное с потерей работоспособности информационной системы или ее компонентов, выполняется на основании заявки, оформленной через ИС "Портал учёта заявок". Заявка должна содержать информацию о составе информации, требуемой к восстановлению, и дату, на которую требуется осуществить восстановление.

Восстановление информации, относящейся к базам прикладных информационных систем, происходит при взаимодействии с администратором прикладной информационной системы. В процессе восстановления резервной копии следует руководствоваться инструкциями по восстановлению информации из резервных копий, описанных в документации, прилагающейся к системе резервного копирования ПО Arcserve Backup 16.1 и инструкциями к прикладной информационной системе.

Процедура восстановления информации из резервной копии осуществляется сотрудниками ГСА.

Электронный текст документа
подготовлен ЗАО "Кодекс" и сверен по:
рассылка

Резервное копирование — Википедия

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

Резервное копирование (англ. backup copy) — процесс создания копии данных на носителе (жёстком диске, дискете и т. д.), предназначенном для восстановления данных в оригинальном или новом месте их расположения в случае их повреждения или разрушения.

Наименование операций

  • Резервное копирование данных (резервное дублирование данных) — процесс создания копии данных.
  • Восстановление данных — процесс восстановления в оригинальном месте.

Цель

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

Кроме этого, решается проблема передачи данных и работы с общими документами.

Требования к системе резервного копирования

  • Надёжность хранения информации — обеспечивается применением отказоустойчивого оборудования систем хранения, дублированием информации и заменой утерянной копии другой в случае уничтожения одной из копий (в том числе как часть отказоустойчивости).
  • Многоплатформенность - полноценное функционирование системы резервного копирования в гетерогенной сети предполагает, что её серверная часть будет работать в различных операционных средах и поддерживать клиенты на самых разных аппаратно-программных платформах.
  • Простота в эксплуатации — автоматизация (по возможности минимизировать участие человека: как пользователя, так и администратора).
  • Быстрое внедрение — простая установка и настройка программ, быстрое обучение пользователей.

Ключевыми параметрами резервного копирования являются:

  • RPO — Recovery Point Objective;
  • RTO — Recovery Time Objective.

RPO определяет точку отката — момент времени в прошлом, на который будут восстановлены данные, а RTO определяет время, необходимое для восстановления из резервной копии.

Виды резервного копирования[1][2]

Полное резервное копирование (Full backup)
Полное копирование обычно затрагивает всю систему и все файлы. Еженедельное, ежемесячное и ежеквартальное резервное копирование подразумевает создание полной копии всех данных. Обычно оно выполняется тогда, когда копирование большого объёма данных не влияет на работу организации. Для предотвращения большого объёма использованных ресурсов используют алгоритмы сжатия, а также сочетание этого вида с другими: дифференциальным или инкрементным. Полное резервное копирование незаменимо в случае, когда нужно подготовить резервную копию для быстрого восстановления системы с нуля.
Дифференциальное резервное копирование (Differential backup)
При дифференциальном («разностном») резервном копировании каждый файл, который был изменён с момента последнего полного резервного копирования, копируется каждый раз заново. Дифференциальное копирование ускоряет процесс восстановления. Все копии файлов делаются в определённые моменты времени, что, например, важно при заражении вирусами.
Инкрементное резервное копирование (Incremental backup)
При добавочном («инкрементном») резервном копировании происходит копирование только тех файлов, которые были изменены с тех пор, как в последний раз выполнялось полное или добавочное резервное копирование. Последующее инкрементное резервное копирование добавляет только файлы, которые были изменены с момента предыдущего. Инкрементное резервное копирование занимает меньше времени, так как копируется меньшее количество файлов. Однако процесс восстановления данных занимает больше времени, так как должны быть восстановлены данные последнего полного резервного копирования, а также данные всех последующих инкрементных резервных копирований. В отличие от дифференциального копирования, изменившиеся или новые файлы не замещают старые, а добавляются на носитель независимо.
Клонирование
Клонирование позволяет скопировать целый раздел или носитель (устройство) со всеми файлами и каталогами в другой раздел или на другой носитель. Если раздел является загрузочным, то клонированный раздел тоже будет загрузочным[3].
Резервное копирование в виде образа
Образ — точная копия всего раздела или носителя (устройства), хранящаяся в одном файле[4].
Резервное копирование в режиме реального времени
Резервное копирование в режиме реального времени позволяет создавать копии файлов, каталогов и томов, не прерывая работу, без перезагрузки компьютера.[5]
Холодное резервирование
При холодном резервировании база данных выключена или закрыта для потребителей. Файлы данных не изменяются и копия базы данных находится в согласованном состоянии при последующем включении.[6]
Горячее резервирование
При горячем резервировании база данных включена и открыта для потребителей. Копия базы данных приводится в согласованное состояние путём автоматического приложения к ней журналов резервирования по окончании копирования файлов данных.[6]

Схемы ротации

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

Одноразовое копирование

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

Простая ротация

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

«Дед, отец, сын»

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

«Ханойская башня»

Схема призвана устранить некоторые из недостатков схемы простой ротации и ротации «Дед, отец, сын». Схема построена на применении нескольких наборов носителей. Каждый набор предназначен для недельного копирования, как в схеме простой ротации, но без изъятия полных копий. Иными словами, отдельный набор включает носитель с полной недельной копией и носители с ежедневными инкрементальными (дифференциальными) копиями. Специфическая проблема схемы «ханойская башня» — её более высокая сложность, чем у других схем.

«10 наборов»

Данная схема рассчитана на десять наборов носителей. Период из сорока недель делится на десять циклов. В течение цикла за каждым набором закреплён один день недели. По прошествии четырёхнедельного цикла номер набора сдвигается на один день. Иными словами, если в первом цикле за понедельник отвечал набор номер 1, а за вторник — номер 2, то во втором цикле за понедельник отвечает набор номер 2, а за вторник — номер 3. Такая схема позволяет равномерно распределить нагрузку, а следовательно, и износ между всеми носителями.

Схемы «Ханойская башня»[источник не указан 2493 дня] и «10 наборов» используются нечасто, так как многие системы резервного копирования их не поддерживают.

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

Причины утери информации

Эксплуатационные поломки носителей информации

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

Решение: хранить всю информацию (каждый файл) минимум в двух экземплярах (причём каждый экземпляр на своём носителе данных). Для этого применяются:

  • RAID 1, обеспечивающий восстановление самой свежей информации. Файлы, расположенные на сервере с RAID, более защищены от поломок, чем хранящиеся на локальной машине;
  • Ручное или автоматическое копирование на другой носитель. Для этого может использоваться система контроля версий, специализированная программа резервного копирования или подручные средства наподобие периодически запускаемого cmd-файла.

Стихийные и техногенные бедствия

Описание: шторм, землетрясение, кража, пожар, прорыв водопровода — всё это может привести к потере всех носителей данных, расположенных на определённой территории.

Борьба: единственный способ защиты от стихийных бедствий — держать часть резервных копий в другом помещении. В частности, помогает резервное копирование через сеть на компьютер, расположенный достаточно далеко (или в облачное хранилище данных).

Вредоносные программы

Описание: в эту категорию входит случайно занесённое ПО, которое намеренно портит информацию — вирусы, черви, «троянские кони». Иногда факт заражения обнаруживается, когда немалая часть информации искажена или уничтожена.

Борьба:

  • Установка антивирусных программ на рабочие станции. Простейшие антивирусные меры — отключение автозагрузки, изоляция локальной сети от Интернета, и т. д.
  • Обеспечение централизованного обновления: первая копия антивируса получает обновления прямо из Интернета, а другие копии настроены на папку, куда первая загружает обновления; также можно настроить прокси-сервер таким образом, чтобы обновления кэшировались (это всё меры для уменьшения трафика).
  • Иметь копии в таком месте, до которого вирус не доберётся — выделенный сервер или съёмные носители.
  • Если копирование идёт на сервер: обеспечить защиту сервера от вирусов (либо установить антивирус, либо использовать ОС, для которой вероятность заражения мала). Хранить версии достаточной давности, чтобы существовала копия, не контактировавшая с заражённым компьютером.
  • Если копирование идёт на съёмные носители: часть носителей хранить (без дописывания на них) достаточно долго, чтобы существовала копия, не контактировавшая с заражённым компьютером.
  • Использование носителей с однократной записью: CD-R, DVD-R, BD-R. Их объём недостаточен для серьёзных применений.

Человеческий фактор

Описание: намеренное или ненамеренное уничтожение важной информации — человеком, специально написанной вредоносной программой или сбойным ПО.

Борьба:

  • Тщательно расставить права на все ресурсы, чтобы другие пользователи не могли модифицировать чужие файлы. Исключение делается для системного администратора, который должен обладать всеми правами на всё, чтобы быть способным исправить ошибки пользователей, программ и т. д.
  • Построить работающую систему резервного копирования — систему, которой люди реально пользуются и которая достаточно устойчива к ошибкам оператора. Если пользователь не пользуется системой резервного копирования, вся ответственность за сохранность ложится на него.
  • Хранить версии достаточной давности, чтобы при обнаружении испорченных данных файл можно было восстановить.
  • Перед переустановкой ОС следует обязательно копировать всё содержимое раздела, на которой будет установлена ОС, на сервер, на другой раздел или на CD/DVD.
  • Оперативно обновлять ПО, которое заподозрено в потере данных.

Затруднения при резервном копировании

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

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

Технические меры защиты от копирования затрудняют резервное копирование независимо от законов и условий.

См. также

Ссылки

Примечания

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *