☚ zurück - Einstiegskurs

In diesem Projekt wird aus einem Raspberry Pi ein zentraler NFS-Backupserver für ein lokales Netzwerk aufgebaut. Ziel ist eine saubere und technisch nachvollziehbare Trennung zwischen einem ausschließlich lesbaren Bereich und einem schreibbaren Datenbereich. Dabei wird bewusst keine Benutzer-Synchronisation zwischen Client und Server eingesetzt. Stattdessen werden alle Schreibzugriffe serverseitig auf einen definierten Service-User abgebildet. Dadurch bleibt die Client-Konfiguration minimal, konsistent und unabhängig von lokalen UID-Strukturen.

Der Server stellt zwei Verzeichnisse bereit:

• /srv/nfs/public → nur lesend (ro)
• /srv/nfs/data → lesend + schreibend (rw, Service-User 2000)

Für das Datenverzeichnis wird ein technischer Service-User mit der UID/GID 2000 eingerichtet. Alle Schreibzugriffe werden mittels all_squash auf diesen Benutzer umgeleitet. Dadurch gehören sämtliche erzeugten Dateien immer demselben Systemkonto – unabhängig davon, welcher Client sie erstellt hat.

Dieses Modell verhindert UID-Konflikte zwischen unterschiedlichen Linux-Systemen im Netzwerk und sorgt für ein eindeutiges Besitzmodell auf dem Server.

Alle schreibenden Zugriffe auf /srv/nfs/data werden serverseitig auf UID/GID 2000 abgebildet (all_squash).

Im Kurs steht der Server bereits zur Verfügung, sodass es primär darum geht, ihn korrekt einzubinden. Wer einen eigenen NFS-Server aufsetzen möchte, findet hier die vollständige Einrichtung.

Einrichtung Server

sudo apt update
sudo apt install -y nfs-kernel-server
 
# Service-User für schreibendes Share
sudo groupadd -g 2000 nfsdata
sudo useradd -u 2000 -g 2000 -M -r nfsdata
 
# Verzeichnisse anlegen
sudo mkdir -p /srv/nfs/public
sudo mkdir -p /srv/nfs/data
 
# Rechte setzen
sudo chown -R root:root /srv/nfs/public
sudo chmod -R 755 /srv/nfs/public
 
sudo chown -R 2000:2000 /srv/nfs/data
sudo chmod -R 2775 /srv/nfs/data
 
# ================================
# /etc/exports
# ================================
 
/srv/nfs/public  IP/24(ro,sync,no_subtree_check,root_squash)
/srv/nfs/data    IP/24(rw,sync,no_subtree_check,all_squash,root_squash,anonuid=2000,anongid=2000)
 
# anwenden
sudo exportfs -ra
sudo systemctl restart nfs-kernel-server
sudo systemctl enable nfs-kernel-server
 
# prüfen
sudo exportfs -v

Um die Freigaben zu verwenden, wird auf dem Client zunächst das notwendige Paket installiert.

sudo apt install -y nfs-common
showmount -e IP

Der Befehl zeigt an, welche Verzeichnisse der Server exportiert.

Für einen ersten Test werden lokale Mountpunkte angelegt und die Freigaben manuell eingebunden.

sudo mkdir -p /mnt/public
sudo mkdir -p /mnt/data
 
sudo mount -t nfs -o ro IP:/srv/nfs/public /mnt/public
sudo mount -t nfs -o rw,soft,timeo=50,retrans=3 IP:/srv/nfs/data /mnt/data

Das Verzeichnis /mnt/public ist nur lesbar. Im Verzeichnis /mnt/data können Dateien erzeugt werden, die serverseitig immer UID/GID 2000 gehören.

Damit der Client auch dann startet, wenn der Server nicht erreichbar ist, erfolgt die Einbindung per systemd-Automount in der /etc/fstab.

IP:/srv/nfs/public  /mnt/public  nfs  ro,_netdev,noatime,x-systemd.automount,nofail  0  0
IP:/srv/nfs/data    /mnt/data    nfs  rw,_netdev,noatime,x-systemd.automount,x-systemd.device-timeout=10s,x-systemd.idle-timeout=600,soft,timeo=50,retrans=3,nofail  0  0
 
sudo systemctl daemon-reload
sudo mount -a

Der Mount erfolgt nun erst beim ersten Zugriff. Ist der Server nicht erreichbar, blockiert der Bootvorgang nicht.

Der NFS-Server stellt lediglich den zentralen Speicher bereit. Die eigentlichen Backups werden auf den Clients erzeugt und anschließend in das Verzeichnis /mnt/data geschrieben.

Im Kurs werden zwei einfache Verfahren verwendet:

• scp → einfache vollständige Kopie
• rsync → effizientes inkrementelles Backup

core) torsten@hiketas:~ $ date +%Y-%m-%d_%H-%M-%S
2026-03-03_11-50-46

scp -r /home/pi/daten /mnt/data/backup_$(date +%Y-%m-%d_%H-%M-%S)

Es wird ein datumsbasierter Ordner erzeugt. Dieses Verfahren kopiert immer alle Dateien vollständig.

rsync -a --delete /home/pi/daten/ /mnt/data/backup_aktuell/

Optionen:

• -a → Archivmodus (Rechte, Zeitstempel, Links)
• –delete → entfernt Dateien im Ziel, die im Quellverzeichnis nicht mehr existieren
• –dry-run führt rsync als Simulation aus und zeigt an, welche Änderungen vorgenommen würden, ohne tatsächlich Dateien zu kopieren oder zu löschen.

Ein Backup ist gut – mehrere Sicherungsstände sind besser. Ein verbreitetes Verfahren ist die Rotation nach dem Round-Robin-Prinzip. Dabei werden mehrere Backup-Ordner zyklisch überschrieben. So stehen mehrere Generationen zur Verfügung, ohne dass der Speicherplatz unbegrenzt wächst.

Damit ein Backup-Konzept zuverlässig funktioniert, muss es außerdem automatisiert werden. Andernfalls wird es im Alltag häufig vergessen. Hierfür verwenden wir cron, ein Standardwerkzeug zur zeitgesteuerten Ausführung von Aufgaben.

Beispiel mit drei Generationen: Dabei werden drei Sicherungsstände verwaltet, wobei bei jedem Durchlauf die älteste Sicherung gelöscht, die beiden vorhandenen um eine Position nach hinten verschoben und anschließend ein neues aktuelles Backup erzeugt wird.

#!/bin/bash
set -euo pipefail
 
TARGET="/mnt/data"
SOURCE="/home/pi/daten"
 
rm -rf "$TARGET/backup_3"
[ -d "$TARGET/backup_2" ] && mv "$TARGET/backup_2" "$TARGET/backup_3" || true
[ -d "$TARGET/backup_1" ] && mv "$TARGET/backup_1" "$TARGET/backup_2" || true
 
rsync -a --delete "$SOURCE/" "$TARGET/backup_1/"

Ergebnis:

• backup_1 → aktuelles Backup
• backup_2 → vorherige Version
• backup_3 → ältere Version

Bei jedem Lauf wird die älteste Version gelöscht und die anderen rücken nach.

Skript speichern, z.B. als /home/pi/backup.sh:

chmod +x /home/pi/backup.sh

Crontab öffnen:

crontab -e

Beispiel: tägliches Backup um 22:00 Uhr:

0 22 * * * /home/pi/backup.sh

Damit wird das Rotationsskript jeden Tag automatisch gestartet.