[[Uebersicht|← Zurück zur Homepage]]
# PaperSafe – Betrieb, Backup und Wiederanlauf
> Kernaussage: Ein Dokumentenarchiv ist nur so viel wert wie sein **getesteter** Restore. Das Backup-Konzept ist der wichtigste Teil dieses Projekts.
## 1. Zwei Backup-Ebenen
### Ebene 1 – Proxmox-Backup des Containers/der VM
**Was:** Vollständiges Abbild inkl. Betriebssystem, Konfiguration, Datenbank und Dokumenten.
**Stärke:** Schnelle vollständige Wiederherstellung nach Hardware- oder Systemausfall.
**Schwäche:** Bindet die Daten an Proxmox und an die eingesetzte Paperless-Version – für eine Aufbewahrung über viele Jahre allein nicht ausreichend.
**Ziel:** Synology NAS `dsobe2023`. Das NAS ist **bereits als Backup-Ziel des Proxmox eingebunden und im Einsatz** – es muss also kein neuer Storage angelegt werden. Der PaperSafe-Container wird in die bestehende Sicherung aufgenommen.
Zu klären: Ob der bestehende Backup-Job den neuen Container automatisch erfasst (Auswahl „alle" vs. explizite Liste), Aufbewahrungstiefe, freier Platz auf dem NAS.
### Ebene 2 – Logischer Export (`document_exporter`)
**Was:** Paperless-eigener Export: Originaldateien plus Metadaten als JSON in einem Verzeichnis.
**Stärke:** Versions- und plattformunabhängig. Auch ohne Paperless bleiben die Dokumente lesbare Dateien – das ist die eigentliche Langzeitsicherheit. Import auf eine neue Instanz über `document_importer`.
**Schwäche:** Läuft nicht automatisch, muss als geplanter Job eingerichtet werden.
**Ziel:** ebenfalls `dsobe2023`, aber in eine **eigene Freigabe getrennt von den Proxmox-Backups**. Grund: Die Proxmox-Backup-Freigabe wird nach Aufbewahrungsregel automatisch ausgedünnt – der logische Export soll davon unabhängig sein und länger vorgehalten werden können.
**Eingerichtet am 18.07.2026:**
| Punkt | Umsetzung |
|---|---|
| Freigabe | `//dsobe2023/papersafeexport`, gemountet auf `/mnt/papersafe-export` (fstab, `_netdev,nofail`) |
| Zugangsdaten | `/root/.smbcred-papersafeexport`, Rechte `600` |
| Skript | `/usr/local/sbin/papersafe-export.sh` |
| Zeitplan | `papersafe-export.timer` – **Sonntag 03:00**, `Persistent=true` (holt verpasste Läufe nach) |
| Aufbewahrung | 60 Tage |
| Fehlerfall | Mail an root über `
[email protected]` |
Das Skript bricht ab, wenn der Mount nicht steht (statt ins Leere zu sichern), vergleicht nach dem Kopieren die Dateigröße auf beiden Seiten und löscht die Arbeitskopie im Container.
> **Abweichung von der Empfehlung:** Ursprünglich war ein **eigener DSM-Benutzer** je Freigabe vorgesehen, damit ein kompromittierter Zugang nicht beide Sicherungsebenen erreicht. Die Anmeldung mit dem separaten Benutzer schlug fehl (`STATUS_LOGON_FAILURE`); genutzt wird nun für beide Freigaben `dsadmin`. **Die Trennung besteht damit nur auf Verzeichnisebene, nicht auf Berechtigungsebene** – nachrüstbar, sobald die Ursache geklärt ist.
## 1b. Frühwarnung LVM-Thin-Pool
Beim ersten Backup-Testlauf meldete `vzdump`, dass keine Absicherung gegen volllaufende Thin Pools konfiguriert ist. Läuft ein Thin Pool voll, schalten **alle** darin liegenden Volumes auf read-only – betroffen wären auch CT 104, CT 105 (Zigbee2MQTT), CT 108 und VM 103.
Ist-Stand 18.07.2026: Pool `pve/data` 794 GB, **5,4 % belegt**; `vg-nvme/data` 465 GB, 12,5 % belegt. Volume Group `pve` hat nur noch **16 GB freie Reserve**.
Eingerichtet: `/usr/local/sbin/thinpool-check.sh`, täglich 07:00 über `thinpool-check.timer`. Meldet per Mail an root ab **75 % (Warnung)** bzw. **85 % (kritisch)** Belegung, ebenso ab 75 % Metadaten. Kein Eingriff in bestehende Volumes. Der Alarmpfad wurde durch temporäres Absenken des Schwellwerts aktiv getestet – die Mail wurde nachweislich zugestellt.
### Bewertung der Aufstellung
Produktivdaten liegen auf dem Proxmox-Host, beide Backup-Ebenen auf dem NAS – damit sind Original und Sicherung **auf getrennter Hardware**. Das deckt die häufigsten Fälle ab: Defekt des Proxmox, kaputtes Update, versehentliches Löschen.
Zwei Restrisiken bleiben:
| Risiko | Bewertung |
|---|---|
| **Beide Geräte am selben Ort** | Brand, Diebstahl oder Überspannung trifft Proxmox und NAS gleichzeitig. Für private Unterlagen tolerierbar, aber bewusst zu entscheiden |
| **Ransomware über die Freigabe** | Wenn dauerhaft Schreibrechte auf die NAS-Freigabe bestehen, können Sicherungen mitverschlüsselt werden. Bei Synology gut lösbar – siehe unten |
### Synology-spezifische Möglichkeiten
Das NAS ist ein Synology-Gerät. Damit stehen Mittel zur Verfügung, die die verbleibenden Risiken deutlich entschärfen:
| Mittel | Nutzen |
|---|---|
| **Snapshot Replication** (setzt Btrfs-Volume voraus) | Schreibgeschützte Snapshots der Freigabe. Verschlüsselte oder gelöschte Dateien lassen sich auf einen früheren Stand zurückholen – der wirksamste Ransomware-Schutz hier |
| **Unveränderliche Snapshots** (Immutable, neuere DSM-Versionen) | Snapshot kann für einen festgelegten Zeitraum auch mit Adminrechten nicht gelöscht werden |
| **Hyper Backup** | Zusätzliche Sicherung des NAS auf externe Platte oder Cloud – deckt den Off-Site-Fall ab |
| **Dedizierter Benutzer je Freigabe** | Der Zugriff für die Export-Freigabe braucht keine Rechte auf die Proxmox-Backup-Freigabe und umgekehrt |
| **S.M.A.R.T.- und Btrfs-Scrub-Zeitpläne** | Erkennt stille Datenfehler, bevor sie in alle Sicherungen wandern |
Zu prüfen: Ist das Volume Btrfs (Voraussetzung für Snapshots) oder ext4? Bei ext4 entfällt Snapshot Replication – dann bleibt Hyper Backup als Hauptmittel.
Für ein rein privates Archiv ist eine zusätzliche Off-Site-Kopie optional. Mit Hyper Backup auf eine externe Platte wäre sie ohne großen Aufwand zu haben.
## 2. Restore-Test
Ohne Test ist ein Backup eine Vermutung. Vorgehen:
1. Backup auf eine **neue** Container-/VM-ID zurückspielen, Netzwerk isoliert oder abweichende IP
2. Dienst starten, Login prüfen
3. Stichprobe: mehrere Dokumente öffnen, Volltextsuche testen, Metadaten prüfen
4. Ergebnis mit Datum hier protokollieren
5. Testinstanz entfernen
**Empfohlener Rhythmus:** nach der Inbetriebnahme, danach halbjährlich und nach jedem größeren Update.
| Datum | Art des Tests | Ergebnis |
|---|---|---|
| 18.07.2026 | Vollständiger Restore von CT 110 auf neue CTID 111, mit Testdokument | **Erfolgreich.** Alle 5 Dienste, Weboberfläche, Datenbank, Dokumentinhalt inkl. Umlaute, Volltextsuche und Dateien auf dem Volume wiederhergestellt. Details siehe [[06-Umsetzungsprotokoll]] |
> **Wichtig für den Ernstfall:** Ein Restore übernimmt die **Original-MAC-Adresse**. Beim Zurückspielen auf eine *andere* CTID muss die MAC vor dem Start geändert werden, sonst fordert die Testinstanz über die Router-Reservierung dieselbe IP wie das Produktivsystem an. Beim Restore auf die *ursprüngliche* ID ist die alte MAC dagegen genau richtig.
## 3. Updates
Ablauf:
1. Release-Notes von Paperless-ngx lesen – insbesondere auf Breaking Changes und Datenbank-Migrationen achten
2. **Snapshot bzw. Backup vor dem Update**
3. Image-Tag auf die neue Version setzen (nicht `latest`), Stack neu starten
4. Funktionsprüfung: Login, Suche, ein Testdokument einlesen
5. Ergebnis mit Version und Datum hier eintragen
Rollback: alten Image-Tag zurücksetzen bzw. Snapshot zurückspielen. Achtung: Nach einer Datenbank-Migration ist ein reiner Image-Rollback in der Regel **nicht** ausreichend – dann Snapshot verwenden.
| Datum | Von Version | Auf Version | Bemerkung |
|---|---|---|---|
| 18.07.2026 | – | Paperless-ngx 2.20.15 | Erstinstallation, siehe [[02-Installation]] |
## 4. Laufender Betrieb
| Aufgabe | Rhythmus |
|---|---|
| Consume-Ordner auf liegengebliebene Dateien prüfen | wöchentlich |
| Fehlerhafte Verarbeitungen in der Oberfläche prüfen | wöchentlich |
| Speicherplatz prüfen | monatlich |
| Betriebssystem-Updates im Container | monatlich |
| Paperless-Update | nach Release, nicht sofort am Erscheinungstag |
| Restore-Test | halbjährlich |
| Suchindex/Klassifikator neu aufbauen (bei Auffälligkeiten) | bei Bedarf |
## 5. Risiken
| Risiko | Gegenmaßnahme |
|---|---|
| Host-Ausfall | Abgedeckt: Backups liegen auf NAS `dsobe2023`, nicht auf dem Proxmox |
| Brand/Diebstahl trifft Proxmox und NAS gemeinsam | Optionale Off-Site-Kopie des logischen Exports auf externe Platte |
| Verschlüsselungstrojaner erreicht die NAS-Freigabe | Synology Snapshot Replication aktivieren (Btrfs vorausgesetzt), Schreibrechte je Freigabe trennen |
| NAS fällt unbemerkt aus, Backups laufen ins Leere | Erfolgskontrolle der Backup-Jobs, Benachrichtigung in DSM aktivieren, Prüfung beim halbjährlichen Restore-Test |
| NAS-Platte fällt aus | RAID-Status und S.M.A.R.T.-Zeitplan in DSM prüfen – ist als bestehendes Sicherungsziel ohnehin relevant |
| Aufbewahrungsregel des bestehenden Jobs dünnt Sicherungen früher aus als gedacht | Retention des vorhandenen Proxmox-Backup-Jobs prüfen, logischen Export bewusst getrennt halten |
| Stiller Datenverlust (Bitfehler) fällt erst spät auf | Prüfsummen/ZFS-Scrub, Stichproben beim Restore-Test |
| Fehlgeschlagenes Update nach DB-Migration | Snapshot unmittelbar vor dem Update |
| Wissen liegt nur im Kopf | Diese Dokumentation aktuell halten, Zugangsdaten sicher hinterlegen |
## Offene Punkte
- [x] ~~Externes Backupziel festlegen~~ → Synology NAS `dsobe2023`
- [x] ~~NAS als Proxmox-Storage einbinden~~ → bereits vorhanden und im Einsatz
- [x] ~~Prüfen, ob der bestehende Backup-Job den neuen Container erfasst~~ → ja, `all 1`, keine Änderung nötig
- [x] ~~Eigene Freigabe für den logischen Export~~ → `papersafeexport`, eingebunden
- [x] ~~Zeitplan für logischen Export~~ → wöchentlich Sonntag 03:00, 60 Tage Aufbewahrung
- [x] ~~Ersten Restore-Test durchführen~~ → **18.07.2026 erfolgreich**
- [ ] **Dateisystem des NAS-Volumes prüfen (Btrfs → Snapshot Replication als Ransomware-Schutz)** – Zugriff auf DSM ist Nutzersache
- [ ] Getrennten DSM-Benutzer für die Export-Freigabe nachrüsten (siehe Abweichung oben)
- [ ] Verschlüsselung der Exporte klären (`document_exporter --passphrase` wäre möglich)
- [ ] Freien Platz auf dem NAS im Blick behalten – aktuell 3,2 TB frei, das Archiv wächst
- [ ] Optional: Hyper Backup auf externe Platte für den Off-Site-Fall
- [ ] Snapshot `snap_vm-110-disk-1_Basis20260718` aufräumen, falls nicht mehr benötigt
## Quellen
- Paperless-ngx – Administration/Backup, `document_exporter` und `document_importer`, docs.paperless-ngx.com – Zugriff 18.07.2026
- Proxmox VE Administration Guide – Backup and Restore, pve.proxmox.com/pve-docs – Zugriff 18.07.2026
- Synology DSM – Snapshot Replication und Hyper Backup, kb.synology.com – Zugriff 18.07.2026
---
**Status:** Eingerichtet und getestet – beide Sicherungswege aktiv, Restore-Test bestanden
**Version:** 2.0
**Letzte Aktualisierung:** 18.07.2026 17:35 Uhr
### Änderungshistorie
| Version | Datum | Uhrzeit | Änderung |
|---|---|---|---|
| 1.0 | 18.07.2026 | 13:44 | Erstfassung – zweistufiges Backup-Konzept, Restore-Test, Update-Prozess, Betriebsroutinen, Risiken |
| 1.1 | 18.07.2026 | 13:52 | **Nutzerentscheidung:** Backup-Ziel ist NAS `dsobe2023` für beide Backup-Ebenen. Warnung vor „Daten und Backup auf einem Gerät" ersetzt durch Bewertung der neuen Aufstellung; Restrisiken (gleicher Standort, Ransomware über Freigabe) und Risikotabelle entsprechend überarbeitet |
| 2.0 | 18.07.2026 | 17:35 | **Umsetzung eingetragen** (Phase 7): Export-Freigabe, Skript, Zeitpläne und Aufbewahrung dokumentiert; Abweichung beim DSM-Benutzer festgehalten. Neuer Abschnitt 1b zur Thin-Pool-Frühwarnung (Befund aus dem Backup-Testlauf). Restore-Test-Tabelle mit dem erfolgreichen Test vom 18.07. gefüllt, inkl. Warnhinweis zur MAC-Adresse bei Restores. Update-Tabelle und offene Punkte aktualisiert |
| 1.2 | 18.07.2026 | 14:12 | **Nutzerangabe:** `dsobe2023` ist ein Synology-NAS und bereits aktives Proxmox-Backup-Ziel – Storage-Einbindung entfällt, Container wird in bestehende Sicherung aufgenommen. Abschnitt zu Synology-Möglichkeiten ergänzt (Snapshot Replication, Hyper Backup, Freigabetrennung, Btrfs-Scrub), Risikotabelle und offene Punkte überarbeitet |
---
[[Impressum|Impressum]] | [[Datenschutzerklärung|Datenschutz]]