Paperless-ngx aktualisieren: sicher zur aktuellen Version

Ursprüngliche Quelle: digitale-archive/paperless-ngx-3-upgrade-praxis/paperless-ngx-3-upgrade-praxis.md. Ursprüngliche Metadaten (historisch):

title: "Paperless-ngx aktualisieren: Updates, Upgrades und meine Praxis"
description: "Paperless-ngx im Docker-Betrieb sicher aktualisieren: Entscheidung, Sicherung, Release Notes, Migrationen, Tests und Rückweg aus der Praxis."
slug: paperless-ngx-3-upgrade-praxis
route: digitale-archive/paperless-ngx-3-upgrade-praxis
wdb: true
scope: public
domain: "Digitale Archive"
category: "Digitale Archive"
tags: [Paperless-ngx, Upgrade, BorgBackup, OCR, Docker]
meta_title: "Paperless-ngx Updates & Upgrades richtig durchführen"
author: "Eric Beuchel"
date: '2026-07-23'
lastmod: '2026-10-06'
version: '1.1'
status: stable
published: true
wp:
  publish: true

Einordnung: Der erste Teil beschreibt mein Vorgehen bei Updates. Das anschließende Praxisbeispiel dokumentiert den Versionswechsel vom 23. Juli 2026; seine damaligen Versionsnummern sind kein aktueller Installationsstand. Einen späteren eigenen Test beschreibt Paperless-ngx 3.3: Update, Datumsfehler und Tika 4 im Praxistest.

Kurz gesagt

Eine neue Versionsnummer ist kein ausreichender Grund, ein funktionierendes Dokumentenarchiv zu verändern. Ich prüfe zuerst die offiziellen Release Notes und die Migrationshinweise: Was ist für meinen Betrieb relevant, ist ein Sicherheitsproblem behoben, und ist Sicherung, Test und Rückweg geklärt? Erst dann wird aktualisiert.

Normale Wartungsupdates plane ich zeitnah. Bei bestätigten Sicherheitslücken hat die Behebung Vorrang; auch dann erfolgen Sicherung und anschließende Funktionsprüfung. Größere Versionswechsel behandle ich vorsichtig, weil sie Migrationen oder Anpassungen an Konfiguration und eigenen Skripten auslösen können.

Praxistipp: In der linken Leiste der Paperless-Oberfläche zeigt der Eintrag „Dokumentation“ die derzeit laufende Paperless-ngx-Version an. Das ist ein schneller Hinweis, ob ein Versionsvergleich sinnvoll ist. Ob tatsächlich aktualisiert wird, entscheide ich erst nach den offiziellen Release Notes und den Migrationshinweisen.

Vor jeder Änderung: entscheiden statt nur nachziehen

Die Bezeichnungen „Update“ und „Upgrade“ nutze ich hier praktisch, nicht als verbindliche SemVer-Regel: Ein Update ist eine überschaubare Aktualisierung innerhalb einer bewährten Reihe. Ein Upgrade ist ein Wechsel, bei dem Breaking Changes, Datenmigrationen oder Eingriffe in die eigene Konfiguration möglich sind.

Ein beweglicher Docker-Tag wie latest passt nicht zu diesem Ablauf. Ein fester Versions-Tag oder Digest macht den tatsächlich geprüften Stand nachvollziehbar. Ein pull ist keine Freigabeentscheidung.

Installation vor dem Upgrade einordnen

Meine konkrete Debian-, Docker-, Speicher- und Consumer-Konfiguration steht im separaten Beitrag Paperless-ngx auf Debian: Installation, Speicherwege und Betrieb. Vor einem Update prüfe ich dort dokumentierte Abweichungen gegen die Release Notes; sie sind keine allgemeine Vorlage zum Kopieren.

Sicherung und Rückweg

Vor jeder produktiven Änderung steht eine aktuelle, nachweisbar erfolgreiche Sicherung. Für meinen Betrieb gehören dazu mindestens Datenbank-Snapshot, Medien, Compose-Datei, Umgebungsdatei und die Konfiguration eigener Skripte. Die zentrale Vorgehensweise beschreibt der Beitrag Paperless-ngx zuverlässig sichern.

Der Rückweg muss vor dem Update klar sein: Das vorherige Image allein genügt nicht. Datenbank, Medien, Konfiguration und der Stand eigener Automatisierung müssen zusammenpassen. Während eines nötigen Rollbacks dürfen keine neuen Dokumente unkontrolliert importiert werden.

Kontrollierter Ablauf und Funktionscheck

Bei einer Major-Migration verlangt die offizielle Paperless-Dokumentation besondere Aufmerksamkeit. Aktive Verarbeitungsvorgänge müssen beendet sein; vor Docker-Upgrade und Migration ist ein vollständiges Backup erforderlich. Release Notes sind dabei die Quelle für die konkrete Zielversion, nicht historische Blog- oder Praxisberichte.

Neue Funktionen werden dadurch nicht automatisch Teil meines Workflows. Besonders externe KI-Dienste oder neue Automatisierungen bewerte ich getrennt nach Nutzen, Datenfluss und Kontrollierbarkeit.

Historisches Praxisbeispiel: Wechsel auf Paperless-ngx 3

Der folgende Abschnitt ist der belegte Snapshot meines Major-Upgrades vom 23. Juli 2026. Hardware, Softwarestände und insbesondere die Dokumentzahl beschreiben diesen damaligen Teststand, nicht den heutigen Betrieb. Der aktuelle End-to-End-Test vom 23. September 2026 wurde bei einem Bestand von 3.983 Dokumenten durchgeführt und ist weiter unten getrennt dokumentiert.

Auch mit diesem deutlich größeren Bestand bleibt der kleine Intel-NUC für meinen Betrieb mehr als ausreichend schnell. Aufbau, Speicherwege und die Einordnung dieser Praxiserfahrung stehen im separaten Installations- und Betriebsartikel.

Welche Änderungen meine Installation betrafen

Andere Breaking Changes wurden nur daraufhin geprüft, ob sie meine SQLite-Installation und meine Skripte betrafen. Eine allgemeine Zusammenfassung aller Änderungen von Paperless-ngx 3 steht in der offiziellen Migrationsdokumentation.

Wichtig für eigene Automatisierungen: Der Wechsel der Dokument-Prüfsumme von MD5 auf SHA-256 betrifft nicht nur die Anzeige. Wer eigene Auswertungen, Exporte oder Duplikatprüfungen auf dem Checksum-Feld aufgebaut hat, muss Länge und Vergleichslogik vorab prüfen. Direkte Datenbankzugriffe sind dabei besonders sorgfältig zu behandeln; nach dem Upgrade müssen sie gegen einen echten Testbestand kontrolliert werden.

Suchindex: Tantivy statt Whoosh

Der neue Volltextindex ist mit dem früheren Whoosh-Format nicht kompatibel. Paperless baut ihn beim ersten Start automatisch neu auf; man muss keinen manuellen Reindex auslösen. Für den Betrieb heißt das trotzdem: Den ersten Start vollständig abwarten und danach nicht nur die Weboberfläche, sondern gezielt Suche, gespeicherte Ansichten und eigene Abfragen testen. Bei Ansichten, die bisher unqualifiziert auch Notizen oder benutzerdefinierte Felder fanden, kann eine Anpassung der Suchsyntax erforderlich sein.

Dateinamensvorlagen: alte Filter gegen aktuelle Platzhalter prüfen

Eigene Speicherpfade verdienen vor dem Wechsel einen kurzen Test mit einem unkritischen Dokument. Die folgende Gegenüberstellung zeigt das Prinzip – sie ist keine Aufforderung, eine funktionierende Vorlage blind zu ersetzen:

# bisherige Django-Filter-Syntax, beispielhaft
{{ created|date:"Y" }}/{{ correspondent }}/{{ title }}

# aktuelle Platzhalter-/Jinja-Syntax
{{ created_year }}/{{ correspondent }}/{{ title }}

Die aktuelle Dokumentation nennt PAPERLESS_FILENAME_FORMAT als Vorlage für Dateinamen. Bei Änderungen an dieser Einstellung werden vorhandene Dokumente nicht automatisch umbenannt; dafür ist der Dokument-Umbenenner vorgesehen. Dateien im Medienverzeichnis werden nicht von Hand verschoben.

Nach der Migration aufräumen: erst prüfen, dann Platz zurückgewinnen

Ein Major-Upgrade kann alte temporäre Verzeichnisse, nicht mehr eingebundene Ablagestrukturen oder Zwischenbestände zurücklassen. Das ist kein Anlass für ein pauschales Löschen: Zuerst prüfe ich eine aktuelle, erfolgreiche Sicherung, den Datenbankzustand und die tatsächlich aktiven Docker-Bind-Mounts. Nur was nicht aktiv eingebunden ist und nach dieser Prüfung entbehrlich bleibt, kommt für eine Bereinigung infrage.

Bei meinem Wechsel von 2.x auf 3.x wurden so rund 13,8 GB frei. Darin lagen 6,43 GB im aktiven, aber seit Tagen ungenutzten temporären Verzeichnis, 4,33 GB in einem nicht mehr eingebundenen Alt-tmp, 6,8 MB unreferenzierte Alternativdateien und zuletzt 3,04 GB eines bewusst freigegebenen 2.x-Altbestands. Vor dem Leeren des aktiven Temp-Bereichs war Paperless angehalten; danach prüfte ich Dienstzustand, API und Datenbank erneut.

Wichtig: Der Wechsel von Paperless-ngx 2.x auf 3.x änderte bei mir auch das Prüfverfahren von MD5 auf SHA-256. Unterschiedliche Prüfsummen beweisen deshalb nicht, dass ein altes Dokument überflüssig ist. Für Altbestände zählen die tatsächliche Einbindung, Sicherungsstand und fachliche Zuordnung – nicht ein Hashvergleich allein.

Für die Praxis ergibt sich eine einfache Reihenfolge: temporäre Dateien nur bei beendetem Verarbeitungslauf leeren, unreferenzierte Sonderordner einzeln prüfen und vollständige alte Datenbestände erst nach bewusster Freigabe entfernen. Backups, Exporte und die aktive Medienablage bleiben davon getrennt.

Durchführung und reale Probleme

Nach der Sicherung setzte ich das Image fest auf Version 3.0.0. Datenbankmigrationen, Umstellung der Dokumentprüfsummen und Neuaufbau des Suchindex liefen vollständig durch.

Doppelte Paperless-Prozessgruppe

paperless-webserver und paperless-worker starteten jeweils Webdienst, Consumer, Celery-Worker und Scheduler gegen dieselben Daten. Das führte zu Migrations- und Scheduler-Konflikten. Für diesen kleinen Host entfernte ich den zusätzlichen vollständigen Container.

Die Ursache lag nicht in Paperless-ngx 3 selbst, sondern in meiner gewachsenen Compose-Struktur: Zwei Dienste übernahmen gleichzeitig den vollständigen Anwendungssatz. Vor einem Upgrade sollte deshalb die Compose-Datei darauf geprüft werden, ob Webdienst, Consumer, Worker und Scheduler genau in der vorgesehenen Rollenverteilung laufen – nicht doppelt gegen dieselbe Datenbank und dieselben Verzeichnisse.

IPv4-Bindung

Mein lokales Netz bleibt bewusst bei IPv4. Mit PAPERLESS_BIND_ADDR=0.0.0.0 band ich die Anwendung ausdrücklich daran.

Dateinamensvorlage und Klassifikator

Ein Testimport deckte die alte Template-Syntax auf. Nach der Umstellung auf Jinja blieb der bestehende Speicherpfad erhalten. Das alte Klassifikationsmodell wurde beim ersten Import verworfen; die Dokumente selbst waren davon nicht betroffen.

End-to-End-Test

Ein synthetisches bildbasiertes PDF ohne produktive Daten durchlief den echten Eingang:

Der Test prüfte damit mehr als einen gestarteten Webserver: Eingang, OCR, Suche, Workflows, Dokumentabruf und die eigene Fail-closed-Duplikatroutine. Wie ähnliche Dokumente danach ohne automatisches Löschen geprüft werden, zeigt der Praxistest zur Fuzzy Duplicate Detection.

Die rund 925 Sekunden bis zum Teststart waren kein allgemeiner Paperless-Standard und auch kein Fehler der v3-Migration. Sie ergaben sich aus meiner damals bewusst gesetzten Stabilitätswartezeit PAPERLESS_CONSUMER_STABILITY_DELAY=720 zusammen mit dem lokalen Polling-Intervall. Solche Werte müssen zum eigenen Eingangsweg passen: Bei langsamen Netzwerkfreigaben schützen sie vor zu frühem Import, bei zeitkritischem Einzug verlängern sie bewusst die Wartezeit.

Wiederholungstest nach dem Rückbau der Consumer-Wartezeit

Am 23. September 2026 habe ich den End-to-End-Test mit dem lokalen Consume-Ordner und den aktuellen Werten PAPERLESS_CONSUMER_POLLING_INTERVAL=0 sowie PAPERLESS_CONSUMER_STABILITY_DELAY=5 wiederholt. Ein neues bildbasiertes Test-PDF durchlief Eingang, OCR, Suche, Dokumentdatum, Original- und Archivdatei. Der Volltext war beim ersten gezielten Kontrollabruf nach 15 Sekunden auffindbar; der Workflow setzte den Tag Posteingang.

Der identische zweite Testimport wurde erwartungsgemäß nicht automatisch verworfen, weil PAPERLESS_CONSUMER_DELETE_DUPLICATES=false bewusst gesetzt ist. Beide Testdokumente ließen sich über dieselbe SHA-256-Prüfsumme erkennen. Anschließend wurden die beiden Datenbankeinträge sowie alle vier zugehörigen Original- und Archivdateien entfernt; der Ausgangsbestand war wieder erreicht. Damit ist der aktuelle Betrieb mit kurzer Wartezeit geprüft, ohne automatische Duplikatlöschung zu behaupten.

Hinweis für PostgreSQL- und MariaDB-Installationen

Mein Praxisbeispiel nutzt SQLite. Wer PostgreSQL oder MariaDB einsetzt, sollte beim Wechsel auf v3 zusätzlich die Datenbank-Konfiguration gegen die Migrationshinweise prüfen: PAPERLESS_DBENGINE muss dann ausdrücklich gesetzt sein; ältere Einzeloptionen wurden in PAPERLESS_DB_OPTIONS zusammengeführt. Die konkrete Kompatibilität der eingesetzten Datenbankversion gehört in die Release Notes der gewählten Zielversion und in den eigenen Testweg.

Messwerte und Grenzen

Nach der Bereinigung antwortete die lokale Startseite in fünf Einzelmessungen nach rund 3,4 bis 4,1 ms. Beim Testimport nutzte Paperless etwa einen CPU-Kern und maximal rund 916 MiB RAM. Der Neustart bis zur ersten HTTP-Antwort dauerte rund 93 Sekunden, bis zum Docker-Status healthy rund 100 Sekunden.

Das sind Messwerte dieser Installation und keine allgemeine Leistungszusage. Ein identischer Vorher-Nachher-Test für OCR, große PDFs und parallele Last wurde nicht durchgeführt.

Ergebnis des dokumentierten Upgrades

Datenbankintegrität, API v10, Suche, Dokumentabruf, OCR und die eigene SHA-256-Routine funktionierten nach dem Upgrade. Die doppelte Prozessgruppe und die alte Dateinamenssyntax wurden bereinigt. Spätere Wartungsupdates sind in den allgemeinen Ablauf dieses Beitrags übernommen.

Offen bleiben ein erneut vollständig protokollierter Host-Restore und reproduzierbare Vergleichsmessungen mit großen Dokumenten.

Quellen und weiterführende Praxis

• Paperless-ngx-Dokumentation
• Paperless-ngx: Administration und Docker-Upgrade
• Migration auf Version 3

• Paperless-ngx 3.0.0

• Dubletten mit Fuzzy Duplicate Detection prüfen – ähnliche Dokumente bewerten, ohne automatisch zu löschen

• Paperless-ngx zuverlässig sichern – Backup, Prüfung und Wiederherstellbarkeit
• Paperless-ngx-Arbeitsabläufe aus der Praxis – Regeln, Posteingang und menschliche Sichtkontrolle

Ursprüngliche Quelle: digitale-archive/paperless-ngx-3-2-0-duplikate-freigabelinks/paperless-ngx-3-2-0-duplikate-freigabelinks.md. Ursprüngliche Metadaten (historisch):

title: "Paperless-ngx 3.2.0: Duplikate filtern und Freigabelinks verwalten"
description: "Paperless-ngx 3.2.0 bringt einen Duplikatfilter und eine zentrale Verwaltung für Freigabelinks. Praxisbewertung für Docker und SQLite."
slug: paperless-ngx-3-2-0-duplikate-freigabelinks
route: digitale-archive/paperless-ngx-3-2-0-duplikate-freigabelinks
wdb: true
scope: public
domain: "Digitale Archive"
category: "Digitale Archive"
tags: [Paperless-ngx, Duplikate, Freigabelinks, Docker, SQLite, Dokumentenarchiv]
meta_title: "Paperless-ngx 3.2.0: Duplikate filtern & Freigabelinks"
author: "Eric Beuchel"
date: '2026-09-19'
lastmod: '2026-09-21'
version: '1.0'
status: stable
published: true
wp:
  publish: true

Kurz gesagt

Stand: 21. September 2026. Paperless-ngx 3.2.1 ist als stabiles Release veröffentlicht. Meine produktive Installation läuft mit Paperless-ngx 3.2.1, Docker und SQLite; der größere Altbestandsimport ist abgeschlossen.

Das Wichtigste zu Paperless-ngx 3.2.0

Duplikate: Erkannte Dubletten lassen sich jetzt gezielt filtern und anschließend prüfen. Freigabelinks: Bestehende Freigaben und Dokument-Bündel können zentral verwaltet werden. SQLite: Für meine Installation besteht kein Grund für einen Datenbankwechsel. Update: Der kontrollierte Wechsel von 3.1.3 auf 3.2.0 ist nach Sicherung und Prüfung abgeschlossen. 3.2.1: Das Folgerelease verbessert die OCR-Textebene und macht den Suchindex robuster; der kontrollierte Wechsel von 3.2.0 auf 3.2.1 ist ebenfalls geprüft und abgeschlossen.

Die Version erweitert den laufenden Archivbetrieb, ohne die grundsätzliche Arbeitsweise zu verändern: Dokumente bleiben sorgfältig erschlossen, Dubletten werden geprüft statt blind gelöscht, und Freigaben bleiben gezielte Ausnahmen.

Update auf Paperless-ngx 3.2.1: OCR und Suchindex

Paperless-ngx 3.2.1 ist ein gezieltes Qualitätsupdate für OCR und Volltextsuche. OCRmyPDF wurde auf Version 17.12 aktualisiert. Damit wird ein Fehler in der erzeugten Textebene bei Ligaturen korrigiert – also bei Zeichenverbindungen wie „fi“ oder „fl“. Bereits verarbeitete Dokumente werden dadurch nicht automatisch geändert. Wenn ein bestimmtes Dokument bei solchen Wörtern auffällig ist, kann es gezielt erneut verarbeitet werden.

Auch der Tantivy-Suchindex behandelt fehlende Indexbestandteile jetzt robuster: Paperless baut den Index in diesem Fall automatisch neu auf, statt mit einem Fehler abzubrechen. Das schützt nicht unmittelbar die SQLite-Dokumentdaten; die Entwickler weisen außerdem darauf hin, dass die Ursache gelegentlich fehlender Indexdateien noch nicht abschließend geklärt ist. Ein eigener Sicherungs- und Prüfablauf bleibt deshalb unverzichtbar.

Für meinen Ablauf sind beide Korrekturen sinnvoll, weil Recherche primär über die OCR-Textebene und einen verlässlichen Suchindex erfolgt. Die Änderung an der E-Mail-Sperre hat dagegen praktisch keine Auswirkung: MailStore Pro bleibt das vollständige E-Mail-Archiv, ausgewählte Anhänge gelangen weiterhin nur gezielt nach Paperless.

Kontrollierter Wechsel von 3.2.0 auf 3.2.1

Vor dem Update wurde ein zusätzlicher Borg-Sicherungslauf einschließlich konsistentem SQLite-Snapshot angelegt; PRAGMA integrity_check lieferte ok. Danach wurde das Docker-Image fest auf 3.2.1 gesetzt und nur der Paperless-Webdienst neu erstellt.

Nach dem Start war der Dienst wieder gesund. Der vorhandene Suchindex wurde als aktuell erkannt; ein unerwarteter automatischer Indexneuaufbau trat nicht auf. Anschließend wurde ein vorhandenes Referenzdokument gezielt neu verarbeitet. Die OCR-/Indexaufgabe lief erfolgreich durch, und die Referenzsuche nach „Finanzierung“ fand das Dokument weiterhin.

Die Governance-Regeln bleiben unverändert: Die Verfahren „Suche primär über OCR“ und „verlässlicher Suchindex“ sind betroffen, die bestehenden Sicherungs-, Prüf- und Rechercheprinzipien decken die Änderung jedoch bereits ab.

Paperless-ngx Duplikate filtern: Arbeitsliste für die Bestandskontrolle

Paperless-ngx 3.2.0 macht erkannte Duplikate leichter auffindbar. In der Dokumentenliste kann jetzt gezielt nach Dokumenten mit oder ohne erkannte Dubletten gefiltert werden. Das ist besonders praktisch, wenn ein größerer Bestand bereits importiert wurde und anschließend kontrolliert werden soll.

Seit Paperless-ngx 3 werden technisch identische Dokumente standardmäßig nicht mehr beim Einzug verworfen. Die neue Kopie wird aufgenommen; Paperless weist in der Aufgabe auf die erkannte Dublette hin und verknüpft die gleichen Inhalte in der Dokumentansicht. Nur wenn PAPERLESS_CONSUMER_DELETE_DUPLICATES=true gesetzt ist, wird die eingehende Datei wieder abgewiesen. Die offizielle Dokumentation zur Dublettenprüfung beschreibt beide Wege.

Dubletten beim Import bewusst prüfen statt verwerfen

In meinem Archiv bleibt das automatische Verwerfen deaktiviert. Eine technische Gleichheit ist ein wichtiges Signal, aber keine fachliche Löschentscheidung. Zwei gleichartige Dateien können unterschiedliche Metadaten, Ablagekontexte oder eine bessere Scanqualität haben.

Der Ablauf bleibt deshalb bewusst einfach:

Erkennen → prüfen → entscheiden → gegebenenfalls bereinigen.

Die ausführliche Praxisprüfung trennt zudem identische Dateien von bloß ähnlichen OCR-Texten: Dubletten mit Fuzzy Duplicate Detection prüfen. Auch hohe Textähnlichkeit ersetzt keine Sichtprüfung.

Paperless-ngx Freigabelinks zentral verwalten

Paperless-ngx kann einzelne Dokumente oder ein Bündel ausgewählter Dokumente über Freigabelinks bereitstellen. Solche Links benötigen beim Empfänger keinen Paperless-Login, sind eindeutig und können ein Ablaufdatum erhalten. Für mehrere Dokumente erzeugt Paperless ein ZIP-Archiv und stellt dafür einen gemeinsamen Link bereit.

Mit 3.2.0 lassen sich Freigabelinks und Link-Bündel zentral verwalten. Das ist besonders dort hilfreich, wo einzelne Dokumente zeitweise weitergegeben werden: Aktive und abgelaufene Freigaben müssen nicht mehr allein am jeweiligen Dokument gesucht werden. Die offizielle Nutzungsdokumentation zu Freigabelinks beschreibt weiterhin die Sicherheits- und Ablaufoptionen.

Freigaben kontrolliert einsetzen

Für meinen Betrieb bleiben Freigabelinks eine Zusatzfunktion. Paperless-ngx ist ein Dokumentenmanagement- und Recherchewerkzeug, keine allgemeine Filesharing-Plattform. Eine Freigabe wird deshalb nur für klar bestimmte Unterlagen, einen festgelegten Empfängerkreis und möglichst mit Ablaufdatum angelegt.

Bei einer öffentlich erreichbaren Installation ist außerdem entscheidend, dass der Pfad eines Freigabelinks nicht durch eine vorgeschaltete Anmeldung blockiert wird. Die offizielle Dokumentation weist darauf hin, dass dafür gegebenenfalls eine eng begrenzte Ausnahme im Reverse Proxy nötig ist. Das ist eine Sicherheitsentscheidung für den konkreten Betrieb – keine allgemeine Konfigurationsempfehlung.

SQLite bleibt unverändert im Einsatz

Die Version 3.2.0 ist für mich kein Anlass, die Datenbankstrategie zu wechseln. Für meine überschaubare Installation hat sich SQLite bewährt: wenig Komplexität, einfache Sicherung und für meinen Anwendungsfall ausreichende Leistung.

Paperless-ngx + Docker + SQLite bleibt daher meine Konfiguration.

Wie Updates und Upgrades vorbereitet und geprüft werden, beschreibt der Beitrag Paperless-ngx aktualisieren: Updates, Upgrades und meine Praxis.

Dauerhafter Archivbetrieb: Nach dem Altbestandsimport zählt die Qualität

Die Importphase ist abgeschlossen. Damit verlagert sich der Schwerpunkt im täglichen Betrieb auf:

• zuverlässige OCR und Volltextsuche,
• konsistente Metadaten,
• nachvollziehbare Dokumenttypen und Korrespondenten,
• wenige, gezielt eingesetzte Tags,
• kontrollierte Duplikatprüfung,
• belastbare Datensicherung und
• langfristige Wartbarkeit.

Neue Versionen sind vor allem dann relevant, wenn sie diese Arbeit verbessern. Die Versionsnummer allein ist kein Grund für eine Änderung am Produktivsystem.

Paperless-ngx 3.2.0 kontrolliert aktualisieren

Vor dem Update prüfe ich die offiziellen Release Notes und insbesondere folgende Punkte:

• Release Notes und bekannte Probleme,
• SQLite und notwendige Datenbankmigrationen,
• Consumer und Dokumentenverarbeitung,
• OCR und Suche sowie
• die aktuelle Datensicherung.

Diese Punkte waren unauffällig. Deshalb habe ich das produktive System am 19. September 2026 von 3.1.3 auf 3.2.0 aktualisiert.

Das ausgeführte Update in der Praxis

Unmittelbar vor dem Update lief ein zusätzlicher Borg-Sicherungslauf erfolgreich durch. Danach wurde das Paperless-Image fest auf Version 3.2.0 gesetzt und der Webdienst neu erstellt. Paperless führte zwei Datenbankmigrationen aus und baute wegen einer geänderten Schema-Version den Suchindex neu auf.

Nach Abschluss des Neuaufbaus war der Webdienst gesund und die Weboberfläche wieder erreichbar. Die SQLite-Integritätsprüfung lieferte ok; alle 3.929 Dokumente waren weiterhin erfasst. Auch die angebundenen Dienste wurden aus Paperless heraus geprüft:

• Apache Tika 3.3.1.0: erreichbar; ein neuerer passender Tag wird im verwendeten offiziellen Docker-Repository derzeit nicht bereitgestellt.
• Gotenberg 8.37.0: zeitgleich auf den aktuellen 8.x-Sicherheitsstand aktualisiert und erreichbar.

Die Grundlagen und den bereits ausgeführten Major-Wechsel beschreibt der Praxisbericht zum Upgrade auf Paperless-ngx 3.0. Die hier genannten Werte dokumentieren den konkreten Stand dieser Installation und sind keine allgemeine Leistungszusage.

Fazit

Paperless-ngx 3.2.0 ist kein grundlegender Umbau, sondern ein sinnvolles Funktionsupdate. Für bestehende Archive ist vor allem der Duplikatfilter interessant: Er erleichtert die nachträgliche Kontrolle eines gewachsenen Dokumentenbestands.

Die zentrale Verwaltung der Freigabelinks schafft zusätzlich mehr Übersicht, wenn Dokumente zeitweise extern bereitgestellt werden.

An meiner technischen Basis ändert das nichts: Docker und SQLite bleiben bestehen. Das Update von 3.1.3 auf 3.2.0 ist nach Sicherung, Migrationen, Suchindex-Neuaufbau und technischen Prüfungen abgeschlossen.

Für mich zählt dabei weiterhin nicht die Versionsnummer, sondern ein nachvollziehbarer, sicherbarer und langfristig beherrschbarer Dokumentenbestand.

Quellen

• Offizielle Release Notes zu Paperless-ngx 3.2.0
• Artikel bei Stadt-Bremerhaven – journalistischer Überblick
• Paperless-ngx: Duplicate documents – Standardverhalten und Prüfung
• Paperless-ngx: Share links – Freigabelinks und Link-Bündel
• Paperless-ngx-Konfiguration – Einstellung zum Umgang mit Duplikaten
• Offizielle Release Notes zu Paperless-ngx 3.2.1
• OCRmyPDF-Update mit Ligatur-Korrektur
• Automatischer Neuaufbau bei fehlenden Tantivy-Indexdateien

Ursprüngliche Quelle: digitale-archive/paperless-ngx-3-3-update-tika-4-praxis/paperless-ngx-3-3-update-tika-4-praxis.md. Ursprüngliche Metadaten (historisch):

title: "Paperless-ngx 3.3: Update, Datumsfehler und Tika 4 im Praxistest"
description: "Paperless-ngx 3.3.0 sicher aktualisieren: Datumsfehler im Suchindex lösen, Wiederherstellung prüfen und Tika 4 vor dem Einsatz mit Paperless testen."
slug: paperless-ngx-3-3-update-tika-4-praxis
route: digitale-archive/paperless-ngx-3-3-update-tika-4-praxis
wdb: true
scope: public
domain: "Digitale Archive"
category: "Digitale Archive"
tags: [Paperless-ngx, Docker, SQLite, Datensicherung, Metadaten, Tika, Gotenberg, Redis]
meta_title: "Paperless-ngx 3.3: Datumsfehler lösen und Tika 4 prüfen"
author: "Eric Beuchel"
date: '2026-10-06'
lastmod: '2026-10-06'
version: '1.0'
status: stable
published: true
wp:
  publish: true

Ein Dokumentenarchiv muss nach einem Update weiterhin recherchierbar sein. Eine laufende Datenbank allein genügt dafür nicht: Auch Suchindex, Hintergrundaufgaben, Textextraktion und Dokumentdownloads müssen funktionieren. Mein Wechsel von Paperless-ngx 3.2.1 auf 3.3.0 zeigte, warum ein geprüfter Rückweg ebenso wichtig ist wie die neue Version.

Stand: 6. Oktober 2026. Paperless-ngx 3.3.0 läuft inzwischen gesund mit Docker und SQLite. Der erste Versuch scheiterte an zwei alten Dokumentdatumswerten. Nach einer kontrollierten Wiederherstellung, einer belegten Datumskorrektur und einer neuen Sicherung gelang das Update. Tika 4.1.0 bestand dagegen den separaten Kompatibilitätstest mit dem verwendeten Paperless-Client nicht.

Die wichtigste Erfahrung: Ein verfügbares Update ist erst dann für den eigenen Archivbetrieb geeignet, wenn die tatsächlich verwendeten Funktionen mit dem vorhandenen Bestand geprüft sind. Ein neuer Container und ein grüner Startstatus ersetzen diese Prüfung nicht.

Ein verlässlicher Ablauf für das Archiv

Die dauerhafte Methode lautet: Ausgangszustand erfassen, konsistent sichern, gezielt aktualisieren und die Nutzung des Archivs erneut prüfen. Wenn der Dienst nicht betriebsbereit wird, geht es zurück zum gesicherten Zustand. Erst danach wird die Ursache untersucht.

Der allgemeine Ablauf ist im Beitrag Paperless-ngx aktualisieren: Updates, Upgrades und meine Praxis beschrieben. Dieser Bericht ergänzt ihn um den konkreten Fehlerfall und den Test der zusätzlichen Docker-Dienste. Die Grundlagen zur konsistenten Sicherung stehen unter Warum ein normales Backup für Paperless-ngx nicht reicht.

Der erste Updateversuch: Datenbankmigration erfolgreich, Suche blockiert

Vor dem Wechsel wurde eine frische Sicherung mit dem bestehenden Borg-Verfahren erstellt. Sie enthielt einen konsistenten SQLite-Snapshot und die Konfiguration. Die Datenbankprüfung mit PRAGMA integrity_check meldete ok. Im Eingang lagen keine unverarbeiteten Dateien; es waren keine Verarbeitungsaufträge aktiv.

Anschließend wurde das feste Image ghcr.io/paperless-ngx/paperless-ngx:3.3.0 geladen und der Webdienst ausdrücklich neu erstellt. Die Datenbankmigrationen liefen erfolgreich. Beim anschließenden Aufbau des Suchindexes brach der Start jedoch ab:

ValueError: datetime out of representable range

Der Fehler entstand beim Übertragen des Dokumentdatums in den Tantivy-Suchindex:

doc.add_date("created", created_date)

Das ist eine entscheidende Unterscheidung: Die Datenbank konnte den vorhandenen Wert speichern, der Suchindex konnte ihn in dieser getesteten Kombination nicht übernehmen. Der Fehler bewies weder einen beschädigten Dokumentinhalt noch einen allgemeinen Datenbankdefekt.

Erst wiederherstellen, dann die Ursache klären

Der nicht betriebsbereite Dienst wurde gestoppt. Aus der gerade erzeugten Borg-Sicherung wurde der konsistente SQLite-Snapshot entnommen, geprüft und wiederhergestellt. Auch das Paperless-Image wurde auf 3.2.1 zurückgesetzt. Nur das alte Image zu starten hätte die bereits ausgeführten Datenbankmigrationen nicht rückgängig gemacht.

Nach dem Rückweg waren die Datenbank und die Dokumentprüfsummen wieder geprüft. Erhalten blieben 4.080 aktive Dokumentdatensätze sowie die vorhandenen Papierkorbeinträge. Der Dienst erreichte erneut den Zustand healthy; Suche, Dokumentzugriff und Hintergrundworker funktionierten.

Dieser konkrete Rückweg wurde tatsächlich durchgeführt. Die Borg-Archivprüfung war eine zusätzliche Kontrolle, aber keine vollständige Prüfung aller gespeicherten Datenblöcke mit --verify-data. Ebenso war dies kein vollständiger Wiederaufbau auf einem zweiten Server. Solche Nachweise sind getrennt zu betrachten.

Zwei alte PowerPoint-Dateien mit dem Datum 01.01.1601

Die Untersuchung aller 4.080 Dokumente umfasste insgesamt 12.240 Werte aus den Feldern Dokumentdatum, hinzugefügt und geändert. Die Prüfung erfolgte separat mit der Suchindex-Bibliothek aus dem 3.3.0-Image und veränderte keine Dokumente. Genau zwei Werte lösten den Fehler aus: 01.01.1601 im Feld created.

Beide betroffenen Originale waren alte PowerPoint-Dateien. Im extrahierten Text stand kein eindeutiges Dokumentdatum. Die Metadaten der Originaldateien enthielten selbst das Erstellungsdatum 1601; zugleich war jeweils ein plausibles Datum der letzten Änderung gespeichert. Damit ließ sich der problematische Wert bis zur Originaldatei zurückverfolgen.

Die belegte Korrektur

Für diese beiden Dokumente habe ich bewusst das Datum der letzten Änderung aus der Originaldatei als Ersatz festgelegt. Es ist ein belegbarer Anhaltspunkt, aber kein nachträglich bewiesenes Erstellungs- oder Präsentationsdatum.

Geändert wurde ausschließlich das Dokumentdatum in Paperless. Die Originaldateien blieben unverändert. Die neuen Werte wurden anschließend durch einen eigenen API-Lesezugriff kontrolliert. Der Vergleich der gespeicherten Original- und Archivprüfsummen über den gesamten aktiven Bestand blieb identisch.

Kein pauschales Ersatzdatum: Nicht alle historischen Dokumente haben ein unbrauchbares Datum. Eine automatische Umstellung aller frühen Jahreszahlen auf das Importdatum würde belegte Archivinformationen zerstören. Entscheidend sind Original, Inhalt, Metadaten und die bewusste Entscheidung für den konkreten Fall.

Auch beim Rückweg meldete 3.2.1 einen notwendigen Neuaufbau des Suchindexes und wurde anschließend wieder betriebsbereit, noch bevor die zwei Datumswerte korrigiert waren. Die ältere Kombination konnte den Bestand in diesem Ablauf also verarbeiten. Welche Änderung im Detail den Unterschied zur geprüften 3.3.0-Kombination verursacht, wurde nicht untersucht. Der konkrete Fehlerfall rechtfertigt keine pauschale Aussage über alle historischen Datumswerte oder alle Tantivy-Versionen.

Der zweite Versuch: Paperless-ngx 3.3.0 erfolgreich

Nach der Datumskorrektur wurde erneut eine frische Sicherung erstellt und das Archiv geprüft. Erst dann folgte der zweite Updateversuch. Diesmal liefen die Migrationen und der notwendige Suchindex-Aufbau durch; Paperless erreichte den gesunden Betriebszustand.

Der Prüfsummenvergleich über alle Datensätze verifiziert die gespeicherten Prüfsummenwerte. Er ersetzt keine erneute vollständige Hashprüfung aller Originaldateien auf dem Datenträger. Die beiden Downloads belegen den tatsächlichen Dateizugriff für die geprüften Stichproben.

Was das Release zusätzlich bringt

Die offiziellen Hinweise zu Paperless-ngx 3.3.0 nennen unter anderem gespeicherte Barcode-Inhalte, die Einbindung des Django-Adminbereichs mit Zwei-Faktor-Authentifizierung und Korrekturen bei Indexierung, Dokumentversionen und der Protokollierung von Sammeländerungen. Diese Funktionen wurden hier nicht sämtlich eingerichtet oder abgenommen. Der Schwerpunkt des eigenen Tests lag auf dem bestehenden Archivbetrieb.

Weitere Docker-Dienste einzeln bewerten

Paperless nutzt zusätzliche Dienste für Hintergrundaufgaben, Textextraktion und Konvertierung. Ein Gesamtupdate mit beliebigen latest-Images würde mehrere Fehlerquellen gleichzeitig verändern. Deshalb wurde jeder vorhandene Dienst getrennt mit dem verfügbaren Herstellerstand verglichen.

Bei Redis änderte sich der Image-Build, nicht die angezeigte Redis-Version. Ein festes Versionsetikett oder ein unveränderlicher Image-Digest macht spätere Schritte besser nachvollziehbar; ein beweglicher Tag wie 7-alpine muss deshalb immer zusammen mit dem tatsächlich laufenden Image geprüft werden. Der vorhandene Tag wurde in diesem Durchlauf beibehalten.

Gotenberg 8.37.0 war bereits der aktuelle Release-Stand. Die Releasehinweise zu Gotenberg 8.37.0 beschreiben unter anderem Sicherheitskorrekturen und Verbesserungen bei Konvertierungen. Das bloße Vorliegen eines aktuellen Releases war hier kein Grund, einen bereits passenden Container erneut zu starten.

Debian-Systempakete und die Docker-Engine wurden in diesem Durchlauf nicht aktualisiert. Dieser Bericht behandelt die vorhandenen Anwendungscontainer, nicht eine abgeschlossene Wartung des gesamten Betriebssystems.

Tika 4: Verfügbares Release ist noch kein Kompatibilitätsnachweis

Laut Apache-Tika-Downloadseite ist 4.1.0 die aktuelle Hauptversion. Die weiterhin unterstützte 3.x-Reihe hat den Stand 3.3.2. Tika 4 benötigt mindestens Java 17 und bringt Änderungen an Paketierung und Konfiguration mit. Für Docker zählen zusätzlich die tatsächlich veröffentlichten Images: Zum Prüfzeitpunkt war kein offizieller Tag für Tika 3.3.2 verfügbar.

Deshalb wurde das stabile Image apache/tika:4.1.0-1 in einem separaten, vorübergehenden Container untersucht. Dieser erhielt keine produktiven Datenvolumes und keinen veröffentlichten Host-Port. Der laufende Tika-3-Dienst blieb währenddessen bestehen. Die Testanfragen liefen im internen Docker-Netz über den Tika-Client, den Paperless 3.3.0 tatsächlich verwendet.

Der konkrete HTTP-404-Befund

Schon die Textextraktion einer vorhandenen PowerPoint-Datei scheiterte:

404 Not Found
/tika/form/text

Das ist kein Hinweis auf eine beschädigte PowerPoint-Datei: Derselbe Aufruf funktionierte mit dem produktiven Tika 3.3.1.0. Die benötigte Schnittstelle war im getesteten Tika-4.1.0-Image unter diesem Pfad nicht verfügbar. Damit war die Kombination für diesen Paperless-Verarbeitungsweg ungeeignet.

Die Dokumentation der offiziellen Tika-Docker-Images nennt weiterhin verfügbare Standardendpunkte. Das genügt jedoch nicht als Nachweis für jeden Client und jeden Unterpfad. Ein erreichbarer Server oder ein erfolgreicher Aufruf von /tika sagt nichts darüber aus, ob auch /tika/form/text wie vom eingesetzten Client erwartet funktioniert.

Folge: Der Testcontainer wurde beendet und entfernt. Der produktive Tika-Dienst blieb auf 3.3.1.0. Anschließend wurden Textextraktion und Metadatenzugriff erneut mit zwei vorhandenen PowerPoint-Dateien erfolgreich geprüft. Es wurden keine neuen Archivdokumente importiert und keine produktiven Dokumente neu verarbeitet.

Was vor einem späteren Tika-4-Wechsel noch zu prüfen ist

1. Die dann aktuellen Releasehinweise von Tika und Paperless lesen und die genaue Client-Version erfassen.
2. Ein festes, veröffentlichtes Docker-Image auswählen; keine Snapshot- oder Preview-Version einsetzen.
3. Die benötigten Aufrufe für Text und Metadaten mit dem tatsächlichen Paperless-Client separat testen.
4. Zusätzlich repräsentative Dateiformate aus dem eigenen Einzug prüfen, etwa Word, Excel, PowerPoint und E-Mail-Dateien, soweit sie tatsächlich genutzt werden.
5. Konfigurationsänderungen von Tika 4 und mögliche Client-Anpassungen abgleichen. Erst nach erfolgreichem Test, frischer Sicherung und gesichertem Rückweg produktiv umstellen.

Hier wurde kein Workaround eingebaut, kein Paperless-Code verändert und keine generelle Aussage getroffen, dass jede Tika-4-Version mit jeder Paperless-Version unvereinbar sei. Der offene Punkt betrifft die konkret geprüfte Kombination. Ein späteres Image oder eine Client-Korrektur kann eine neue Prüfung sinnvoll machen.

Kurze Checkliste für den nächsten Wartungstermin

• Vorher: Versionen, laufende Images, Datenbankintegrität und aktive Aufgaben feststellen.
• Sicherung: konsistenten Datenbankstand, Dokumentdateien und Konfiguration im bestehenden Verfahren erfassen.
• Neustart: gezielt einen Dienst ändern und die anderen Komponenten im Blick behalten.
• Fehlerfall: Protokoll sichern, betriebsfähigen Zustand wiederherstellen, Ursache mit Originalquellen prüfen.
• Nachher: Laufzeitversion, Migrationen, Suchindex, Referenzsuche, Dokumentzugriff und Worker nachweisen.
• Abhängigkeiten: Konvertierung und Textextraktion über die tatsächlich verwendeten Schnittstellen prüfen.
• Abschluss: Erfolgreich aktualisiert, unverändert aktuell und bewusst zurückgestellt getrennt dokumentieren.

Fazit

Das Update auf Paperless-ngx 3.3.0 ist erfolgreich abgeschlossen. Ausschlaggebend war, den ersten Fehlschlag kontrolliert zurückzunehmen, die zwei problematischen Datumswerte an den Originalen zu prüfen und den zweiten Versuch mit einer neuen Sicherung zu beginnen. Suche und Dokumentzugriff sind nachgewiesen; die Originaldateien blieben unverändert.

Bei den ergänzenden Diensten führte dieselbe Methode zu unterschiedlichen Ergebnissen: Redis erhielt ein neueres Image, Gotenberg war bereits aktuell, und Tika 4.1.0 wurde nach dem Schnittstellenfehler zurückgestellt. Ein dauerhaft nutzbares Archiv entsteht durch nachvollziehbare Entscheidungen und geprüfte Rückwege – auch wenn die richtige Entscheidung vorerst lautet, eine neue Version noch nicht einzusetzen.

Weiterführende Praxis und Quellen

• Paperless-ngx aktualisieren: Updates, Upgrades und meine Praxis
• Konsistente Sicherung und Wiederherstellung von Paperless-ngx
• Paperless-ngx auf einem Debian-Server
• Paperless-ngx im privaten digitalen Archiv
• Paperless-ngx 3.3.0: offizielle Releasehinweise
• Apache Tika: aktuelle Releases und unterstützte 3.x-Reihe
• Apache Tika: offizielle Docker-Images und Schnittstellenhinweise
• Offizielle Tika-Image-Tags
• Gotenberg 8.37.0: offizielle Releasehinweise

Die eigenen Testergebnisse stammen vom 6. Oktober 2026. Versionsstände, verfügbare Image-Tags und Schnittstellen können sich ändern; die beschriebene Sicherungs- und Prüfmethode bleibt davon unabhängig.

Ursprüngliche Quelle: digitale-archive/paperless-ngx-3-3-1-update-begleitdienste/paperless-ngx-3-3-1-update-begleitdienste.md. Ursprüngliche Metadaten (historisch):

title: "Paperless-ngx 3.3.1: Patchupdate und Begleitdienste geprüft"
description: "Paperless-ngx 3.3.1 im Praxisbetrieb: gesichertes Patchupdate, Suchindex und Downloads geprüft sowie Redis, Gotenberg und Tika getrennt bewertet."
slug: paperless-ngx-3-3-1-update-begleitdienste
route: digitale-archive/paperless-ngx-3-3-1-update-begleitdienste
wdb: true
scope: public
domain: "Digitale Archive"
category: "Digitale Archive"
tags: [Paperless-ngx, Docker, Datensicherung, Datenintegrität, Tika, Gotenberg, Redis]
meta_title: "Paperless-ngx 3.3.1: Update und Begleitdienste in der Praxis"
author: "Eric Beuchel"
date: '2026-10-13'
lastmod: '2026-10-13'
version: '1.0'
status: stable
published: true
wp:
  publish: true

Ein Dokumentenarchiv soll nach einem Update genauso zuverlässig nutzbar sein wie vorher. Dazu gehören die Suche, der Zugriff auf Originale und die Verarbeitung neuer Dateien. Bei einer Installation mit mehreren Diensten genügt es deshalb nicht, nur die Versionsnummer der Hauptanwendung zu kontrollieren.

Stand: 13. Oktober 2026. Mein Paperless-ngx wurde von 3.3.0 auf 3.3.1 aktualisiert. Die Datenbank blieb konsistent, die Suche funktionierte und zwei Originaldownloads bestanden den Prüfsummenvergleich. Die Begleitdienste wurden getrennt bewertet: Redis und Gotenberg waren bereits auf dem aktuellen Stand ihrer eingesetzten Reihen. Tika 4.1.0-1 wurde erneut außerhalb des produktiven Dienstes mit dem Paperless-Client getestet.

Der praktische Nutzen: Eine neue Versionsnummer ist kein ausreichender Grund, alle Container auszutauschen. Entscheidend sind ein gesicherter Ausgangszustand, kompatible Schnittstellen und nachvollziehbare Funktionsprüfungen.

Erst das Archiv sichern, dann das Werkzeug aktualisieren

Die Methode bleibt auch bei kleinen Patchupdates dieselbe: laufende Importe ausschließen, eine konsistente Sicherung erstellen, die Änderung begrenzen und anschließend die Nutzung prüfen. Im Eingang lagen vor diesem Update keine Dateien; der Hintergrundworker meldete keine aktiven Verarbeitungsaufträge.

Die frische Sicherung entstand mit meinem bestehenden Borg-Verfahren. Sie wurde erfolgreich abgeschlossen und zusätzlich auf Archivebene geprüft. Das Verfahren enthält einen konsistenten SQLite-Snapshot und die Anwendungskonfiguration. Die Ausgangskonfiguration wurde für den unmittelbaren Rückweg separat auf dem Server gesichert.

Die Archivebene-Prüfung war keine vollständige Prüfung aller Sicherungsdaten mit --verify-data. Bei diesem Patchupdate war auch keine Wiederherstellung notwendig. Ein neu durchgeführter vollständiger Restore-Test wird damit nicht behauptet. Warum ein konsistenter Datenbankstand wichtig ist, erklärt der Beitrag Paperless-ngx sichern.

Was 3.3.1 für den bisherigen Fehlerfall bedeutet

Der vorige Praxisbericht über Paperless-ngx 3.3.0 dokumentiert einen Startfehler beim Indexieren historischer Datumswerte. Zwei alte Originaldateien enthielten das Datum 01.01.1601. Erst nach einem geprüften Rückweg und einer bewusst festgelegten Datumskorrektur gelang der damalige Wechsel.

Die am 12. Oktober 2026 veröffentlichte Version 3.3.1 korrigiert mehrere für den Archivbetrieb relevante Fehler aus 3.3.0:

• Stapelweises Reprocessing verarbeitet bei einem Hauptdokument mit Versionshistorie die neueste Version.
• Ein unterbrochener Suchindex-Neuaufbau wird erneut gestartet.
• Nicht darstellbare Erstellungsdaten sollen den Volltextindex nicht mehr blockieren.
• Dokumentversionen werden bei Indexierung und Berechtigungsprüfung ihrem Hauptdokument zugeordnet.

Das Release ist ein reguläres Patchupdate; die Release-Hinweise weisen es nicht als Sicherheits- oder Notfallupdate aus. Wer noch vor dem Wechsel von 3.2.1 steht, hat damit 3.3.1 als sinnvolleren Zielstand als 3.3.0. Mein hier dokumentierter Lauf begann bereits bei 3.3.0 und belegt keinen direkten Sprung von 3.2.1.

Das ist für den früheren Fehlerfall relevant. In meinem heutigen Bestand waren die beiden Daten aber bereits korrigiert. Ich habe die alten Werte nicht erneut produktiv eingetragen. Der erfolgreiche Patchwechsel belegt deshalb den aktuellen Betriebszustand; er ist kein eigener Wiederholungstest mit dem früheren Fehlerdatum. Die fachliche Bestimmung eines Dokumentdatums bleibt unabhängig davon eine Aufgabe der Quellenprüfung.

Gezielter Wechsel statt pauschalem Stack-Neustart

Für die Hauptanwendung wurde das feste Image ghcr.io/paperless-ngx/paperless-ngx:3.3.1 geladen und ausschließlich der Webserver neu erstellt. Die laufende Version wurde anschließend am Containerimage und im Startprotokoll bestätigt.

SQLite-Datenhaltung, bestehendes Borg-Verfahren, Consumer-Einstellungen und die Abgrenzung zu MailStore wurden bei diesem Auftrag nicht geändert. Die Anwendungskonfiguration blieb bytegleich; KI und Barcode-Speicherung waren weiterhin deaktiviert. Die aktuelle fachliche Governance wurde vorab gelesen, aber nicht geändert.

Es waren keine Datenbankmigrationen auszuführen. Der Suchindex erkannte jedoch eine Schemaänderung und wurde beim Start neu aufgebaut. Während dieser Phase antwortete die Anwendung noch nicht vollständig; zeitweise meldete der Container auch unhealthy. Nach Abschluss des Starts erreichte er healthy, und die anschließenden Betriebsprüfungen waren erfolgreich. Der Zwischenstatus allein war hier kein Anlass für einen Rückweg.

Reprocessing mit vorhandener Versionshistorie

Nach dem Patchwechsel wurde ein vorhandenes Hauptdokument mit Versionshistorie über den authentifizierten Stapel-Endpunkt zum Reprocessing ausgewählt. Der tatsächlich eingereihte Auftrag verwies auf die neueste Dokumentversion. Die Hintergrundaufgabe endete erfolgreich.

Der Vergleich vor und nach diesem Test bestätigte unveränderte Originalbytes sowie die geprüften Titel-, Datums-, Zuordnungs-, Eigentümer- und benutzerdefinierten Metadaten. Reprocessing darf OCR-Inhalt, Vorschau und gegebenenfalls die abgeleitete Archivdatei neu erzeugen; diese Funktion ist daher gesondert vom unveränderten Prüfsummenbestand unmittelbar nach dem Patchwechsel zu betrachten. Für diesen Test wurden keine Importworkflows ausgeführt und keine externen OCR-Dienste angefordert.

Die Grenze des Nachweises: Der Vergleich über den gesamten Bestand bezog sich auf die gespeicherten Prüfsummenfelder. Die tatsächlichen Dateibytes wurden bei zwei Downloads kontrolliert. Das ist keine erneute vollständige Integritätsprüfung aller Originaldateien und kein Test jeder Berechtigungskombination.

Redis, Gotenberg und Tika getrennt entscheiden

Redis vermittelt Hintergrundaufträge zwischen Anwendung und Worker. Gotenberg erzeugt PDF-Ausgaben aus unterstützten Dokumenten. Tika extrahiert Text und Metadaten. Ihre Versionsnummern sind unabhängig voneinander; ihre Schnittstellen müssen zur eingesetzten Anwendung passen.

Warum bei Tika ein Major-Upgrade ausblieb

In der abgefragten offiziellen Docker-Tagliste gab es weiterhin kein Image der 3.3.2-Reihe. Die neueren stabilen Tags lagen in der 4er-Reihe; auch latest verwies inzwischen auf 4.1.0-1. Damit hätte ein pauschales Update auf latest einen Wechsel der Hauptversion ausgelöst.

Der separate Test verwendete eine künstliche ODT-Datei ohne Archivdaten und den tatsächlich in Paperless 3.3.1 installierten Tika-Client. Der produktive Tika-3-Dienst extrahierte den erwarteten Text. Beim getesteten Tika-4-Image scheiterte derselbe Clientaufruf am Endpunkt /tika/form/text mit HTTP 404. Daher blieb Tika 3.3.1.0 produktiv erhalten.

Dieser Befund gilt für die geprüfte Kombination. Er belegt keine pauschale Unvereinbarkeit aller Tika-4-Versionen mit jeder Paperless-Version. Eine zukünftige Umstellung braucht einen neuen Test der dann verfügbaren Images und Clients. Die synthetischen Konvertierungstests erzeugten keine neuen Dokumente im Archiv.

Fazit: Updates an der Nutzbarkeit messen

Der Wechsel auf Paperless-ngx 3.3.1 war erfolgreich. Für die Begleitdienste ergab die Prüfung keinen geeigneten zusätzlichen Versionswechsel: Redis und Gotenberg waren aktuell, während der getestete Tika-4-Endpunkt mit dem vorhandenen Client nicht funktionierte.

Langfristig zählen zugängliche Originale, verständliche Metadaten, funktionierende Recherche und ein konsistenter Rückweg. Die Programme helfen bei dieser Arbeit; sie ersetzen die Archivierungsstrategie nicht. Der allgemeine Praxisablauf für Paperless-Updates ordnet diese einzelnen Prüfungen in den laufenden Archivbetrieb ein.

Quellen und Prüfstand

Eigene Betriebs- und Funktionstests vom 13. Oktober 2026. Herstellerangaben und Image-Tags wurden am selben Tag geprüft:

• Paperless-ngx: Release 3.3.1
• Gotenberg: offizielle Releases
• Apache Tika: offizielle Docker-Tags
• Redis: offizielles Docker-Image