Глава 7. Сохранение и восстановление данных с помощью программы Acronis True Image Home В настоящее время на рынке представлено множество самых разных продуктов, предназначенных для резервного копирования и восстановления данных, и с некоторыми из них мы уже познакомились в

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

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

Резервная копия данных: Что это?

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

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

Резервная копия системы

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

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

Создание резервной копии и восстановление данных с помощью Windows

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

История файлов

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

Чтобы настроить Историю файлов перейдите в меню Пуск и выберите Параметры. В открывшемся меню Параметров войдите в меню Обновление и безопасность / Служба архивации.

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

Во время создания бэкапа История Файлов также автоматически копирует все папки учётной записи пользователя: Изображения, Документы, Загрузки и т.д.

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

По умолчанию установлено резервное копирование файлов каждый час. Минимальное время, которое возможно установить – 10 минут, максимальное - Ежедневно. Также можно установить длительность хранения копий: от одного месяца до момента пока не понадобится свободное пространство (в таком случае более давние резервные копии будут удаляться автоматически, для освобождения места для новых бэкапов).

Восстановление файлов из резервной копии

Чтобы восстановить файлы из диска с резервной копией данных перейдите в Панель управления и Выберите меню История файлов.

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

Облачный сервис OneDrive

Ещё одним способом обезопасить себя от утери важных файлов, это перенести их в облачное хранилище и синхронизировать его с компьютером. Таких хранилищ существует много: Dropbox, Google Drive и т.д. Но особенностью последних версий Windows (10, 8, 8.1) есть наличие собственного встроенного в операционную систему облачного сервиса Microsoft, который называется OneDrive .

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

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

Точка Восстановления

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

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

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

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

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

Чтобы восстановить Windows из точки восстановление перейдите в Панель управления и выберите меню Восстановление / Запуск восстановления системы, выберите необходимую Точку восстановления и нажмите Далее.

Образ системы

Наверное, самой основной и сложной функцией резервного копирования Windows есть функция под название Образ системы.

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

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

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

Чтобы восстановить систему из Образа системы перейдите в меню Параметры системы / Обновление и безопасность / Восстановление, и выберите особые варианты загрузки. После того как Windows 10 перезагрузится, выберите в предложенном меню пункт Восстановление системы из образа.

Другие программы для резервирования и восстановления файлов Windows 10

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При небольших объемах данных и не очень сложной ИТ-инфраструктуре можно попытаться совместить обе эти задачи в одной, например, делать ежедневное полное копирование всех дисковых разделов и баз данных. Но все же лучше различать две цели и подбирать под каждую из них правильное средство. Соответственно под каждую задачу используется свой инструмент, хотя есть и универсальные решения, как тот же пакет 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 и при крахе файловой системы в результате несанкционированной перезагрузки.

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

Вконтакте

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

Вызовы в розничной торговле

Заказчик: крупная страховая компания.

Краткое описание причины аварии: ошибка персонала, неправильная установка патча на Oracle.

Описание проблемы

Речь идет о крупной компании, которая имеет зрелое ИТ-подразделение и вкладывает достаточно средств в его оборудование и персонал. Достаточно сказать, что СУБД Oracle работала на двух Oracle Exadata, распределенных по двум технологическим площадкам, с проработанным DR-решением и настроенной системой резервного копирования.

В один печальный день было принято решение установить патч на СУБД Oracle. К сожалению, инженер не дочитал инструкцию до конца: «Что я, патч не установлю без бумажки?!» - и неправильно сделал это. Ошибку заметили через несколько часов, когда СУБД стала вести себя странно и сообщать об этом в журналах. Тогда инженер принял решение откатиться. Это действие окончательно обездвижило оба экземпляра базы (все изменения успели отреплицироваться на Standby) и испортило все данные.

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

Решение

Заказчик принял решение восстанавливаться из резервной копии. В то время восстановление базы в 5 ТБ (сейчас ~15 ТБ) заняло - внимание! - более 30 часов! Итого, через 1,5 дня восстановили базу на день раньше аварии. Но данных-то было больше! Все остальное силами программистов и персонала восстанавливали из других систем компании, из первичной документации (бланков заявлений, копий, сканов). На это ушло еще 1,5 дня напряженной работы.

Итого

2 High-End системы Oracle Exadata, Oracle Standby, работающая система резервного копирования и 3!!! дня полного простоя при неправильной установке патча. Было ли это допустимо согласно регламенту компании? Конечно же, нет.

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

Как можно было избежать

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

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

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

Continuous Data Protection - непрерывная защита данных. Это проприетарные устройства или ПО, позволяющее логировать все записи с возможностью отката на любую точку во времени. Действует аналогично Oracle FlashBack, но для любых данных.

Кейс: Аппаратный сбой

Заказчик: Федеральная служба в одном из субъектов РФ

Краткое описание причины аварии: аппаратная ошибка внутри дискового массива.

Описание проблемы

В этот раз у компании чуть менее развитая ИТ-инфраструктура, зато чаще встречающаяся у наших заказчиков: дисковые массивы среднего уровня, СУБД Oracle, Standby не используется.

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

Решение

Заказчик принял решение о восстановлении из резервной копии. Этот процесс занял примерно сутки, несмотря на все ухищрения и тюнинг производительности (база довольно большая). Пока восстанавливалась БД, резервная копия логов была утеряна (был выставлен слишком маленький Retention Period, СРК удалила их сама).

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

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

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

Итого

Проблема с массивом вызвала потерю данных и простой около недели! В современных условиях это может привести к банкротству компании.

Основные проблемы:

• СРК была настроена неверно, пробные восстановления не проводили.
• Не было средств оперативного восстановления в случае аварии и дублирующих систем.
• Не было четкого DR-плана.

Как можно было этого избежать:

• Использовать Oracle Standby, расположенный на другом массиве. Это позволило бы в течение непродолжительного времени переключиться на работающий экземпляр данных.
• Oracle ZDLRA позволил бы в гораздо более сжатые сроки восстановить БД на резервном оборудовании.
• Грамотные планирование процессов резервного копирования и восстановление позволили бы избежать таких больших потерь и восстановиться менее чем за сутки.

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

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

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

Скорость резервного копирования и последующего восстановления

На данный момент скорость backup прямо пропорциональна объему данных, при этом у всех наших заказчиков годовой рост данных не менее 30%. За 3–4 года данные как минимум удваиваются, но у некоторых компаний этот показатель даже выше, при этом за то же время скорость резервного копирования не меняется вовсе. Здесь можно сделать простой вывод, что те сроки и те SLA, которые были 3–4 года назад актуальны, сейчас нужно увеличивать как минимум вдвое. При этом требования бизнеса к восстановлению данных (RPO/RTO) постоянно растут.

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

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

Зависимость времени восстановления от объема данных

Низкая гранулярность восстановления

Фактически большинство ошибок связано с потерей какой-то части данных. При этом традиционные средства резервного копирования позволяют восстанавливать данные напрямую из backup, но чаще приходится восстанавливать систему целиком. Если ваша база данных занимает 15 ТБ, вы потратите на это несколько суток. Заказчиков, у которых требование RTO (Recovery Time Objective) - 2 дня, мы не знаем. В нашей практике таких примеров не было, когда бы клиент сказал: «Ребята, восстанавливаться 2 дня - это нормально, я потерплю», - если администратор случайно удалил несколько строк из базы данных. Довольно частая проблема, с которой сталкиваются наши клиенты: как вычленить небольшой кусочек данных из резервной копии, не восстанавливая ее саму (и не тратить на это несколько суток).

Чрезмерное RPO (Recovery Point Objective)

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

Скрытые ошибки

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

Увы, большинство наших клиентов этим не занимается. Часто складывается такая ситуация, что все делают резервные копии, но к моменту восстановления, оказывается, что их можно было не делать - они просто не восстанавливаются, несмотря на внешне правильную работу СРК. Это происходит по различным причинам. И лучше всего это можно продемонстрировать на примере. Один наш заказчик использовал систему SAP с базой данных Oracle. Резервное копирование осуществлялось встроенными средствами SAP с помощью одного из крупнейших вендоров СРК.

Были настроены 2 разные политики резервного копирования: одна из них файловая - копировала данные операционных систем и настройки ПО, а вторая - саму базу данных. Поскольку они были направлены на одну и ту же систему, был настроен список исключений, в который занесли базу данных. Файловая политика учитывала этот список и не резервировала те директории, в которых лежала БД. Из-за особенностей архитектуры СРК, политика резервирования БД игнорировала список исключений и корректно копировала нужные данные.

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

Таким образом, все работало больше полугода. До того момента, пока не понадобилось восстановиться...

Несистемный подход

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

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

Чтобы проверить, насколько системно вы подошли к вопросу построения СРК, ответьте на несколько простых вопросов:

• Есть ли у вас выстроенная модель рисков, в рамках которой прописано место СРК?
• От каких сбоев вас защищает СРК?
• Как вы защищаетесь от остальных рисков (это могут быть не просто технические решения, но и другие компенсационные меры)?
• Уверены ли вы в том, что система восстановится в установленные сроки?
• Проверяли ли вы это на практике?

Решение

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

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

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

Другим решением может быть использование различных средств приложений, например, Oracle Standby, DB2 HADR, MS SQL Always On. Все эти средства позволяют иметь работающую копию продуктивной системы, отвязанную от исходной, которую можно развернуть мгновенно. Это позволяет начать работу сразу после сбоев.

Второе - дать возможность восстанавливать только нужные данные. Наш подход учитывает, что при восстановлении части данных нам не требуется копировать всю систему целиком, мы можем восстановить данные, которые нам нужны на данный момент. Это достигается возможностью быстро развернуть либо использовать уже развернутые системы, которые эти данные содержат. Так же как и в первом случае, snapshot позволяют решить эту проблему (можно быстро открыть snapshot на соседний сервер и вытянуть необходимый кусочек данных). Сюда же можно отнести технологии непрерывной защиты данных, например, Oracle Standby с Flashback, решения continuous data protection (CDP). Они позволяют быстро развернуть работающую копию данных на нужный момент времени.

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

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

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

Для наиболее критичных систем временного интервала может не быть совсем – данные нужно защищать непрерывно. Существует несколько решений этого класса, например, Oracle Standby с FlashBack, который позволяет откатить базу данных на некоторое время назад благодаря логированию всех изменений. Также можно использовать ПАК Oracle ZDLRA, который практически синхронно получает все изменения в БД, либо программно-аппаратные комплексы общего назначения, например, EMC RecoverPoint, ПО Vision Solutions Double-Take. Они тоже логируют все изменения и позволяют восстановиться на любую точку в интервале времени.

Если говорить об инновациях в системах резервного копирования и восстановления, нельзя не упомянуть Oracle Zero Data Loss Recovery Appliance (ZDLRA). Этот программно-аппаратный комплекс семейства Oracle Engineered Systems предоставляет возможность резервного копирования и быстрого восстановления Oracle Database любых платформ и любых Edition (Enterprise и Standard). В основе ZDLRA лежат виртуальные backup-базы (Virtual Full Backup), получаемые на основе первого полного backup и последующих журналов изменений. За счет этих виртуальных backup можно восстановить базу данных на любой момент времени значительно быстрее, чем при классическом использовании СРК по схеме «раз в неделю полный backup, раз в сутки инкрементальный». Можно сказать, что ZDLRA продолжает направление, заданное Oracle Exadata. В Exadata за счет специального Software реализована инновационная система хранения, оптимизированная под задачи Oracle Database. А в ZDLRA функционирует специальное Software, оптимизирующее резервное копирование именно Oracle Database.

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

Четвертое - уменьшение скрытых ошибок. Существует только один способ убедиться в корректной работе резервной копии - попробовать ее восстановить. Это самый правильный и редко используемый нашими заказчиками метод.

Но мы предлагаем выход и из этой ситуации. Во-первых, иметь легко восстанавливаемые экземпляры систем. Это опять история о snapshot- и standby-системах, которые можно достаточно быстро развернуть и проверить. Времени и сил это займет несравнимо меньше, чем «разматывание» всей резервной копии. Конечно, это помогает далеко не всегда, но оставляет чуть больше надежды, что в случае ЧП будет можно восстановить данные хотя бы этими средствами.

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

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

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

• Второй способ, когда заказчик не уверен, что сможет поддерживать систему СРК постоянно в боевом состоянии, выходом будет передача системы на частичный либо полный аутсорсинг. И у нас есть такие клиенты, которые успешно пользуются данной услугой, постоянно наращивая и требования SLA, и масштабы вовлеченности нас как ИТ-аутсорсера.

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