Hi everyone
Ich bin mich im Moment “ein wenig” intensiv mit dem Thema Backup und Restore am beschäfigen. Bis jetzt habe ich meine Paperless Instanz mit HyperBackup gesichert. Also das einfache kopieren der Ordner an einen anderen Ort. Natürlich inkl. Offsite, 3-2-1 usw. Ich frage mich gerade, ob dies so reicht oder ob das Backup mit einem Datenbankdump und rsync Ordner geschehen muss. Ein Restore, bei welchem nur die PDF’s zurückgeladen werden müssten ist eher unwahrscheinlich. Ein kompletter Restore mit DB und allem drum und dran, wäre konsistenter.
Hat jemand von euch schon etwas in die Richtung gemacht? Ich denke an ein benutzerdefiniertes Skript im Aufgabenplaner der Synology.
Wenn du nach der Masterclass vorgegangen bist, ist die Datenbank in den Ordnern enthalten und du bist mit deiner Methode fein raus.
Rein theoretisch könnte es natürlich passieren, dass das Backup genau in dem Moment zuschlägt, in dem gerade in die DB geschrieben wird, was aber auch kein allzu großes Problem wäre, eher akademischer Natur.
Wenn du auf Nummer sicher gehen möchtest, kannst du die Instanz vorher mit dem Aufgabenplaner herunterfahren, dann das Backup planen und dann wieder hochfahren. Mir ist bisher aber noch kein einziger Fall untergekommen, der hierbei Probleme hatte.
Stimmt, der ist auch nicht verkehrt, allerdings bricht der bei der kleinsten Inkonsistenz ab. Ein Dokument z.B. von Hand verschoben und das gesamte Backup ist wertlos, vor allem wenn du es nicht monitorst.
Was du aber machen kannst: Du kannst den document_exporter nur für die DB, nicht aber für die Medien laufen lassen (quasi als Plan B zusätzlich zu Hyper Backup).
Ganz genauso. Die Datenbank in einen Ordner mappen und regelmäßig sichern. Das ist eine extrem einfache und für die meisten Fälle völlig ausreichend gute Lösung wie ich finde.
Mein Paperless läuft in einem Kubernetes Cluster. Als Datenbank Backend verwende ich PostgreSQL mittels CloudNativePG PostgreSQL Operator für Kubernetes. Das ist im Grunde ein PostgreSQL Cluster. Dort liegen auch noch andere Datenbanken drin.
Ich mache täglich ein Backup aller Datenbanken mittels pg_dump sowie extra ein document_exporter. Ausserdem wird das Volume zusätzlich noch einmal gesichert.
Ich habe nach einer Idee von @AlexanderF70 die für mich perfekte Backuplösung. Wahrscheinlich nutzt das dem Themenersteller nicht direkt, aber eine Erwähnung ist es sicher wert.
Mein paperless läuft auf einer separaten Ubuntu Proxmox-VM mit Docker. Proxmox hat mit dem Backup-Server ein sehr gutes Backupkonzept. Proxmox und Backupserver laufen auf unterschiedlicher Hardware. Ich sichere die gesamte paperless-VM auf dem Backupserver. Zusätzlich gibt es Anbieter, die Online Proxmox Backupserver hosten. Bei meinem kostet das GB 2 Cent im Monat. Damit habe ich für einen Euro/Monat ein Außer-Haus-Backup und muß mich nach der Einrichtung der Sync Jobs um nix mehr kümmern. Bei Bedarf (hatte ich bis jetzt einmal) spielt man die VM völlig entspannt auf Knopfdruck wieder zurück und macht weiter als wäre nix gewesen. Als zweites Netz mache ich trotzdem noch täglich einen Dokumenten-Export auf einen anderen Netzspeicher als der Backupserver.
Hier wurden schon einige gute Lösungen genannt. Ich setze es gerade so auf: Proxmox als Host-OS, darin ein Debian-LXC-Container, der wiederum Paperless als kleinen Docker-Compose-Stack betreibt zusammen mit Postgres und Redis. Und auf dem Proxmox-Host läuft ein Backup-Skript als cronjob, der wesentliche konfigurationen und daten von Proxmox und von dem Filesystem des LXC einsammelt und per restic an einen Netzwerkspeicher sowie ein Cloud-Ziel sichert. (Nach Empfehlung des heutigen YT-Video habe ich ein stoppen und starten des LXC-Containers noch im Skript hinzugefügt, um das theoretische DB-Transaktions-Thema rauszunehmen).
Damit fühle ich mich safe, mit der Instanz zu starten. Was ich mir später noch anschauen möchte sind Proxmox-Sicherungen bzw. Container-Snapshots/Backups. Und auch die von Roland genannte Variante über PBS ist bestimmt als zusätzliche Sicherung sinnvoll, um das System praktisch sofort wiederherstellen zu können.