Capacity Tier (або як ми називаємо його у себе всередині віма - каптир) з'явився ще за часів Veeam Backup and Replication 9.5 Update 4 під ім'ям Archive Tier. Закладена в нього ідея - це дати можливість переміщати бекапи, які випали з так званого operational restore window на об'єктні сховища. Це допомагало розчищати дисковий простір тим користувачам, які мали його мало. А називалася ця опція Move Mode.

Для виконання цієї нехитрої (як здається) дії достатньо було дотриматися двох умов: всі точки з бекапа, що переміщується, повинні бути за межами вищезгаданого operational restore window, яке задається в явному вигляді в UI. І друге: ланцюжок має бути в так званому «запечатаному вигляді» (sealed backup chain або Inactive Backup Chain). Тобто з часом у цьому ланцюжку не відбувається змін.

Але в VBR v10 концепція доповнилася новими функціями - з'явився Copy Mode, Sealed Mode і штука зі складною назвою Immutability.

Ось про ці цікаві речі ми сьогодні і поговоримо. Спочатку про те, як це працювало в VBR9.5u4, а потім про зміни у десятій версії.

І нехай пробачать мені поборники чистої мови, але надто багато термінів неможливо перекласти.
Тож тут буде темрява англіцизмів.
І багато гіфок.
І картинок.

• Без жодних жалю. Автор статті.

Як було

Ну що ж, починаємо з аналізу operational restore window і sealed backup (або як вони називаються в документації Inactive Backup Chain). Без їхнього розуміння подальше пояснити не вийде.

Як ми бачимо на картинці, у нас є якийсь бекапний ланцюжок з блоками даних, який розташований на Performance tier SOBR репозиторію, до якого підключено Capacity Tier. Наше вікно операційного бекапа дорівнює трьом дням.

Відповідно, створений у понеділок .vbk запечатує попередній ланцюжок, вікно якого встановлено на три дні. І, значить, спокійно можна починати відвозити в капасити тир все, що старше за ці три дні.

Але що саме малося на увазі під sealed ланцюжком та що могло вирушати у капасити тир у update 4?

Для Forward Incremental ознакою запечатування ланцюжка є створення нового фула бекапа. І не важливо, як цей фульник виходить: вважаються і synthetic full, і active full бекапи.

У випадку Reverse це всі файли, які не потрапляють до операційного вікна.

У випадку Forward increment з роллбеками це все роллбеки та .vbk, якщо на перфоманс екстенті є ще один .vbk

Тепер розглянемо варіант роботи з Backup Copy ланцюжками. Тут відвозилося тільки ретеншн, що потрапляє під GFS. Тому що все, що зберігається в свіжих backup copy ланцюжках, може бути тим чи іншим способом змінено.

Тепер заглянемо під капот. Там відбувається процес, званий дегідрацією - залишення пустушок бекапних файлів на екстенті та перетягування блоків із цих файлів на капасити тир. Для оптимізації цього процесу використовують так званий індекс дегідрації, який дозволяє не копіювати блоки, які вже були скопійовані в капасити тир.

Розглянемо, як це виглядає на прикладі: припустимо, що у нас є .vbk, що вийшов з операційного вікна і належить запечатаному ланцюжку. Отже, ми маємо повне право перенести його до капасити тиру. У момент переїзду створюється файл метаданих у капасити тире і блоки файлу, що переноситься. У файлі метаданих лише на рівні посилань описується, із яких блоків складається наш файл. У випадку на картинці наш перший файл складається з блоків a, b, c і метаданих розміщені посилання на ці блоки. Коли у нас з'являється другий .vbk файл, готовий до переїзду і що складається з блоків a, b і d, ми, аналізуючи індекс дегідрації, розуміємо, що переносити треба лише блок d. А його файл метаданих міститиме посилання на два попередні блоки і один новий.

Відповідно, процес зворотного заповнення цих пустушок даними називається регідрацією. Тут використовується вже свій індекс регідрації, що спирається на найстаріший файл .vbk на локальному перфоманс екстенті. Тобто якщо користувач хоче повернути файл з капасити тиру, ми спочатку створюємо індекс блоків найстарішого повного бекапа і переносимо з капасити тиру тільки блоки, що відсутні. У випадку, представленому на картинці, щоб регідрувати FullBackup1.vbk згідно з індексом регідрації, нам не вистачає тільки блоку С, який ми і забираємо з капасити тиру. Якщо капасити тиру виступає хмарний обжект сторадж, це дозволяє економити колосальні гроші.

Тут може здатися, що ця технологія ідентична використовуваної WAN Accelerators, але це тільки здається. В акселераторах дедуплікація глобальна, тут же використовується локальна у межах кожного файлу за певним офсетом. Це відбувається через різницю вирішуваних завдань: тут нам треба копіювати великі файли фулл бекапів, і за нашими дослідженнями, навіть якщо між ними проходить великий період часу, такий алгоритм дедуплікації дає кращий результат.

Але більше індексів богу індексів! Є ще й індекс відновлення даних! Коли ми запускаємо відновлення машини, розташованої в капасити тирі, читатимемо тільки унікальні блоки даних, яких немає в перфоманс тирі.

як стало

На цьому з вступною частиною все. Вона досить докладна, але, як говорилося вище, без цих подробиць не вдасться пояснити, як працюють нові функції. Тому без зайвих передмов переходимо до першої.

Режим копіювання

Багато в чому заснований на існуючих технологіях, проте несе зовсім іншу логіку використання. 

Ціль цього режиму — гарантувати, що всі дані, розташовані на локальному екстенті, мають копію в капасити тире.

Якщо порівняти в лоб Move та Copy режими, то вийде так:

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

У розгляді нового режиму пропоную йти від найпростіших прикладів до складних.

У найбанальнішому випадку у нас просто з'являються нові файли з інкрементами, і ми просто копіюємо їх у капасіті тир. Безвідносно того, який режим використовується в бекапній джобі, безвідносно того, чи належить він до запечатаної частини ланцюжка чи ні, безвідносно того, чи закінчилося наше операційне вікно. Просто взяли та скопіювали.

Процес, що стоїть за цим, — як і раніше, дегідрація у тому вигляді, як було описано вище. У копальні режимі вона також стежить, щоб ми не копіювали блоки, які вже є на нашому сторожі. Єдина відмінність - це якщо в режимі ми замінювали реальні файли файлами пустушками, то тут ми їх ніяк не чіпаємо і залишаємо все як є. В іншому це такий самий індекс дегідрації, який старанно намагається економити ваші гроші і час.

Виникає питання - якщо подивитися в UI, то там є можливість вибрати обидві опції одночасно. Як працюватиме такий суміщений режим?

Давайте розбиратися.

Початок стандартний: створюється файл бекапа і відразу копіюється. До нього створюється інкремент і також копіюється. Так відбувається до моменту, коли ми розуміємо, що файли вийшли з нашого операційного вікна і з'явився запечатаний ланцюжок. У цей момент ми виконуємо операцію дегідрації та замінюємо ці файли пустушками. Звісно, ​​повторно на капасити тир нічого не копіюємо.

За всю цю захоплюючу логіку відповідає лише одна галочка в інтерфейсі.

А навіщо цей Copy режим?

Навіть краще перефразувати питання так — від яких ризиків ми захищаємось за його допомогою? Яку проблему він допомагає вирішувати?

Відповідь очевидна: звичайно ж, це відновлення даних. Якщо у нас на обжект стораджі є повна копія локальних даних, то байдуже, що трапиться з нашим продом, ми завжди можемо відновити дані з файлів, розміщених в умовному амазоні.

Тому давайте пройдемося за можливими сценаріями, від найпростішого до складнішого.

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

Сумніша історія — у нас зламався один із екстентів нашого SOBR репозиторію.

Ще гірше стає, коли весь SOBR репозиторій став недоступним, але працює капасити тир.
І зовсім все погано — це коли вмирає бекапний сервер і твоє перше бажання спробувати добігти до канадського кордону за десять хвилин.

А тепер давайте розберемо кожну ситуацію окремо.

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

Тепер ситуація складніша. Припустимо, що наш SOBR складається з двох екстентів, що працюють у Performance режимі, а значить наші .vbk і .vib розмазані по них досить нерівномірним шаром. І в якийсь момент часу один із екстентів стає недоступним, а користувачеві треба терміново відновити машину, частина даних якої лежить саме на цьому екстенті.

Користувач запускає Візард відновлення, вибирає точку, на яку хоче відновити, а Візард в процесі роботи приходить до усвідомлення, що всіх необхідних для відновлення даних локально у нього немає і тому їх треба завантажити з капасити тиру. При цьому блоки, які залишилися на локальному сховищі, не скачуватимуться з хмари. Слава restore індексу (так, про нього теж було на початку статті).

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

І найцікавіша ситуація — помер бекапний сервер. Тут є два варіанти: адмін молодець і робив конфігураційні бекапи, і адмін сам собі злісний Буратіно і не робив конфігураційний бекап.

У першому випадку йому буде досить десь розгорнути чисту інсталяцію VBR і відновити його базу з бекапа штатними засобами. На завершення цього процесу все повернеться на круги свої. Або ж буде відновлено за одним із сценаріїв вище.

Але якщо адмін або сам собі ворог, або бекап конфігурації теж спіткала билина невдача, то навіть тут ми не кинемо його напризволяще. Для цього випадку ми запровадили нову процедуру, яка називається Import Object Storage. Вона дозволяє пропустити процес відтворення вручну SOBR репозиторію та прикріплення до нього капасити тиру з наступним ресканом, а просто додати обжект сторадж в інтерфейс віма та запустити Import Storage Repository процедуру. Єдине, що може стати на шляху між вами та вашими бекапами – це прохання ввести пароль, якщо ваші бекапи були зашифровані.

На цьому про Copy Mode, мабуть, все і ми переходимо до

Sealed Mode

Основна задумка – на вибраному екстенті SOBR репозиторію не можуть з'являтися нові бекапи. До v10 у нас був лише Maintenance Mode, коли повністю заборонялася будь-яка робота з репозиторієм. Такий собі хардкорний режим виведення сховища з роботи, де доступна лише кнопка Evacuate, що разово перевозила бекапи на інший екстент.

А Sealed mode - це своєрідний "м'який" варіант: ми забороняємо створювати нові бекапи і поступово видаляємо старі згідно з обраним ретеншном, але в процесі не втрачаємо можливість відновлюватися з точок, що зберігаються. Дуже корисна штука, коли у нас або добігає кінця термін життя залізниці і її треба буде замінити, або її просто треба звільнити під щось важливіше, а брати і разово все переносити нікуди. Або не можна видалити.

Відповідно, принцип роботи досить простий: треба заборонити всі write операції (поява нових даних), залишивши read(рестори) і delete(ретеншн).

Обидва режими можна використовувати одночасно, тільки треба враховувати, що у Maintenance пріоритет вищий.

Як приклад розглянемо SOBR, що складається із двох екстентів. Припустимо, перші чотири дні у нас створювалися бекапи в режимі Forward Forever Incremental, а потім ми запечатуємо екстент. Якщо наш ретенш дорівнює чотирьом, то коли весь ланцюжок, розташований на запечатаному екстенті, вийде за його межі, він зі спокійною совістю видаляється.

Є ситуації, коли вилучення відбувається раніше. Наприклад, це Forward incremental із періодичними фулами. Якщо перші два дні у нас створювалися фул бекапи, а в четвер ми вирішуємо запечатати репозиторій, то в п'ятницю, коли створиться новий фульник, файл за понеділок буде видалено т.к. до цієї точки немає залежностей. І сама точка ні від кого не залежить. Після чого ми чекаємо коли будуть створені чотири точки на доступному екстенті і видаляємо три, які залишилися, які не можуть бути видалені незалежно один від одного.

Простіші справи з Reverse Incremental. У ньому найстаріші точки не залежать і можуть бути спокійно видалені. Тому, як тільки буде створено новий .vbk на новому екстенті, старі .vrb по одному видалятимуться.

До речі, чому ми щоразу створюємо новий .vbk: якщо його не створювати, а продовжувати старий ланцюжок інкрементів, то старий .vbk підвисав би на нескінченно довгий час у будь-якому режимі, перешкоджаючи його видаленню. Тому було ухвалено рішення, що як тільки запечатується екстент, ми створюємо фул бекап на вільному екстенті.

Складніші справи з капасити тиром.

Спочатку розглянемо copy mode. Припустимо, що у нас чотири дні активно створювалися бекапи, а потім капасіті тир було запечатано. Ми нічого не видаляємо, а смиренно витримуємо ретеншн, після чого видаляємо дані з капасити тиру.

Приблизно те саме відбувається при move mode - вичікуємо ретенш, видаляємо старе в локальному сховищі, видаляємо стораджі, що зберігається в обжект.

Цікавий приклад із Forever forward incremental. Встановлюємо ретенш у три крапки і починаємо з понеділка робити бекапи, які справно копіюються у хмару. Після запечатування сховища бекапи продовжують створюватися, витримуючи три точки, але дані, що зберігаються в капасити тире, залишаються залежними і не можуть бути видалені. Тому ми чекаємо четверга, коли наш .vbk виходить за рамки ретеншн, і тільки тоді спокійно видаляємо весь збережений ланцюжок.

І невелике застереження: всі приклади тут показано з однією машиною. Якщо у вас в бекапі їх кілька, то ретенш у них відрізнятиметься залежно від того, був зроблений Active Full чи ні.

На цьому, в принципі, все. Отже переходимо до найхардкорнішої фічі.

Незмінюваність

Як і з попередніми пунктами, насамперед про те, яку проблему вирішує ця функція. Як тільки ми вивантажуємо кудись наші бекапи на зберігання, виникає гостре бажання гарантувати їх збереження, тобто фізично заборонити їх видалення та будь-яку модифікацію протягом заданого ретеншена. У тому числі адмінами, у тому числі під їхніми рутовими обліками. Це дозволяє захистити їх від випадкового чи навмисного псування. Хто працює з AWS, міг зустрічати подібну функцію під назвою Object Lock.

Тепер розглянемо режим у загальних словах, а потім заглибимося до деталей. У нашому прикладі Immutability буде включений для нашого капасити тиру з ретенш на чотири дні. А в бекапі включено режим Copy.

Immutability не взаємодіє із загальним ретеншном. Наприклад, він не додає додаткових точок чи щось таке. Просто протягом чотирьох днів людина не може видалити файли бекапи. Якщо в понеділок зробити бекап, видалити його файл вийде тільки в п'ятницю.

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

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

Візьмемо тимчасову шкалу в шість днів і знизу відзначатимемо час очікуваного закінчення незмінності. Беремо і створюємо в перший день файл, що складається з блоку даних а, та його метадані. Якщо нездатність встановлена ​​в три дні, логічно припустити, що на четвертий день дані будуть розлочені та видалені. На другий день додамо новий file2, що складається з блоку b з тими самими налаштуваннями. Блок все ще повинен бути видалений на четвертий день. Але третій день трапляється страшне — створюється файл File3, що з нового блоку d і посилання старий блок а. Це означає, що для блоку, а його невимушеність прапор повинен бути перевиставлений на новий термін, який зсувається на шостий день. І тут постає проблема — у реальних бекапах таких блоків виникає величезна кількість. А щоб продовжити їм неабиякий період, треба щоразу здійснювати величезну кількість запитів. І фактично це буде близько-нескінченний щоденний процес, тому що з великою часткою ймовірності ми при кожному копіюванні знаходитимемо здорові пачки дедуплікованих блоків. А що означає велика кількість запитів у провайдерів обжект стораджів? Правильно! Величезний рахунок наприкінці місяця.

І щоб не виставляти на рівному місці на солідні гроші своїх улюблених клієнтів, придумали механізм block generation. Це додатковий період, який ми додаємо до виставленого періоду невимушеності. У прикладі нижче такий період дорівнює двом дням. Але це лише для прикладу. Насправді там використовується своя формула, що дає приблизно десять додаткових днів при місячному лоці.

Продовжимо розглядати ту ж саму ситуацію, але вже з block generation. Створюємо першого дня file1 з блоку а і метаданих. Складаємо період поколінь та immutability - значить, можливість видалити файл буде на шостий день. Якщо на другий день ми створимо File2, що складається з блоку b і посилання на блок а, то з гаданою датою видалення нічого не відбувається. Вона як стояла шостого дня, так і стоїть. А ми тим самим намагаємось заощаджувати гроші на кількості запитів. Єдина ситуація, коли термін може бути зрушений, це якщо generation period минув. Тобто, якщо на третій день новий File3 міститиме посилання на блок а, то буде додано generation 2 так як Gen1 вже минув. А очікувана дата видалення блоку зміститься на восьмий день. Це дозволяє нам драматично знизити кількість запитів на продовження життя дедуплікованих блоків, що економить вагон грошей клієнтам.

Сама технологія доступна користувачам S3 та S3-сумісного заліза, виробники якого гарантують, що їх реалізація не відрізняється від амазонівської. Звідси відповідь на законне питання, чому не підтримується Azure - вони мають схожу фічу, але вона працює на рівні контейнерів, а не окремих об'єктів. До речі, в самому амазоні обжект лок є у двох режимах: compliance та governance. У другому випадку залишається можливість, щоб найбільший адмін над адмінами і рут над рутами, незважаючи на обжект лок, все ж таки видалив дані. У разі compliance все прибито цвяхами намертво і бекапи не видалити нікому. Навіть у адмінів амазону (за їхніми офіційними заявами). Ми підтримуємо саме цей режим.

І, традиційно, трохи корисних посилань:

• Про Генерація блоків у всіх подробицях.
• Вся інформація про Veeam Backup & Replication 10 у кращому вигляді
• О Capacity Tier в деталях

Джерело: habr.com