StoreBackup vs. BorgBackup

[Celica]

Bisher haben mir die eingeschränkten User Rechte ausgereicht. Damit konnte ich alles für mich wichtige sichern.
Allerdings gibt es nur root und den User, also eine friedliche Koexistenz.
Geht das über den User hinaus, dann musst du bei StoreBackup auch mit root Rechten sichern.

Warum nutzt du Borg?

[MegaV0lt]

Ich habe früher rsync verwendet und Dateien der letzten 30 Tage behalten.

Jetzt mit Borg Behalte ich Dateien biz zu einem Jahr!

Unterschied ist deutlich weniger Plattenverbrauch mit Borg.
Außerdem ist es auch viel schneller. Eine Sicherung von / auf meinem Server dauert keine Minute

Code: Alles auswählen

==> Belegung von /mnt/ST32000542AS/_Backup/MCP-Server/root_fs:
16G	/mnt/ST32000542AS/_Backup/MCP-Server/root_fs
16G	/mnt/ST32000542AS/_Backup/MCP-Server/root_fs/borg_repository/

==> Ausführungszeiten:
Skriptlaufzeit: 0 Minute(n) und 59 Sekunde(n)
  Sicherung: 0 Minute(n) und 59 Sekunde(n)
  Erstellen des Mailberichts: 0 Minute(n) und 0 Sekunde(n)

[MSfree]

Ich habe früher rsync verwendet und Dateien der letzten 30 Tage behalten.

Ich nutze rsync. Aber warum nur 30 Tage? Ich habe dank Hardlinks mit rsync im Moment 1326 Vollbackups auf meiner Backupkiste.

Jetzt mit Borg Behalte ich Dateien biz zu einem Jahr!

Siehe oben, ich habe mehr als 3.5 Jahre Backuphistory mit rsync. Das ist also kein Alleinstellungsmerkmal von Barg.

Unterschied ist deutlich weniger Plattenverbrauch mit Borg.

Wirklich? OK, Borg komprimiert das Backup noch, aber das könnte man auch mit einem geeigneten Dateisystem bekommen, z.B. unterstützt btrfs Kompression, was den Datenumfang grob geschätzt etwas mehr als halbiert.

Außerdem ist es auch viel schneller. Eine Sicherung von / auf meinem Server dauert keine Minute

Solche Zeitangaben sind einigermassen sinnlos, wenn Angaben wie Anzahl der Datein, Anzahl der geänderten und zu übertragenden Dateien und das dabei entstehende Übertragungs- und Schreibvolumen zu nennen. Bei mir sind es über ein Millionen Dateien und 2.2TB Volumen, die täglich mit rsync gesichert werden. Typischerweise entsteht dabei ein Übertragungsvolumen von 15GB, was etwa 20 Minuten dauert.

==> Belegung von /mnt/ST32000542AS/_Backup/MCP-Server/root_fs:
16G /mnt/ST32000542AS/_Backup/MCP-Server/root_fs
16G /mnt/ST32000542AS/_Backup/MCP-Server/root_fs/borg_repository/
==> Ausführungszeiten:
Skriptlaufzeit: 0 Minute(n) und 59 Sekunde(n)
Sicherung: 0 Minute(n) und 59 Sekunde(n)
Erstellen des Mailberichts: 0 Minute(n) und 0 Sekunde(n)[/code]

Eine Minute für ein Volumen von 16GB,von denen sicherlich nicht mehr als 1.5Gb geändert wurden, würde ich nicht als ausgesprochen schnell bezeichnen.

[MegaV0lt]

Ich benötige keine zig tausend Backupsätze. Mein Calc-Dokument von 1995 benötige ich sicher nie mehr. Ich bin hier nur im privaten Bereich unterwegs und sichere meine PC's, Handy's, Laptops, VDR und auch den Server.

Ist eine Glaubensfrage so wie es aussieht. Warum nicht einfach mal selber testen? Ich bin so zu Borg gekommen, nach dem ich einiges ausprobiert hatte. Für mich ist Borg eben dank Komprimierung und Deduplizierung "besser". Und btrfs habe ich auch getestet. Wurde am selben Tag noch entfernt. War viel zu langsam; und die Hardware ist jetzt nicht so uralt:

Code: Alles auswählen

[~] # inxi -c
CPU: Quad Core Intel Core i5-4570 (-MCP-) speed/min/max: 942/800/3600 MHz Kernel: 5.10.0-21-amd64 x86_64 Up: 39d 23h 39m 
Mem: 2500.8/7840.3 MiB (31.9%) Storage: 2.27 TiB (36.3% used) Procs: 162 Shell: Bash inxi: 3.3.01 

Im Beispiel von Oben sieht man ja, dass die Sicherung mit Borg statt 215 GB nur 16 GB belegt. Mit Komprimierung allein geht das nicht.

[cosinus]

Ist eine Glaubensfrage so wie es aussieht.

Du willst aber keinen Glaubenskrieg anzetteln?
Ich finde es ist in Ordnung, wenn du Borg benutzt. Hauptsache du machst dir Gedanken um die Datensicherung, die auch funktioniert. Zuhause bevorzuge ich aber auch rsync und aus kleineren Verzeichnissen macht ich auch gerne mal tar und/oder sqfs Archive.

[MSfree]

Für mich ist Borg eben dank Komprimierung und Deduplizierung "besser".

Im Beispiel von Oben sieht man ja, dass die Sicherung mit Borg statt 215 GB nur 16 GB belegt. Mit Komprimierung allein geht das nicht.

Deduplizierung macht rsync doch auch. Und bei mir benötigt das 2.2TB Backup typischerweise 10-15GB, da sind aber auch Tage dabei, wo nur 2GB gesichert werden müssen, genauso wie es Tage gibt, be denen 25GB entstehen.

Kompression bringt auch nur dann etwas, wenn die Dateien sich auch komprimieren lassen. Debianpakete, JPG-Bilder, ZIP-Dateien, Filme... sind bereist komprimiert und lassen sich nicht weiter eindampfen, so daß Kompression in diesen Fällen sogar kontraproduktiv wäre.

Warum ich 1326 Backups habe? Bei nur 15GB/Tag und 40TB Backupkapazität, warum nicht?

Ich sehe ehrlicherweise keinen Grund, an der Methode etwas zu ändern.

[MegaV0lt]

So der riesige Unterschied besteht ja nicht zwischen Borg und rsync. Wie schon gesagt wohl Geschmackssache.

Und die Anzahl der Backups ist auch eine Geldfrage. Klar, wenn 40 TB da sind, kann man auch mal ein paar tausend Backups pro Maschine speichern.

Ich habe beide Versionen meiner Skripte im Einsatz. Aber das rsync-Backup laüft nur noch auf einem Laptop

[chrbr]

Deduplizierung macht rsync doch auch.

Tatsächlich? Wie funktioniert das denn? Ich kannte Deduplizierung im Zusammenhang mit Dateisystemen wie ZFS, bei der identische Blöcke an Daten gesucht und letztendlich nur 1x physikalisch gespeichert werden.

Andererseits kopiert rsync nur Dateien, die auf dem Backup Ziel nicht vorhanden sind oder andere Eigenschaften wie die Größe nicht übereinstimmen.

Warum ich 1326 Backups habe? Bei nur 15GB/Tag und 40TB Backupkapazität, warum nicht?

Ich sehe ehrlicherweise keinen Grund, an der Methode etwas zu ändern.

Bei den Zahlen sehe ich das auch so.

[MSfree]

Tatsächlich? Wie funktioniert das denn? Ich kannte Deduplizierung im Zusammenhang mit Dateisystemen wie ZFS, bei der identische Blöcke an Daten gesucht und letztendlich nur 1x physikalisch gespeichert werden.

Das Urbackup muß natürlich erstmal vollstandig vorhanden sein. Das zweite und jedes folgenden Backup kann man mit Hardlinks auf die jeweils vorherige Version erzeugen. Dabei wird von der vorherigen Version die komplette Datei- und Verzeichnisstruktur als "Kopie" in einem Zielverzeichnis in Form von Hardlinks erzeugt. Anschließend wird diese Hardlinkversion mit der Datenquelle verglichen und das kopiert, was sich verändert hat. Die Hardlinks benötigen so gut wie keinen Platz, nur der Platz für die veränderten Dateien wird tatsächlich benöigt, wobei der Hardlink in diesen Fällen durch eine "echte" Datei ersetzt wird.

Siehe auch man rsync und dort die Option --link-dest=DIR

Einziger Vermutstropfen hier ist, daß rsync umbenannte und/oder verschobene Dateien nicht erkennt und somit keine Hardlinks erzeugen kann. Meiner Erfahrung nach ist das aber verschmerzbar, weil zumindest bei mir Dateien selten umbenannt oder in ein anderes Verzeichnis verschoben werden. Die paar MByte, die dadurch gelegentlich mal kopiert werden, sind nicht der Rede wert.

Ich benötige aber zum Wiederherstellen keine spezielle Software, da das Backup direkt im Dateisystem liegt und bei einzelnen Dateien simple mit cp zurückgeholt werden kann. Sollte es nötig sein, den kompletten Bestand zurückzuholen, ginge auch das mit cp -r aber auch mit rsync, scp ... Ich bin hier also nicht, wie im Falle von Borg, auf Borgbackup angewiesen.

[chrbr]

Hallo MSfree,
vielen Dank für die ausführliche Erklärung. Nach meinem jetzigen Verständnis wird die Deduplizierung also durch

• Erzeugung eines Directories für jedes Backup

• Verwendung von Hardlinks zu den Dateien bzw Hardlinks des vorherigen Directories

• Überschreiben der Hardlinks nur, wenn sich etwas geändert hat.

Damit hat man ja auch ganz einfach eine Versionierung mit erledigt, weil man ja Zugriff zu jedem vorherigen Backup hat.

Das könnte ich für mich auch mal überlegen. Ich sichere bisher auf FreeBSD mit ZFS. Dort mache ich ab und zu einen Snapshot. Dadurch habe ich eine etwas gröbere Versionierung, die mir bisher aber reicht. Wo es mir sinnvoll erscheint habe ich sowieso lokale git repositories, die mit gesichert werden.

Vielen Dank nochmal,
Christoph

[MSfree]

Nach meinem jetzigen Verständnis wird die Deduplizierung also durch

• Erzeugung eines Directories für jedes Backup

• Verwendung von Hardlinks zu den Dateien bzw Hardlinks des vorherigen Directories

• Überschreiben der Hardlinks nur, wenn sich etwas geändert hat.

Damit hat man ja auch ganz einfach eine Versionierung mit erledigt, weil man ja Zugriff zu jedem vorherigen Backup hat.

Richtig.

Ich sichere bisher auf FreeBSD mit ZFS. Dort mache ich ab und zu einen Snapshot. Dadurch habe ich eine etwas gröbere Versionierung, die mir bisher aber reicht.

Wie grob deine Versionierung ist, hängt ja nur davon ab, wie oft du Snapshots ziehst. Bei mir hängt es davon ab, wie häufig ich rsync aufrufe. Das passiert bei mir cron-gesteuert, so daß ich mich darum nicht kümmern muß und ich es auch nicht vergessen kann.

Aber wenn du ohnehin ZFS Snapshots nutzt, wird dir rsync keinen Zusatznutzen bieten, denn mittels Snapshots hast du ja auch Versionierung, History, Deduplizierung ... gelöst.

[Celica]

StoreBackup ist wohl raus
Eigentlich schon die ganze Zeit und ich wollte das nur nicht wahr haben
Im übrigen erzeugt SB auch eine Versionierung.
Bisher habe ich nichts gelesen was SB nicht auch kann, bis auf die Geschwindigkeit. Das müsste man mal tatsächlich testen.

[MegaV0lt]

Zumindest der Punkt ist wohl weder mit Borg oder rsync machbar:

Erkennen von identischen Dateien (Doubletten) in unterschiedlichen, unabhängigen Backups (z.B. von unterschiedlichen Rechnern)

[MSfree]

Zumindest der Punkt ist wohl weder mit Borg oder rsync machbar:

Erkennen von identischen Dateien (Doubletten) in unterschiedlichen, unabhängigen Backups (z.B. von unterschiedlichen Rechnern)

Ein Backup ist ein Backup.

Ein gemeinschaftlich genutzeter Ordner, der zwischen unterschidlichen Rechnern synchronisiert werden soll, ist nunmal ein gemeinschaftlich genutzeter Ordner.

Beides zu verheiraten, kann nicht Aufgabe eines Backups sein.

Man kann aber den geimschaftlich genutzten Ordner sichern

[anmith]

Hallo,

war hier - glaube ich - noch nicht genannt, aber BorgBackup dedupliziert nicht nur komplette Dateien, sondern teilt diese in sog. Chunks auf. Die Doku sagt:

Deduplication based on content-defined chunking is used to reduce the number of bytes stored: each file is split into a number of variable length chunks and only chunks that have never been seen before are added to the repository.
A chunk is considered duplicate if its id_hash value is identical. A cryptographically strong hash or MAC function is used as id_hash, e.g. (hmac-)sha256.

To deduplicate, all the chunks in the same repository are considered, no matter whether they come from different machines, from previous backups, from the same backup or even from the same single file.

Compared to other deduplication approaches, this method does NOT depend on:

* file/directory names staying the same: So you can move your stuff around without killing the deduplication, even between machines sharing a repo.
* complete files or time stamps staying the same: If a big file changes a little, only a few new chunks need to be stored - this is great for VMs or raw disks.
* The absolute position of a data chunk inside a file: Stuff may get shifted and will still be found by the deduplication algorithm.

[Celica]

Sehr gut.

Das eine ist "Ein Backup ist ein Backup" und das andere ist wie ein Backup erstellt wird.
Z.B. das Deduplizieren, komprimieren, ...was auch immer.

Ich halte auch erst einmal das Backup als solches für das wichtigste.
Dann der Restore wo funktionieren muss.
Am Ende das wie.

[MSfree]

das andere ist wie ein Backup erstellt wird.
Z.B. das Deduplizieren, komprimieren, ...was auch immer.

Deduplizierung spart jede Menge Platz. Man erkauft sich diese Ersparnis aber damit, daß das Backup selbst empfindlicher für Datenverlust wird. Ist nämlich die Urkopie einer Datei nicht mehr lesbar, sind auch alle weitere Deduplikate nicht mehr lesbar.

Die logische Konsequenz ist, daß man mindestens ein weiteres Backup braucht, eher sogar zwei, am besten noch mindestens eins an einem anderen Standort.

Dann der Restore wo funktionieren muss.

Ich geh sogar noch weiter, das Restore muß mit möglichst einfachen Mitteln funktionieren, also mit nicht viel mehr als einem Rettungssystem und deren Shell. Ich halte nichts von "Sondersoftware", die ggfls. nicht auf einem Rettungssysetm zur Verfügung steht. Eine Shell wie bash und der Kopierbefehl cp ist halt universell verfügbar.

[Celica]

Dann sind wir bei StoreBackup.
Ein Kriterium was ich seiner Zeit hatte: Keine extra Software für den Restore! Lediglich Boardmittel.

[nasenmann72]

Hallo Celica,

der Thread ist zwar schon ein paar Tage alt, aber ich möchte doch kurz anmerken, dass ich DER ANDERE Benutzer bin, der auch Storebackup nutzt.
Und ich musste vor gar nicht allzu langer Zeit ALLE meine Daten von meinen Backups rückspielen da meine TrueNAS Scale Instanz bei einem Synchronisationsjob "eigenwillig" meine ZFS-Datasets gelöscht hatte. Keine Ahnung, wie das genau passierte, ich konnte es nicht mehr nachstellen. Jedenfalls hatte ich das Löschen erst spät gemerkt und musste ungläubig dabei zusehen, wie meine Daten (mehrere TB Fotos, Musik, etc). nach und nach verschwanden. Aber dank des guten Storebackup von Heinz-Josef Claes konnte ich alle meine Daten wieder herstellen.
Ich habe mir aber zusätzlich noch ein Wrapper-Skript "drumrum" geschrieben, welches Buch führt über die durchgeführten Backups, also wann welches ZFS-Dataset auf welcher Backupplatte gesichert wurde. Somit behalte ich den Überlick, wo ich die neuesten Versionen meiner Daten finde.
Dass Storebackup scheinbar nicht weiter entwickelt wird, finde ich eigentlich nicht so dramatisch. Es funktioniert super und ab und an korrigiert der Heinz-Josef Claes auch doch noch einen kleinen Fehler. Also tot ist es noch nicht!
Ein GANZ wichtiges Kriterium ist für mich eben genau die Möglichkeit die Daten ohne Storebackup wieder herstellen zu können.

Viele Grüße

[Celica]

Hallo nasenmann72,

danke für die Info und den Zuspruch.
Ja, die Entwicklung scheint nicht mehr aktiv weiter zu gehen, aber wie du richtig gesagt hast: Alles funktioniert so wie es soll und das reicht mir auch aus.
Aktuell bleibe ich auch erst einmal dabei, da ich total zufrieden bin (hatte aber bisher noch nie den Worst Case!).

Hatte mit Heinz-Josef schon zwei oder dreimal Kontakt und der ist super nett und hilfsbereit.
Hätte mich sogar telefonisch supported. Wow sage ich da nur!

Für das was ich mache und sichern muss ich das alles drei mal gut und am Ende ist es doch so: Weniger womit du sicherst sondern vielmehr das du es tust

[Celica]

Hallo nasenmann72,

ich habe noch einmal ein wenig geluschert und bin bei Restic hängen geblieben, was ich auch sehr interessant finde.
Was aber die meisten im Vergleich zu StoreBackup nicht können: Restore mit Bordmitteln!
Wobei ein Restic Backup möglicherweise auch ohne Restic zurück gespielt werden kann, allerdings weniger als Restore von einzelnen Schnappschüssen.
Wäre auch mal einen Blick wert.

[juribel]

Hallo zusammen,

seit Jahr und Tag nutze ich rsync für die Datensicherung. Ich kann mich nur den Postings von msfree und seiner hervorragenden Erklärung von rsync anschliessen. Meine Meinung ist, ein "Backup", das zum Zurückkopieren eine unbeschädigte und vollständige Ursicherung und alle unbeschädigten und vollständigen Zwischensicherungen benötigt, ist kein Backup, es ist ein Datengrab und die Daten sind im Zweifelsfall "weg" gesichert. Wenn ich dann auch noch lese, dass manche Tools die Dateien in "Chunks" zerlegen, um Platz zu sparen, gruselt es mich vollends. Je komplizierter ein Sicherungsverfahren ist, desto schneller wird die Sicherung unbrauchbar. Und "Backup"-Lösungen, die zum Zurückspeichern das Sicherungstool benötigen, sind für mich persönlich ebenfalls ein absolutes No-go.

Mein Datenbestand liegt zwischen 500 und 600 GBytes, und eine Sicherung nimmt meistens weniger als 10 GBytes in Anspruch und dauert bei mir meistens weit weniger als eine Minute.

Die Grenzen von rsync liegen allerdings dort, wenn man z. B viele Maschinen, also Riesen-Dateien hat, in denen sich ständig etwas ändert. Die würde rsync jedes Mal in Gänze kopieren. Aber da kann man ja statt dessen in der virtuellen Maschine rsync anstossen und z. B. auf ein mit Samba angeschlossenes Laufwerk sichern.

[cosinus]

seit Jahr und Tag nutze ich rsync für die Datensicherung. Ich kann mich nur den Postings von msfree und seiner hervorragenden Erklärung von rsync anschliessen.

rsync ist echt gut. Ich mach damit auch Backups. (Zusätzlich erstelle ich Archivdateien von wichtigen Verzeichnissen)
Hab erst gestern weil ich Zeit hatte am Samstagabend mal wieder nen Restore-Test durchgeführt:

Ich mach einfach regelmäßig Backups, auch mit rsync. Gestern erst wieder probiert, hab mein gesamtes System mit rsync gesichert und weil ich Zeit hatte auch den Restore in eine VM getestet. Ist zwar nach dem Zurückkopieren etwas Fummelei mit mount hier, mount da, chroot dort und grub-install, aber: es klappt! Ich hab meine echte Maschine (ohne die 300-GB-Datenhalde) in eine VM geklont

[Celica]

Grundsätzlich gebe ich euch Recht.
Deswegen nutze ich nach wie vor StoreBackup.
Braucht kein Tool zum Restore und ist m.M.n. relativ einfach ohne viel Firlefanz.

Rsync nutze ich um mein /home auf das NAS zu syncen und als weitere Sicherung zu den SB Sicherungen.
Allerdings empfinde ich sowohl SB wie auch Rsync als relativ langsam.
Jedoch kann ich keinen wirklichen Vergleich ziehen.
Deswegen hatte ich Borg und Restic ins Spiel gebracht.

Jeder hat so seine eigene Philosophie und das ist auch gut so, vor allem aber interessant

[cosinus]

Allerdings empfinde ich sowohl SB wie auch Rsync als relativ langsam.

Das liegt meiner Meinung nach an vielen kleinen Dateien. Gestern hat mein Restore-Test auch recht lange gedauert, weil da sehr viele kleine Dateien bei sind. Und man sollte rsync nicht im verbose Modus aufrufen (auch --progress weglassen) sonst wird STDOUT zugemüllt was das ganze auch wieder verlangsamt

rsync an sich ist nicht langsam, wenn ich damit größere Dateien übers Netzwerk wegsichere hab ich stabile Datenraten von 110 MB/s, also 1 GBit voll ausgelastet, auch bei großen Dateien auf eine USB3-Disk hab ich tw. 200 MB/s