VM-Backups auf ZFS Storage

Ich muss keine alten Daten wiederherstellen können die versehentlich gelöscht wurden und älter als 1 Woche alt sind.
Bist du sicher? Schonmal an Malware gedacht? Sagen wir du hast einen Windows PC und auf dem ist die Nextcloud App installiert damit du deine Dateien zwischen Windows und Nextcloud syncen kannst. Dann öffnest du einen eMail-Anhang und fängst dir Ransomware ein. Die Ransomware zeigt sich nicht, verschlüsselt aber heimlich alle deine Daten auf dem Rechner (und alle Daten in der Nextcloud auf die dein Windows-Rechner Zugriff hat) ohne das es dir auffällt, weil du weiterhin auf alle Daten zugreifen kannst, da diese unlocked vorliegen. Dann wartet die Ransomware 3 Monate, entfernt den Schlüssel vom System und erpresst dich damit, dass du 1000€ zahlen sollst, wenn du wieder an deine Daten kommen willst. Wenn du da keine Backups hast die älter als die 3 Monate sind dann bist du echt aufgeschmissen, weil alle deine Backups auch nur die verschlüsselten und nun unnutzbaren Daten enthalten, und dir bleibt nichts anderes über als die 1000€ zu zahlen, damit dir der Erpresser den Key zukommen lässt um alles rückgängig zu machen. Genau sowas kommt ständig vor und trifft auch Privatpersonen. Abhilfe schaffen da nur Backups mit einer echt langen Retention die an einem Ort liegen, auf die kein Rechner, der irgendwie infiziert werden könnte, zugriff hat.

Ähnliches Problem mit schleichendem Dateiverfall oder defektem RAM. Wenn dein Server ECC RAM und ZFS benutzt dann sind Daten, die sich bereits auf dem Server befinden, zwar vor schleichendem Dateiverfall geschützt. Das gilt aber nicht für deinen Windows Rechner der vielleicht keinen ECC RAM besitzt und defivitiv kein ZFS, der da Dateien auf der Nextcloud editiert oder schreibt. Da kann dir immer noch der Windows Rechner durch z.B. einen RAM Fehler eine Datei korrumpieren und die dann auf die Cloud syncen. Sagen wir du hast eine wichtige Datei die du nur alle paar Wochen mal editierst. Da öffnest du nun die bestehende Datei, editierst diese, speicherst sie und die Änderung wird auf die Nextcloud gesynct. Dein Win-Rechner hatte aber einen Fehler und die Datei ist nun korrumpiert gespeichert worden. Wenn du die Datei vielleicht erst in 2 Monaten wieder brauchst, dann stellst du auch erst in 2 Monaten fest, dass sich die Datei nicht mehr öffnen lässt. Hast du dann kein Backup was älter als 2 Monate ist, dann ist die Datei auch unwiederruflich kaputt. Ein Scrub von ZFS auf dem Server bringt dir auch nichts und ZFS wird dir sagen alle wäre ok, obwohl die Datei korrumpiert ist, da ZFS beim Scrub nur prüft ob die Datei noch die gleiche ist wie zu dem Zeitpunkt, als sie auf den Pool geschrieben wurde. Wenn die Datei aber schon kaputt war, als sie auf dem Server angekommen ist, weil sie außerhalb vom Win Rechner kaputtgemacht wurde, dann kann da ZFS auch nichts erkennen oder reparieren.

Und gerade Nextcloud ist ja super anfällig. Hast du 10 Rechner mit Nextcloud verbunden, dann hast du eine 10-fache Chance, dass da wer dir irgendwie die Daten kaputt macht. Und macht auch nur ein Rechner seine Kopie der Datei kaputt, dann wird die kaputte Datei an alle anderen 9 Rechner synchronisiert und überschreibt alle 10 heilen Versionen der Datei. Dann hast du nur noch 11 kaputte Versionen der Datei. Gerade bei solchen Cloud-Sync-Lösungen muss man da echt aufpassen. Erstmal klingt es recht sicher wenn eine Datei auf möglichst viele Rechner synchronosiert wird, da sie dann ja sehr oft an verschiedenen Orten vorhanden ist. Das hilft aber höchstens gegen plötzlich ausfallende Disks und bei allen anderen Fällen macht es so eine Synchronisation über viele Geräte nur schlimmer. Da wiegt man sich dann schnell in falscher Sicherheit.

Bei mir im Windows PC hatte sich z.B. mal langsam aber unauffällig der RAM verabschiedet. War kein ECC RAM also sind die RAM-Fehler auch erst nicht aufgefallen. Über viele Wochen hat da mein Win PC unbemerkt alles mögliche an Daten kaputt gemacht die irgendwie von ihm editiert oder geschrieben wurden. Erst nach vielen Wochen ist mir das Problem dann aufgefallen, weil dann die Bluescreens angefangen haben. Am Ende konnte ich von der gleichen Datei 4 mal einen sha512 Hash berechnen lassen und habe 4 verschiedene Hashes bekommen.
Ich dachte eigentlich meine Daten auf dem NAS (ZFS, ECC RAM, alles Enterprise Hardware) wären sicher, aber die Daten sind immer nur so sicher wie das schwächste Glied was auf diese zugreift. Ich bin danach alle Daten durchgegangen die mein Win Rechner über 2 Monate auf dem NAS geöffnet hat und massig davon war kaputt ohne das es mir aufgefallen ist. Videos die sich nur zur Hälfte abspielen lassen, Bilder bei denen die untere Hälfte fehlt und all so etwas. Hätte ich da keine Backups gehabt wäre das auch echt übel geendet. Und das ganze ist mir mehrfach passiert, weil nach und nach 3 der 4 RAM-Riegel vom selben Rechner gestorben sind. Seitdem kommt bei mir nur noch ECC RAM in alle Rechner, selbst wenn es Gaming-Rechner sind. Und alles wird für mindestens 2 Monate gesichert. Wichtiges für Jahre.

Und ich habe auch schon einmal 10 Jahre an Familienfotos komplett verloren, weil die HDD kaputt ging und bis ich dann eine neue HDD gekauft hatte war auch meine USB-HDD mit den Backups verstorben. Seitdem habe ich immer mindesten 3 Kopien von Allem auf verschiedenen Geräten.
Also Wichtigkeit von multiplen Langzeit-Backups sollte man nicht unterschätzen.

Edit:
Sorry für die langen Kettensätze. ECC und RGB schließen sich übrigens nicht aus:
839-768-max.jpg
Ob RGB den trägen ECC RAM aber schneller bekommt ist eine andere Sache ;). Aber jedenfalls wirkt er jetzt optisch wie niedriglatenter übertakteter RAM. :D
 
Last edited:
Schönen guten Morgen. Na da hast Du natürlich recht in allen Punkten. Vielen Dank für Deine ausführlichen Erklärungen.

Obwohl bei uns die 3 Hauptuser kein Windows sondern Mac benutzen. Die restlichen sowohl Mac als auch Windows. Diese Teiluser greifen aber nur auf wenige gemeinsame Dateien zu. Das tut den erwähnten Risiken aber keinen Abbruch. Ich muss die Langzeitstrategie tatsächlich nochmals überprüfen. Das ist jedoch erst mal eine Frage des Platzes. Ich muss mal schauen wie sich die Daten anhäufen. Habe letzte Nacht ein Snapshot von den 1.34 TB gemacht. Dazu hat er 6h gebraucht. Ein zweiter Snapshot heute Morgen, nach 6 Sek war er fertig ;-)

Nun zeigt er aber auf dem PBS zweimal 3.4 TB an:
1645943521440.png
Tatsächlich ist der Datastore aber nur mit 1.2 TB belegt:
1645943692402.png

Wenn sich das tatsächlich so verhält mit dem Platz wie beim 2. Screenshot, dann hat es Platz für viele Snapshots und ich kann die Langzeitaufbewahrung in Betracht ziehen.

Hast Du folgende Retention? Sowohl bei den Stop-Mode als auch bei den Snapshots? (auf 2 separaten Datastores, auf demselbem PBS)
Damit kannst Du dann theoretisch 5 Jahre zurück?
Man könnte genau so gut 14 tägliche + 8 wöchentliche + 12 monatliche + 5 Jährliche Backups behalten. Dann hast du auch nur knappe 40 Backups, kannst aber viel weiter zurück. Und je weiter die Backups in der Vergangenheit liegen, desto unwichtiger werden ja auch die Abstände zwischen den Backups.
 
Hast Du folgende Retention? Sowohl bei den Stop-Mode als auch bei den Snapshots? (auf 2 separaten Datastores, auf demselbem PBS)
Damit kannst Du dann theoretisch 5 Jahre zurück?
Ich habe da einmal meinen täglichen Backup Job der Snapshot-Backups auf den täglichen Datastore schreibt und einmal täglich von Mo-Sa läuft. Der tägliche Datastore hat tägliches Prune, tägliches GC, kein Verify, und hat bei der Retention "Keep-last: 3, Keep-daily: 7". Ich sollte da also immer 10 tägliche Backups haben (womit ich 12 Tage in täglichen Schritten zurück könnte).

Dann habe ich noch meine wöchentlichen Stop-Mode Backups die immer am Sonntag gemacht werden und auf ihr eigenes wöchentliches Datastore kommen. Hier habe ich dann wöchentliches Prune, wöchentliches GC, wöchentliches Verify und die Retention "Keep-last: 3, Keep-weekly: 4, Keep monthly: 12, Keep-yearly: 3". Hier kann ich also die letzten 1-7 Wochen oder 1-12 Monate oder 1-3 Jahre zurück.

Und dann mache ich gelegendlich noch manuelle Stop-Mode Backups auf das wöchentliche Datastore. Z.B. immer vor nach nachdem ich etwas am Server ändere oder aktualisiere, damit ich bei einem Fehler oder Problem alles gut zurückrollen kann. Diese behalten ich auch meistens für etliche Monate, weil sich Probleme oft erst spät zeigen. Diese manuellen Backups bekommen dann von mir das Protection-Attribut gesetzt und einen ausführlichen Kommentar. Dadurch sind diese Backups dann von der Retention ausgeschlossen und werden niemals automatisch gelöscht.

Und dann nutze ich noch den proxmox-backup-client um wöchentliche Backups von dem Proxmox Server ("/root", "/etc", "/var", "/home") selbst anzulegen. Vor einem größeren PVE Update mache ich außerdem noch über den proxmox-backup-client manuelle Blocklevel-Backups von den kompletten PVE System Disks. Die bekommen dann auch das Protection-Attribut und landen auf dem wöchentlichen Datastore.
 
Hei Danke für die Aufstellung. Erscheint mir logisch. Habe das auch mal so gemacht:
1645995753227.png

Was ich nicht kapiere, die Retention habe ich ja bereits wie oben ersichtlich im Backup-Job auf PVE eingestellt. Ich kann das jedoch auch noch auf dem Datastore selber tun:
1645996389725.png
Wo macht man das standardmässig und wenn direkt auf datastore Ebene, was soll ich denn dann im Backup-Job in PVE einstellen?
1645996493558.png
Was macht eigentlich GC und Prune? Ich habe vorher GC laufen lassen, weiss aber gerade nicht ob das gut war...
 
Was ich nicht kapiere, die Retention habe ich ja bereits wie oben ersichtlich im Backup-Job auf PVE eingestellt. Ich kann das jedoch auch noch auf dem Datastore selber tun:
View attachment 34697
Wo macht man das standardmässig und wenn direkt auf datastore Ebene, was soll ich denn dann im Backup-Job in PVE einstellen?
View attachment 34698
Die Retention kann man sowohl über den PVE Job als auch über den Datastore des PBS einstellen. Bei mir habe ich die in PVE weggelassen und nutze stattdessen die Retention des Datastores. Retention bei beiden macht keinen Sinn, weil dann einfach beides doppelt gemacht wird.

Was macht eigentlich GC und Prune? Ich habe vorher GC laufen lassen, weiss aber gerade nicht ob das gut war...
Prune sorgt dafür dass die Backups als zu löschend markiert werden, welche nicht mehr der Retention entsprechen. Also hast du als Retention z.B. last=10 und es gibt 13 Backups, dann wird ein Prune Job die ältesten 3 Backups markieren, damit die vom nächsten GC gelöscht werden.

Die GC selbst löscht dann als zu löschend markierte Backups. GC löscht dabei aber nur Backups, welche vor mindestens 24 Stunden als zu löschend markiert wurden. Es dauert also immer mindestens einen Tag, bevor etwas wirklich gelöscht wird.
 
Prune sorgt dafür dass die Backups als zu löschend markiert werden, welche nicht mehr der Retention entsprechen. Also hast du als Retention z.B. last=10 und es gibt 13 Backups, dann wird ein Prune Job die ältesten 3 Backups markieren, damit die vom nächsten GC gelöscht werden.

Die GC selbst löscht dann als zu löschend markierte Backups. GC löscht dabei aber nur Backups, welche vor mindestens 24 Stunden als zu löschend markiert wurden. Es dauert also immer mindestens einen Tag, bevor etwas wirklich gelöscht wird.
Danke für diese Erklärung. Nun wäre es ja toll wenn ich sich Backup / Snapshot / GC und Prune nicht überschneiden während diese laufen.
Ich weiss nun wie lange das ein Vollbackup geht, ca. 6.5 h. Wie lange muss ich denn bei GC und Prune rechnen?
 
  • Like
Reactions: herzkerl
Schwer zu sagen. Das hängt immer ganz von der Datenmenge im Datastore und der IOPS-Performance deines Storages ab. Bei mir auf 4 HDDs kann so ein GC schon mal seine 1-2 Stunden dauern um da 700GB an Backups abzuarbeiten. Da darfst du ja nicht vergessen, dass da deine 1.34TB mindestens eine drittel Million Chunks ergeben. Und ein GC muss dann alle Chunk-Dateien einmal durchgehen und prüfen, ob die Chunks gelöscht werden sollen. Noch schlimmer ist es bei Verify Jobs. Da müssen dann alle Chunk auch noch einmal komplett gelesen und erneut gehasht werden was bei mir gute 6 Stunden pro TB dauert.
 
Last edited:
ahhh... gut zu wissen. Dann werde ich mehr als 2 h zwischen GC und Prune einplanen. Und den Verify-Job werde ich auf Samstag morgen legen. Dann ist die Last ein wenig verteilt.

Ich werde die Geschichte mal so laufen lassen und natürlich beobachten wie sich alles entwickelt.

Tja, was soll ich sagen.... du hast mir als Neuling auf Proxmox sehr geholfen mit Deinen ausführlichen Erklärungen. Vielen herzlichen Dank dafür.
Ich wünsche Dir morgen eine guten Start in die neue Woche ;-)