В предишната статия Разказахме ви за новите функции в излязлото през януари обновление Update 4 за Veeam Backup & Replication 9.5 (VBR), в което съзнателно не споменахме архивирането на магнитни ленти. Разказът за тази област заслужава отделна статия, защото новите функции наистина бяха много.

– Хей, момчета от QA, ще напишете статия?
– Защо не!

Лентови носители в XXI век

Съхранение на данни на магнитни ленти (касети, “тейпове”, както ги наричаме в R&D) не се ограничава до отминалия компютър ZX-Spectrum, една игра за който можеше да се зарежда в оперативната памет от 48 kb от магнитофонна касета в продължение на няколко минути. За четвърт век скоростите и капацитетите на касетите нараснаха с 6-7 реда. Това не е напълно коректно сравнение, и по Закона на Мур стандарти LTO не успява да настигне. Въпреки това, съвременните технологии позволяват записването на 12 терабайта данни на километрова лента от една касета (до 30 терабайта в режим на компресия), по този начин, 160-доларовият носител остава напред по отношение на цената за дългосрочно съхранение на голям обем данни дори с оглед на инвестициите в оборудване за запис/четене. Данните на такива касети се съхраняват надеждно за 15-30 години.

Ще подходим от друга страна. Напоследък вирусите-вымогатели достигнаха ново ниво. Те могат да чакат своя час в инфраструктурата на голямата компания седмици и месеци, а с появата на нова уязвимост с нулев брой дни – да унищожат (не без помощта на човек, защото става въпрос за много пари) не само всички данни, но и всички резервни копия, до които само могат да достигнат. Ето свеж пример, когато компанията се наложи да плати на изнудвачите. Така наречените air gap, т.е. физически изолирани от инфраструктурата резервни копия, стана в същност единственото надеждно спасение от такива случаи. Магнитната лента е едно от неизменните решения тук.

Но само спецификация и технологични иновации с железни и барий-ферритни продукти от водещи производители (IBM, HPE, Oracle, Dell) не са достатъчни за надеждна защита на данните, необходим е и добър софтуер. В Veeam имаме цяла екип, който се занимава с ленточни резервни копия, около 10 души ежедневно анализират, планират, проучват, разработват и тестват. Резултатите от тази работа можете да видите в предишни статии (раз, два). Какво беше постигнато през последната година?

Глосарий

Става избор между свободите спрямо родния език и усложняващите четенето бюрокризми. Предпочитам първото, затова предварително се извинявам, ако на някого жаргонните термини от списъка по-долу дразнят окото. Тук накратко ще припомня какво означава единичен термин.

На корифеите на VBR част от това може да бъде пропуснатаДжоб – job – задание за резервно копиране. Всъщност, целият VBR е изградена на джобовете. Освен за бекап и репликация, това може да бъде и копиране на магнитна лента (backup to tape job, тейп-джоб). ще уточня, че възстановяването от резервна копия (рестор) също е джоб, но в тази статия под това понятие ще се има предвид именно бекап.

Сторидж – storage – исторически утвърдено название. Това са файлове в репозитории (repository – хранилище), съдържащи резервни копия – пълни и инкрементални. В едно сторидж може да има както една, така и няколко виртуални машини.

Верига – chain – последователност от свързани помежду си сториджи. За възстановяване на данни от n-кия инкрементален сторидж са необходими всички предишни от (n-1)-ия до 1-вия и пълният сторидж, на който се отнася първият инкрементален.

Сорс, таргет – source, target. Сорс – исходна сущност, която обработва джобата. В случая с бекапите/репликите, това обикновено е виртуална машина в хипервизора. В случая на тейп-джоб, сорс е самата бекап-джоба (или файловете в случая file to tape-джоба). Таргет за бекап-джоб е репозитория, където се съхраняват бекапите. За тейп-джоб, това е медиа-пул.

Медиа-пул – media pool – пул носители на информация, в нашия случай – касети. Логическо съдържание, създадено от потребителя и съдържащо касети от една или няколко библиотеки. И така, тейп-джоб винаги има медиа-пул като таргет, т.е. данните не се записват на специфична касета или на произволна касета в библиотеката, а на определен набор от касети. Медиа-пул има настройка за времето на съхранение на данните, след изтичането на което касетата може да бъде презаписана. Потребителят може да създава обикновени (standard) и GFS-пули. Всеки от тези видове сега може да бъде още WORM и не-WORM, за това по-долу.

Медиа-сет – media set – комплект касети в медия-пул, на които непрекъснато се записват бекъпи/файлове. За GFS пуловете медийните комплекти са свързани и с интервала (например, годишен – yearly), касетите се въртят само в рамките на своя интервал.

Диск, чейнджър – елементи на лентовата библиотека. Дискът чете и превърта касетата, чейнджърът е робот, който премества касетите между слотовете за съхранение, слотовете за изтегляне и диска. Има и стенд-алон дискове (standalone – самостоятелно), ролята на чейнджъра тук играе човек. За диска е задължително правилно инсталираният драйвер на производителя на Windows машината, към която е свързана библиотеката; с чейнджъра можем да работим и без драйвери, по native SCSI.

Наемател към касета. Защитен е доставчикът – защитени са клиентите

Сразу козите на масата. Най-мащабната функция на нашето обновление, предназначена за облачни доставчици, използващи във своята инфраструктура VBR. Разработката започна преди две години. Скоро разбрахме, че няма да успеем да се справим с толкова сериозна задача за близкото издание, взехме малка пауза и в крайна сметка пуснахме функцията в версия 9.5 Update 4.

Ако кажем накратко, сега доставчиците имаха възможност да копират бекъпите на своите клиенти на касети с помощта на лентовата работа в GFS пул. Това дава на доставчиците – които са много големи и скъпи за нашето сърце и търговския отдел момчета – две възможности:

• да защитят своите клиенти (наематели, tenant – наемател) от загуба на данни в резултат на случайно изтриване или инфраструктурни проблеми ("наводнение в сървъра");
• да предоставят на наемателите допълнителна услуга за възстановяване на данни от стара резервна копия, която вече е била изтрита от облачния репозиторий в съответствие с политиката за съхранение на данни, но все пак е останала на касетите.

От маркетингова гледна точка функционалността е много "вкусна", а от наша страна – не по-малко сложна за реализиране.

Разработка

Основният възникнал проблем – шифроването на данните. Повечето облачни бекъпи са шифровани, статистиката показва, че ⅔ от общия брой. За нас това число беше изненада, предполагахме, че почти всичко се криптира, но не – много клиенти, изглежда, безусловно вярват на своите доставчици.

Простата на парадигмата: доставчикът не трябва да може да разшифрова данните на своите наематели. В същото време в рамките на новата функция е необходимо на страната на доставчика да се отварят стораджи с бекъпи. Това е нужно, за да се прехвърлят блокове данни, например, за създаване на виртуално пълно резервно копие. Важно е това да се прави независимо от наемателя, когато необходимите ключове не се предават на страната на доставчика по време на изпълнението на джоба.

Решението на този проблем, което е използвано и в друга важна функция на новото допълнение – Capacity Tier – се състои в добавянето на допълнителен ключ за шифроване. Архивният ключ (Archive key) се съхранява в базата данни на доставчика в криптиран вид. Чрез хитра схема на страната на доставчика с него може да се отворят стораджи, да се прехвърлят и прешифроват блокове данни между стораджи (всеки сторадж има свой ключ), но не може да се разшифрова самата информация.

Хитра схема (работещ вариант)

Добавям, че всички инженери в R&D много обичат шифроването в нашия продукт, въпреки че никой не знае в детайли как работи. (Имаше и шега „и защо изобщо работи“, но редакторите не я пропуснаха.)

Тестване

На функцията бяха записани стотици бъгове. Най-трудни области – шифроване, потребителски интерфейс, проблеми при възстановяване.

От гледна точка на тестването трудността представляваше голямата вариативност, „комбинаториката“ на видовете и типовете наемни джоби и репозитории – имам предвид както източник, така и цел по време на възстановяване на бекъпи в инфраструктурата. Всичко това се наслагва върху логиката в рамките на модела GFS (включително новия – паралелизъм и ежедневни медийни сетове, за които по-долу), и като цяло на необичайната за тейповата облачна специфика. Не забравяйте да добавите обилно шифроване. Ако продължим метафората, ние се наядохме с това ястие – но и го опитахме от всяка страна.

Фрагмент от тестовия план

В резултат на това

Подробно описание може да се намери в ръководството за потребителя (засега на английски): бекъп, възстановяване. Ще се спра на основните моменти.

Резервно копие

Доставчикът добавя наематели в тейп-джоба с GFS-пул в качеството на цел. При наличие на облачна лицензия на втория етап от магьосничеството е достъпна опцията НаемателиМожете да добавите всички тенанти наведнъж или поотделно, а можете да изберете и само отделна квота (но не сабквота) на отделен тенант. Не може да се смесват тенантски бекъпи и обикновени локални бекъпи в една джоба.

Останалите настройки почти напълно съвпадат с обикновената джоба в GFS пула.

Възстановяването на данни е възможно както на страна на доставчика, така и на самия тенант.

Възстановяване на страна на доставчика

Извършва се чрез новия магьосник. Тук вече можете да се спуснете до отделна джоба, като се възстановява изцяло веригата, находила се в репозитория на определена дата.

Има три варианта за възстановяване:

1. В оригиналната локация. В този случай оригиналният бекъп, ако има такъв, се изтрива; джобите на тенанта автоматично се пренастройват за възстановената верига. Разбира се, такова възстановяване ще бъде абсолютно незабележимо за клиента, само за кратко време той ще бъде изключен от облачния репозитория.
2. В нова квота/репозиторий. Доставчикът може, например, да създаде за тази цел отделен времемен акаунт, който впоследствие ще изтрие. Бекъпът се появява в инфраструктурата на тенанта след синхронизиране с базата на доставчика.
3. Просто на диска на Linux или Windows сървър, регистриран в инфраструктурата на доставчика. След това тази верига може да бъде запазена на флашка и изпратена на тенанта.

Възстановяване на страна на тенанта

Тази опция предполага наличие на собствена тейп инфраструктура и голям обем данни за възстановяване. Касетата с записаните бекъпи доставчикът може физически да изпрати на клиента с куриер, който я каталогизира на своето оборудване, декриптира касетите и бекъпите и работи с резервните копия, сякаш самият той ги е записал на лента. Това е един трик, за да не изтегляте терабайти по WAN.

Мащабни подобрения на GFS пула

GFS-медийни пулове се появиха в VBR преди две години, в версия 9.5. В издаденото обновление, както във връзка с появата на функцията Tenant to tape, така и по искане на потребителите, значително подобрихме тази функционалност.

Ежедневни медийни сетове

Появи се нов ежедневен (ежедневен) медиасет. Вече в GFS пула можете да съхранявате резервни копия за всеки ден, и не само пълни, но и инкрементални. Последните заемат значително по-малко място и е направено с цел икономия на лента. Предполага се, че тези ленти постоянно се ротират в библиотеката и не се транспортират за отдалечено съхранение. В същото време за възстановяване от инкрементална точка ще са необходими касети от един от по-високите медиасети (седмичен, месечен, тримесечен или годишен). Не може да се включи ежедневен медиасет без включване на седмичен, тъй като в повечето случаи за възстановяване от инкрементална копия са необходими именно седмичните касети. Те или винаги са в библиотеката, или се съхраняват на не толкова отдалечен склад.

Логика на работа на тейп-джобовете в GFS медиапул не е най-простата, техническите писатели няма да излъжат. Ако да обобщим, опускайки детайлите, в седмичните и по-високите медиасети се копират само пълни резервни копия (включително виртуални пълни резервни копия), по едно за всяка дата, а в ежедневния – всички налични в хранилището резервни копия за текущия ден, тъй като резервната работа може да се стартира по-често от веднъж на ден.

Паралелизъм, време за стартиране и изчакване в GFS пуловете

Сега е възможно паралелното записване на няколко верига или джоб на няколко диска в библиотеката и в GFS медиапулите (по-рано – само в обикновените). Включва се на стъпка Опции медиапула.

Важно уточнение: един и същ файл винаги се записва в един поток, затова в случай на няколко големи виртуални машини се препоръчва да се включи настройката per-VM в репозиторите, така че резервната копия да се състои от няколко вериги.

Освен това стана възможно да се избира времето за стартиране на самата GFS работа. На много потребители не им харесваше стартирането в полунощ и последвало изчакване почти цял ден, докато сорс джобът завърши. Сега това време може, например, да бъде зададено за късния вечер, когато вече е натрупано нещо за копиране на лента. Освен това, по искане на потребителите, добавихме опцията в разширените настройки, която преди можеше да се активира само с помощта на ключ от регистъра. Достатъчно е да изберете Обработете най-скорошната точка на възстановяване вместо да чакате – и на касетата се копира това, което има в репозитория в момента на стартиране на тейп-джобата (точката от вчера, например), без никакво чакане.

Подобрена работа с множество библиотеки

Ще разгледаме ситуация, когато в един медиапул е добавена повече от една библиотека. Ние сме поддържали това и преди, но от време на време получавахме жалби от клиенти за непредсказуемо поведение.

Имаше

Например, стартирала е задача за запис, която е заела два диска в първата библиотека, но настройките за паралелизъм позволяват използването на 4 диска едновременно. Трябва ли тази задача да премине към втората библиотека в медиапула и да я използва също, или това ще бъде преразход на ресурси?

Друг случай. Избрана е опцията за превключване по условие "няма налични касети", в първата библиотека има само една касета, но на нея потенциално могат да се запишат всички данни. Въпреки това настройките позволяват паралелно записване на две касети. Трябва ли да се използва втората библиотека в този случай?

Решихме да подредим тази област, предоставяйки възможност за явно настройване на поведението.

Стана

За библиотеките в медиапула са въведени роли – активна и пасивна. А самият медиапул има два режима: отказоустойчив, или фейловер (failover) и паралелно записване (paralleling). Сега, в зависимост от изискванията, може да настроите медиапула по различен начин.

• Ако имате няколко равноправни библиотеки и е необходимо да разпаралелите записа в тях – включете режима за паралелно записване, за което на всички библиотеки трябва да се назначат активни роли. В този случай новите касети и дискове ще бъдат задействани веднага, когато възникне необходимост, без значение в коя библиотека се намират. Все пак има приоритет – първо ще се опитваме да намерим ресурси в библиотеката, разположена по-горе в списъка.
• Ако имате една основна библиотека и един стар или резервен диск, включете режима на фейловер, като поставите основната библиотека най-горе в списъка и изберете пасивна роля за резервните устройства. Превключването към такова устройство ще се извършва само когато това е наистина необходимо, за да работи задачата изобщо. Такава ситуация ще се счита за извънредна, за което ще бъде изпратено уведомление на електронната поща.

Съществува по-сложна ситуация, която в момента не поддържаме – няколко активни библиотеки при наличие на пасивни. Обратната връзка ще покаже дали има нужда от такива конфигурации и необходимо ли е да 'поправим' функцията в бъдеще. Стандартна практика.

Поддръжка на WORM

WORM – Записвай веднъж, чети много – касети, които не могат да бъдат изтрити или презаписани на ниво хардуер, могат да бъдат добавяни само данни. Задължителната им употреба се регламентира от правилата на определени организации, например, работещи в сферата на медицината. Основният проблем с такива касети преди беше, че VBR при инвентаризация или каталогизация записваше заглавие, което по-късно не можеше да бъде изтрито, и тейп-работите се проваляха с грешка при такъв опит.

В Update 9.5 Update 4 е реализирана пълна поддръжка на такива касети. Добавени са WORM медиа пулове, обикновен и GFS, където могат да бъдат поставени само касети от този тип.

Новите касети имат синя, 'замразена' иконка. От гледна точка на потребителя, работата с WORM касети не се различава от работата с обикновени.

'Wormността' на касетите първоначално се определя по суфикс на баркода, а ако баркодът им е обикновен или нечетим, информацията се предоставя от драйвера при първоначалното поставяне на касетата. Не е възможно да се поставят WORM касети в обикновен медия пул и да се пише на тях. Интересното е, че вече има потребители, които лепят WORM баркодове на обикновени касети и се учудват на промените в своята инфраструктура след ъпдейта.

Чип на касетата

Паралелно с внедряването на не-презаписваеми касети започнахме да работим с чипа. Стандартните атрибути в чипа преди не бяха използвани от нас, сега в някои от тях записваме и четем, но не ги възприемаме като основен източник на данни. Основен ориентир – все още е заглавието на касетата. Това решение се оказа правилно: след месец след релиза виждаме как 'зоопаркът' от хардуер на потребителите ни изненадва в работата с чипа.

Бакъп на NDMP томове на лента

В заключение – за най-търсената функция по количество отзиви от този ъпдейт. Стана достъпен бакъп на NDMP томове на касети. В инфраструктурата на VBR е необходимо да добавите NDMP сървър, след което в файловата тейп-дейност ще бъде възможно да се изберат томове от този хост. Те се записват на касети под формата на файлове със специален атрибут, за да бъдат отличавани от обикновените при каталогизация.

В първата реализация има определени ограничения: не се поддържат разширения (extensions), плюс е възможен бекъп и възстановяване само на целия том, но не и на отделни файлове. Бекъпът работи през dump (в случай на NetApp – ufsdump), тук има свои особености: максималното количество инкрементални точки е 9, след което се форсира пълна резервна копия.

В заключение

Това бяха само най-значителните нововъведения в областта на резервното копиране на магнитна лента в VBR 9.5 Update 4. Други промени ще предоставя в списък:

• възможност за определяне на реда на сорс-дейности и файлове в тейп-дейностите;
• добавена роля Tape Operator (потребителят може да прави всичко, с изключение на възстановяването от лента – за това е Restore Operator);
• добавени са пълноценни include/exclude-маски в файловата тейп-дейност (освен NDMP);
• доработено възстановяване в файловата тейп-дейност (папката се възстановява с файловете, които са били там в момента на бекъпа, а не с всички, които някога са били в нея за цялата история на бекъпите – много търсена функция, между другото);
• увеличена е скоростта на възстановяване на много голям брой файлове от касети;
• доработен алгоритъм за избор на следващата касета за запис, в частност, при равни условия се взема предвид обемът на записаните/прочетените данни през целия й живот, взимаме най-новата;
• подобрен е продуктът по отношение на стабилност.

Полезни връзки

За разнообразие ще предоставя няколко линка и на руски ресурси:

• Линк за изтегляне на безплатната пробна версия VBR 9.5 Update 4
• Статия в Хабра «Полезни съвети за архивиране на бекъпи Veeam на магнитна лента»
• Статия в Хабра «7 полезни съвета за защита на резервните копия от вируси-шифровальчици»
• Раздел от ръководството за потребителя, отнасящ се до тейпове (на английски език)
• И се върнахме на предишното място с обзорните видеа «Как работи» (обаче, засега на английски език) – можете да го гледате тук.. За тейповете се разказва на слайдове 95 – 102.

Източник: habr.com