Резервное копирование физических серверов начинается с RTO

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

Противопоставление «Veeam Agent или полный образ» сбивает с толку. Режим Entire computer в Veeam Agent как раз создает образ на уровне томов. Полезный выбор звучит иначе: какие тома и состояние приложений попадут в копию, на какой платформе сервер должен запуститься после аварии и сколько времени организация готова ждать.

Veeam Agent и полный образ не являются альтернативами

Полный образ описывает охват и уровень копирования, а Agent описывает механизм, который работает внутри защищаемой операционной системы. В Veeam Agent for Microsoft Windows режим Entire computer относится к резервному копированию на уровне томов: агент читает блоки томов из снимка VSS, сжимает данные и пишет их в целевое хранилище. Первая сессия создает полный файл VBK, последующие обычно добавляют инкрементальные файлы VIB с новыми или измененными блоками.

Документация Veeam разделяет три режима. Entire computer захватывает образ компьютера со всеми поддерживаемыми томами и системными разделами. Volume level backup позволяет явно выбрать нужные тома. File level backup сохраняет выбранные папки и годится для возврата файлов, но не дает основы для bare metal recovery. Когда в volume-level задании выбран системный том Windows, агент автоматически добавляет служебный раздел System Reserved или EFI, если администратор намеренно не исключил его.

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

Есть и менее очевидная причина не выбирать file level ради экономии. Руководство Veeam предупреждает, что файловое копирование обычно медленнее volume-level и создает больше сетевого трафика. При инкременте измененный большой файл может уйти целиком, тогда как копирование тома передает изменившиеся блоки. Для файлового сервера с миллионами небольших объектов это нужно проверить на собственном наборе данных, но считать файловый режим автоматически более компактным нельзя.

Сначала выберите место, где сервер должен ожить

Правильный режим определяется целевой точкой восстановления, а не привычкой администратора. Для каждой физической машины нужно письменно выбрать основной и запасной сценарии: возврат на исходный сервер, перенос на замену или временный запуск в виртуальной среде. Один и тот же volume-level backup может поддержать все три, однако инфраструктура и время у них разные.

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

Instant Recovery через Veeam Backup & Replication запускает резервную копию физической Windows- или Linux-машины как VM на VMware vSphere либо Hyper-V. Система читает виртуальные диски прямо из сжатых резервных файлов, а изменения пишет отдельно. Такой сервер можно поднять до полного переноса на продукционное хранилище, но документация прямо указывает на ограниченную I/O-производительность временной VM. Это аварийный мост, а не постоянное размещение.

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

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

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

Другое железо проверяет загрузочную цепочку, а не бренд корпуса

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

Veeam Recovery Media для Windows строится на Windows RE. При создании оно может включить установленные драйверы дискового контроллера, сетевого и USB-контроллеров, а также сетевые настройки. Дополнительные INF-драйверы можно добавить заранее или загрузить во время восстановления. Носитель, созданный на исходном сервере несколько лет назад, не обязан знать контроллер новой машины, поэтому рядом с ним нужен проверенный пакет драйверов для резервного оборудования.

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

Особенно опасна молчаливая смена BIOS/MBR на UEFI/GPT или обратно. Recovery Media может восстановить разделы, однако прошивка должна загружать получившуюся схему. Перед закупкой резервного сервера зафиксируйте текущий режим загрузки, тип таблицы разделов, назначение каждого диска и настройки контроллера. После восстановления проверьте порядок загрузки, а не начинайте сразу чинить Windows.

Драйвер, с которым среда восстановления увидела массив, еще должен попасть в восстановленную ОС. Мастер bare metal recovery умеет внедрять загруженные драйверы в Windows. Если отключить эту опцию или подать неподходящий пакет, копирование завершится успешно, но система получит ошибку при первом старте. Это хороший пример копии, которая технически цела и операционно бесполезна.

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

RTO складывается из действий, которые редко замеряют

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

Для bare metal полезна простая оценка нижней границы:

T_restore = T_detect + T_prepare + Data_to_restore / Effective_throughput + T_boot + T_app_check

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

Предположим, на томах занято 2,4 ТБ, а тест показал устойчивое восстановление 180 МБ/с. Одно копирование в идеальных условиях займет около 3 часов 43 минут. Это расчетный пример, а не обещание производительности Veeam: параллельная нагрузка на репозиторий, сеть, дедупликация, шифрование и мелкие блоки меняют результат. Если согласованный RTO равен двум часам, покупка более быстрого диска может не спасти проект, потому что сам выбранный путь не помещается в окно.

Instant Recovery сокращает время до первой загрузки, поскольку не ждет полного извлечения образа. Зато репозиторий становится частью работающего сервиса и получает случайную I/O-нагрузку. Перед тем как обещать короткий RTO, запустите копию из нужного класса хранилища, выполните типичную операцию приложения и затем перенесите VM на продукционное хранилище. Время фоновой миграции тоже входит в план, даже если пользователи уже работают.

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

RPO надо считать отдельно. Ежедневное задание, которое завершилось в 02:00, после отказа в 17:00 допускает потерю почти рабочего дня изменений. Частота инкрементов, обработка журналов базы и репликация приложения определяют эту потерю. Быстрый запуск старой копии выполняет RTO и проваливает RPO.

Объем хранилища определяет изменение данных, а не размер RAID

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

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

Repository = Full_used × K_full + Daily_change × K_increment × Restore_points + Extra_fulls + Safety_space

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

Цепочка имеет значение. Veeam хранит первый полный VBK и последующие VIB; для восстановления точки нужны полный файл и связанные с ним инкременты. Удаление отдельного VIB вручную разрывает цепочку. Retention policy должна удалять точки штатно, а мониторинг свободного места должен предупреждать до того, как задание остановится посреди новой точки.

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

Не смешивайте логическую емкость и аварийную пропускную способность. Репозиторий может вместить год точек и при этом слишком медленно отдавать образ для нужного RTO. Если план включает Instant Recovery, проверьте задержку под рабочей нагрузкой и одновременное выполнение обычных заданий. Иногда разумнее хранить меньше быстрых точек на основном репозитории и более длинную историю на другом уровне, но это решение должно сохранять требуемые RPO и независимость копий.

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

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

Согласованность приложения важнее полного набора блоков

Полный образ дисков не гарантирует, что база данных или каталог корректно откроется. Для Windows Veeam Agent запрашивает снимок Microsoft VSS, а application-aware processing координирует VSS-aware приложения и обработку журналов. Руководство Veeam отдельно указывает Microsoft SQL Server, Exchange, SharePoint и Oracle среди приложений, для которых нужна такая обработка.

Есть три разных состояния копии. Crash-consistent образ похож на диски после внезапного отключения питания: файловая система и приложение должны выполнить собственное восстановление журналов. VSS-consistent снимок фиксирует согласованное представление томов. Application-consistent копия дополнительно учитывает состояние приложения и выбранную политику его журналов. Называть их одинаково «целостным образом» опасно, потому что время и вероятность успешного старта различаются.

Если приложение не поддерживает VSS, как MySQL в приведенном в документации Veeam примере, агент не может магически сделать его транзакционно согласованным. Нужны поддерживаемый приложением способ snapshot, pre-freeze и post-thaw scripts либо отдельная резервная копия базы. Скрипт должен завершать задание ошибкой, если подготовка не удалась; запись предупреждения, после которой образ продолжают считать пригодным, маскирует риск.

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

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

Носитель восстановления и паспорт сервера надо обновлять вместе

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

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

Get-Disk | Select Number,FriendlyName,SerialNumber,PartitionStyle,Size,HealthStatus
Get-Partition | Select DiskNumber,PartitionNumber,DriveLetter,Type,Size
Get-NetAdapter | Select Name,InterfaceDescription,MacAddress,Status,LinkSpeed
reagentc /info
vssadmin list writers

У Get-Disk ожидайте таблицу с номером диска, моделью, серийным номером, стилем GPT или MBR, размером и состоянием. reagentc /info показывает статус Windows RE и путь к образу восстановления. vssadmin list writers перечисляет VSS writers и их состояния; перед резервированием серверных приложений состояния должны быть стабильными без постоянных ошибок. Сохраните вывод вне защищаемого сервера и обновляйте после изменения железа или разметки.

Практическая проверка Recovery Media состоит из пяти действий:

1. Загрузить исходный или резервный сервер с носителя в том же режиме UEFI или BIOS, который предусмотрен планом.
2. Убедиться, что видны все целевые диски и сетевые интерфейсы; при необходимости загрузить подготовленный INF-драйвер.
3. Подключиться к репозиторию по штатному аварийному пути и открыть зашифрованную цепочку без учетных данных из памяти одного сотрудника.
4. Дойти до экрана сопоставления дисков, записать выбранную схему и остановиться до перезаписи, если это только проверка носителя.
5. В отдельном учебном окне выполнить полное восстановление, загрузить систему в изолированной сети и сохранить фактические времена этапов.

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

Проверка файла и проверка восстановления отвечают на разные вопросы

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

SureBackup для поддерживаемых Veeam Agent backups публикует машину в изолированной виртуальной среде и проверяет восстановимость. Документация разрешает проверять точки Windows- и Linux-компьютеров, но перечисляет ограничения, в том числе для file-level backups, failover clusters, отдельных схем системного и загрузочного разделов, некоторых дисков и мест хранения. Перед включением задания надо сопоставить ограничения с конкретным сервером, а не считать функцию универсальной.

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

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

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

Решение фиксируют для каждого сервера, а не для продукта

Для большинства одиночных физических Windows-серверов базовой политикой будет Entire computer или volume-level backup со всеми загрузочными и прикладными томами, application-aware processing и готовым Recovery Media. Если нужен очень короткий RTO, к нему добавляют проверенный Instant Recovery на доступный гипервизор. Файловое копирование оставляют для узких наборов данных, когда полный возврат системы сознательно не требуется.

Универсального выбора нет. Сервер с аппаратным измерительным адаптером разумно возвращать на заранее совместимое физическое шасси. Обычный сервер приложений часто быстрее переживает аварию как временная VM. Большая база может потребовать образ ОС плюс собственную схему backup и point-in-time recovery, потому что частота образов не дает нужный RPO.

Запишите решение в одну строку на машину: «основной путь, запасной путь, RTO, RPO, точка хранения, Recovery Media, владелец теста». Затем подтвердите его полным упражнением. Если фактическое время не помещается в RTO, меняйте архитектуру: добавляйте вычислительный резерв, ускоряйте репозиторий, сокращайте объем восстановления или выбирайте виртуальный аварийный запуск. Переписывание цифры в регламенте не ускоряет чтение данных.

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

Спор «Agent или образ» можно закрыть после первого же испытания. Если команда загрузила копию на предусмотренной запасной платформе, измерила время и проверила приложение, у нее есть рабочий способ восстановления. Если испытания не было, название режима в консоли ничего не гарантирует.