Schnelle Sicherung v. großen Containern / Fast Backup with container of many files

[floh8]

ich bin heute über einen post gestolpert, der mir nochmal begreiflich machte, dass das Problem mit langsamen Backups bei containern mit vielen Dateien nicht nur besteht, wenn der container auf einen FS wie NFS oder ext4 liegt, sondern bei jedem FS vorherrscht - auch bei denen, die snapshots unterstützen. Ich recherchierte bereits im Inet für Lösung und fand diesen Blog. Nun ist der etwas älter und ich dachte, das Problem besteht sicherlich nicht mehr, aber dem ist wohl nicht so.

Ich finde borgbackup ist 'ne geniale Lösung und wenn man ein bißchen Technisches liest, könnte man denken, das proxmox dort gelernt hat, denn die nutzen auch chunks, unterstützen auch komprimierung und Deduplizierung. Ist alles sehr ähnlich. Nur borgbackup kann wohl große Datenmounts schnell sichern. Doch wie in den aktuellem Post von @Dunuin angegeben, besteht das Problem immer noch. Man findet auch keinen Hinweis einer Verbesserung in den ReleaseNotes. Ich finde, da muss sich Proxmox schnell mal was einfallen lassen, weil ditte is schon wichtig, dass ich bei der Wahl zwischen Container und VM nicht so eingeschränkt bin. Wenn der Hypervisor oder das Filesystem keine Unterstützung leistet, muss ich halt einen Client zum Installieren im Container programmieren, der mir dabei hilft oder ich gugge bei borgbackup einfach ab. Alles machbar - Ausreden gelten hierfür nicht.

Ich würde ja Proxmox nur mit GlusterFS einsetzen und auf Snapshots bei Containern verzichten. Ein schnelles Backup könnte man dann mit borgbackup umsetzen. Der erwähnte Post oben zeigt dies ja für ceph. Ich würde das Script noch erweitern.

Vorgehen:

- man lässt auf jedem PVE-Node dieses Script laufen und sichert nur die container, die direkt auf diesem Host laufen.
- um eine konsistente Sicherung zu haben, müßte ich den container stoppen
- dann mounte ich das RAW-File von meinem NFS temporär, readonly
- lasse borgbackup die Ordner sichern via ssh oder NFS
- dann natürlich umount des Ordners
- starten des containers

Dabei sichere ich nur die Zusatzmounts und nicht das rootfs. Das rootfs sichere ich mit der config separat über PBS-GUI. Könnte man aber auch gleich über dieses Script an den PBS feuern. Was schön wäre, wenn der PBS pre+post-scripts unterstützen würde.

Übrigens ist die Abfolge oben genau die Gleiche, die proxmox beim Sichern von Containern einsetzt. Bei snapshots oder bei "stop" wird dann das RAW-File oder das Blockdevice gemountet und gesichert.

Vorteil d. Lösung:

- ich habe auch Komprimierung + Dedup
- wenn container verschoben werden, muss ich nichts umkonfigurieren

Ergänzung:
Bezogen auf meinen Post unten will ich ergänzen, dass man es auch mit einer Image-Based-Sicherung des Proxmox-Backup-Clients umsetzen kann. Man muss trotzdem den Container stoppen, aber kann dann mit einem Befehl die Sicherung aller Mounts +Config durchführen und hat alles im PBS genau wie bei einer Konfiguration im PVE. Man nutzt halt nur nicht file-based-Sicherung. Wie in der Doku angemahnt, wird die Dedup-Rate nicht so gut sein, dafür geht die Sicherung schneller als file-based und vermutlich langsamer als mit borgbackup. Will man keine Downtime, müßte man den container auf ceph haben.

 

[dcsapak]

hi,

ich bilde mir zwar ein dass ich zu diesem Thema schon mal was ausführliches geschrieben habe, finde den thread/bug gerade nicht, dh schreib ich hier mal eine Zusammenfassung
(Achtung, tlw sehr technisch)

Am Anfang ein paar grundsätzliche Dinge:
* proxmox-backup-clients' Datei-basiertes backup ist (und vorerst bleibt) so weit es geht Dateisystem agnostisch
* Um ein Datei-basiertes Backup zu machen das zu 100% konsistent & korrekt ist müssen Alle Dateien gelesen werden

Zu Borg-Backup:

Es verwendet zwar ähnliche Prinzipien (Deduplikation, Chunking, etc..) jedoch in einer anderen Art als PBS.
Konkret werden bei borg die chunks niemals über file grenzen hinweg gemacht, bei PBS aber schon:
in pbs sind die chunks ganz unabhängig von den Dateien: Zuerst wird on-the-fly ein 'pxar' Archiv generiert (ähnlich zu tar oder anderen container Formaten) über das dann die
chunks generiert werden, dh man kann von den chunks nicht auf die Dateien schließen (und umgekehrt).

Bei Borg wird pro Datei immer mindestens ein chunk generiert, dh man kann sehr wohl von den Dateien auf die chunks schließen.
Weiters verwendet Borg (konfigurierbare) Heuristiken um Dateien zu überspringen, zb Dateiname + Größe + modification time (weiß gerade nicht was das default ist)
Die Heuristiken können leider im schlimmsten fall dazu führen dass Dateien nicht gesichert werden obwohl sie sich geändert haben (zb wenn eine Applikation die mtime manuell umsetzt)

Nagut, jetzt kann man sagen, ist mir egal, PBS soll auch die Heuristiken verwenden um Dateien zu überspringen. Hier ist jedoch das problem dass (wie oben beschrieben) man nicht
von Dateien auf chunks schließen kann. Dh es würde ein neues partielles pxar generiert werden (mit nur neuen, geänderten files). Dieses würde aber komplett andere chunks generieren und außerdem
könnte man jetzt die alten backups nicht mehr löschen, da das neue die alten Daten nicht mehr enthält.

Ok, jetzt kann man natürlich sagen, schmeißt dass pxar format weg und macht es so wie borg, chunks pro file. Das hat ein anderes großes problem:
viele kleine chunks: Borg hat in meinen Tests mindestens 10mal so viele chunks generiert wie pbs (und im durchschnitt ~1/10 so groß)
das macht die Performance von allen "pro chunk Operationen" kaputt: restore/garbage collect/verify
Von HDDs können 4MiB chunks ca mit 115 MiB/s gelesen werden, 1MiB nur mehr mit 60MiB/s und 64K nur mehr mit 6MiB/s (restore fall)[0]
dh man will so große chunks wie möglich, geht aber nicht wenn man viele kleiine files hat die man nicht zusammenfasst
borg umgeht das, indem sie mehrere chunks in "Segmente" zusammenfassen. Das geht für Borg gut, da sie pro repository nur einen Client unterstützen (dh dedup pro client).
Sobald man sowas macht mit chunks die von unterschiedlichen Systemen kommen, hat man entweder so gut wie keine Deduplikation über Gast-Grenzen hinweg (ein großer vorteil von PBS),
oder jede Garbage-Collection operation dauert ein vielfaches länger + braucht immens mehr Ressourcen.

Weiters gilt, ein PBS backup sollte nicht länger als ein "klassisches" vzdump backup dauern, und das sollte sich in der gleichen Größenordnung wie ein initiales Borg-Backup bewegen.

Wir haben auch Ideen, wie wir das Backup verbessern können, sodass wir zumindest teilweise Dateien überspringen können (mit oben genannten Heuristiken),
das ist aber gar nicht einfach zu lösen und relativ komplex in code umzusetzen.

Falls jemand gute Ideen dazu hat (und vielleicht auch weiß wie man sie technisch umsetzen kann), würde ich bitten auf die developer mailing liste zu schreiben, dort kann man sowas besser (mit allen Entwicklern) diskutieren.
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel

Ich hoffe dieser Post hilft dabei die Unterschiede zu Borg sowie die Design Entscheidungen von PBS besser zu verstehen.

0: https://git.proxmox.com/?p=proxmox-...06b643df542e2664b08009fe;hb=refs/heads/master

 

[floh8]

jetzt habe ich grad ausversehen mein entwurf gelöscht und darf nochmal schreiben
also, danke für die Klarstellung der Unterschiede. Das war sehr informativ. Man erkennt vor allem, das jede techn. Lösung so seine Vor- und Nachteile hat. Ich freue mich, dass ihr euch bereits Gedanken macht dies zu lösen und offen seid für Entwicklerhilfe. Leider bin ich keiner, denn dann hätte ich euch sicherlich schon Vorschläge gemailt.

Fazit deines Posts:

borgbackup kann unter gewissen Umständen kein Backup sein, nämlich dann, wenn filesystem parameter wie mtime oder ctime direkt geändert werden. Wie das geht kann man hier gut nachlesen. Zu betonen bleibt, dass der Dateiinhalt sich nicht verändert hat.

Bewertung meiner seits:

Im Normalfall sollte sich ein Programm an Standards halten, die sowas verbieten. Wir arbeiten im produktiven Bereich alle mit professionellen Softwarelösungen und deshalb denke ich, kann man dieses Manko von borgbackup vernachlässigen.

Ich hoffe, dass wir proxmox-anwender bald auf solche Zusatzlösungen verzichten können. ich bin da zuversichtlich.

 

[floh8]

Am Anfang ein paar grundsätzliche Dinge:
* proxmox-backup-clients' Datei-basiertes backup ist (und vorerst bleibt) so weit es geht Dateisystem agnostisch

@dcsapak : Eine Verständnis frage hätte ich noch. Der Proxmox-Client unterstütz ja auch Imagesicherung von Blockdevicen oder Imagefiles. Werden diese Devices auch temporär vor jeder Sicherung gemountet? Schließlich kann man ja darüber auch Single-File-Restore fahren.

 

[dcsapak]

nein das ist umgekehrt: block devices werden stur in 4MiB chunks unterteilt und gesichert (daher geht das mit der qemu dirty-bitmap gut, das kann man so mappen das ein bit einem chunk entspricht) und beim file-restore wird dynamisch
eine vm mit minimalem kernel + daemon gestartet wo gemountet wird

 

[dcsapak]

zur ergänzung (hab jetzt nachgeschaut), borg verwendet filename + size + mtime + inode nummer

If the file’s size, mtime_ns and inode number is still the same, it is considered to not have changed. In that case, we check that all file content chunks are (still) present in the repository (we check that via the chunks cache).

die inode nummer ist eine gute idee, geht aber leider nicht immer
zb bei unseren 'suspend' backups werden die daten wegkopiert und bekommen klarerweise neue inodes

 

[floh8]

Wer es komfortabler haben möchte, sollte sich diese Lösung anschauen. Ehrlich bewertet ist es nicht ganz mein Geschmack, da zusätzlich mit vzdump gearbeitet wird. Das wäre mir dann schon zuviel overhead. Ansich ist das Script klasse.

 

[floh8]

Weiters verwendet Borg (konfigurierbare) Heuristiken um Dateien zu überspringen, zb Dateiname + Größe + modification time (weiß gerade nicht was das default ist)
Die Heuristiken können leider im schlimmsten fall dazu führen dass Dateien nicht gesichert werden obwohl sie sich geändert haben (zb wenn eine Applikation die mtime manuell umsetzt)

Problem kann man hier nachlesen:https://borgbackup.readthedocs.io/e...lways-chunks-all-my-files-even-unchanged-ones

ABER:
ist gelöst schon seit einer Weile:https://github.com/borgbackup/borg/issues/4583

 

[dcsapak]

Problem kann man hier nachlesen:https://borgbackup.readthedocs.io/e...lways-chunks-all-my-files-even-unchanged-ones

ABER:
ist gelöst schon seit einer Weile:https://github.com/borgbackup/borg/issues/4583

ok aber ctime kann man nicht immer nehmen, siehe mein kommentar wegen suspend backup

 

[floh8]

zur ergänzung (hab jetzt nachgeschaut), borg verwendet filename + size + mtime + inode nummer


die inode nummer ist eine gute idee, geht aber leider nicht immer
zb bei unseren 'suspend' backups werden die daten wegkopiert und bekommen klarerweise neue inodes

Zitat auf borg-website:

"....It is possible for some filesystems, such as mergerfs or network filesystems, to return inconsistent inode numbers across runs, causing borg to consider them changed. A workaround is to set the option --files-cache=ctime,size to exclude the inode number comparison from the files cache check so that files with different inode numbers won’t be treated as modified. ..."

man merkt, borg entwickelt sich auch weiter.

 

[dcsapak]

bitte nochmals meinen satz genau lesen: wir kopieren die daten bei einem suspend backup dh die dateien bekommen neue inodes (+ctime), in so einem fall kann man nur die mtime + size nehmen... für stop/snapshot backups sollte Inode+ctime+size natürlich auch funktionieren. das löst aber die anderen probleme bezüglich deduplication/files etc nicht

 

[floh8]

also..mein post bezieht sich auf die probleme von borg, die du aufwirfst, nicht auf eure mögliche Lösung für big container bzw. probleme bei suspend (bitte nochmal genau die posts verfolgen!)...ihr habt eure probleme noch nicht gelöst. wir warten gespannt bis es soweit sein wird.

 

[dcsapak]

ah ok, dann hab ich das missverstanden.

 

[ahofmann]

Nur borgbackup kann wohl große Datenmounts schnell sichern.

Meine 2 Cent abseits allem anderen, was hier besprochen wurde: Ich liebe Borg und ich nutze seit Jahren nichts anderes. Aber es ist eigentlich nicht wirklich schnell. Durch die sehr gut funktionierende Deduplikation wirkt es schnell, aber die hat andere Nachteile (die hier auch schon genannten Chunks können schnell in die Millionen gehen und dann kann jeder Aufruf von Borg gerne mal 30 Sekunden dauern). Ich sichere damit alle 4 Stunden 70 GB SQL Dumps, also wenige, große Dateien. Das ist das einfachste Szenario, das es für ein Backupprogramm gibt. Es ist nur so schnell, wie die Festplatte die Dateien lesen kann, denn jedes Byte wird gelesen und gehashed. Und das jedes Mal, auch wenn am Ende nur ein paar Megabyte im Borg repo landen. Ich wünschte Borg könnte auf Changed Block Tracking zurückgreifen, aber das wird nie kommen, ist out of scope.

Dann sichere ich damit noch Dateiserver und da ist es auch nicht schnell und da schmerzt fehlendes CBT umso mehr. Jeder Backuplauf dauert auf einigen Systemen Stunden, einfach, weil alle Dateien geöffnet und gelesen werden müssen (außer man verlässt sich auf mtime bzw. ctime der Datei, was z. B. bei TrueCrypt/VeraCrypt Containern nicht funktioniert).

Und dann ist Borg noch single threaded...

Wie gesagt, Borg ist bisher der heilige Gral was Sicherungen angeht. Aber schnell ist es nur dadurch, dass die Deduplikation sehr gut funktioniert (wenn man es korrekt eingestellt hat). Alles andere an Borg ist schmerzhaft lahm und/oder frisst enorm RAM.

urbackup z.B. kann CBT und ist dadurch wesentlich schneller beim Sichern von Dateibackups.

 

[floh8]

danke für deine erfahrungen...CBT in urbackup gibt es nur für Windows. Für Windows würde ich andere tools nehmen. Hier geht es um Linux Container.

 

[floh8]

Die schwammichen und extra verworrenen Aussagen vom staff oben stehen im direkten Widerspruch zur Doku v. Proxmox.
Auszüge aus der Doku:

Fixed sized chunking requires minimal CPU power, and is used to backup virtual machine images.

Variable sized chunking needs more CPU power, but is essential to get good deduplication rates for file archives.

The Proxmox Backup Server supports both strategies.

Fixed-sized Chunks​

For block based backups (like VMs), fixed-sized chunks are used. The content (disk image), is split into chunks of the same length (typically 4 MiB).

This works very well for VM images, since the file system on the guest most often tries to allocate files in contiguous pieces, so new files get new blocks, and changing existing files changes only their own blocks.

As an optimization, VMs in Proxmox VE can make use of 'dirty bitmaps', which can track the changed blocks of an image. Since these bitmap are also a representation of the image split into chunks, there is a direct relation between dirty blocks of the image and chunks which need to get uploaded, so only modified chunks of the disk have to be uploaded for a backup.

Since the image is always split into chunks of the same size, unchanged blocks will result in identical checksums for those chunks, so such chunks do not need to be backed up again. This way storage snapshots are not needed to find the changed blocks.

For consistency, Proxmox VE uses a QEMU internal snapshot mechanism, that does not rely on storage snapshots either.

Warum poste ich das? Der Proxmox-Backup-Client ist nicht speziell ausgelegt auf file-based-Sicherungen, wie man oben in der doku liest.
Imagedateien geben generell die Möglichkeit schneller zu sichern als filesystem-based, wenn das Dateisystem mitspielt. Optimieren kann man es mit Dirty-Bitmaps, um noch schneller zu sein.

Wenn man die Sicherung eines Container startet, dann macht Proxmox immer eine file-based-Sicherung. Ich frage mich aber warum eigentlich. Ich habe einen laufenden Container mit rootfs auf LVM-Thin manuell als "block based backup" gesichert. Ich musste noch nicht mal ein Zusatzmount machen oder ähnliches.

# proxmox-backup-client backup ct_root.img:/var/lib/vz/images/100/vm-100-disk-0.raw --repository 192.168.122.4:bkpdatastore2 --backup-type ct --backup-id 100 --crypt-mode none

Natürlich habe ich keine konsistente Sicherung hier, deshalb muss man halt den container vorher herunterfahren.
Deshalb nochmals eine Ergänzung zur obigen Empfehlung.

 

[dcsapak]

Die schwammichen und extra verworrenen Aussagen vom staff oben stehen im direkten Widerspruch zur Doku v. Proxmox.

nur zur info: den großen teil des zitierten Auszugs aus der Doku hab auch ich geschrieben
ich wüsste nicht was da im Widerspruch steht?

Der Proxmox-Backup-Client ist nicht speziell ausgelegt auf file-based-Sicherungen, wie man oben in der doku liest.

hat niemand behauptet

Wenn man die Sicherung eines Container startet, dann macht Proxmox immer eine file-based-Sicherung. Ich frage mich aber warum eigentlich.

Das hat mehrere gründe:

* Datei-basierte backups sind grundsätzlich angenehmer um zu restoren, gerade was einzelne Dateien angeht. VM File restore kam erst vor kurzem hinzu (und geht überhaupt nur auf PVE, nicht auf dem PBS selbst)
* Container auf zb ZFS haben ein subvolume, hier gibt es kein Image. Ein 'Image' basiertes container backup kann man nicht so einfach auf einem ZFS restoren (muss man wieder mounten, etc.), das macht den Backup/Restore code unnötig kompliziert und Fehleranfällig.
* Wir wollen die Backups so konsistent wie möglich machen, also Container Backups sind file-basiert (sowohl "klassische" vzdump backups als auch auf PBS), VM Backups sind Disk-Image basiert.
* Es gibt soweit ich weiß kein vernünftiges CBT für Image files, dh dieser Vorteil fällt komplett weg.

Natürlich habe ich keine konsistente Sicherung hier, deshalb muss man halt den container vorher herunterfahren.

Das größte Argument dagegen. kann man zwar meistens mit 'snapshots' lösen, unterstützt aber nicht jeder storage, hier wird dann der 'suspend' Modus genommen wo Dateien kopiert werden. Hier könnte man zwar
Image basiertes backup machen (macht den code auch nicht einfacher) aber je nach Dateien ist das image jedes mal ganz anders und die Deduplizierung ist im Eimer.

 

[floh8]

nur zur info: den großen teil des zitierten Auszugs aus der Doku hab auch ich geschrieben
ich wüsste nicht was da im Widerspruch steht?

dann vielleicht mal in englisch antworten, da drückst du dich viel verständlicher und einfacher aus, auch wenn die doku semi professionell ist, weil so viel fehlt.

Wir wollen die Backups so konsistent wie möglich machen, also Container Backups sind file-basiert

was hat konsistenz mit backuptyp zu tun? da gibt es keine korrelation. ich antworte mal: nichts.

Image basiertes backup machen (macht den code auch nicht einfacher) aber je nach Dateien ist das image jedes mal ganz anders und die Deduplizierung ist im Eimer.

wies ich auch drauf hin. es geht in dem thread nicht um die beste deduplizierungsrate, sondern um schnellere backups von großen containern, die auf glusterfs/nfs liegen, deshalb ist z.B. der suspend - Modus auch nicht relevant hier. jeder muss selber entscheiden, für welchen container er meinen vorschlag umsetzt. niemand empfiehlt hier jetzt gänzlich auf image-based-zu wechseln.
ich verstehe, dass ihr manchmal eine Entscheidung treffen müßt, wie ihr es umsetzt, aber wenn schon so ein Problem mit großen containern wissentlich besteht, dann versuche ich doch dem Anwender wenigstens die möglichkeit zu geben, imagebasierte backups auszuwählen. und dieses zerrede in den threads hier immer, wenn die user mal was berechtigt kritisieren, ist echt läßtig. das macht euch richtig unseriös, unsympathisch und unprofessionell wirkend.

an alle: es wäre schön, wenn jemand reale Daten liefern könnte von einem Vergleich zw. file- und image-based eines großen containers.

 

[dcsapak]

auch wenn die doku semi professionell ist, weil so viel fehlt.

Wenn konkret etwas fehlt, bitte mach einen bug auf unserem bugtracker auf, dort können wir das dann jemandem zuweisen der die doku ergänzen kann.

was hat konsistenz mit backuptyp zu tun? da gibt es keine korrelation. ich antworte mal: nichts.

ich meinte nicht Datenkonsistenz sondern Konsistenz mit Auge auf Gast-Typ (CT/VM). PVE Container Backups sind immer ein File-Archiv, PVE VM Backups sind immer disk images (in einem Container format).

ich verstehe, dass ihr manchmal eine Entscheidung treffen müßt, wie ihr es umsetzt, aber wenn schon so ein Problem mit großen containern wissentlich besteht, dann versuche ich doch dem Anwender wenigstens die möglichkeit zu geben, imagebasierte backups auszuwählen. und dieses zerrede in den threads hier immer, wenn die user mal was berechtigt kritisieren, ist echt läßtig. das macht euch richtig unseriös, unsympathisch und unprofessionell wirkend.

Ich verstehe nicht ganz wo jetzt das Problem ist. Wir versuchen die Produkte so gut wie möglich zu machen, jedoch muss man immer zwischen verschiedenen Dingen wie Entwickler-Zeit/Performance/Wartbarkeit/UX/(und noch vielem mehr) abwägen und balancieren. Da der Code für Container bis jetzt auf File-Archive ausgelegt war (vor PBS) und file-basierte backups noch viele andere vorteile haben, sind wir diesen Weg weitergegangen (PBS Container backups sind übrigens nicht langsamer als alte VZDUMP Container backups) da eine Änderung hier eine nicht triviale Code Anpassung von Nöten macht, die den ganzen restore/backup code Pfad verkompliziert. (Abgesehen dass man Container dann nicht von jedem storage auf die gleiche art sichern kann, ein storage wechsel vom container das backup-format wechselt, etc.)

Ich versuche hier nur auf die (berechtigten) Fragen zu antworten um zu erklären warum wir die Entscheidungen so getroffen haben.

Niemand hindert dich daran, Container Backups manuell image basiert zu machen, aber dann musst du auch beim restore den backup-client manuell bedienen.

 

[floh8]

So, ich bin kein Freund von Kaffeesatz lesen, sondern eher von praktischen Tests, wenn Proxmox keine Daten liefern kann. Dafür haben sie ja eine community ich habe also in meinem bescheidenen Testsystem den Proxmox-Client mit borg verglichen, dabei noch zwischen Image-based und File-based Sicherung unterschieden. Ziel ist für mich eine Tendenz abzulesen, wie sich die einzelnen Varianten in größeren Umgebungen verhalten.

Mein Versuchsaufbau:

KVM-System auf ssd
container mit einem 30 GB großen Mount als Raw-File
PBS mit 2 Datastores von 20 GB auf XFS für die beiden proxmox-Varianten auf einer 2. VM natürlich
2. virt. Platte v. 13 (erweitert auf 40) GB mit XFS für das borg repository auf dem PVE-Host
für borg und file-based wird dann das raw-file lokal auf dem PVE-Host gemountet, genau so wie das Proxmox auch macht


Meine Testdaten:
Ich habe zunächst die 30 GB mit Dateien von unterschiedlicher Größe zw. 100K und 50 MB mit realistischen Textdaten über den Lorem-Algorithmus gefüllt. Unterverzeichnisstruktur habe ich nicht geskriptet.
Nach dem Fullbackup habe ich eigentlich nur 5 GB des Speichers mit geänderten Daten beschreiben wollen. Dazu wurden zufällige Dateien zu 5% mit Base64-Zeichenketten an zufälligen Stellen der Datei überschrieben, die nur druckbare Zeichen enthielten und zusätzlich Zeilen gelöscht. Das simluliert nochmal Bilder oder gezippte Daten. Keine Datei wurde doppelt geändert. Allerdings musste ich das Script mehrmals abbrechen, um es zu optimieren und konnte somit danach nicht mehr nachvollziehen, wie viele Daten geschrieben wurden sind. Zu letzt habe ich ca. 3,8 GB Dateiinhalte gelöscht und geändert. 1,7 GB entstandener freier Speicher wurde wieder mit neuen Dateien aufgefüllt. Wenn ich mir die Backupdaten anschaue, dann waren es wohl eher 10 GB oder mehr die geändert worden sind.
Zuletzt habe ich ein weiteres inkrementelles Backup durchgeführt. Diesmal aber ohne zwischenzeitliche Änderung der Daten.

Ergänzung zu borg:
borg kann zstd nur auf einem Kern nutzen, was es damit zu langsam hier und auch im Alltag macht, sodaß ich die Default-Kompression gelassen habe. Es geht ja um Geschwindigkeit.

Modus​	proxmox als image-based​	proxmox als file-based​	borg​
	Dauer | Größe | Repo-Größe	Dauer | Größe | Repo-Größe	Dauer | Größe | Repo-Größe
Vollbackup Dateianzahl: 45417	14,6 min | 8,43 GB | 8,65 GB	19,83 min | 8,14 GB | 8.37 GB	10,75 min | 13 GB | 12,8 GB
1. Inkrementelles B. Dateianzahl: 45482	15,45 min | 7,92 GB | 16,59 GB	22,43 min | 7,64 GB | 16,03 GB	9,17 min | 9,4 GB | 22 ,4 GB
2. Inkrementelles B. Dateianzahl: 45482	7,23 min | 0 GB | 16,59 GB	6,6 min | 0 GB | 16,03 GB	0,17 min | 0 GB | 22,4 GB
Auslastung SSD+CPU während Vollbackup:	cpu bei 50-75%; i/o blinkend	cpu bei 75-100%; fast durchgängig volle i/o auf sdd	cpu bei 25-50%; i/o blinkend - full

Fehler, die auftraten:

Mir ist besonders borg negativ aufgefallen. ich musste zwischenzeitlich mehrmal das Repository löschen und dabei schmeisst er immer einen Fehler. borg wurde übrigens in der aktuellen Debian-Version 1.1.16 eingesetzt. Desweiteren musste ich den Backupspeicher für Borg erweitern und im folgenden Job stürzte er bei 90 % mit der Fehlermeldung "kein Platz mehr" ab, obwohl ausreichend da war. Beim PBS nervte mich ,das bei bei Löschung eines Datastores nicht alle Ordner und Dateien in dem Datastore-Ordner gelöscht werden. Dies musste ich manuell erledigen. Durch Abbruch des Backupvorgangs musste ich Sessions nochmal starten. Während Proxmox-Backup-Client die alten Chunks überschrieb, legte borg komplett neue an und somit lief der Storage voll. borg löscht aber diese unfertigen Chunks/fehlerhafte Backups bei einem Pruning-Vorgang.

Fazit:
Die Zahlen sprechen für sich. Borg geht hier als klarer Gewinner hervor. Interessant ist der Unterschied zwischen den beiden Proxmox-Varianten. Da kann ich nur nochmal wieder holen, was ich oben geschrieben habe. Warum kein Imagebackup bei Containern? Das dies allerdings so extrem zu Gunsten der Image-Based-Variante ausfällt, hatte ich bei weitem nicht erwartet. Obwohl hier der Staff die schlechte Deduplizierungsrate für Image-Based bei inkrementellen Sicherungen betonte, sehe ich hier nun keinen nennenswerten Unterschied. Trotzdem sind beide, auf Grund der Dauer, für die Praxis nicht tauglich. Meine Umgebung ist natürlich hemmend, aber wenn man die Zeiten auf praxisnahe Umgebungen mit mehreren 100 GB hochrechnet, dann wird es für große Umgebungen mehr als schwierig. borg schneidet hier besser ab, aber die Stabilität gibt mir leider zu denken. Was mir beim PBS fehlt ist eine Fortschrittsanzeige der laufenden Tasks wie sie borg anbietet.

Ich hoffe nun, dem einen oder anderen geben die Zahlen eine Entscheidungsgrundlage für sein System.