Paperless-ngx: Die unterschätzte Macht der Hardware-Dimensionierung

Uncategorized

Paperless-ngx: Die unterschätzte Kunst der Hardware-Dimensionierung

Sie haben die Entscheidung getroffen: Paperless-ngx soll das digitale Rückgrat Ihrer Dokumentenverwaltung werden. Die Open-Source-Lösung punktet mit Flexibilität, durchdachter Taxonomie und beeindruckender OCR-Integration. Doch während Funktionsumfang und Workflows intensiv diskutiert werden, bleibt ein kritischer Faktor oft im Hintergrund – die Hardware. Dabei entscheidet sie maßgeblich darüber, ob Ihre papierlose Vision zum Flaschenhals wird oder nahtlos skalieren kann.

Warum die Kiste unter dem Schreibtisch (nicht) reicht

Der verlockende Gedanke, Paperless-ngx einfach auf einer ausrangierten Workstation oder einem Mini-PC zu installieren, endet meist jäh. Stellen Sie sich vor: Ein Mitarbeiter lädt ein 200-seitiges PDF mit komplexen Tabellen hoch. Parallel startet der nächtliche OCR-Job für hunderte eingescannte Rechnungen. Gleichzeitig durchsucht die Buchhaltung das Archiv nach Belegen von 2018. Plötzlich ruckelt die Oberfläche, Suchanfragen verzögern sich um Sekunden – die Produktivität sinkt spürbar. Das ist kein Software-Versagen, sondern klassisches Hardware-Underprovisioning.

Die vier Säulen der Performance

CPU: Der OCR-Turbo
Die optische Zeichenerkennung ist der heimliche Ressourcenfresser. Tesseract OCR, das Herzstück von Paperless-ngx, profitiert massiv von mehr Kernen und höheren Taktfrequenzen. Ein Dual-Core-Prozessor mag für Testumgebungen genügen, doch im Produktivbetrieb zeigt sich schnell:

  • Ein moderner Quad-Core (z.B. Intel i5-12500/AMD Ryzen 5 5600) ist das Minimum für kleine Teams (<10 Nutzer)
  • Bei parallelen OCR-Jobs und >20 Nutzern empfehlen sich 6-8 Kerne (Intel i7/i9, Ryzen 7/9)
  • Enterprise-Umgebungen mit Batch-Verarbeitung großer Backlogs greifen zu Server-CPUs (Xeon, EPYC)

Faustregel: Jeder aktive OCR-Thread belegt einen Kern nahezu vollständig. Asynchrone Verarbeitung via Celery Worker entlastet zwar den Hauptprozess, verteilt die Last aber aufs Gesamtsystem.

RAM: Wo der Index atmet
Paperless-ngx lebt von seiner Suchgeschwindigkeit. PostgreSQL hält Indizes im RAM, Redis cached Sitzungsdaten und Warteschlangen. Knapp dimensionierter Arbeitsspeicher führt zu vermehrtem Swapping – der Performance-Killer schlechthin.

  • 4 GB: Absolutes Minimum für Experimentierumgebungen (inakzeptabel im Echtbetrieb)
  • 8 GB: Machbar für Kleinstbetriebe mit geringem Dokumentenaufkommen (<10.000 Docs)
  • 16-32 GB: Sweet Spot für mittlere Installationen (50.000-200.000 Dokumente)
  • 64 GB+: Enterprise-Level bei Millionen-Dokumenten oder vielen gleichzeitigen Nutzern

Nicht vergessen: Betriebssystem, PostgreSQL, Redis und die Python-Applikation teilen sich den Speicher. Wer virtuellisiert, muss Overhead für den Hypervisor einkalkulieren.

Storage: Der unterschätzte Flaschenhals
Hier lauern gleich drei Fallstricke: Kapazität, Geschwindigkeit und Ausfallsicherheit. Ein Rechenbeispiel: Bei 5.000 Dokumenten à durchschnittlich 5 MB (hochaufgelöste Scans + Textversionen) sind bereits 25 TB reine Dokumentenkapazität fällig – ohne Backups, ohne Indizes, ohne Systempartition.

  • SSD vs. HDD: Feste Platten (HDD) sind bei großen Archiven kostengünstig, aber eine Qual für Datenbankoperationen. PostgreSQL-I/O lastet massiv bei komplexen Suchanfragen. Eine SSD für das DB-Volume (auch im RAID) ist nicht verhandelbar. Für reine Dokumentenspeicherung können HDDs im entkoppelten Storage sinnvoll sein.
  • RAID-Konfiguration: RAID 5/6 für Dokumentenspeicher (kapazitätsorientiert), RAID 10 für PostgreSQL-Daten (performancekritisch). Hardware-RAID-Controller mit BBU (Battery Backup Unit) verhindern Datenverlust beim Stromausfall.
  • Dateisystem: XFS oder ext4 bewähren sich. ZFS glänzt bei integrierter Kompression und Snapshots, benötigt aber mehr RAM.

Tipp: Trennen Sie System, PostgreSQL-Daten, Dokumentenspeicher (media) und Backups physisch/logisch. Das vereinfacht Wartung und Skalierung.

Netzwerk: Die unsichtbare Pipeline
Ein übersehener Faktor: Bei 100 Usern, die täglich je 20 Dokumente hochladen (à 10 MB), summiert sich der Traffic auf 20 GB/Tag – nur für Uploads. Hinzu kommen Volltextsuchen, Vorschau-Generierungen und Downloads.

  • 1 GbE-Netzwerk ist heute Standard, aber bei zentralisiertem Storage (NAS/SAN) prüfen: Reicht der Durchsatz?
  • 10 GbE-Anbindung für den Paperless-Server wird bei hohem Parallelaufkommen oder großen PDFs (>100 MB) relevant
  • Latency: Vor allem bei virtuellen Umgebungen oder Cloud-Instanzen wirken sich Latenzen im Millisekundenbereich spürbar auf die UI-Reaktionszeit aus

Virtualisierung vs. Bare Metal: Ein Praxisvergleich

Die Frage „Physischer Server oder VM?“ spaltet Admins. Beide Ansätze haben ihre Berechtigung:

Virtualisierung (VMware, Proxmox, Hyper-V)
Vorteile: Bessere Ressourcenauslastung durch Konsolidierung, schnelle Backups (Snapshots), einfache Migration. Nachteile: I/O-Overhead besonders bei Storage-Intensitiven Tasks, „Noisy Neighbor“-Effekt wenn andere VMs plötzlich Ressourcen beanspruchen. Wichtig: Reservieren Sie CPU-Kerne und RAM fest – nicht nur Limits setzen! PCI-Passthrough kann bei NVMe-SSDs Performance-Einbußen minimieren.

Bare Metal
Vorteile: Maximale Performance, direkter Hardwarezugriff, keine Virtualisierungs-Overheads. Nachteile: Geringere Flexibilität, höherer Platz-/Energiebedarf, aufwändigeres Hardware-Backup. Ideal für reine Paperless-ngx-Hosts mit hohem Durchsatz.

Containerisierung (Docker)
Der De-facto-Standard für Paperless-ngx-Installationen. Entkoppelt Abhängigkeiten, vereinfacht Updates. Aber: Docker selbst verursacht kaum Overhead, die darunterliegende Hardware/VM entscheidet. Resource Limits (–cpus, –memory) im docker-compose.yml sind Pflicht – sonst kann ein einzelner OCR-Job das ganze System ausbremsen.

Dimensionierungspraxis: Von der Werkstatt zum Konzern

Szenario 1: Handwerksbetrieb (5 Nutzer, ~1.000 Docs/Jahr)

  • CPU: 4 Kerne (z.B. Intel i3-12100)
  • RAM: 16 GB DDR4
  • Storage: 500 GB NVMe SSD (System + DB) + 2 TB SATA SSD (Dokumente), wöchentliches Backup auf NAS
  • Netzwerk: 1 GbE
  • Formfaktor: Kompakter Tower oder Mini-PC (z.B. HP ProDesk)

Kostenrahmen: € 1.200 – € 1.800. Hier reicht oft eine stabile Consumer-Hardware.

Szenario 2: Steuerberatung (25 Nutzer, ~50.000 Docs/Jahr)

  • CPU: 8 Kerne / 16 Threads (z.B. Ryzen 7 7700X)
  • RAM: 32 GB DDR5
  • Storage: 1 TB NVMe (RAID 1, System+DB) + 8 TB SATA SSD (Software-RAID 5, Dokumente), tägliche Backups
  • Netzwerk: 2,5 GbE-Anbindung ans LAN
  • Infrastruktur: Dedizierter Server oder Hochverfügbarkeits-VM-Cluster

Kostenrahmen: € 4.000 – € 6.500. Investition in Enterprise-SSDs und ECC-RAM empfohlen.

Szenario 3: Logistikunternehmen (100+ Nutzer, >500.000 Docs)

  • CPU: 2x Xeon Silver 4314 (16 Kerne / 32 Threads)
  • RAM: 128 GB DDR4 ECC
  • Storage: Tiered Storage – NVMe-Pool (2 TB, RAID 10 für DB), SAS-SSDs (20 TB, RAID 6 für „heiße“ Dokumente), SATA-HDDs (100 TB+, RAID 6 für Archiv), 10 GbE zum SAN
  • Backup: Dedizierter Backup-Server mit WORM-Funktion, Offsite-Kopie
  • Infrastruktur: Hochverfügbarkeitscluster mit Loadbalancer

Kostenrahmen: € 15.000+. Hier wird Hardware zum strategischen Faktor.

Die Backup-Frage: Nicht nur wo, sondern wie schnell

Ein Paperless-ngx-Backup umfasst drei Schichten:

  1. Datenbankdump (PostgreSQL)
  2. Dokumentenverzeichnis (media Ordner)
  3. Konfiguration (env Datei, Docker-Compose, ggf. Secrets)

Die Hardware bestimmt das Restore-Fenster. Ein 500 GB-Dokumentenordner von einer SATA-HDD wiederherzustellen, kann Stunden dauern – bei NVMe-SSDs nur Minuten. Testen Sie regelmäßig das komplette Restore auf isolierter Hardware! Tools wie BorgBackup oder Restic bieten Deduplizierung, entscheiden aber nicht das Geschwindigkeitsproblem.

Future-Proofing: Heute für morgen planen

Dokumentenwachstum ist nicht linear. Ein Unternehmenskauf, neue Compliance-Vorschriften oder digitale Aktenvernichtung können Volumen sprunghaft ändern. Planen Sie:

  • CPU: Mind. 20% Headroom für Lastspitzen
  • RAM: Freie Steckplätze für späteres Upgrade
  • Storage: Modular erweiterbare Lösungen (JBODs, Scale-out-Storage)
  • Netzwerk: 10 GbE-fähige Switches auch bei aktuell geringer Auslastung

Ein interessanter Aspekt: Cloud-Instanzen (AWS, Azure, Hetzner) bieten Flexibilität, aber Achtung bei egress-Kosten für große Datenmengen und dauerhaften Betrieb. Die monatliche Rechnung übertrifft oft nach 3 Jahren die Anschaffungskosten eigener Hardware.

Fazit: Hardware als Erfolgsfaktor

Paperless-ngx ist kein Ressourcenmonster – wenn man es richtig füttert. Die Krux liegt im Detail: Ein unterdimensionierter Server macht aus der eleganten DMS-Lösung schnell eine digitale Krücke. Investitionen in ausreichend Kerne für OCR, schnellen Speicher für die Datenbank und redundante Infrastruktur zahlen sich in Nutzerakzeptanz und geringeren Betriebskosten aus. Dabei zeigt sich: Wer beim Dokumentenmanagement spart, zahlt doppelt – in verlorener Produktivität und technischer Schuldenlast. Planen Sie Hardware nicht als Nachgedanken, sondern als integralen Teil Ihrer Paperless-ngx-Strategie. Nur dann entfaltet das System seine ganze Kraft als Schaltzentrale für betriebliche Organisation und digitale Archivierung.