[SOLVED] File Restore Dateien defekt

[cfuchs]

Hallo zusammen,

folgende Ausgangssituation:
PVE 7.1-12, PBS 2.1-5, VM Windows Server 2022 mit aktivierter Deduplikation (Dedup-Rate derzeit 23 %)

Wie schon im Titel erwähnt, sind die Dateien, die per File Restore wiederhergestellt werden, defekt. Die Sicherung läuft ohne Probleme und die Rücksicherung sieht auch unauffällig aus. Die Dateigrößen passen auch soweit.

Mir fehlt jetzt die Idee an was es liegen könnte.


Gruß

Christian

 

[fiona]

Hallo,
um was für eine Art Dateien handelt es sich dabei und in welcher Weise sind sie defekt? Ist der Qemu guest agent für die VM konfiguriert? Tritt die Korruption bei allen Backups dieser VM auf?

 

[ITT]

Du meinst, im Win2022 ist die Windows-Deduplizierung aktiv?
Meines Wissens nach kann das nicht funktionieren.

 

[cfuchs]

Hallo,
um was für eine Art Dateien handelt es sich dabei und in welcher Weise sind sie defekt? Ist der Qemu guest agent für die VM konfiguriert? Tritt die Korruption bei allen Backups dieser VM auf?

Hallo Fabian,

eigentlich alle Dateien. Getestet habe ich das mit PDFs, einer Sketchup-Datei sowie mit einer EXE-Datei. Die Dateigrößen sind wie im Original. Der Qemu-Agent ist nicht extra konfiguriert, sprich: Standard-Installation. Bisher gibt es nur zwei Backups. Aus dem ersten lassen sich noch die Dateien wiederherstellen. Die Deduplizierungsrate liegt hier bei 1 %.

Gruß

Christian

 

[cfuchs]

Du meinst, im Win2022 ist die Windows-Deduplizierung aktiv?
Meines Wissens nach kann das nicht funktionieren.

Ja, aber warum sollte das nicht funktionieren?

Ich denke, dass die Situation nicht so ungewöhnlich ist. Auf einem Windows-Server mit Benutzerprofilen von > 250 User wird dadurch einiges an Platz eingespart.

 

[ITT]

Ja, aber warum sollte das nicht funktionieren?

Ich denke, dass die Situation nicht so ungewöhnlich ist. Auf einem Windows-Server mit Benutzerprofilen von > 250 User wird dadurch einiges an Platz eingespart.

Ich habe da eine andere Sichtweise: Warum sollte das (ausserhalb Windows) funktionieren?
Ich kenne kein Backupprogramm das dies kann ausser die für Hyper-V.
Platz sparen, das macht man doch besser über den Hypervisor (ZFS/BTRFS usw..)
Ich glaube, dein Konzept ist nicht so ganz durchgedacht.
Windows-Deduplication benötigt IMMER Windows-Deduplication! Egal ob zum deduplizieren und eben de-deduplizieren, irgendwie ja logisch..
Proxmox kann mit den deduplizierten Chunks nichts anfangen.

 

[cfuchs]

Ich habe da eine andere Sichtweise: Warum sollte das (ausserhalb Windows) funktionieren?
Ich kenne kein Backupprogramm das dies kann ausser die für Hyper-V.
Platz sparen, das macht man doch besser über den Hypervisor (ZFS/BTRFS usw..)
Ich glaube, dein Konzept ist nicht so ganz durchgedacht.
Windows-Deduplication benötigt IMMER Windows-Deduplication! Egal ob zum deduplizieren und eben de-deduplizieren, irgendwie ja logisch..
Proxmox kann mit den deduplizierten Chunks nichts anfangen.

Vielen Dank für Deine Gedanken. Ich werde dem Hinweis bzgl. ZFS nachgehen - mal sehen wie viel ich durch die Komprimierung einsparen kann. Dedup unter ZFS scheint auszuscheiden, weil die Daten tatsächlich nur einem zpool liegen.

 

[fabian]

wenn du einen normalen restore machst (in eine neue VMID ) - passt der inhalt dann? file-restore verwendet eine spezielle linux VM um die daten zu lesen, eventuell macht der NTFS treiber dort mit der deduplizierung irgendwas "falsch" (metadaten passen, inhalt aber nicht?)

 

[Falk R.]

Zum Thema Windows Dedup und Backup: Mit Veeam kann man sowas restoren, aber nur wenn der Veeam Backupserver die gleiche OS Version oder neuer hat und das Dedup Feature installiert hat. Ohne das Windows Dedup Feature weiß auch windows nicht, dass die Datei nur noch ein Zeiger auf den Dedupstore im Ordner System Volume Information ist. Du stellst also nur den Zeiger wieder her.

 

[ITT]

@SkyDiver79 , völlig richtig.

 

[Falk R.]

Ich habe z.B. eine Ubuntu VM auf der OneDrive for Linux läuft, um Dateien einfach mit PBS wieder herstellen zu können und für meine verbliebenen Windows altlasten nutze ich Veeam Agent mit der Veeam B&R Free Edition (bis 10 Instanzen kostenlos).
Also entweder Linux Filer mit Dedup, Windows ohne Dedup oder anderes Backup.

 

[ITT]

Goldene Regel: Verwende Compression/Dedup etc. ausschliesslich auf Hypervisor-Ebene, niemals in einer VM.

 

[Falk R.]

Goldene Regel: Verwende Compression/Dedup ausschliesslich auf Hypervisor-Ebene, niemals in VM-Ebene.

Da muss ich mal wiedersprechen, wenn du einen Filer als VM hast, funktioniert das Dedup in der VM mit den vielen Dateien deutlich effektiver als auf Hypervisor Ebene. Aber man muss sich bei dem Design natürlich über alle anderen Effekte im klaren sein.

 

[ITT]

Da muss ich mal wiedersprechen, wenn du einen Filer als VM hast, funktioniert das Dedup in der VM mit den vielen Dateien deutlich effektiver als auf Hypervisor Ebene. Aber man muss sich bei dem Design natürlich über alle anderen Effekte im klaren sein.

Schon klar.
Workarounds gibts immer, können aber je nach (fehlenden) Wissen im Notfall gefährlich sein.

ALTERNATIVE: In der betroffenen Windows-VM UrBackup für Filebackup verwenden.
Aber auch da benötigt man eine zusätzliche VM.

Edit: Ich rate generell davon ab (dedup/compression innerhalb einer VM), denn im Falle eines Hardwareschadens (Datenträger) kommst du nie wieder an deine Dateien ran. Ich hatte das bei Kunden schon öfters. Und mit Hardwareschaden meine ich nicht zwingend einen Ausfall sondern Controller-Fehler, Firmwarefehler oder fehlenden ECC-Speicher. Also solche Hardwaredefekte/Fehlfunktionen, die du anfangs nicht erkennst, die sich aber immer weiter schleppen bis nichts mehr geht.

 

[cfuchs]

wenn du einen normalen restore machst (in eine neue VMID ) - passt der inhalt dann? file-restore verwendet eine spezielle linux VM um die daten zu lesen, eventuell macht der NTFS treiber dort mit der deduplizierung irgendwas "falsch" (metadaten passen, inhalt aber nicht?)

Bei einem kompletten Restore passt der Inhalt.

 

[fabian]

dann liegt es vermutlich wie oben von anderen postern bereits erwaehnt an der deduplizierung die vom Linux NTFS treiber nicht unterstuetzt wird. der hersteller der den (neuen) NTFS treiber fuer linux urspruenglich geschrieben hat hat ein extra (kostenpflichtiges) modul fuer dedup support - aber soweit ich sehe keine ambitionen den teil auch open source zu machen..

 

[Falk R.]

Erschwerend kommt hinzu, dass die Dedup Funktion bei Microsoft FS unabhängig ist. Bei ReFS wird die gleiche Dedup Engine genutzt.
ReFS Support für Linux habe ich auch noch nicht gesehen.
Deshalb nutzen alle Backuphersteller mindestens eine Helper VM mit Windows bei Restores falls die Backupsoftware nicht eh auf Windows läuft.
Das ganze ist aber Lizenzrechtlich wieder ein schwieriges Thema.

 

[cfuchs]

dann liegt es vermutlich wie oben von anderen postern bereits erwaehnt an der deduplizierung die vom Linux NTFS treiber nicht unterstuetzt wird. der hersteller der den (neuen) NTFS treiber fuer linux urspruenglich geschrieben hat hat ein extra (kostenpflichtiges) modul fuer dedup support - aber soweit ich sehe keine ambitionen den teil auch open source zu machen..

Du meinst die NTFS-Treiber von Tuxera? Wie sieht es mit älteren Versionen des Plugins aus?

https://jp-andre.pagesperso-orange.fr/advanced-ntfs-3g-old.html#download

Edit: Ich hätte dem Link folgen sollen bevor ich antworte - sorry.

 

[cfuchs]

Andere Frage/Idee: Könnte ich das Backup per

proxmox-backup-client map <snapshot> <archive-name> [OPTIONS]

einbinden und das an eine bestehende Windows VM mit aktiviertem Dedup hängen um einzelne Dateien wiederherzustellen?

 

[fabian]

Du meinst die NTFS-Treiber von Tuxera? Wie sieht es mit älteren Versionen des Plugins aus?

https://jp-andre.pagesperso-orange.fr/advanced-ntfs-3g-old.html#download

Edit: Ich hätte dem Link folgen sollen bevor ich antworte - sorry.

nein, ich meine den in-kernel treiber (ntfs3) der auf dem source code von paragon basiert. ntfs-3g ist userspace und hat angeblich experimentiellen support, aber der ist nicht paketiert und ich kann auch nicht einschaetzen ob das stabil/zuverlaessig laeuft.