Windows Backup

Встроенная в ОС Windows технология Windows Backup предоставляет широкие возможности для создания резервных копий ОС и файлов, но ограничения, накладываемые пользовательским интерфейсом, не дают возможности реализовать их полностью. Так, ни одна из редакций Windows Backup не позволяет сохранять несколько версий резервных копий при работе с сетевым каталогом, а инструменты для управления политикой хранения локальных копий появились лишь в Windows Server 2012. До этого системные администраторы должны были полагаться на механизм автоматического удаления, который не всегда работал корректно .

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

Краткая история Windows Backup.

Windows Backup в его сегодняшнем виде появился в Windows Server 2008, придя на смену NTBackup, который присутствовал в линейке ОС Windows с Windows NT по Windows 2003. В нем отказались от работы на уровне файлов и перешли к работе на блочном уровне устройств хранения.

В своей первой реализации в Windows Server 2008 функциональность компонента Windows Backup была сильно ограничена и частично уступала даже NTBackup. Так, минимальной единицей резервного копирования был том, а для хранения бэкапов требовался выделенный диск, который при инициализации форматировался и не мог быть использован далее для других целей. В Windows Server 2008 R2 его возможности были значительно расширены: добавилась возможность резервного копирования отдельных файлов и каталогов, стала доступна комбинация объектов бэкапа (например, можно хранить в одной копии файлы/каталоги и System State) и появились инкрементные копии System State. Также была расширена интеграция с PowerShell.

В Windows Server 2012 добавили резервное копирование и восстановление отдельных виртуальных машин. До этого они могли быть сохранены лишь в составе резервной копии тома и отсутствовали инструменты для их индивидуального восстановления. Появилась возможность ротации локальных бэкапов, а также новые командлеты PowerShell.

Механизм работы Windows Backup

Для хранения резервных копий Windows Backup использует следующую схему именования <3аданный каталог> Windows lmageBackup<имя Компьютера>. В процессе резервного копирования выполняются следующие шаги:

> Windows Backup читает данные с исходных томов и создает по одному файлу VHD (VHDX в Windows Server 2012) на каждый том в заданном каталоге и файлы с метаданными.

> После окончания записи данных Windows Backup с помощью VSS (Volume Shadow Copy Sen/ice) создает теневую копию тома, на котором хранятся резервные копии. Эти копии хранят состояние тома на момент копирования и используются для версионирования бэкапов, то есть для каждого последующего бэкапа будет создана своя теневая копия, из которой бэкап может быть впоследствии восстановлен.

> Создав теневую копию, Windows Backup обновляет метаданные, записывая в них время создания резервной копии, идентификатор теневой копии и номер версии бэкапа, который используется далее командлетами PowerShell и утилитой командной строки Wbadmin.

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

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

Резервное копирование и ротация бэкапов System State и Bare Metal Recovery с помощью PowerShell.

Наибольший интерес из описанных выше режимов представляет создание бэкапов System State и Bare Metal Recovery.

В состав System State входят системные файлы, внутренние базы данных (такие, как реестр, объекты Active Directory и т.д.), и его удобно использовать для быстрого отката в случае проблем с ОС, например, сбойных обновлений. Размер копии состояния системы относительно невелик, и ее восстановление позволяет быстро вернуть работоспособность ОС в случае проблем.

В свою очередь, Bare Metal Recovery позволяет восстановить операционную систему целиком даже в случае полной потери данных, так как включает в себя все системные тома.

Для реализации автоматического резервного копирования System State и Bare Metal Recovery мною был написан скрипт, который позволяет:

Создавать резервные копии и управлять их ротацией с настраиваемыми параметрами независимо от того, на какой диск (локальный или сетевой) выполняется копирование.

Вести подробный журнал операций.

Отправлять отчеты по электронной почте.

Из-за ограничений функциональности серверной ОС Windows Server 2008 скрипт поддерживает только Windows 2008 R2 и Windows Server 2012.

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

Алгоритм работы

Алгоритм работы скрипта выглядит следующим образом:

Инициализировать пути для лог-файла и файла с настройками.

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

Создать и запустить задачу резервного копирования Windows Backup.

Отослать отчет на e-mail.

Основное отличие заключается в п. 3, где создаются задания для Windows Backup и происходит ротация резервных копий. Также изменился набор параметров, контролирующих процесс бэкапа и ротации в файле настроек, который состоит из двух секций: [Backup], где задаются параметры резервного копирования, и [Email], в которой указываются настройки почтового сервера для отправки отчетов.

Доступные опции в секции [Backup]:

BackupPath — путь к каталогу для резервных копий. Это может быть локальный диск (X:) или сетевой каталог (ServerShare).

IsNetworkBackup — тип хранилища для резервных копий (О — локальное, 1 — сетевое). Должен соответствовать заданному в опции BackupPath пути.

BackupType — тип резервной копии (0 — Bare Metal Recovery, 1 — System State).

MaxBackups — количество хранимых копий. Если установить в 0, то ротация будет отключена и старые бэкапы не станут удаляться.

Доступные опции в секции [Email]:

SendEmail — принимает значения 0 или 1. Контролирует отправку на электронную почту журнала работы скрипта.

Sender — почтовый ящик отправителя.

Receipt — почтовый ящик адресата.

Server — почтовый сервер.

Login — логин.

Password — пароль.

Port — порт почтового сервера, 25 по умолчанию.

SSL — принимает значения 0 или 1. Включите, если ваш почтовый сервер использует SSL/TLS. По умолчанию выключено.

TrustAnyCert — принимает значения 0 или 1. Отключает проверку сертификатов, если почтовый сервер использует самоподписанный сертификат или он не установлен в системе. По умолчанию выключено.

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

Первое, что необходимо сделать в начале скрипта, — подключить командлеты Windows Backup, которые находятся в отдельной оснастке. При этом проверяется результат, и, если оснастка не найдена, скрипт завершается.

се командлеты Windows Backup имеют префикс WB, и их полный список можно посмотреть командой Get-Command *-WB*.

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

Задания для службы резервного копирования являются политиками и создаются с помощью командлета New-WBPolicy.

Создаем политику $WBPolicy = New-WBPolicy

Write-Log «Создаем политику: $WBPolicy»

Политики имеют набор свойств, которые определяют параметры резервного копирования.

В эту политику нужно добавить как минимум путь к целевому каталогу/диску (BackupTargets) и в нашем случае предварительно созданные объекты для резервного копирования (SystemState или Bare Metal Recovery, BMR).

Объект целевого каталога создается командлетом New-WBBackupTarget.

После завершения резервного копирования проверяется результат его выполнения. Если значение свойства LastBackupResultHR у объекта, возвращаемого командлетом Get-WBSummary, равно 0, то бэкап выполнен успешно. В противном случае поле DetailedMessage будет содержать подробное сообщение об ошибке, которое записывается в лог. Если производилось копирование Bare Metal Recovery, сохраняется идентификатор теневой копии, узнать который можно из свойства Snapshotld объекта, возвращаемого ко-мандлетом Get-WBBackupSet. Этот идентификатор сохраняется функцией UpdateBmrLog и будет использоваться далее в процедуре ротации теневых копий.

Проверяем, успешно ли выполнен бэкап if (!(Get-WBSummary).LastBackupResultHR)

{

Write-Log «Бэкап завершился успешно» if ( (!$IsNetworkBackup) -and (!$BackupType))

{

# Получаем ID снэпшота для последнего бэкапа $CurrSnapshotId = (Get-WBBackupSet).Snapshotld I J

Select -Last 1

# Обновляем лог Bare Metal Recovery UpdateBmrLog «Add» $CurrSnapshotId

}

} else

{

$WBError = (Get-WBSummary).DetailedMessage Write-Log «Бэкап завершился с ошибкой!»

Write-Log «$WBError»

}

Windows Backup ведет собственные текстовые логи для каждого выполненного задания, которые хранятся в каталоге C:WindowsLogsWindowsServerBackupV Получить путь к ним также можно через свойства объекта, возвращаемого командлетом Get-WBJob.

# Записываем в лог результат работы задания Write-Log «Лог успешных операций Windows Backup: J $((Get-WBJob -Previous 1).SuccessLogPath)»

Write-Log «Jlor операций Windows Backup с ошибками: J $((Get-WBJob -Previous 1).FailureLogPath)»

Ротация резервных копий

К сожалению, в Windows Backup отсутствуют командлеты для удаления резервных копий. Поэтому нам придется реализовать такой механизм самостоятельно.

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

Для бэкапов System State эта задача решается использованием утилиты для работы с подсистемой резервного копирования Wbadmin. Команда delete systemstatebackup этой утилиты поддерживает ключ -keepversions, с помощью которого можно указать, сколько копий System State следует сохранить при удалении. Таким образом, ротация копий System State реализуется достаточно просто.

Write-Log «Делаем ротацию локальных бэкапов для System State»

# Получаем имя локального компьютера $SName=$env:ComputerName

# Удаляем бэкапы на локальном диске для System State

&WBADMIN DELETE SYSTEM STATE BACKUP -backupTarget:$Path J

-machine:$SName -keepVersions:$MaxBackups | Out-Null

Для проверки результата выполнения команды используется автоматическая переменная SLastExitCode, которая содержит код возврата, оставленный внешней утилитой.

# С помощью кода возврата проверяем, успешно ли удален бэкап if(!$LastExitCode)

Write-Log «Устаревшие бэкапы System State удалены»

} else {

Write-Log «Ошибка удаления бэкапов System State!»

}

Однако даже Wbadmin не включает в себя инструменты для удаления теневых копий, не являющихся бэкапами System State. Чтобы получить доступ к функциональности, предоставляемой службой теневых копий (Volume Shadow Copy Service, VSS), необходимо использовать утилиту DiskShadow. Она поддерживает два режима работы: интерактивный, когда команды вводятся пользователем внутри сеанса, и скриптовый, когда утилита построчно выполняет команды из файла.

Для просмотра списка всех снэпшотов диска используется команда list shadows all. Она отображает информацию о них, в том числе и Shadow Сору Ю . Это идентификатор теневой копии, представленный в виде GUID: уникального 128-битного идентификатора, генерируемого случайно, вероятность повторения которого очень мала.

Удалить теневую копию можно командой delete shadow, которая поддерживает различные ключи. Самым простым вариантом является использование delete shadows oldest <Имя-Тома>. В этом случае будет удален самый старый снэпшот для указанного тома. Запуском этой команды можно организовать примитивную ротацию со следующим алгоритмом:

> Получить количество теневых копий, запустив команду list shadows all и найдя в ее выводе строку «Number of shadow copies listed: X».

> Сравнить число теневых копий с заданным в файле конфигурации максимальным количеством бэкапов MaxBackups.

> Удалить необходимое число теневых копий, вызывая в цикле нужное количество раз delete shadows oldest с указанием тома из параметра BackupPath.

У такого подхода есть серьезный недостаток: если в промежутках между запуском скрипта были сделаны резервные копии через графический интерфейс Windows Backup, то при ротации они тоже будут удалены. Кроме того, list shadows all выводит общее количество теневых копий на компьютере, а нас интересует их число для отдельного тома.

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

Для этого используется тот факт, что после завершения резервного копирования можно получить идентификатор созданной в процессе теневой копии, о чем уже говорилось выше. Если сохранять список этих GUID, то мы сможем удалять только принадлежащие нам снэпшоты, используя команду delete shadows id (идентификатор). Проще всего сохранять GUID в текстовый файл и обновлять его после создания или удаления копий.

Работа со списком снэпшотов реализована в функции UpdateBmrLog. Она принимает два параметра, первый (SAction) указывает действие, которое необходимо выполнить с GUID (Add — добавить или Remove — удалить), а второй (SSnapshotldList) содержит идентификатор копии. Файл со списком GUID располагается в подкаталоге скрипта BMRJog и называется Имя Компьютера.1од. Это дает возможность переносить скрипт с компьютера на компьютер, сохраняя полную историю копий. Новые идентификаторы дописываются в конец файла: таким образом, в процессе работы первыми в списке оказываются самые старые GUID теневых копий .

При вызове функция проверяет наличие подкаталога BMRJog (имя каталога задается глобальной переменной в функции SetPaths и может быть изменено) и при необходимости создает его.

В зависимости от указанного действия GUID либо записывается в конец файла с новой строки, либо идентификатор удаляется из списка. Удаление из списка реализовано с помощью командлета Compare-Object, который принимает два объекта, сравнивает их и создает новый, в котором присутствуют только уникальные поля из первых двух.

В нашем случае первый объект — это список идентификаторов, прочитанный из файла, а второй — GUID, переданный функции. Полученный новый массив затем записывается в файл.

За физическое удаление теневых копий отвечает функция DeleteBmrSnapshot, принимающая в качестве параметра идентификатор снэпшота. Сначала она генерирует в системном каталоге %ТЕМР% временный файл со случайным именем, содержащий команду на удаление копии. Для генерации случайного имени файла используется метод [System. 10.Path]::GetRandomFileName() из .Net.

Затем функция вызывает утилиту DiskShadow в скриптовом режиме, передавая ей имя этого файла, и сохраняет ее код возврата в переменной SDelExitCode и вывод в переменной SDelOutput.

Далее проверяется код возврата, и в случае неудачи в лог записывается сообщение об ошибке, выданное DiskShadow. Функция возвращает True при успешном удалении теневой копии и False при возникновении ошибки.

Возвращаемое значение проверяется в функции ротации DoRotation, и при ошибке удаления снэпшота запись о нем не удаляется из файла лога.

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

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

[Backup]

BackupPath=D:

IsNetworkBackup=0

BackupType=l

MaxBackups=5

[Email]

SendEmail=l

Sender=WinBackup@mycompany.ru

Receipt=admin@mycompany.ru

Server=mail.mycompany.ru

Login=winbackup

Password=password

Port=25

SSL=0

TrustAnyCert=0

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

***

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

Like this post? Please share to your friends: