Feature Request: do not prune flag

[Dunuin]

Moin,

Ich habe hier aktuell das Problem, dass ich 2 Arten von Backups haben möchte. Einmal die regelmäßigen Backups die der PVE Backup-Job automatisch jeden Tag erstellt und wo das ja auch gut klappt mit den "keep hourly/daily/weekly/monthly/annualy" Prune-Einstellungen.
Dann mache ich aber gerne noch manuelle Backups vor und nachdem ich etwas wichtiges ändere. Stelle ich z.B. eine VM von Buster auf Bullseye um, dann möchte ich ein Backup von dem letzten Stand auf Buster, damit ich später zur aktuellsten Buster-Version restoren kann, falls sich doch einmal (vielleicht Wochen später) herausstellt, dass es da doch Probleme mit Bullseye gibt.
Soweit ich weiß würde das mit PBS aktuell nur gehen, wenn ich da zwei getrennte Datastores erstellen würde, da ich Prune-Einstellungen nur global für den ganzen Datastore festlegen kann. Ich müsste also einen weiteren Datastore anlegen und den dann so einstellen, dass da kein automatisches Pruning stattfindet. Das wäre aber natürlich ziemlich ungünstig, da es quasi die den benötigten Platz für Backups verdoppeln würde, da verschiedene Datastores nicht gegenseitig auf die Chunks zugreifen können und dann natürlich die Deduplikation auch keinen Platz einsparen kann. Statt 1% würde so ein zusätzlicher manueller Snapshot dann ja die vollen 100% belegen.

Was ich da also super praktisch finden würde wäre eine Art Do-not-Prune-Flag was man für jeden PBS Snapshot setzen könnte. Das Pruning von PBS könnte dann gucken, ob das Flag gesetzt ist und falls ja, dann wird der Snapshot ignoriert und kann nicht automatisch von PBS gelöscht werden und man müsste es dann manuell tun.
So ein Flag könnte man dann ja für den proxmox-backup-client per parameter "--ignore-prune yes" oder ähnlich setzen und bei PVE könnte man eine entsprechende Checkbox haben.

Mit so einem Do-Not-Prune-Flag könnte man dann automatische Backups die sich automatisch löschen, manuelle Backups die sich automatisch löschen und manuelle Backups die nie gelöscht werden alles in einem Datastore haben.

Aktuell speichere ich hier alle manuellen Backups noch per vzdump auf mein NAS, damit wenn das schon zusätzlichen Platz braucht, ich wenigstens noch ein Not-Backup habe, falls beim PBS mal etwas schief läuft und der ganze Datastore irgendwie kaputt geht. Schöner wäre es da aber schon das alles über PBS in einem Datastore machen zu können. Und den durch die Deduplikation eingesparten Platz könnte man dann lieber dazu nutzen, um den ganzen Datastore einmal zusätzlich extern zu sichern.

Geht sowas technisch? Ist nach sowas bereits als Wunsch im Bugtracker oder sollte ich das mal dort posten? Würden das andere auch nützlich finden?

 

[fluxX04]

Hi,

dazu gibt es schon einen feature request im bugtracker: https://bugzilla.proxmox.com/show_bug.cgi?id=3602
und es wird ebenso daran gearbeitet: https://lists.proxmox.com/pipermail/pbs-devel/2021-September/003926.html

Greetz

 

[floh8]

übrigens: https://forum.proxmox.com/threads/feature-request-please-add.95652/

 

[Dunuin]

Das mit den Backup Retentions finde ich auch noch etwas unschön gelöst, dass das nur global per Datastore geht. Wäre wirklich schön, wenn man da pro Datastore verschiedene Backup Retentions nutzen könnte. Das man da z.B. wöchentliche "Stop" Backups machen könnte die Monate/Jahre behalten werden und tägliche "Snapshot" Backups die aber nur Wochen behalten werden. Ist halt schon etwas unschön, wenn man die selben VMs in unterschiedlichen Datastores speichern muss, was dann den Platz verdoppelt, obwohl das super deduplizierbar wäre.

 

[floh8]

Das mit den Backup Retentions finde ich auch noch etwas unschön gelöst, dass das nur global per Datastore geht. Wäre wirklich schön, wenn man da pro Datastore verschiedene Backup Retentions nutzen könnte. Das man da z.B. wöchentliche "Stop" Backups machen könnte die Monate/Jahre behalten werden und tägliche "Snapshot" Backups die aber nur Wochen behalten werden. Ist halt schon etwas unschön, wenn man die selben VMs in unterschiedlichen Datastores speichern muss, was dann den Platz verdoppelt, obwohl das super deduplizierbar wäre.

du kannst die dateisystemdeduplizierung von zfs oder btrfs nutzen....die ist dann datastore-übergreifend, deshalb wird ja auch immer zfs unterstützt - naja das selfhealing ist wohl auch nicht ganz unwichtig und die raid-funktion

 

[Dunuin]

du kannst die dateisystemdeduplizierung von zfs oder btrfs nutzen....die ist dann datastore-übergreifend, deshalb wird ja auch immer zfs unterstützt - naja das selfhealing ist wohl auch nicht ganz unwichtig und die raid-funktion

Das frisst mir dann aber auch zusätzliche 5GB RAM weg je 1TB Datastore für die Deduplikationtabellen und Dedupliziertes nochmal deduplizieren ist auch nicht gerade effizient.
Bin schon froh das ich mein PBS auf 3GB RAM drücken konnte, weil das auf dem TrueNAS läuft und da habe ich schon die maximalen 32GB RAM verbaut die das Board verträgt, wovon Dienste dann schon 12-18GB schlucken und so schon nicht mehr viel für den ARC frei ist.

 

[floh8]

ür die Deduplikationtabellen und Dedupliziertes nochmal deduplizieren ist auch nicht gerade effizient.
Bin schon froh das ich mein PBS auf 3GB RAM drücken konnte, weil das auf dem TrueNAS läuft und da habe ich schon die maximalen 32GB RAM verbaut die das Board verträgt, wovon Dienste dann schon 12-18GB schlucken und so schon nicht mehr viel für den ARC frei ist.

hä? warum stellst du dann die frage, wenn du eh zfs hast? Sinnlos.

 

[Dunuin]

Weil ich keine ZFS Deduplikation nutze. Mein ARC hat nur 12-16 GB und da ist keine ZFS Deduplikation drin. Dann bräuchte ich zusätzliche 5 bis 160GB mehr RAM, je nachdem wieviel von meinem Speicher ich deduplizieren wollen würde. PBS Deduplikation läuft wunderbar ohne irgendwie extra RAM belegen zu müssen. Bin froh das die 12-16GB ARC gerade so für die 34TB zum Cachen reichen. Eigentlich bräuchte ich da ja schon ein vielfaches an RAM.
Mehr als 32GB RAM verträgt CPU/Chipsatz nicht, da lässt sich also nichts mit ZFS Deduplikation machen, da das weit mehr RAM benötigen würde als meine Hardware unterstützt.

 

[floh8]

naja, sind wir mal gespannt. ich mein, etwas doppelt zu haben, ist ja nicht der weltuntergang. früher gabs keine dedup und keiner meckerte.
umsetzbar wäre es und ich denke noch nicht mal sehr aufwendig. Im Grunde genommen, könntest du es hirarchisch betrachten und jede Backupgroup kann wieder andere Retention haben.

 

[Dunuin]

Doppelt auf dem selben ZFS Pool ist aber schon etwas unschön, wenn man theoretisch ja mit dem halben Platz auskommen würde. Und dann wird der Pool ja noch auf das Backup-NAS repliziert. Dann muss ich das nicht doppelt sondern 4 mal speichern. Und dann noch die Kapazitätsverluste weil alles, inkl. Backups, Raid mit Parität ist und man 10-20% wegen CoW freilassen muss, dass das eher den 6 fachen Platz wegnehmen würde.
Ist dann schon ein unterschied ob ich nur 4TB an Laufwerken für einen einzelnen Datastore oder 12TB an Laufwerken für 3 Datastores brauche, wenn ich eigentlich nur meinen PVE sichern möchte der nur 1,2 TB an Storage hat.

Aber das Do-Not-Prune-Flag an dem gearbeitet wird ist ja schon einmal ein guter Anfang. Dann muss ich die selbe VM wenigstens nicht auf drei verschiedenen Datastores speichern um drei verschiedene Backup Retentions zu haben.

Wäre schon echt schön, wenn man da die Backup Retentions individueller einstellen könnte. Ob nun per Backup-Job, das man einen Datastore in Untergruppen strukturieren könne, Retention pro Backup manuells als CLI parameter oder sonst wie. Haufenweise verschiedene Datastores anlegen nur um die selben VMs mit anderen Retentions sichern zu können ist jedenfalls recht günstig. Gerade im Homelab, wo man ja doch mehr aufs Geld achten muss.

 

[Falk R.]

Mal ne dumme Frage dazu:
Unterstützt der PBS reflink? Kann ZFS das eventuell auch?
Ich nutze für meine Windows Backups Veeam und auf dem Repo XFS mit reflink.
Habe nach 5 Monaten bei 100TB Belegung im FS, 400TB Backups.

 

[Dunuin]

Mal ne dumme Frage dazu:
Unterstützt der PBS reflink? Kann ZFS das eventuell auch?
Ich nutze für meine Windows Backups Veeam und auf dem Repo XFS mit reflink.
Habe nach 5 Monaten bei 100TB Belegung im FS, 400TB Backups.

Hm, gute Frage. Aber btrfs und xfs sind ja auch reine Dateisysteme und können nicht als Block Devices benutzt werden. Wenn dann würde das bei ZFS wohl höchstens für Datasets gehen.

 

[fabian]

Mal ne dumme Frage dazu:
Unterstützt der PBS reflink? Kann ZFS das eventuell auch?
Ich nutze für meine Windows Backups Veeam und auf dem Repo XFS mit reflink.
Habe nach 5 Monaten bei 100TB Belegung im FS, 400TB Backups.

nein und nein

@thread es existieren plaene fuer ein namespace feature, dass erlaubt mehrere "logische" datastores mit einem gemeinsamen chunk store zu betreiben. damit waeren auch die prune settings und schedules getrennt - pruning laeuft ja auf der ebene der metadaten, nicht der chunks.

 

[floh8]

btrfs und xfs unterstützen beide reflink - nur leider muss bei xfs das backupprogramm dies unterstützen und pbs tut dies leider nicht. Da es kein dedup-programm gibt, was mich ehrlich gesagt ziemlich verwundert, dass das noch niemand in Angriff genommen hat, fällt diese Variante auch flach. Vielleicht muss bei xfs das Dedup zwingend das Programm selber anschieben - techn. bedingt. Es wäre auf jeden Fall eine geile Alternative zu zfs.
Also übergangsmäßig wäre btrfs für dich @Dunuin die mögliche Alternative, denn Proxmox wird wohl noch einige Zeit für ihre Lösung brauchen.
Und wenn du jetzt mit deinem RAM kommst, dann probiere es doch mal aus, denn btrfs macht vorerst nur offline-dedup und da werden die Tabellen sicherlich nicht im RAM gehalten. Und COW kannst du abstellen.

Ha...ich fasse es nicht....nein, ich fasse es nicht....du kannst dedup-tools auch für xfs einsetzen.....na wie geil.

http://dashohoxha.fs.al/deduplicating-data-with-xfs-and-reflinks/

 

[Falk R.]

Ha...ich fasse es nicht....nein, ich fasse es nicht....du kannst dedup-tools auch für xfs einsetzen.....na wie geil.

http://dashohoxha.fs.al/deduplicating-data-with-xfs-and-reflinks/

Aber Vorsicht, wenn du reflink und dedup mixt, hast du schnell Performanceeinbußen und mehr RAM Bedarf. Das zusätzliche Dedup lässt die Daten mehr fragmentieren. Habe ich schon ausgiebig mit Veeam gestestet.
Wenn die Backupsoftware reflink unterstützt ist das schon geil.

 

[floh8]

Aber Vorsicht, wenn du reflink und dedup mixt, hast du schnell Performanceeinbußen und mehr RAM Bedarf. Das zusätzliche Dedup lässt die Daten mehr fragmentieren. Habe ich schon ausgiebig mit Veeam gestestet.
Wenn die Backupsoftware reflink unterstützt ist das schon geil.

wenn software reflink unterstützt, brauchste ja auch kein dedup-tool mehr oder ist veeam reflink nicht repoübergreifend? übrigens vprotect unterstützt auch reflink.

 

[Falk R.]

Von vprotect hatte ich bisher noch nichts gehört. Super ist, dass alle gängigen Hypervisoren unterstützt werden. Application konsistente Backups gehen laut Doku auch relativ gut, nur für den Restore finde ich nichts. Hast du schon Erfahrungen damit?

 

[floh8]

ich stieß nur darauf, um eine backuplösung für xcp-ng zu finden. mittlerweile gibt es aber eine bessere alternative.