Вітаю читачів нашого блогу! Почасти ми вже знайомі – мої англомовні пости з'являлися тут у перекладі моєї дорогої колеги . На цей раз я вирішив звернутися до російськомовної аудиторії безпосередньо.
Для свого дебюту мені хотілося знайти тему, цікаву максимально широкій аудиторії та яка вимагає детального розгляду. Даніель Дефо стверджував, що на будь-яку людину чекають смерть і податки. Зі свого боку можу сказати, що на будь-якого інженера підтримки чекають питання щодо політик зберігання точок відновлення (або якщо простіше – ретеншену). Як працює ретеншен, я почав пояснювати 4 роки тому, будучи молодшим інженером першого рівня, продовжую пояснювати і зараз, вже будучи тим лідером іспано- та італомовної команди. Впевнений, що мої колеги з другого та навіть третього рівня підтримки також регулярно відповідають на ті самі питання.
У цьому світлі мені захотілося написати остаточну, максимально докладну посаду, до якої російськомовні користувачі могли б повертатися знову і знову як до довідника. Момент підходящий – нещодавно випущена ювілейна десята версія додала нові можливості до базового функціоналу, який не змінювався роками. Мій пост орієнтований насамперед на цю версію — хоча більшість написаного вірна і для попередніх версій, дещо з описаного функціоналу ви там просто не знайдете. Нарешті, заглядаючи трохи в майбутнє, скажу, що в наступній версії очікуються деякі зміни, але про це ми розповімо коли настане час. Отже, почнемо.
Завдання резервного копіювання (Backup job)
Спочатку розберемо ту частину, яка зазнала змін у версії 10. Політика ретеншена визначається кількома параметрами. Відкриємо вікно створення нового завдання та перейдемо на вкладку Storage. Тут ми побачимо параметр, який визначає бажану кількість точок відновлення:
Однак це лише частина рівняння. Реальна кількість точок визначається також режимом бекапу, встановленим для завдання. Для вибору цього параметра потрібно натиснути на кнопку Advanced на тій же вкладці. Це відкриє нове вікно з безліччю опцій. Пронумеруємо їх та розглянемо по черзі:
Якщо включити лише опцію 1, то завдання працюватиме в «нескінченно інкрементальному» режимі (forever forward incremental). Тут ніяких складнощів не виникає – завдання зберігатиме встановлену кількість точок відновлення від повного бекапу (файл з розширенням VBK) до останнього інкременту (файл з розширенням VIB). Коли кількість точок перевищить встановлене значення, найстаріший інкремент буде поєднано з повним бекапом. Іншими словами, якщо завдання встановлено зберігати 3 точки, то відразу після чергової сесії на репозиторії буде 4 точки, після чого повний бекап буде об'єднаний із найстарішим інкрементом і загальна кількість точок повернеться до 3.
Також гранично простий ретеншень для «назад-інрементального» (reverse incremental) режиму (опція 2). Оскільки в цьому випадку найновіша точка буде повним бекапом, за яким тягнеться ланцюжок так званих роллбеків (файли з розширенням VRB), то для застосування ретеншена досить просто видалити найстаріший роллбек. Ситуація буде такою самою: відразу після сесії кількість точок перевищить встановлену на 1, після чого повернеться до потрібного значення.
Зверніть увагу, що з зворотно-інкрементальним режимом можна також включити періодичний повний бекап (опція 4), але суті це не змінить. Так, у ланцюжку з'являться повні точки відновлення, але ми все так само будемо просто видаляти найстаріші точки по одній.
Нарешті ми підходимо до цікавої частини. Якщо активувати інкрементальний бекап, але також увімкнути опції 3 або 4 (а можна і обидві одночасно), завдання почне створювати періодичні повні бекапи «активним» або синтетичним методом. Метод створення повного бекапу не важливий – він міститиме ті ж дані, а інкрементальний ланцюжок буде розділений на «підчіпки». Такий метод називається forward incremental і саме він викликає значну частину питань у наших клієнтів.
Ретеншен тут застосовується видаленням найстарішої частини ланцюжка (від повного бекапу до інкременту). При цьому ми не видалятимемо тільки порожнистий бекап або тільки частину інкрементів. Весь «підчіпок» видаляється повністю за раз. Змінюється і значення налаштування кількості точок - якщо в інших методах це максимально допустима кількість, після якої потрібно застосовувати ретеншен, то це налаштування визначає мінімальну кількість. Іншими словами, після видалення найстарішої «підчіпки», кількість точок в частині, що залишилася, не повинна впасти нижче цього мінімуму.
Намагатимуся зобразити цю концепцію графічно. Припустимо, ретеншень виставлений на 3 крапки, завдання працює щодня з повним бекапом у понеділок. Ретеншен у такому випадку буде застосований, коли загальна кількість точок досягне 10:
Чому аж 10, коли виставили 3? У понеділок було створено повний бекап. З вівторка по неділю завдання створювало інкременти. Нарешті, наступного понеділка знову створюється повний бекап і тільки коли будуть створені 2 інкременти нарешті вся стара частина ланцюжка може бути видалена, тому що кількість точок, що залишилася, не впаде нижче встановлених 3.
Якщо ідея зрозуміла, пропоную вам спробувати порахувати ретеншен самостійно. Візьмемо такі умови: завдання запускається вперше у четвер (звісно, буде зроблено повний бэкап). Завдання виставлено створювати повний бекап по середах та неділях та зберігати 8 точок відновлення. Коли ретеншень буде застосовано вперше?
Для відповіді на це запитання я рекомендую вам взяти аркуш паперу, розкреслити його по днях тижня та написати, яка точка створюється щодня. Відповідь стане очевидною
відповідь
Пояснення: для відповіді достатньо запитати себе, коли буде застосовано ретеншен? Відповідь – коли ми зможемо видалити 3 перші точки (VBK, VIB, VIB) і решта ланцюжка не впаде нижче за 8 точок. Стає ясно, що ми зможемо це зробити, коли ми матимемо 11 точок у сумі, тобто в неділю другого тижня.
Деякі читачі можуть заперечити: «навіщо це, якщо є ?». Без сумніву, це дуже корисний інструмент, і в деяких випадках я б застосовував саме його, але є й обмеження. Насамперед, він не дозволяє вказати початкові умови, а в багатьох випадках випадків питання звучить саме «у нас є такий ланцюжок, що буде, якщо змінити такі налаштування?». По-друге, інструменту все-таки дещо бракує наочності. Показуючи сторінку RPS клієнтам, я не знаходив розуміння, а ось розписав її як у прикладі (навіть використовуючи той же Paint), день за днем, все ставало ясно.
Нарешті ми не розглянули опцію “Transform previous backup chains into rollbacks” (позначено цифрою 5). Ця опція іноді бентежить клієнтів, які активують її "на автоматі", бажаючи включити просто синтетичний бекап. Тим часом, ця опція активує особливий режим бекапу. Не вдаючись у подробиці, одразу скажу, що на даному етапі розвитку продукту Transform previous backup chains into rollbacks – опція застаріла, і я не можу придумати жодного сценарію, коли б її слід було використовувати. Її цінність настільки сумнівна, що якийсь час сам Антон Гостев кинув клич через форум, просячи надіслати йому приклади її корисного використання (якщо у вас вони є, напишіть у коментарях, мені дуже цікаво). Якщо таких не знайдеться (я думаю, так і буде), то видалятимуть опцію в наступних версіях.
Завдання створюватиме інкременти (VIB) до дня, коли призначено синтетичний повний бекап. У цей день дійсно створюється VBK, але всі точки до цього VBK трансформуються в роллбеки (VRB). Після цього завдання продовжуватиме створювати інкременти до повного бекапу до наступного синтетичного бекапу. У результаті ланцюжку створюється гримуча суміш з VBK, VBR і VIB файлів. Ретеншен застосовується дуже просто - видаленням останнього VBR:
Проблеми
Крім власне розуміння, як це працює, більшість проблем, що виникають при використанні інкрементального режиму, зазвичай пов'язані з повним бекапом. Регулярний повний бекап необхідний цьому режиму, інакше репозиторій буде накопичувати крапки, доки не переповниться.
Наприклад, повний бекап може створюватися дуже рідко. Скажімо, завдання виставлено зберігати 10 пікселів, а повний бекап створюється раз на місяць. Зрозуміло, що фактична кількість точок тут буде значно більшою за виставлену. Або завдання взагалі виставлено працювати в нескінченно-інкрементальному режимі і зберігати 50 точок. Потім хтось випадково створив повний бекап. Все, відтепер завдання чекатиме, доки повна точка накопичить 49 інкрементів, після чого застосує ретеншен і повернеться в безкінечно-повний режим.
В інших випадках повний бекап виставлений створюватися регулярно, але з якоїсь причини цього не робить. Розпишу тут найпопулярнішу причину. Деякі клієнти вважають за краще використовувати опцію розкладу “run after” та налаштовувати завдання працювати у ланцюжку. Візьмемо такий приклад: є 3 завдання, які працюють щодня та створюють повний бекап у неділю. Перше завдання запускається о 22.30, решта запускається по ланцюжку. Інкрементальний бекап займає 10 хвилин, і тому до 23.00 усі завдання закінчують роботу. А ось повний бекап займає годину, тож у неділю відбувається таке: перше завдання працює з 22.30 до 23.30. Наступне з 23.30:00.30 до XNUMX:XNUMX. А ось третє завдання запускається вже у понеділок. Повний бекап налаштований на неділю, тож у такому разі його просто не буде. Завдання ж чекатиме повний бекап, щоб застосувати ретеншен. Тому будьте уважні при використанні опції "run after" або не використовуйте її взагалі - просто виставте завдання стартувати одночасно і дозвольте планувальнику ресурсів зробити свою роботу.
Непроста опція "Remove deleted items"
Пройшовши за налаштуваннями завдання Storage - Advanced - Maintenance, можна натрапити на опцію "remove deleted items data after", що обчислюється днями.
Деякі клієнти очікують, що це є ретеншен. Насправді це абсолютно окрема опція, нерозуміння якої може призвести до несподіваних наслідків. Однак, перш за все потрібно пояснити, як B&R реагує на ситуації, коли за час сесії успішно бекапиться лише кілька машин.
Уявімо такий сценарій: нескінченно-інкрементальне завдання, налаштоване зберігати 6 точок. У завданні 2 машини одна завжди бекапілася успішно, інша іноді давала помилки. У підсумку до сьомої точки склалася така ситуація:
Час застосовувати ретеншен, але в однієї машини 7 крапок, а в іншої тільки 4. Чи буде тут застосовано ретеншен? Відповідь – так, буде. Якщо хоч один об'єкт був забекаплений, B&R вважає, що точку створено.
Аналогічна ситуація може скластися, якщо якусь машину просто не було включено до завдання під час певної сесії. Таке буває, наприклад, коли машини додані в завдання не індивідуально, а у складі контейнерів (папки, сховища) та якась машина тимчасово мігрує до іншого контейнера. Завдання в такому випадку вважатиметься успішним, але в статистиці ви знайдете повідомлення, що закликає звернути увагу, що така машина більше не обробляється завданням.
Що ж буде, якщо не зважати на це? У випадку з нескінченно-інкрементальним або зворотно-інкрементальним режимами кількість точок відновлення «проблемної» машини буде зменшуватися з кожною сесією, доки не досягне 1, збереженої в VBK. Іншими словами, навіть якщо машина не буде бекапатися довгий час, одна точка відновлення таки залишиться. Справа йде іншим чином, якщо включені періодичні повні бекапи. Якщо ігнорувати сигнали від B&R, то остання точка може бути видалена разом зі старою частиною ланцюжка.
Усвідомивши ці деталі, нарешті можна розглянути опцію "Remove deleted items data after". Вона видаляє всі крапки для певної машини, якщо ця машина не бекпит протягом X днів. Зверніть увагу, що на помилки (спробували – не вийшло) це налаштування не реагує. Не повинно бути навіть спроби бекапу машини. Здавалося б, опція корисна і її слід тримати включеної. Якщо адміністратор видалив машину із завдання, то логічно через деякий час очистити від непотрібних даних та ланцюжок. Однак, налаштування потребує дисципліни та уважності.
Наведу приклад із практики: у завдання було додано кілька контейнерів, склад яких був досить динамічним. Через відсутність ОЗУ B&R сервер мав проблеми, які залишалися непоміченими. Завдання запустилося і спробувало зробити бекап машин, крім однієї, яка на той момент не була присутня в контейнері. Оскільки багато машин видали помилки, за замовчуванням B&R має виконати 3 додаткові спроби зробити бекап «проблемних» машин. Через постійні проблеми з ОЗУ ці спроби розтяглися на кілька днів. Повторної спроби зробити бекап відсутньою ВМ не було (відсутність ВМ – це не помилка). У результаті під час однієї з повторних спроб була виконана умова "Remove deleted items" і всі точки машини були вилучені.
З цього приводу можу сказати наступне: якщо у вас налаштовані оповіщення про результати завдань, а ще краще – використовується інтеграція з Veeam ONE, то, швидше за все, такого з вами не відбудеться. Якщо ж ви заглядаєте на B&R сервер щотижня, перевірити, що все працює, то від опцій, які потенційно можуть призвести до видалення бекапів, краще відмовитися.
Що додалося у v.10
Те, про що ми говорили раніше, існувало в B&R протягом багатьох версій. Усвідомивши ці принципи роботи, давайте тепер подивимося, що додалося в ювілейній «десяточці».
Daily retention
Вище ми розглядали «класичну» політику зберігання, що ґрунтується на кількості точок. Альтернативний підхід - виставити в тому ж меню "days" замість "restore points".
Ідея зрозуміла з назви – ретеншен буде зберігати встановлену кількість днів, кількість точок у кожному дні не має значення. При цьому слід пам'ятати таке:
- Поточний день не враховується під час розрахунку ретеншена
- Дні, коли завдання не працювало зовсім, також вважаються. Це слід мати на увазі, щоб випадково не втратити точки завдань, які працюють нерегулярно.
- Точка відновлення вважається з того дня, коли почалося її створення (тобто якщо завдання почало працювати у понеділок, а закінчило у вівторок, то це точка від понеділка)
В іншому принципи застосування ретеншена завданнями все також визначаються вибраним методом бекапу. Давайте спробуємо ще одне завдання на розрахунок, використовуючи той самий інкрементальний метод. Скажімо, ретеншень виставлений на 8 днів, завдання працює кожні 6 годин з повним бекапом у середу. При цьому завдання не працює у неділю. Завдання запускається у понеділок уперше. Коли буде застосовано ретеншен?
відповідь
Як завжди, найкраще намалювати табличку. Я дозволю собі спростити завдання і не малюватиму всі точки, створені за кожен день, адже кількість точок на день тут не відіграє значення. Нам важливо тільки, що в перший понеділок і по середах перша точка буде повним бекапом, в інші дні завдання просто буде створювати 4 інкрементальні точки.
Усвідомлюємо собі що ретеншен буде використаний видаленням понеділкового повного бекапу та його інкременту. Коли це відбудеться? Коли частина ланцюжка, що залишилася, міститиме 8 днів. При цьому ми не рахуємо поточний день, а ось неділю, навпаки, рахуємо. Тому відповідь – у четвер другого тижня.
Архівування методом GFS для звичайних завдань
До v.10 метод зберігання Grandfather-Father-Son (GFS) був доступний лише для завдань створення архівних копій (Backup copy) та завдань копіювання на магнітну стрічку. Тепер він доступний і для звичайного бекапу.
Хоча це не стосується поточної теми, не можу не сказати, що новий функціонал не означає відходу від стратегії 3-2-1. Присутність архівних точок переважно репозиторії ніяк не впливає на його надійність. Мається на увазі, що GFS буде використаний разом з репозиторієм, що розширюється (Scale-out), для відвантаження цих точок в S3 і їм подібні сховища. Якщо ви ним не користуєтеся, то краще зберігати первинні та архівні точки на різних репозиторіях.
Тепер розглянемо принципи створення GFS-точок. У налаштуваннях завдання, на кроці Storage, з'явилася спеціальна кнопка, яка викликає наступне меню:
Суть GFS можна звести до кількох пунктів (зверніть увагу, GFS в інших видах завдань працює інакше, але про це трохи пізніше):
- Завдання не створює окремий повний бекап під GFS точку. Натомість буде використано найбільш відповідний повний бекап з наявних. Тому завдання має працювати в інкрементальному режимі з періодичним повним бекапом, або повний бекап повинен створюватися користувачем вручну.
- Якщо увімкнено лише один період (наприклад, тижневий), то на початку GFS періоду завдання просто почне чекати повного бекапу і відзначить перший відповідний як GFS.
Приклад: завдання настроєно зберігати тижневий GFS, використовуючи бекап у середу. Завдання працює щодня, але повний бекап призначено на п'ятницю. У цьому випадку в середу почнеться GFS період і завдання почне чекати відповідної точки. Вона з'явиться у п'ятницю і буде відзначена прапором GFS.
- Якщо увімкнуто відразу кілька періодів (наприклад, тижневий та місячний), то B&R буде застосовувати метод, що дозволяє використовувати ту саму точку як GFS декількох інтервалів (для економії місця). Прапори будуть призначені по черзі, починаючи з молодшого.
Приклад: тижневий GFS виставлений на середу, а місячний – останній тиждень місяця. Завдання працює щодня і створює повні бекапи по понеділках та п'ятницях.
Для простоти почнемо відлік із передостаннього тижня місяця. Цього тижня буде створено повний бекап у понеділок, але він буде проігнорований, тому що тижневий GFS інтервал починається в середу. Натомість повний п'ятничний бекап повністю підходить для GFS точки. Ця система нам уже знайома.
Тепер розглянемо, що станеться в останній тиждень місяця. Місячний GFS інтервал розпочнеться у понеділок, але понеділковий VBK не буде позначений як GFS, тому що завдання прагне позначити один VBK і як місячну, і як тижневу точку GFS. При цьому починається пошук саме з тижневої, тому вона за визначенням зможе стати і місячною.
При цьому якщо включити лише тижневий та річний інтервали, то вони будуть діяти незалежно один від одного і можуть відзначити 2 окремі VBK як відповідні GFS інтервали.
Завдання створення архівної копії (Backup copy)
Ще один тип завдань, який часто вимагає роз'яснень по роботі. Для початку розберемо "класичний" метод роботи, без нововведень v.10
Простий метод ретеншену
За замовчуванням такі завдання працюють у нескінченно-інкрементальному режимі. Створення точок визначається двома параметрами – інтервалом копіювання та бажаною кількістю точок відновлення (ретеншена днями тут немає). Інтервал копіювання виставляється на першій вкладці Job при створенні завдання:
Кількість точок визначається трохи далі на вкладці Target
Завдання створює одну нову точку за кожен інтервал (скільки точок було створено для ВМ вихідними завданнями, значення не має). Під кінець інтервалу нова точка фіналізується і, якщо це необхідно, застосовується ретеншен шляхом об'єднання VBK та найстарішого інкременту. Цей механізм нам уже знайомий.
Метод ретеншену з використанням GFS
BCJ теж вміє зберігати архівні точки. Налаштовується це на тій же вкладці Target, трохи нижче за налаштування кількості точок відновлення:
GFS точки можуть створюватися двома способами – синтетично, використовуючи дані на вторинному репозиторії, або ж імітуючи повний бекап та зчитуючи всі дані з первинного репозиторію (активується опцією, зазначеною цифрою 3). Ретеншен в обох випадках сильно відрізнятиметься, тому розглянемо їх окремо.
Синтетичний GFS
У цьому випадку GFS точка не створюється точно у призначений день. Натомість, GFS точка буде створена, коли VIB того дня, на який було призначено створення GFS точки, буде об'єднаний з повним бекапом. Це іноді викликає непорозуміння, адже час іде, а GFS точки все немає. І лише могутній шаман з техпідтримки може передбачити, в який день крапка таки з'явиться. Насправді магія не потрібна – достатньо подивитися на виставлену кількість точок та інтервал синхронізації (скільки точок створюється щодня). Спробуйте підрахувати самі на такому прикладі: завдання виставлено зберігати 7 пікселів, інтервал синхронізації – 12 годин (тобто 2 крапки на день). На даний момент у ланцюжку вже 7 точок, сьогодні понеділок, і на цей день призначено створення GFS-точки. Якого дня її буде створено?
відповідь
Тут краще розписати, як ланцюжок буде змінюватися в динаміці, щодня:
Отже, в понеділок останній інкремент у ланцюжку позначається як GFS, але жодних інших видимих змін не відбувається. Щодня завдання створює дві нові точки, і ретеншен невблаганно рухає ланцюжок вперед. Нарешті, у четвер настає час застосовувати ретеншен до того самого інкременту. Ця сесія займе більше часу, ніж зазвичай - тому що завдання "витягне" потрібні блоки з ланцюжка і створить нову повну точку. З цього моменту в ланцюжку буде вже 2 точок – 8 в основному ланцюжку + GFS.
Створення GFS точок із опцією “Read entire point”
Вище я сказав, що BCJ працює у нескінченно-інкрементальному режимі. Зараз ми розберемо єдиний виняток із цього правила. При включенні опції “Read entire point” GFS точка буде створена у запланований день. Саме завдання буде працювати в інкрементальному режимі з періодичними повними бекапами, який ми розбирали вище. Ретеншен також застосовуватиметься видаленням найстарішої частини ланцюжка. Однак у цьому випадку будуть видалені лише інкременти, а повний бекап буде залишений як GFS точка. Відповідно, при розрахунку ретеншена не враховуються точки, відзначені прапорами GFS.
Допустимо, завдання виставлено зберігати 7 точок і створювати тижневу GFS точку у понеділок. У цьому випадку кожен понеділок завдання дійсно буде створювати повний бекап і позначати його як GFS. Ретеншен буде застосований, коли після видалення інкрементів з найстарішої частини, кількість інкрементів, що залишилися, не впаде нижче 7. Ось як це виглядає на схемі:
Отже, до кінця другого тижня в ланцюжку в сумі 14 пікселів. Протягом другого тижня завдання створило 7 точок. Якби це просте завдання, ретеншень був би вже застосований. Але це BCJ з GFS ретеншеном, тому GFS точки ми не рахуємо, а отже, їх лише 6. Тобто ретеншен ми ще застосувати не можемо. На третьому тижні ми створюємо ще один повний бекап з прапором GFS. 15 точок, але цю ми знову не рахуємо. І, нарешті, у вівторок третього тижня ми створюємо інкремент. Тепер, якщо ми видалимо інкременти ланцюжка першого тижня, загальна кількість інкрементів задовольнить встановленому ретеншену.
Як уже говорилося вище, у цьому методі дуже важливо, щоб повні бекапи створювалися регулярно. Скажімо, якщо виставити основний ретеншен на 7 днів, але тільки 1 річну точку, неважко уявити, що інкрементів накопичиться сильно, сильно більше, ніж 7. У таких випадках краще використовувати синтетичний метод створення GFS.
І знову “Remove deleted items”
Ця опція також є і для BCJ:
Логіка цієї опції тут така ж, як і у звичайних завданнях бекапу – якщо машина не обробляється вказану кількість днів, то її дані видаляються з ланцюжка. Однак, для BCJ корисність цієї опції об'єктивно вища, і ось чому.
У звичайному режимі BCJ працює в нескінченно-інкрементальному режимі, тому якщо в якийсь момент машина видаляється із завдання, то ретеншень поступово видаляє всі точки відновлення, доки не залишиться одна-єдина - в VBK. Тепер уявімо, що завдання налаштовано створювати синтетичні GFS точки. Коли настане час, завдання має створити GFS для всіх машин у ланцюжку. Якщо якась машина зовсім не має нових точок – ну що ж, доведеться використовувати ту, що є. І так щоразу. У результаті може скластися така ситуація:
Зверніть увагу на розділ Files: у нас є основний VBK і 2 тижневі GFS точки. А тепер на секцію Restore points – за фактом у цих файлах лежить той самий образ машини. Звичайно, ніякого сенсу в таких GFS точках немає, вони тільки займають місце.
Така ситуація можлива лише за умови використання синтетичного GFS. Щоб цього не допустити, використовуйте опцію “Remove deleted items”. Тільки не забудьте виставити її на адекватну кількість днів. Техпідтримка бачила випадки, коли опцію виставляли на менше днів, ніж інтервал синхронізації - BCJ починала шаленіти і видаляти точки, не встигнувши їх створити.
Врахуйте також, що ця опція не торкається вже створених GFS точок. Якщо ви хочете почистити архіви, зробити це потрібно вручну - клікнувши правою кнопкою по машині і вибравши "Delete from disk" (у вікні не забудьте виставити галочку "Remove GFS full backup"):
Нововведення v.10 – негайна копія (immediate copy)
Розібравшись із «класичним» функціоналом, перейдемо до нового. Нововведення одне, але дуже важливе. Це новий режим роботи.
Тут немає такого поняття, як «інтервал синхронізації», завдання постійно стежитиме, чи не з'явилися нові точки, і копіювати їх усіх, скільки б їх не було. Але при цьому завдання залишається інкрементальним, тобто навіть якщо основне завдання створює VBK або VRB ці точки будуть скопійовані як VIB. В іншому режимі немає жодних сюрпризів – як стандартний, так і GFS ретеншен працюють за правилами, описаними вище (щоправда, тут доступний лише синтетичний GFS).
Крутуються диски. Особливості репозиторіїв із ротацією дисків (rotated drives)
Постійна загроза вірусів-шифрувальників зробила де-факто стандартом безпеки наявність копії даних на носії, куди вірус дістатися не може. Один із варіантів – це використання репозиторіїв з ротацією дисків, коли диски використовуються по черзі: у той час як один диск підключений та доступний для запису, інші зберігаються у безпечному місці.
Щоб навчити B&R працювати з такими репозиторіями, необхідно в налаштуваннях репозиторію на кроці Repository, клинути по кнопці Advanced і вибрати відповідну опцію:
Після цього VBR буде очікувати, що періодично існуючий ланцюжок буде зникати з репозиторію, що означає ротацію диска. Залежно від типу репозиторію та виду завдання, B&R поводитиметься по-різному. Уявити це можна такою таблицею:
Розглянемо кожний варіант.
Звичайне завдання та Windows репозиторій
Отже, ми маємо завдання, яке зберігає ланцюжки на перший диск. При ротації створений ланцюжок практично зникає, і завдання потрібно якось пережити цю втрату. Втіху воно знаходить у створенні повного бекапа. Таким чином, кожна ротація означає повний бекап. Але що відбувається з точками на вимкненому диску? Вони запам'ятовуються та враховуються при прорахунку ретеншену. Таким чином, виставлена кількість точок у завданні – це те, скільки точок необхідно тримати на всіх дисках. Наведемо приклад:
Завдання працює в нескінченно-інкрементальному режимі та настроєно зберігати 3 точки відновлення. Але у нас є ще другий диск, і ми раз на тиждень проводимо ротацію (дисків може бути і більше, це не змінює суті).
У перший тиждень завдання створюватиме точки на першому диску та об'єднуватиме зайві. Таким чином, загальна кількість точок дорівнюватиме трьом:
Потім ми підключаємо другий диск. Під час запуску B&R помітить, що диск змінився. Ланцюжок на першому диску зникне з інтерфейсу, але інформація про нього залишиться в базі. Тепер завдання триматиме 3 крапки на другому диску. Загальна ситуація буде така:
Нарешті ми знову підключаємо перший диск. Перед створенням нової точки завдання перевірить, що там із ретеншеном. А ретеншен, нагадую, виставлений зберігати 3 крапки. Тим часом у нас є 3 крапки на диску 2 (але він вимкнений і зберігається в надійному місці, куди B&R дістатися не може) і 3 крапки на диску 1 (а ось цей підключений). Отже, можна сміливо видалити 3 крапки з диска 1, оскільки вони перевищують ретеншен. Після чого завдання знову створює повний бекап, і наш ланцюжок починає виглядати так:
Якщо ретеншен налаштований зберігати дні замість кількості точок, логіка не змінюється. Крім того, GFS ретеншен не підтримується при використанні репозиторіїв з ротацією дисків.
Звичайне завдання та Linux репозиторій мережеве сховище
Такий варіант також можливий, але загалом менш рекомендований через накладені обмеження. На ротацію диска та зникнення ланцюжка завдання буде реагувати так само – створенням повного бекапу. Обмеження ж пов'язані з обрізаним механізмом ретеншена.
Тут при ротації весь ланцюжок на відключеному диску легко видаляється з бази даних B&R. Зверніть увагу – з бази даних самі файли при цьому залишаються на диску. Їх можна імпортувати та використовувати для відновлення, але неважко здогадатися, що рано чи пізно такі забуті ланцюжки заповнять весь репозиторій.
Рішення – додати DWORD ForceDeleteBackupFiles як це вказано на цій сторінці: . Після цього завдання просто видаляє весь вміст папки завдання або папки репозиторію (залежно від значення) при кожній ротації.
Однак це не елегантний ретеншень, а саме чищення всього вмісту. На жаль, техпідтримці траплялися випадки, коли як репозиторій був вказаний просто кореневий каталог диска, де крім бекапів лежали й інші дані. Все це було знищено під час ротації.
Крім того, при включенні ForceDeleteBackupFiles працює для всіх типів репозиторіїв, тобто навіть репозиторії на Windows перестануть застосовувати ретеншен і почнуть видаляти вміст. Іншими словами, локальний диск на Windows – найкращий вибір для такої системи зберігання бекапів.
Backup copy та Windows репозиторій
З BCJ все стає ще цікавіше. Мало того, що тут є повноцінний ретеншн, але тут не потрібно робити повний бекап при кожній зміні диска! Працює це так:
Спочатку B&R починає створювати крапки на першому диску. Скажімо, ми виставили ретеншен на 3 крапки. Завдання працюватиме в нескінченно-інкрементальному режимі та об'єднуватиме все зайве (нагадаю, GFS ретеншен у цьому випадку не підтримується).
Потім ми підключаємо другий диск. Оскільки на ньому ще немає ланцюжка, то ми створюємо повний бекап, після чого у нас з'являється другий ланцюжок із трьох крапок:
Нарешті, настав час знову підключити перший диск. І ось тут починається магія, оскільки завдання не створить повний бекап, а натомість просто продовжить інкрементальний ланцюжок:
Після цього фактично на кожному диску існуватиме свій незалежний ланцюжок. Тому ретеншен тут означає кількість точок усім дисках, а кількість точок кожному диску окремо.
Backup copy та Linux репозиторій мережеве сховище
І знову, вся елегантність зникає, якщо репозиторій не так на локальному диску Windows. Цей сценарій працює аналогічно розглянутому вище із простим завданням. При кожній ротації BCJ створюватиме повний бекап, а існуючі точки будуть забуті. Щоб не залишитись без вільного місця, потрібно використовувати DWORD ForceDeleteBackupFiles.
Висновок
Отже, внаслідок такого довгого тексту ми розглянули два типи завдання. Звичайно, завдань набагато більше, але розглянути їх не вийде у форматі однієї статті. Якщо після прочитання у вас залишилися якісь питання, то пишіть їх у коментарі, я радий відповісти особисто.
Джерело: habr.com