4 Punkte von GN⁺ 2024-10-02 | 1 Kommentare | Auf WhatsApp teilen
  • 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 transfer verwendet werden
  • Vor der Nutzung von borg transfer ist ein Upgrade auf borg >= 1.2.6 oder auf eine Borg-Version mit Fix für CVE-2023-36811 erforderlich; 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: NAME identifiziert die Serie gleichnamiger Archive, ein bestimmtes einzelnes Archiv wird mit aid:<archive hash> identifiziert
  • Durch Änderungen an der Kommandozeilen-Syntax müssen Skripte und Wrapper angepasst werden: Repositories werden normalerweise mit BORG_REPO oder borg -r <MYREPO> <COMMAND> angegeben, das Format repo::archive wird 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 init heißt jetzt borg repo-create, Repository-Operationen verwenden borg repo-*, Archiv-Operationen borg create NAME, borg list ID, borg extract ID usw.
  • --glob-archives wurde in --match-archives umbenannt; unterstützt die Musterstile id:, sh: und re:, Standard ist die exakte Zeichenkettenübereinstimmung id:
  • Durch die Nutzung von platformdirs 3.x.x werden XDG_*_HOME unter 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-lock und borg config wurden entfernt
  • Die gleichzeitige Nutzung von --list und --progress ist verboten, außer bei --log-json
  • Performance von borg check und compact auf Repositories mit hoher Latenz verbessert, da unnötige repository.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 ctime als auch mtime, 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

 
GN⁺ 2024-10-02
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

    • Wenn man eine Desktop-Umgebung nutzt und eine GUI bevorzugt, passt Vorta ebenfalls gut.
      https://vorta.borgbase.com/
    • Solche Tools lernt man, richtet sie ein und vergisst sie dann wirklich; später ist es lästig, sich wieder einzuarbeiten, sodass man die Backup-Verifizierung eher vermeidet.
      Deshalb tendiere ich zunehmend zu rsync oder Tools mit GUI-Frontend.
    • Wenn „eingerichtet und vergessen“ 7 Jahre bedeutet, hoffe ich, dass gelegentlich eine Überprüfung der Backup-Wiederherstellung gemacht wird.
    • Ich frage mich, ob es einen brauchbaren Android-Client gibt.
  • 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.

    • Wenn du die Konfiguration wie eine einzelne Datei behandeln willst, lohnt sich ein Blick auf kopia.
      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.
    • Nachdem ich versucht hatte, auf einem rpi Backups zu machen, und Borg dabei als viel zu langsam zum Benutzen empfand, nutze ich bupstash.
      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
    • Ob es einfach ist, hängt vom Anwendungsfall ab, aber borg war hervorragend.
      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.
    • Ich nutze die Kombination restic + autorestic/resticprofile.
      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.
    • Ich bin sehr zufrieden damit, mit Restic nach BackBlaze B2 zu sichern.
      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.

    • Ich bevorzuge restic, weil es leichter zu verstehen und zu benutzen ist.
      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.

    • Auch das storage box-Angebot von Hetzner ist einen Blick wert.
      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.

    • In meinem Fall sparen Deduplizierung und Kompression enorm viel Speicherplatz.
      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.
    • Ein häufiges Problem ist: Wenn man eine Datei löscht oder beschädigt und es erst zwei Tage später bemerkt, hilft ein tägliches Backup nicht.
      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 rsync repliziert man nur den letzten Zustand.
      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

    1. https://borgbackup.readthedocs.io/en/2.0.0b11/quickstart.htm...
    2. https://rclone.org/crypt/
    • rclone crypt hat mit Borg nicht viel zu tun
      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
    • Mich interessiert auch der Unterschied zwischen diesem Paket und Restic
      Ich würde gern wissen, wie sie sich in Bezug auf Effizienz und Verschlüsselung unterscheiden
    • Ich frage mich, wie gut Deduplizierung bei aktivierter Verschlüsselung funktioniert
      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

    • Ich war auf der Suche nach einer Lösung, die verhindert, dass ein kompromittierter Host seine eigenen Backups löscht
      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