Резервное копирование Windows Server: состав и контроль

Опишите роль сервера и требования восстановления

Состав резервной копии определяется ролью, а не названием операционной системы. Файловый сервер, контроллер домена, узел Hyper-V, сервер IIS и система с SQL Server имеют разные данные, зависимости и поддерживаемые способы восстановления. Начните с перечня ролей, томов, приложений, баз, общих папок, сертификатов, задач планировщика, сервисных учётных записей и внешних интеграций.

Для каждой нагрузки согласуйте RPO — допустимую потерю изменений — и RTO — время возврата функции. Ежедневный backup не покрывает RPO в один час, а копия нескольких терабайт на медленном offsite-канале может не уложиться в короткий RTO. Разделяйте восстановление отдельного файла, приложения, целого сервера и площадки: для них нужны разные точки, инфраструктура и проверки.

Зафиксируйте порядок зависимостей. Например, приложение может требовать DNS, Active Directory, базу данных, сертификат и доступ к внешнему API. Образ сервера без этих компонентов не возвращает бизнес-функцию. Документация должна быть доступна при отказе домена и файлового сервера, а контакты ответственных — не храниться только в недоступной системе.

Разделите данные, System State и Bare Metal Recovery

Файловый backup защищает выбранные каталоги и удобен для гранулярного restore, но не восстанавливает всю конфигурацию ОС. System State включает набор компонентов, зависящий от установленных ролей: реестр, загрузочные файлы, COM+ и, для контроллера домена, Active Directory и SYSVOL. Он нужен для поддерживаемых сценариев восстановления системных компонентов, однако не равнозначен полному образу всех томов.

Bare Metal Recovery предназначен для восстановления системы на чистый диск или после потери загрузочных томов и включает критические тома. Его состав следует проверить командой wbadmin и сопоставить с фактическим размещением приложения. Если база или пользовательские данные находятся на некритическом томе, они могут не попасть в BMR автоматически и требуют отдельного включения.

Для контроллеров домена проектируйте backup вместе с планом восстановления AD, а не как обычного Windows-узла. Не возвращайте произвольный старый образ контроллера без понимания поддерживаемого процесса, VM-Generation ID и срока жизни удалённых объектов. Для леса должен существовать отдельный документ восстановления с выбранными копиями, учётными данными DSRM и порядком доменов.

wbadmin get status
wbadmin get versions
wbadmin get items -version:<идентификатор_версии>
wbadmin start systemstatebackup -backuptarget:E: -quiet

Пример с диском E: нельзя переносить в production без проверки: целевой том, retention и поддерживаемый сценарий зависят от архитектуры.

Обеспечьте согласованность через VSS и средства приложения

Volume Shadow Copy Service координирует создание согласованной точки между backup-программой, providers и writers приложений. Перед вводом задания проверьте состояние writers. Stable без ошибок — необходимый исходный признак, но пригодность копии подтверждает только restore. Failed writer не следует бесконечно лечить перезапуском: найдите связанный сервис, журнал событий и причину тайм-аута или ошибки.

Для SQL Server, Exchange и других транзакционных систем используйте официально поддерживаемый application-aware backup или собственный механизм приложения. Копирование файлов работающей базы может получить логически несогласованный набор. Уточните, кто управляет журналами транзакций и их усечением: несогласованные параллельные задания способны нарушить цепочку restore или заполнить диск.

Если резервируется виртуальная машина, проверьте поддержку guest processing, состояние integration services и поведение конкретного приложения. Crash-consistent snapshot похож на внезапное отключение питания и не всегда соответствует требованиям. Не создавайте долгоживущие checkpoints вместо backup: они зависят от исходного хранилища, растут и усложняют эксплуатацию.

• Все требуемые VSS writers присутствуют и не находятся в Failed.
• Метод backup официально поддерживается приложением.
• Определён владелец журналов транзакций и retention.
• Snapshot или checkpoint не считается независимой копией.

vssadmin list writers
vssadmin list providers
Get-WinEvent -LogName Application -MaxEvents 200 | Where-Object ProviderName -Match 'VSS|VolSnap'
Get-VMIntegrationService -VMName '<имя_ВМ>'

Разместите копии вне общего контура отказа

Backup на второй раздел того же диска не защищает от отказа устройства. Копия на NAS в той же стойке помогает при логическом удалении, но остаётся уязвимой для пожара, кражи и общей электропроблемы. Используйте локальный репозиторий для быстрого restore и отдельную offsite-копию для потери площадки; конкретная схема должна соответствовать RPO, RTO и объёму.

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

Шифруйте данные при передаче и хранении, особенно offsite. Ключи и recovery password храните независимо от резервируемого сервера и домена. Одновременно контролируйте их доступность: потеря единственного ключа делает restore невозможным. Процедура должна учитывать отзыв доступа администратора и аварийное использование ключа двумя ответственными, если этого требует политика.

Настройте задания, retention и наблюдаемость

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

Windows Server Backup подходит для определённых базовых сценариев, но его возможности хранения и централизованного контроля ограничены. Независимо от продукта проверяйте возраст последней точки, объём, длительность, VSS-ошибки, пропущенные источники, свободное место и целостность цепочки. Зелёный job, который копирует пустой каталог после изменения пути, формально успешен и практически бесполезен.

Оповещения направляйте в обслуживаемую систему, а не только на локальную консоль. Назначьте сроки реакции и эскалацию. Следите за журналами Microsoft-Windows-Backup, VSS, VolSnap и приложения. Автоматический retry может устранить временную ошибку, но повторяющиеся сбои нужно оформлять как проблему; иначе фактическое RPO незаметно увеличивается.

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

Get-WinEvent -LogName 'Microsoft-Windows-Backup' -MaxEvents 100
Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='VSS'; StartTime=(Get-Date).AddDays(-1)}
wbadmin get status
Get-Volume | Sort-Object SizeRemaining | Format-Table DriveLetter, SizeRemaining, Size

Проводите гранулярные и полные тесты восстановления

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

Полное восстановление сервера выполняйте в изолированной сети. Совпадающие имя, IP, SID приложения или расписание могут конфликтовать с production. Для контроллера домена следуйте отдельному поддерживаемому сценарию AD; простая загрузка копии рядом с рабочими DC не является безопасным тестом. Для Hyper-V отключите сетевой адаптер или подключите тестовый virtual switch до первого запуска.

Измерьте время получения offsite-копии, развёртывания ОС, восстановления данных, запуска зависимостей и функциональной проверки. Сравните сумму с RTO. Итог «сервер загрузился» недостаточен: пользовательская операция, доступ к файлам, запрос приложения или авторизация должны пройти по заранее заданным критериям.

1. Выбрать точку и записать ожидаемую дату данных.
2. Подготовить изолированную целевую среду без конфликтов.
3. Получить копию тем же способом, который доступен при аварии.
4. Восстановить систему и зависимости по инструкции.
5. Проверить данные, права, приложение и журналы.
6. Зафиксировать фактические RPO/RTO и обновить регламент.

Соберите эксплуатационный регламент

В регламенте укажите системы, владельцев, состав копирования, расписание, retention, репозитории, шифрование, RPO/RTO, каналы оповещения и инструкции restore. Секреты не помещайте в открытый документ; вместо них укажите защищённое хранилище и процедуру аварийного доступа. Версии backup-агента, ОС и приложения также важны для совместимости восстановления.

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

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

• Все роли, тома и приложения явно включены или исключены с причиной.
• System State и BMR используются по подходящему сценарию.
• VSS writers и application-aware обработка контролируются.
• Есть независимая offsite или immutable-копия.
• Ключи доступны без production-домена.
• Restore проверяет бизнес-функцию и измеряет время.