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

Acronis True Image Home.

Paragon Drive Backup Server Edition.

Symantec Backup Exec.

Windows System Recovery.

Для сетевого резервного копирования:

Paragon Drive Backup Enterprise Server Edition.

Acronis Backup & Recovery.

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

Paragon Drive backup Workstation.

Acronis True Image Home.

Обзор программы GFI backup

Общая характеристика.

Системные требования:

Microsoft Windows 7 (x86 или x64), Server 2008

(x86 или x64), Vista (x86 или x64), Server 2003 Standard/Enterprise

(x86 или x64), XP (x86 или x64)

Процессор - Intel Pentium 4 или подобный

Память - 512 Мб

Физическая память - 100 Мб для установки

Характеристики:

1. Безопасное и надежное резервное копирование и восстановление данных.

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

2. Синхронизация данных.

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

3. Резервное копирование на любое устройство хранения данных; резервное копирование через FTP.

GFI Backup позволяет выполнять резервное копирование на внутренние и внешние жесткие диски, на диски в локальной сети, сетевые устройства хранения данных, носители

CD/DVD/Bluray, переносимые устройства (USB-устройства, карты памяти, флэш-память, флоппи-диски, и т.д.), а также на удаленные расположения при помощи FTP с системой автоматического возобновления.

6. Использование стандартных Zip-архивов.

В отличие от остальных программ резервного копирования, GFI Backup не использует собственные форматы архивов, но использует стандартный формат Zip. Это позволяет

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

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

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

Организационные сложности по части защиты данных

• Внутренние противоречия в технической команде
• Администраторы приложений должны отвечать за сохранность данных, SLA и восстановление?
• Централизованный автоматизированный контроль – снижение рисков для ИТ директора: повышается прозрачность, предсказуемость ИТ процессов

Правильная стратегия защиты данных для ЦОДа

Устаревший подход под названием «РЕЗЕРВНОЕ КОПИРОВАНИЕ»

• Резервное копирование
• Восстановление

Современный подход под названием «УПРАВЛЕНИЕ ИНФОРМАЦИЕЙ»

• Резервное копирование
• Восстановление
• Аналитика по содержимому
• Контекстный поиск
• Мобильный доступ к данным
• Прозрачная интеграция с облаком
• Задачи ИБ
• ЛЮБЫЕ приложения сторонних разработчиков по обработке данных (Открытый API)

Проблема копий

• При отсутствии централизованного подхода количество данных неконтролируемо растет
• Где лежит самая актуальная версия данных?
• Если потребуется удалить данные по Compliance, где найти все копии?
• Удалениеи архивирование устаревшей информации. Как определить разумный критерий ценности данных?

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

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

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

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

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

Внесерверное копирование

Данный тип резервного копирования представляет собой дальнейшее развитие метода внесетевого копирования (LAN -free), поскольку уменьшает количество процессоров , памяти , устройств ввода-вывода, задействованных в этом процессе. Данный процесс архивирует разделы целиком, в отличие от пофайлового архивирования , но при этом позволяет восстанавливать отдельные файлы . По определению, при вне-серверном копировании данные копируются с диска на ленту и обратно без прямого участия сервера. Поскольку для резервного копирования требуется наличие некоторого дополнительного третьего узла, полностью отвечающего за процесс копирования, то отсюда происходит и другое название этого подхода - копирование с участием третьей стороны (Third_-Party Copy, 3PC). Так, в качестве подобного оборудования может использоваться маршрутизатор хранилищ данных, который берет на себя функции, ранее выполнявшиеся сервером.

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

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

Репликация данных

Современные дисковые массивы обладают средствами создания копий данных внутри самого массива. Данные, созданные этими средствами, носят название Point-In-Time (PIT)-копий, т. е. фиксированных на определенный момент времени. Существует две разновидности средств создания PIT-копий: клонирование и «моментальный снимок» (snapshot). Под клонированием обычно понимают полное копирование данных. Для него требуется столько же дискового пространства, как и для исходных данных, и некоторое время. При использовании такой копии нет нагрузки на дисковые тома, содержащие исходные данные. Иными словами, нет дополнительной нагрузки на дисковую подсистему продуктивного сервера.

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

Аналитическая компания Gartner в очередной раз провела исследование рынка решений резервного копирования данных для предприятий. Специалисты проанализировали условия развития направления резервного копирования, актуальные продукты, техники и решения для сохранения и восстановления данных физических и виртуальных серверов, приложений и т.д. Основные представители рынка были оценены по многим критериям. Лидерство в индустрии аналитики Gartner отдали таким компаниям: Commvault, Symantec, EMC и IBM. В качестве нишевых игроков на рынке были выделены Dell, Acronis, Asigra, FalconStor и другие.

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

РЕШЕНИЯ РЕЗЕРВНОГО КОПИРОВАНИЯ ОТ КОМПАНИИ SYMANTEC

Symantec в последнее время продолжает расширять внедрение интегрированных средств резервного копирования; появилось большее разнообразие функций (например, NetBackup Accelerator для быстрого резервного копирования и Instant Recovery для виртуальных машин VMware).

Сильные стороны Symantec:

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

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

РЕШЕНИЯ РЕЗЕРВНОГО КОПИРОВАНИЯ ОТ КОМПАНИИ ACRONIS

Предоставляет решения для малого и среднего бизнеса или отдельных подразделений предприятия. Предоставляется несколько вариантов услуг резервного копирования и удаленного хранения данных, основанных на облачных технологиях. Копии могут быть записаны в 5 разных хранилищах, включая Acronis Cloud или через FTP/SFTP в частное облако. Специальные технологии дают возможность полного или выборочного восстановления данных с поддержкой Exchange, Microsoft SQL Server и SharePoint, а также других сервисов Microsoft, VSS-совместимых программ и баз данных. Для ускорения процессов резервного копирования, дедупликация и сжатие на стороне источника комбинируются с постобработкой (индексирование, каталогизация) на стороне конечного объекта.

Сильные стороны Acronis: гибкая модель лицензирования, удобный интерфейс, поддержка любых типов миграции (V2V, V2P, P2V и P2P), поддержка 6 разных типов гипервизоров вне зависимости от приобретенной версии и т.д.

Специалисты предостерегают: Acronis может оказаться не очень подходящим для крупных компаний, а поддержка сетевых хранилищ данных (NAS) ограничена протоколами CIFS/NFS.

РЕШЕНИЯ РЕЗЕРВНОГО КОПИРОВАНИЯ ОТ КОМПАНИИ VEEAM

Veeam давно признанный пользователями лидер в сфере резервного копирования виртуальных машин. В данной области выигрывает у многих конкурентов, благодаря предоставлению особых функций (например, Veeam Explorer и Snapshot Hunter), простоте и надежности использования. В последнем релизе были добавлены такие важные для предприятий функции как: комплексное шифрование, усовершенствованный контроль резервного копирования, поддержка EMC Data Domain Boost, NetApp Snapshot, SnapMirror, SnapVault и другие.

Сильные стороны:

• Veeam Backup & Replication – надежное и многофункциональное решение для защиты данных виртуальных сред;
• Veeam предлагают одни из самых простых в использовании и недорогих продуктов для резервного копирования на уровне предприятий;
• Имеет множество положительных отзывов пользователей по опыту использования разных функций.

Специалисты предостерегают:

• поддерживает только VMware и Hyper-V, следовательно, резервное копирование для других гипервизоров или физических серверов не предлагается;
• Собственная дедупликация Veeam имеет довольно низкий коэффициент, требуя больше места для хранения резервных копий;
• Поскольку Veeam предлагают функцию U-AIR, то отдельно поддержка восстановления для таких решений, как Domino, MySQL и Oracle, пока не предоставляется.

РЕШЕНИЯ РЕЗЕРВНОГО КОПИРОВАНИЯ ОТ КОМПАНИИ COMMVAULT

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

Сильные стороны Commvault:

• единая административная консоль и механизм отчетов/аналитики для всех резервных копий (дата-центр, удаленный офис, приложения SaaS или ПК), архивирования, синхронизации и передачи файлов, поиска и функций предупреждения потери данных;
• целевые пакеты решений, многоплановая система лицензий Simpana и другие.

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

Специалисты предостерегают: цена приобретения и дальнейшей поддержки может быть довольно высокой.

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

1. Многие компании продолжают активно перестраивать свою систему резервного копирования, с целью найти самые современные решения для обработки новых типов данных, моделей хранения и увеличивающихся рабочих нагрузок, а также решить задачу ускорения процессов резервного копирования и восстановления.
2. Основными направлениями поиска методов улучшения являются применение дисковых решений, включая: резервное копирование напрямую на диск и дополнительно в облако, снапшоты массивов и реализацию репликации, виртуализацию серверов для резервного копирования, а также технологии максимально эффективной дедупликации данных.
3. Вендора стремятся разрабатывать множество различных решений резервного копирования, пытаясь удовлетворить разные по объекту защиты запросы пользователей: персональные компьютеры, сервера, удаленные офисы, виртуальные машины, различные приложения и база данных и т.д.).
4. Многие компании стремятся снизить стоимость владения своих продуктов и внедрять новые решения, которые были бы максимально просты в использовании.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На заметку 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 или программа ntbackup

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

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

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

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

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

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

Мне доводилось слышать фразу: «У нас очень надежное оборудование, везде стоят 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-сервера для выгрузки баз данных в файлы резервных копий. Еще одним плюсом является возможность использования различных программ и систем, лишь бы все они могли получить доступ к целевому ресурсу для хранения резервных копий.

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

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

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

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

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

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

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

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

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

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

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

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

Отдельно стоит сказать о мерах безопасности при организации хранения данных. В первую очередь необходимо позаботиться о том, чтобы носители с данными находились в охраняемом помещении, и о мерах, препятствующих прочтению данных посторонними лицами. Например, использовать систему шифрования, заключить договора о неразглашении и так далее. Если задействованы съемные носители, данные на них должны быть также зашифрованы. Используемая система маркировки при этом не должна помогать злоумышленнику в анализе данных. Необходимо применять безликую номерную схему маркировки носителей названий передаваемых файлов. При передаче данных по сети необходимо (как уже писалось выше) использовать безопасные методы передачи данных, например, 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 ().
6. Бережной А. Организуем систему резервного копирования для малого и среднего офиса. //Системный администратор, №6, 2009 г. – С. 14-23 ().
7. Маркелов А. Linux на страже Windows. Обзор и установка системы резервного копирования BackupPC. //Системный администратор, №9, 2004 г. – С. 2-6 ().
8. Описание VPN – http://ru.wikipedia.org/wiki/VPN .
9. Дедупликация данных – http://en.wikipedia.org/wiki/Data_deduplication .

Вконтакте

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

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

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

1. Структура папок проекта осталась без изменения - пропали только файлы.

2. На ленте резервного копирования (которое, кстати, выполнялось ежедневно) файлов обнаружено не было, хотя структура папок присутствовала в полном объеме.

	Необходимые меры для создания системы резервного копирования Система резервного копирования является одним из необходимых условий обеспечения непрерывности бизнеса. По данным Gartner, 43% компаний, пострадавших от катастроф и переживших крупную необратимую потерю корпоративных данных, не смогли продолжить свою деятельность. Для того чтобы система резервного копирования отвечала своему назначению и работала оптимальным образом, необходимо выполнить полный цикл проектных работ, что, впрочем, рекомендуется сделать для любой создаваемой системы. Полный цикл работ, направленный на создание или модернизацию системы резервного копирования, как правило, включает следующие этапы: Технический аудит вычислительной системы на предмет создания или модернизации системы резервного копирования; Разработка концепции системы резервного копирования - выработка рекомендаций по построению, модернизации и развитию системы резервного копирования. Данный вид работ не является обязательным, но рекомендуется для больших, динамически развивающихся систем; Проектирование системы резервного копирования - разработка технической и рабочей документации; Разработка плана-графика перехода со старой системы резервного копирования на новую. Данный вид работ необходим при модернизации системы резервного копирования, приведшей к значительному изменению существующей системы; Поставка и настройка оборудования и программного обеспечения; Разработка процедур эксплуатации - организация процессов эксплуатации системы резервного копирования, разработка регламентов и расписаний системы резервного копирования. Этот вид работ очень важен: без организованного должным образом процесса эксплуатации не будет эффективно работать ни одна система, в том числе система резервного копирования; Составление программы тренинга персонала заказчика по резервному копированию и восстановлению данных. Для системы резервного копирования тренинг персонала играет особую роль. Поскольку цель системы резервного копирования - восстановление данных после сбоев, то персонал, осуществляющий данную процедуру, будет работать в условиях внештатной ситуации и дефицита времени на восстановление работоспособности системы. Следовательно, выполнение операций восстановления данных должно быть доведено администраторами до автоматизма, что достигается только регулярной практикой.

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

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

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

	Требования к системе резервного копирования Поскольку любая современная информационная система строится на основе сети, система резервного копирования также должна быть сетевой, то есть обеспечивать сохранение данных, поступающих от всех узлов сети. В целом к сетевой системе резервного копирования выдвигаются следующие функциональные требования: Построение системы по принципу «клиент-сервер» . В применении к резервному копированию терминология «клиент-сервер» означает следующее: компонент системы резервного копирования, обеспечивающий управление всеми процессами и устройствами, называется сервером, а компонент, отвечающий за сохранение или восстановление конкретных данных, - клиентом. В частности, такая система должна обеспечивать: Управление с выделенных компьютеров резервным копированием во всей сети; Удаленное резервное копирование данных, содержащихся на серверах и рабочих станциях; Централизованное использование устройств резервного копирования. Многоплатформенность . Современная информационная сеть является гетерогенной. Соответственно и система резервного копирования должна полноценно функционировать в такой сети, то есть предполагается, что ее серверная часть будет работать в различных операционных средах и поддерживать клиенты на самых разных аппаратно-программных платформах. Автоматизация типовых операций . Процесс резервного копирования неизбежно содержит много циклов различных операций. Например, копирование может осуществляться каждый день в определенное время. Другой пример цикла — это процесс перезаписи информации на носителях резервных копий. Если ежедневная резервная копия должна храниться неделю, то по истечении этого срока соответствующий носитель можно использовать заново. Такой процесс последовательной замены носителей резервных копий называется ротацией. К циклическим работам относится и профилактическое обслуживание устройств резервного копирования, например чистка узлов лентопротяжного механизма стримера при помощи специальной кассеты по истечении определенного срока работы. Таким образом, система резервного копирования должна выполнять циклические работы в автоматическом режиме и минимизировать число ручных операций. В частности, она должна поддерживать: Выполнение резервного копирования по расписанию; Ротацию носителей; Обслуживание устройств резервного копирования по расписанию. Следует отметить, что автоматизация работ является одним из ключевых условий снижения затрат на сопровождение системы резервного копирования. Поддержка различных режимов резервного копирования . Предположим, что каждый день необходимо создавать резервную копию некоторого набора файлов, например содержащихся в одном каталоге. Как правило, в течение рабочего дня изменения вносятся лишь в отдельные файлы, вследствие чего ежедневное копирование информации, оставшейся неизмененной с момента создания предыдущей резервной копии, является излишним. Исходя из этого система должна обеспечивать различные режимы резервного копирования, то есть поддерживать возможность сохранения только той информации, которая была изменена с момента создания предыдущей копии. Быстрое восстановление серверов сети после аварии . Сервер сети может выйти из строя по различным причинам, например из-за аварии системного жесткого диска или вследствие ошибок программного обеспечения, приведших к разрушению системной информации. В этом случае его восстановление требует переустановки ОС, конфигурирования устройств, инсталляции приложений, восстановления файловой системы и учетных записей пользователей. Все эти операции очень трудоемки, и на любом из этапов данного процесса возможно возникновение ошибок. Таким образом, для восстановления сервера необходимо иметь резервную копию всей хранящейся на нем информации, включая системные данные, чтобы как можно быстрее привести его в рабочее состояние. Резервное копирование данных в интерактивном (on-line) режиме . Зачастую информационная система включает различные приложения «клиент-сервер», которые должны функционировать круглосуточно. Примером этого являются почтовые системы, системы коллективной работы (например, Lotus Notes) и SQL-серверы. Осуществить резервное копирование баз данных таких систем обычными средствами невозможно, поскольку они все время открыты. Поэтому в них часто встроены собственные средства резервного копирования, но их использование, как правило, не вписывается в общую технологию, принятую в организации. Исходя из этого система резервного копирования должна обеспечивать сохранение баз данных приложений «клиент-сервер» в интерактивном режиме. Развитые средства мониторинга и управления. Для управления процессами резервного копирования и отслеживания их состояния система резервного копирования должна иметь графические средства мониторинга и управления и широкий набор средств оповещения о событиях.

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

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

Чем же закончилась сия печальная история? А вот чем:

1. Было принято решение сохранять завершенные проекты на DVD.

2. Период ротации магнитных носителей был увеличен до трех месяцев.

3. Была разработана и принята политика хранения и резервирования информации в рамках всего холдинга.

P.S. Данные все-таки были найдены в одном из файловых залежей, коих немало в любой сети.