BorgBackup 2.0 unterstützt Rclone – zusätzliche Unterstützung für mehr als 70 Cloud-Anbieter neben SSH
(borgbackup.readthedocs.io)- Beta 2.0.0b11 ist ausschließlich zum Testen neuer Repositories gedacht und nicht für den Produktionseinsatz geeignet
- Borg 2.0 ist ein Breaking Release, das nicht mit bestehenden Repositories kompatibel ist. Um Archive aus Borg-1.2-/1.4-Repositories in ein neues Borg-2.0-Repository zu verschieben, muss
borg transferverwendet werden - Vor der Nutzung von
borg transferist ein Upgrade aufborg >= 1.2.6oder auf eine Borg-Version mit Fix fürCVE-2023-36811erforderlich; außerdem müssen die Upgrade-Anweisungen zu Manifest und Archive-TAM befolgt werden - Unterstützung für
rclone://-URLs zu Borg-Repositories hinzugefügt; damit können Amazon S3, Backblaze B2, Ceph, Dropbox, Google Cloud Storage, Google Drive, Microsoft Azure, Microsoft OneDrive, OpenStack Swift, sftp, SMB/CIFS, WebDAV und mehr als 70 Cloud-Storage-Produkte genutzt werden - Unterstützung für parallele Vorgänge auf demselben Repository desselben Clients
- Funktion Archive series hinzugefügt:
NAMEidentifiziert die Serie gleichnamiger Archive, ein bestimmtes einzelnes Archiv wird mitaid:<archive hash>identifiziert - Durch Änderungen an der Kommandozeilen-Syntax müssen Skripte und Wrapper angepasst werden: Repositories werden normalerweise mit
BORG_REPOoderborg -r <MYREPO> <COMMAND>angegeben, das Formatrepo::archivewird nicht verwendet - Repository-Syntax im scp-Stil entfernt; stattdessen muss eine
ssh://-URL verwendet werden - Einige Befehle, die sowohl für Repositories als auch Archive galten, wurden getrennt oder umbenannt:
borg initheißt jetztborg repo-create, Repository-Operationen verwendenborg repo-*, Archiv-Operationenborg create NAME,borg list ID,borg extract IDusw. --glob-archiveswurde in--match-archivesumbenannt; unterstützt die Musterstileid:,sh:undre:, Standard ist die exakte Zeichenkettenübereinstimmungid:- Durch die Nutzung von
platformdirs 3.x.xwerdenXDG_*_HOMEunter macOS und Windows nicht angewendet; das Standardverzeichnis für config/cache unter macOS wurde auf~/Library/Application Support/borg/geändert --remote-ratelimit,--numeric-owner,--nobsdflags,--noatime,--save-space,--bypass-lockundborg configwurden entfernt- Die gleichzeitige Nutzung von
--listund--progressist verboten, außer bei--log-json - Performance von
borg checkundcompactauf Repositories mit hoher Latenz verbessert, da unnötigerepository.list()-Aufrufe entfernt wurden; durch einen Chunks-Index-Cache im Repository wurde außerdem die Performance der meisten Befehle auf solchen Repositories gegenüber b10 verbessert - Seltener Race Condition mit möglichem Datenverlust im Datei-Cache behoben
- Datei-Cache-Einträge enthalten nun sowohl
ctimeals auchmtime, und der Datei-Cache kann aus dem vorherigen Archiv derselben Archive series rekonstruiert werden - Datei-Caches werden pro Archive series getrennt, wodurch der RAM-Verbrauch sinkt
- Doppelte Angabe einiger bedeutungsloser Optionen ist nun verboten, wodurch zuvor funktionierende Skripte fehlschlagen können
1 Kommentare
Meinungen auf Hacker News
Ich nutze BorgBackup und bin ziemlich zufrieden damit.
Es war praktisch einrichten und vergessen, und auch 7 Jahre später laufen die deduplizierten Backups jede Woche problemlos.
Ich empfehle die Nutzung zusammen mit borgmatic, das die Komplexität interner Borg-Backups reduziert: https://github.com/borgmatic-collective/borgmatic
https://vorta.borgbase.com/
Deshalb tendiere ich zunehmend zu rsync oder Tools mit GUI-Frontend.
Derzeit sichere ich einfach nur mit rclone auf meine Remote-Maschine, aber das ist eindeutig keine professionelle Lösung.
Ich hatte überlegt, Backblaze B2 als externes Ziel hinzuzufügen, aber nur rclone zu verwenden wirkt nicht gerade wie ein moderner Backup-Ansatz.
rclone ist streng genommen kein Backup-Tool, und obwohl es Verschlüsselung bietet, ist sie etwas grob.
Ein richtiges Backup-Tool sollte die Daten in Blöcke geeigneter Größe aufteilen, bei Bedarf Verzeichnisse als tar bündeln, um Links zu erhalten, statt sie passend zur S3/B2-API einfach unverändert als einzelne Dateien abzulegen, und lange etablierte Best Practices wie Deduplizierung abdecken.
Ich frage mich, ob es empfehlenswerte Tools gibt.
restic und duplicati habe ich kurz angesehen, aber sie waren nicht so einfach, wie ich es von dedizierten Backup-Tools erwarten würde.
Eine GUI brauche ich nicht und will sie eher nicht; schön wäre, wenn die gesamte Konfiguration in einer einzigen Konfigurationsdatei läge, die ich wie andere Daten an einem separaten Ort sichern und auf einer neuen Maschine reproduzieren kann.
Das größere Problem ist, dass ich beängstigende Berichte gesehen habe, in denen solche Tools den Index beschädigt haben und Daten nicht mehr wiederherstellbar waren; bei einem Backup-Tool ist das ein Kernbereich, in dem so etwas unter keinen Umständen passieren darf, daher fällt mir das schwer zu akzeptieren.
Es erfüllt eine ähnliche Rolle wie restic, aber die Art, wie es mit Konfiguration umgeht, könnte dir besser gefallen.
Zusätzlicher Hinweis: https://news.ycombinator.com/item?id=34154052
duplicati sollte man lieber gar nicht erst versuchen.
Ich habe es mehrfach ernsthaft einsetzen wollen, bin aber immer an Bugs gescheitert; umso bedauerlicher, weil mir das Interface gefällt.
Inzwischen habe ich meinen Heimserver auf vernünftige Hardware aufgerüstet, aber bupstash läuft im Allgemeinen besser, also bin ich dabei geblieben.
Man sollte allerdings berücksichtigen, dass das letzte Release 2 Jahre zurückliegt und der Autor es noch als Beta markiert.
Trotzdem scheinen mir die Qualitätsansprüche des Autors höher zu sein als bei anderen Projekten, die „nicht Beta“ sind.
Nützlicher Vergleich von Backup-Tools: https://github.com/deajan/backup-bench
Ich empfehle, dem Quickstart in der Dokumentation zu folgen.
Es unterstützt Deduplizierung und Verschlüsselung und hat viel mehr Funktionen, aber wenn man sie nicht braucht, muss man sie nicht verwenden.
Ich nutze es zusammen mit borgmatic, um Backup- und Disaster-Recovery-Abläufe aufzusetzen, die das Risiko von Datenverlust verringern.
borgbase ist ebenfalls ein guter Dienst, aber wenn man die Zusatzfunktionen von borgbase nicht braucht, kann es günstiger sein, mit der rclone-Unterstützung etwas wie B2 zu verwenden.
Ich nutze es schon ziemlich lange sowohl für persönliche Projekte als auch für bezahlte Arbeit, und meine Erfahrungen waren gut.
Borg 2 ist noch Beta, und Kopia befindet sich in einer ähnlichen Position.
Kopia ist das neuere Tool, daher teste ich es in einem separaten redundanten Backup auf derselben Maschine; da Platz vorhanden ist, gibt es keinen Grund, es nicht zu tun.
Gelegentlich lasse ich eine Integritätsprüfung inklusive Daten laufen, damit ich darauf vertrauen kann, dass Metadaten und Daten in Ordnung sind.
Die „Konfigurationsdatei“ ist in Wirklichkeit ein Shell-Skript, das Umgebungen wie den Repository-Ort setzt, die gewünschten Backups ausführt und prune-Befehle gemäß der Aufbewahrungsrichtlinie startet.
Diese Konfiguration nutze ich seit Jahren erfolgreich.
Eine vollständige Wiederherstellung habe ich nie gemacht, aber die Wiederherstellung einzelner Dateien und Verzeichnisse war problemlos.
Ich frage mich, ob es Links zu Problemen mit Indexbeschädigung gibt.
Selbst erlebt habe ich es nicht, aber eine einzelne Stichprobe ist natürlich nicht besonders aussagekräftig.
Ich wollte schon lange ein rclone-Backend für Borg bauen.
In v1 war die Backend-Abstraktion aber nicht gut genug, sodass es nicht einfach zu bauen war.
In v2 hat Thomas Waldmann eine brauchbare abstrakte Schnittstelle geschaffen, und der rclone-Code umfasst weniger als 300 Zeilen Python, sodass man das an ein oder zwei Nachmittagen bauen konnte.
https://github.com/borgbackup/borgstore/blob/master/src/borg...
Sehr interessant.
Besonders mit der zunehmenden Beliebtheit von Object Storage und sinkenden Kosten war das eine lange gewünschte Funktion.
Dass Borg mit Object Storage arbeitet, wurde offiziell nicht unterstützt, aber einige nutzten es so.
Soweit ich es verstehe, haben die meisten das Repository eher repliziert und anschließend hochgeladen, statt Borg direkt darauf zugreifen oder es verändern zu lassen; wenn das Quell-Repository beschädigt ist, kann diese Beschädigung allerdings mitrepliziert werden, was problematisch ist.
Mit dieser Unterstützung dürfte es deutlich einfacher werden und die Workflows vereinfachen.
Sich für rclone-Unterstützung statt für einen bestimmten Dienst zu entscheiden, wirkt wie die klügere und zukunftssicherere Wahl.
Verwandte Beiträge
Borg 2.0 beta (deduplicating backup program with compression and encryption) - https://news.ycombinator.com/item?id=40990425 - Juli 2024
Borgctl – borgbackup without bash scripts - https://news.ycombinator.com/item?id=39289656 - Februar 2024
BorgBackup: Deduplicating archiver with compression and encryption - https://news.ycombinator.com/item?id=34152369 - Dezember 2022
Emborg – Front-End to Borg Backup - https://news.ycombinator.com/item?id=30035308 - Januar 2022
Deduplicating Archiver with Compression and Encryption - https://news.ycombinator.com/item?id=27939412 - Juli 2021
BorgBackup: Deduplicating Archiver - https://news.ycombinator.com/item?id=21642364 - November 2019
Borg – Deduplicated backup with compression and authenticated encryption - https://news.ycombinator.com/item?id=13149759 - Dezember 2016
BorgBackup (short: Borg) is a deduplicating backup program - https://news.ycombinator.com/item?id=11192209 - Februar 2016
Ich frage mich, ob es einen aktuellen Vergleich von Borg und Restic gibt oder ob es überzeugende Gründe gibt, von Restic zu Borg zu wechseln.
Früher habe ich Borg genutzt, aber dass man außer lokalen Dateien oder ssh keine anderen Backends verwenden konnte, war ein Problem.
Etwa als Restic anfing, Kompression zu unterstützen, bin ich zu Restic gewechselt.
Für meinen Anwendungsfall, mehrere Server auf S3-kompatible Storage-Anbieter zu sichern, wirken Restic und Borg inzwischen nahezu gleichwertig.
Ich möchte nichts reparieren, was nicht kaputt ist, wüsste aber auch gern, was mir mit Restic im Vergleich zu Borg entgeht.
Nur so passieren Backups dann auch wirklich.
Es fühlt sich auch weniger so an, als würde es sich ständig ändern; bei einer Backup-Lösung wollte ich nie einen dauernden Strom neuer Features.
Wenn man günstigen Online-Backup-Speicher sucht, sollte man wissen, dass ein Microsoft 365 Single-Abo 1 TB OneDrive enthält.
Beim Family-Abo sind es 1 TB pro Person.
Ich nutze seit Jahren erfolgreich restic + rclone dafür.
Es ist nicht schnell, aber es funktioniert.
1 TB per SSH erreichbarer Speicher für 4 Euro im Monat ist schwer zu schlagen.
Ich frage mich, ab wann man für den privaten Gebrauch Borg statt einfachem rsync empfehlen würde.
Derzeit sichere ich ein paar Verzeichnisbäume von einem Laufwerk per rsync auf ein anderes Laufwerk und zu einem entfernten Dienst (rsync.net).
Das funktioniert gut, aber ich bin mir nicht sicher, ob meine Nutzung einfach genug ist, dass diese Lösung ausreicht, oder ob ich große Vorteile von Borg verpasse.
Die Verschlüsselung von Borg ist reizvoll, aber die Komplexität eines neuen Tools und die Sorge, vielleicht meine Daten kaputtzumachen, halten mich vom Wechsel ab.
Die zu sichernden Daten liegen derzeit bei etwa 5 TB, also nicht extrem viel.
Bei meinem Mail-Backup entsprechen 17 Backups der letzten 6 Monate ursprünglich 837 GB, nach Kompression 312 GB und nach Deduplizierung 19 GB.
Postgres schrumpft ebenfalls von 25 GB auf 7 GB und dann weiter auf 900 MB.
Beim Mail-Backup ließe sich mit Hardlinks in rsync zwar auch Platz sparen, aber ich weiß nicht, ob es ohne zusätzliche Handarbeit so klein würde.
Mehrere Snapshots zu haben, ist sehr wichtig.
Auch Materialien wie http://www.taobackup.com/ sind einen Blick wert.
rsync ist bei vielen Dateien sehr langsam und kann auch umbenannte Dateien nicht erkennen, sodass sie erneut übertragen werden.
Mit Borg kann man alle erstellten Backups sehen und zu einem gewünschten Zeitpunkt eines früheren Snapshots zurückkehren.
Das ist ein Vorteil, der auch für viele andere Backup-Lösungen gilt.
Konkret: Wenn man versehentlich eine Datei gelöscht hat und dieser Zustand per rsync übertragen wurde, kann man die Datei aus diesem Backup nicht wiederherstellen.
Mit Borg geht das.
Ich frage mich, ob es Gründe gibt, Borg-Verschlüsselung statt rclone crypt zu verwenden – oder umgekehrt
Es ist ein Tool zum Kopieren von Dateien von einer Maschine auf eine andere; in diesem Fall werden sie vor dem Kopieren verschlüsselt
Es ist eher wie rsync für die Nutzung mit der Cloud
Borg ist eine andere Art von Tool für Backups
Es dedupliziert, verschlüsselt, snapshotet, prüfsummiert und komprimiert ein Quellverzeichnis in ein einzelnes Repository
Es arbeitet nicht auf Dateiebene, sondern auf Ebene von Datenblöcken
Es enthält auch Befehle zur Repository-Verwaltung, mit denen man Daten durchsuchen, Snapshots bereinigen oder zusammenführen usw. kann
Anschließend kann man Tools wie rsync/SSH oder rclone verwenden, um das Repository an einen beliebigen Ort zu übertragen oder zu synchronisieren
Da rclone jetzt nativ unterstützt wird, muss man das Repository nicht mehr sowohl lokal als auch remote vorhalten, sondern kann direkt auf ein Remote-Ziel sichern
Ich würde gern wissen, wie sie sich in Bezug auf Effizienz und Verschlüsselung unterscheiden
Ich habe mir rsync.net angesehen, fand es aber schade, dass es keine vernünftige Art von Verschlüsselung unterstützt
Ich nutze seit Jahren Borg-Backups auf rsync.net und bin zufrieden
Es unterstützt die Funktion, Borg per force-command in der ssh-Session zu erzwingen, und Borg hat eine Option, mit der sich Löschungen verhindern lassen, selbst wenn der Backup-ssh-Schlüssel kompromittiert wird
Insgesamt ist es eine robuste Lösung, ohne dass die Einrichtung besonders schmerzhaft wäre
Wie gesagt: Mit erzwungenem Kommando ist das bei rsync.net möglich, und die Snapshots von rsync.net sind ebenfalls ein Schutz gegen versehentliches falsches Löschen