Beiträge

Paperless-ngx Docker Upgrade: von 2.20.15 auf 3.0.4

Paperless-ngx 3.0 bringt Breaking Changes. Diese Anleitung zeigt das Upgrade einer Docker-Installation, Schritt für Schritt.

Voraussetzung: Ausgangsversion muss 2.20.15 sein. Nur von dort aus ist der Sprung auf 3.0 offiziell unterstützt. Ältere Versionen zuerst auf 2.20.15 bringen.

Was sich in 3.0 ändert

  • Suchindex wechselt von Whoosh zu Tantivy (Rust). Volltextindex muss neu aufgebaut werden, passiert im Docker-Image automatisch beim Start.
  • PAPERLESS_SECRET_KEY ist jetzt Pflicht.
  • PAPERLESS_DBENGINE ist bei PostgreSQL/MariaDB jetzt Pflicht (vorher aus PAPERLESS_DBHOST abgeleitet).
  • Diverse SSL-/Timeout-/Pooling-Variablen der DB entfallen zugunsten von PAPERLESS_DB_OPTIONS.
  • API-Version 1 fällt weg.
  • Dokument-Prüfsummen wechseln auf SHA-256.
  • Datenbankmigrationen sind nicht rückwärtskompatibel. Ohne Backup kein Rollback.

Vollständige Liste: github.com/paperless-ngx/paperless-ngx/releases

Schritt 1: Backup

cd /opt/paperless

docker compose stop

# Datenbank (Beispiel PostgreSQL)
docker compose exec -T db pg_dump -U paperless paperless > /opt/backup/paperless-db-$(date +%F).sql

# Volumes sichern
sudo tar -czf /opt/backup/paperless-data-$(date +%F).tar.gz ./data
sudo tar -czf /opt/backup/paperless-media-$(date +%F).tar.gz ./media

# Compose-Files sichern
cp docker-compose.yml /opt/backup/docker-compose.yml.bak
cp docker-compose.env /opt/backup/docker-compose.env.bak

Alternativ den eingebauten Paperless-Exporter nutzen:

docker compose run --rm webserver document_exporter ../export

Schritt 2: Secret Key setzen

Falls bisher kein PAPERLESS_SECRET_KEY gesetzt war, lief 2.x mit einem eingebauten Default-Key. Für 3.0 wird ein expliziter Key Pflicht.

openssl rand -base64 64

In docker-compose.env oder direkt in docker-compose.yml unter environment eintragen:

YAML Datei
PAPERLESS_SECRET_KEY: "<generierter-wert>"

Wichtig: Wird ein neuer, zufälliger Key gesetzt statt des alten Default-Keys, werden bestehende Sessions und API-Tokens ungültig. Nutzer müssen sich neu anmelden.

Schritt 3: Datenbank-Engine explizit setzen

Nur bei PostgreSQL oder MariaDB nötig, nicht bei SQLite.

YAML Datei

# v2 (PostgreSQL wurde aus PAPERLESS_DBHOST abgeleitet)
PAPERLESS_DBHOST: postgres

# v3 (Engine muss explizit gesetzt sein)
PAPERLESS_DBENGINE: postgresql
PAPERLESS_DBHOST: postgres

Zulässige Werte: postgresql oder mariadb. Bisherige einzelne SSL-/Timeout-/Pooling-Variablen durch PAPERLESS_DB_OPTIONS ersetzen, falls verwendet:

YAML Datei
PAPERLESS_DB_OPTIONS: "sslmode=require,pool.max_size=20"

Alte Variablen funktionieren übergangsweise weiter, loggen aber eine Deprecation-Warnung beim Start.

Schritt 4: Image-Tag auf 3.0.4 setzen

In docker-compose.yml:

YAML Datei
services:
  webserver:
    image: ghcr.io/paperless-ngx/paperless-ngx:2.20.15

ändern zu:

YAML Datei

services:
  webserver:
    image: ghcr.io/paperless-ngx/paperless-ngx:3.0.4

Wer bisher :latest nutzt: :latest zeigt seit Juli 2026 bereits auf 3.x. Für kontrollierte Major-Upgrades empfiehlt sich grundsätzlich ein fester Versions-Tag statt :latest.

Schritt 5: Neues Image ziehen und Container neu erstellen

docker compose pull
docker compose up -d

Der Suchindex-Rebuild (Whoosh → Tantivy) läuft beim ersten Start automatisch im Container. Bei größeren Archiven dauert das spürbar.

Schritt 6: Logs beobachten

docker compose logs -f webserver

Auf Migrationsfehler, fehlende Env-Variablen oder Reindex-Fortschritt achten.

Schritt 7: Verifikation

  • Version in der Weboberfläche prüfen (Systemstatus zeigt 3.0.4).
  • Volltextsuche testen, auch nach Umlauten und mehreren Suchbegriffen (Tantivy verknüpft Begriffe standardmäßig mit OR statt AND wie zuvor Whoosh).
  • Ein Testdokument einscannen/konsumieren lassen, OCR-Ergebnis prüfen.
  • Download und Vorschau eines bestehenden Dokuments prüfen.
  • Login/API-Token testen, falls der Secret Key neu gesetzt wurde.
  • Containerstatus prüfen: docker compose ps.

Rollback

Bei Problemen:

docker compose down

Alten Image-Tag (2.20.15) in docker-compose.yml zurücksetzen, DB-Dump aus Schritt 1 einspielen, data/ und media/ aus dem Backup zurückkopieren, dann:

docker compose up -d

Bekannte Stolperfallen

  • Fehlender PAPERLESS_SECRET_KEY bricht den Start ab.
  • PAPERLESS_DBENGINE vergessen bei PostgreSQL/MariaDB führt zu Verbindungsfehlern.
  • Zusätzliche, verwaiste Container aus älteren Compose-Setups können mit dem neuen Consumer kollidieren.
  • Veraltete Syntax in globalen Dateinamensvorlagen kann nach dem Upgrade Fehler werfen.

Quelle: github.com/paperless-ngx/paperless-ngx/releases

Debian 12 auf 13 Upgrade im Proxmox LXC Container (Copy & Paste)

Debian 12 Bookworm auf 13 Trixie upgraden, direkt im LXC Container auf Proxmox. Fertiges Script zum Copy & Paste, plus Backup und Verifikation.

Vorher: Snapshot

Vor jedem Major-Upgrade einen Snapshot des Containers erstellen. Einzige einfache Rückfallebene bei Problemen.

pct snapshot <CTID> pre-debian13-upgrade

Das Upgrade-Script

Im Container als root ausführen:

cat <<EOF >/etc/apt/sources.list
deb http://ftp.debian.org/debian trixie main contrib non-free non-free-firmware
deb http://ftp.debian.org/debian trixie-updates main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security trixie-security main contrib non-free non-free-firmware
deb http://ftp.debian.org/debian trixie-backports main contrib non-free non-free-firmware
EOF

apt-get update
DEBIAN_FRONTEND=noninteractive apt-get -o Dpkg::Options::="--force-confold" dist-upgrade -y

# Disable services that break in LXC / containers (harmless if not present)
systemctl disable --now systemd-networkd-wait-online.service || true
systemctl disable --now systemd-networkd.service || true
systemctl disable --now ifupdown-wait-online || true

# Install ifupdown2 (better networking stack for LXC/VMs)
apt-get install -y ifupdown2

# Cleanup
apt-get autoremove --purge -y
apt-get clean

reboot

Was das Script macht

  • Sources.list: ersetzt Bookworm-Quellen durch Trixie-Quellen, inklusive Security und Backports.
  • dist-upgrade: zieht alle Pakete auf Trixie, –force-confold behält bestehende Config-Dateien bei Konflikten.
  • Service-Disables: systemd-networkd-wait-online, systemd-networkd und ifupdown-wait-online können im LXC-Kontext beim Boot hängen bleiben, da sie auf Netzwerk-Hardware warten, die im Container nicht existiert. Deaktivieren verhindert das. || true sorgt dafür, dass das Script nicht abbricht, falls ein Dienst gar nicht installiert ist.
  • ifupdown2: modernerer Networking-Stack, funktioniert zuverlässiger in LXC/VM-Umgebungen als das klassische ifupdown.
  • Cleanup: entfernt nicht mehr benötigte Pakete und den apt-Cache.
  • Reboot: notwendig, damit Kernel-Userspace-Tools, systemd und Netzwerkstack sauber auf Trixie laufen.

Danach: Verifikation

cat /etc/debian_version
lsb_release -a
apt list --upgradable
ip a
systemctl --failed
  • debian_version sollte 13.x zeigen.
  • apt list –upgradable sollte leer sein.
  • ip a prüft, ob die Netzwerkschnittstelle nach dem Reboot korrekt hochgekommen ist.
  • systemctl –failed zeigt fehlgeschlagene Dienste nach dem Upgrade.

Bekannte Stolperfallen

  • Container-Config auf Proxmox-Host prüfen: sehr alte LXC-Templates können mit Trixie inkompatible Cgroup- oder AppArmor-Profile mitbringen.
  • Bei gepinnten Paket-Repos (Docker, PostgreSQL, etc.) müssen deren eigene sources.list-Einträge separat auf trixie umgestellt werden, das Script deckt nur die Debian-Basisquellen ab.
  • Nach dem Upgrade Dienste einzeln prüfen, die auf spezifische Paketversionen angewiesen sind (z. B. PHP, Python, Datenbanken).

Rollback

Bei Problemen: Container stoppen, Snapshot aus dem ersten Schritt zurückspielen.

pct rollback <CTID> pre-debian13-upgrade

Paperless-ngx Upgrade: von 2.20.15 auf 3.0.4 (Debian-VM auf Proxmox)

Paperless-ngx 3.0 bringt Breaking Changes. Diese Anleitung zeigt das Bare-Metal-Upgrade auf einer Debian-VM unter Proxmox, Schritt für Schritt.

Voraussetzung: Ausgangsversion muss 2.20.15 sein. Nur von dort aus ist der Sprung auf 3.0 offiziell unterstützt. Ältere Versionen zuerst auf 2.20.15 bringen.

Was sich in 3.0 ändert

  • Suchindex wechselt von Whoosh zu Tantivy (Rust). Volltextindex muss neu aufgebaut werden.
  • PAPERLESS_SECRET_KEY ist jetzt Pflicht.
  • PAPERLESS_DBENGINE ist bei PostgreSQL/MariaDB jetzt Pflicht (vorher aus PAPERLESS_DBHOST abgeleitet).
  • Diverse SSL-/Timeout-/Pooling-Variablen der DB entfallen zugunsten von PAPERLESS_DB_OPTIONS.
  • API-Version 1 fällt weg.
  • Dokument-Prüfsummen wechseln auf SHA-256.
  • Consumer-/OCR-Variablen teils umbenannt, OCR_MODE=skip-Verhalten ändert sich.
  • Datenbankmigrationen sind nicht rückwärtskompatibel. Ohne Backup kein Rollback.

Schritt 1: Snapshot der Proxmox-VM

Vor allem anderen: VM-Snapshot in Proxmox erstellen. Das ist der schnellste Rollback-Weg, unabhängig vom Applikations-Backup. Backup wichtig! Es kann immer was schief laufen!

qm snapshot <VMID> pre-paperless-3-0-4

Schritt 2: Anwendungs-Backup

Zusätzlich zum Snapshot ein Paperless-eigenes Backup, da die DB-Migration nicht reversibel ist.

sudo systemctl stop paperless-webserver paperless-consumer paperless-scheduler paperless-task-queue

# Datenbank (Beispiel PostgreSQL)
sudo -u postgres pg_dump paperless > /opt/backup/paperless-db-$(date +%F).sql

# Daten- und Medienverzeichnisse
sudo tar -czf /opt/backup/paperless-media-$(date +%F).tar.gz /opt/paperless/media
sudo tar -czf /opt/backup/paperless-data-$(date +%F).tar.gz /opt/paperless/data

# Konfiguration
sudo cp /opt/paperless/paperless.conf /opt/backup/paperless.conf.bak

Bei SQLite genügt eine Kopie der .sqlite3-Datei aus dem Datenverzeichnis.

Schritt 3: Version prüfen

cd /opt/paperless
sudo -Hu paperless git describe --tags

Muss v2.20.15 zeigen. Falls nicht: erst dorthin updaten, dann weiter.

Schritt 4: Secret Key sichern/setzen

Falls bisher kein PAPERLESS_SECRET_KEY gesetzt war, lief 2.x mit einem eingebauten Default-Key. Für 3.0 wird ein expliziter Key Pflicht.

python3 -c "import secrets; print(secrets.token_urlsafe(64))"

Wert in paperless.conf eintragen:

ini
PAPERLESS_SECRET_KEY=<generierter-wert>

Wichtig: Wird ein neuer, zufälliger Key gesetzt statt des alten Default-Keys, werden bestehende Sessions und API-Tokens ungültig. Nutzer müssen sich neu anmelden.

Schritt 5: Datenbank-Engine explizit setzen

Nur bei PostgreSQL oder MariaDB nötig, nicht bei SQLite.

ini
PAPERLESS_DBENGINE=postgresql
PAPERLESS_DBHOST=postgres

Zulässige Werte: postgresql oder mariadb. Bisherige einzelne SSL-/Timeout-/Pooling-Variablen durch PAPERLESS_DB_OPTIONS ersetzen, falls verwendet, z. B.:

ini
PAPERLESS_DB_OPTIONS=sslmode=require,pool.max_size=20

Alte Variablen funktionieren übergangsweise weiter, loggen aber eine Deprecation-Warnung beim Start.

Schritt 6: Systemabhängigkeiten aktualisieren

bash
sudo apt update
sudo apt install --only-upgrade python3 python3-pip python3-dev imagemagick fonts-liberation \
  gnupg libpq-dev default-libmysqlclient-dev pkg-config libmagic-dev mime-support \
  libzbar0 poppler-utils unpaper ghostscript icc-profiles-free qpdf liblept5 \
  libxml2 pngquant zlib1g tesseract-ocr

Ergänzend benötigte OCR-Sprachpakete (tesseract-ocr-deu etc.) prüfen, falls sich Sprachvorgaben geändert haben.

Schritt 7: Dienste stoppen

Falls Schritt 2 nicht schon erledigt:

sudo systemctl stop paperless-webserver paperless-consumer paperless-scheduler paperless-task-queue

Schritt 8: Quellcode auf 3.0.4 bringen

cd /opt/paperless
sudo -Hu paperless git fetch --all --tags
sudo -Hu paperless git checkout tags/v3.0.4

Schritt 9: Python-Abhängigkeiten aktualisieren

Venv aktivieren und Requirements neu installieren:

sudo -Hu paperless bash -c '
  source /opt/paperless/venv/bin/activate
  pip install --upgrade pip
  pip install -r requirements.txt
'

Danach die installierten Pakete gegen die neue requirements.txt abgleichen und nicht mehr benötigte Pakete entfernen, um Konflikte zu vermeiden.

Schritt 10: Datenbankmigration

cd /opt/paperless/src
sudo -Hu paperless ../venv/bin/python3 manage.py migrate

Schritt 11: Statische Dateien und Suchindex

sudo -Hu paperless ../venv/bin/python3 manage.py collectstatic --clear --no-input
sudo -Hu paperless ../venv/bin/python3 manage.py document_index reindex --if-needed

Der --if-needed-Flag prüft Schema-Version und Sprach-Sentinels und baut den Tantivy-Index nur neu, wenn nötig. Bei größeren Archiven (mehrere zehntausend Dokumente) dauert das spürbar; Fortschritt im Log beobachten.

Schritt 12: Dienste starten

sudo systemctl start paperless-webserver paperless-consumer paperless-scheduler paperless-task-queue
sudo systemctl status paperless-webserver

Schritt 13: Verifikation

  • Version in der Weboberfläche prüfen (Systemstatus zeigt 3.0.4).
  • Volltextsuche testen, auch nach Umlauten und mehreren Suchbegriffen (Tantivy verknüpft Begriffe standardmäßig mit OR statt AND wie zuvor Whoosh).
  • Ein Testdokument einscannen/konsumieren lassen, OCR-Ergebnis prüfen.
  • Download und Vorschau eines bestehenden Dokuments prüfen.
  • Login/API-Token testen, falls der Secret Key neu gesetzt wurde.
  • Log auf Fehler prüfen: journalctl -u paperless-webserver -n 200.

Rollback

Bei Problemen: Dienste stoppen, VM-Snapshot aus Schritt 1 zurückspielen. Alternativ Git-Checkout auf v2.20.15, DB-Dump aus Schritt 2 einspielen, altes paperless.conf zurückkopieren, Venv-Requirements der 2.20.15 neu installieren.

Bekannte Stolperfallen

  • Fehlender PAPERLESS_SECRET_KEY bricht den Start ab.
  • PAPERLESS_DBENGINE vergessen bei PostgreSQL/MariaDB führt zu Verbindungsfehlern.
  • Veraltete Syntax in globalen Dateinamensvorlagen kann nach dem Upgrade Fehler werfen.
  • Zusätzliche, nicht mehr benötigte Container/Prozesse aus älteren Setups können mit dem neuen Consumer kollidieren.
proxmox ve 9.1

Für Unternehmen, Agenturen und IT-Dienstleister im deutschsprachigen Raum ist eine zuverlässige, performante und flexible Virtualisierungslösung unverzichtbar. Mit dem Release von Proxmox Virtual Environment 9.1 liefert der österreichische Hersteller Proxmox Server Solutions ein umfassendes Update, das besonders in produktiven Umgebungen wie Rechenzentren, KMU-Netzwerken und Hosting-Infrastrukturen überzeugt.

Das Update bringt signifikante Verbesserungen im Bereich Container-Technologien, Sicherheit, Netzwerk-Management und Virtualisierungs-Performance – ideal für Administratoren in Deutschland, Österreich und der Schweiz, die ihre Infrastruktur modern halten wollen.


Was ist neu in Proxmox VE 9.1?

Die Version 9.1 baut auf der stabilen Debian-Basis (Bookworm) auf und integriert zahlreiche Detailverbesserungen, die den täglichen Betrieb vereinfachen.

1. LXC-Container jetzt mit voller OCI-Image-Unterstützung

Proxmox unterstützt ab sofort OCI-Images (z. B. von Docker Hub).
Das ermöglicht:

  • schnellere Container-Deployments

  • flexible Workload-Migrationen

  • einheitliche Container-Standards für DevOps-Teams

2. vTPM-Support jetzt im qcow2-Format

Virtual Trusted Platform Modules unterstützen nun:

  • Snapshots über verschiedene Storage-Backends hinweg

  • mehr Flexibilität für Windows-VMs

  • Einsatz von Virtualization-based Security (VBS)

Wichtig für Windows-Infrastrukturen in Firmen & Behörden im DACH-Raum.

3. Verbesserte Kontrolle für Nested Virtualization

Ideal für:

  • Lab-Umgebungen

  • Hypervisor-Tests

  • komplexe Entwicklungs-Workflows

Admins können geschachtelte Virtualisierung granular steuern.

4. SDN-Stack erweitert – besseres Monitoring

In großen Proxmox-Clustern (z. B. Unternehmens- oder Hosting-Umgebungen) profitieren Nutzer von:

  • klareren Netzwerkübersichten

  • detaillierten Statusinformationen

  • verständlicher Fabric- und VNet-Visualisierung

Perfekt für IT-Teams in Rechenzentren oder anspruchsvollen KMU-Netzen.


Warum das Update wichtig ist – besonders für DACH-Unternehmen

✔ Höhere Sicherheit durch moderne Standards

Mit vTPM-Support & optimiertem Virtualisierungs-Handling erfüllt Proxmox VE 9.1 wichtige Anforderungen für DSGVO-konforme IT-Umgebungen.

✔ Zukunftsfähige Container-Infrastruktur

OCI-Support bringt Proxmox funktional auf Augenhöhe mit Kubernetes-Ökosystemen – entscheidend für Digitalagenturen, Hosting-Provider und DevOps-Teams.

✔ Vereinfachtes Netzwerk-Management

Gerade in deutschen Rechenzentren mit Multi-Node-Clustern sorgen die SDN-Verbesserungen für weniger Ausfälle und schnellere Fehlerdiagnose.


Download & Changelogs

Hier findest du die wichtigsten Links für Installation und Update:

Download Proxmox VE 9.1 ISO
https://www.proxmox.com/de/downloads

Changelog & technische Dokumentation
https://pve.proxmox.com/wiki/Roadmap
https://pve.proxmox.com/pve-docs/

Upgrade-Anleitung von älteren Versionen
https://pve.proxmox.com/wiki/Upgrade_from_8_to_9


Fazit: Ein starkes Update für moderne Virtualisierungsumgebungen

Proxmox VE 9.1 liefert genau die Features, die Administratoren im deutschsprachigen Raum benötigen: mehr Sicherheit, flexiblere Container-Workflows und ein klar verbessertes Netzwerk-Management.
Wer Proxmox produktiv einsetzt – egal ob im Unternehmen, im Hosting-Bereich oder in der eigenen Homelab-Umgebung – sollte das Update zeitnah einplanen.


Jetzt aktiv werden

Upgrade planen — erst Testumgebung, dann Rollout
⬇️ ISO herunterladen
Neue Sicherheitsfeatures nutzen

Proxmox VE 9.1 bringt deine Infrastruktur auf ein modernes, stabiles und leistungsstarkes Level.

 

 

 

Proxmox Backup Server in Proxmox installieren und einrichten – mit Screenshots

Mit Proxmox Backup Server (PBS) sicherst du deine virtuellen Maschinen (VMs) und Container effizient und dedupliziert. Die Integration in Proxmox VE ist nahtlos – ideal für Homelab und professionelle Setups.

In diesem Beitrag zeige ich dir Schritt für Schritt, wie du PBS in einer VM installierst und mit deinem Proxmox-Cluster verbindest. Screenshots helfen dir dabei, keinen Schritt zu übersehen.


Voraussetzungen

  • Proxmox VE installiert

  • ISO-Image von Proxmox Backup Server

  • Mindestens 2 vCPUs, 2–4 GB RAM, 32 GB HDD für PBS

  • Separate Festplatte/Datenspeicher für Backups empfohlen


Schritt 1: PBS ISO herunterladen und VM vorbereiten

  1. Lade das ISO-Image von https://www.proxmox.com/en/downloads.

  2. Lade es in deine Proxmox VE-Maschine hoch (z. B. unter „local (storage)“ > ISO Images > Upload).

Screenshot-Tipp: ISO-Upload-Dialog in Proxmox zeigen.

  1. Erstelle eine neue VM in Proxmox:

    • Name: pbs

    • OS: „Do not use any media“ → dann ISO manuell auswählen

    • CPU: 2 Cores

    • RAM: 2048–4096 MB

    • Disk 1: 32 GB (System)

    • Disk 2: optional (z. B. 500 GB, für Backups)

    • Netzwerk: Bridge auf dein internes Netz

Screenshot-Tipp: Zusammenfassung der VM-Konfiguration vor dem Erstellen.


Schritt 2: Proxmox Backup Server installieren

  1. Starte die VM mit dem ISO.

  2. Wähle „Install Proxmox Backup Server“ im Bootmenü.

  3. Folge dem Installationsassistenten:

    • Sprache, Tastaturlayout, Zeitzone

    • Festplatte auswählen (Systemdisk)

    • Passwort und Email für Root-Benutzer

    • Netzwerk konfigurieren (DHCP oder statisch)

Nach Abschluss: Neustarten und Webinterface aufrufen:

https://<PBS-IP>:8007


Schritt 3: Webinterface & Storage einrichten

Melde dich mit dem Root-Zugang an.

  1. Gehe zu Datastore > Add

    • Name: backup01

    • Directory: z. B. /mnt/data

Optional: Füge eine zusätzliche Festplatte über Proxmox hinzu und mounte sie z. B. als /mnt/data.

Schritt 4: PBS mit Proxmox VE verbinden

  1. Öffne dein Proxmox VE Interface.

  2. Gehe zu Datacenter > Storage > Add > Proxmox Backup Server.

  3. Trage folgendes ein:

    • ID: pbs-backup

    • Server: IP oder DNS von PBS

    • Datastore: backup01

    • Username: root@pam

    • Password oder API Token (optional)

  1. Backup-Modus auf „stop“ , hiermit erzielt man eher ein sicheres Backup, Modus snapshot ist sonst hier (standard).

  2. Speichern – Verbindung sollte sofort aktiv sein.


Schritt 5: Backup-Job erstellen

  1. In Proxmox VE:

    Datacenter > Backup > Add

  2. Wähle:

    • Storage: pbs-backup

    • Auswahl: Container/VMs oder ganze Gruppen

    • Schedule: z. B. täglich 03:00

    • Mode: snapshot / stop / suspend

    • Compression: zstd

    • Encryption Key: optional


Schritt 6: Restore testen

  1. Gehe zu Storage > pbs-backup > Content

  2. Klicke auf ein Backup und wähle „Restore“

    • Direkt wiederherstellen oder in neue VM-ID


Fazit

Mit Proxmox Backup Server bekommst du ein leistungsstarkes, sicheres und extrem effizientes Backup-System – perfekt für VMs, Container und sogar Dateien. Die Kombination aus Deduplizierung, Verschlüsselung und einfacher Integration macht PBS zu einem Muss für jedes Proxmox-Setup.


Paperless-AI ist ein Dokumentenmanagementsystem mit integrierter KI – ideal für alle, die Dokumente nicht nur digitalisieren, sondern auch intelligent auswerten lassen wollen. In dieser Anleitung zeige ich dir, wie du Paperless-AI sauber und einfach in einem Proxmox LXC-Container installierst.


Voraussetzungen

  • Proxmox VE 7 oder 8

  • Ubuntu 22.04 LXC-Container

  • Mind. 2–4 GB RAM

  • 1–2 CPU-Kerne

  • Docker & Docker Compose

  • OpenAI API Key (optional, für KI-Funktionen)


Schritt 1: LXC-Container anlegen

Erstelle im Proxmox Webinterface einen neuen Container:

  • Template: ubuntu-22.04-standard

  • Hostname: paperlessai

  • RAM: mind. 2–4 GB

  • CPU: 1–2 Kerne

  • Festplatte: 10–20 GB (je nach Dokumentenmenge)

  • Netzwerk: statische IP oder DHCP

Wichtig:

Aktiviere unter “Options” die Features nesting und fuse.

Schritt 2: Container vorbereiten

Per Shell oder SSH:

apt update && apt upgrade -y
apt install -y curl wget git docker.io docker-compose
systemctl enable docker
systemctl start docker

Schritt 3: Paperless-AI klonen & konfigurieren

git clone https://github.com/paperless-ai/paperless-ai.git /opt/paperless-ai
cd /opt/paperless-ai

Kopiere die Beispiel-Konfiguration:

cp .env.template .env

Bearbeite .env und trage z. B. deinen OpenAI API-Key ein:

OPENAI_API_KEY=sk-...
PAPERLESS_TIME_ZONE=Europe/Berlin

Optional kannst du auch HuggingFace oder andere Modelle einbinden.


Schritt 4: Container starten

docker compose up -d

Der Start dauert beim ersten Mal ein paar Minuten.

Danach erreichst du Paperless-AI über:

http://<IP_DES_CONTAINERS>:8000

Erstkonfiguration

Erster Benutzer:

docker compose exec web python3 manage.py createsuperuser

Dann einloggen und das Dashboard erkunden.


Dokumente hochladen

Dokumente kannst du via Web-UI oder in den Ordner /opt/paperless-ai/data/consume/ hochladen:

scp rechnung.pdf root@<IP>:/opt/paperless-ai/data/consume/

Die Dokumente werden automatisch verarbeitet und mit Hilfe der KI ausgewertet (z. B. Felder wie Rechnungsnummer, Absender, Betrag usw.).

Updates & Wartung

Update auf neueste Version:

cd /opt/paperless-ai
git pull
docker compose pull
docker compose up -d

Logs ansehen:

docker compose logs -f

Fazit

Mit Paperless-AI kombinierst du OCR und KI-basierte Analyse in einem System – ideal für Selbstständige, IT-affine Nutzer oder kleine Büros. In Proxmox als LXC läuft es besonders ressourcenschonend und stabil. Damit erweitert man den Paperless-NGX um AI Funktionen mit OpenAI oder Local mit Ollama einfach nutzen.

Homepage / Download Entwickler: https://github.com/clusterzx/paperless-ai

 

Du möchtest dein Dokumentenmanagement mit Paperless-ngx selbst hosten? In diesem Tutorial zeige ich dir, wie du Paperless-ngx in einem LXC-Container auf Proxmox VE installierst – schlank, performant und vollständig unter deiner Kontrolle.


Voraussetzungen

  • Proxmox VE (7.x oder 8.x)

  • Root-Zugriff auf den Server

  • Container-Template: Ubuntu 22.04 empfohlen

  • mind. 2 GB RAM & 1 CPU-Kern

  • Optional: externes NAS oder Verzeichnis für Dokumente


Schritt 1: LXC-Container erstellen

Im Proxmox Webinterface:

  1. Neuen CT anlegen

  2. Template: ubuntu-22.04-standard_*.tar.zst

  3. Hostname: paperless

  4. CPU: mind. 1 Core

  5. RAM: mind. 2048 MB (mehr bei vielen Dokumenten)

  6. Netzwerk: statische IP oder DHCP

  7. Festplatte: 10–20 GB (je nach Nutzung)

⚠️ Aktiviere unter “Options” → “Features”:

  • Nesting

  • Fuse


Schritt 2: Container starten & vorbereiten

Per Konsole oder SSH verbinden:

apt update && apt upgrade -y
apt install -y curl wget git docker.io docker-compose

Docker aktivieren:

systemctl enable docker
systemctl start docker

Optional neuen User anlegen:

adduser paperless
usermod -aG docker paperless

Schritt 3: Paperless-ngx via Docker Compose installieren

Wechsle in ein passendes Verzeichnis:

mkdir -p /opt/paperless
cd /opt/paperless

Beispiel docker-compose.yml:

version: "3.4"

services:
  broker:
    image: redis:7
    restart: always

  db:
    image: postgres:15
    environment:
      POSTGRES_DB: paperless
      POSTGRES_USER: paperless
      POSTGRES_PASSWORD: paperless
    volumes:
      - db_data:/var/lib/postgresql/data
    restart: always

  paperless:
    image: ghcr.io/paperless-ngx/paperless-ngx:latest
    restart: always
    ports:
      - 8000:8000
    environment:
      PAPERLESS_REDIS: redis://broker:6379
      PAPERLESS_DBHOST: db
      PAPERLESS_DBNAME: paperless
      PAPERLESS_DBUSER: paperless
      PAPERLESS_DBPASS: paperless
    volumes:
      - data:/usr/src/paperless/data
      - media:/usr/src/paperless/media
      - export:/usr/src/paperless/export
      - consume:/usr/src/paperless/consume
    depends_on:
      - db
      - broker

volumes:
  data:
  media:
  export:
  consume:
  db_data:

Dann starten:

docker compose up -d

Schritt 4: Paperless-ngx aufrufen & einrichten

Nach ein paar Sekunden erreichst du Paperless im Browser:

http://<IP_DES_CONTAINERS>:8000

Erster Login:

Benutzername: admin

Passwort: admin (wird beim ersten Start generiert, ggf. selbst setzen!)

Du kannst auch via ENV-Variablen eigene Benutzer beim ersten Start anlegen – siehe die Paperless-ngx Dokumentation.


Schritt 5: Dokumente ablegen und verarbeiten

Lade PDFs in das Verzeichnis consume/, z. B.:

scp dokument.pdf root@<IP>:/opt/paperless/consume/

Paperless importiert sie automatisch und erstellt OCR-Texte.

 


Dokumententypen

 


Updates & Neustart

Zum Aktualisieren:

cd /opt/paperless
docker compose pull
docker compose up -d

Logs prüfen:

docker compose logs -f

Fazit

Mit dieser Anleitung hast du in wenigen Minuten ein leistungsfähiges, selbst gehostetes DMS am Start – ganz ohne schwerfällige Server oder VMs. Paperless-ngx ist leichtgewichtig, OCR-fähig und perfekt für Homelab oder kleine Unternehmen.

 

Wenn du einen Node aus einem Proxmox VE Cluster entfernen möchtest – sei es wegen Hardwaretausch, Migration oder weil der Node defekt ist – solltest du einige Dinge beachten, um den Cluster stabil und fehlerfrei zu halten.

In diesem Tutorial zeige ich dir Schritt für Schritt, wie du einen Node sicher aus einem Proxmox-Cluster entfernst.


⚠️ Voraussetzungen & Warnung

⚠️ Achtung: Diese Anleitung gilt nur, wenn du den Node dauerhaft und vollständig entfernen willst. Die Schritte sind nicht rückgängig zu machen!

Was du brauchst:

  • Root-Zugriff auf alle Proxmox-Nodes

  • SSH-Zugang zum Cluster

  • Backup deiner VMs/CTs (zur Sicherheit!)

  • Der Node sollte keine laufenden VMs oder Container mehr enthalten


Schritt 1: Prüfen, ob der Node leer ist

Stelle sicher, dass der Node keine wichtigen Ressourcen mehr hält.

# Auf dem zu entfernenden Node
pct list
qm list

Wenn dort noch Container oder VMs sind: migrieren oder löschen!


Schritt 2: Node im Webinterface in den Wartungsmodus setzen (optional)

Gehe im Proxmox Web-GUI zu:

Datacenter → Node auswählen → More → Maintenance Mode aktivieren

Damit werden keine neuen Tasks mehr dorthin verteilt.


Schritt 3: Node aus dem Cluster entfernen

Variante A: Der Node ist noch erreichbar

Gehe auf einen anderen Node im Cluster (nicht den, der entfernt wird) und führe Folgendes aus:

pvecm delnode <NODE-NAME>

Beispiel:

pvecm delnode pve3

Der Node wird nun aus dem Cluster entfernt. Das Webinterface zeigt ihn nach einem Refresh nicht mehr an.


Variante B: Der Node ist

nicht mehr erreichbar

(z. B. defekt)

In diesem Fall kannst du den Node trotzdem aus dem Cluster entfernen. Gehe dazu ebenfalls auf einen erreichbaren Node:

pvecm delnode <NODE-NAME>

Zusätzlich solltest du danach auf allen verbleibenden Nodes prüfen, ob der entfernte Node noch in irgendwelchen Konfigurationen oder der /etc/hosts Datei auftaucht, und diese ggf. bereinigen.


Schritt 4: Aufräumen

Auf allen Nodes:

  • Lösche Einträge in /etc/pve/ (z. B. Storage- oder Netzwerkconfigs, falls vorhanden)

  • Passe /etc/hosts und evtl. DNS-Einträge an

  • Entferne SSH-Keys, falls du sie manuell eingerichtet hast


Bonus: Node neu in einen anderen Cluster integrieren?

Wenn du denselben Server später in einen neuen Cluster aufnehmen willst, solltest du das System neu installieren oder pvecm expected 1 + pvecm create nutzen.

Alternativ:

rm -r /etc/pve/corosync.conf
rm -r /etc/corosync/*

Und dann den Node ganz normal zu einem neuen Cluster hinzufügen.


✅ Fazit

Das Entfernen eines Nodes aus einem Proxmox Cluster ist relativ einfach – wenn man es strukturiert und mit Vorsicht angeht. Denk immer an Backups und überprüfe, ob der Node wirklich keine Ressourcen mehr verwaltet.

 

Weitere Doku gibt es auch bei Proxmox oder Thomas Krenn –

Ziel:

  • Erstellen von Netzwerkbrücken für VMs/Container
  • VLANs für segmentiertes Netzwerk

Schritt 1: Bridge konfigurieren

Bearbeite /etc/network/interfaces:

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10
    netmask 255.255.255.0
    gateway 192.168.1.1
    bridge_ports enp3s0
    bridge_stp off
    bridge_fd 0

Schritt 2: VLANs anlegen

Für VLAN 10 auf vmbr0:

auto vmbr0.10
iface vmbr0.10 inet static
    address 192.168.10.1
    netmask 255.255.255.0
    vlan-raw-device vmbr0

Tipps:

  • VLAN-Tagging funktioniert nur mit VLAN-fähigem Switch

Schritt 1: Template herunterladen

Unter „Storage“ > „CT Templates“ ein passendes Template herunterladen

Schritt 2: Container erstellen

  • „Create CT“ klicken
  • Hostname, Passwort und Template wählen
  • Ressourcen und Netzwerk konfigurieren

Schritt 3: Container starten

  • Container starten, Konsole öffnen, System konfigurieren

Tipps:

  • Container starten schneller, ideal für Webserver und kleine Dienste