Köra Paperless-ngx med lite lagringsutrymme: flytta dokument till en molntjänst

Paperless-ngx lagrar sina dokument i en lokal katalog, och den katalogen växer med varje inskanning. I vardagen behöver Paperless dock knappt filerna: sökningen körs mot databasen, listan visar förhandsvisningsbilder och själva filen läses först när den öppnas. Därför testade jag om lagringen kan flyttas till en molntjänst. Verktyget för detta är Rclone, som Plex-användare sedan åratal använder för att montera hela mediesamlingar från molnet.

Resultatet: Det fungerar åt båda hållen, och installationen har nu krympt till tre kommandon. Den här artikeln sammanfattar vad testet visade och hur du kan sätta upp lösningen själv. De tekniska detaljerna finns i separata artiklar som länkas i slutet: Docker-mount-propagation, AppArmor-särdrag, tvåfaktorsautentisering och testmetodik.

Principen: Hot Storage stannar lokalt, Cold Storage ligger i molnet

I Paperless är just katalognamnet missvisande: archive/ är inte Cold Storage, utan innehåller PDF/A-versionen som levereras vid varje visning. Trots namnet hör den till Hot Storage. Originalen under originals/ som sällan behövs är den egentliga Cold Storage. Om du vill spara maximalt kan du stänga av arkivkopian helt med PAPERLESS_ARCHIVE_FILE_GENERATION=never; fulltextsökningen påverkas inte, eftersom texten finns i databasen.

Paperless-ngx har för övrigt ingen egen molnanslutning, varken S3 eller django-storages. En filsystemsmount via Rclone är för närvarande den enda vägen, och den fungerar med var och en av de över 70 tjänster som Rclone stöder. Proton Drive var mitt testval på grund av end-to-end-krypteringen; S3-kompatibel lagring är det robustare alternativet.

Vad testet visade

Testat med en isolerad Paperless-instans, 40 genererade test-PDF:er (13.9 MB) och ett dedikerat Proton-konto:

Det lokala lagringsbehovet är därmed frikopplat från arkivets storlek: samlingen får växa, disken behöver inte göra det.

Så ställer du in det

Den kompletta konfigurationen finns som en mall på GitHub: pfstr/paperless-cloud-storage. På servern:

git clone https://github.com/pfstr/paperless-cloud-storage.git
cd paperless-cloud-storage
sudo ./setup.sh      # einmalig, bereitet den Host vor (einziger Root-Schritt)
./wizard.sh          # geführt: Anbieter wählen, Zugangsdaten, Rundlauf-Test

Guiden frågar efter molntjänsten (Proton, S3, Backblaze B2, WebDAV, SFTP eller ”Not in the list” för alla andra Rclone-tjänster), kontrollerar anslutningen med ett verkligt upp- och nedladdningstest och startar lagringscontainern. Därefter:

• Nyinstallation: docker compose -f paperless.yml up -d, klart.
• Befintlig Paperless-instans: Databas och inställningar förblir orörda; instruktionen RETROFIT.md beskriver uppladdningen av befintliga dokument och den nödvändiga ändringen i din Compose-fil.

Jag har medvetet avstått från ett webbgränssnitt. Rclones webb-GUI användes först, men SSH-tunnlar, CORS och tillfälliga mountar gjorde det sämre än kommandoraden som det skulle ersätta. Tre frågor i terminalen går snabbare.

Så förblir mounten stabil i vardagen

Mallen hanterar fyra punkter som du också måste beakta vid en egen uppsättning:

1. propagation: rslave på Paperless-containerns media-bind-mount, annars överlever containern inte en omstart av mounten. Detaljer och AppArmor-problemet bakom: Rclone-mount i Docker-containern.
2. Stoppa Paperless när mounten saknas. Annars skriver den dokument till en tom lokal katalog, och den återvändande mounten döljer dem osynligt. Ett watchdog-skript ingår i mallen.
3. Ett konto som kan logga in utan övervakning. För Proton innebär det att TOTP-nyckeln måste sparas i Rclone-konfigurationen. Varför det inte urholkar tvåfaktorsautentiseringen och hur läget för Proton under Linux ser ut i stort: Proton Drive under Linux.
4. Stäng av schemalagda uppgifter som läser hela innehållet (PAPERLESS_SANITY_TASK_CRON=disable), eftersom integritetskontrollen annars regelbundet läser hela beståndet från molnet.

Vad du bör överväga före användning

Ett nyinläst dokument finns bara i den lokala cachen under några sekunder tills uppladdningen är klar. Om maskinen fallerar just i det fönstret saknas filen. Cachegränsen är mjuk och kan tillfälligt överskridas betydligt vid åtkomsttoppar. Dessutom är Rclones Proton-backend officiellt i beta; vid snabba API-anrop visade den tecken på strypning. Eftersom långtidsdata från kontinuerlig drift ännu saknas är mallen märkt som experimentell.

Hur mätvärdena togs fram, vilka fel som simulerades och hur en sådan uppsättning över huvud taget kan testas seriöst beskrivs i metodartikeln: Testa molnmountar med genererade PDF:er.

Slutsats

Paperless-ngx på en liten disk med molnlagring är genomförbart och användbart i vardagen: knappt två sekunder vid första öppningen, därefter cachehastighet, sökning och gränssnitt förblir oberoende av molnet, och uppsättningen självläker efter avbrott. Om du på en normalt dimensionerad server bara vill spara några gigabyte bör du dock räkna efter: i mitt fall tog hela lagringen upp 71 MB, medan operativsystemet tog flera gigabyte. Vinsten ligger inte i det omedelbart sparade utrymmet, utan i att beståndet får växa utan att disken måste växa med det.