Die Euphorie ist verständlich: Endlich Schluss mit quellenden Aktenschränken, verzweifelter Suche nach Rechnungen von 2018 und dem Chaos ungescannter Belege. Paperless-ngx verspricht Ordnung – digital, durchsuchbar, elegant. Doch während Einrichtung und Tagging oft im Fokus stehen, bleibt ein kritischer Aspekt im Blindspot: der Speicherbedarf. Denn jedes PDF, jeder gescannte Kassenzettel, jede archivierte E-Mail frisst Platz. Und das summiert sich schneller, als viele ahnen.

Vom Papier zum Byte: Wo Speichervolumen wirklich entsteht

Paperless-ngx ist kein passiver Aktenkoffer. Es ist eine Verarbeitungspipeline. Ein Dokument durchläuft mehrere Stufen, die jeweils Speicher kosten – manche temporär, manche dauerhaft:

• Rohdokumente: Der Ausgangspunkt. Ein 20-seitiger High-Res-Scan als TIFF? Leicht 100 MB. Ein Office-DOCX? Vergleichsweise winzig. Hier entscheidet die Quelle.
• OCR-Erzeugnisse: Die Texterkennung braucht Arbeitsraum. Tesseract (die OCR-Engine hinter Paperless-ngx) zerlegt Bilder in bearbeitbare Komponenten, analysiert Layouts, korrigiert Schräglagen. Dieser Prozess hinterlässt temporäre Zwischendateien – bei Massenimporten spürbar.
• Der finale PDF-Speicher: Das Herzstück. Paperless-ngx konvertiert fast alles in PDF/A (ideal für Langzeitarchivierung). Entscheidend ist das „Wie“: Wird ein Original-PDF einfach eingelagert? Oder wird ein gescanntes JPEG in ein PDF mit eingebettetem Textlayer verwandelt? Letzteres bläht Dateien auf.
• Indizes: Die PostgreSQL-Datenbank speichert Metadaten, Tags, Korrespondenten. Bei Millionen Dokumenten wächst auch dieser Overhead. Vernachlässigbar? Nicht bei feingranularen Taxonomien.
• Thumbnails & Vorschauen: Für schnelle Blicke im Webinterface generiert Paperless-ngx Miniaturansichten. Kleine Dateien einzeln – in Masse relevant.

Ein Praxisbeispiel: Eine mittelständische Steuerberatung scannt 500 Rechnungen pro Monat (Durchschnitt 3 Seiten). Unoptimierte 300-dpi-Scans als JPEG: ~5 MB pro Dokument. Macht 2,5 GB/Monat – nur für Rohdaten. Nach OCR und PDF-Erstellung (Textlayer + Bild) sind es oft noch 3-4 MB/Stück. Plus Indizes. Da sind 30 GB/Jahr schnell erreicht – für einen einzigen, schmalen Dokumententyp.

Die Stellschrauben: Von Kompression bis Aufbewahrungspolitik

Glücklicherweise ist Paperless-ngx kein Blackbox-Speicherfresser. Es bietet Hebel – technische und organisatorische:

1. Dokumentenerfassung optimieren

Qualität vs. Größe: Ein Scan mit 600 dpi ist selten nötig. 200-300 dpi reichen für OCR und Lesbarkeit meist aus. Entscheidend ist das Dateiformat:

• Direkt-PDFs nutzen: Liefert ein Lieferant elektronische Rechnungen als PDF? Diese nicht neu scannen! Paperless-ngx kann native PDFs direkt verarbeiten. Spart Scanspeicher und OCR-Laufzeit.
• Scanner richtig konfigurieren: Moderne Scanner bieten PDF/A-Optionen mit integrierter Kompression (JBIG2, JPEG2000). Besser dort komprimieren als in Paperless-ngx nachbearbeiten lassen.
• Office-Dokumente als Original behalten? Paperless-ngx konvertiert DOCX etc. standardmäßig in PDF/A. Sinnvoll für Konsistenz. Aber: Große Präsentationen mit Videos? Hier lohnt ein Check, ob das Original zusätzlich archiviert werden muss.

2. OCR-Strategie: Klug erkennen, nicht maximal

Die OCR-Einstellungen in config.yml sind mächtig – und speicherrelevant:

• Sprachen: Jede zusätzliche OCR-Sprache (z.B. deu+eng) vergrößert den Arbeitsaufwand und temporären Speicher.
• PDF-Output: Der Parameter OCR_MODE ist zentral:
  • redo: Erstellt komplett neue, durchsuchbare PDFs (größte Dateien).
  • skip_noarchive: Kluger Mittelweg. Nur Dokumente ohne Textlayer werden OCR-unterzogen. Elektronische PDFs bleiben unangetastet.

  Empfehlung: skip_noarchive nutzen, wann immer möglich. Spart Speicher und CPU-Zyklen.

• Post-OCR-Skripte: Mit Python-Skripten lassen sich generierte PDFs nachträglich komprimieren (z.B. mit Ghostscript). Vorsicht: Qualitätsverluste prüfen!

3. Speicherarchitektur: Flexibel skalieren

Paperless-ngx trennt klar: Die Applikation (Docker-Container) läuft woanders als die Dokumente (PAPERLESS_DATA_DIR) und die Datenbank. Das ermöglicht kluge Aufteilung:

• SSD für Hot Data: Die Datenbank und aktuelle Indizes gehören auf schnellen Flash-Speicher. Zugriffe sind I/O-intensiv.
• HDD/Cloud für Dokumente: Das Archiv selbst (PDFs) kann auf günstigeren, hochkapazitiven Spinning Disks oder in S3-kompatiblen Object Stores liegen (MinIO, Ceph, AWS S3). Paperless-ngx unterstützt S3 nativ.
• Object Storage Vorteile: Nahezu unbegrenzte Skalierbarkeit, integrierte Redundanz, Lifecycle-Regeln (z.B. automatischer Wechsel zu günstigerem Glacier-Speicher nach 90 Tagen). Ideal für langfristige Archivierung.

4. Betriebliche Disziplin: Löschen dürfen!

Die größte Speicherverschwendung? Dokumente, die niemand mehr braucht, aber aus Bequemlichkeit oder Rechtsangst ewig liegen. Paperless-ngx bietet Tools:

• Automatische Aufbewahrungsrichtlinien: Pro Dokumententyp (Tag, Korrespondent) lassen sich Aufbewahrungsfristen definieren (z.B. „Kassenbelege: 2 Jahre“). Abgelaufene Dokumente können automatisch gelöscht oder zur manuellen Freigabe markiert werden.
• Duplikaterkennung: Wie oft wurde dieselbe Rechnung gescannt? Die integrierte Erkennung hilft, Redundanzen zu killen.
• Regelmäßige Audits: Einmal pro Jahr prüfen: Welche Dokumententypen wachsen unkontrolliert? Sind Aufbewahrungsregeln noch zeitgemäß?

Ein Erfahrungswert: In 80% der Firmen liegen >30% obsolete Dokumente im DMS. Das ist purer Speicherballast.

Praxis-Szenarien: Von KMU bis Konzern

Fall 1: Handwerksbetrieb (10 Mitarbeiter)

Dokumentenaufkommen: ~1000 Neue Dokumente/Jahr (Rechnungen, Lieferscheine, Personalakten).
Setup: Paperless-ngx auf einem NUC mit 512 GB SSD, Daten und DB lokal.
Speicherbedarf: Nach 3 Jahren ~120 GB (optimierte Scans, skip_noarchive OCR). Kein Problem. Wichtig: Externes Backup auf NAS.
Optimierungspotenzial: Automatisierte Löschregeln für alte Angebote/Lieferscheine einrichten.

Fall 2: Steuerkanzlei (50 Mitarbeiter)

Dokumentenaufkommen: ~50.000 Neue Dokumente/Jahr (Mandantenakten, Finanzamtsschreiben, Scans).
Setup: Dedizierter Server, DB auf SSD, Dokumente auf 8 TB HDD-RAID. Backup auf Tape.
Speicherbedarf: ~1,2 TB/Jahr. Kritisch: Spitzen während der Abgabetermine (Massenimporte).
Maßnahmen: OCR-Worker auf separatem Rechner entlasten. Dokumente nach Mandanten-Jahrgangsordnern strukturieren (vereinfacht Migration/Archivierung). Prüfung, ob ältere Jahrgänge (vor 2018) auf externes Archiv ausgelagert werden können.

Fall 3: Industrieunternehmen (Produktion, 1000+ MA)

Dokumentenaufkommen: >500.000 Dokumente/Jahr (Technische Zeichnungen, Prüfprotokolle, Compliance-Docs, Einkauf).
Setup: Kubernetes-Cluster für Paperless-ngx, PostgreSQL-HA-Cluster, Dokumente im S3-Object Store (MinIO on-prem), Lifecycle-Regeln verschieben alte Daten auf Tape-Library.
Speicherbedarf: >20 TB/Jahr + erhebliche Indexgröße.
Architektur: Entscheidend ist die Entkopplung. Der Object Store skaliert nahezu linear. Separate Worker-Pools für OCR und Import entlasten die Hauptapp. Regelmäßiges „Reinigen“ der Datenbank (leeren Papierkorb, Optimieren der Indizes).

Langzeitarchivierung: PDF/A ist nicht genug

Paperless-ngx zielt auf PDF/A. Das Format garantiert Langzeitlesbarkeit – technisch. Doch was nützt es, wenn die Hardware oder das Wissen um die Systeme schwindet? Speicherbedarf hat hier eine zeitliche Dimension:

• Medienbruch: 10 TB heute auf HDDs? In 20 Jahren sind die Lesegeräte vielleicht Museal. Object Storage mit Standard-APIs (S3) reduziert dieses Risiko.
• Integrität prüfen: Paperless-ngx kann Checksums prüfen. Wichtig für Archivierung: Regelmäßige Prüfroutinen einplanen, ob Dateien korrupt sind.
• Migration einplanen: Alle 5-10 Jahre sollte das Gesamtsystem (Hardware, Software, Speichermedien) auf den Prüfstand. Paperless-ngx-Daten lassen sich via Export/Import migrieren – bei Terabytes ein Projekt!

Ein interessanter Aspekt: Der Speicherbedarf von heute ist die Archivkostenfalle von morgen. Wer billige Consumer-HDDs für Langzeitarchiv nutzt, spart am falschen Ende. Enterprise-Drives oder Tape mit höherer Lebensdauer rechnen sich bei großen Volumina.

Zukunft: KI als Speicheroptimierer?

Spannende Entwicklungen könnten den Speicherdruck mindern:

• Intelligente Kompression: KI-Modelle erkennen unwichtige Bildhintergründe (z.B. bei gescannten Formularen) und komprimieren selektiv stärker.
• Automatisierte Klassifikation & Retention: Statt starren Regeln: KI schlägt Aufbewahrungsdauern basierend auf Dokumenteninhalt und Nutzungsmustern vor. Verhindert sinnloses Horten.
• Deduplikation 2.0: Erkennung inhaltlicher Ähnlichkeit (nicht nur exakter Duplikate) – etwa bei leicht geänderten Vertragsversionen.

Noch sind diese Features nicht Mainstream in Paperless-ngx. Aber die Pluginfähigkeit der Software lässt Raum für Experimente.

Fazit: Speicher ist kein Technikproblem, sondern Managementaufgabe

Paperless-ngx macht Dokumente beherrschbar – nicht unsichtbar. Der Speicherbedarf wächst mit jedem importierten PDF. Die Krux liegt im Dreiklang:

1. Technische Weitsicht: Skalierbare Speicherarchitektur (S3!) von Anfang an mitdenken, nicht als Afterthought. Trennung von Applikation, Index und Dokumentenspeicher.
2. Prozessdisziplin: Aufbewahrungsrichtlinien rigoros durchsetzen. Digitalisieren heißt auch: mutig löschen dürfen. OCR-Einstellungen (skip_noarchive) bewusst wählen.
3. Regelmäßige Pflege: Speichermonitoring, Datenbankoptimierung, Archivierungsprojekte für kalte Daten einplanen.

Wer das beherzigt, wird Paperless-ngx nicht als Speicherfresser erleben, sondern als effizientes Werkzeug. Denn der wahre Gewinn liegt ja nicht in gesparten Gigabytes, sondern in Sekunden, die Mitarbeiter nicht mehr mit Suchen verbringen – und in der Gewissheit, dass die digitale Akte auch in 10 Jahren noch zugänglich ist. Dafür lohnt es sich, den Speicherbedarf klug zu managen.