Backup inkrementell
- Thread starter Stone
- Start date
-
- Tags
- backup inkrementell
Hallo,
Hilft eventuell weiter:
Beschäftige dich bitte einmal mit Datendeduplizierung.
Wir nutzen das bei uns für Backups und haben eine dedup Rate von ca.96%.
Wichtig hierbei die Backups unkomprimiert abzulegen.
Dann belegst du nur soviel wie es Änderungen in den Daten gibt.
Peter
Hilft eventuell weiter:
Beschäftige dich bitte einmal mit Datendeduplizierung.
Wir nutzen das bei uns für Backups und haben eine dedup Rate von ca.96%.
Wichtig hierbei die Backups unkomprimiert abzulegen.
Dann belegst du nur soviel wie es Änderungen in den Daten gibt.
Peter
Nicht schlecht. Darf man fragen wie viel RAM die Maschine hat?
Hab das hier mal getestet.
Code:
zfs get dedup v-machines/testdub
NAME PROPERTY VALUE SOURCE
v-machines/testdub dedup on local
Code:
v-machines/testdub 12.6G 623G 12.6G /v-machines/testdub
Code:
3.2G vzdump-qemu-116-2018_01_17-22_58_11.vma
3.2G vzdump-qemu-116-2018_01_17-23_01_34.vma
3.2G vzdump-qemu-116-2018_01_17-23_12_47.vma
3.2G vzdump-qemu-116-2018_01_17-23_15_33.vmaVielen Dank
Nachtrag: Verwirrende Sache, anscheinend geht das ganze auf dem Pool.
Code:
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
v-machines 7.25T 6.16T 1.09T - 21% 85% 4.37x ONLINE -
Last edited:
Hallo,
Das Backup wird nicht schneller da die zu speichernde Menge nicht weniger wird, sondern eher mehr ohne Komprimierung.
Die dedub Rate hängt vom Backupsystem ab. ZFS ist schlechter als bspw. Enterprise Backuplösungen (Datadomain).
ZFS macht dies auf Blockebene, sprich gleiche Blöcke werden als Hardlink gespeichert.
zpool Status -D zeigt die Rate besser an.
Wenn du nur die vier Backups dort liegen hast wirst du mit Sicherheit nicht viel mehr als die 3.2 GB belegen.
Achtung: dedup kannst du nicht nachträglich einschalten bzw. einschalten kannst du es schon, hat aber auf die vorhandenen Daten keinen Einfluss.
Peter
Das Backup wird nicht schneller da die zu speichernde Menge nicht weniger wird, sondern eher mehr ohne Komprimierung.
Die dedub Rate hängt vom Backupsystem ab. ZFS ist schlechter als bspw. Enterprise Backuplösungen (Datadomain).
ZFS macht dies auf Blockebene, sprich gleiche Blöcke werden als Hardlink gespeichert.
zpool Status -D zeigt die Rate besser an.
Wenn du nur die vier Backups dort liegen hast wirst du mit Sicherheit nicht viel mehr als die 3.2 GB belegen.
Achtung: dedup kannst du nicht nachträglich einschalten bzw. einschalten kannst du es schon, hat aber auf die vorhandenen Daten keinen Einfluss.
Peter
und noch viel wichtiger - ZFS dedup braucht RAM (und zwar ordentlich!). der RAM-verbrauch geht erst weg, wenn dedup ausgeschaltet und alle deduplizierten blöcke gelöscht worden sind!
Ok, ich hab 500GB an Daten, wieviel RAM benötige ich? Gibt es ne gültige Faustregel?
Bei pve-zsync targets wird's ja wohl nix bringen... da wird das ja mit den Snapshots schon geregelt.
Bei pve-zsync targets wird's ja wohl nix bringen... da wird das ja mit den Snapshots schon geregelt.
Das ist heftig.
320 byte pro Block, wenn ich mich richtig erinnere. Beim Schreiben wird dann statt ein Duplikat zu schreiben ein Counter erhöht bzw. wenn der Blockinhalt komplett neu ist und kein Duplikat, ein neuer Eintrag angelegt und der Block tatsächlich geschrieben. Beim Löschen eines Blocks dann umgekehrt den Counter verringern bzw. wenn er auf 0 fällt tatsächlich freigeben. Dh. nach dem Ausschalten von Dedup müssen diese Einträge weiter bestehen und mit-Tracken, wie viele Referenzen auf Block X noch existieren.
Beim letzten OpenZFS Summit gabs einen Talk mit einer Alternativimplementierung:
Gibt es noch weitere Möglichkeiten das Backup inkrementell ohne ZFS zu machen?
Hab einen FreeNAS Storage und mache jede Nacht ein Fullbackup auf eine NFS-Freigabe...
Wüsste auch gerne noch wie man die Konfiguration des Proxmox sichern kann?
Hab vor einigen Tagen etwas über Borgbackup gehört, kennt/nutzt das vielleicht jemand von Euch?
Hab einen FreeNAS Storage und mache jede Nacht ein Fullbackup auf eine NFS-Freigabe...
Wüsste auch gerne noch wie man die Konfiguration des Proxmox sichern kann?
Hab vor einigen Tagen etwas über Borgbackup gehört, kennt/nutzt das vielleicht jemand von Euch?
Genau das ist eben egal. Der Ziel-Server läuft mit ZFS und dort werden die Backups entpackt und in Copy-on-Write-Manier gespeichert, sodass hier sehr viel Platz gespart wird ohne dass man das extrem speicherhungrige Deduplizieren verwenden muss. Klar wird es mit Deduplizierung noch besser, aber das ging in unseren Experimenten immer in die Hose bei 12x 3 TB Festplatten und zu wenig RAM (72 GB).
Gibt einen inoffiziellen Patch für vzdump, der aber manuelles eingreifen bei JEDEM Update mit sich bringt:
https://ayufan.eu/projects/proxmox-ve-differential-backups/
Wenn das FreeNAS ein ZFS hat und du die Daten via NFS dort hin schiebst ist das exat meine Lösung die ich oben skizziert habe.
Sämtliche VM-relevanten Dinge werden im Backup der jeweiligen VM gespeichert, für das Betriebssystem gibt es auch Lösungen:
https://forum.proxmox.com/threads/best-practice-for-proxmox-self-backup.38382/
Gibt auch mindestens ein Post über Borg hier im Forum, somit kennt das jemand :-D
Danke für die super Infos... !
Sorry aber das ist jetzt, schön langsam, ganz schön komplex... Wenn ich das richtig verstehe ist die Variante NFS-Freigabe auf ZFS-Dateisystem bei Schmalspurhardware mit wenig RAM, abgesehen von offenen Datenbanktransaktionen, am "ökonomischsten" ?
Das wird mir dann zu kompliziert, könnte dann etwas vergessen, bedeutet mehr Aufwand...
Sorry aber das ist jetzt, schön langsam, ganz schön komplex... Wenn ich das richtig verstehe ist die Variante NFS-Freigabe auf ZFS-Dateisystem bei Schmalspurhardware mit wenig RAM, abgesehen von offenen Datenbanktransaktionen, am "ökonomischsten" ?
Also meine Maschine hier ist klein, nur 4x2TB im RaidZ mit 32GB RAM. Hmm... könnte knapp werden.
Sag mal... gibt es davon ne Doku, oder in ein paar Punkten wo ich nachvollziehen wie was wann wo... steh da gerade voll auf'n Schlauch...
Tja, irgend einen Tod muss man leider immer sterben. Ich würde Datenbankbackup (z.B. über Transaktionslogs) immer einem VM-Backup bevorzugen, wenn es WIRKLICH WICHTIGE Daten sind, sonst kann ich QEmu Agent + Hooks im Gast für die Datenbanken empfehlen, der vor einem VM-Backup dann schnell einen Log-Switch macht. Wenn man keine 24/7 Last auf den VMs hat sollte die Konsistenz bei Backup in betriebsarmer Zeit kein Problem darstellen.
Effiziente Deduplizierung bei VMs muss immer mit der eingestellten Blockgröße im Gast passieren um das Beste aus der Deduplizierung herauszuholen, da die Daten oft fragmentiert und eben nicht immer gleich im Gast liegen. Ganz doofes und simples Beispiel ist die Reihenfolge von Dateien wie (examplarisch) config.sys autoexec.bat und command.com. Alles ist klein aber wenn die Daten identisch sind, aber in verschiedenen Reihenfolgen im Gast direkt hintereinander liegen sieht die Deduplizierung außen eben verschiedenen Inhalt.
Dabei muss natürlich das Alignment auch korrekt sein. Somit hat man meist eine Blockgröße von maximal 4K und somit ist das zum einen schlecht (bei ashift=9) bis zu garnicht (bei ashift=12) zu komprimieren und zum anderen benötigt man VIEL VIEL mehr RAM für die Deduplizierungstabelle, da die ganzen Hinweise zur Deduplizierung immer von Blockgrößen bis 128K ausgehen. Auf meinem Backupserver kann ich mir mit 72 GB-RAM nichtmal die simulierte Deduplizierungstabelle anzeigen lassen, der Prozess schmiert mit OOM ab.
Die Versuche die ich zu dem Thema gemacht hatte (also im Vorfeld) war, dass sich natürlich VMs prima deduplizieren lassen, wenn diese ähnlich sind. Für sehr viele VMs bringt das natürlich ersparnis, jedoch haben wir bei über 100 VMs zwar einiges Identische (Meistens Debian in Verwendung), aber die "gleichen" Teile sind meistens nur so 1 GB pro VM (keine GUI usw. OS brauch ja nicht viel). Die meisten Daten liegen aber als "sonstiges" rum, also der Teil, den man so hat wie Dokumente, Bilder, Videos, Software-Installationspakete, ISOs, Paketspiegel usw.
Daher könnte man natürlich bei Deduplizierung den gemeinsamen Teil sparen, aber das wäre in unserem Fall weniger als 10% und dafür ist das Ding einfach viel, viel viel zu RAM hungrig. Deduplizierung auf SSDs wäre noch was, das ist natürlich auch alles langsam, aber es fällt nicht so auf, bzw. es wird länger schnell reagieren als es Festplatten tun. Ich hatte meistens genau an dem Punkt, an dem der DDT nicht mehr in den RAM gepasst hat solche Aussetzer am Client, dass jedes Programm in ein Timeout gelaufen ist. Das war nicht schön.
Diesen Patch verwende ich aktuell und dieser läuft auch gut. Jedoch läuft dieser nicht mit jeder Version. Es gibt zB. für PVE 5.1 noch keinen. Daher war eben die ursprüngliche Frage ob sowas in der Art in PVE einmal kommen soll. Ich würde es super finden wenn der Hersteller diese Funktion out of the box anbieten könnte.