Jak Veeam pracuje s objektovým úložištěm a využitím Immutability

Pozn.: Popis v článku vychází z Veeam Backup & Replication 12.3, licencováno pomocí Veeam Universal License (VUL), tedy obdoba Enterprise Plus.

Úvod

Objektovým úložištím, i ve spojení s Veeam Backup & Replication, jsme se věnovali již v několika článcích. Zde se snažím detailněji rozebrat a shrnout, jak Veeam ukládá zálohy (Restore Points), pracuje s nimi, nastavuje Immutability, maže zálohy s vypršenou retencí atd. Některé věci byly zmíněny již dříve. Starší články také obsahují řadu souvisejících informací a praktické ukázky konfigurace.

Souborové versus objektové úložiště

Když se rozhodneme využít objektové úložiště pro ukládání záloh, tak musíme počítat s tím, že má toto řešení výhody i nevýhody. Práce s uloženými daty je značně odlišná od běžné práce se soubory. U většiny Backup Repositories ukládáme zálohy jako soubory. Můžeme je jednoduše kopírovat, pracovat s nimi a máme přehled o existujících Restore Points na úložišti. Na objektovém úložišti se nachází ohromné množství objektů a je skoro nemožné zjistit k jakému patří Restore Point.

Object Storage (objektová úložiště)

Obecný popis objektových úložišť (a základní srovnání s dalšími typy) obsahuje článek Co je objektové úložiště (Object Storage)?. Veeam podporuje řadu typů a poskytovatelů objektových úložišť. Může jít o cloudovou službu i lokální úložiště, nejčastěji S3 kompatibilní.

Immutability (neměnnost)

Jedna z důležitých vlastností, proč zvolit objektové úložiště, je podpora Immutability (nejčastěji pomocí funkce S3 Object Lock). Neměnnosti můžeme dosáhnout i jinak, ale u objektových úložišť funguje jednoduše a spolehlivě (jde o nativní vlastnost).

Princip Immutability, a různé možnosti, jak ji dosáhnout ve Veeam Backup & Replication, popisuje článek Veeam Backup & Replication - Immutable Repository a bezpečné zálohy.

Praktické použití Object Storage Repository

Objektové úložiště můžeme využít jako Backup Repository pro Backup Job nebo Backup Copy Job. Můžeme jej použít také v rámci Scale-Out Backup Repository (SOBR), ale to zde neřešíme. Zálohy můžeme ukládat přímo na objektové úložiště (Direct-to-Object Storage), tedy vytvářet primární kopii (v SOBR Performance Tier). Nebo zálohy kopírovat (Backup Copy) a vytvářet sekundární kopii (v SOBR Capacity Tier).

Použití S3 Compatible Object Storage Repository (NetApp ONTAP) a Microsoft Azure Blob Storage Repository jsme prakticky popsali v článku Veeam Backup & Replication - Object Storage Repository a Immutability. Wasabi Cloud Storage Repository se věnuje článek Veeam Backup & Replication - Wasabi jako objektové úložiště záloh.

Retention Policy (zásady uchovávání) a mazání Restore Points (bodů obnovy)

Každý úspěšný běh zálohovací úlohy (provedení zálohy) vytváří Restore Point (bod obnovy). Uchovávat jich chceme pouze omezené množství, proto nastavujeme Retention Policy (Short-Term Retention Policy). Zadáváme počet dní nebo bodů obnovy, které se mají uchovat. Automaticky dochází k odstraňování nejstarších bodů obnovy, které překračují retenci. Retention Policy určuje počet Restore Points v Backup Chain (řetězci záloh).

Obecné vlastnosti (primárně pro retenci ve dnech):

• Minimálně se vždy uchovávají 3 Restore Point. Když máme retenci několik dní, úlohu na delší dobu zastavíme a opět zapneme, tak po provedení zálohy zůstane jedna nová a dvě staré zálohy (tedy retence nesmaže všechny staré zálohy).
• Retention Policy se aplikuje po úspěšném běhu zálohovací úlohy. Pokud úloha neběží nebo neskončila korektně, tak se zálohy nemažou.
• Bod obnovy má datum podle toho, kdy byla úloha spuštěna. Retention Policy počítá počet dní, až když úloha skončí. Pokud běží do dalšího dne, tak se může odmazat 1 záloha navíc.
• Ve skutečnosti Veeam často uchovává body obnovy N + 1 dní.
• Pokud odstraníme VM ze zálohovací úlohy, tak v zálohách stále zůstává. Dokud neprovedeme aktivní plnou zálohu nebo na úloze není nastaveno Remove deleted items data after. Je to proto, že se vždy uchovávají minimálně 3 body obnovy (když nevznikají nové, tak zůstávají staré).

Jak proběhne zpracování bodů obnovy (odstranění nejstarších nebo sloučení s nejbližším) záleží na typu (třeba Forever Forward Incremental) a formátu (třeba Per-Machine Backups with Separate Metadata Files) zálohovacího řetězce (Backup Chain).

Forever Forward Incremental

Forever Forward Incremental Backup Retention Policy

• první proběhne aktivní plná záloha (VBK)
• dále probíhají pouze přírůstkové zálohy (VIB)
• po vytvoření nového bodu obnovy se kontroluje Retention Policy dané úlohy, pokud je překročena retence (N + 1 dní), tak se nejstarší VIB sloučí do VBK (datové bloky VIB se vloží do VBK, VIB se odstraní), tím se (syntetická) plná záloha posune dopředu (o jeden den)

Forward Incremental

Forward Incremental Backup Retention Policy, Removal of Restore Points from Forward Incremental Chains

• první proběhne aktivní plná záloha (VBK)
• dále probíhají přírůstkové zálohy (VIB)
• pravidelně je naplánováno provedení syntetické nebo aktivní plné zálohy (VBK), které rozdělí Backup Chain na kratší série
• po přidání nového bodu obnovy se kontroluje Retention Policy dané úlohy, pokud celý Backup Chain překračuje retenci, tak se celý odstraní (musí zůstat minimálně aktuální řetězec)

Záleží tedy jak často provádíme plnou zálohu a jaká je retence. Pokud třeba děláme Full Backup jednou týdně a chceme udržovat 7 dní, tak se bude uchovávat 7 až 14 dní.

Background Retention

Mimo aplikace Retention Policy v rámci běhu úlohy se provádí také Background Retention a pro objektová úložiště Background Checkpoint Removal Job. Pro tyto úlohy nalezneme log v History - System - Background retention.

Full Backup (plná záloha)

Aktivní plná záloha (Active Full Backup) provádí kompletní zálohu dat (načte všechna data) ze zálohovaného zdroje. Ukládá se do VBK souboru (standardně deduplikovaně a komprimovaně).

Syntetická plná záloha (Synthetic Full Backup) vzniká spojením předchozí plné zálohy s následnými přírůstkovými. Záloha se syntetizuje z dat, která již jsou na zálohovacím úložišti. Vytváří se nový soubor, který zabírá daný diskový prostor. Pokud využíváme souborový systém s Fast Clone (ReFS nebo XFS), tak můžeme ušetřit prostor (i čas kopírování), protože se využívají odkazy na bloky dat v předchozích souborech.

Immutability period (období neměnnosti)

V konfiguraci Backup Repository nastavujeme neměnnost. Dobu, po kterou není možné uložená data měnit nebo mazat. Pokud je záloha neměnná, tak nemůže být odstraněna při překročení retence. Čeká se, až skončí období neměnnosti (Immutability) a uchovávání (Retention), pak se tyto soubory odstraní.

Block Generation (generace bloků)

K zadané době neměnnosti aplikuje Veeam ještě Block Generation. Časový úsek, ve kterém mají všechny bloky v zálohách (plné i přírůstkové zálohy) stejnou dobu neměnnosti. Pro většinu objektových úložišť je to 10 dní. Hodnotu můžeme změnit zásahem do registrů (ale moc se to nedoporučuje).

Příklad, jak se nastavuje datum neměnnosti. Immutability period na úložišti máme 20 dní, Block Generation period je 10 dní. Každý den probíhá záloha, začínáme 1.1. V tomto příkladě neuvažujeme Retention Policy (komplexní popis je dále v článku).

• vytvoří se první plná záloha (FB), nastaví se neměnnost 30 dní (do 31.1.)
• devětkrát proběhne přírůstková záloha (IB), nastaví se neměnnost 29, 28 … 21 dní (vždy do 31.1.)
• desetkrát proběhne přírůstková záloha (IB), nastaví se neměnnost 30, 29 … 21 dní (vždy do 10.2.)
• desetkrát proběhne přírůstková záloha (IB), nastaví se neměnnost 30, 29 … 21 dní (vždy do 20.2.)
• a tak stále znovu, vždy 10 Restore Points spadá do stejné generace

Jak funguje ukládání záloh na objektové úložiště

Pokud máme v zálohovací úloze (Backup Job) jako cíl objektové úložiště, tak se standardně vytváří Forever Forward Incremental a používá se formát Per-Machine Backup with Separate Metadata Files. Pro Backup Copy Job platí obecně to samé i na jiných typech úložišť.

Objektové úložiště nepracuje se soubory, ale s objekty. Veeam rozdělí soubory záloh (Restore Points) na bloky určité velikosti (standardně 1 MB), ty komprimuje a přenese jako objekty na objektové úložiště. Využívají se Checkpoints, které obsahují odkazy na objekty jednotlivých Restore Points v Backup Chain.

Checkpoints

Pozn.: Oficiální dokumentace příliš Checkpoint nepopisuje. Jediné zmínky jsou v Checkpoints, Extension of Effective Immutability Period a Background Checkpoint Removal Job. Často se řeší na Veeam R&D Forums.

Checkpoint je logická entita, která obsahuje aktuální stav celého zálohovacího řetězce (Backup Chain) v určitém časovém okamžiku (na úrovni metadat). Nachází se zde podrobnosti o tom, které body obnovy jsou aktuálně součástí zálohovacího řetězce a z jakých bloků (objektů) se skládají. Soubor Checkpoint používá XML formát.

Při každém přenosu dat do Object Storage Repository se vytváří nový Checkpoint soubor s metadaty, který popisuje poslední stav zálohy v úložišti. Když proběhne přírůstková záloha, tak se přenesou objekty s novými (změněnými) daty. Informace o tomto bodu obnovy, spolu s předchozími, se uloží do nového Checkpoint.

Checkpoint verze

Ve většině případů se uchovává pouze jeden Checkpoint. Předchozí stavy zálohovacího řetězce se přepisují. Ale když použijeme Immutability, tak se začne uchovávat několik Checkpoints. Což umožňuje návrat ke staršímu stavu zálohovacího řetězce.

Retention Policy

Využívá se princip Forever Forward Incremental. Když nejstarší Restore Point (řekněme VBK) překročí retenci, tak dojde k jeho spojení (merge) s předchozím (řekněme VIB). To ovšem znamená pouze úpravu Checkpoint (aktualizaci metadat), kde je uvedeno, z jakých objektů se skládá plná záloha (VBK).

Odstraní se duplicitní Restore Point (sloučený VIB). Smažou se objekty (až když skončí jejich neměnnost), na které odkazuje tento bod obnovy, ale neodkazuje na ně žádný novější. Odstraňování bloků se provádí v rámci Background Checkpoint Removal Job.

Celý princip je podobný, jako u souborového úložiště, kde máme soubor VBK a několik VIB. Ty tvoří Backup Chain a umožňují provést plnou obnovu. Stejné informace se nachází v aktuálním Checkpoint. Na objektovém úložišti nedochází k fyzickému vytváření syntetické plné zálohy (úpravy souborů), protože žádné soubory neexistují. Pracuje se pouze s metadaty. Z pohledu využití diskového prostoru je to podobné jako u souborového systému s Fast Clone. Nekopírují se bloky dat, ale aktualizují se odkazy na existující bloky.

V logu úlohy se nachází akce (stejná jako na souborovém úložišti, bez informace [fast clone], trvá podobně dlouho):

Full backup file merge completed successfully 

Když akce probíhá

Merging oldest incremental backup into full backup file (58% done)

Nastavení a prodlužování Immutability

Neměnnost se nastavuje na každý objekt a chrání celý Backup Chain se všemi jeho Restore Points. Když Veeam ukládá objekty daného Restore Point, tak na ně nastaví Immutability. Hodnota je podle nastavené Immutability Period na daném Backup Repository s aplikací Block Generation.

Potřebujeme chránit celý zálohovací řetězec (přírůstkové zálohy jsou k ničemu, pokud nemáme úvodní plnou zálohu). Takže na existujících Restore Points musíme prodlužovat dobu neměnnosti, aby byla pro celý Backup Chain stejná (a útočník nemohl smazat nejstarší plnou zálohu). Oficiální popis Extension of Effective Immutability Period.

Při každé záloze (přenosu dat do objektového úložiště) vytvoří Veeam nový Checkpoint. Do něj vloží Restore Points (patřící do Backup Chain) z předchozího Checkpoint (staré bloky) plus nově vytvořený Restore Point (právě přenesená data, nové bloky). Pokud objekty předchozích Restore Points nemají stejnou Immutability jako nové datové bloky, tak se jim prodlouží. Veeam udržuje opakovaně používané bloky dat uzamčené tím, že je přiřazuje do nové generace a prodlužuje jejich dobu neměnnosti.

Díky použití Block Generation mají nové bloky 10 dní (v rámci jedné generace) stále stejné datum Immutability. Proto se prodlužování provádí jednou za 10 dní a blokům předchozích Restore Points se posune o 10 dní vpřed. Dalších 9 dní má aktuální generace stejné datum Immutability jako předchozí generace (kde bylo prodlouženo).

Také se uplatňuje Retention Policy, která udržuje délku Backup Chain. Provádí se spojení nejstarších Restore Points (z jakých bloků se skládá Full Backup). Blokům dat, které již nejsou použity ve Full Backup (přepsané nebo smazané), se neprodlužuje Immutability (a po jejím skončení jsou smazány).

Stručný průběh je tedy:

• vytvoří se Restore Point, nastaví se Immutability (Immutability Period + Block Generation Period) na jeho objekty
• jednou za Block Generation Period se prodlouží Immutability na předchozí Restore Points
• pokud je překročena retence, tak se provede spojení Full Backup s předchozím Incremental Backup (v rámci Checkpoint)

Příklad nastavení a prodlužování Immutability

• Immutability Period 10 dní
• Block Generation Period 10 dní
• Retention Policy 20 dní

Následující obrázek schématicky znázorňuje existující Restore Points (Backup Chain) k určitému dni (poslední modrý s černým textem).

• zelené FB znázorňuje Full Backup, na počátku aktivní, později vzniklý spojením se sousedním IB
• modré IB znázorňuje Incremental Backup
• v řádku je vždy jedna generace a vpravo je uvedeno datum neměnnosti, které se postupně aktualizuje

Z průběhu vidíme, že zálohovací řetězec má 20 dní (což odpovídá zadání). Ve Veeam Backup & Replication uvidíme 20 Restore Points. Ale ještě 20 starších Restore Points má aktivní Immutability. Takže nemůže být smazáno, i když již nepatří do aktivního zálohovacího řetězce. Veeam je smaže po vypršení neměnnosti. Na objektovém úložišti se tedy může nacházet až 40 Restore Points (a můžeme se k nim vrátit). Více řešíme v další kapitole.

To odpovídá skutečné retenci (Actual Retention) popsané v dokumentaci.

Actual Retention = Job Retention Policy + Immutability Period + Block Generation Period

Vztah Retention period a Immutability period

Retenci bychom měli (je doporučeno) nastavit minimálně stejnou jako Immutability + Block Generation. Tedy například máme Immutability 10 dní, Block Generation také 10 dní, což znamená neměnnost maximálně 20 dní. Retence by měla být 20 dní nebo více.

Co se stane, když nastavíme retenci kratší než Immutability?

Standardně se uplatní Retention Policy. Restore Points mimo retenci budou odstraněny z metadat zálohy a konfigurace (nový Checkpoint je neobsahuje). Ale data s nastavenou neměnností se budou stále nacházet na objektovém úložišti. Veeam zobrazuje, a umožňuje pracovat, pouze známe Restore Points. Jinak řečeno ve Veeamu uvidíme pouze zálohy spadající do retence.

Načtení záloh z objektového úložiště (Rescan)

Pokud provádíme Disaster Recovery a připojíme úložiště k jinému Veeam Backup & Replication serveru. Nebo jen odebereme zálohy z Veeam konfigurace (Home - Backups, klikneme Ctrl + pravé tlačítko na úlohu, Remove from configuration). Tak můžeme provést Rescan Backup Repository (v Backup Infrastructure - Backup Repositories).

Veeam shromáždí informace o zálohách, které jsou aktuálně dostupné v úložišti, a aktualizuje seznam záloh v konfigurační databázi. Informace získává z uložených metadat (VBM). Pokud nejsou k dispozici, tak nelze importovat zálohu. V našem případě se tedy opět objeví pouze Restore Points, které spadají do retence (a viděli jsme je předtím). I když se na úložišti nachází starší neměnné zálohy.

Návrat k předchozím zálohám (staršímu stavu Backup Chain)

Pokud se potřebujeme dostat k datům, které byly odstraněny pomocí Retention Policy, ale na úložišti stále existují. Tak se musíme vrátit zpět v čase a synchronizovat stav z objektového úložiště (z určitého staršího Checkpoint). Oficiální popis Rolling Back Immutable Data.

Tuto operaci můžeme provést pouze pomocí PowerShellu. Využijeme cmdlety Get-VBRObjectStorageRepositorySyncInterval, Sync-VBRObjectStorageRepositoryEntityState. Při synchronizaci se z konfigurační databáze odstraní aktuální stav zálohovacího řetězce a načte se určitý stav z objektového úložiště.

Nejprve můžeme zjistit časové období, ve kterém můžeme vrátit řetězec záloh zpět (jsou dostupné Checkpoints).

$repository = Get-VBRObjectStorageRepository -Name WasabiRepo
Get-VBRObjectStorageRepositorySyncInterval -Repository $repository

StartDateUtc       EndDateUtc        
------------       ----------        
02.02.2025 1:06:24 16.02.2025 8:41:35

Následně můžeme vrátit stav Backup Chain do libovolného období v dostupném intervalu. Můžeme to provést pro celé Backup Repository.

Sync-VBRObjectStorageRepositoryEntityState -Repository $repository -PointInTime "15.02.2025 10:00:00" 

Name         : Backup Synchronization
CreationTime : 16.02.2025 9:50:20
EndTime      : 16.02.2025 9:53:38
JobId        : 3d30b5bd-84e9-4f46-94bf-19ff34b9556c
Result       : Warning
State        : Stopped
Id           : 7bd391d8-662a-408b-8539-209e8ccdf3b6

Test jsem prováděl na zkušebním úložišti, kde probíhá jedna zálohovací úloha (a různě se mění její parametry). Na úložišti se nacházelo 8 Restore Point, které viděl Veeam. Zkrátil jsem Retention Policy na 2 dny a spustil úlohu. Veeam ukazoval 3 Restore Point. Vrátil jsem stav o den zpět a v seznamu záloh se objevilo (korektně) 7 Restore Point.

Cmdlet skončil varováním. Informace nalezneme v logu (defaultní cesta) C:\ProgramData\Veeam\Backup\DirectBackupSync\DirectBackupSync.log. Zajímavé je, že podle logu se pokoušel pracovat také se zálohami, které jsou ukládány do jiného kbelíku, a tedy jiného Backup Repository. Na nich došlo k varování, že nebylo nic zpracováno.

Jistější možná je specifikovat nejen úložiště, ale také zálohovací úlohu.

$repository = Get-VBRObjectStorageRepository -Name WasabiRepo
$job = Get-VBRJob -Name Copy-HyperV-Wasabi
Get-VBRObjectStorageRepositorySyncInterval -Repository $repository -Job $job

StartDateUtc       EndDateUtc        
------------       ----------        
02.02.2025 1:06:24 16.02.2025 8:41:35

Sync-VBRObjectStorageRepositoryEntityState -Job $job -PointInTime "16.02.2025 9:00:00"

Name         : Backup Synchronization
CreationTime : 16.02.2025 10:20:56
EndTime      : 16.02.2025 10:21:59
JobId        : e0ea5740-e76c-42bc-8465-ef5b10aba6bf
Result       : Warning
State        : Stopped
Id           : 0962c9f7-321b-40ab-a177-42420a89275d 

Zkusil jsem použít datum, které je po časovém období. Úloha proběhla s varováním, v logu jsou informace.

Warning (3)    [CDirectBackupSyncPerformer] All checkpoints are older then sync date for backup ... Skipping checkpoint recreation
Warning (3)    Failed synchronize data stored on the object storage repository: the data has been already synchronized.

Při dalším pokusu jsem se vracel na úplný začátek řetězce.

Sync-VBRObjectStorageRepositoryEntityState -Job $job -PointInTime "02.02.2025 1:06:24"

Name         : Backup Synchronization
CreationTime : 16.02.2025 11:19:19
EndTime      : 16.02.2025 11:22:49
JobId        : aed428c0-b0de-4dac-a69e-229400ea5041
Result       : Success
State        : Stopped
Id           : c33d0c71-6865-4cb1-bbf3-11600d9d4bcc 

Musíme počítat s tím, že při posunu zpět zná Veeam konfigurace jen staré Restore Points. Pokud následně proběhne záloha, tak uvidíme staré zálohy plus jednu novou.

Struktura objektového úložiště

Veeam na objektovém úložišti vytvoří a udržuje strukturu adresářů. Určitý popis je v dokumentaci Object Storage Repository Structure.

Pozn.: Mimochodem Anton Gostev na fóru stále zdůrazňuje, že na objektovém úložišti neexistují soubory a složky (ani souborový systém), ale objekty. Jde pouze o virtuální reprezentaci adresářů. V praxi je běžně, že nástroje pro přístup na objektové úložiště pracují, jako by zde existovaly adresáře a soubory.

Zálohy

Dle dokumentace odpovídá cesta k datům jednotlivých záloh ve Wasabi:

Buckets/[jméno kbelíku]/Veeam/Backup/[jméno složky pro Veeam repository]/Clients/[Client ID]/[Backup ID]/CloudStg/Data

Počet složek s Backup ID odpovídá počtu zálohovaných objektů (VM) ukládaných na úložiště. Pod nimi se nachází další složky, kde se patrně ukládají jednotlivé Restore Points. Rád bych podle tohoto ID (dokumentace uvádí, že jde o Backup catalogue - Contains backup ID) nalezl o jaký zálohovaný objekt se jedná.

Pro zjištění různých ID můžeme využít Veeam PowerShell. Ale ID, která si zobrazím, neodpovídají těm, která jsou jako názvy složek. Například pod Clients jsou patrně složky pro jednotlivé zálohovací servery a měly by se identifikovat jejich ID. Když se podíváme do Clients/[Client ID]/Config/ClientInfo.xml, tak zde nalezneme jméno našeho serveru a ID stejné jako složka. Ale vypsání informací o serveru Get-VBRServer -Name backuppraha neobsahuje stejné ID.

Podobně, když si zobrazíme ID jednotlivých záloh, tak neodpovídá názvům složek se zálohami.

$backup = Get-VBRBackup -Name Copy-HyperV-Wasabi
Get-VBRBackupObject -Backup $backup 

Na fóru jsem dostal odpověď, že jde o cloud_backup_id, které se nachází v tabulce backup.model.backups.directbackupinfos. Takže patrně jej nijak jednoduše nezjistíme.

Metadata - Checkpoints

Nejvíce informací nalezneme v Checkpoint souborech. Ty se nachází pod jednotlivými zálohami v cestě:

Buckets/[jméno kbelíku]/Veeam/Backup/[jméno složky pro Veeam repository]/Clients/[Client ID]/[Backup ID]/Metadata/Checkpoint

Jsou zde různé Checkpoint ID. Jde o XML soubory s informacemi o Backup Chain. Pro jednotlivé Restore Points je zde element StgTag, který má v atributu Tag název VKB či VIB souboru. Na začátku souboru jsou obecné informace o zálohovacím řetězci, třeba ExpectedImmutableTillUtc.