Бэкап данных windows server 2008 r2

The Windows Server Backup feature of Windows Server 2008 R2 includes an enhanced Windows PowerShell Snap-in that can be used to manage and control Windows Server backups. But before you can use the Snap-in, you need to enable the feature on Windows Server,
and then load the snap-in.

Once the feature is enabled, and the snap-in loaded, you then build the backup policy a step at a time. Once the policy has been built, you set the new policy as the system backup policy.

Alternately, if the server has an existing backup policy, you can modify it by changing what is backed up, or what the backup target is, by opening the existing policy in edit mode.

1.) Enable Windows PowerShell Support for Windows Server Backup

2.) Create /Get/Edit Policy (Schedule) 
The backup is controlled by the WBPolicy. This policy includes all the information necessary to perform a backup, including the backup schedule. You can create a new policy, retrieve an existing policy, or open an existing policy in edit mode to change it.

3.) Include Volumes in the Backup
Create individual WBVolume objects by selecting on the MountPath (or other property) of the volume. Combine WBVolume objects as a list and add to the WBPolicy with Add-WBVolume.

4.) Exclude Files/Folders from Backup
Next, create a new WBFileSpec object for each exclusion or inclusion. Inclusions and exclusions are assumed to be recursive unless -nonrecursive is specified. If no inclusions or exclusions are specified for a volume that is included, then the entire
volume is assumed. Add all the WBFileSpec objects as a list to the WBPolicy.

5.) Define Backup Target/Device
Define one or more backup targets. WBBackupTarget objects can be dedicated external disks, dedicated or shared internal disks, or network share.
You can define a Backup Target as an external disk by selecting it from the WBDisk objects on the system.

To back up to a network share, you need to first set the credential that will be used to connect to the share using Get-Credential.

6.) Define a backup schedule
Add backup schedule times to the backup. Define for the current day and the schedule will repeat daily. So, for twice a day, at 12:30 PM and 9PM

7.) Enable System State Backup

9.) Define the Volume Shadow Copy Options
Set Volume Shadow Copy to VssFullBackup when Windows Server Backup is the only application performing backups. Use
VssCopyBackup when additional backup applications are in use.

10.) Enable the Backup Policy
Finally, before the backup policy actually does anything, we need to set it in place. Use the ‑force parameter to avoid prompting.

Start a One-Time Backup

Using the current scheduled backup settings for items to be backed up, and backup target.

To perform a one-time backup using different settings, without modifying the existing backup settings, first create a new policy with

Then, build the one-time backup policy just as you would the standard policy, but without a schedule. Then when you’ve added what is backed up, and where it will be backed up to,  do not run Set-WBPolicy, but rather use:

See Also

• PowerShell Portal
• Wiki: Portal of TechNet Wiki Portals

В предыдущей части бэкапа в Windows Server 2008 R2 (Windows Server 2008 R2 и Windows Backup (часть 1)) мы рассмотрели основные моменты создания бэкапа средствами PowerShell. Сегодня мы рассмотрим вопросы самого процесса бэкапа и о его хранении.

Проверка успешности бэкапа

Когда процесс бэкапа закончится, можно посмотреть его статус:

[↑] [Administrator] Get-WBSummary


NextBackupTime                  : 0001.01.01. 0:00:00
NumberOfVersions                : 5
LastSuccessfulBackupTime        : 2009.10.07. 14:39:42
LastSuccessfulBackupTargetPath  : \?Volume{ca6dbf07-14ad-11de-937f-806e6f6e6963}
LastSuccessfulBackupTargetLabel : Camelot Share-1
LastBackupTime                  : 2009.10.07. 14:39:42
LastBackupTarget                : E:
DetailedMessage                 :
LastBackupResultHR              : 0
LastBackupResultDetailedHR      : 0
CurrentOperationStatus          : NoOperationInProgress

Здесь вы увидите основные сведения о результатах бэкапа. Свойство LastBackupResultHR содержит код возврата. Если это 0, то всё хорошо. Если это не 0, то бэкап не был выполнен удачно. А вот свойство NumberOfVersions показывает сколько уже копий бэкапа содержится в текущем архиве. Более подробно этот момент будет рассмотрен ниже.

Процесс создания и хранения бэкапа

При выполнении бэкапа происходит несколько вещей:

• В корне диска назначения бэкапа создаётся структура папок: <путь до диска или сетевой папки>WindowsImageBackup<имя компьютера>

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

• Обновляется каталог бэкапов.

Если это сетевая папка, то в пути \ServerBackupShareWindowsImageBackup создаст папку для каждого компьютера и в ней будет хранить бэкап соответствующего компьютера. При этом последующие операции бэкапа будут копировать архив в эту же папку.  Во времена ntbackup.exe мы могли выбирать метод выполнения бэкапа — с использованием VSS или без (это не относилось к SystemState бэкапам), а теперь этот вопрос решён однозначно — VSS используется всегда. Это обусловлено ещё тем, что Server Backup использует VSS для ведения истории бэкапов, что исключает путаницу в архивных копиях. Внимательные читатели могут заметить, что внутри папки бэкапа есть VHD файл (по одному VHD на каждый архивируемый том), который содержит актуальное состояние бэкапа. И тут появляется интересная вещь: каждый новый бэкап копируется в один VHD файл — а куда же деваются предыдущие копии? На самом деле все они хранятся в этом VHD файле, но скрыты за теневыми копиями, которые создаются при каждой операции бэкапа и закрепляются за архивом:

[↑] [Administrator] Get-WBBackupSet


VersionId        : 10/07/2009-10:49
BackupTime       : 2009.10.07. 13:49:41
BackupTarget     : E:
RecoverableItems : Volumes, Files
Volume           : {System (C:)}
Application      : {}
VssBackupOption  : VssCopyBackup
SnapshotId       : 8d6aa8ef-bb24-4ffc-93da-08831bc4ae88

VersionId        : 10/07/2009-11:15
BackupTime       : 2009.10.07. 14:15:36
BackupTarget     : E:
RecoverableItems : Volumes, Files
Volume           : {System (C:)}
Application      : {}
VssBackupOption  : VssCopyBackup
SnapshotId       : ab2c6d39-3447-4c9b-b072-f03d746045c4

<...>

Команда Get-WBBackupSet показывает историю бэкапов системы и ID номер теневой копии, которая содержит файлы архива на момет выполнения конкретного задания бэкапа. При восстановлении из бэкапа консоль MMC считывает эти копии и позволяет восстановить файлы на любой момент времени выполнения бэкапа. Чтобы дать более понятное представление об этом, покажу простой пример:

1. Выполняется первый бэкап №1.
2. В BackupTarget создаётся папка с архивом и в VHD файл записываются данные, которые мы архивируем;
3. В BackupTarget создаётся теневая копия, которая так же содержит эти файлы и закрепляется за этим бэкапом;
4. Время бэкапа и ID теневой копии записывается в каталог бэкапа;
5. Выполняется следующий бэкап этого же задания под № 2.
6. В BackupTarget уже ничего не создаётся, а новые данные добавляются в VHD файл, скрывая данные из бэкапа №1;
7. В BackupTarget создаётся теневая копия, которая так же содержит новые данные и закрепляется за этим бэкапом (№2);
8. Время бэкапа и ID теневой копии записывается в каталог бэкапа.
9. повторяются пункты 5-8.

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

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

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

Как долго хранятся бэкапы на архивном томе?

Хранятся они там сколь угодно долго, пока есть свободное место. Когда свободное место заканчивается, то Server Backup автоматически пытается отыскать себе место. Если у нас выполняются только полные бэкапы, то наиболее старые версии архивов просто удаляются. Если у нас комбинируются полные бэкапы с инкрементальными/дифференциальными, то берётся наиболее старый архив и в него вписываются инкрементальные/дифференциальные архивы, которые были выполнены в промежутках между полными бэкапами до тех пор, пока не освободится достаточно для нового бэкапа места. Таким образом обеспечивается сохранность наиболее новых архивов с удалением более старых. Такая схема автоматической ротации так же будет востребована в большинстве случаев. Для экономии места Server Backup для запланированного задания автоматически делает комбинирование полных и инкрементальных бэкапов. Каждые 2 недели выполняется полный бэкап и ежедневно в промежутках между полными будет выполняться только инкрементальное архивирование.

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

Совмещение нескольких заданий и индивидуальная ротация архивов

Разработчики Server Backup сделали всё, чтобы упростить процесс выполнения бэкапа в стандартных случаях SOHO/SMB. Но когда появляются особые условия, то тут начинаются свои сложности, хотя это всё относительно преодолимо. Например, вы создали несколько заданий бэкапов, которые отдельно что-то архивируют в одну и ту же точку. Но к каждому заданию предъявляются свои требования по сроку хранения бэкапа.

Пример: это файл-сервер и вы архивируете папку с документами пользователей ежедневно и следует хранить только 7 последние копии. Другое задание архивирует инсталляционные файлы вашей сети раз в неделю и требуется наличие только 4 последних копий. Так же все копии должны копироваться в сетевую папку или на съёмный диск на случай катастрофы и/или ада и Израиля. В такой ситуации мы потеряем возможность использования авторотации архивов и прочих плюшек. Давайте посмотрим, как будет выглядеть примерный скрипт:

Add-PSSnapin Windows.Serverbackup

$profiles = New-WBPolicy

$source = New-WBFileSpec -FileSpec "D:Users"
Add-WBFileSpec -Policy $profiles -FileSpec $source

$target = New-WBBackupTarget -VolumePath "E:"
Add-WBBackupTarget -Policy $profiles -Target $target

Start-WBBackup -Policy $profiles

if ((Get-WBSummary).LastBackupResultHR -eq 0) {
    
    $newname = "Profiles_$(Get-Date -f dd.MM.yyyy)"
    Ren E:WindowsImageBackup -NewName $newname
    
    copy e:$newname \serverbackupsprofiles
    
    dir \serverbackupsprofiles | ?{$_.lastwritetime -lt (Get-Date).AddDays(-7)} | del -Force
} else {
    
}

И уже этот файл отдельно зашедулить в Task Scheduler. В такой ситуации дополнительных шагов не требуется, т.к. пока живы теневые копии, вы можете восстанавливать файлы из них (наличие самого архива не требуется). А если теневых копий уже не осталось (например, том с архивами был отформатирован), то для восстановления данных просто копируете папку с архивом в корень любого тома с именем WindowsImageBackup и тогда этот архив будет определён системой как пригодный для восстановления. Так вы можете делать несколько раздельных заданий с индивидуальным расписанием бэкапа и ротацией.

Если ротация архивов в сетевой папке достаточно проста и укладывается в одну строчку, то с локальными архивами придётся подключать утилиты CMD, а именно — diskshadow.exe! Вам нужно внутри diskshadow выполнить Delete Shadows ID {GUID}, где GUID — ID теневой копии, которая закреплена за конкретным бэкапом и его можно получить из вывода Get-WBBackupSet (свойство SnapshotID)

[↑] [Administrator] diskshadow
Microsoft DiskShadow version 1.0
Copyright (C) 2007 Microsoft Corporation
On computer:  CAMELOT,  2009.10.13. 22:18:05


DISKSHADOW> delete shadows ID {8d6aa8ef-bb24-4ffc-93da-08831bc4ae88}
Deleting shadow copy {8d6aa8ef-bb24-4ffc-93da-08831bc4ae88}...

1 shadow copy deleted.

DISKSHADOW>

Вот таким образом можно удалять старые теневые копии архивов по одиночке. При удалении теневой копии при следующей операции бэкапа будет обновлён каталог бэкапов. Чтобы удалить все предыдущие архивы кроме текущего внутри diskshadow нужно выполнить:

Delete Shadows Oldest E:

где E: — путь к тому с архивами.

Сами данные из VHD файла будут удалены только при следующей операции бэкапа. Однако, это не относится к архивам, которые содержат SystemState. Для ротации архивов SystemState придётся воспользоваться уже другой утилитой — wbadmin.exe:

wbadmin delete systemstatebackup –version: datetime

где datetime — дата и время выполнения бэкапа. Эту дату можно получить так же из вывода командлета Get-WBBackupSet (свойство VersionID). Чтобы удалить все бэкапы SystemState, кроме текущего следует выполнить:

wbadmin delete systemstatebackup –backuptarget:E: –deleteoldest

и для удаления всех наиболее старых архивов SystemState с сохранением N копий выполнить:

wbadmin delete systemstatebackup –keepversions:N

где N — количество копий SystemState, которые должны быть сохранены.

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

Add-PSSnapin Windows.Serverbackup

$profiles = New-WBPolicy

$source = New-WBFileSpec -FileSpec "D:Users"
Add-WBFileSpec -Policy $profiles -FileSpec $source

$target = New-WBBackupTarget -VolumePath "E:"
Add-WBBackupTarget -Policy $profiles -Target $target

Start-WBBackup -Policy $profiles

if ((Get-WBSummary).LastBackupResultHR -eq 0) {
    
    $newname = "Profiles_$(Get-Date -f dd.MM.yyyy)"
    Ren E:WindowsImageBackup -NewName $newname
    
    copy e:$newname \serverbackupsprofiles
    
    dir \serverbackupsprofiles | ?{$_.lastwritetime -lt (Get-Date).AddDays(-7)} | del -Force
    
    $csv = Import-Csv E:ProfileBackup.csv
    
    $count = $csv.count
    
    
    if ($count -gt 7) {
        $old = $count - 7
        
        $file = [System.IO.Path]::GetRandomFileName()
        
        $csv | sort | select -First $old | %{
            
            "delete shadows ID {$($_.SnapshotID)}" > $Env:TEMP$file
            
            diskshadow -s $Env:TEMP$file
        }
        del $Env:TEMP$file
    }
    
    $current = Get-WBBackupSet | select -Last 1  | select VersionID, SnapshotId
    
    $csv += $current
    
    $csv | sort | select -Last 7 | Export-Csv E:ProfileBackup.csv -NoTypeInformation
} else {
    
}

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

Вот и всё, наверное, что я хотел рассказать про бэкап в Windows Server 2008 R2. В Windows 7 нет командлетов для бэкапа,  поэтому свои хотелки придётся реализовывать только средствами CMD (wbadmin, vssadmin, diskshadow). И это будет значительно сложнее, чем вариант с командлетами повершела.

Перейти к содержимому