ubuntuusers.de

Wahl einer Backup-Software

Status: Ungelöst | Ubuntu-Version: Ubuntu 20.04 (Focal Fossa)
Antworten |

fork991

Anmeldungsdatum:
26. Mai 2010

Beiträge: 58

Off-Topic

Ich nutze beruflich BackupPC. Das skaliert wesentlich besser als Borg, da Borg nur innerhalb eines Archivs dedupliziert und außerdem das Archiv bei Benutzung durch einen Host sperrt. Die Deduplikation von BackupPC dagegen funktioniert auf Pool-Ebene aller Hosts, so dass ich da auf einen realen Speicherplatzverbrauch von üblicherweise 6% vor Kompression und Deduplizierung komme. D. h. die Backups benötigen vor Kompression und Deduplizierung z. B. ca. 135 TB und der tatsächlich benötigte Plattenplatz beträgt nur 8 TB).

Außerdem finde ich bei einem Netzwerkbackupsystem eine Clientseitige Konfiguration - wie bei Borg - unbrauchbar. Auch bzgl. des Themas Sicherheit. D. h. der Client kann sein Backup selbst verändern - wegen Push- statt Pull-Konzeption. Das ist nicht gut. Ja. Borg kann auch irgendwie Pull-Backup. Aber in einer maximal komplizierten Weise, die ich mir nie im Leben ans Bein binden wollen würde.

Aber die BackupPC-Vorteile/Borg-Nachteile sind kaum relevant für den vorliegenden Fall.

Weitere Alternative wäre noch Bareos (Bacula Fork) - ebenso nicht relevant für den vorliegenden Fall. Das dedupliziert allerdings auch nur auf Hostebene.

On-Topic

Bzgl. Restic wäre es interessant ein paar Erfahrungen zu lesen, die jemand damit gemacht hat. Von der Konzeption scheint es aber borg sehr ähnlich zu sein.

Aufschlussreicher Artikel zum Thema: Borg vs. Restic

https://stickleback.dk/borg-or-restic/

Kurzfassung

Restic

  • PRO: Kann auch eine poolweite Deduplizierung

  • PRO: Unterstützt sehr viele Speicherbackends

  • PRO: Kann gleichzeitig mehrere Rechner im gleichen Archiv sichern

  • CONTRA: Braucht viel RAM

  • CONTRA: Keine Unterstützung für Kompression (Kompression kann über das Dateisystem erledigt werden. Z. B. ZFS, aber das wäre für den Raspi eher ungeeignet, weil das wiederrum große RAM-Anforderungen hat.)

  • CONTRA: Aufräumarbeiten (Löschung alter Backups) dauern lang sperren das Archiv. D. h. während der Zeit sind keine Backups möglich.

Borg

  • PRO: Hohe Performance (Sowohl das Backup als auch die Aufräumarbeiten alter Backups aus dem Archiv laufen wesentlich schneller als bei Restic)

  • CONTRA: Keine simultan ausgeführten Backups pro Archiv möglich

  • CONTRA: Braucht SSH zum Speicherbackend

In dem Fall wäre also klar Borg das sinnvollere Programm. Restic ist durch seine vielen Speicherbackends interessant, wenn z. B. Daten in irgendeiner Form in der Cloud gespeichert werden sollen.

Ich habe selbst in einer Umgebung "Borgmatic" ein Frontend für Borg im Einsatz. Borgmatic vereinfacht den Umgang mit Borg nochmal etwas und kümmert sich automatisch Sachen wie Backuprotation umsetzt.

Moderiert von rklm:

Abgetrennt von diesem Thema.

rklm Team-Icon

Projektleitung

Anmeldungsdatum:
16. Oktober 2011

Beiträge: 13075

fork991 schrieb:

Ich nutze beruflich BackupPC. Das skaliert wesentlich besser als Borg, da Borg nur innerhalb eines Archivs dedupliziert und außerdem das Archiv bei Benutzung durch einen Host sperrt. Die Deduplikation von BackupPC dagegen funktioniert auf Pool-Ebene aller Hosts, so dass ich da auf einen realen Speicherplatzverbrauch von üblicherweise 6% vor Kompression und Deduplizierung komme. D. h. die Backups benötigen vor Kompression und Deduplizierung z. B. ca. 135 TB und der tatsächlich benötigte Plattenplatz beträgt nur 8 TB).

Interessant!

Aufschlussreicher Artikel zum Thema: Borg vs. Restic

https://stickleback.dk/borg-or-restic/

Kurzfassung

Danke für die Zusammenfassung!

Restic

  • CONTRA: Keine Unterstützung für Kompression (Kompression kann über das Dateisystem erledigt werden. Z. B. ZFS, aber das wäre für den Raspi eher ungeeignet, weil das wiederrum große RAM-Anforderungen hat.)

Btrfs unterstützt auch Komprimierung.

  • CONTRA: Aufräumarbeiten (Löschung alter Backups) dauern lang sperren das Archiv. D. h. während der Zeit sind keine Backups möglich.

Borg

  • CONTRA: Braucht SSH zum Speicherbackend

Wieso ist das ein Nachteil? Was brauchen denn Restic und BackupPC auf der entfernten Seite? sshd erscheint mir eine recht geringe Anforderung.

Restic ist durch seine vielen Speicherbackends interessant, wenn z. B. Daten in irgendeiner Form in der Cloud gespeichert werden sollen.

Es gibt auch Cloud-Angebote für Borg, so dass Backups in die Cloud auch kein Problem sind. Selbst eine VM aufsetzen geht natürlich auch.

Ich habe selbst in einer Umgebung "Borgmatic" ein Frontend für Borg im Einsatz. Borgmatic vereinfacht den Umgang mit Borg nochmal etwas und kümmert sich automatisch Sachen wie Backuprotation umsetzt.

Das ist doch mit einem Skipt auch sehr einfach zu lösen, weil borg prune dafür alles mitbringt. Was mehr gibt es da, wo Borgmatic hilft?

fork991

(Themenstarter)

Anmeldungsdatum:
26. Mai 2010

Beiträge: 58

rklm schrieb:

  • CONTRA: Keine Unterstützung für Kompression (Kompression kann über das Dateisystem erledigt werden. Z. B. ZFS, aber das wäre für den Raspi eher ungeeignet, weil das wiederrum große RAM-Anforderungen hat.)

Btrfs unterstützt auch Komprimierung.

Ich meine mal von anderen gelesen zu haben, dass die Kompression von Btrfs nicht so dolle sein soll. Wenn ich aber das hier ( https://btrfs.readthedocs.io/en/latest/Compression.html ) lese, dann scheint Kompression von Btrfs mittlerweile unproblematisch und leistungsfähig zu sein.

Borg

  • CONTRA: Braucht SSH zum Speicherbackend

Wieso ist das ein Nachteil? Was brauchen denn Restic und BackupPC auf der entfernten Seite? sshd erscheint mir eine recht geringe Anforderung.

Das ist der Gegenpart zum RESTIC-Vorteil "Unterstützt viele Speicherbackends". Borg braucht halt zwingend SSH.

Ich habe selbst in einer Umgebung "Borgmatic" ein Frontend für Borg im Einsatz. Borgmatic vereinfacht den Umgang mit Borg nochmal etwas und kümmert sich automatisch Sachen wie Backuprotation umsetzt.

Das ist doch mit einem Skipt auch sehr einfach zu lösen, weil borg prune dafür alles mitbringt. Was mehr gibt es da, wo Borgmatic hilft?

Natürlich kann ich mir ein Script basteln. Gleichzeitig ist "Borgmatic" so ein Script, was dann nur noch (einen) einzelne(n) Aufruf(e) zeitgesteuert in crontab / systemd-timer benötigt. Und es ist ein Script, das IMHO besser ist, als dass wass ich auch schnell zusammengehackt bekomme, wenn ich mir sogar einen ganzen Tag Zeit nehme dafür. Konkretisieren kann ich das aber leider nicht (mehr). Mir gefiel Borgmatic jedenfalls gleich sehr gut.

Restic ist durch seine vielen Speicherbackends interessant, wenn z. B. Daten in irgendeiner Form in der Cloud gespeichert werden sollen.

Es gibt auch Cloud-Angebote für Borg, so dass Backups in die Cloud auch kein Problem sind. Selbst eine VM aufsetzen geht natürlich auch.

Ja, gibt es. Z. B. die Hetzner Storage Box. Funktioniert auch gut. Das ändert aber nichts an der Tatsache, das Restic einfach viel mehr Speicherbackends unterstützt. Weiß der Geier, wann man so etwas mal braucht.

fork991

(Themenstarter)

Anmeldungsdatum:
26. Mai 2010

Beiträge: 58

Hier auch nochmal zwei Screenshots des Grafiken zum Speicherplatzverbrauch von BackupPC:

System 1) Langfristige Aufbewahrung

  • 112 Systeme, 7 inkrementelle Backupsätze, 24 Vollbackupsätze (20 x wöchentlich, 4 x ca. jährlich) pro System.

  • Gesparte Daten durch Kompression und Deduplizierung 93,4%

System 2) Kurzfristige Aufbewahrung

  • 72 Systeme, 7 inkrementelle Backupsätze, 5 Vollbackupsätze (2 x wöchentlich, 3 x monatlich) pro System.

  • Gesparte Daten durch Kompression und Deduplizierung: 60%

Bilder

fork991

(Themenstarter)

Anmeldungsdatum:
26. Mai 2010

Beiträge: 58

Was Borgmatic - Frontend für Borg - interessant macht:

  1. Es prüft die Datenintegrität der Archive, wenn konfiguriert

  2. Es kümmert sich um die Backupaufbewahrung und automatische Löschung

  3. Es erlaubt mehrere Backup-Archive für eine redundante Datensicherung

rklm Team-Icon

Projektleitung

Anmeldungsdatum:
16. Oktober 2011

Beiträge: 13075

fork991 schrieb:

Was Borgmatic - Frontend für Borg - interessant macht:

  1. Es prüft die Datenintegrität der Archive, wenn konfiguriert

  2. Es kümmert sich um die Backupaufbewahrung und automatische Löschung

  3. Es erlaubt mehrere Backup-Archive für eine redundante Datensicherung

Alles kein Problem mit einem Backup-Skript, das man für Borg sowieso haben sollte. Die Integritätsprüfung kann man u.U. auch ersetzten durch btrfs scrub, wenn man das Dateisystem für das Repo nutzt - unter der Annahme, dass es keine Bugs in der Software gibt, die die Integrität ruinieren.

Ich habe jetzt mal den Artikel gelesen. Damit habe ich ein Problem:

Borg and Restic both support pruning backups as they age, e.g. you could decide to keep hourly backups from the last 24 hours, daily backups from the last two weeks, the last 6 monthly backups, etc. With Borg this operation only takes a few moments to complete, but it can take several hours to prune a Restic repository (and a lot of memory). Worse, while Restic is completing the prune operation, it places an exclusive lock on the repository, making any attempts to backup to that repository fail. This is a significant limitation – especially if you backup multiple machines to the same repository.

Dass das Pruning so lange dauert, ist für mich ein Ausschlusskriterium. Bei mir läuft das nach jedem Backup, um die Größe des Archivs im Zaum zu halten. Das kann man nicht machen, wenn es Stunden dauert. Typischerweise dauert ein Borg-Backup von meinem Home (ca. 230GB) unter zwei Minuten.

fork991

(Themenstarter)

Anmeldungsdatum:
26. Mai 2010

Beiträge: 58

Nachtrag:

Bzgl. der Performance sehe ich sowohl BorgBackup als auch BackupPC 4 auf einem ähnlichen Level. BorgBackup würde ich bzgl. einer Implementierung von besserer Codequalität einschätzen. BackupPC 4 hat selbst auch auf der Serverseite eine eigene kompilierte Rsync-Implementierung. BackupPC kann grundsätzlich sehr performant mehrere gleichzeitige Backups gut handhaben. Wie viele genau, das hängt von der verwendeten Umgebung (Speicher + Netzwerk) ab.

Vom Einsatzzweck ist also der primäre Einsatzzweck von borg das Einzelsystem, während das für BackupPC als zentrales Netzwerkbackup für viele Systeme ist.

buhtz

Anmeldungsdatum:
28. September 2022

Beiträge: 28

Schon mal an Back In Time als elegantes rsync Front-End gedacht?

Antworten |