[[Uebersicht|← Zurück zur Homepage]] # PaperSafe – Konzept und Architektur ## 1. Was Paperless-ngx technisch ist Paperless-ngx ist keine einzelne Anwendung, sondern ein Verbund mehrerer Dienste: | Dienst | Aufgabe | Pflicht | |---|---|---| | **Webserver (Django)** | Weboberfläche und API | ja | | **Task-Worker (Celery)** | Verarbeitung eingehender Dokumente, OCR | ja | | **Redis** | Message-Broker zwischen Webserver und Worker | ja | | **Datenbank** | PostgreSQL empfohlen; SQLite möglich, aber für größere Bestände schwächer | ja | | **Gotenberg** | Konvertierung von Office-Dokumenten nach PDF | optional | | **Apache Tika** | Text-/Metadatenextraktion aus Office-Formaten | optional | Die eigentliche OCR erledigt **OCRmyPDF/Tesseract** im Worker. Für Deutsch muss das Sprachpaket `deu` vorhanden sein. **Datenverzeichnisse** (die für Backup relevanten): | Verzeichnis | Inhalt | |---|---| | `media/documents/originals` | Originaldateien – unersetzlich | | `media/documents/archive` | OCR-PDF-Versionen – aus Original neu erzeugbar | | `data` | Suchindex, Klassifikator – neu erzeugbar | | `consume` | Eingangsordner, wird nach Verarbeitung geleert | | `export` | Ziel für `document_exporter` (logisches Backup) | | Datenbank | Metadaten, Tags, Benutzer – unersetzlich | Merksatz fürs Backup: **Originale + Datenbank sind unersetzlich**, alles andere ist regenerierbar. --- ## 2. Deployment-Varianten im Vergleich ### Variante A: Unprivilegierter LXC + Docker Compose **Vorteile** - Ressourcenschonend (kein zweiter Kernel, deutlich weniger RAM/Disk als eine VM) - Docker Compose ist der **offiziell dokumentierte und getestete** Installationsweg von Paperless-ngx – Updates laufen über neue Image-Tags, Rollback über den alten Tag - LXC-Backup über Proxmox erfasst den kompletten Container inkl. Daten - Snapshots vor Updates sind schnell und platzsparend **Nachteile** - Docker in unprivilegiertem LXC erfordert Zusatzkonfiguration (Nesting/keyctl aktivieren); ohne diese Optionen startet der Docker-Daemon nicht - Verschachtelung Container-in-Container macht Fehlersuche unübersichtlicher - Bind-Mounts von Host-Verzeichnissen in unprivilegierte LXC bringen UID-Mapping-Themen mit sich ### Variante B: VM (Debian) + Docker Compose **Vorteile** - Saubere Isolation, eigener Kernel – keine LXC-Sonderfälle, Docker verhält sich wie überall dokumentiert - Fehlersuche und Support-Fälle entsprechen exakt der Standarddoku - Unkritisch bei Kernel-abhängigen Themen und bei Proxmox-Upgrades - Snapshots inkl. RAM-State möglich **Nachteile** - Höherer Ressourcenverbrauch (eigener Kernel, feste RAM-Zuteilung, größeres Disk-Image) - Backups sind größer und dauern länger - Zusätzliches Betriebssystem, das separat gepflegt werden muss ### Variante C: LXC über Proxmox-Community-Helper-Script (tteck-Nachfolge) **Vorteile** - Schnellste Einrichtung, Container ist in Minuten betriebsbereit - Bare-Metal-Installation ohne Docker-Zwischenschicht – geringster Overhead - Skript setzt sinnvolle Defaults **Nachteile** - Abweichung vom offiziellen Installationsweg – bei Problemen greift die offizielle Doku nur eingeschränkt - Updates hängen am Skript bzw. dessen Pflegezustand; die Community-Scripts haben nach dem Tod des ursprünglichen Autors (tteck, 2024) den Maintainer gewechselt - Ein Fremdskript mit Root-Rechten auf dem Host – setzt Vertrauen in die Quelle voraus - Rollback nach fehlgeschlagenem Update nur über Snapshot, nicht über Image-Tag ### Einschätzung Für den geplanten Einsatz (ein Host, überschaubare Dokumentmenge, Wert liegt auf Langlebigkeit und sauberem Restore) spricht am meisten für **Variante A (LXC + Docker Compose)**: offizieller Update-Pfad bei gleichzeitig geringem Ressourcenverbrauch. **Variante B** ist die Wahl, wenn die LXC-Docker-Sonderkonfiguration als Risiko empfunden wird – der Preis ist reiner Ressourcenverbrauch, kein Funktionsverlust. **Variante C** ist die schnellste, aber die am wenigsten zukunftssichere Option. > ✅ **Entschieden am 18.07.2026: Variante A – unprivilegierter LXC + Docker Compose.** Die Varianten B und C bleiben zur Nachvollziehbarkeit dokumentiert. Konsequenz für die Umsetzung: LXC-Features `nesting=1` und `keyctl=1` sind zwingend zu setzen, sonst startet der Docker-Daemon nicht. --- ## 3. Diskussion: privat, geschäftlich oder beides? Der Punkt ist nicht technisch, sondern rechtlich – und er entscheidet, wie aufwendig das Projekt wird. ### Option 1: Rein privat **Vorteile** - Keine gesetzlichen Anforderungen an Unveränderbarkeit, Protokollierung oder Aufbewahrungsfristen - Freie Gestaltung von Struktur, Tags und Löschverhalten - Deutlich geringerer Dokumentations- und Betriebsaufwand **Nachteile** - Kein Nutzen für die geschäftliche Belegablage – dafür bliebe ein zweites System nötig ### Option 2: Rein geschäftlich (Obeco) **Vorteile** - Ein System für alle betrieblichen Belege, Volltextsuche über den gesamten Bestand - Vorbereitung auf Betriebsprüfungen, wenn sauber aufgesetzt **Nachteile / Anforderungen** - Es gelten die **GoBD**: Nachvollziehbarkeit, Vollständigkeit, Unveränderbarkeit, Ordnung, zeitgerechte Erfassung - Erforderlich wird eine **Verfahrensdokumentation** – wer scannt wann was, wie wird geprüft, wie wird archiviert. Diese Doku hier kann deren technischer Teil werden, ersetzt sie aber nicht - Aufbewahrungsfristen (handels-/steuerrechtlich, je nach Belegart 8 oder 10 Jahre) müssen über die gesamte Zeit technisch gehalten werden – inkl. Lesbarkeit und Migration - Paperless-ngx ist **nicht per se revisionssicher**: Administratoren können Dokumente löschen und Metadaten ändern. Unveränderbarkeit muss organisatorisch und über Backup-Strategie hergestellt werden (z. B. unveränderliche Backups, Berechtigungskonzept, Protokollierung) - Beim ersetzenden Scannen (Vernichtung der Papieroriginale) steigen die Anforderungen deutlich – das sollte bewusst und dokumentiert entschieden werden ### Option 3: Beides in einer Instanz, getrennt über Mandanten **Vorteile** - Nur ein System zu betreiben, zu sichern und zu aktualisieren - Paperless-ngx bringt Benutzer, Gruppen und **objektbezogene Berechtigungen** je Dokument mit; Trennung ist zusätzlich über Tags, Dokumenttypen und Speicherpfade möglich **Nachteile** - Die Trennung ist eine *Berechtigungs*-Trennung, keine *System*-Trennung – eine Fehlkonfiguration vermischt private und betriebliche Unterlagen - Bei einer Betriebsprüfung mit Datenzugriff wird die Abgrenzung zur Privatsphäre zum Thema; sauber getrennte Systeme sind hier die deutlich einfachere Position - Das strengere Regime (GoBD) prägt faktisch den Betrieb des Gesamtsystems, auch für die privaten Dokumente - Beim Restore lässt sich nicht selektiv nur ein Mandant zurückholen ### Option 4 (Variante zu 3): Zwei getrennte Instanzen auf demselben Host **Vorteile** - Vollständige Datentrennung bei nur einem physischen Server; unabhängige Backups und Restore-Zeitpunkte - Klare Position gegenüber Dritten/Prüfern **Nachteile** - Doppelter Betriebs- und Update-Aufwand, doppelter Ressourcenbedarf - Zwei Oberflächen, zwei Zugänge im Alltag ### Einschätzung und Entscheidung Wenn geschäftliche Belege überhaupt ins System sollen, ist **Option 4 (zwei getrennte Instanzen)** die sauberste Lösung. **Option 3** ist der pragmatische Kompromiss, verlagert das Risiko aber in die Berechtigungskonfiguration. **Option 1** hält das Projekt klein und schnell umsetzbar. > ✅ **Entschieden am 18.07.2026: Option 1 – rein private Nutzung.** > > Konsequenzen: > - **GoBD spielt keine Rolle.** Keine Verfahrensdokumentation, keine Anforderungen an Unveränderbarkeit oder Protokollierung, keine gesetzlichen Aufbewahrungsfristen für dieses System > - Struktur, Tags und Löschverhalten sind frei gestaltbar > - Benutzerkonzept bleibt einfach: ein Administrator, ein Alltagskonto > - **Abgrenzung:** Obeco-Belege gehören nicht in dieses System. Falls das später gewünscht wird, ist das ein eigenes Projekt mit eigener Instanz – nicht ein Nachrüsten hier > - Papieroriginale: Umgang ist frei wählbar, da keine steuerlichen Aufbewahrungspflichten greifen. Ausnahme sind Dokumente, die im Original Beweiswert haben (Urkunden, notarielle Verträge, Zeugnisse, Bürgschaften) – die gehören weiterhin ins Papierarchiv --- ## 4. Ressourcen-Planung (Richtwerte) | Ressource | Empfehlung | |---|---| | CPU | 2 Kerne (4 bei häufiger Massenverarbeitung – OCR ist der Flaschenhals) | | RAM | 4 GB (2 GB Minimum; Tika/Gotenberg erhöhen den Bedarf) | | Disk System | 16–20 GB | | Disk Daten | Nach Dokumentenmenge; Faustwert: gescanntes A4-PDF mit OCR ca. 100–500 KB. Archivversion kommt zur Originaldatei hinzu, also ungefähr doppelt rechnen | Die konkreten freien Ressourcen auf 192.168.2.146 sind noch zu prüfen. ## 5. Netzwerk und Zugriff - Feste IP im LAN, Reservierung im DHCP - Weboberfläche standardmäßig Port 8000 (im Compose-Stack frei wählbar) - Externer Zugriff, falls gewünscht: **VPN bevorzugt** gegenüber einem öffentlich erreichbaren Reverse Proxy – ein Dokumentenarchiv gehört nicht ungeschützt ins Internet - Backup-Ziel (**NAS `dsobe2023`**) und Scanner-Freigabe im selben Netzsegment ## Offene Punkte - [x] ~~Deployment-Variante wählen~~ → Variante A (LXC + Docker Compose) - [x] ~~Nutzungsumfang wählen~~ → Option 1 (rein privat) - [x] ~~Ersetzendes Scannen ja/nein~~ → entfällt als Rechtsfrage, da privat - [ ] Freie Ressourcen auf dem Proxmox prüfen - [ ] Externer Zugriff nötig? ## Quellen - Paperless-ngx – offizielle Dokumentation, docs.paperless-ngx.com (Architektur, Installationswege, Backup) – Zugriff 18.07.2026 - Proxmox VE Administration Guide – LXC-Container und Backup, pve.proxmox.com/pve-docs – Zugriff 18.07.2026 - GoBD: BMF-Schreiben „Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff" – Zugriff 18.07.2026 > Hinweis: Die genannten technischen Details entsprechen dem Stand meiner Kenntnis und sind vor der Umsetzung gegen die aktuelle Fassung der Paperless-ngx-Doku abzugleichen. Die GoBD-Aussagen sind eine fachliche Einordnung, keine Rechts- oder Steuerberatung – für den geschäftlichen Einsatz ist der Steuerberater einzubinden. --- **Status:** Entscheidungen getroffen **Version:** 1.1 **Letzte Aktualisierung:** 18.07.2026 13:52 Uhr ### Änderungshistorie | Version | Datum | Uhrzeit | Änderung | |---|---|---|---| | 1.0 | 18.07.2026 | 13:44 | Erstfassung – Komponentenübersicht, Deployment-Varianten A/B/C, Diskussion privat/geschäftlich (Optionen 1–4), Ressourcen- und Netzwerkplanung | | 1.1 | 18.07.2026 | 13:52 | **Nutzerentscheidungen eingearbeitet:** Variante A (LXC+Docker) und Option 1 (rein privat) gewählt, jeweils mit Konsequenzen dokumentiert. GoBD-Anforderungen entfallen damit; Hinweis auf Papieroriginale mit Beweiswert ergänzt. Backup-Ziel NAS `dsobe2023` im Netzwerkabschnitt ergänzt. Verworfene Varianten bleiben zur Nachvollziehbarkeit erhalten | --- [[Impressum|Impressum]] | [[Datenschutzerklärung|Datenschutz]]