Backupkonzept

Heute möchte ich über das Thema Datensicherung aka Backups schreiben. Hier und da wurde ich gefragt, wie ich das löse bzw. umgesetzt habe.

Mariannes Blog-Artikel gab den Ausschlag dieses nun endlich mal aufzuschreiben.

Es wird eine kleine Reise werden. Ich werde über die grundsätzlichen Gedanken berichten, die ich mir gemacht habe, als auch etwas in technische Details gehen. Ebenso werde ich Dinge niederschreiben, die sich nicht bewährt haben, da dies evtl. für andere ebenfalls hilfreich erweisen sein.

Dieser Artikel wird länger ;-)

Start

Grundsätzlich wollte ich das Backup am Ende so gestalten, dass es für mich relativ einfach ist anzuwenden. Sind beim Anfertigen eines Backups mehrere Vorbereitungen notwendig oder muss ich minutenlang einem Script zuschauen, neige ich dazu, das Backup zu vergessen oder “gerade keine Zeit” zu haben. Und ein Backup sollte natürlich möglichst aktuell sein. Ein Ziel von mehreren muss also die Cloud^(tm) sein. Damit entfällt das Gestöpsel von einer externe Festplatte und es gibt eine Ausrede weniger. Weiterhin bietet dies die Möglichkeit, das Backup weiter zu automatisieren, z.B. beim Runterfahren des PCs. Dazu jedoch später mehr.

Was will ich sichern und warum?

Der erste Schritt, den ich getan habe, war mir zu überlegen, was ich alles sichern möchte und ich habe mir folgende Fragen gestellt:

Was ist mir wichtig?

Habe ich Dinge, an denen mein Herz hängt? Die Antwort lautet: “Ja” und zwar z.B.

• Fotos, Videos
• bestimmte E-Mails
• Systemeinstellungen
• Programm-Einstellungen
• selbst geschriebene Scripte
• Dokumente

Gibt es nicht ganz so wichtige Daten?

Gibt es Dinge, die ich zwar sichern möchte, aber es vielleicht nicht so schlimm ist, wenn ich sie doch verliere? Dies wird später wichtig, in welche Sicherungs-Archive ich Dateien zuordne. Zum Beispiel:

• ISO-Dateien von gekauften CDs
• alte Installations-CDs von Steuer- oder Finanzsoftware

Habe ich unwichtige Dinge?

Kann ich Daten sparen bzw. das Backup kleiner machen? Kann ich Dinge ausschließen? Beispiele:

• temporäre Dateien
• Download-Ordner
• thumbnails-Ordner
• Cache-Ordner

All das verringert unter anderem die Größe eines Archivs, was wiederum kosten spart. Eine größere externe Festplatte oder mehr Cloud-Speicherplatz kosten nun mal Geld. Dateien, die beim Backup übergangen werden können, sparen zudem Zeit, weil sie nicht gelesen werden müssen. Das hat den Vorteil, dass auch der einzelne Lauf schneller geht, was wiederum mehr motiviert, ein Backup durchzuführen.

Je nach Art des Backup-Programms gibt es unterschiedliche Möglichkeiten, entweder bestimmte Dateien oder Pfade zu definieren, die ich ausschließen möchte. Zum Teil lassen sich sogar generische Muster von Dateinamen oder Verzeichnispfaden definieren. Diese Muster sind flexibler als starre Listen, weil ich dann nicht mehr absolut und gewissenhaft jeden einzelnen thumbnails-Unterordner definieren muss.

Einige Backup-Programme unterstützen auch eine Datei namens CACHEDIR.TAG .
Dies ist eine simple Text-Datei, die einen bestimmten Inhalt haben muss. Befindet sich diese Datei in einem Ordner (zum Beispiel der Download-Ordner) so wird dieser Inhalt vom Backup-Lauf ausgenommen. Wie die Datei genau aussehen muss, habe ich in diesem Blog-Artikel beschrieben.

Vertraulichkeit

Zudem wollte ich ein Backup haben, das für andere Personen wertlos ist, wenn es ihnen in die Hände fällt. Hier bietet es sich an das Archiv Archiv zu verschlüsseln.

Wie will ich sichern?

Ich habe mich für eine dateibasierte Sicherung entschieden. Vielfach musste ich in der Vergangenheit bisher nur einzelne Dateien oder Ordner wiederherstellen. Im allerschlimmsten Fall, musste ich meinen Rechner komplett neu aufsetzen. In diesem Fall habe ich die Installationsmedien des Betriebssystems und der jeweiligen installierten Programme zu Hause vorrätig.

Alternativ müsste ich mir die Medien aus diesem Internet neu herunterladen. Es gibt zwar Tools, mit denen man die komplette Festplatte inklusive ihrer Konfigurationen sichern kann, aber dies erfordert meist mehrere Handgriffe und eine Downtime des Rechners. Die Erfahrung zeigt, dass man dies nur selten macht, eben weil es so umständlich ist. Als initiale Sicherung mag dies jedoch eine gute Idee sein.

Insofern wollte ich eine bequeme Lösung haben, wo ich nicht viel tun muss. Ich wollte nicht allzu oft meine externe Festplatte anschließen, denn das bietet sonst nur Ausreden Nahrung.

Und was ist mit dem Betriebssystem?

Ich habe vom jeweiligen Betriebssystem ein Installationsmedium; das reicht mir. Im schlechtesten Fall muss ich den kompletten Rechner neu aufsetzen; egal ob Windows oder Linux. Im schlimmsten Fall sind die Installationsmedien auch noch aus dem Internet herunterladbar.

3-2-1

Hinweis

Hinweis: Das 3-2-1-Prinzip bedeutet in kurz:
Du hast drei Kopien auf zwei unterschiedlichen Medien, wobei eine Kopie außerhalb liegt.

Schnelle Sicherung: lokal

Was im Grunde übrig bleibt, sind viele Dateien unterschiedlicher Größe und Wichtigkeit. Sehr lange habe ich dafür BorgBackup benutzt, einfach auch weil es bei meiner Distribution dabei war und ich mich dann nicht um Programm-Updates kümmern muss(te). Inzwischen verwende ich restic - zu den Gründen komme ich später.

Die allererste Sicherung geht erst einmal lokal auf die Festplatte in einem extra Bereich; unter Linux ist das bei mir der Pfad /backup. Die Dateisystem-Rechte sind so gesetzt, dass hier nur ein Benutzer mit administrativen Rechten herankommt. Das schützt unter anderem vor versehentlichen Löschen.

Die eigentliche Arbeit erledigt ein selbst geschriebenes bash-Script. Dieses Script kann z.B. beim Runterfahren des PCs verwendet werden. Der Vorteil: Ich muss dem Script nicht zugucken und alle Programme sind geschlossen. Dies ermöglicht ein konsistentes Backup der Dateien, weil sich keine Dateien mehr ändern. Ggf. kann ich dies sogar remote per ssh vom Handy aus aufrufen, weil ich für ein bash-Script keine Oberfläche benötige.

Wenn das Script fertig ist, fährt es den PC komplett runter und schickt mir eine Discord-Nachricht aufs Handy mit einer Statusmeldung. Für dieses Script habe ich mich schon vor einiger Zeit in einen eigenen Blog-Artikel verfasst.

Wenn das Script fehlerfrei durchgelaufen ist, kann ich die Steckerleiste ausschalten und habe keinen Standby-Stromverbrauch mehr. Im Fehlerfall weiß ich Bescheid, dass irgendwo ein Fehler passiert ist und ich evtl. kein aktuelles Backup habe.

Auf Servern starte ich dieses (ggf. abgewandelte und angepasste Script) automatisch per crontab. Im Fehlerfall weiß ich Bescheid, dass ich bei nächster Gelegenheit mal auf das System gucken sollte, was da genau schief gelaufen ist. Im einfachsten Fall ist es eine Datei, die sich dann im laufenden Betrieb geändert hat, aber auch schon volle Backup-Partitionen hatte ich. Ja, Monitoring auf den privaten Systemen Punkt 3.520.230 auf meiner TODO-Liste.

Aufräumen

Am besten räumt man vorher auf, hat also etwas Datendisziplin. Mehrere Versionen einen Schnappschusses bereinigt man um die Version, die man aufheben möchte. Eigene Filmaufnahme oder Filmschnipsel kürzen und verwackelte, unscharfe Handyvideos fressen auch nur unnötig Platz.

Die Programme borg bzw. restic können Sicherungen zudem automatisch ausdünnen. Über Parameter kann ein Backup anhand definierter Regeln ausgedünnt werden. Beispielweise bleiben die letzten 7 täglichen Backups erhalten und für den Rest des Monats wird ein wöchentlicher Schnappschuss aufbewahrt. Danach wird nur der neueste monatliche Schnappschuss aufbewahrt. Durch die fest definierten Regeln, wird ein manuelles und damit meist fehlerträchtiges Heraussuchen vermieden.

Sicherung Cloud

Das selbe Script hat einen optionalen Schalter, wo diese Sicherung “in die Cloud” angeschaltet werden kann. Dieser Schritt kommt zwischen dem Ende der lokalen Sicherung und dem letztendlichen Herunterfahren des Rechners.

Offsite-Backup

Um eine weitere Kopie meiner Daten zu haben, habe ich mir zwei externe Festplatten beschafft. Eine liegt immer neben dem Rechner, ist aber nicht angeschlossen, die andere liegt bei meinen Eltern. Die externen Platten sind außen beschriftet und haben auch ein Software-Label, so dass ich sie beim Einhängen in das Dateisystem unterscheiden kann. Alle paar Tage stöpsle ich dann die externe Festplatte an und synchronisiere die lokale Sicherung vom dem PC auf diese. Nach der Sicherung stöpsle ich sie wieder ab und die Festplatte ist dann vor versehentlichen Löschen sicher.

Diese Festplatte bringe ich dann alle paar Wochen zu meinen Eltern und tausche sie mit dort liegenden Festplatte aus. So habe ich im Fall der Fälle (Hausbrand, Einbruch usw.) eine weitere Kopie an einem anderen Ort. Der Stand der Sicherung ist dann möglicherweise ein paar Wochen alt, aber immerhin besser als ein Totalverlust.

In der Summe sind die Daten jetzt fünfmal vorhanden.

Aber !?!

Die Kosten

USB-Festplatten

Die externen Festplatten tausche ich alle paar Jahre aus. Nicht nur weil sie irgendwann zu klein werden, sondern ich möchte Bitfäule und mechanischem Ausfall vorbeugen. Die Variante als drehenden Rost ist derzeit noch die billigste Variante pro Gigabyte.

Cloud

Ja auch Cloud-Storage-Anbieter möchten Geld verdienen; schließlich müssen Server und Personal irgendwie bezahlt werden.

Alternative?

In der Summe sind mir meine Daten lieb und diesen Preis wert. Die Alternative wäre ein Totalverlust und das möchte ich nicht.

Sync

Das führende Backup ist die Sicherung auf dem lokalen PC. Zum Synchronisieren auf die externe Platte nutze ich rsync, in die Cloud verwende ich rclone. Beide Tools haben mehrere Vorteile. Das lokale Backup hat einen konsistenten Stand. Die Synchronisation kann im Hintergrund laufen. Weil der neueste Stand immer lokal vorhanden ist, müssen nur die Differenzen in die Cloud oder die externe Festplatte übertragen werden, d.h. es geht sehr schnell. Zudem muss ich mir keine Gedanken machen, wo wie welcher Stand ist und ob und wo ich irgendwelche Voll- oder inkrementelle Backups gemacht habe oder noch machen muss. Auch das automatische Ausdünnen bzw. aufräumen der Backups wird dann auf allen Zielen automatisch mitgezogen bzw. vollzogen. Da ich nur stumpf Dateien hin und her kopiere, ist die Wahl des Backup-Programms (borg oder restic) irrelevant.

Online-Speicher aka Cloud

Cloud !!!111EinsElf Oh! Nein! Doch!

Die Programme borg bzw. restic können Out-of-the-box stark verschlüsseln. Die Archive können mit einer Datei oder einen starken Passwort gesichert werden. Insofern kann ist Wahl des Anbieters für den Cloud-Storage unabhängig von dessen Vertrauenswürdigkeit. Mit den verschlüsselten Dateien kann ohne das Passwort niemand etwas anfangen. Somit können Parameter wie Zuverlässigkeit, Geschwindigkeit und der Preis entscheiden.

Ich persönlich habe mich aufgrund Mariannes restic-Artikel ebenfalls für Backblaze entschieden. Das Tool rclone synchronisiert wie gefordert die dateibasierte Sicherung und unterstützt deren Produkt B2 Cloud.

Download kostet aber

Backblaze verlangte für den Download der Daten Geld; inzwischen gibt es ein bestimmtes Freikontingent. Andere Anbieter verlangen allerdings auch zum Teil Download-Gebühren.

Hier stellte ich mir die Frage, wann ich jemals Download-Traffic in Anspruch nehmen werde. Ja genau, beim Recover. Und diesen Fall wollte ich erstens so selten wie möglich und wenn, dann ist der Cloud-Speicher ja einer meiner Standbeine. Und im Fall einer Wiederherstellung sind mir die Daten so wichtig, dass ich das Geld auch gerne ausgebe, um die wiederzubekommen. Schließlich war genau dies der Zweck, den der Anbieter erfüllen sollte.

Im Bestfall kann der Großteil der Sicherung auch von der externen Festplatte gezogen werden und es müssen nur noch die Differenz aus der Cloud heruntergeladen werden. Dadurch minimiert sich dann die Größe der Dateien, die heruntergeladen werden müssen. Und damit sinken die Download-Kosten und natürlich auch die benötigte Zeit.

Beispiel

Genau so einen Fall hatte ich vor einiger Zeit schon einmal. Ich wollte eine alte, externe Festplatte verschenken und daher diese sicher löschen. Ich hatte leider nicht gut genug aufgepasst und mit dc3dd die falsche Partition geschreddert; inklusive der lokalen Backup-Kopie unter /backup. Die letzte Sicherung auf der externen Festplatte war drei Wochen alt, weil ich wohl zu diesem Zeitpunt längere Zeit zu faul war sie anzustöpseln. Der Stand im Cloud-Speicher war aber vom Vortag. Yay! Das war meine Rettung. Einige E-Mails lagen eh noch auf dem IMAP-Server und ein paar Downloads wie Rechnungen, Kontoauszüge, musste ich dann eben neu herunterladen. Das Delta aus der Cloud war damit gering und ging schnell von statten. Im Grunde hatte ich kaum etwas verloren. Ohne Cloud-Backup wären mir drei Wochen Daten flöten gegangen, es hat mir wortwörtlich den Hintern gerettet.

Jeder Ort ein Repo

Hier gehe ich einen anderen Weg, als allgemein empfohlen. Viele Backup-Konzepte raten dazu für jedes Ziel (lokale Festplatte, externe Festplatte oder Cloud) einen komplett neuen Lauf zu starten. Aus meiner Sicht laufen die Stände dann auseinander. Man hat überall unterschiedliche Stände. Wenn ich eine Datei wiederherstellen möchte, muss ich gucken welcher meiner Sicherungsorte die gewünschte Datei zu einem vorhandenen Sicherungszeitpunkt noch beinhaltet. Außerdem dauern die Sicherungen länger, weil wieder alle Quell-Dateien neu eingelesen werden müssen, um zu schauen, welche Dateien sich geändert haben. Dieser Schritt fällt bei mir weg, weil die Anzahl der Dateien in meinem Backup prinzipbedingt schon geringer ist und die Daten schon komprimiert wurden. Das Übertragen auf einen weiteren Ort, geht also wesentlich schneller. Zudem müsste ich so mehrere Scripte vorhalten, die nur unterschiedliche Zielpfade haben, oder das Script so generisch schreiben, dass wiederum die Komplexität steigt und Wartbarkeit leidet.

In meinem Fall ist es ein einfacher rsync oder rclone-Aufruf.

Wann

Linux

Ich habe mich bewusst gegen einen Automatismus an meinem persönlichen Desktop-PC entschieden. Es erfordert etwas Disziplin, hat sich bisher aber für mich bewährt.

Aktuell kann ich spontan entscheiden, ob ich den PC nur schnell runterfahren möchte oder ob ich ein Backup fahren möchte. Wenn ich mich entscheide, kein Backup zu machen, weil ich z.B. nur schnell ein paar E-Mails geschrieben habe, kann ich den PC schneller wieder runterfahren. Das Ausschalten über die Steckerleiste hilft mir dann wieder Strom sparen.

Habe ich viele Änderungen an den Daten vorgenommen und entscheide ich mich für das Backup, wird eine lokale Kopie auf dem Rechner angelegt. Dies kann auch durchaus mehrmals am Tag sein. Am Ende des Tages setze ich dann per Script-Parameter, dass im Anschluss eine Synchronisation in die Cloud stattfinden soll. Ich kann dann den Rechner verlassen und mich anderen Dingen widmen. Etwas später, z.B. kurz vor dem ins Bett gehen, kann ich dann die Steckerleiste ausschalten. Die automatische Discord-Benachrichtigung zum Schluss des Scriptes erinnert mich daran. Da ich das Script kurz vor dem Runterfahren des Rechners ausführe, ist auch egal wie lange es dauert. Solange ich außerhalb jeglichen Glasfaser-Ausbau-Gebieten wohne, muss ich nun mal mit der langsamen Upload-Leitung leben.

Was

Unter Linux sichere ich z.B. den /etc-Baum, wo viele Einstellungen und Konfigurationen liegen. Der größere Teil liegt dann im Benutzer-Verzeichnis (bei mir unterhalb von /home). Genauere Details dazu wird es mal in einem späteren Blog-Artikel geben.

Wiederherstellung

Das letzte Mal, als ich mein System wiederherstellen musste, hat es gereicht /etc als auch /home neu einzuspielen und ich war überwiegend wieder arbeitsfähig. Die Programm-Installation unter Linux gestaltet sich relativ einfach und unkompliziert, zumindest bei den Dingen, die von der jeweiligen Distribution mitgeliefert werden.

Windows

Bei Familienmitgliedern, die Windows verwenden, läuft das Backup-Script wiederum beim Anmelden am System. Ich habe noch keine Möglichkeit gefunden, dass es beim Herunterfahren ausgeführt wird. Ein extra Klick mit einer Verknüpfung hat sich nicht bewährt, weil es gerne vergessen wird und der Rechner einfach nur stumpf via Windows-Menü heruntergefahren wird. Durch den automatisierten Aufruf während des Logins, entfällt ein manueller Eingriff und es läuft jedes Mal.

Was

Bei Windows im Enduser-Bereich sichere ich ebenfalls hauptsächlich den Benutzerordner, da dort vieles wichtiges abgelegt ist. Mir ist klar, dass auch durchaus einige Einstellungen in der Registry stehen, aber für die weitere Recherche reicht meine Motivation nicht. Wahrscheinlich ist es eh besser, im K-Fall¹ das System komplett neu aufzusetzen und dann nur die Benutzerdaten wiederherzustellen.

Server

Zu Hause läuft noch ein NAS-System mit virtuellen Servern. Dort wird mittels Crontab fast dasselbe Backup-Script ausgeführt. Der Sync in die Cloud findet allerdings täglich statt. Da ich noch Webanwendungen betreibe, ist das Backup-Script etwas aufgebohrt. Je nach Dienst dreht es noch ein paar Schleifen.

Beispielsweise hat das interne Kanboard eine Datenbank-Anbindung. Vor dem Start der dateibasierten Sicherung wird noch ein logischer Datenbank-Dump in ein Verzeichnis geschrieben, dass dann ebenfalls mitgesichert wird. Ich weiß, dass es da z.T. bessere Möglichkeiten gibt, als ein schnöder mysqldump. Da ich schon mehrfach das Kanboard und andere Dienste wiederherstellen konnte, hat es für mich bisher so gereicht.

Anwendungen in Docker-Containern stoppe ich vorher, um einen konsistenten Stand zu sichern oder fahre, wie bei paperless, einen automatisierten Export der Daten in das Dateisystem.

Recover testen

Auch das Thema Recover, also der Wiederherstellen der Daten, sollte man nicht unterschätzen. Testet Eure Backups und versucht die Daten wieder herzustellen!

Nichts ist schlimmer, als wenn man meint immer ein Backup gemacht zu haben und man dann feststellen muss, dass es kaputt ist oder wichtige Dinge fehlen. Der Test schützt vor dem Verlust wichtiger Dateien bzw. Daten. Wenn Ihr Software wie zum Beispiel Tandoor Recipes aufsetzt, befüllt sie zu Anfang mit nur ein paar wenigen Daten. Dann macht Ihr ein Backup und löscht die komplette Installation. Im nächsten Schritt versucht Ihr die Anwendung oder auch die Daten aus dem Backup wieder herzustellen.

Pro-Tipp am Rande: Dokumentiert in diesem Fall gleich, wie ihr vorgegangen seid, die Daten wieder herzustellen. Wenn Ihr Daten verloren habt, befindet Ihr Euch meist sowieso in einer Stress-Situation. Wenn ihr dann noch rausfinden müsst, wie ihr wieder an Eure Daten kommt und wie der alten Zustand wieder hergestellt werden kann, bedeutet das zusätzlichen Stress, den ihr mit diesem Vorgehen vermeiden könnt. Eine gute Anleitung erleichtert später die Arbeit und trägt wesentlich zur Entspannung bei.

Verfeinerung

Sortierung nach Wichtigkeit

Ich sortiere meine Backups in unterschiedliche Container bzw. Repositorys.

Es gibt persönlich mir wichtige Sachen, wie E-Mails und Bilder, selbst geschriebene Scripte etc. Dann gibt es nicht so wichtige Dinge, wie ISO-Dateien von gekauften CDs oder alter Installations-CDs von Steuer- oder Finanzsoftware.

Einige Dateien ziehe ich auch über das Netz, wie das Backup-Archiv vom NAS. Dies dauert dann länger und daher möchte ich das nicht immer machen.

Es gibt ein extra Repo und Script für die Sicherung meiner digitalen Bilder. Dies erfordert durchaus Disziplin, um da den Überblick zu behalten, aber die Bilder-Ordner erfahren aber auch nicht so oft eine Änderung, als dass das täglich nötig wäre.

Ebenso gibt es Backups-Repos, die nur auf der externen Festplatte landen und nicht in der Cloud.

Meta-Daten

Ein paar wichtige Meta-Daten, wie die Aufteilung der Festplatte, schreibe ich ebenso automatisiert während des Backup-Laufs in einen speziellen Unterordner. Diesen sichere ich gleich mit.

Auch Infos zum LVM, Filesysteme oder installierte Pakete speichere ich in Textdateien und nehme diese Pfade in zu sichernden auf.

 1# Partitionen
 2parted -l > "${METAINFOSDIR}/parted-l.txt"
 3# Filesysteme
 4mount >> "${METAINFOSDIR}/parted-l.txt"
 5# Software-Pakete
 6pacman -Qqet > "${METAINFOSDIR}/manjrao_installierte_pakete"
 7pacman -Qqm > "${METAINFOSDIR}/manuell-installierte-pakete.txt"
 8# LVM-Infos
 9vgdisplay >  "${METAINFOSDIR}/lvm_infos.txt"
10pvdisplay >> "${METAINFOSDIR}/lvm_infos.txt"
11lvdisplay >> "${METAINFOSDIR}/lvm_infos.txt"

Probleme: Borg

Lange Zeit habe ich borg für meine Sicherungen benutzt. In der Vergangenheit hatte ich ein paar Unschönheiten, die ich aber lösen könnte. Irgendwann hatte ich Probleme meine Sicherung in die Cloud zu schieben; doch der Reihe nach.

Anderer Ort

Dadurch, dass ich meine Repos immer nur per rsync übertrage, nörgelt borg, wenn ich mal einen Blick in das Archiv werfen wollte, was auf einer externen Festplatte liegt.

1borg list bilder
2Warning: The repository at location /run/media/rainer/backup_hdd_1/backup_nuc/bilder was previously located at /backup/borgbackup/bilder
3Do you want to continue? [yN]

Vielleicht war es ein Bug oder es gab ein anderes Problem. Es gab mal eine Zeit, wo genau dieser der Zugriff außerhalb des Original-Ortes meiner Erinnerung nach verweigert wurde. Eine Lösung hatte ich damals gefunden. Durch das oben beschriebene Konzept mit rsync konnte ich es z.B. wieder an den ursprünglichen Ort kopieren. Danach war der Zugriff wieder möglich. Ich kann es derzeit nicht mehr nachstellen; aktuell scheint es wieder zu gehen, wenn die Frage einfach bejaht wird. Es ist mir negativ im Gedächtnis geblieben und es schwirrte schon lange die Idee in meinem Kopf herum, dass ich mich um eine Alternative zu borg kümmern müsse.

Große Dateien

Ausschlaggebend für den endgültigen Wechsel war ein Problem mit Backblaze vor einiger Zeit.

Wie weiter oben beschrieben habe ich mehrere Repos. Eines der größeren Archive mit ca. 66 GB machte beim Upload nach B2 Probleme:

Das Logfile war sehr hilfreich - nicht:

1 data/0/31: Error sending chunk 0 (retry=true): incident id ec43eb366fa6-744fae19214412f6 (500 internal_error): &api.Error{Status:500, Code:"internal_error", Mes 

Ich lernte, dass es bei größeren Repos, wie dem 66 GB in meinem Fall, irgendwann recht große Dateien (ca. 500MB pro Stück) mit borg entstehen.

 1ls -hl data/0/ |head
 2insgesamt 46G
 3-rw------- 1 root root 503M 29. Sep 2022  10
 4-rw------- 1 root root 504M 11. Okt 2022  100
 5-rw------- 1 root root 503M 11. Okt 2022  101
 6-rw------- 1 root root 501M 11. Okt 2022  102
 7-rw------- 1 root root 503M 11. Okt 2022  103
 8-rw------- 1 root root 503M 11. Okt 2022  104
 9-rw------- 1 root root 502M 11. Okt 2022  105
10-rw------- 1 root root 504M 11. Okt 2022  106
11-rw------- 1 root root 501M 11. Okt 2022  107

Dieses führte beim Upload zu Backblaze Problemen und warf daher mehrere Fehler beim Ausführen von rclone.

Bei meinen Recherchen in diesem Internet fand ich folgenden Blog-Artikel mit dem Titel What To Do When You Get a B2 503 (or 500) Server Error.

Im Grunde steht da nur stumpf, dass man es nach einer gewissen Zeit nochmal probieren soll. Nach ein paar Tagen mit dem selben Fehlerbild war ich genervt und las den Artikel nochmal genauer. Dort wird auf B2 error handling protocols verwiesen, wo unter dem Absatz “Multithreading Uploads” Hinweise in Bezug auf Dateien größer als 200 MB gegeben werden. Diese Dateien sollen beim Upload gesplittet werden und dann parallel hochgeladen werden. Ich vermute mal, dass das rclone unter der Haube macht; nachgeschaut habe ich nicht.

Bisher war nur ein Repo betroffen und andere Repos konnte ich problemlos nach Backblaze hochladen bzw. synchronisieren mittels rclone.

Große Lust dem Backblaze-Support hinterherzulaufen oder debugging im rclone-Umfeld zu betreiben, hatte ich nicht.

Umstieg auf restic

Damit war die Entscheidung gefallen; ich würde alle meine Backup-Scripte auf restic umstellen. Ein kleiner Test ergab, dass ein restic-Lauf zwar wesentlich mehr Dateien der selben Quell-Dateien ergab, aber auch wesentlich kleinere. Da ich alle meine Backups in einem Unterverzeichnis sammle, war die Analyse mittels find recht simpel.

1find borgbackup -size +200M | wc -l

Das Ergebnis: 816 Treffer.

Mein Testverzeichnis mit dem selbigen problembehafteten Dateien bzw. Repo in restic gebaut ergab keine Treffer

1find resticbackup -size +200M | wc -l

und es ging wesentlich schneller. Alleine der initiale Durchlauf beim allerersten Erstellen des Archivs war um Zeitfaktor 10 schneller. Es waren nur zwei statt zwanzig Minuten nötig, was mich zusätzlich bestärkt hat umzusteigen.

Erleichterungen

Um mich noch etwas unabhängiger im K-Fall zu machen, speichere zusätzlich das restic-Binary noch im Verzeichnis aller restic-Repos. Dieses wird dann ebenfalls via rsync mit auf die externen Festplatten kopiert, so dass ich immer eine aktuelle Version habe.

Für Neuigkeiten abonniere ich noch den RSS-Feed und habe einen Watcher auf die Github Releases. Aber das ist einen extra Blog-Artikel wert.

Tipps und Tricks zu Bedienung lege ich in eine extra Datei namens restic-hilfe.md. Hier stehen dann die wichtigsten Befehle zum Wiederherstellen der Dateien und zum Mounten des gewünschten Repos ins aktuelle Dateisystems.

Alles im Sinne der Stress-Reduzierung während eines potentiellen Recover-Scenarios.

Ende

Ich hoffe, ich konnte ein paar Einblicke in meine Überlegung zu meiner Backup-Strategie geben. Vielleicht hilft es dem einem oder anderen ein Konzept selbst zu überlegen oder sein oder ihr existierendes anzupassen.

Wenn Ihr ich jetzt nach den Scripten fragt, muss ich Euch auf die Zukunft vertrösten. Die Scripte selbst sind einen eigen Blog-Artikel wert.

Ausblick (Update)

Inzwischen habe ich auf den Chemnitzer Linux-Tagen einen Vortrag über restic gehalten. Auch habe ich vor demnächst^tm die Scripte auf resticprofile umzustellen. Über beide Tools erzähle ich was in meinem Vortag.

Changelog