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

Backup Job - zálohovací úloha

V minulých dílech jsme si prošli teorii a základní fungování Veeam Backup & Replication (VBR), takže nyní můžeme s těmito znalostmi vytvořit rozumnou zálohovací úlohu. Předpokladem je, že máme nainstalovaný a nastavený Veeam Backup & Replication, s přidanými komponentami, včetně zdrojů dat pro zálohování.

Zálohovací úlohu můžeme vytvořit z pohledu Home (ale prakticky odkudkoliv), například z menu záložky Home volba Backup Job. Úlohy jsou děleny podle typu zdroje zálohování a úloha může obsahovat pouze objekty stejného typu.

Můžeme zde vytvořit úlohu pro zálohování téměř všeho co Veeam podporuje. Standardně jde o

• virtuální stroje (VM) VMware vSphere (VMware Backup), Microsoft Hyper-V (Hyper-V Backup)
• souborová úložiště (File Share Backup)
• Veeam agenty s různým OS, jako Windows computer (Windows Agent Backup) a Linux computer (Linux Agent Backup)

Nelze zde vytvořit úlohu pro zálohování pomocí Veeam Plug-in (ta se vytvoří vzdáleně konfigurací pluginu).

Virtual Machine (VM) Backup Job

• VMware Creating Backup Jobs, Hyper-V Creating Backup Jobs

Standardní zálohování VM probíhá skrze virtualizaci, takže nemusíme mít síťový (LAN) přístup do VM. To je potřeba pouze pro Guest Processing, kdy se zálohovací server po síti připojí do OS. Zpracování probíhá na Backup Proxy.

Při vytváření nebo editaci zálohovací úlohy typu Virtual Machine (VMware vSphere a Microsoft Hyper-V jsou téměř identické) procházíme průvodce a na několika záložkách nastavujeme různé parametry. Stručný soupis většiny položek:

• Name - každá úloha musí mít unikátní název, který nám napoví její účel/obsah
• Virtual Machines - základem úlohy je určení, které virtuální počítače budeme zálohovat, můžeme přidat VM, VM kontejnery (pokud se do kontejneru přidá nové VM, tak se automaticky přidá do zálohovací úlohy) nebo VM Tagy (štítky, opět se automaticky přidají označené VM)
  • v panelu nástrojů (v pravém horním rohu) můžeme přepínat pohledy, abychom viděli určité objekty
  • můžeme také využít Exclusions (výluky) a vynechat ze zálohy určitá VM z VM kontejneru, VM disky nebo VM templates
  • jednotlivá VM se zpracovávají postupně, můžeme upravit preferované pořadí
• Storage - nastavujeme mnoho důležitých vlastností zálohování a uchování záloh
  • Proxy, Repository (pomocí Map backup můžeme úlohu namapovat na existující zálohy), Retention Policy (kolik bodů obnovy nebo dní chceme uchovat), GFS (zásady dlouhodobého uchovávání)

• Advanced - Backup - zálohovací metoda (Backup mode) a možnost vytváření Full Backup (Active nebo Synthetic), pokud pro Incremental nenastavíme Full Backup, tak půjde o Forever Forward Incremental

• Advanced - Maintenance - můžeme naplánovat pravidelné provádění údržby, kontrolu posledního Restore Point - Perform backup files health check a údržbu Full Backup, pokud neprovádíme pravidelně aktivní plnou zálohu, jde o smazání odstraněného VM ze záloh (když bylo VM smazáno nebo vyjmuto ze zálohování) - Remove deleted items data after, defragmentace a zhutnění (vytvoří novou plnou zálohu, do které kopíruje data) - Defragment and compact full backup file
• Advanced - Storage - nastavení redukce dat - deduplikace, komprese, vynechání Windows swap files a smazaných bloků, optimalizace úložiště (velikost datových bloků), a šifrování záloh
• Advanced - Notifications - nastavení upozornění při dokončení úlohy (můžeme nastavit globálně nebo upravit pro jednotlivou úlohu, abychom mohli nastavit na úloze, tak musí být povoleno globálně, například pokud nepovolíme globálně Success, tak nebude fungovat při nastavení na úloze) - SNMP, email, pro VMware nastavit atribut VM
• Advanced - vSphere / Hyper-V - zapnutí Guest quiescence (uklidnění VMware tools quiescence nebo Hyper-V guest quiescence) zmrazí VM souborový systém (uvede do konzistentního stavu) během zálohy, Veeam doporučuje využít spíše jejich vlastní Application-aware Processing, a zapnutí Changed block tracking, pro Hyper-V se doporučuje využít Allow processing of multiple VMs with a single volume snapshot (nefunguje pro Hyper-V Server 2016 s On-Host Proxy)
• Advanced - Integration - pro VMware můžeme nastavit Backup from Storage Snapshot (defaultně povolené)
• Advanced - Scripts - můžeme spouštět vlastní skripty před a/nebo po zálohovací úloze
• Guest Processing - můžeme povolit různé operace, kdy Veeam komunikuje s operačním systémem VM, využívá buď dočasné komponenty (Non-Persistent Runtime Components), které nasadí při začátku úlohy, nebo (podle mne lepší) trvalého agenta (Persistent Guest Agent - Guest Helper a Log Shipping Service), který vyžaduje méně otevřených portů
  • Application-Aware Processing - detekuje a připraví aplikace pro konzistentní zálohu
  • Guest File System Indexing - vytvoří katalog souborů, který umožní prohlížení, vyhledávání a obnovu jedním kliknutím z Veeam Backup Enterprise Manager, není potřeba pro Instant File Level Recovery

• Schedule - můžeme naplánovat pravidelné spouštění úlohy (druhá možnost je spouštět ručně)
  • můžeme nastavit určitý čas denně nebo měsíčně, opakovaně v průběhu dne nebo úlohy zřetězit, kdy se úloha spustí po dokončení jiné zvolené plánované úlohy (řetězení úloh má určitá rizika, doporučuje se mu vyhnout)
  • můžeme zapnout automatické opakování zálohy VM, které selhalo
  • ukončit úlohu, pokud překročí povolené časové okno zálohování

Retention Policy

Když je překročen zadaný počet bodů obnovy nebo dní, tak je nejstarší Restore Point odstraněn. Ovšem pro Forward Incremental s Periodic Full Backup jsou některé Restore Point uchovány delší dobu, než je určeno. Protože celý Backup Chain může být smazán, až když poslední závislá přírůstková záloha nespadá pod Retention Policy. Prakticky to znamená, že většinu doby máme uchováno více Restore Point. 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í.

Guest Quiescence

Standardně, při zálohování běžícího VM, Veeam Backup & Replication provádí Crash-consistent backup, kdy se čtou data VM disku bez uložení dat v paměti (nezachovává integritu dat otevřených souborů transakčních aplikací). Pokud chceme, aby byl souborový systém a data aplikací v konzistentním stavu, tak můžeme využít Guest Quiescence nebo Application-aware Image Processing.

Provede se uklidnění (Quiesce) nebo zmrazení (Freeze) VM, čímž se uvede souborový systém do konzistentního stavu. Pomáhá to vytvořit transakčně konzistentní zálohy. Ale aby se aplikace, která nepodporuje Microsoft VSS, uvedla do transakčně konzistentního stavu, tak musíme využít skripty před a po zmrazení.

Guest Quiescence využívá služby VMware Tools nebo Hyper-V Integration Services. Umožňuje zálohovat VM, která nepodporují Microsoft VSS, jako Linux VM, kde provede zmrazení. Pro Windows VM mohou VMware Tools využít VMware VSS komponentu.

Pokud jsou v zálohovací úloze Windows i Linux VM, tak se doporučuje zapnout Guest Quiescence i Application-aware Processing. Nejprve se zkusí použít Application-aware Processing, pro VM, kde se nepovede, využije Guest Quiescence. V nastavení Guest Processing pro jednotlivá VM musíme zvolit Try application processing, but ignore failures.

Guest Processing

Možnosti zpracování hosta jsou pokročilé úlohy, které vyžadují, aby Veeam Backup & Replication komunikoval s hostujícím OS běžícího virtuálního počítače (standardně přes síť, případně pomocí VMware VIX API nebo Microsoft PowerShell Direct na Windows VM). Musíme zadat pověření (Credentials) s dostatečnými právy pro přihlášení do OS.

• Application-Aware Processing - umožňuje vytvořit transakčně konzistentní zálohy VM, kde běží Microsoft Active Directory, Microsoft Exchange, Microsoft SharePoint, Microsoft SQL Server nebo Oracle Database
• Pre-freeze and post-thaw scripts - můžeme využít skripty před a po zmrazení pro aplikace, které nepodporují Microsoft VSS
• Transaction log truncation - můžeme nastavit zkrácení transakčního logu po úspěšné záloze, je podporován Exchange DAG (dojde ke zkrácení logů, ať je zálohován kterýkoliv uzel)
• Transaction logs backup for Microsoft SQL Server and Oracle Database - zálohování transakčních logů SQL Serveru nebo archivních logů Oracle DB, vytvoří se rodičovská úloha, která zálohuje VM, a podřízená úloha, která pravidelně zálohuje logy, při selhání serveru se obnoví VM a pomocí Veeam Explorer aplikujeme transakční logy
• VM guest file system indexing - vytvoří katalog souborů, který umožní prohlížení, vyhledávání a obnovu jedním kliknutím z Veeam Backup Enterprise Manager, není potřeba pro Instant File Level Recovery
• VM guest OS files exclusion - můžeme vyloučit/zahrnout určité soubory nebo složky ze zálohy

Application-Aware Processing vytváří transakčně konzistentní zálohy, kdy zpracovává aplikační logy. Využívá Microsoft VSS, které uvede aplikace ve VM do klidového stavu. Takže neexistují žádné nedokončené databázové transakce nebo neúplné soubory, ve chvíli, kdy se provede VM Snapshot / Checkpoint. Ve VM musí být instalované VMware Tools nebo Hyper-V Integration Services.

Při zpracování VM se zjistí informace o instalovaných aplikacích, Microsoft VSS uvede aplikace do klidového stavu, provede se VM VSS snapshot, provede se Snapshot VM pro VMware vSphere nebo Snaphost svazku Hyper-V, Microsoft VSS obnoví I/O aktivity hostujícího OS. Zálohovací úloha pokračuje standardně dále. Případně se provede zkrácení transakčních logů.

Pozn.: Možnosti, které se nabízí v Guest Processing, se lyší podle typu úlohy. Pro VM Hyper-V, VMware a Windows Agent jsou dost podobné. Linux Agent má zásadnější změny. V dalším článku jsou screenshoty jednotlivých variant.

Pokud dojde k nějakým chybám při Guest Processing v rámci VM, tak se můžeme podívat do Guest Helper logu. Ten se nachází na souborovém systému uvnitř VM, pro Windows jde o cestu C:\ProgramData\Veeam\Backup\VeeamGuestHelper_19102022.log.

Guest Processing a přístupy

Dole v kroku Guest Processing se nachází velice užitečné tlačítko Test Now. Pro všechna zálohovaná VM provede ověření připojení do VM různými metodami (tedy, zda je komunikace dostupná a projde přihlášení). Pro Windows VM testuje síťové připojení pomocí RPC, dále na VMware pomocí VIX, na Hyper-V pomocí PowerShell Direct, a zkouší přístup na admin$ sdílení. Pokud jsme zvolili Use Persistent Guest Agent, tak se ověřuje přístup na tuto službu.

Zobrazí se log provedených akcí a jejich stav, v případě selhání také informace chybě. Nemusí být všechny metody úspěšné, aby byla komunikace možná. Pokud máme instalovaného Persistent Guest Agent, tak se primárně využije ten. Jinak se využívá RPC. Pokud není síťově dostupné, tak se zkouší VIX/PowerShell Direct. Pomocí admin sdílení se dočasně instalují Non-Persistent Runtime Components (případně Persistent Agent Components). Pokud využíváme trvalého agenta, tak tento přístup není potřeba.

Agenta můžeme instalovat ručně pomocí Installer Service (VeeamInstallerSvc.msi, které nalezneme na Veeam serveru v C:\Program Files\Veeam\Backup and Replication\Backup\Packages). Více informací v Persistent Agent Components.

Některé přístupy nám nemusí projít, protože jsou blokovány pomocí User Account Control (UAC). Zmínka je v dokumentaci Persistent Agent Components, podrobněji v Local Account with administrative access či Access is Denied. When Using a Local Account to Add a Windows Machine to Veeam Backup & Replication. Mluví se tam o situaci, kdy pro Guest Processing využijeme lokální (ne-doménový) účet, který může být ve skupině Administrators. UAC blokuje takový účet pro vzdálený přístup. Pokud používáme lokální účet, tak se doporučuje využít vestavěný účet Administrator (UAC pro něj funguje jinak).

Já jsem narazil na problém, když Veeam server nebyl v doméně, ale pro Guest Processing se využil doménový účet. Přesto nefungoval přístup přes VIX. Veeam má dva články Troubleshooting Guest Processing Test Now issues a Credentials Test or Job Fails when attempt to use VIX.

Zobrazovala se chyba, která začínala:

Connecting to guest OS via VIX Error: Cannot connect to host [x.x.x.x] over web services. Login: [account-vmware]. Guest Login: [account-windows].
Could not copy host file [C:\Program Files (x86)\Veeam\Backup Transport\GuestInteraction\VSS\VeeamGuestHelpers\VeeamVixProxy.exe] to guest [C:\Windows\TEMP\{409c833b-3225-48d4-9190-13170a21871e}]

Zkusil jsem vypnout UAC na Veeam serveru, pak se chyba lehce změnila:

Connecting to guest OS via VIX Error: Cannot connect to host [x.x.x.x] over web services. Login: [account-vmware]. Guest Login: [account-windows].
Failed to execute Pwdkey
Failed to execute vSphere API command: [Failed to set registry value BiosUUID 
Failed to create SOFTWARE\VeeaM\Veeam Backup and Replication registry key 
Win32 error:Access is denied.
 Code: 5].

Zkusil jsem vypnout UAC i na zálohovaném VM a následně vše prošlo bez chyby (zatím jsem nepátral dále, VIX nepotřebuji).

Vypnutí UAC ve Windows patrně nestačí přes Control Panel, ale musí se provést přes registry. V cestě HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System změnit hodnotu EnableLUA z 1 na 0. Pak je potřeba restart. (Best Practice Guide uvádí, že na stejném místě můžeme vytvořit hodnotu LocalAccountTokenFilterPolicy s 1, ale to mi nefungovalo).

Vynechání dat ze zálohy - Data Exclusion

Veeam Backup & Replication standardně zálohuje obraz celého VM. Máme ale několik možností, jak určitá data ze zálohy vynechat.

Na úrovni VM

• VM disky - běžně se zálohují všechny disky, ale můžeme vybrat pouze určité IDE, SCSI nebo SATA disky, pro VMware můžeme nechat upravit VMX soubor, aby neobsahoval nezálohované disky (a VM šlo nastartovat), funguje to velmi dobře, o jaký disk jde, vidíme v nastavení VM nebo ve Windows v Disk Management, ccstandardně se využívá SCSI a postupně 0:0, 0:1, 0:2
• VM templates - pro VMware můžeme volit, zda se mají zálohovat šablony VM, případně pouze při plné záloze
• VM z VM kontejneru - pokud zálohujeme celý VM kontejner, tak můžeme vybrat určitá VM, která se zálohovat nemají

Na úrovni operačního systému VM

• soubory a složky - v rámci Guest Processing můžeme vynechat určité soubory a složky ze zálohování nebo naopak zálohovat pouze vybrané, určit soubory můžeme pomocí plné cesty, proměnných prostředí nebo masky souborů, funguje pouze pro NTFS, nepodporuje RAID v OS, pokud použijeme masku, tak se prohledává celý disk, což je časově náročné a zatěžuje VM
• Swap file - defaultně je zatrženo Exclude swap file blocks a nekopírují se soubory pagefile.sys a hiberfil.sys z Windows VM s NTFS
• Bloky smazaných souborů - defaultně je zatrženo Exclude deleted file blocks a nekopírují se špinavé datové bloky (označené jako smazané), funguje pouze pro NTFS

Doporučení pro Backup Job

Maximum VM per Job

• Veeam doporučuje použít v úloze více VM (nedělat pro každé VM samostatnou úlohu), ale na druhou stranu nepřekračovat určité množství
• pokud máme záložní soubory per Job, tak do 30 VM v úloze
• pokud máme záložní soubory per VM, tak do 200 VM v úloze

Používat zálohovací soubory per VM

• na mnoha místech se doporučuje ukládat každé zálohované VM v rámci úlohy do samostatného souboru (opakem je jeden soubor pro celou úlohu), ve VBR 12 má jít o výchozí nastavení
• nevýhoda je, že se neprovádí deduplikace mezi VM, takže zabírá o něco více místa
• Backup Infrastructure - Backup Repositories - pravé tlačítko Properties - Repository - Advanced - Use per-machine backup files

Repository s Fast Clone

• doporučuje se využívat Fast Clone, které může ušetřit místo při syntetické plné záloze, detaily Fast Clone
• musí být formátováno pomocí souborového systému ReFS 3.1 nebo XFS
• pro Linux Repository s XFS musíme povolit Fast Clone
• Backup Infrastructure - Backup Repositories - pravé tlačítko Properties - Repository - Use fast cloning on XFS volumes
• pro Microsoft Windows (minimálně Server 2016 nebo Windows 10 Pro) se používá defaultně, pokud jsou splněny podmínky

Pozn.: Jako velký nedostatek mi přijde, že pro ReFS nejsou v systému nástroje, které by ukazovaly různé statistické údaje. Například pro složku, kolik fyzicky data zabírají, kolik jsme ušetřili díky Block Cloning apod. Můžeme pouze zobrazit údaje o celém disku, kolik je obsazeno a volno. Pak velikost všech složek na disku, což bude většinou více, než je obsazeno. Podle toho spočítáme celkovou úsporu místa. Našel jsem jediný nástroj blockstat, který není moc ideální, porovnává uložené bloky zadaných souborů a ukáže kolik se ušetřilo.

Storage Latency Control

• popis Storage Latency Control
• aby se předešlo přetěžování úložiště, kde jsou uložena VM, tak můžeme zapnout řízení zpoždění, monitoruje se aktuální zatížení a při určitých hodnotách se nespouští nové úlohy nebo omezuje rychlost běžících

Storage Maintenance

Pokud používáme zálohovací metodu Forever Forward Incremental nebo Reverse Incremental, tak se doporučuje zapnout Defragment and compact full backup file (dočasně potřebuje více úložného prostoru). Pokud nepoužíváme Active Full Backup, tak je doporučeno pravidelně provádět Perform backup files health check (Storage-level corruption guard).

Storage Optimization

Pro většinu situací se doporučuje mít zapnutou deduplikaci a kompresi. Výchozí nastavení by mělo být optimální v poměru velikosti zálohy a využití prostředků během procesu zálohování (případně obnovy). Pokud ukládáme zálohy na deduplikační appliance, tak může být vhodné nastavit na Repository Decompress backup data blocks before storing. Stále využívat kompresi v nastavení úlohy, protože ušetříme data při přenosu.

Veeam Agent Backup Job

Instalace agenta

Nebudeme se příliš věnovat instalaci Veeam Agenta, kterou můžeme provést různými způsoby (hodně záleží na operačním systému, nejlepší podpora je pro Windows). Nejjednodušší je automatické nasazení z Veeam Serveru.

Buď můžeme vytvořit Protection Group pro nasazení a správu agentů, kdy se agent může instalovat při vytvoření skupiny (a na nově přidané počítače během Rescan - Agent Discovery). Nebo přidat jednotlivé počítače přímo do Backup Job, agent se nainstaluje při prvním spuštění a počítač se zařadí do skupiny (Protection Group) Manually Added. Při konfiguraci musíme použít účet, který má oprávnění instalace na daných počítačích. Na Windows se může instalovat Changed Block Tracking (CBT) driver, který umožní sledovat změny na úrovni bloků (ne jen souborů). Po instalaci vyžaduje restart OS. Součástí Linux instalace je Kernel modul Veeam Agent for Linux Driver (veeamsnap) pro vytváření Snapshotů a CBT.

Režimy práce agenta a úlohy

Agent může být samostatný (Standalone mode, Veeam Agent for Microsoft Windows), instalujeme přímo na počítač. Správu provádí uživatel v agentovi nebo s integrací do Veeam Backup & Replication. Nebo řízený (Managed mode, Veeam Agent Management Guide), instalujeme vzdáleně z Veeam Backup & Replication. Všechny operace (správa) se provádí vzdáleně z konzole.

Úloha může pracovat jako spravovaná zálohovacím serverem (Managed by backup server), označuje se jako Backup Job či Veeam Agent backup job managed by the backup server. Zálohovací úloha běží standardně na serveru (jako pro zálohování VM), což je vhodné pro stále běžící a připojené počítače (servery). Agent je odlehčený a nemá GUI. Agenta nemusíme instalovat z Veeam Backup & Replication, ale můžeme využít jím generované soubory a skupinu Computers with pre-installed agents (Deploying Veeam Agents Using Generated Setup Files).

Nebo spravovaná agentem (Managed by agent), která se označuje Backup Policy či Veeam Agent backup job managed by Veeam Agent. Vytvoří se politika, která se jako šablona aplikuje na agenty a zálohovací úloha je řízena agentem. Je vhodné pro počítače (notebooky), které mají omezené připojení k zálohovacímu serveru. Pokud máme předinstalovaný Standalone Agent, tak musíme využít tento mód.

Veeam Agent for Microsoft Windows podporuje také Backup from Storage Snapshots. Agent musí být řízený a musíme mít integraci s diskovým polem. Veeam Backup & Replication využije Off-host Backup Proxy a Hardware VSS Provider. Vytvoří se nativní snímek (Native Snapshot) na úložišti a z něj se zálohuje. Takže je mnohem méně zatížen zálohovaný počítač.

Kdy použít Veeam Agent

Zásadní otázka je, kdy je nutné nebo výhodné využít pro zálohování Veeam Agenta. U Veeamu se hledá odpověď dost těžko. Jsou situace, kdy je to jasné. Agenta musíme použít v situacích, kdy nelze využít VM zálohování. Tedy například pro zálohování fyzických počítačů, VM ve veřejném cloudu, VM, kde nemůžeme vytvořit Snapshot. V praxi jsem narazil na další situaci, když zálohujeme VM, které využívá Raw Device Mapping (RDM), tedy přistupuje přímo na LUN diskového pole.

Na různých místech dokumentace se uvádí, že agent je potřeba pro zálohování Microsoft Failover Cluster. Podporováno je Windows File Server Failover Clusters, Windows Server Failover Clusters s SQL, SQL Always On Availability Groups a Exchange Database Availability Groups. Dokumentace uvádí i řadu omezení (Failover Cluster Support). Agent musí být spravovaný zálohovacím serverem, zálohovací úloha typu Failover cluster a servery přidány pomocí Protection Group s Active Directory objects a vybraným clusterovým objektem.

Ale někde se uvádí, že je také možno použít základní VM Backup Job pro zpracování virtuálních clusterů bez agenta. V popisu Best Practice pro zálohování Exchange DAG je uvedeno VM zálohování bez agenta.

Agent Backup Job

• Creating Veeam Agent Backup Jobs

Při zálohování pomocí agenta provádí zpracování agent. Podle módu agenta je potřeba, aby agent komunikoval se zálohovacím serverem, a vždy s úložištěm záloh.

Ač zálohování pomocí agenta funguje jiným principem než zálohování VM, tak jsou k dispozici téměř shodné možnosti a nastavení. Zmíníme si pouze pár rozdílů či poznámek.

• Computers - přidáváme Protection Group a/nebo jednotlivé počítače (určené IP adresou nebo jménem, pro ně musíme určit účet - Credentials pro přístup)
• Backup Mode - můžeme zálohovat celý počítač (i včetně USB disků, podporuje CBT a paralelní zpracování), obraz určitých svazků (Volume, podporuje CBT a paralelní zpracování) nebo určité soubory a složky (menší výkon, není k dispozici pro typ Failover cluster)

• Guest Processing - také možnosti zpracování hosta jsou velmi podobné jako u VM, nemusíme ovšem zadat Credentials pro přístup do operačního systému, využijí se oprávnění, pod kterými běží agent, který zpracování provádí

Operace se zálohou

Přejmenování Backup Job

Když vytvoříme Backup Job, tak mu zadáváme unikátní jméno, pod kterým se úloha zobrazuje ve Veeam Backup & Replication Console. Zároveň se na přiřazeném Repository (v jeho definované cestě) vytvoří složka se jménem podle úlohy. Tedy například D:\Backups\Test VM Backup.

Zálohovací úlohu můžeme jednoduše přejmenovat. Zvolíme na ní Edit, změníme jméno a klikneme Finish. Ale změní se pouze jméno úlohy a v History jsou nové Session pod novým jménem. Zálohy jsou stále pod starým jménem a na disku je staré jméno složky.

Pokud chceme změnit vše (abychom měli logický přehled), tak můžeme vyjít z návodu How to Move Veeam Backup & Replication Backup Files. Kde jsou popsány situace při přesunu záložních souborů na nové úložiště buď se zachováním zálohovací úlohy nebo s novou úlohou.

• (není povinné, ale bezpečnější) zakážeme úlohu, Home - Jobs, na přejmenovávané úloze zvolíme Disable
• změníme jméno úlohy, na úloze zvolíme Edit
• v Repository se zálohou změníme jméno složky, která obsahuje záložní soubory (názvy souborů neměníme)
• znovu naskenujeme dané úložiště, Backup Infrastructure - Backup Repositories - na úložišti volba Rescan
• skenování by mělo najít a přidat jednu novou zálohu a jednu odebrat
• když se podíváme do Home - Backups - Disk (Imported), tak zde uvidíme naši zálohu (pod starým jménem), cestu můžeme zkontrolovat, pokud na záloze zvolíme Properties a zde Copy path
• namapujeme zálohu na zálohovací úlohu, Home - Jobs, na úloze zvolíme Edit, na záložce Storage zvolíme Map backup, vybereme zálohu (stále má původní jméno), dokončíme průvodce (Next) a potvrdíme Apply
• v Home - Backups vidíme, že záloha zmizela z Disk (Imported) a objevila se v Disk pod novým názvem
• povolíme úlohu

Přesun souborů zálohy na jiné úložiště

Pozn.: Ve verzi 12 již můžeme přesun provést v jednoduše konzoli, více v článku Veeam Backup & Replication 12 - upgrade formátu Backup Chain a Backup Copy (Move backup - přesun záloh)

• (není povinné, ale bezpečnější) zakážeme úlohu, Home - Jobs, na přejmenovávané úloze zvolíme Disable
• přesuneme záložní soubory (celou složku) na nové Repository
• znovu naskenujeme nové úložiště, Backup Infrastructure - Backup Repositories - na úložišti volba Rescan
• skenování najde jednu novou zálohu, objeví se v Home - Backups - Disk (Imported)
• namapujeme zálohu na zálohovací úlohu, Home - Jobs, na úloze zvolíme Edit, na záložce Storage přepneme Repository a zvolíme Map backup (mapování můžeme přeskočit, protože by mělo proběhnout automaticky), vybereme zálohu, dokončíme průvodce (Next) a potvrdíme Apply
• původní soubory (staré Repository) se objeví v Home - Backups - Disk (Orphaned)
• znovu naskenujeme původní úložiště, Backup Infrastructure - Backup Repositories - na úložišti volba Rescan
• skenování odebere zálohu (zmizí Disk (Orphaned))
• povolíme úlohu

Vytvoření Synthetic Full Backup

• ručně (Ad-hoc) lze vytvořit pouze Active Full Backup
• Synthetic Full Backup můžeme vytvořit pouze aktuálně (nelze vytvořit zpětně k určitému Restore Point)
• jediná možnost je upravit Backup Job, Home - Jobs, na úloze zvolíme Edit
• nastavíme vytvoření Synthetic Full Backup na aktuální den
• spustíme úlohu, Home - Jobs, na úloze zvolíme Start
• vrátíme úpravu zpět

Jiná možnost je provést export zálohy v Home - Backups - Export backup. To umožňuje syntetizovat úplný a nezávislý soubor plné zálohy z vybraných bodů obnovení, které se nachází v úložišti záloh. Vytvoří se tak VBK soubor k určitému datu. Funkce je určena pro archivaci důležitých bodů obnovy, zabrání se jejich smazaní pomocí Retention Policy a učiní je přenosnými.

Při exportu můžeme vybrat více VM či počítačů z různých typů záloh, každý stroj se uloží do nezávislého Full Backup souboru. Exportované soubory se uloží do stejného úložiště, kde jsou body obnovy. Ve Veeamu jsou vidět pod Disk (VeeamZIP) nebo Object Storage (VeeamZIP). Můžeme nastavit, aby byla exportovaná záloha smazána po určité době.

Odebrání starších Restore Points

Removing Missing Restore Points

• smažeme na disku vybrané soubory (VIB má smysl jen s patřičným/předchozím VBK, nesmíme rozbít Backup Chain)
• znovu naskenujeme úložiště, kde je záloha, Backup Infrastructure - Backup Repositories - na úložišti volba Rescan
• necháme zapomenout smazané soubory, Home - Backups - Disk, na záloze zvolíme Properties, chybějící Restore Point se zobrazí s červeným křížkem, na některý klikneme pravým tlačítkem a zvolíme Forget - All unavailable backups