Pozn.: Popis v článku vychází z Veeam Backup & Replication 12.3.1, licencováno pomocí Veeam Universal License (VUL), tedy obdoba Enterprise Plus. A Veeam Hardened Repository ISO 2.0.0.8 for v12.
Mazání neměnných souborů
Pokus o smazání zálohy
Když zkusíme smazat zálohu ve Veeam Backup & Replication, tak ke smazání nedojde a dostaneme informaci, že do určitého data je nastavena Immutability.
Pokus o smazání souborů
Pokud zkusíme přímo smazat soubory na serveru, třeba zde pomocí WinSCP, tak se smaže pouze soubor VBM. U všech ostatních dostaneme chybu, že smazání není povoleno.
Práce se soubory na serveru
Pokud povolíme SSH, tak můžeme využít účet veeamsvc a připojit se na konzoli nebo přes SSH na server. Tím se dostaneme do příkazové řádky, kde běží Bash shell. Máme oprávnění použít pouze omezenou skupinu Linuxových příkazů. Několik příkladů je níže.
Přesun do adresáře se zálohami
cd /mnt/veeam-repository01/backups/VMware-test/
Výpis seznamu souborů
ls -l -a
Výpis atributů souborů (ukazuje Immutability attribute i)
lsattr -a
Výpis souborů se všemi nastavenými rozšířenými atributy (Extended attributes)
getfattr * -d
Zobrazení stromu procesů
pstree -u
Výpis běžících procesů
ps -ef
Příklad výstupu některých příkazů
[veeamsvc@backupstorage ~]$ cd /mnt/veeam-repository01/backups/VMware-test/ [veeamsvc@backupstorage VMware-test]$ ls -l -a total 17131352 drwxr-xr-x. 2 veeamsvc veeamsvc 4096 Sep 20 07:01 . drwx------. 3 veeamsvc veeamsvc 25 Sep 12 19:18 .. -rw-r--r--. 1 veeamsvc veeamsvc 70555 Sep 20 07:01 sab_alma10_05834.vbm -rw-r--r--. 1 veeamsvc veeamsvc 5536157696 Sep 12 19:26 sab_alma10.vm-119368D2025-09-12T191840_DB65.vbk -rw-r--r--. 1 veeamsvc veeamsvc 5536133120 Sep 13 09:06 sab_alma10.vm-119368D2025-09-13T090649_AB4C.vbk -rw-r--r--. 1 veeamsvc veeamsvc 1671168 Sep 14 15:04 sab_alma10.vm-119368D2025-09-14T150348_9E27.vib -rw-r--r--. 1 veeamsvc veeamsvc 1671168 Sep 15 07:01 sab_alma10.vm-119368D2025-09-15T070002_010E.vib -rw-r--r--. 1 veeamsvc veeamsvc 1671168 Sep 16 07:01 sab_alma10.vm-119368D2025-09-16T070017_E043.vib -rw-r--r--. 1 veeamsvc veeamsvc 776364032 Sep 17 07:01 sab_alma10.vm-119368D2025-09-17T070008_B45F.vib -rw-r--r--. 1 veeamsvc veeamsvc 68829184 Sep 18 07:01 sab_alma10.vm-119368D2025-09-18T070011_E9D9.vib -rw-r--r--. 1 veeamsvc veeamsvc 1671168 Sep 19 07:01 sab_alma10.vm-119368D2025-09-19T070018_55B2.vib -rw-r--r--. 1 veeamsvc veeamsvc 5615243264 Sep 20 07:01 sab_alma10.vm-119368D2025-09-20T070127_0034.vbk -rw-r--r--. 1 root root 1272 Sep 20 07:01 .veeam.20.lock [veeamsvc@backupstorage VMware-test]$ lsattr -a ---------------------- ./. ---------------------- ./.. ---------------------- ./sab_alma10.vm-119368D2025-09-12T191840_DB65.vbk ----i----------------- ./sab_alma10.vm-119368D2025-09-19T070018_55B2.vib ----i----------------- ./.veeam.20.lock ----i----------------- ./sab_alma10.vm-119368D2025-09-13T090649_AB4C.vbk ----i----------------- ./sab_alma10.vm-119368D2025-09-14T150348_9E27.vib ----i----------------- ./sab_alma10.vm-119368D2025-09-15T070002_010E.vib ----i----------------- ./sab_alma10.vm-119368D2025-09-16T070017_E043.vib ----i----------------- ./sab_alma10.vm-119368D2025-09-17T070008_B45F.vib ----i----------------- ./sab_alma10.vm-119368D2025-09-18T070011_E9D9.vib ----i----------------- ./sab_alma10.vm-119368D2025-09-20T070127_0034.vbk ---------------------- ./sab_alma10_05834.vbm [veeamsvc@backupstorage VMware-test]$ getfattr * -d # file: sab_alma10.vm-119368D2025-09-12T191840_DB65.vbk user.immutable.until="2025-09-19 17:27:04" # file: sab_alma10.vm-119368D2025-09-13T090649_AB4C.vbk user.immutable.until="2025-09-20 07:07:01" # file: sab_alma10.vm-119368D2025-09-14T150348_9E27.vib user.immutable.until="2025-09-21 13:04:58" # file: sab_alma10.vm-119368D2025-09-15T070002_010E.vib user.immutable.until="2025-09-22 05:01:16" # file: sab_alma10.vm-119368D2025-09-16T070017_E043.vib user.immutable.until="2025-09-23 05:01:32" # file: sab_alma10.vm-119368D2025-09-17T070008_B45F.vib user.immutable.until="2025-09-24 05:01:23" # file: sab_alma10.vm-119368D2025-09-18T070011_E9D9.vib user.immutable.until="2025-09-25 05:01:24" # file: sab_alma10.vm-119368D2025-09-19T070018_55B2.vib user.immutable.until="2025-09-26 05:01:36" # file: sab_alma10.vm-119368D2025-09-20T070127_0034.vbk user.immutable.until="2025-09-27 05:01:40"
Příklad nepovolených operací
[veeamsvc@backupstorage VMware-test]$ chattr -i * chattr: Operation not permitted while setting flags on sab_alma10.vm-119368D2025-09-13T090649_AB4C.vbk chattr: Operation not permitted while setting flags on sab_alma10.vm-119368D2025-09-14T150348_9E27.vib chattr: Operation not permitted while setting flags on sab_alma10.vm-119368D2025-09-15T070002_010E.vib chattr: Operation not permitted while setting flags on sab_alma10.vm-119368D2025-09-16T070017_E043.vib chattr: Operation not permitted while setting flags on sab_alma10.vm-119368D2025-09-17T070008_B45F.vib chattr: Operation not permitted while setting flags on sab_alma10.vm-119368D2025-09-18T070011_E9D9.vib chattr: Operation not permitted while setting flags on sab_alma10.vm-119368D2025-09-19T070018_55B2.vib chattr: Operation not permitted while setting flags on sab_alma10.vm-119368D2025-09-20T070127_0034.vbk [veeamsvc@backupstorage VMware-test]$ rm *.vbk rm: cannot remove 'sab_alma10.vm-119368D2025-09-13T090649_AB4C.vbk': Operation not permitted rm: cannot remove 'sab_alma10.vm-119368D2025-09-20T070127_0034.vbk': Operation not permitted
Testování výkonu úložiště a sítě
K řešení problémů a testování výkonu můžeme použít Live System. Náš VHR server nabootujeme z VHR ISO a zvolíme Live System.
Pouze stručné kroky pro přípravu
- přihlásíme se výchozím jménem
vhradmina heslemvhradmin - musíme změnit heslo (nejsou požadavky na složitost nebo délku)
- použijeme nástroj
nmtui, kde vytvoříme nové síťové rozhraní (připojení) typu Bond a nastavíme IP adresu - nastartujeme SSH Daemon
sudo systemctl start sshd - připojíme se pomocí SSH a účtu
vhradmin - připojíme datový svazek k
/mnt/veeam-repository01pomocísudo ./mount_datavol.sh
Pozn.: S níže uvedenými nástroji nemám zkušenost, takže jsem využil jen příklady z internetu. Výsledky rychlosti sítě bych očekával jiné, ale může to být ovlivněno řadou věcí.
Testování výkonu datových svazků
Pro testování rychlosti zápisu a čtení na úložišti můžeme využít nástroj fio. Příklady použití nalezneme ve Veeam článku nebo na řadě místech na internetu.
Test, který simuluje sekvenční I/O (zápis) generované při vytváření plné zálohy nebo přírůstku (Forward Incremental).
[vhradmin@localhost /]$ sudo fio --name=full-write-test --filename=/mnt/veeam-repository01/backups/testfile.dat --size=25G --bs=512k --rw=write --ioengine=libaio --direct=1 --time_based --runtime=60s
[sudo] password for vhradmin:
full-write-test: (g=0): rw=write, bs=(R) 512KiB-512KiB, (W) 512KiB-512KiB, (T) 512KiB-512KiB, ioengine=libaio, iodepth=1
fio-3.27
Starting 1 process
full-write-test: Laying out IO file (1 file / 25600MiB)
Jobs: 1 (f=1): [W(1)][100.0%][w=3035MiB/s][w=6070 IOPS][eta 00m:00s]
full-write-test: (groupid=0, jobs=1): err= 0: pid=2760: Mon Sep 22 11:15:08 2025
write: IOPS=6172, BW=3086MiB/s (3236MB/s)(181GiB/60001msec); 0 zone resets
slat (usec): min=10, max=182, avg=23.25, stdev= 8.44
clat (usec): min=60, max=3288, avg=137.33, stdev=50.34
lat (usec): min=76, max=3306, avg=160.75, stdev=51.90
clat percentiles (usec):
| 1.00th=[ 68], 5.00th=[ 72], 10.00th=[ 78], 20.00th=[ 93],
| 30.00th=[ 110], 40.00th=[ 121], 50.00th=[ 135], 60.00th=[ 141],
| 70.00th=[ 157], 80.00th=[ 178], 90.00th=[ 198], 95.00th=[ 227],
| 99.00th=[ 273], 99.50th=[ 293], 99.90th=[ 326], 99.95th=[ 343],
| 99.99th=[ 570]
bw ( MiB/s): min= 2800, max= 3304, per=100.00%, avg=3087.78, stdev=140.05, samples=119
iops : min= 5600, max= 6608, avg=6175.56, stdev=280.11, samples=119
lat (usec) : 100=23.73%, 250=73.74%, 500=2.52%, 750=0.01%, 1000=0.01%
lat (msec) : 2=0.01%, 4=0.01%
cpu : usr=8.88%, sys=7.68%, ctx=370342, majf=0, minf=12
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,370331,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=3086MiB/s (3236MB/s), 3086MiB/s-3086MiB/s (3236MB/s-3236MB/s), io=181GiB (194GB), run=60001-60001msec
Disk stats (read/write):
dm-8: ios=0/369740, merge=0/0, ticks=0/49164, in_queue=49164, util=99.87%, aggrios=0/370362, aggrmerge=0/0, aggrticks=0/49798, aggrin_queue=49798, aggrutil=99.83%
sda: ios=0/370362, merge=0/0, ticks=0/49798, in_queue=49798, util=99.83%
Část výstupu testu sekvenčního čtení.
[vhradmin@localhost /]$ sudo fio --name=seq-read-test --filename=/dev/sda1 --size=16Gb --rw=read --bs=1M --direct=1 --numjobs=8 --ioengine=libaio --iodepth=8 --group_reporting --runtime=60 ... Run status group 0 (all jobs): READ: bw=13.8GiB/s (14.8GB/s), 13.8GiB/s-13.8GiB/s (14.8GB/s-14.8GB/s), io=128GiB (137GB), run=9271-9271msec Disk stats (read/write): sda: ios=257290/0, merge=0/0, ticks=677834/0, in_queue=677835, util=98.94%
Testování výkonu sítě
Pro testování rychlosti sítě můžeme využít nástroj iperf3.
Na jednom serveru spustíme iPerf v roli server. Já jsem použil VBR Server (je potřeba na FW povolit komunikaci na použitý port, default 5201), i když na Windows není iPerf moc doporučený. Oba fyzické servery jsou připojeny do sítě o rychlosti 25 Gbps.
d:\iperf>iperf3.exe -s
Na druhém použijeme iPerf v roli klienta. Můžeme využít řadu různých přepínačů.
[vhradmin@localhost /]$ iperf3 -c 10.0.0.89 -n 1G Connecting to host 10.0.0.89, port 5201 [ 5] local 10.0.0.110 port 55558 connected to 10.0.0.89 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-0.82 sec 1.00 GBytes 10.5 Gbits/sec 107 1.27 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-0.82 sec 1.00 GBytes 10.5 Gbits/sec 107 sender [ 5] 0.00-0.82 sec 1016 MBytes 10.4 Gbits/sec receiver iperf Done.
Při některých testech byly výsledky lepší.
[ 5] 0.00-1.00 sec 1.26 GBytes 10.8 Gbits/sec 189 1022 KBytes [ 5] 7.00-8.00 sec 2.19 GBytes 18.8 Gbits/sec 0 2.04 MBytes [ 5] 8.00-9.00 sec 2.31 GBytes 19.9 Gbits/sec 45 1.99 MBytes [ 5] 9.00-10.00 sec 2.08 GBytes 17.9 Gbits/sec 118 1.68 MBytes [ 5] 10.00-11.00 sec 2.28 GBytes 19.6 Gbits/sec 308 1.70 MBytes [ 5] 47.00-48.00 sec 2.14 GBytes 18.4 Gbits/sec 7 1.96 MBytes [ 5] 48.00-49.00 sec 2.44 GBytes 21.0 Gbits/sec 180 1.92 MBytes [ 5] 49.00-50.00 sec 1.82 GBytes 15.6 Gbits/sec 21 1.11 MBytes
Statistiky z praxe
Reálný výkon úložiště vidíme při praktickém používání. Když na úložiště přesouváme zálohy nebo probíhá vlastní zálohování. V mém případě je VHR i VBR server připojen do sítě rychlostí 25 Gbps, ale větší část infrastruktury využívá rychlost 10 Gbps.
Při přesunu záloh na VHR server se paralelně přesouvá několik objektů (workloads) a postupně jejich jednotlivé zálohy (Restore Points). Dosahoval jsem proměnlivých výsledků. Veeam průměrně ukazoval 500 MB/s až 900 MB/s, síť byla zatížená do 8 Gbps. Výkon určitě omezovalo staré úložiště odkud se zálohy přesouvaly.
Při porovnání statistik zálohovací úlohy (zde šlo o Hyper-V) na původním úložišti a po přesunu na Hardened Repository můžeme vidět zvýšení rychlosti. Je však třeba mít na paměti, že přírůstková záloha je ovlivněna řadou faktorů. Zajímavé může být podívat se na využití komponent, kde došlo k výrazným změnám.
Jako transportní režim pro zálohování VMware vSphere používám Direct Storage Access, tedy Backup from Storage Snapshot. Na novém úložišti jsem provedl krátké testy všech tří režimů. Prováděl jsem Full Backup testovacího VM (velikost jen 12 GB, záloha 5 GB). Nejde o jasně vypovídající výsledky, spíše orientační (když jsem test pustil druhý den, tak jsem dosáhl vyšších rychlostí, ale ve stejném poměru).
- Direct Storage Access
[san]- Processing rate 493 MB/s, Duration 2:24, Load: Source 99 %, Proxy 26 %, Network 8 %, Target 0 % - Virtual Appliance (Hot Add)
[hotadd]- Processing rate 339 MB/s, Duration 2:10, Load: Source 67 %, Proxy 93 %, Network 17 %, Target 0 % - Network
[nbd/nbdssl]- Processing rate 349 MB/s, Duration 1:44, Load: Source 99 %, Proxy 19 %, Network 4 %, Target 0 %
Závěrečné shrnutí
Jako velkou výhodu Veeam Hardened Repository vidím, že vše funguje přirozeně, tak jak bych očekával a jsem zvyklý. Zálohy se ukládají jako soubory, s kterými můžeme, v případě potřeby, běžně pracovat. Neměnnost se chová stejně jako retence (a podle nastavení může být stejná). Jednoduše můžeme přesunout zálohy ze současného úložiště na VHR a vše funguje plynu dál.
Celé VHR a zálohy na něm můžeme spravovat přímo z Veeam Backup & Replication. Potřebujeme vyřešit pouze dohled zdraví serveru a disků a aktualizace firmware serveru.
Topologie zálohovací infrastruktury
Pokud jsme využívali jednoduché nasazení (Simple Deployment) vše v jednom, tak jsme měli jeden Veeam Backup Server, kde se nacházela také Veeam Backup Proxy (pro VMware) a většinou lokální Veeam Backup Repository (třeba disky připojené přes iSCSI z diskového pole).
Nyní máme Backup Repository jako samostatný server připojený v LAN, takže zálohy se na něj musí přenášet vždy po síti. Podle typu zdroje zálohování se použije určitá síťová cesta a infrastrukturní komponenty. Třeba Microsoft Hyper-V může využít On-Host Proxy, pak dojde k redukci dat přímo na serveru a zálohy se posílají na VHR. Podobné je to v případě Veeam Agent.
Ale pro VMware vSphere potřebujeme někde instalovanou Proxy, nyní ji máme na VBR serveru. Můžeme zvážit, zda cesta ESXi - VBR - VHR je optimální řešení nebo je lepší umístit Proxy jinam. V řadě případů může být efektivnější využít Backup from Storage Snapshot (Direct SAN).
Ve starším článku jsem popisoval související věci Veeam Backup & Replication - přenos dat a rychlost záloh či obnovy.
Nastavení bezpečnosti
Na závěr je důležité zkontrolovat, že jsme provedli co nejlepší zabezpečení a nic nevynechali. Základ je zabezpečit VHR server. V druhé části série jsme zmínili různá doporučená bezpečnostní nastavení HPE serveru a iLO. Některá jsme nemohli hned provést, aby nám prošla implementace. Nyní je čas vše dokončit.
Zatím zde nejsou žádné komentáře.