Windows Server 2008 R2 та Windows Backup (частина 2) - PKI Extensions

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

Тут ви побачите основні відомості про результати бекапу. ВластивістьLastBackupResultHR містить код повернення. Якщо це 0, то все гаразд. Якщо це не 0, то бекап не був виконаний вдало. А ось властивістьNumberOfVersions показує скільки копій бекапу міститься в поточному архіві. Докладніше цей момент буде розглянуто нижче.

Процес створення та зберігання бекапу

При виконанні бекапу відбувається кілька речей:

Якщо це мережна папка, то в дорозі \\Server\BackupShare\WindowsImageBackup створить папку для кожного комп'ютера і в ній зберігатиме бекап відповідного комп'ютера. При цьому наступні операції бекапу копіюватимуть архів у цю папку. За часів ntbackup.exe ми могли вибирати метод виконання бекапу — з використанням VSS або без (це не стосувалося SystemState бекапів), а тепер це питання вирішене однозначно — VSS використовується завжди. Це зумовлено тим, що Server Backup використовує VSS для ведення історії бекапів, що виключає плутанину в архівних копіях. Уважні читачі можуть помітити, що всередині папки бекапу є VHD файл (по одному VHD на кожен том, що архівується), який містить актуальний стан бекапу. І тут з'являється цікава річ: кожен новий бекап копіюється в один VHD файл — а куди подіться попередні копії? Насправді всі вони зберігаються в цьому VHD файлі, але приховані за тіньовими копіями, які створюються за кожної операції бекапу і закріплюються за архівом:

Команда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.

  • більше немає купи файлів архівів, які потрібно самому збирати в якесь сховище та якось ідентифікувати;
  • для відновлення файлів та томів не обов'язково наявність самого бекапу. Адже тіньова копія, що закріплюється за цим бекапом, теж може використовуватися для відновлення.

У більшості випадків це рішення буде достатнім для будь-яких операцій відновлення. Єдиним критичним місцем тут буде наявність цих тіньових копій. Це може спричинити труднощі лише при пошкодженні тіньових копій на архівному томі. Але зазвичай це вже означатиме втрату всіх бекапів. Такі справи.

Як довго зберігаються бекапи на архівному томі?

Зберігаються вони там як завгодно довго, поки є вільне місце. Коли вільне місце закінчується, то Server Backup автоматично намагається знайти собі місце. Якщо у нас виконуютьсятільки повні бекапи, то найстаріші версії архівів просто видаляються. Якщо у нас комбінуються повні бекапи з інкрементальними/диференціальними, то береться найстаріший архів і в нього вписуються інкрементальні/диференціальні архіви, які були виконані в проміжках між повними бекапами доти, доки не звільниться достатньо нового бекапу місця. Таким чином забезпечується збереження нових архівів з видаленням старіших. Така схема автоматичної ротації також буде затребувана в більшості випадків. Для економії місця Server Backup для запланованого завдання автоматично робить комбінування повних та інкрементальних бекапів. Кожні 2 тижні виконується повний бекап і щодня у проміжках між повними виконуватиметься лише інкрементальне архівування.

Поєднання кількох завдань та індивідуальна ротація архівів

Розробники Server Backup зробили все, щоб спростити процес виконання бекапу у стандартних випадках SOHO/SMB. Але коли з'являються особливі умови, то тут починаються свої складнощі, хоча це відносно переборне. Наприклад, ви створили кілька завдань бекапів, які окремо щось архівують в одну й ту саму точку. Але до кожного завдання пред'являються свої вимоги щодо терміну зберігання бекапу.

І вже цей файл окремо зашедулити вTask Scheduler. У разі додаткових кроків непотрібен, т.к. доки живі тіньові копії, можна відновлювати файли з них (наявність самого архіву не требуется). А якщо тіньових копій вже не залишилося (наприклад, том з архівами було відформатовано), то для відновлення даних просто копіюєте папку з архівом у корінь будь-якого тома з ім'ямWindowsImageBackup і тоді цей архів буде визначений системою як придатний длявідновлення. Так ви можете робити кілька роздільних завдань з індивідуальним розкладом бекапу та ротацією.

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

Ось таким чином можна видаляти старі тіньові копії архівів поодинці. При видаленні тіньової копії при наступній операції бекапу буде оновлено каталог бекапів. Щоб видалити всі попередні архіви крім поточного всередині 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 файл для каталогізації тіньових копій. Ось як це приблизно виглядає:

У принципі, це лише один варіант реалізації подібного завдання і не обвішено жодними перевірками. Однак, враховуючи те, що цей код публікується на правахТЗ (ТЗ — Таємне Знання), тому може використовуватися як шаблон алгоритму такої кастомної ротації. Цей скрипт лише демонструє логіку, якою ви можете скористатися та підпиляти під свої умови самостійно.

Ось і все, мабуть, що я хотів розповісти про бекап у Windows Server 2008 R2. У Windows 7 немає командлетів для бекапу, тому свої хотілки доведеться реалізовувати лише засобами CMD (wbadmin,vssadmin,diskshadow ). І це буде значно складніше, ніж варіант із командлетами повершила.

Вітаю! Чи можливо вибрати провайдера VSS перед бекапом. На сервері w2k8 R2 встановлено Aronis True Image Agent. Під час бекапу за допомогою wbadmin у журналі подій з'являється така помилка 22 та 12292 Помилка служби тіньового копіювання томів: не зареєстрований критичний компонент, необхідний для служби тіньового копіювання томів. Це може бути наслідком помилки під час інсталяції Windows або під час встановлення постачальника тіньового копіювання. Помилка повернута функцією CoCreateInstance для класу з CLSID та ім'ям HWPRV: [0x80004002, Інтерфейс не підтримується]. Операція: Створення екземпляра постачальника обладнання Отримання інтерфейсу з можливістю виклику для цього постачальника Перелік інтерфейсів усіх постачальників, які підтримують цей контекст Отримання властивостей тіньової копії Контекст: Код постачальника: Кодпостачальника: Код класу: Контекст моментального знімка: 25 Контекст моментального знімка: 25 Контекст виконання: Coordinator Помилка тіньового копіювання тома: Помилка під час створення класу постачальника тіньового копіювання COM з CLSID [0x80004002, Інтерфейс не підтримується]. Операція: Створення екземпляра постачальника обладнання Отримання інтерфейсу з можливістю виклику для цього постачальника Перелік інтерфейсів усіх постачальників, які підтримують цей контекст Отримання властивостей тіньової копії Контекст: Код постачальника: Код постачальника: Код класу: Контекст моментального знімку: 25 Контекст моментального знімку: 25 Coordinator Ось цей Код постачальника: належить Acronis При цьому бекап проходить нормально.

Наскільки я знаю, ні, не можна використовувати сторонні провайдери VSS. Принаймні немає інтерфейсу, щоб це можна було зробити.

Ось така помилка вивалюється: Cannot add Windows PowerShell snap-in Windows.Serverbackup because it is already added. Verify name of snap-in and try again. At:line:2 char:12 + Add-PSSnapin

ну це означає, що оснастка вже додана заздалегідь. Не бачу у цьому криміналу.

А друга помилка? Scheduler::GetRegisteredTaskInfo failed до error: Object не підключений до сервера, (0x800401fd). . At :line:4 char:24 + $profiles = New-WBPolicy

про цю помилку нічого сказати не можу.

З подібними питаннями краще звертатися до технічної підтримки Акронісу, тим більше, я з їхніми продуктами не працюю.