Tags
incus
file
peertube

Diese Dokumentation beschreibt das final empfohlene Setup für die PeerTube-Instanz auf at1 in Verbindung mit:

  • einem btrfs‑RAID1 unter /mnt/raid1,
  • klar getrennten btrfs‑Subvolumes,
  • einem Incus‑Container (peertube oder peertube4),
  • sauberem Host→Container‑Mounting via Incus‑Disk‑Device,
  • korrekt eingerichtetem User‑Namespace‑Mapping.

Das Ziel ist ein robustes, snapshot‑fähiges, sauber getrenntes System, das Migrationen und Backups extrem erleichtert.

Zielsetzung

Die PeerTube‑Instanz soll auf dem neuen Host exakt wie bisher funktionieren – inklusive:

  • identischem Medienpfad,
  • identischen Zugriffsrechten,
  • btrfs‑Subvolume‑Vorteilen (Snapshots, Send/Receive),
  • sauberem Incus‑Mapping,
  • vollständiger Separation von App‑Daten und Container‑Daten.

Struktur des Dateisystems (btrfs)

Das RAID1‑Volume unter /mnt/raid1 enthält folgende Subvolumes:

/mnt/raid1/                   # btrfs Mountpoint
├── @                         # Root‑Subvolume
├── .snapshots/               # Snapper‑Snapshots
├── incus/@incus/...          # Incus Container und Images
└── peertube-media            # Eigenes PeerTube‑Medien‑Subvolume

Das Subvolume peertube-media ist schreibbar, isoliert und ideal für Backups, Migrationen und Quotas.

Einrichtung der PeerTube‑Medien (Schritt für Schritt)

1) Subvolume erstellen

btrfs subvolume create /mnt/raid1/peertube-media

Falls dort bereits Daten existierten:

mv /mnt/raid1/peertube-media /mnt/raid1/peertube-media.old
btrfs subvolume create /mnt/raid1/peertube-media
rsync -aHAXv /mnt/raid1/peertube-media.old/ /mnt/raid1/peertube-media/
rm -rf /mnt/raid1/peertube-media.old

2) Mediendaten vom alten Server übertragen (empfohlen: rsync)

rsync -aHAXvP -e ssh root@OLD-SERVER:/var/www/peertube/storage/ \
  /mnt/raid1/peertube-media/

Bei Containern ggf. Quelle anpassen:

/var/lib/lxc/peertube4/rootfs/var/www/peertube/storage/
/var/lib/incus/containers/peertube4/rootfs/var/www/peertube/storage/

3) Mounting in den Incus‑Container

Das PeerTube‑Medienverzeichnis wird per Incus‑Device eingebunden:

incus config device add peertube media disk \
  source=/mnt/raid1/peertube-media \
  path=/var/www/peertube/storage

Alternative über ein Profil:

incus profile import peertube-profile.yaml
incus profile add peertube peertube-profile

Rechte und User‑Namespaces

Der PeerTube‑User im Container besitzt UID/GID 1000:1000.

Incus mappt Container‑UIDs über einen Host‑Offset:

Hostid = 1000000
Container UID 1000 → Host UID 1001000
Container GID 1000 → Host GID 1001000

Ownership im Container setzen (empfohlen)

incus exec peertube -- chown -R peertube:peertube /var/www/peertube/storage
incus exec peertube -- chmod -R 750 /var/www/peertube/storage

Ownership auf dem Host numerisch setzen (äquivalent)

chown -R 1001000:1001000 /mnt/raid1/peertube-media
find /mnt/raid1/peertube-media -type d -exec chmod 750 {} \;
find /mnt/raid1/peertube-media -type f -exec chmod 640 {} \;

Verifikation

Auf dem Host

ls -ln /mnt/raid1/peertube-media | head -n 10
btrfs subvolume list -p /mnt/raid1 | awk '{print $9}'

→ Erwartet: 1001000:1001000 für alle Dateien

Im Container

incus exec peertube -- ls -ld /var/www/peertube/storage
incus exec peertube -- df -hT /var/www/peertube/storage
incus exec peertube -- id peertube

→ Erwartet: Besitzer peertube:peertube, Filesystem btrfs

Snapshots & Backups

Snapshot erstellen

btrfs subvolume snapshot -r \
  /mnt/raid1/peertube-media \
  /mnt/raid1/.snapshots/$(date +%Y%m%d_%H%M)_peertube-media

Snapshot senden (Backup/Migration)

btrfs send /mnt/raid1/.snapshots/20251205_2000_peertube-media | \
  ssh root@backuphost "btrfs receive /backup/raid1/"

Häufige Probleme und Lösungen

Dateien gehören auf dem Host user 1000:1000

→ Ursache: Ownership nicht auf die gemappten UID/GIDs gesetzt
→ Lösung: chown -R 1001000:1001000 oder im Container chown ausführen

Container zeigt falsches Filesystem

→ Prüfen mit df -hT
→ Erwartet: btrfs

Alte Daten im Container „verschwinden“

→ Das Host‑Mount überdeckt den Container‑Pfad
→ Alte Rootfs‑Daten ggf. manuell löschen (Container vorher stoppen)

Kurz‑FAQ

1. Muss ich fstab ändern?

Nein. Incus mountet direkt. fstab wird nicht benötigt.

2. Sollte peertube-media ein eigenes Subvolume sein?

Ja. Bessere Trennung, schnellere Backups, saubere Migration.

3. Kann Snapper auch peertube-media snapshotten?

Ja. Üblich ist jedoch, gezielt App‑Subvolumes wie peertube-media einzubinden.

Befehlsübersicht (Copy‑Paste)

# Subvolume erstellen
btrfs subvolume create /mnt/raid1/peertube-media

# Medien kopieren
rsync -aHAXvP -e ssh root@OLD-SERVER:/var/www/peertube/storage/ \
  /mnt/raid1/peertube-media/

# Incus‑Device hinzufügen
incus config device add peertube media disk \
  source=/mnt/raid1/peertube-media \
  path=/var/www/peertube/storage

# Ownership (Host)
chown -R 1001000:1001000 /mnt/raid1/peertube-media
find /mnt/raid1/peertube-media -type d -exec chmod 750 {} \;
find /mnt/raid1/peertube-media -type f -exec chmod 640 {} \;

# Verify
incus exec peertube -- ls -ld /var/www/peertube/storage
ls -ln /mnt/raid1/peertube-media | head -n 10
btrfs subvolume list -p /mnt/raid1 | awk '{print $9}'

Best Practices

  • Für jede App ein eigenes Subvolume (z. B. PeerTube‑Media)
  • Incus‑Subvolumes von benutzerdefinierten Daten strikt trennen
  • UID‑Mapping berücksichtigen und möglichst im Container chownen
  • Snapshots automatisieren (systemd‑timer oder cron)
  • Für große Migrationen immer ein readonly Snapshot + btrfs send/receive verwenden

Ende der Dokumentation