Paperless-ngx, Teil 10: Das Rundum-sorglos-Backup

Der Aufbau unseres digitalen Archivs hat Zeit gekostet, die analoge Papierversion wurde entsorgt oder in den Keller verbannt, wir sind zufrieden, dass unser System rund läuft. Höchste Zeit für eine Backup-Strategie, die für einen Rundum-Schutz sorgt: Dokumente, Dateipfade, Tags, Notizen – ja, das gesamte System soll gegen alle Arten von Notfällen abgesichert werden. Und das in einer Art und Weise, die kaum Zeit oder Mühe beansprucht.

4-3-2-1 – Die besondere Backup-Strategie

Bekannt ist die 3-2-1-Regel für Backups: 3 x Daten (1 Original + 2 Backup-Versionen) auf 2 unterschiedlichen Speichermedien und 1 Sicherung außer Haus. Das gilt für „normale“ Computer oder Server. Aber beim Raspberry Pi können wir einen Klon des vollständigen „PCs“ in einer Streichholzschachtel aufbewahren, das ist Nr. 4. Dazu gleich mehr.

Zunächst zu den üblichen 3-2-1 Bedingungen: Für die lokale Sicherung taugt jedes übliche Speichermedium: eine zweite SD-Karte, ein USB-Stick, eine SSD, ein NAS usw. – Was man halt gerade zur Hand hat.

Für die Außer-Haus-Speicherung werde ich hier den Weg über eine Cloud-Sicherung beschreiben. Dabei ist es höchst gleichgültig, ob man Google Drive oder die Varianten von Microsoft bzw. Apple nimmt – die Daten werden trotzdem perfekt geschützt sein. Aber als Nextcloud-Anwender werde ich das Vorgehen mit dieser Cloud beschreiben.

Verschlüsseltes Cloud-Backup mit Duplicati

Duplicati gehört zu den bekannten Backup-Programmen, kann sehr viel und ist mit einer guten Nutzeroberfläche ausgestattet. Eine ältere Version gibt es zwar im Paketmanager vom Raspberry Pi, aber man kann problemlos mit der neusten arbeiten: Einfach auf die Homepage von Duplicati gehen, dort zu „Downloads“ und das Debian-Paket runterladen. Anschließend den Paketinstaller anklicken – fertig.

[Grafiken vergrößern = Klick auf die Grafik]

Duplicati kann über das Startmenü aufgerufen werden – es öffnet sich eine Weboberfläche für das Programm (localhost:8200). Dort konfiguriert man eine neue Sicherung:

Im ersten Schritt wird die Verschlüsselung aktiviert – die Voreinstellung „AES-256“ ist ausreichend:

Nun wird das Sicherungsziel ausgewählt. Sofern man eine Nextcloud verwendet, hat man zwei Möglichkeiten: Entweder man richtet zuvor den Desktop-Sync-Client ein (ist im Paketmanager des Raspberry Pi vorhanden) und trägt dort einen lokalen Pfad für den Sync der Backups ein (z.B. „/home/pi/paperless_backup“). Bei dieser Variante wählt man in Duplicati „Lokaler Ordner oder Laufwerk“ für die Speicherung aus – der Nextcloud-Client besorgt später den Rest.

Oder man wählt „WebDAV“ aus, dann klappt es auch ohne die Installation des Nextcloud-Clients. Ich habe in meiner Nextcloud einen zusätzlicher Nutzer namens „Paperless“ angelegt, so dass dieses Konto nicht durch andere Dateien belegt wird. Den notwendigen WebDAV-Link findet man im Dateibereich der Nextcloud, linke Sidebar, unten „Einstellungen“. Den kopiert man in die Zwischenablage und setzt ihn bei Duplicati zusammen mit seinen Nextcloud-Zugangsdaten ein.

Wichtig: Nicht die Protokollbezeichnung „https://“ im Serverfeld verwenden – aber „SSL“ ankreuzen. Anschließend wählt man den Pfad von Paperless-ngx aus. In den Unterpfaden befinden sich ja nicht nur Originale- und Archiv-Dateien – auch der Ordner „export“, in dem alle Einstellungen gespeichert sind.

Einen Zeitplan kann man ebenfalls einstellen. In diesem Beispiel wird 5 Uhr morgens, täglich, gewählt. Unser Raspberry Pi ist ja durchgehend in Betrieb, so dass er solche arbeiten gut in den frühen Morgenstunden erledigen kann.

Jetzt fragt Duplicati noch, ob mehrere Sicherungs-Version aufbewahrt werden sollen. Man könnte z.B. auswählen, dass die 3 letzten Version in der Nextcloud gespeichert werden sollen. Mit der Einstellung „Intelligente Sicherungsaufbewahrung“ fährt man aber recht gut. Man kann auf diese Weise vergangene Backups auswählen, ohne dass zu viel Speicherplatz in der Nextcloud belegt wird.

Zur angegebenen Zeit startet das Backup. Dabei kommt eine Variante des inkrementellen Backups zum Zuge, es werden also nur neue/geänderte Daten übertragen (in Wirklichkeit ist die Art des Duplicati-Backups noch cleverer, aber das würde hier zu weit führen).

In der Cloud landen die Dateien verschlüsselt – sie sind also für keinen Hoster einsehbar.

Über den Menüpunkt „Wiederherstellen“ lässt sich das letzte oder ein früheres Backup zurückspielen. Wenn nur eine einzelne Datei beschädigt ist, so kann man diese gezielt auswählen:

Damit ist Schritt 1 erledigt: Egal, ob Wasserschaden, Blitzeinschlag oder spielendes Kind – eine Rekonstruktion unseres Dokumentenarchivs ist im Falle des Falles außer Haus untergebracht. Verschlüsselt, in einem professionellen Rechenzentrum, von Fachpersonal betreut. Zudem wird das Archiv von Duplicati gepackt – es genügt also ein kleiner Serverbereich, den man bei seinem Cloud-Speicher vielleicht ohnehin noch übrig hat.

Lokales Backup

Back In Time

Wenn man ohnehin Duplicati für das Backup in der Cloud nutzt, so kann man darin einfach einen zweit Job erstellen, der diese Aufgabe übernimmt. Den eingehängten Ziel-Speicher, etwa eine SSD, findet man über das Root-Verzeichnis, dort /media/nutzer/speichermedium:

Allerdings: Falls nach einem Update mal was mit Duplicati nicht korrekt verläuft, so könnten sich gleich in beide Backups Fehler einschleichen. Etwas sicherer fährt man also mit einem zweiten Backup-Tool. Es gibt da unter Linux unzählige Möglichkeiten – mir gefällt besonders gut „Back In Time“ (die Basis für das Tool bildet rsync).

Das ist im Paketmanager von Raspberry Pi OS vorhanden, lässt sich also mit einem Klick installieren. Durch die klare Oberfläche wird die Auswahl von Quelle und Ziel bei der Konfiguration kein Problem darstellen – die Darstellung ähnelt der von Dateimanagern:

Für das lokale Backup würde ich auf die Verschlüsselungsoption verzichten, da sie keine Vorteile bringt. Die Daten liegen ja ohnehin auf dem Raspberry Pi offen – ein Agent der Gegenseite würde also einfach die kleine Schachtel in seine Jackentasche stecken 😉 Der Zielspeicher muss zwar im Linux-Forma formatiert sein (also z.B. EXT4 und nicht FAT), aber Tools wie Rufus & Co. erledigen das ja mit einem Klick. Notwendig ist dies, damit auch bei diesem Backup Speicherplatz gespart wird. Und wegen der „Zeitmaschine“. Man kann in Back In Time sehr bequem in der Zeit reisen und Dateien eines früheren Backups reaktivieren.

Wie bei Duplicati ist auch die Zeitplanung eingebaut, die man mit ein paar Haken einrichten kann. Oder man nimmt die Einstellung, dass das Backup immer durchgeführt wird, wenn man das Speichermedium einhängt usw.

Borg-Backup mit Vorta

Wer mit Linux etwas vertrauter ist, dem ist sicher schon einmal der Begriff „Borg“ für Backups untergekommen. Eine Sicherungsvariante, die von vielen sehr geschätzt wird, aber in der Einrichtung nicht ganz einfach ist. Mit Vorta steht eine Oberfläche für diese Art des Backups zur Verfügung, die sich mit einem einfachen Befehl in der Kommandozeile installieren lässt:

sudo apt install vorta

Über das Raspberry Pi-Desktop-Menü lässt sich Vorta anschließend aufrufen und einrichten:

Damit könnte man auch ein Backup auf ein NAS überspielen. Aber da gibt es auch zahlreiche andere Möglichketen, über ein Netzwerk eine Sicherung herzustellen (NFS wäre hier ein Stichwort).

Backup von allem: SD-Karte mit 1 Klick klonen

SD Card Copier

Eine Besonderheit des Raspberry Pi ist, dass auf der microSD-Karte (oder einem USB-Speichermedium) das gesamte lauffähige System liegt. Eingebaut in Raspberry Pi OS ist ein Tool, mit dem sehr einfach eine Dublette erzeugt werden kann: „SD Card Copier“.

Dabei müssen Quell- und Zielmedium nicht die gleiche Größe haben (das Zielmedium muss halt groß genug sein, um alle Dateien aufzunehmen).

Also: Leere microSD-Karte z.B. mit einem USB-Adapter in den Raspberry Pi stecken und auswählen (= Auf Gerät kopieren). Quell-Laufwerk (= Von Gerät kopieren) ist jene Karte, mit der der Raspberry Pi gerade läuft. Je nach Umfang der Sicherung etwas warten (bei mi meist um die 10 Minuten). Danach hat man eine 1:1 Kopie seines Raspberry Pi-Systems, das man in die Schublade für Notfälle legen kann. Sollte später etwas nicht mehr funktionieren – einfach diese Karte einstecken und der Raspberry Pi ist sofort wieder lauffähig. Natürlich funktioniert auch Paperless-ngx umgehend, lediglich die neuen Dateien müssen hinzugefügt werden. Aber durch das regelmäßige Backup des Export-Folders ist das eine Sekundensache.

PiSafe

Es müssen nicht physische Karten sein – mit dem Tool PiSafe können auch Image-Dateien angefertigt werden, die man regelmäßig speichert und erst bei Bedarf auf ein Medium überspielt. Enthalten ist PiSafe ist der absolut empfehlenswerten Tool-Sammlung „Pi Apps“. Wieder genügt ein Klick – und die Anwendung ist installiert.

PiSafe führt automatisch eine Reihe von Anwendungen aus (dd-Befehl, pi shrink usw.). Das Ergebnis: Man erhält eine sehr kleine Image-Datei (bei mir waren auf einer 128 GB-Karte ca. 26 GB belegt – die Image-Datei hatte nur 6 GB) – samt Datum im Dateinamen.

Bonus-Tipp: Der Westentaschen-Tresor

Seit ca. 2 Jahren kann ein Raspberry Pi auch über USB-Sticks und andere Medien gebootet werden. Ich persönlich mag allerdings die kleinen Karten, da ich neben Backups auch alternative Betriebssysteme für den Raspberry Pi damit bestücke. So habe ich z.B. eine Karte für Manjaro, eine für Ubuntu usw.

Ganz nett für die Sammlung derartiger SD-Karten sind jene „Scheckkarten“, die man sogar im Geldbeutel mit sich führen kann. Wenn man ein kleines RFID-Etikett drauf klebt, so kann man sich eine Liste mit entsprechenden Vermerken anzeigen lassen. Bei mir öffnet sich die entsprechende Notiz in Obsidian. Aber da Paperless-ngx seit Version 2 auch Links zu Dokumenten zur Verfügung stellt, könnte man sogar dort eine entsprechende Tabelle aufbewahren.

Bisherige Teile der Paperless-ngx-Serie:
Teil 1: Ausführlicher Überblick
Teil 2: Suche & Tags
Teil 3: consume-Ordner – Einsatz von Scannern
Teil 4: Speicherpfade konfigurieren
Teil 5: Installation auf dem Raspberry Pi
Teil 6: Neue Funktionen in Version 2
Teil 7: Dokumente unterwegs über das eigene Modem abrufen
Teil 8: Exportfunktion nutzen
Teil 9: Update durchführen
Teil 10: Das Rundum-sorglos-Backup
Teil 11: Mail-Abruf mit vielen Extras
Teil 12: Mein Alltag mit Paperless-ngx
Teil 13: Ein Quanten-Code für das Papier-Archiv
FORUM für Fragen eröffnet
Teil 14: Automatisierte Ablage auf Speicherpfaden
Teil 15: Neue Funktion für das Verbinden und Trennen von Dokumenten

9 Kommentare

  • Sascha

    Mein System habe ich soweit aufgebaut und alless läuft. Nun habe ich auch die ersten Backup Strategien übernommen und fühle mich soweit sicher gewappnet, meine kommenden Dokumente digital zu verwalten und auch alte Ordner peu à peu einzupflegen. Allerdings mache ich mir ein wenig Sorgen, dass paperless-ngx auf einer SD Karte läuft. Ich habe zwar eine HDD per USB 3.0 für das Backup dranhängen und gerade läuft SD Card Copier zum ersten Mal, aber wäre es nicht sinnvoller, weil sicherer (?) zeitnah das System auf eine SSD Karte (ebenfalls per USB) zu übertragen? Und würde das genau so einfach per SD Card Copier laufen und ich könnte dann einfach die SD Karte rausziehen und booten?
    Vielen Dank und einen schönen Sonntag Abend aus dem Norden!
    Sascha

    • Herbert

      Hallo Sascha, da man von einem USB-Medium (z. B. einem USB-Stick) booten kann, sollte es eigentlich keine Probleme geben (habe ich aber noch nicht getestet). Statt „SD Card Copier“ kannst Du auch PiSafe nehmen: https://github.com/RichardMidnight/pi-safe Das koppelt automatisch Image plus Verkleinerung plus Speicherung usw. – sehr empfehlenswert.
      Zur Frage der microSD-Karte: Da haben etliche Nutzer Bedenken – allerdings habe ich das Gefühl, dass oft die Billig-Varianten genutzt werden. Wenn man z.B. von SanDisk „Extreme“ oder „Extreme Pro“ nimmt, so erreicht man durch eine spezielle Technik, die auf diesen Karten eingesetzt wird, nach meiner Erfahrung sehr hohe Geschwindigkeiten ohne Stabilitätsverluste. Ich setze bevorzugt die 128-GB-Modelle ein – meine Erfahrungen sind seit rund drei Jahren sehr gut.

  • Rainer

    Hallo Herbert, herzlichen Dank für deine ausgezeichnete Beschreibung. Ich habe Paperless-ngx auf einem HP Thin Client mit Debian Bookworm und XFCE installiert. Für das Backup mit Duplicati und Back In Time habe ich deine Anleitung verwendet und beide funktionierten auf Anhieb. Zum Backup habe ich aber noch ein paar grundsätzliche Fragen und vor allem auch zum Restore.

    Ist es sinnvoll, den vollständigen Ordner paperless-ngx zu sichern und nicht nur den export-Ordner? Wie du im Teil 8 beschreibst, kann man die Daten nach einer Neuinstallation mit dem document_importer wiederherstellen.
    Was passiert, wenn ich nach einer Neuinstallation den Inhalt des vollständigen Ordners wieder zurückspiele? Kann es Konflikte mit Ordnern und Daten geben, die während der Neuinstallation angelegt und erstellt wurden?
    Auch das Zurückspielen von einzelne Dateien aus dem Backup halte ich für problematisch. Was passiert in diesem Fall mit den Datenbankeinträgen? Ich würde mich freuen, wenn du in einem weiteren Kapitel das Thema Restore behandeln würdest.

    Im Voraus herzlichen Dank und viele Grüße aus dem Münsterland,
    Rainer

    • Herbert

      Hallo Rainer, die Anregung, etwas zum Restore zu schreiben, nehme ich gerne auf. Auch bei mir läuft Paperless-ngx auf der neuen MX Linux-Version mit XFCE, die speziell für den Raspberry Pi entwickelt wurde. Ausgesprochen schnell und gut 🙂
      Zu Deinen Fragen:
      1. Ruhig den ganzen Paperless-ngx-Ordner sichern, in dem „archive“, „originale“ und „export“ liegen. So bleibst Du unabhängig von Paperless-ngx, sofern Du Dir die Dateipfade so angelegt hast, wie ich es beschrieben habe.
      2. Allerdings für Restore-Vorhaben nur den export-Ordner in den (neuen) Paperless-ngx-Pfad hängen, nicht die Ordner „archive“ und „originale“. Anschließend Import-Befehl – dann sind die neuen „archive“ und „originale“ korrekt rekonstruiert durch den Import-Befehl.
      3. Einzelne Dateien für ich nicht auf den Pfad Paperless-ngx zurück-sichern. Falls wirklich mal mit einem Dokument etwas nicht stimmt: a) In Paperless-ngx löschen, b) clean-Befehl in Paperless-ngx ausführen, c) Dokument aus Backup-„originale“ nehmen und auf den consume-Pfad legen.

  • Florian

    Hallo Herbert,

    ich finde die Anleitung super, ich baue gerade für Freunde jeweils einen Raspberry auf und setze die Tips um.
    Eines wäre für mich wichtig, da der Raspberry PI 400 nicht am Bildschirm angeschlossen wird , sondern als „Mini“ Server in der Abstellkammer steht, frage ich ich mich, ob eine Fernwartung möglich wäre um z.B. die Duplicat oder Borg zu verwalten. Kannst du mir eun Remote Desktop Programm emfpehlen ?

    Grüße
    Florian

  • Thomas

    Hallo,
    danke für die wirklich sehr hilfreichen Beschreibungen. Eine Anmerkung habe ich aber doch: Duplicati startet nicht automatisch beim Neustart des Raspbery Pi. Man muss Duplicati erst neu über das Startmenu starten.
    Schön wäre ein Automatismus nach dem Neustart des Raspberrys. Vielleicht kannst Du die Anleitung entsprechend erweitern.

    • Herbert

      Danke für den Hinweis! Nehme ich gerne auf – werde bei Gelegenheit ergänzen, wie man Programme in die Autostart-Gruppe einpflegt.

  • Rainer

    Hallo Herbert,

    nach einer erfolgreichen Datensicherung mit dem Sicherungsziel Microsoft OneDrive habe ich heute versucht, die Backup-Daten mit Hilfe von WebDAV auf meinem Nextcloud-Konto abzuspeichern. Die NC hat die Version 28.0.5.

    Dazu habe ich zuerst ein Update von Duplicati auf die Version 2.0.8.1 durchgeführt und auf der NC den Ordner „Paperless-Sicherung“ erstellt. Dann habe ich in Duplicati ein neues Backup hinzugefügt und die Einträge für das Sicherungsziel WebDAV gemäß deiner Anleitung vorgenommen, d.h. auch Häkchen bei „SSL benutzen“ gesetzt und „https://“ bei der Server-URL gelöscht. Nach „Verbindung prüfen“ erhalte ich die Fehlermeldung „Failed to connect: Error: SecureChannelFailure (Authentication failed, see inner exception.)“ Hast du diesen Fehler schon einmal beobachtet?

    Viele Grüße
    Rainer

Eine Antwort schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert