Wo liegen die Sicherungen?<\/h2>\n
F\u00fcr diese Entscheidung sollte zun\u00e4chst \u00fcberlegt werden, vor welchen konkreten Gefahren man sich sch\u00fctzen m\u00f6chte bzw. muss. Viele denken zun\u00e4chst an Hardwareausf\u00e4lle, was durchaus berechtigt ist. Doch es gibt noch weitere Gefahren, wie etwa:<\/p>\n
- \n
- Versehentliches L\u00f6schen oder zerst\u00f6ren von Dateien (z.B. durch Software- oder Bedienfehler)<\/li>\n
- Physische Sch\u00e4den (z.B. Feuer, Rohrbruch) und Naturkatastrophen<\/li>\n
- Entwendung\/Zerst\u00f6rung durch Dritte (etwa Laptop-Diebstahl oder Infektion mit Schadsoftware wie Ransomware)<\/li>\n
- Zugriffsverlust aus anderen Gr\u00fcnden: Dienstleister wird gehackt\/geht pleite\/sperrt das Konto usw.<\/li>\n<\/ul>\n
Die 3-2-1 Regel ist eine bew\u00e4hrte Strategie, um m\u00f6glichst vielen Risiken vorzubeugen. Dabei werden drei Sicherungen auf zwei Medien angelegt, eine Kopie liegt Extern. Mindestens zwei Sicherungen an getrennten Orten sollten von wichtigen Daten vorliegen. Als wichtig<\/em> klassifiziere ich nicht blo\u00df Unternehmensdaten, die kritisch f\u00fcr das Gesch\u00e4ft sind. Private Erinnerungen sind individuell sicher in der Regel ebenfalls wertvoll – auch wenn sich der Wert kaum in Euro beziffern l\u00e4sst. Andererseits k\u00f6nnen z.B. Bilder von Familie oder Freunden bei Verlust mit Geld oft nicht wiederhergestellt werden. Es lohnt sich daher auch privat, die eigenen Daten zu sichern.<\/p>\n
Was man sonst noch bedenken sollte<\/h2>\n
Der Einsatz von Verschl\u00fcsselung ist zum Schutz der Daten super. Un\u00fcberlegt eingesetzt kann man sich damit allerdings selbst aussperren. Es ist daher wichtig, den Ablauf einer Wiederherstellung gedanklich durchzuspielen – ausgehend vom schlimmsten Szenario. Ein Klassiker: F\u00fcr die Sicherung wurde ein sicheres Kennwort verwendet und daher im Passwortsafe abgelegt. Der liegt allerdings in der verschl\u00fcsselten Sicherung – somit kommt man nicht mehr an die Daten heran.<\/p>\n
In diesem Falle m\u00fcsste man entweder den Passwortsafe ohne zus\u00e4tzliche Verschl\u00fcsselung \u00fcbertragen. Das ist ohne Sicherheitsverlust m\u00f6glich, weil dieser bereits verschl\u00fcsselt ist. Oder alternativ ein Kennwort nutzen, auf das man in jedem Falle Zugriff hat: Beispielsweise ist es an einem sicheren Ort verwahrt oder man kennt es auswendig. Wobei beim auswendig lernen die Gefahr des Vergessens droht, wenn es l\u00e4ngere Zeit nicht eingegeben werden muss.<\/p>\n
Dies sind nur Beispiele. Es variiert je nach Umgebung und Umst\u00e4nden. Gerade deswegen ist wichtig, sich vorab Gedanken dar\u00fcber zu machen.<\/p>\n
Wie ist Borg aufgebaut?<\/h2>\n
Ein Repository<\/strong> dient als Container im Zielspeicher, um die Sicherungen in der gew\u00fcnschten Konfiguration (Verschl\u00fcsselt, Komprimiert, Dedupliziert) zu b\u00fcndeln. Als Archiv<\/strong> bezeichnet Borg eine einzelne Sicherung der \u00fcbergebenen Verzeichnisse. Im Repository k\u00f6nnen mehrere Archive angelegt werden. Und zwar recht frei, wenn man es mit anderer Sicherungssoftware wie Duplicati vergleicht. Vorgegeben ist nur, dass der Archivname innerhalb eines Repository eindeutig sein muss.<\/p>\n
\n![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2024\/09\/borg_archiv-repo-aufteilung.avif\")
<\/a><\/figure>\n<\/div>\nDamit es nicht zu Chaos kommt, empfiehlt sich die Verwendung eines Namensschemas. L\u00e4sst man die Sicherungen \u00fcber ein kleines Shell-Skript anlegen, bleibt diese gewahrt. Schon alleine deswegen macht das Sinn. Sp\u00e4testens wenn mehrere Archive (= Sicherungen) pro Durchlauf angelegt werden sollen, wird das Skript zur Pflicht. Sonst ist die Handhabung umst\u00e4ndlich und es passiert leicht, dass etwas vergessen wird.<\/p>\n
Installation und Vorbereitung<\/h2>\n
Die verf\u00fcgbaren Versionen finden sich auf der Webseite.1<\/a><\/sup> Manche sind experimentell und sollten nicht produktiv verwendet werden. Zum Erstellungszeitpunkt des Beitrages war Borg 1.4 die aktuellste stabile Version, w\u00e4hrend sich 2.0 in der Testphase befindet. Es empfiehlt sich, die jeweils aktuelle stabile zu nutzen. Die Bin\u00e4rdateien finden sich auf der GitHub Release-Seite.2<\/a><\/sup><\/p>\n
wget https:\/\/github.com\/borgbackup\/borg\/releases\/download\/1.4.0\/borg-linux-glibc228\nchmod +x borg-linux-glibc228\nsudo mv borg-linux-glibc228 \/usr\/local\/bin\/borg\n\n$ borg --version\nborg 1.4.0<\/code><\/pre>\nEs sollte sichergestellt werden, dass gen\u00fcgend freier Speicherplatz (mindestens die Gr\u00f6\u00dfe der zu sichernden Daten) im Ziel vorhanden ist. Auch in
~\/.cache <\/code>werden mehrere Gigabyte ben\u00f6tigt. Borg ben\u00f6tigt freien Speicherplatz, um Dateien zu l\u00f6schen. Auf voll gelaufenen Laufwerken kann daher nicht durch das Entfernen \u00e4lterer Sicherungen Platz geschaffen werden!<\/p>\nVorbereitung: Anlegen eines Repositories f\u00fcr Sicherungen<\/h2>\n
Zu Beginn muss ein Repository im Zielpfad (z.B. eine externe Festplatte) angelegt werden. Borg unterst\u00fctzt auch entfernte Repositories \u00fcber SSH. Einmalig l\u00e4sst sich festlegen, ob und wie die sp\u00e4teren Sicherungen verschl\u00fcsselt werden. Dies l\u00e4sst sich nicht<\/strong> nachtr\u00e4glich ver\u00e4ndern! Nur \u00fcber das Anlegen eines neuen Repositories, womit jedoch alle bisherigen Versionen verloren gehen. Ich halte es daher f\u00fcr wichtig, sich an dieser Stelle einen \u00dcberblick \u00fcber die verschiedenen Methoden zu verschaffen und gezielt eine zu w\u00e4hlen.3<\/a><\/sup><\/p>\n
Borg empfiehlt Verschl\u00fcsselung, um die Sicherungen gegen unbefugten Zugriff (Cloudanbieter, Kompromittierung, Einbruch usw) zu sch\u00fctzen. Aber auch zur Sicherung der Integrit\u00e4t. Ansonsten k\u00f6nnten Angreifer mit Zugang beispielsweise Dateien manipulieren. Sicherheitstechnisch ist das zu empfehlen. Man sollte jedoch insbesondere hier darauf achten, das R\u00fccksichern zu testen. Verschl\u00fcsselung und Kompression sind potenzielle zus\u00e4tzliche Fehlerquellen. Wer darauf verzichtet, kann sie mit
--encryption none<\/code> komplett abschalten.<\/p>\nIm Falle verschl\u00fcsselter Sicherungen w\u00fcrde ich
repokey<\/code> verwenden: Intern legt das mehrere (private) Schl\u00fcssel an, die mit dem von euch eingegebenen Passwort (passphrase<\/em>) gesch\u00fctzt werden. Wie der Name erahnen l\u00e4sst, speichert Borg die Schl\u00fcssel im Repository – sie sind somit automatisch in eurer Sicherung enthalten. Ein gesonderter Export mitborg key export<\/code> wird dennoch empfohlen, da zum R\u00fcckspielen sowohl der Schl\u00fcssel im Dateisystem, als auch euer Passwort notwendig ist. Das Risiko, sich selbst auszusperren, ist hier geringer. Beikeyfile<\/code> liegt der Schl\u00fcssel dagegen in eurem Heimverzeichnis (~\/.config\/borg\/keys<\/code>). Hier kann es leicht passieren, dass dieser vergessen wird, au\u00dferhalb zu sichern. Eine Wiederherstellung w\u00e4re dann nicht m\u00f6glich, weil der Schl\u00fcssel daf\u00fcr ben\u00f6tigt wird. Um an den Schl\u00fcssel zu kommen, m\u00fcsste jedoch die Sicherung entschl\u00fcsselt werden…<\/p>\nborg init --make-parent-dirs --encryption repokey \/mnt\/backup-8tb\/borg_nas<\/code><\/pre>\nWie viele Repositories\/Archive anlegen?<\/h3>\n
Das wichtigste ist, zusammenh\u00e4ngende Dateien im gleichen Repository zu sichern. Auf dessen Ebene findet n\u00e4mlich die Deduplizierung statt. M\u00f6chte man z.B. einen Heimserver oder ein NAS sichern, reicht ein Repo in vielen F\u00e4llen aus. Eine explizite Trennung kann u.u. Sinn machen, etwa wenn man gro\u00dfe Dateien hat und diese unterschiedlich kritisch sind. Eine gro\u00dfe Filmsammlung m\u00f6chte man evtl. weniger stark replizieren, als die privaten Dateien. Die gesicherten Dateien lassen sich nicht zerlegen – in diesem Falle w\u00e4re es sinnvoll, zwei Repos anzulegen.<\/p>\n
Bei den Archiven d\u00fcrften die Intervalle von Sicherungen das wichtigste Kriterium sein. Sollen bestimmte (wichtigere) Daten h\u00e4ufiger gesichert werden, als andere? Dann ist ein eigenes Archiv sinnvoll. Theoretisch kann das auch der Fall sein, wenn nur wenige Dateien h\u00e4ufiger gesichert werden sollen, als viele andere. Borg muss alle angegebenen Ordner rekursiv auf \u00c4nderungen gegen\u00fcber dem letzten Backup pr\u00fcfen. In der Praxis ist das Programm dabei recht flott und es d\u00fcrfte in den seltensten F\u00e4llen eine Rolle spielen, ob der Durchlauf etwas l\u00e4nger dauert. Das Bereinigen einzelner Dateien ist zwar auch im gro\u00dfen Archiv m\u00f6glich – kann jedoch mit mehreren Archiven \u00fcbersichtlicher werden, wenn man hier komplexere Ausnahmen machen m\u00f6chte.<\/p>\n
Was die Wiederherstellung angeht, l\u00e4sst sich das gesamte Archiv einh\u00e4ngen und man kopiert nur ben\u00f6tigte Inhalte zur\u00fcck. Ein einziges Archiv, aus dem man nur eine Datei holt, ist daher m\u00f6glich. S\u00e4mtliche Daten wiederherzustellen ist mit mehreren Archiven ebenfalls m\u00f6glich – allerdings mehr Arbeit. Tendenziell w\u00fcrde ich daher mit m\u00f6glichst wenig Archiven starten.<\/p>\n
Sichern von Dateien und Ordnern<\/h2>\n
Innerhalb eines Repositories k\u00f6nnen nun Ordner oder einzelne Dateien mit
borg create<\/code> in ein Archiv gesichert werden.4<\/a><\/sup> Folgendes Beispiel sichert alle Heimverzeichnisse meines Servers in das zuvor erstellte Repository \/mnt\/backup-8tb\/borg_nas als Archivhome-{zeitstempel}<\/code>:<\/p>\nborg create --one-file-system --dry-run --list --progress --stats --exclude '*\/.cache' \/mnt\/backup-8tb\/borg_nas::home-{now:%d.%m.%Y} \/home<\/code><\/pre>\n–one-file-system<\/strong> stellt sicher, dass keine innerhalb des Zielordners eingeh\u00e4ngten Laufwerke gesichert sind. Beispielsweise externe Festplatten oder per SSHFS gemountete Server. Typischerweise legt man diese in
\/mnt<\/code>. Zur Sicherheit finde ich die Option sinnvoll, bevor irgend etwas voll l\u00e4uft, weil doch versehentlich eine andere Platte mit gesichert wird.<\/p>\n–dry-run<\/strong> f\u00fchrt lediglich eine Simulation durch. Zusammen mit –list<\/strong> zeigt es euch an, welche Dateien Borg sichern w\u00fcrde. Das hilft bei ersten Tests. Insbesondere um zu pr\u00fcfen, ob Filter wie gew\u00fcnscht funktionieren. Ist das der Fall, ersetze ich beide durch –stats<\/strong>.<\/p>\n
–stats<\/strong> gibt nach Abschluss eine Zusammenfassung aus. Sie zeigt etwa, wie viele Dateien gesichert wurden, wie gro\u00df diese sind und wie hoch der tats\u00e4chliche Speicherplatzbedarf auf dem Zielmedium nach der Deduplizierung war.<\/p>\n
–progress<\/strong> zeigt w\u00e4hrend der Sicherung den Fortschritt an.5<\/a><\/sup> Vor allem anfangs n\u00fctzlich, wenn man diese (testweise) von Hand ausf\u00fchrt.<\/p>\n
–exclude<\/strong> schlie\u00dft Dateien und Ordner aus, die dem \u00fcbergebenen Muster entsprechen. In diesem Beispiel wird jeglicher
.cache<\/code> Ordner ignoriert. Typischerweise befindet er sich im Heimverzeichnis eines GNU\/Linux-Benutzers und dient als tempor\u00e4rer Zwischenspeicher. Vor allem auf Desktop-Systemen kommen dort schnell einige Gigabyte zusammen, etwa durch Vorschaubilder im Datei-Explorer. Was hier liegt, ist fl\u00fcchtig und kann aus den originalen Quellen\/Dateien neu generiert werden. Beispielsweise werden beim Laden eines Ordners neue Thumbnails erzeugt, wenn sie hier nicht mehr vorhanden sind. Diesen Ordner zu sichern, macht daher wenig Sinn.<\/p>\n\/mnt\/backup-8tb\/borg_nas::home-{now:%d.%m.%Y}<\/strong> ist das Sicherungsziel: Der Pfad stammt vom zuvor erstellten Repository, nach dem Doppelpunkt steht der Name des Archivs. Dieser muss einzigartig sein.<\/p>\n
Wie viel Speicherplatz belegen die Sicherungen?<\/h2>\n
Bei jeglichen Statistiken unterscheidet Borg zwischen der originalen Gr\u00f6\u00dfe (Original size<\/strong>) – das sind die originalen Dateien im Quellverzeichnis, wie sie das Programm zum Sicherungszeitpunkt vorgefunden hat. Beim Anlegen der Sicherungsarchive werden sie komprimiert (Compressed size<\/strong>) und es findet eine Deduplizierung statt: Liegt eine Kopie der gleichen Datei an mehreren Stellen, merkt sich Borg das und speichert die Datei nur einmal in der Sicherung. Wie viel durch Komprimieren gespart wird, h\u00e4ngt von der Art der Dateien ab. Text l\u00e4sst sich z.B. stark verkleinern, bereits komprimierte Formate wie JPG-Bilder hingegen kaum.<\/p>\n
Die Ausgabe mit
--stats<\/code> ist recht ausf\u00fchrlich, nicht alles erschlie\u00dft sich jedoch auf Anhieb. Bei This archive<\/strong> seht ihr, dass in diesem Falle 1,24 TB im Quellordler liegen. Komprimiert reduziert sich das kaum auf 1,23 TB. Unter Deduplicated size<\/strong> sieht man den Speicherbedarf der jetzigen Sicherung – im Regelfall das, was nach einem Lauf am meisten interessiert. Beim ersten Durchlauf ist dieser Wert am H\u00f6chsten, weil eine Vollsicherung erfolgt. Danach sieht man hier nur noch das Delta, d.H. neue und ver\u00e4nderte Dateien seit der letzten Sicherung.<\/p>\n\n![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2024\/08\/borg-summary.avif\")
<\/a><\/figure>\n<\/div>\nDirekt darunter findet sich in der gleichen Spalte der belegte Speicher von allen Archiven im Repository, hier 4,57 TB. Was verwirren kann: Die Originale Gr\u00f6\u00dfe in der ersten Spalte rechnet nicht inkrementell! Die originale Gr\u00f6\u00dfe aller Archive ist daher von 17.90 TB im vorherigen Archiv auf 19.14 TB gestiegen, weil die Originalgr\u00f6\u00dfe in diesem Archiv 1,24 TB betr\u00e4gt. Tats\u00e4chlich blieben inkrementell mit Komprimierung & Deduplizierung aber eben nur die 1,72 GB \u00fcbrig, welche wirklich auf dem Sicherungsmedium physisch liegen. All archives<\/strong> in der Original size<\/strong> Spalte wird somit schnell riesige Dimensionen annehmen, was jedoch eher ein theoretischer Wert ist, der die Sicherungsplatte nicht zum \u00dcberlaufen bringt.<\/p>\n
Was man vor dem Aufr\u00e4umen wissen sollte<\/h2>\n
Beide Wege geben den belegten Speicher im Dateisystem nicht<\/strong> automatisch frei! Hierf\u00fcr muss man zun\u00e4chst mit
borg prune<\/code> eine Aufbewahrungsstrategie festgelegt werden. Die Software markiert daraufhin alle Sicherungen, die ihr nicht entsprechen, als gel\u00f6scht. Anschlie\u00dfend sind die Datenbl\u00f6cke (Chunks) weiterhin vorhanden. Der Speicher wird erst mitborg compact<\/code> aufgerufen. Diese Aufteilung existiert wegen der Deduplizierung: Pro Repo liegt jeder Datenblock nur einmal im physischen Dateisystem. Um von dort in verschiedenen Sicherungen referenziert zu werden. Bei prune l\u00f6scht Borg die Referenzen. Mit compact folgen alle Bl\u00f6cke, auf die kein Backup mehr verweist, erst hier gibt es physischen Speicher frei.<\/p>\nSicherungsgr\u00f6\u00dfe<\/h3>\n
Bevor man sich mit dem L\u00f6schen befasst, ist es sinnvoll, die Gr\u00f6\u00dfe der Sicherungen zu ermitteln. Der Info-Befehl liefert mehrere Ausgaben: Original size<\/strong> umfasst die Quell-Datenmenge ohne jegliche Optimierungen. Haben wir etwa einen Ordner mit 100 GB Daten, die 5x gesichert werden, betr\u00e4gt deren originale Gr\u00f6\u00dfe im Repo 5×100 GB = 500 GB. Physisch belegen diese Sicherungen auf dem Zielmedium weitaus weniger Speicher, weil Borg komprimiert. Im folgenden Beispiel spart das 86 TB. <\/p>\n
borg info\n[...]\n------------------------------------------------------------------------------\n Original size Compressed size Deduplicated size\nAll archives: 768.01 TB 682.65 TB 7.53 TB\n\n Unique chunks Total chunks\nChunk index: 4512339 1344658730<\/code><\/pre>\nDen gr\u00f6\u00dften Effekt hat Deduplizieren, was auf die inkrementellen Sicherungen zur\u00fcckzuf\u00fchren ist. Tats\u00e4chlich \u00e4ndern sich bei Sicherung #2 im Vergleich zu Sicherung #1 ja niemals alle Dateien. Sondern in aller Regel nur ein sehr kleiner Teil. Borg sichert daher ab der zweiten Sicherung nur den jeweiligen Unterschied zu vorherigen. Deduplicated size<\/strong> entspricht daher dem physischen Speicherverbrauch nach s\u00e4mtlichen Optimierungen. Hier sind das 7,53 TB.<\/p>\n
Wichtig<\/h3>\n
Borg kennt keine Archiv-Gruppen<\/strong>! Wenn wie in meinem Szenario Gruppen f\u00fcr verschiedene Inhalte angelegt werden, stellt es standardm\u00e4\u00dfig nicht<\/strong> sicher, dass die Aufbewahrungsregeln (z.B. je eine der letzten 7 Tage) auf alle Anwendung finden! Ein weiterer Grund, unbedingt zuerst mit
--dry-run<\/code> zu simulieren. Hierbei f\u00e4llt das auf:<\/p>\nKeeping archive (rule: daily #1): software_04.04.2026 Sat, 2026-04-04 05:34:29 [8f965397f472179573bb52be1614f9ce4720ca619add45029852bc9957676eaf]\nWould prune: multimedia_04.04.2026 Sat, 2026-04-04 04:53:12 [45118b8605aa530f9108a9125169aca80f6ff73172421e739f0a9cea9822dbbb]\nWould prune: nextcloud-daten_04.04.2026 Sat, 2026-04-04 04:10:49 [410a5001e35b8bd7e6589f0bfe0522dc7d053f04d815f6d865b2b4391450a3d2]\n[...]\nKeeping archive (rule: daily #2): software_03.04.2026 Fri, 2026-04-03 05:08:32 [494cc30642fa03b738f7e90eb080e4d983976a16988d531f0970d0f652769b50]<\/code><\/pre>\nIn diesem Falle wird nur das Software-Archiv enthalten, weil es die jeweils letzte Sicherung des Tages ist. Alle anderen gehen verloren. Dies l\u00e4sst sich auf zwei Arten sinnvoll l\u00f6sen: Entweder durch Verwendung eines Pr\u00e4fixes – man setzt die Policy f\u00fcr das Pr\u00e4fix software_* multimedia_* nextcloud-daten_* und so weiter. Oder legt sie zu einem Archiv zusammen, ggf. mit mehreren Repos. Mehr Repos machen es komplizierter. Dies w\u00fcrde ich nur empfehlen, wenn es sich um sehr gro\u00dfe Datenmengen handelt – hier kann die Performance durch Aufteilung profitieren.<\/p>\n
Keeping archive (rule: daily #1): software_04.04.2026 Sat, 2026-04-04 05:34:29 [8f965397f472179573bb52be1614f9ce4720ca619add45029852bc9957676eaf]\nWould prune: multimedia_04.04.2026 Sat, 2026-04-04 04:53:12 [45118b8605aa530f9108a9125169aca80f6ff73172421e739f0a9cea9822dbbb]\nWould prune: nextcloud-daten_04.04.2026 Sat, 2026-04-04 04:10:49 [410a5001e35b8bd7e6589f0bfe0522dc7d053f04d815f6d865b2b4391450a3d2]\n[...]\nKeeping archive (rule: daily #2): software_03.04.2026 Fri, 2026-04-03 05:08:32 [494cc30642fa03b738f7e90eb080e4d983976a16988d531f0970d0f652769b50]<\/code><\/pre>\nDaher nutze ich prune mit Pr\u00e4fix pro Archiv. Dies f\u00fchrt zum erwarteten Ergebnis<\/p>\n
borg prune --dry-run --list --keep-daily=7 --keep-weekly=4 --keep-monthly=12 --keep-yearly=6 --glob-archives 'software_*'<\/code><\/pre>\nAufr\u00e4umen<\/h2>\n
Automatisch nach bestimmten Mustern<\/h3>\n
Am sinnvollsten ist es, die Sicherungen nach einem bestimmten Zeitplan automatisch l\u00f6schen zu lassen. Man sollte sich daher zun\u00e4chst \u00fcberlegen, wie weit zur\u00fcck diese reichen sollen. Zum Wiederherstellen m\u00f6glichst vieler Daten kann es nie genug Sicherungen geben. Allerdings kosten diese Speicherplatz – insbesondere wenn h\u00e4ufige \u00c4nderungen an gr\u00f6\u00dferen Inhalten vorgenommen werden. Borg nutzt inkrementelle Sicherungen, Komprimierung und Deduplizierung, um den Speicherbedarf so gering wie m\u00f6glich zu halten. Anfangs kann man den Speicherbedarf auch erst mal beobachten, bis man sich f\u00fcr eine L\u00f6schstrategie entscheidet.<\/p>\n
Wahlweise kann eine zeitliche Vorgabe f\u00fcr das gesamte Repository festgelegt werden. Oder mit
--glob-archives <\/code>ein Filter, um von wichtigere Daten mehr Sicherungen aufzuheben, als von anderen. Grunds\u00e4tzlich ist es eine gute Idee, mehr aktuelle als \u00e4ltere aufzubewahren. Wer alte Sicherungen komplett l\u00f6scht, geht ein Risiko ein: Beispielsweise kann man eine Datei versehentlich zerst\u00f6ren, die aber nur selten ben\u00f6tigt wird. F\u00e4llt das erst einige Zeit sp\u00e4ter auf,<\/p>\nFolgendes Beispiel beh\u00e4lt eine Sicherung pro Tag der letzten Woche (7 Tage), eine aus den letzten 8 Wochen, 8 der letzten Monate und 4 pro Jahr. Mit
--list --dry-run<\/code> f\u00fchrt es zun\u00e4chst eine Trocken\u00fcbung durch, die alle Archive auflistet, welche gel\u00f6scht werden w\u00fcrden. <\/p>\nborg prune -v --list --dry-run --keep-daily=7 --keep-weekly=8 --keep-monthly=12 --keep-yearly=6 \/mnt\/backup-8tb\/borg_nas\/<\/code><\/pre>\nOhne \u00dcbergabe eines Archivs wird dies auf s\u00e4mtliche Archive angewendet! Mit
--glob-archives='abc-*'<\/code> wird nur auf Archive gefiltert, die mit abc- beginnen. Entspricht das Ergebnis der Simulation den Erwartung, ruft man es zur tats\u00e4chlichen L\u00f6schung ohne--dry-run<\/code> Parameter auf.<\/p>\nManuell<\/h3>\n
Mit -a kann ein glob angegeben werden, um Archive dieses Musters zu l\u00f6schen. Sinnvoll ist, sich zun\u00e4chst mit
--list --dry-run<\/code> simuliern zu lassen, auf welche Archive dies zutrifft. Insbesondere dann, wenn man Platzhalter (z.B. *-2024) nutzt.<\/p>\nborg delete -a 'nextcloud-daten_26.08.2024' --list --dry-run \/mnt\/backup-8tb\/borg_nas\/\nEnter passphrase for key \/mnt\/backup-8tb\/borg_nas: \nWould delete archive: nextcloud-daten_26.08.2024 Mon, 2024-08-26 12:33:45 [e6369857a90324be3e927cfa33a2d0bb11be07ae5f97831883956bd89d51bf95] (1\/1)<\/code><\/pre>\nEinzelne Sicherungen (Archive) lassen sich mit
borg delete<\/code> im gewohnten Format einzeln l\u00f6schen:6<\/a><\/sup><\/p>\nborg delete \/mnt\/backup-8tb\/borg_nas::home-xxx<\/code><\/pre>\nIst das Repository per BORG_REPO Umgebungsvariable gesetzt, muss dies nicht angegeben werden. Die zwei Doppelpunkte sind allerdings erforderlich, um den Parameter als Archiv zu kennzeichnen – beispielsweise:<\/p>\n
borg delete \/mnt\/backup-8tb\/borg_nas::vms_12.12.2024<\/code><\/pre>\nFreigeben des Speichers<\/h3>\n
Wieder zeigt Deduplicated size<\/strong> die Menge des eingesparten physischen Speicherplatzes. Je nachdem, wie viele \u00c4nderungen die gel\u00f6schten Archive enthalten, kann das Ergebnis \u00fcberschaubar sein. Hier betr\u00e4gt die Einsparung rund 27 GB.<\/p>\n
------------------------------------------------------------------------------\n Original size Compressed size Deduplicated size\nDeleted data: -340.24 GB -239.15 GB -26.57 GB\nAll archives: 767.64 TB 682.40 TB 7.50 TB\n\n Unique chunks Total chunks\nChunk index: 4486640 1342142749\n------------------------------------------------------------------------------<\/code><\/pre>\nWie zuvor erw\u00e4hnt, entfernt prune<\/em> nur die Bl\u00f6cke der zu l\u00f6schenden Sicherungen. Dasselbe gilt f\u00fcr delete<\/em>. In beiden F\u00e4llen muss daher danach compact<\/em> ausgef\u00fchrt werden, um nicht mehr referenzierte Dateien physisch vom Ziellaufwerk zu entfernen. Dies sollte regelm\u00e4\u00dfig nach prune\/delete<\/em> geschehen.<\/p>\n
borg compact \/mnt\/backup-8tb\/borg_nas\/<\/code><\/pre>\nTipps f\u00fcr Skripte<\/h2>\n
Borg besitzt ein paar n\u00fctzliche Funktionen, um die Sicherungen in Skripten teilweise oder komplett zu automatisieren. Das d\u00fcrfte fast immer Sinn machen: Schnell hat man mehrere Archive und\/oder ein paar Ordner, die aus der Sicherung ausgeschlossen werden. Soll eine Bereinigung erfolgen, lassen sich prune & compact dort einbauen. Dank Skript wird nichts davon vergessen.<\/p>\n
Wer das Passwort nicht bei jeder Sicherung eingeben oder den Prozess komplett automatisieren m\u00f6chte, kann es in der Umgebungsvariable
BORG_PASSPHRASE<\/code> f\u00fcr alle Borg-Befehle setzen. Beim erzeugen mehrerer Archive im gleichen Repository istBORG_REPO<\/code> eine Hilfe, um diese Angabe beim Aufruf zu ersparen. Alternativ lassen sich Wiederholungen \u00fcber eine Bash-Variable vermeiden.<\/p>\nexport BORG_REPO=\/mnt\/backup-8tb\/borg_nas\nexport BORG_PASSPHRASE='DeinSuperSicheresPasswortZumSchutzDeinerBackups!'<\/code><\/pre>\nIm Skript empfehle ich folgenden Ablauf:<\/p>\n
- \n
- Anlegen der Sicherung(en), also Archive<\/li>\n
- Gegebenenfalls Passwortsafe au\u00dferhalb des Repos kopieren, um sich nicht auszusperren (siehe oben)<\/li>\n
- Bereinigen alter Sicherungen mit
borg prune<\/code> (hierf\u00fcr definieren, wie lange ihr Sicherungen aufbewahren m\u00f6chtet)<\/li>\n- Freigabe des bereinigten Speicherplatzes im Dateisystem:
borg compact<\/code><\/li>\n<\/ul>\nEs ist eine gute Idee, eine Sicherung zu automatisieren und die dortigen Ausgaben in eine Logdatei zu schreiben.<\/p>\n
Wiederherstellen von Daten aus einer Sicherung<\/h2>\n
Es gibt eine alte Weisheit, die besagt: Ein nicht getestetes Backup ist kein Backup<\/em>. Manche bewerten dies sogar noch schlimmer, weil es ein falsches Gef\u00fchl von Sicherheit vermitteln kann. Das kommt nicht von ungef\u00e4hr – zwei gute Gr\u00fcnde sprechen daf\u00fcr, das R\u00fccksichern am besten direkt nach dem Durchlauf der ersten Sicherung zu testen:<\/p>\n
- \n
- Sieht man, was enthalten ist. Wurden Dateien vergessen, kann rechtzeitig nachgebessert werden.<\/li>\n
- Der Ablauf ist bekannt und am besten dokumentiert, um ihn im Ernstfall zeitnah durchf\u00fchren zu k\u00f6nnen.<\/li>\n<\/ol>\n
Auch dar\u00fcber hinaus ist es ratsam, die Sicherungen in regelm\u00e4\u00dfigen Abst\u00e4nden zu pr\u00fcfen. Schlie\u00dflich gibt es weitere Dinge, die schief gehen k\u00f6nnen<\/a>.<\/p>\n
Borg bietet die M\u00f6glichkeit, eine Sicherung (also das Archiv in einem Repository) als Dateisystem einzuh\u00e4ngen.7<\/a><\/sup> Dabei kann man wahlweise das ganze Repository einh\u00e4ngen und sieht die Archive als Unterordner – sehr praktisch, falls man z.B. eine fehlerhafte Datei wiederherstellen m\u00f6chte, bei der nicht genau klar ist, welche Sicherung die aktuellste, funktionierende enth\u00e4lt. Oder man h\u00e4ngt ein spezifisches Archiv ein.<\/p>\n
sudo mkdir \/mnt\/borg_restore\nborg mount \/home\/daniel\/backups_borg \/mnt\/borg_restore\/<\/code><\/pre>\nWer sich f\u00fcr das Einh\u00e4ngen eines einzelnen Archivs entscheidet, m\u00f6chte sich wahrscheinlich die existierenden vorher anzeigen lassen:<\/p>\n
borg list \/mnt\/backup-8tb\/borg_nas<\/code><\/pre>\nNun kann der Einh\u00e4ngepfad (hier
\/mnt\/borg_restore\/<\/code>) beliebig durchsucht werden. Das erste \u00d6ffnen eines Archivs dauert einige Sekunden (meinen Tests ca. 15s), da das Laden erst beim Abruf erfolgt. Danach ist die Navigation nicht sp\u00fcrbar langsamer, als ein natives Dateisystem. Es kann einfach durchsucht werden und man kopiert sich ben\u00f6tigte Dateien heraus.<\/p>\nNach Abschluss das Dateisystem wieder aush\u00e4ngen:<\/p>\n
sudo umount \/mnt\/borg_restore<\/code><\/pre>\nFazit<\/h2>\n
Inkrementell, Komprimiert, Dedupliziert – viel mehr l\u00e4sst sich kaum machen, um Datensicherungen m\u00f6glichst sparsam zu speichern. Borg bietet viele Funktionen, um auch umfangreichere Sicherungen durchzuf\u00fchren. In Anbetracht der zu durchsuchenden Datenmenge ist die Sicherung recht flott abgeschlossen: F\u00fcr \u00fcber 215.000 Dateien waren nur gute 3,5 Minuten notwendig, um 1,72 GB\/1,24 TB neuer Dateien in das Backup aufzunehmen.<\/p>\n
Es eignet sich besonders f\u00fcr Fans der Kommandozeile und damit zur (Teil-) Automatisierung. Durch inkrementelle Durchl\u00e4ufe k\u00f6nnen Sicherungen h\u00e4ufig stattfinden, ohne riesige Dateimengen zu verursachen. \u00dcber eine Client-Server Architektur lassen sich Backups per SSH auf entfernten Systemen anlegen.8<\/a><\/sup> Eine Integration in z.B. \u00f6ffentliche Clouddienste fehlt dagegen. Wer das ben\u00f6tigt oder lieber mit grafischen Oberfl\u00e4chen arbeitet, findet mit Duplicati eine Alternative.<\/p>\n
Weiterf\u00fchrende Infos<\/h2>\n
- \n
- Das Format der Repository URLs<\/em> wird hier in allen Varianten beschrieben. Darunter auch f\u00fcr entfernte Repos.\r\nhttps:\/\/borgbackup.readthedocs.io\/en\/stable\/usage\/general.html<\/li>\n
- Flags, die Borg w\u00e4hrend der Sicherung anzeigt. Sie informieren dar\u00fcber, ob eine Datei neu hinzugef\u00fcgt\/modifiziert wurde oder als unver\u00e4ndert \u00fcbersprungen.\r\nhttps:\/\/borgbackup.readthedocs.io\/en\/stable\/usage\/create.html#item-flags<\/li>\n
- Eine gute \u00dcbersicht f\u00fcr den Einstieg bietet auch der Artikel im Ubuntu-Wiki:\r\nhttps:\/\/wiki.ubuntuusers.de\/BorgBackup\/<\/li>\n<\/ul>\n
Quellen<\/h2>\n
- \n
- https:\/\/www.borgbackup.org\/releases\/ \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/github.com\/borgbackup\/borg\/releases \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/borgbackup.readthedocs.io\/en\/stable\/usage\/init.html \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/borgbackup.readthedocs.io\/en\/stable\/usage\/create.html \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/github.com\/borgbackup\/borg\/issues\/5038#issuecomment-599491540 \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/borgbackup.readthedocs.io\/en\/stable\/usage\/delete.html \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/borgbackup.readthedocs.io\/en\/stable\/usage\/mount.html \u21a9\ufe0e<\/a><\/li>\n
- https:\/\/borgbackup.readthedocs.io\/en\/stable\/usage\/serve.html \u21a9\ufe0e<\/a><\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
Backups sch\u00fctzen die eigenen Daten gegen eine Vielzahl an Gefahren und verhindern damit Besch\u00e4digung oder Verlust. Borg ist eine freie & quelloffene Software, um Dateien effizient zu sichern – ob auf dem Raspberry Pi, (Heim-) Server oder anderen PCs. Dieser Beitrag zeigt, wie das Programm funktioniert und wie ihr damit Sicherungen einrichtet. Warum Borg? Nicht …<\/p>\n","protected":false},"author":5,"featured_media":13991,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"[{\"content\":\"https:\/\/www.borgbackup.org\/releases\/\",\"id\":\"d9774eaa-185b-4d0c-b28d-c00c97fb4a5e\"},{\"content\":\"https:\/\/github.com\/borgbackup\/borg\/releases\",\"id\":\"1440862c-c8c3-42de-815f-c4566b2fa906\"},{\"content\":\"https:\/\/borgbackup.readthedocs.io\/en\/stable\/usage\/init.html\",\"id\":\"8ee0be29-9c48-4f36-a30c-ee6f0320984b\"},{\"content\":\"https:\/\/borgbackup.readthedocs.io\/en\/stable\/usage\/create.html\",\"id\":\"edb258aa-33e8-4539-8c05-886f63f95f00\"},{\"content\":\"https:\/\/github.com\/borgbackup\/borg\/issues\/5038#issuecomment-599491540\",\"id\":\"4f0d790d-9748-49e0-83a8-9ab9b4517f5b\"},{\"content\":\"https:\/\/borgbackup.readthedocs.io\/en\/stable\/usage\/delete.html\",\"id\":\"ba8591e7-33fd-4a3a-9ae5-d0ede6c5d499\"},{\"content\":\"https:\/\/borgbackup.readthedocs.io\/en\/stable\/usage\/mount.html\",\"id\":\"02ef20b1-c7aa-41aa-96e3-ad4fcc971aaf\"},{\"content\":\"https:\/\/borgbackup.readthedocs.io\/en\/stable\/usage\/serve.html\",\"id\":\"cb8f25c2-4576-432f-8f42-23b715c54910\"}]"},"categories":[78],"tags":[69,68],"class_list":["post-13408","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-software","tag-backups","tag-datensicherung"],"_links":{"self":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/13408","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/comments?post=13408"}],"version-history":[{"count":48,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/13408\/revisions"}],"predecessor-version":[{"id":17189,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/13408\/revisions\/17189"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media\/13991"}],"wp:attachment":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media?parent=13408"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/categories?post=13408"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/tags?post=13408"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- https:\/\/github.com\/borgbackup\/borg\/releases \u21a9\ufe0e<\/a><\/li>\n
- Das Format der Repository URLs<\/em> wird hier in allen Varianten beschrieben. Darunter auch f\u00fcr entfernte Repos.\r\nhttps:\/\/borgbackup.readthedocs.io\/en\/stable\/usage\/general.html<\/li>\n
- Freigabe des bereinigten Speicherplatzes im Dateisystem: