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

[ahofmann]

Hallo zusammen!

Zuerst einmal meinen Dank an Team und Community. Eine gewisse Emotionalität zeigt eine Verbundenheit auf beiden Seiten ;-) .

Der Threat ist zwar schon einige Wochen alt aber sicher noch nicht veraltet. Wir setzen bei uns die Proxmox-KVM-Virtualierung ein, primär allerdings VMs und keine Container, müssen aber auch "banale" Linux-Rechner sichern und haben hier angefangen, den PBS einzusetzen, nachdem wir bisher viel mittels rsync auf Backups synchronisiert haben.

Wir haben auch das im Threat angesprochene Problem von "zuviel Daten" auf den Platten: Auch wenn die Platen bmit 140M/s sichern ... bis da 10TB durch sind, dauert das ... zu lange.

Das Problem hier ist, dass jede Backuplösung, die Dir zur Verfügung steht, kein CBT unterstützt. Ich muss dazu sagen, dass ich PBS nicht nutze. Ich kenne rsync, borg und urbackup in- und auswendig. Man verzeihe mir, wenn ich bezüglich PBS ein paar Fakten falsch darstelle.
PBS, Borg und wie sie alle heißen, müssen jede Datei „anschauen“ und testen, ob die gesichert werden muss. Das ist der Teil, der bei hunderttausenden kleinen Dateien zu lange dauert, selbst wenn am Ende nur wenige neue Daten im Backup landen. PBS arbeitet beim file based backup so: https://pbs.proxmox.com/docs/technical-overview.html#file-based-backup

Beim Backup gibt es ja grob gesagt drei Phasen:

1. checken was gesichert werden muss
2. Daten hashen, komprimieren, verschlüsseln
3. Daten übertragen

In Phase 1 ähneln sich borg, rsync und PBS stark. Um zu wissen, was gesichert werden muss, müssen alle Dateien einzeln angeschaut werden.

Phase 2 gibt es bei rsync so gesehen nicht, in PBS und Borg schon. Hier kenne ich mich zu wenig mit PBS aus, bei Borg ist das Problem, dass es in Python geschrieben ist und single-threaded. Dadurch dauern Backups, wo auch viele Daten übertragen werden müssen, seeeehr lange verglichen damit was der Server schaffen könnte, könnte er nur alle Cores dafür nutzen. Hier ist z.B. rclone den genannten Tools weit überlegen und hat bei mir rsync schon fast komplett verdrängt.

Phase 3 hängt eigentlich immer von der Hardware ab. Das was die Netzwerkverbindung schafft, oder der Storage auf dem die Daten landen, bestimmt wie schnell es geht.

Und dann gibt es noch Backupprogramme, die CBT https://www.storage-insider.de/was-ist-change-block-tracking-cbt-a-949639/ nutzen. Die haben den Vorteil, dass Phase 1 komplett anders aussieht und in bestimmten Fällen enorme Zeitersparnis bringt. Ein Windows urbackup Client braucht für jeden Backup-Lauf mehrere Stunden. Mit CBT? Wenn nicht viel passiert ist, höchstens ein paar Minuten. Hätten meine Proxmox Server irgendeine Form von CBT, müsste ich meine Backups nicht über Nacht laufen lassen, sondern könnte wahrscheinlich alle 30 Minuten ein Backup ziehen.

Lange Rede, kurzer Sinn: Wenn ich diesen Thread noch richtig in Erinnerung habe, basieren die beschriebenen Probleme eigentlich immer darauf, dass PBS zu lange für Phase 1 braucht. Und es wäre das absolute Killer-Feature, wenn PBS eine CBT Lösung mitbringen würde, oder auf eine andere Art schafft Phase 1 deutlich zu verkürzen.

 

[ahofmann]

Eine Alternative zu CBT sind ja ZFS Snapshots. Das ist CBT direkt im Dateisystem. Das wäre vielleicht ein Weg, den PBS gehen könnte und den ganzen „Snapshot anlegen, warten, neuen Snapshot anlegen, Differenz davon sichern“ Tanz automatisieren. Für mich wäre das das ultimative Backup-System, dass fast alle Unzulänglichkeiten der heutigen Backup-Lösungen für Linux ausgleichen würde. Ein bisschen tricky ist da der Restore von einzelnen Dateien, aber wenn ich es richtig im Hinterkopf habe, könnte man Snapshots auf dem Backup-Host „mergen“ und hätte so eine konsistente Sicht auf das gesicherte Dateisystem.

 

[imadevel]

Das Problem hier ist, dass jede Backuplösung, die Dir zur Verfügung steht, kein CBT unterstützt. [...]

Beim Backup gibt es ja grob gesagt drei Phasen:

1. checken was gesichert werden muss

[...]
Und dann gibt es noch Backupprogramme, die CBT https://www.storage-insider.de/was-ist-change-block-tracking-cbt-a-949639/ nutzen. Die haben den Vorteil, dass Phase 1 komplett anders aussieht und in bestimmten Fällen enorme Zeitersparnis bringt. [...]

Lange Rede, kurzer Sinn: Wenn ich diesen Thread noch richtig in Erinnerung habe, basieren die beschriebenen Probleme eigentlich immer darauf, dass PBS zu lange für Phase 1 braucht. Und es wäre das absolute Killer-Feature, wenn PBS eine CBT Lösung mitbringen würde, oder auf eine andere Art schafft Phase 1 deutlich zu verkürzen.

Ja, wenn man - ZFS etc. - weiß, welche Blocks sich geändert haben, ist das Leben definitiv einfacher. Alle mir bekannten Dateisysteme, die CBT unterstützen, sind jedoch COW-Dateisysteme mit den Damit verbundenen Nach-(und auch Vor-)teilen. Sie wissen aber alle nicht direkt, welche Blöcke einer Datei sich verändert haben (kann sicherlich ermittelt werden, spucken die aber nicht direkt aus und haben vor allem keine allgemeingültige Schnittstelle, in die ein Backupsystem wie PBS einhaken könnte). Man könnte also sicherlich ein schnelles PBS-Backup für z. B. ZFS programmieren (wir haben mit einer Datensicherung mit Snapshots vie ZFS-Send und -Receive sehr gute Erfahrungen gemacht), aber dann hängt man an z. B. ZFS fest. Prima bei SSD-Arrays, eine Katastrophe mit drehenden Platten (trotz bcache etc.).
Meine Idee war daher, analog der Möglichkeiten von rsync, einzustellen, dass den Änderungsdaten des Dateisystems vertraut wird, also Dateien, die im Dateisystem als unverändert gelten, auch als real unverändert anzusehen. Bei Dateisystemen, auf denen sich keine Datenbanken etc. befinden (also zur reine "Dateiablagen"), sollten da keine Verluste auftreten. Das Backupprogramm muss sich dann zwar durchs Dateisystem durchhangeln und bei jeder Datei die Metadaten ansehen, aber nicht die Dateien blockweise vergleichen. Sicherlich langsamer als CBT, aber schneller als die ganzen Platten zu lesen. Wenn ich rsync als Beispiel nehme: Der Vergleich der Prüfungszeit mit und ohne "--checksum" ist schon erheblich.