PBS 2.4-1: Ein fehlerhaftes Backup macht alle Backups einer VM unbrauchbar.

[Ariston]

Hallo,
Ich sicher unsere VMs per PBS (2.4-1) von einem PVE (7.4-3) auf ein NFS-Share (auf einem Isilon Cluster). Das NFS Share ist per fstab auf dem PBS gemountet.
Die mangelnde Performance (IOPS) von NFS ist zweitrangig in diesem Fall, ist im Testbetrieb.

Solange alle Backups einer VM erfolgreich verifiziert sind, können auch alle Backups wiederhergestellt werden.
Sobald ein Backup nicht erfolgreich verifiziert wurde, kann ich kein einziges Backup der entsprechenden VM mehr wiederherstellen auch nicht Backups die vor dem
fehlgeschlagenen Lauf erzeugt wurden. Die Harddisk wird immer gelöscht.
Die Fehlermeldung bezieht sich immer auf einen fehlenden Chunk z.B. "restore failed: reading file "/nfs/.chunks/705e/705ef03501370cf36ec8a0c2193f3ebb819aeecc40b43b4a7ed911c153ef6c97" failed: No such file or directory (os error 2)"
Der entsprechende Chunk existiert auf dem Share nicht, die Fehlermeldung ist korrekt.
Wenn ich das fehlerhafte Backup lösche hat dies leider keinen Effekt. Ich kann immer noch kein Backup wiederherstellen, gleichgültig, wann das Backup erstellt wurde.

Meine Frage/Problem ist, wieso kann ein fehlerhafter Backup-Lauf alle Backups eine VM unbrauchbar machen. Selbst das erste initiale Backup kann nicht wiederhergestellt werden.

Grüße Ariston

 

[fabian]

sh. https://pbs.proxmox.com/docs/technical-overview.html

PBS speichert backups dedupliziert - chunks die von mehreren snapshots referenziert werden werden trotzdem nur 1x gespeichert. der chunk geht allerdings sicher nicht durch ein fehlgeschlagenes backup verloren, sondern die tatsache dass er fehlt wird vielleicht beim inkrementellen backup oder beim nachtraeglichen verifizieren festgestellt...

 

[Dunuin]

ALLE VMs/LXCs/Hosts des gleichen Datastores teilen sich die gleichen Chunks wegen Deduplizierung. Kein Chunk wird 2 mal gespeichert. Geht dir ein Chunk kaputt, dann gehen auch alle Backup Snapshots nicht mehr, welche dieses Chunk benutzen. Wenn der fehlende Chunk bei allen Backup Snapshots der VM benutzt wurde, dann gehen halt alle nicht mehr.
Hier bietet sich dann z.B. ZFS als Storage an,welcher korrupte Chunks reparieren kann. Oder man synct mehrere PBS, damit man einen korrupten/fehlenden Chunk von einem anderen PBS wiederherstellen kann.

 

[Ariston]

Danke für die Antworten. Das jeder Chunk nur einmal gespeichert wird, war mich bewusst. Was ist halt nicht verstehe ist, das ich kein Backup wiederherstellen kann auch nicht das initiale bei dem alle VMs im Datastore erfolgreich verifiziert wurden.

Ich habe im Attachment beispielhaft den Backupverlauf einer VM dargestellt. Am 6.5. gab es ein Problem mit dem Share, dadurch sind alle Backups an dem Tag fehlgeschlagen (nicht verifiziert). Nach dem Datum kann ich kein Backup wiederherstellen, auch nicht das erste vom 4.5.23.
Das kann meines Erachtens nach nicht an einem fehlenden Chunk liegen, den es am 4.5. noch nicht gab. Wenn ich das Dedublizieren richtig verstanden habe, bauen die Chunks aufeinander auf. Daten aus dem vorherigen Run, die unverändert sind, werden im nächsten Run nicht nocheinmal gespeichert.
Wieso kann ein Fehler am 6.5. das Backup vom 4.5. beinträchtigen? Das ist die Frage, die sich mir im Moment stellt.

Grüße Ariston

 

[fabian]

das backup vom 6.5. ist ja nicht fehlgeschlagen, sondern die verifizierung desselben. vielleicht gibt der (chronologisch) erste fehlgeschlagene verification log mehr auskunft? wie genau hat sich denn "das problem mit dem share" geaeussert?

fuer mich sieht das ganze so aus

- backup OK
- verification OK
- backup OK
- verification OK
- backup OK
- verification FAILED <= hier waere die ursache zu suchen!

wenn der letzte snapshot einen failed verification state hat, und die daten auf der quellenseite (PVE) noch vorhanden sind, sollte das naechste backup den fehlenden chunk uebrigens wieder hochladen.. dann sind auch alle backup snapshots denen ausschliesslich dieser chunk (oder diese chunks) gefehlt haben wieder OK.

 

[Ariston]

Hallo Fabian,

der Fehler im Share war, das ein Node im Cluster ausgefallen ist und der NFS Share umgeschenkt ist auf einen anderen Node.

Das Hochladen des fehlenden Chunks scheint, zumindest im Moment, bei uns nicht zu funktionieren. Ich habe als Test seit letztem Mittwoch
eine ausgeschaltete VM mit nur initial erzeugter HDD gesichert und nachdem dort auch ein Backup nicht verifiziert wurde, konnte ich
die VM nicht mehr zurücksichern, obwohl es danach noch einen Backup-Lauf gab.
Parallel habe ich die gleiche VM noch auf den lokalen Storage des PBS gesichert. Von da aus lässt sich die VM wiederherstellen. Es gab allerdings auch keinen Verificationsfehler.
In den Logdateien habe ich nichts erhellendes gefunden. Welches Loglevel sollte ich einstellen? Leider sind nicht mehr alle Logs vorhanden, weil wir noch
im Testbetrieb vom Proxmox VE & PBS sind.

Der zeitliche Ablauf des Testbetriebs:
- 1te Einrichtung des PVE Cluster
- Einrichten von Test VMs
- Aufsetzen PBS und integrieren in PVE
- Sichern der Test VMs (verschlüsselt)
- Restore von Test VMs (funktionierte)
- PBS löschen und automatisch neu Installieren und wieder in PVE integrieren
- Restore von Test VMs (funktionierte)
- weitere Sicherungen der Test VMs
- PVE löschen und automatisiert neu aufsetzen
- PBS wieder in PVE integrieren,
- Einspielen des gesicherten encryption Keys
- Restore von Test VMs. Funktioniert bei einer VM die keine verification Fehler hatte.
Funktioniert nicht bei VMs die verification Fehler hatten.

Wir wollten in der Testphase ausprobieren, wie der B.M.R. eines PBS aussieht (Backupdaten bleiben erhalten) und wie nach einem Ausfall des PVE die gesicherten VMs von einem PBS wiederhergestellt werden können.

Was passiert, wenn ich aus der Backuphistorie ein Backup lösche, das nicht erfolgreich verifiziert wurde? Werden dann die Informationen von dem vorherigen Backup-Lauf mit denen des nachfolgenden Laufs verbunden?

Grüße Ariston

 

[Dunuin]

Wenn ich das Dedublizieren richtig verstanden habe, bauen die Chunks aufeinander auf. Daten aus dem vorherigen Run, die unverändert sind, werden im nächsten Run nicht nocheinmal gespeichert.

Was passiert, wenn ich aus der Backuphistorie ein Backup lösche, das nicht erfolgreich verifiziert wurde? Werden dann die Informationen von dem vorherigen Backup-Lauf mit denen des nachfolgenden Laufs verbunden?

PBS macht keine differenziellen Backups. Jedes Backup ist ein Vollbackup, teilt sich aber die gleichen Chunks mit jedem anderen Vollbackups, so dass da nichts noch einmal gespeichert wird, was bereits existiert. Daher ist jedes Backup quasi ein inkrementelles Vollbackup.
Da Backup Snapshots nicht aufeinander aufbauen, kann man beliebige aus der Mitte löschen, ohne dass es andere Backup Snapshots beeinflusst.
Die Chunks selbst werden aber erst beim GC wirklich geöscht, nachdem sie von keinerlei Backup Snapshots mehr referenziert werden.

 

[fabian]

bitte folgende infos:
- pveversion -v
- proxmox-backup-manager versions
- verification log vom letzten snapshot der gruppe (kann auch von einer neuerlichen verification sein!)
- dann ein backup machen und den backup task log posten
- den verification log von diesem neuen backup snapshot ebenfalls

 

[Ariston]

Hallo Fabian,
hier die gewünschten Informationen.

$ pveversion -v
proxmox-ve: 7.4-1 (running kernel: 5.15.107-2-pve)
pve-manager: 7.4-3 (running version: 7.4-3/9002ab8a)
pve-kernel-5.15: 7.4-3
pve-kernel-5.15.107-2-pve: 5.15.107-2
ceph: 17.2.5-pve1
ceph-fuse: 17.2.5-pve1
corosync: 3.1.7-pve1
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown: residual config
ifupdown2: 3.1.0-1+pmx3
libjs-extjs: 7.0.0-1
libknet1: 1.24-pve2
libproxmox-acme-perl: 1.4.4
libproxmox-backup-qemu0: 1.3.1-1
libproxmox-rs-perl: 0.2.1
libpve-access-control: 7.4-2
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.4-1
libpve-guest-common-perl: 4.2-4
libpve-http-server-perl: 4.2-3
libpve-rs-perl: 0.7.6
libpve-storage-perl: 7.4-2
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 5.0.2-2
lxcfs: 5.0.3-pve1
novnc-pve: 1.4.0-1
proxmox-backup-client: 2.4.1-1
proxmox-backup-file-restore: 2.4.1-1
proxmox-kernel-helper: 7.4-1
proxmox-mail-forward: 0.1.1-1
proxmox-mini-journalreader: 1.3-1
proxmox-offline-mirror-helper: 0.5.1-1
proxmox-widget-toolkit: 3.6.5
pve-cluster: 7.3-3
pve-container: 4.4-3
pve-docs: 7.4-2
pve-edk2-firmware: 3.20230228-2
pve-firewall: 4.3-2
pve-firmware: 3.6-5
pve-ha-manager: 3.6.1
pve-i18n: 2.12-1
pve-qemu-kvm: 7.2.0-8
pve-xtermjs: 4.16.0-1
qemu-server: 7.4-3
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.8.0~bpo11+3
vncterm: 1.7-1
zfsutils-linux: 2.1.11-pve1

proxmox-backup-manager versions
proxmox-backup-server 2.4.1-1 running version: 2.4.1

-----
letztes Verification-Log


2023-05-22T10:35:08+02:00: Automatically verifying newly added snapshot
2023-05-22T10:35:08+02:00: verify pbackup-nfs:vm/3001/2023-05-22T08:35:05Z
2023-05-22T10:35:08+02:00: check qemu-server.conf.blob
2023-05-22T10:35:08+02:00: check drive-scsi0.img.fidx
2023-05-22T10:35:08+02:00: verified 0.00/8.00 MiB in 0.06 seconds, speed 0.01/142.47 MiB/s (0 errors)
2023-05-22T10:35:08+02:00: check drive-efidisk0.img.fidx
2023-05-22T10:35:08+02:00: verified 0.01/0.52 MiB in 0.00 seconds, speed 3.05/290.18 MiB/s (0 errors)
2023-05-22T10:35:08+02:00: TASK OK

----------
Backup Task

()
{{guestname}}
INFO: starting new backup job: vzdump 3001 --mode snapshot --storage pbackup --remove 0 --node virt1-1 --notes-template '{{guestname}}'
INFO: Starting Backup of VM 3001 (qemu)
INFO: Backup started at 2023-05-22 15:11:05
INFO: status = stopped
INFO: backup mode: stop
INFO: ionice priority: 7
INFO: VM Name: TestToDelete
INFO: include disk 'scsi0' 'pool0:vm-3001-disk-0' 32G
INFO: include disk 'efidisk0' 'pool0:vm-3001-disk-1' 1M
INFO: creating Proxmox Backup Server archive 'vm/3001/2023-05-22T13:11:05Z'
INFO: starting kvm to execute backup task
INFO: enabling encryption
INFO: started backup task 'e1af91d3-bef5-46b1-b53f-a942c85e8038'
INFO: efidisk0: dirty-bitmap status: created new
INFO: scsi0: dirty-bitmap status: created new
INFO: 100% (32.0 GiB of 32.0 GiB) in 3s, read: 10.7 GiB/s, write: 0 B/s
INFO: backup is sparse: 32.00 GiB (99%) total zero data
INFO: backup was done incrementally, reused 32.00 GiB (100%)
INFO: transferred 32.00 GiB in 3 seconds (10.7 GiB/s)
INFO: stopping kvm after backup task
INFO: adding notes to backup
INFO: Finished Backup of VM 3001 (00:00:05)
INFO: Backup finished at 2023-05-22 15:11:10
INFO: Backup job finished successfully
TASK OK

---------------------------------
Verification-Log vom Backup Task

()
2023-05-22T15:11:09+02:00: Automatically verifying newly added snapshot
2023-05-22T15:11:09+02:00: verify pbackup-nfs:vm/3001/2023-05-22T13:11:05Z
2023-05-22T15:11:09+02:00: check qemu-server.conf.blob
2023-05-22T15:11:09+02:00: check drive-scsi0.img.fidx
2023-05-22T15:11:09+02:00: verified 0.00/8.00 MiB in 0.06 seconds, speed 0.01/141.25 MiB/s (0 errors)
2023-05-22T15:11:09+02:00: check drive-efidisk0.img.fidx
2023-05-22T15:11:09+02:00: verified 0.01/0.52 MiB in 0.00 seconds, speed 1.84/174.45 MiB/s (0 errors)
2023-05-22T15:11:09+02:00: TASK OK

 

[fabian]

das backup ist ja okay - die drei logs (verification, dann backup, dann nochmal neue verification) braeuchte es von einem der "betroffenen" backups

 

[Ariston]

Hallo Fabian,

leider kann ich von den VMs kein neues Backup machen. Der Test sollte sein, die VMs nach dem
Neuaufsetzen des PVE Clusters wieder einzuspielen.
Ich kann das letzte Verifications-Log und das Log des Restore-Versuch anbieten.
Von der VM kann ich auch das Log des fehlgeschlagenen Verification-Lauf anbieten.

letztes Verification-Log
Als Anhang : task-pbackup-verificationjob-2023-05-11T22_00_00Z.log

------------
Restore Log

Using encryption key from file descriptor..
Fingerprint: a3:61:b6:42:ee:ac:89:cf
Using encryption key from file descriptor..
Fingerprint: a3:61:b6:42:ee:ac:89:cf
new volume ID is 'pool0:vm-1001-disk-0'
new volume ID is 'pool0:vm-1001-disk-1'
restore proxmox backup image: /usr/bin/pbs-restore --repository pbackup-user@pbs@pbackup_backup-nfs vm/667/2023-05-11T19:01:42Z drive-efidisk0.img.fidx 'rbdool0/vm-1001-disk-0:conf=/etc/pve/ceph.conf:id=admin:keyring=/etc/pve/priv/ceph/pool0.keyring' --verbose --format raw --keyfile /etc/pve/priv/storage/pbackup.enc --skip-zero
connecting to repository 'pbackup-user@pbs@pbackup._backup-nfs'
open block backend for target 'rbdool0/vm-1001-disk-0:conf=/etc/pve/ceph.conf:id=admin:keyring=/etc/pve/priv/ceph/pool0.keyring'
starting to restore snapshot 'vm/667/2023-05-11T19:01:42Z'
download and verify backup index
restore failed: reading file "/nfs/.chunks/589a/589ae73490b4c0eac4b2d482e231edce74aa00f752db780c04f77ab430d796ee" failed: No such file or directory (os error 2)
Removing image: 100% complete...done.
temporary volume 'pool0:vm-1001-disk-0' sucessfuly removed
Removing image: 1% complete...
Removing image: 2% complete...
Removing image: 3% complete...
Removing image: 4% complete...
Removing image: 5% complete...
[...]
Removing image: 91% complete...
Removing image: 92% complete...
Removing image: 93% complete...
Removing image: 94% complete...
Removing image: 95% complete...
Removing image: 96% complete...
Removing image: 97% complete...
Removing image: 98% complete...
Removing image: 99% complete...
Removing image: 100% complete...done.
temporary volume 'pool0:vm-1001-disk-1' sucessfuly removed
error before or during data restore, some or all disks were not completely restored. VM 1001 state is NOT cleaned up.
TASK ERROR: command '/usr/bin/pbs-restore --repository pbackup-user@pbs@pbackup_backup-nfs vm/667/2023-05-11T19:01:42Z drive-efidisk0.img.fidx 'rbdool0/vm-1001-disk-0:conf=/etc/pve/ceph.conf:id=admin:keyring=/etc/pve/priv/ceph/pool0.keyring' --verbose --format raw --keyfile /etc/pve/priv/storage/pbackup.enc --skip-zero' failed: exit code 255

Als Anhang das Log des fehlgeschlagenen Verification-Laufs.

Grüße Ariston

 

[fabian]

okay, dann haben wir wohl aneinander vorbeigeredet.. wenn die original VM nicht mehr existiert, koennen natuerlich auch die chunks nicht durch ein neuerliches backup wieder am PBS auftauchen..

der Fehler im Share war, das ein Node im Cluster ausgefallen ist und der NFS Share umgeschenkt ist auf einen anderen Node.

mir erschliesst sich noch nicht, warum dadurch sowohl chunks verschwunden als auch als korrupt erkannt worden sind.. klingt so, als waere vielleicht in bzw. auf caching was grob falsch eingestellt gewesen?

 

[Ariston]

Hallo Fabian,

das NFS Share ist hard gemountet, caching sollte kein Problem sein. Unter Umständen ein stale NFS Handle,
das ist in der Vergangenheit schon mal vorgekommen.
Das Chunks verschwinden erschliesst sich mir auch nicht. NFS ist zwar nicht das sicherste Protokoll aber
der Isilon Cluster auf dem das Share liegt ist schon ziemlich sicher, was Datenintegrität angeht.

Mein erster Gedanke ging in Richtung eines Bugs. Das ein fehlender/korrupter Chunk im Backup-Lauf 7 das Backup aus Lauf 1 beeinträchtigt,
kann ich mir so nicht vorstellen.
Gibt es die Möglichkeit, die zu einem Backup-Lauf gehörigen Chunks sich auflisten zu lassen? Ggfs. mit dem Zeitpunkt an dem sie
zuletzt geschrieben wurden? Vielleicht ein falscher Pointer in der Liste der Chunks oder etwas in der Art.

Grüße Ariston

 

[fabian]

hard vs. soft hat nichts mit caching zu tun

der ablauf ist folgender (der link den ich weiter oben gepostet hab gibt mehr details):

1. client generiert chunk
2. falls chunk schon im letzten backup enthalten war (und das nicht als "failed to verify" markiert ist!), wird der chunk nicht hochgeladen, sonst schon
3. falls der chunk am server schon existiert, wird der hochgeladene chunk verworfen
4. chunk wird im index eingetragen

das passiert bei jedem backup. ein backup hat also keinen effekt auf aeltere snapshots, es sei denn den aelteren backups fehlen chunks oder diese sind korrupt, dann korrigiert ein spaeteres backup eventuell ein kaputtes aelteres.

beim verify werden chunks die fehlen erkannt, und chunks die korrupt sind (hash mismatch) aus dem weg geschoben (damit ein neuerliches backup diese chunks ggf. wieder hochladen kann!).

ich sehe jetzt zwei moeglichkeiten:
- backup hat chunks hochgeladen, danach ist der NFS server ausgefallen, die chunks waren nur irgendwo im cache (auf PBS oder NFS seite!) und sind verloren gegangen (das faellt dann erst beim naechsten verify auf!)
- verify und NFS ausfall haben sich "gekreuzt", verify hat faelschlicherweise chunks als corrupt markiert

die zweite option scheint mir unwahrscheinlich - im normall geht bei NFS gar nix wenn ein ausfall passiert, und dann waeren ja auch die index files nicht lesbar gewesen bzw. die korrupten chunks nicht verschiebbar.. ausser ihr habt die metadaten und den .chunks ordner auf unterschiedlichen exports oder aehnliches?

fuer die erste option laesst sich das verhalten (neben NFS mount optionen) auch auf PBS ebene tunen - sh. https://pbs.proxmox.com/docs/storage.html#options

 

[Ariston]

Hallo Fabian,

Möglichkeit 2 glaube ich auch nicht. Den PBS haben wir noch nicht optimiert. Er ist als Paket auf einem
Debian-Server, den wir mit FAI und Puppet installieren, installiert.

"chunk-order=none" werde ich mal ausprobieren, die Performance ist im Moment noch nicht so wichtig.

Im Moment ist es noch kein Problem, weil wir in der Testphase sind. Gibt es einen Weg um zu Verhindern, das soetwas noch einmal passiert?
Würde ein zweiter PBS mit einem Sync-Job helfen? Wird vor dem Sync-Job ein Verify durchgeführt um Sicherzustellen, dass die Daten die gesynct werden
fehlerfrei sind?

Grüße Ariston

 

[fabian]

Hallo Fabian,

Möglichkeit 2 glaube ich auch nicht. Den PBS haben wir noch nicht optimiert. Er ist als Paket auf einem
Debian-Server, den wir mit FAI und Puppet installieren, installiert.

"chunk-order=none" werde ich mal ausprobieren, die Performance ist im Moment noch nicht so wichtig.

die andere option waere die relevante um konsistenz sicherzustellen bzw. zu verbessern

Im Moment ist es noch kein Problem, weil wir in der Testphase sind. Gibt es einen Weg um zu Verhindern, das soetwas noch einmal passiert?
Würde ein zweiter PBS mit einem Sync-Job helfen? Wird vor dem Sync-Job ein Verify durchgeführt um Sicherzustellen, dass die Daten die gesynct werden
fehlerfrei sind?

jein. ein sync verifiziert selbst die chunks die neu gesynct werden, bestehende chunks am sync target werden genauso wie beim backup nur durch ein verify ueberprueft, alles andere waere zu teuer. aber zwei (oder mehr) kopien der backups zu haben, hilft natuerlich wenn eine kopie kaputt geht - daher ja auch die klassische 3-2-1 backup strategie

 

[Ariston]

Hallo Fabian,

der Test ist eine anderen Optionen zu verwenden, Inode ist der Default für die Chunks und damit ist das Problem aufgetreten.

Mir ging es mit der Frage nach dem 2ten Server eher darum wie ich sicherstellen kann, das die Quelle (die Backups) sauber ist. Mir ist immer noch nicht klar, wieso durch einen fehlenden Chunk alle Backups einer VM betroffen sind und ob ausgeschlossen ist, das das Problem nicht beim Kopieren der Backups mitwandert.
Ich habe ja mehrere Backup-Läufe die als grün verifiziert sind und trotzdem kann ich keinen davon nutzen um eine VM zu restoren.

Grüße Ariston

 

[mow]

ich sehe jetzt zwei moeglichkeiten:
- backup hat chunks hochgeladen, danach ist der NFS server ausgefallen, die chunks waren nur irgendwo im cache (auf PBS oder NFS seite!) und sind verloren gegangen (das faellt dann erst beim naechsten verify auf!)

Das kommt allerdings mir unwahrscheinlich vor - das würde ja nur chunks betreffen, die erst mit dem neuen Backup erzeugt wurden, aber hier ist ja offenbar ein chunk verlorengegangen, der auch schon im allerersten Backup drin ist.

Ich habe ja mehrere Backup-Läufe die als grün verifiziert sind und trotzdem kann ich keinen davon nutzen um eine VM zu restoren.

Dann versuch mal einen davon zu reverifizieren.

 

[Ariston]

Das kommt allerdings mir unwahrscheinlich vor - das würde ja nur chunks betreffen, die erst mit dem neuen Backup erzeugt wurden, aber hier ist ja offenbar ein chunk verlorengegangen, der auch schon im allerersten Backup drin ist.

Dann versuch mal einen davon zu reverifizieren.

Hallo Mow,

Das geht leider nicht, wie weiter oben geschrieben, haben wir den PVE Cluster neu aufgesetzt und das Puppet Manifest zu testen, dabei sind alle VMs gelöscht worden. Als Test sollten dann die gesicherten VMs aus dem Backup wiederhergestellt werden. Der Verlust der VMs ist nicht so schlimm, weil es Test-VMs waren, nur gibt es deshalb davon auch keine andere Kopie, die ich wiederherstellen kann um diese zu reverifizieren.
Mögliche Probleme sollten in der Testphase gefunden werden und das hat auch geklappt.

 

[mow]

Der Verlust der VMs ist nicht so schlimm, weil es Test-VMs waren, nur gibt es deshalb davon auch keine andere Kopie, die ich wiederherstellen kann um diese zu reverifizieren.

Häh? Du solltest doch im PBS im Datastore unter Actions durch Klick auf "V." die einzelnen Backups nachverifizieren können, ohne dazu den pve zu brauchen, wo die herkommen?