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




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

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

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

Этот кошмар остался в прошлом с появлением в программах для бэкапов поддержки HAL – слоя абстрагирования оборудования. За счёт него была реализована возможность добавлять драйверы сетевых или запоминающих устройств «на лету» и выполнять процедуру восстановления на других аппаратных конфигурациях. Acronis называет такой подход Universal Restore. Одноимённый компонент среды восстановления бесплатно включён во все последние версии продуктов Acronis.

Acronis Universal Restore может быть записан на загрузочный носитель одного из двух типов: простой универсальный (на базе GRUB с поддержкой EFI) или на основе среды Win PE с подключаемым модулем Acronis. Первый вариант оптимален в простых ситуациях (Linux, 32-битные системы без UEFI), а второй поддерживает 64-разрядные системы и загрузку UEFI. Второй способ предпочтителен для добавления драйверов Windows для новых устройств прямо в среде восстановления. Команда их установки перед первым запуском будет автоматически добавлена в реестр восстановленной ОС.

С помощью Universal Restore даже самую сложную систему можно целиком восстановить на любом подходящем железе: на том же сервере после его апгрейда, на совершенно другом или вообще виртуальном – лишь бы места хватало. Отсутствие привязки к определённому оборудованию не просто развязывает руки системным администраторам, а позволяет гибко менять всю ИТ-инфраструктуру предприятия соответственно текущим задачам. Данный подход используется для тиражирования стандартных рабочих мест, упрощения консолидации, переноса реальных серверов на виртуальные и обратно.

Конечно, как и любая технология, Universal Restore имеет свои ограничения. При создании диска восстановления на базе WinPE v.3.0 потребуется пакет автоматической установки Windows (AIK), а для WinPE более новых версий – пакет развертывания и оценки Windows (ADK). В обоих вариантах загрузочный носитель должен быть отформатировать в FAT32. Через Universal Restore добавляются только драйверы устройств, необходимых для успешной загрузки – дисковых и сетевых контроллеров, чипсета материнской платы. Остальные инсталлируются обычным способом уже после запуска восстановленной операционной системы.

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

Выводы:
• современные средства управления бэкапами не имеют привязки к железу;
• драйверы новых устройств для Windows можно добавить прямо в среде восстановления, если она поддерживает HAL;
• среда восстановления может быть создана для разных конфигураций, в том числе с поддержкой UEFI и 64-разрядных систем;
• Acronis Universal Restore позволяет выполнить полное восстановление сервера из резервной копии даже после его апгрейда или замены;
• Механизм универсального восстановления можно использовать также для клонирования любых систем, переноса физических серверов в виртуальные и наоборот.

Так же на эту тему можно послушать мои вебинары «Бэкап и защита данных».

Не забывайте качественно бэкапиться, друзья!

Комментарии (1)


  1. zirf
    25.02.2016 13:40
    +1

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

    1. Установка на "bare metal". С учетом распространенности и доступности различных систем виртуализации уже на этапе развертывания отвязывает систему от железа. Задача резервного копирования интегрируется с задачами миграции между физическими хостами и собственно развертывания.
    2. Игнорирование специфики структуры данных. Скажем так, для СУБД схема резервного копирования должна быть разработана вместе со структурой базы. Если это сделать, то головной боли не будет.
    3. "Высшая мысль": уже для бизнеса — оценить стоимость информационных активов (данных), чтобы четко представлять себе расходы на их целостность, доступность и конфиденциальность. На практике обычен анекдот "Сколько стоят данные?", "Стопитсотмильенов.", "Сделаем, 10% от стоимости", данные тут же обесценятся со скоростью света.