NAS

Proxmox Backup Server im Homelab: Wie ich mein Proxmox-System endlich richtig abgesichert habe

von
Zeraphys, ein drachenartiger Avatar, steht zufrieden in einem Rechenzentrum und hält Festplatten als Symbol für den Proxmox Backup Server

Inhaltsverzeichnis

Warum ich mir überhaupt Gedanken über den Proxmox Backup Server gemacht habe

„RAID ist doch Backup, oder?“ – genau mit dieser falschen Beruhigung bin ich jahrelang durchs Homelab-Leben getapst. Zwei Platten gespiegelt, läuft schon. Dazu noch ein NAS irgendwo im Netzwerk, fertig.

Spoiler: Nein. Ist es nicht.

Erst als ich mich ernsthaft mit dem Proxmox Backup Server (PBS) beschäftigt habe, ist mir klar geworden, wie viele Lücken in so einem „funktioniert ja seit Jahren“-Setup stecken. Der Proxmox Backup Server ist dabei nicht einfach ein weiteres Tool, sondern ein komplett anderer Ansatz für Backups im Proxmox-Umfeld. In diesem Beitrag zeige ich dir, wie ich meinen Proxmox-Host mit PBS, NAS und USV zu einer ziemlich robusten Backup-Strategie zusammengebaut habe – und wo trotzdem noch Grenzen sind.

Ziel: Ein realistisches Setup, das nicht nur bei Sonnenschein funktioniert, sondern auch dann, wenn etwas richtig schiefgeht.

Ausgangslage: Was schon da war

Wer sich generell erst einmal einen Überblick über Proxmox verschaffen will, findet im Beitrag Proxmox Anleitung – Der große Überblick für Nerds und Homelab-Bastler eine gute Grundlage. Der folgende Aufbau setzt genau dort an und geht einen Schritt weiter Richtung Datensicherheit.

Bevor PBS ins Spiel kam, sah die Welt so aus:

  • Proxmox-Server mit allen VMs und Containern (teilweise ausgelagert, ähnlich wie in meinem Beitrag Proxmox NAS mit LXC einrichten beschrieben)
  • System- und VM-Platten im Mirror (RAID1)
  • Zusätzlich ein Backup-Job von Proxmox direkt aufs NAS
  • Verschiedene Stromkreise, einer davon mit USV abgesichert

Das klingt erst mal gar nicht schlecht:

  • Fällt eine Platte aus, übernimmt die andere.
  • Wenn sich eine VM zerschießt, gibt es meistens ein Backup auf dem NAS.
  • Wenn der Strom kurz weg ist, hält die USV den Laden am Laufen.

Aber: RAID hilft nicht, wenn man sich selbst ins Knie schießt. Und das passiert schneller, als man denkt.

Warum RAID kein Backup ist – wirklich nicht

Wer seine VMs und Container auf einem ZFS-Mirror betreibt, ist hardwareseitig schon gut unterwegs. Wie ich meine Proxmox VMs und Container auf ein solches Setup verschoben habe, beschreibe ich ausführlich im Beitrag Proxmox VMs und Container auf ein ZFS Mirror Storage verschieben. Wichtig ist aber: Auch ein ZFS-Mirror ersetzt kein echtes Backup.

Ein Mirror schützt vor Hardwaredefekten, aber nicht vor:

  • „Ups, falsche VM gelöscht …“
  • „Ups, falsches ZFS-Pool gelöscht …“
  • kaputten Updates
  • Malware oder Ransomware im Host oder in einer VM
  • Fehlkonfigurationen, die Daten logisch zerstören

RAID sorgt für Verfügbarkeit, nicht für Zeitreisen. Wenn du Mist baust, spiegelt RAID deinen Mist nur sehr zuverlässig.

Genau hier kommt Proxmox Backup Server ins Spiel.

Was der Proxmox Backup Server anders (und besser) macht

An dieser Stelle lohnt sich auch ein Blick auf die Hardware-Seite: Für einen Proxmox Backup Server braucht es kein High-End-System. Eine kleine, zuverlässige SSD reicht oft schon aus – etwa eine NAS- oder Server-SSD mit guter Dauerlast-Tauglichkeit.

Der Proxmox Backup Server ist kein „wir kopieren mal ein paar Dateien weg“-Backup, sondern arbeitet chunk-basiert und dedupliziert:

  • Daten werden in kleine Blöcke (Chunks) zerlegt.
  • Jeder Chunk bekommt einen Hash.
  • Existiert der Chunk schon, wird er nicht noch einmal gespeichert.
  • Backups bestehen aus Referenzen auf vorhandene Chunks.

Das Ergebnis:

  • Erstes Backup: groß.
  • Weitere Backups: oft nur noch wenige Prozent davon.
  • Identische Daten in mehreren VMs werden nur einmal gespeichert.

Zusätzlich bringt PBS:

  • Versionierte Backups (Zeitachsen-Feeling).
  • Retention-Regeln (wie viele Backups wie lange aufbewahrt werden).
  • Prune- und Garbage-Collection-Jobs, die Altlasten sauber wegräumen.

Kurz gesagt: Der Proxmox Backup Server ist eine deduplizierende Zeitmaschine für VMs, Container und Hosts.

Proxmox Backup Server einrichten: Kurz-Anleitung aus der Praxis

Bevor die ganze Backup-Strategie überhaupt Sinn ergibt, muss der Proxmox Backup Server natürlich erst einmal sauber eingerichtet werden. Hier keine trockene Referenzdoku, sondern eine praxisnahe Kurz-Anleitung – genau so, wie ich es umgesetzt habe.

1. Proxmox Backup Server installieren

Der Proxmox Backup Server wird nicht als Plugin installiert, sondern läuft als eigenes System.

Kurzfassung:

Wichtig dabei:

  • Eigene Platte verwenden (keine VM-Disk des Proxmox-Hosts)
  • Root-Passwort sauber setzen
  • Netzwerk korrekt konfigurieren

Nach der Installation erreichst du die Weboberfläche unter:

https://IP-DES-PBS:8007

2. Datastore anlegen

Im PBS-Webinterface:

Datastores → Add

  • Name: z. B. pve-backups
  • Pfad: z. B. /mnt/datastore/pve-backups
  • Garbage Collection aktiv lassen

Der Datastore ist der eigentliche Speicherort für alle Backups.

3. API-Token für Proxmox erstellen

Damit der Proxmox-Host Backups schreiben darf, wird kein Passwort, sondern ein API-Token genutzt.

Access Control → API Tokens → Add

  • User: root@pam
  • Token-ID: z. B. pve
  • Privilege Separation: aktivieren

Das erzeugte Token wird später im Proxmox-Host benötigt.

4. Berechtigungen für den Datastore setzen

Ohne ACL sieht Proxmox den Datastore zwar, darf ihn aber nicht nutzen.

Access Control → Permissions → Add

  • Path: /datastore/pve-backups
  • User/Token: root@pam!pve
  • Role: DatastoreBackup (oder DatastoreAdmin)

5. Proxmox Backup Server im Proxmox-Host einbinden

Im Proxmox VE:

Datacenter → Storage → Add → Proxmox Backup Server

  • Server: IP des PBS
  • Datastore: pve-backups
  • Username: root@pam!pve
  • Password: API-Token
  • Fingerprint: aus der PBS-Weboberfläche (Configuration → Certificates)

Nach dem Speichern sollte der Storage-Status sofort auf OK stehen.

6. Backup-Job anlegen

Im Proxmox-Host:

Datacenter → Backup → Add

  • Storage: PBS
  • Schedule: täglich
  • Mode: Snapshot
  • Compression: ZSTD
  • Retention: z. B. last 7, daily 14

Spätestens jetzt ist der Proxmox Backup Server produktiv im Einsatz.

Mein Setup mit Proxmox Backup Server, NAS und USV

Gerade beim Thema Stromversorgung zahlt sich saubere Hardware aus. Eine USV für Server und Netzwerk ist kein Luxus, sondern schützt Backups und Dateisysteme zuverlässig vor Stromausfällen und Spannungsschwankungen.

1. Mirror für VM-Storage

Die VM- und CT-Platten liegen auf zwei physisch getrennten Laufwerken im Mirror. Das schützt mich vor einem spontanen Plattentod mitten in der Nacht. Komfort, nicht Backup.

2. Proxmox Backup Server als zentrale Backup-Zentrale für Proxmox

Der Proxmox Backup Server läuft auf einem eigenen System. Wichtig dabei:

  • Eigener Host, nicht nur ein Container.
  • Eigener Datastore für die Proxmox-Backups.
  • Deduplizierte, versionierte Backups aller wichtigen VMs und CTs.

Auf Proxmox-Seite sind dann Backup-Jobs eingerichtet, die regelmäßig Snapshots auf den Proxmox Backup Server schieben.

3. NAS als zusätzliche Kopie

Zusätzlich läuft ein weiterer Backup-Job, der auf ein NAS schreibt. Das ist mein „Backup vom Backup“ bzw. eine Parallel-Schiene für wichtige Daten.

4. Stromseitig getrennt + USV

PBS, Proxmox-Host und NAS hängen nicht alle am gleichen Stromkreis. Einer der Kreise ist zusätzlich über eine USV abgesichert.

Das bedeutet:

  • Ein kaputtes Netzteil oder eine fliegende Sicherung legt nicht alles lahm.
  • Bei Stromausfall gibt es Zeit, sauber herunterzufahren.

Damit ist das Setup schon deutlich robuster als „alles an einer Steckdosenleiste hinterm Sofa“.

Wie sicher ist das Setup mit Proxmox Backup Server jetzt wirklich?

Mit diesem Aufbau bin ich gegen vieles gut abgesichert:

  • Plattenausfall: Mirror fängt das ab.
  • Datenkorruption / Zerschossene VMs: PBS hält mehrere Versionen vor.
  • Fehlkonfiguration / kaputte Updates: Zurückrollen auf ältere Snapshots.
  • Stromprobleme: getrennte Stromkreise + USV fangen das Gröbste ab.
  • PBS-Problem oder Fehler im Backup-Jobsystem: zusätzliche Kopie aufs NAS.

Auf einer sehr subjektiven Skala von 0 bis 10 würde ich sagen:

  • Kein Backup: 1
  • RAID ohne Backup: 3
  • PBS ohne Zweitkopie: 7
  • PBS + Mirror + NAS (mein Setup): etwa 9

Die eine große Schwachstelle bleibt: alles steht im selben Gebäude.

Was noch fehlt: Offsite oder Offline

Für Offline-Backups nutze ich bewusst einfache Mittel. Eine externe USB-Festplatte mit ausreichend Kapazität ist günstig, flexibel und vor allem komplett vom System trennbar – ein großer Vorteil gegenüber permanent verbundenem Storage.

So gut das Ganze schon ist – bei Feuer, Diebstahl oder einem wirklich fiesen Überspannungsereignis kann es passieren, dass:

  • Proxmox-Host,
  • PBS,
  • NAS

alle gleichzeitig beschädigt oder zerstört werden.

Dagegen hilft nur eines: Ein Backup, das nicht dauerhaft online und nicht am gleichen Ort liegt.

Ein paar simple Ideen, ohne gleich halbe Rechenzentren zu bauen:

1. Offline-USB-Platte

  • Einmal im Monat eine USB-HDD ans NAS oder PBS hängen.
  • Wichtige Backups oder Snapshots darauf kopieren.
  • Platte abstöpseln und in einen anderen Raum (oder zu jemandem vertrauenswürdigen) legen.

Vorteil: günstig, simpel, offline = keine Ransomware-Gefahr.

2. Zweiter PBS an anderer Stelle

  • Kleiner Server bei Freund:in, Familie oder im Büro.
  • Replikation der PBS-Backups dorthin.
  • Daten verschlüsselt übertragen.

Vorteil: echte Offsite-Strategie, automatisiert. Nachteil: braucht wieder Hardware und Setup.

3. Cloud-Speicher (für die ganz Wichtigen)

  • Nicht alles, aber z. B. Konfigurationsbackups, wichtigstes System, Passwort-Datenbank.
  • Verschlüsselt in einen S3-kompatiblen Storage oder ähnliches.

Vorteil: geografisch getrennt. Nachteil: laufende Kosten, mehr Komplexität.

3-2-1-Regel im Nerd-Check

Die klassische 3-2-1-Backup-Formel lautet:

  • 3 Kopien der Daten
  • auf 2 verschiedenen Medien
  • 1 Kopie offsite

Mein aktuelles Setup erfüllt:

  • 3 Kopien:
    • VM/CT auf dem Proxmox-Host
    • Backup auf PBS
    • Backup auf NAS
  • 2 Medien:
    • lokale SSDs/HDDs
    • NAS-Storage

Was (noch) fehlt, ist die 1 Offsite-Komponente. Die lässt sich aber relativ leicht nachrüsten, z. B. mit einer rotierenden USB-HDD.

Praktische Checkliste für ein ähnliches Setup

Wenn du etwas Vergleichbares nachbauen willst, hier eine kompakte Checkliste:

  1. VM-Storage robust machen
    • Mirror (RAID1) oder ZFS-Mirror für wichtige Platten.
  2. Proxmox Backup Server aufsetzen
    • Eigene SSD / eigener Host.
    • Datastore anlegen.
    • PVE per API-Token anbinden.
  3. Regelmäßige Backup-Jobs in Proxmox einrichten
    • Tägliche Snapshots auf PBS.
    • Retention sinnvoll wählen (z. B. last 7, daily 14, weekly 8, monthly 6).
  4. Prune- und Garbage-Collection-Jobs auf PBS konfigurieren
    • Täglich Prune, danach GC.
  5. Zweiten Backup-Pfad einrichten
    • Zusätzlicher Job aufs NAS.
  6. Stromseitig trennen & absichern
    • PBS, PVE, NAS nicht alle an einem Stromkreis.
    • Wichtigster Pfad über USV absichern.
  7. Optional: Offsite / Offline hinzufügen
    • USB-Platte, zweiter PBS oder Cloud.

Sinnvolle Hardware-Ergänzungen für ein solides Proxmox-Backup-Setup

Zum Abschluss noch ein paar ganz praktische Empfehlungen aus der Kategorie „braucht man nicht sofort – aber spätestens dann, wenn man sie nicht hat“. Keine Pflicht, aber extrem sinnvoll, wenn man es mit Backups ernst meint:

  • Eine gute USV (bezahlter Link) sollte mindestens am Produktivsystem und am Proxmox Backup Server hängen. Sie schützt nicht nur vor Stromausfällen, sondern verhindert vor allem beschädigte Dateisysteme durch harte Abschaltungen.
  • Zuverlässige NAS- oder Server-SSDs (bezahlter Link) für den Proxmox Backup Server sorgen dafür, dass Deduplizierung, Garbage Collection und Verifikation nicht zur Geduldsprobe werden. Billige Consumer-SSDs sind hier oft der falsche Sparpunkt.
  • Eine externe USB-Festplatte (bezahlter Link) für Offline-Backups ist eine der günstigsten Möglichkeiten, sich gegen Feuer, Diebstahl oder Totalausfälle im eigenen Netzwerk abzusichern. Abstecken nicht vergessen.
  • Ein separates NAS (bezahlter Link) als zusätzlicher Backup-Zielort erhöht die Redundanz deutlich und dient gleichzeitig als zweite Verteidigungslinie, falls am PBS selbst etwas schiefgeht.

Fazit: Mit Proxmox Backup Server von „wird schon gut gehen“ zu „ich kann nachts wieder ruhig schlafen“

Mit dem Proxmox Backup Server, einem zusätzlichen NAS-Backup und gespiegelten Platten ist mein Homelab von „funktioniert irgendwie“ zu „relativ katastrophenresistent“ gewandert.

Perfekt ist das Ganze erst, wenn mindestens eine Kopie wirklich offsite oder offline liegt. Aber der Unterschied zwischen „gar kein echtes Backup“ und einem deduplizierten, versionierten PBS-Setup ist gewaltig.

Wenn du also gerade mit Proxmox herumspielst und noch kein ordentliches Backup-Konzept hast: PBS ist genau der Punkt, an dem aus Bastelbude langsam ernstzunehmende Infrastruktur wird.

Und ganz ehrlich: Nichts fühlt sich so nerdig befriedigend an wie der Moment, in dem man eine VM mutwillig zerschießt – und sie dann mit ein paar Klicks aus einem sauberen, aktuellen Backup zurückholt.

Proxmox NAS mit LXC einrichten – die schlanke Lösung für Nerds und Homelab-Bastler

von
Rotes Zebra mit blauem Irokesenschnitt steht in einem Serverraum mit Proxmox-Oberfläche im Hintergrund – Symbolbild für ein selbst gebautes NAS im LXC-Container.

Ein leichtgewichtiges NAS ohne dicke Klick-Klick-Oberfläche – genau das basteln wir hier: ein Debian-LXC auf Proxmox, eine dedizierte Festplatte als Datenspeicher, Samba für Windows-Freigaben und MiniDLNA für TV/Player. Der Guide ist so gebaut, dass du ihn 1:1 ins Terminal werfen kannst – und jetzt mit nerdig-charmanten Erklärungen, warum das Ganze funktioniert.

Zielbild

  • Host: Proxmox VE
  • Datendisk: ext4 auf /mnt/nas-disk
  • LXC (Debian 12): sieht die Platte als /mnt/nas
  • Shares (Samba): fotos, videos, music, backups
  • DLNA (MiniDLNA): scannt fotos/videos/music

Voraussetzungen – das Fundament

Bevor wir loslegen, checken wir, ob unser Proxmox bereit ist: ein Debian-Template, eine Bridge fürs Netz (vmbr0) und eine zusätzliche Platte, die bald zum Datenhort wird. Wenn hier was fehlt, erstmal das fixen – sonst wird’s wie Kuchenbacken ohne Backofen.

Praktisch: Lies vorher kurz in meiner Proxmox Anleitung rein, falls du neu im Homelab-Game bist.

Tipp: Für das Projekt lohnt sich eine solide SSD (Crucial BX500 1TB (bezahlter Link) oder Samsung 870 EVO 1TB (bezahlter Link)). Wenn du später mehr speichern willst, gönn dir gleich eine große NAS-HDD* (WD Red Plus 4TB (bezahlter Link)).

1) Platte vorbereiten – Bits und Bytes in Reih und Glied

Hier bringen wir Ordnung auf die Festplatte: Partition anlegen, Dateisystem erstellen, Mountpoint bauen und in die fstab eintragen. Kurz gesagt: Wir sagen Linux, wo es die Daten später wiederfindet.

👉 Mehr zu Dateisystemen findest du im Debian Wiki (Filesystem Basics).

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT

Zeigt alle Laufwerke und Partitionen an – quasi der Röntgenblick in den Speicherbauch des Servers.

wipefs -a /dev/sdb

Löscht alles – gnadenlos. Danach ist das Ding wirklich leer. Nur nutzen, wenn du dir absolut sicher bist.

fdisk /dev/sdb <<'FDISK'
g
n

w
FDISK

Das altehrwürdige fdisk: Wir werfen eine neue GPT-Tabelle auf die Platte (g), erstellen eine Partition (n) und speichern das Ganze (w).

mkfs.ext4 -L NASDATA /dev/sdb1

Formatiert die Partition mit ext4, nennt sie NASDATA – unser kleiner digitaler Tresor bekommt seinen Namen.

mkdir -p /mnt/nas-disk
blkid /dev/sdb1

Wir machen einen Mountpunkt und lesen die UUID aus – das ist der unverwechselbare Fingerabdruck der Partition.

nano /etc/fstab

Die fstab ist wie ein Stundenplan fürs Booten: Hier tragen wir ein, welche Platten automatisch eingehängt werden sollen.

mount -a
df -h | grep nas-disk

Wir testen, ob das Ganze funktioniert – und prüfen, ob die Platte wirklich da hängt, wo sie soll.

2) Debian-LXC erstellen – unser kleines Betriebssystem im Käfig

Jetzt wird’s konkret: Wir erschaffen den Container, in dem unser NAS lebt. Das ist wie ein Mini-PC im großen Proxmox-System.

pct create 200 local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst \
  --hostname nas \
  --memory 512 \
  --cores 1 \
  --swap 512 \
  --rootfs local-lvm:8 \
  --net0 name=eth0,bridge=vmbr0,ip=dhcp \
  --unprivileged 1

Dieser Befehl erschafft Container-ID 200 mit 512 MB RAM, einer CPU und automatischer IP über DHCP. --unprivileged sorgt für mehr Sicherheit.

pct start 200

Wir hauchen ihm Leben ein. Der Container startet – ab jetzt tickt dort ein eigenes Mini-Debian.

pct exec 200 -- hostname -I

Damit finden wir heraus, welche IP unser LXC im Netzwerk bekommen hat.

Hardware-Tipp: Für stabile Netzwerkverbindungen im Rack ist ein PoE-Switch Gold wert – z. B. der TP-Link TL-SG108PE (bezahlter Link).

3) Datendisk einhängen – Platte trifft Container

Jetzt verheiraten wir Host und Container: Die physische Platte auf dem Host wird im LXC eingebunden.

pct set 200 -mp0 /mnt/nas-disk,mp=/mnt/nas

Das ist der Zauberspruch: Wir sagen dem Container, dass /mnt/nas-disk auf dem Host unter /mnt/nas im LXC erscheinen soll.

(A) Container privilegiert schalten – schnell und schmutzig

Manchmal darf der Container ruhig wissen, dass er auf dem Host läuft. So kann er ohne Umwege auf die Platte schreiben.

pct stop 200
nano /etc/pve/lxc/200.conf   # unprivileged: 1 -> 0
pct start 200

Container stoppen, in der Konfigurationsdatei den Schalter umlegen und wieder starten. Voilà: privilegiert.

(B) Container unprivilegiert lassen – sauber, aber mehr Aufwand

Hier bleibt die Sicherheit höher, wir müssen aber UID und GID passend setzen.

id zebra
chown -R 1000:1000 /mnt/nas-disk

Im Container sehen wir, welche ID der Benutzer hat (meist 1000). Dann geben wir ihm auf dem Host Besitzrechte über die Platte.

pct enter 200
ls -lh /mnt/nas

Wir schauen nach, ob der Container die Platte jetzt brav sieht.

4) Samba installieren – Windows spricht jetzt auch NASisch

Samba ist der Dolmetscher zwischen Linux und Windows. Hiermit bekommt dein NAS endlich eine Freigabe im Explorer.

👉 Weitere Infos: Offizielle Samba Doku

apt update
apt install -y samba

Lädt die neuesten Paketlisten und installiert Samba.

mkdir -p /mnt/nas/{fotos,videos,music,backups}

Erstellt die Ordner, die später als Freigaben auftauchen.

adduser zebra
smbpasswd -a zebra

Erzeugt einen Benutzer im System und gibt ihm ein Samba-Passwort – ohne das gibt’s keinen Zutritt.

nano /etc/samba/smb.conf

Hier konfigurieren wir unsere Freigaben: Pfade, Zugriffsrechte, Benutzer. Danach speichern, schließen, fertig.

systemctl enable smbd --now
systemctl status smbd

Aktiviert den Samba-Dienst, startet ihn sofort und prüft den Status. Läuft’s grün, läuft’s gut.

5) MiniDLNA – Medienstreaming für Faule

Jetzt kommt der Bonus: Wir verwandeln das NAS in einen Medienserver, der automatisch alle Bilder, Videos und Musik findet und an Smart-TVs verteilt.

apt update
apt install -y minidlna locales

Zieht sich DLNA und Sprachpakete – weil deutsche Fehlermeldungen einfach freundlicher sind.

sed -i 's/^# \(de_DE.UTF-8 UTF-8\)/\1/' /etc/locale.gen
locale-gen
update-locale LANG=de_DE.UTF-8

Aktiviert die deutsche Sprache im System – kein Muss, aber hübscher.

mkdir -p /var/cache/minidlna /var/log/minidlna /run/minidlna
chown -R minidlna:minidlna /var/cache/minidlna /var/log/minidlna /run/minidlna

Erstellt Cache- und Logverzeichnisse, damit MiniDLNA nicht meckert.

nano /etc/minidlna.conf

Hier sagen wir dem Server, welche Medienordner er scannen soll und welchen Namen er im Netzwerk trägt.

systemctl enable minidlna --now
systemctl stop minidlna
minidlnad -R -f /etc/minidlna.conf
systemctl start minidlna

Startet MiniDLNA, baut eine neue Medien-Datenbank auf und startet wieder sauber durch.

Weboberfläche: http://<Container-IP>:8200/ – hier siehst du, was der Server gefunden hat.

Tipp: Wenn du keinen Smart-TV hast, probier VLC Media Player oder einen Raspberry Pi mit Kodi (Raspberry Pi Set bei Amazon (bezahlter Link)).

6) Troubleshooting – wenn das NAS zickt

Hier greifen wir zum Schraubenzieher der digitalen Welt. Ob fehlende Berechtigungen, blockierte Ports oder störrische Fernseher – hier findest du die typischen Stolpersteine und ihre Reparaturkommandos.

7) Fertig & Nächste Schritte – der Nerdmodus ist aktiviert

Dein DIY-NAS läuft! Zeit für den Feinschliff: Backups mit rsync oder borgbackup (BorgBackup Doku) automatisieren, vielleicht noch SnapRAID für Redundanz oder MergerFS für Plattenverbunde.

Wenn du magst, spiel mit Samba-Performanceparametern und gönn deinem LXC eine feste IP – denn Stabilität ist sexy.

Glückwunsch, du hast ein echtes Nerd-NAS gebaut! 💾📺🦓