Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- project:backup [2026/03/03 09:30] – torsten.roehl
+++ project:backup [2026/03/03 10:51] (aktuell) – torsten.roehl
@@ Zeile 1: / Zeile 1: @@
 ====== Projekt: Raspberry PI als Backupserver ======
 [[raspberry_pi:einstiegskurs_raspberry_pi|  ☚ zurück - Einstiegskurs]]
-===== Varianten des NFS-Betriebs =====
+//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. {{ :raspberry_pi:nfs_2.png?250|}}
+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.//
-In diesem Projekt werden zwei einfache und praxisnahe Varianten behandelt.
+====== Konzept ======
-Eine dritte, klassische UNIX-Variante existiert ebenfalls, wird hier jedoch nicht umgesetzt.
+Der Server stellt zwei Verzeichnisse bereit:
-==== Variante A – Einheitlicher Service-User (all_squash) ====
+  * ''/srv/nfs/public''  → nur lesend (''ro'')
+  * ''/srv/nfs/data''    → lesend + schreibend (''rw'', Service-User 2000)
-Alle Zugriffe von Clients werden serverseitig auf eine feste UID/GID (hier 2000) abgebildet.
+{{ :raspberry_pi:nfs1.png?400 |}}
-Merkmale:
+Für das Datenverzeichnis wird ein technischer Service-User mit der ''UID/GID'' **2000** eingerichtet.
-  * keine UID-/GID-Synchronisation zwischen Clients notwendig
+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.
-  * alle Dateien gehören serverseitig dem Service-User
-  * sehr wartungsarm
-  * ideal für Backup- oder Sammelverzeichnisse
-  * geeignet für kleine, vertrauenswürdige Netzwerke
-Diese Variante wird in diesem Projekt standardmäßig verwendet.
+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'').
+<note important>
+**SERVER**
+Die IP-Adresse des Servers wird hier mit ''IP'' gekennzeichnet und muss im Kurs durch die tatsächliche IP-Adresse ersetzt werden.
+</note>
-==== Variante B – Nur Lesen (read-only Export) ====
+====== NFS Server ======
-Der Server stellt das Verzeichnis ausschließlich lesend bereit.
+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.
-Merkmale:
+++++ Einrichtung Server |
-  * Clients können keine Daten verändern
+<code bash>
-  * hohe Betriebssicherheit
+sudo apt update
-  * geeignet für Software-Repositories, Images oder Referenzdaten
+sudo apt install -y nfs-kernel-server
-  * nicht geeignet als Backup-Ziel
-Diese Variante ist optional möglich und wird unten technisch gezeigt.
+# 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
-==== Variante C – Klassisches UNIX-Modell (nicht Bestandteil dieses Projekts) ====
+sudo chown -R 2000:2000 /srv/nfs/data
+sudo chmod -R 2775 /srv/nfs/data
-Hier arbeiten Server und Clients mit identischen UID/GID-Werten.
+# ================================
-Der Server speichert echte Benutzer-IDs ohne Mapping.
+# /etc/exports
+# ================================
-Merkmale:
+/srv/nfs/public  IP/24(ro,sync,no_subtree_check,root_squash)
-  * saubere Benutzertrennung
+/srv/nfs/data    IP/24(rw,sync,no_subtree_check,all_squash,root_squash,anonuid=2000,anongid=2000)
-  * ACLs und klassische UNIX-Rechte funktionieren vollständig
-  * erfordert konsistente Benutzerverwaltung auf allen Systemen
-  * administrativ aufwendiger
-Diese Variante wird hier bewusst nicht behandelt, da der Fokus auf einem einfachen,
+# anwenden
-wartungsarmen Backup-Server liegt.
+sudo exportfs -ra
+sudo systemctl restart nfs-kernel-server
+sudo systemctl enable nfs-kernel-server
+# prüfen
+sudo exportfs -v
+</code>
+Nach dem Neustart des Dienstes stellt der **Raspberry Pi** beide Verzeichnisse im Netzwerk bereit.
+Das öffentliche Verzeichnis ist ausschließlich lesbar, während im Datenverzeichnis alle Schreibzugriffe auf den Service-User 2000 abgebildet werden.
+++++
-===== Voraussetzungen =====
+====== NFS Client ======
-  * SERVER: Mit ''IP'' ist die IP-Adresse des Servers gemeint.
-  * CLIENT: Rechner, der das exportierte Verzeichnis vom Server einbindet.
+Um die Freigaben zu verwenden, wird auf dem Client zunächst das notwendige Paket installiert.
+===== Verfügbare Exports anzeigen =====
-===== NFS SERVER =====
 <code bash>
-sudo apt update
+sudo apt install -y nfs-common
-sudo apt install -y nfs-kernel-server
+showmount -e IP
+</code>
-# Service-User (nur für Variante A notwendig)
+Der Befehl zeigt an, welche Verzeichnisse der Server exportiert.
-sudo groupadd -g 2000 nfsdata
-sudo useradd -u 2000 -g 2000 -M -r nfsdata
-# Export-Verzeichnis
+===== Manuell Mounten =====
-sudo mkdir -p /srv/nfs/data
-sudo chown -R 2000:2000 /srv/nfs/data
+Für einen ersten Test werden lokale Mountpunkte angelegt und die Freigaben manuell eingebunden.
-sudo chmod -R 2775 /srv/nfs/data
+<code bash>
+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
 </code>
+Das Verzeichnis ''/mnt/public'' ist nur lesbar.
+Im Verzeichnis ''/mnt/data'' können Dateien erzeugt werden, die serverseitig immer UID/GID 2000 gehören.
-==== Variante A – Schreibend mit Service-User ====
+===== Automatisch Mounten (/etc/fstab) =====
+Damit der Client auch dann startet, wenn der Server nicht erreichbar ist, erfolgt die Einbindung per systemd-Automount in der ''/etc/fstab''.
 <code bash>
-# /etc/exports
+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
-/srv/nfs/data  IP/24(rw,sync,no_subtree_check,all_squash,root_squash,anonuid=2000,anongid=2000)
+sudo systemctl daemon-reload
+sudo mount -a
+</code>
-# anwenden
+Der Mount erfolgt nun erst beim ersten Zugriff.
-sudo exportfs -ra
+Ist der Server nicht erreichbar, blockiert der Bootvorgang nicht.
-sudo systemctl restart nfs-kernel-server
-sudo systemctl enable nfs-kernel-server
-# prüfen
+<note>**Ergebnis**
-sudo exportfs -v
-</code>
+  * /srv/nfs/public  → nur lesbar für alle Clients
+  * /srv/nfs/data    → schreibbar, serverseitig UID/GID 2000
+  * Client bootet auch wenn Server offline ist
+  * Mount erfolgt erst bei Zugriff (automount)
+  * Keine UID-Anpassung auf Clients erforderlich
-==== Variante B – Nur Lesen ====
+Damit steht ein wartungsarmes Backup-System auf Basis eines **Raspberry Pi** zur Verfügung.
+</note>
-<code bash>
+====== Backup erstellen ======
-# /etc/exports
-/srv/nfs/data  IP/24(ro,sync,no_subtree_check,root_squash)
+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.
-# anwenden
+Im Kurs werden zwei einfache Verfahren verwendet:
-sudo exportfs -ra
-sudo systemctl restart nfs-kernel-server
-sudo systemctl enable nfs-kernel-server
-# prüfen
+  * ''scp''   → einfache vollständige Kopie
-sudo exportfs -v
+  * ''rsync'' → effizientes inkrementelles Backup
+===== Einfache Kopie mit scp =====
+<code bash>
+core) torsten@hiketas:~ $ date +%Y-%m-%d_%H-%M-%S
+-03-03_11-50-46
 </code>
+<code bash>
+scp -r /home/pi/daten /mnt/data/backup_$(date +%Y-%m-%d_%H-%M-%S)
+</code>
+Es wird ein datumsbasierter Ordner erzeugt.
+Dieses Verfahren kopiert immer alle Dateien vollständig.
-===== NFS CLIENT =====
-==== Verfügbare Exports anzeigen ====
+<note>Da das Verzeichnis mit ''nfs'' gemountet ist, wäre technisch auch ein einfaches ''cp'' ausreichend. Im Kurs wird jedoch zusätzlich ''scp'' verwendet, um zu zeigen, wie Backups auf andere Rechner übertragen werden können, die nicht per NFS eingebunden sind.</note>
+===== Inkrementelles Backup mit rsync =====
 <code bash>
-sudo apt install -y nfs-common
+rsync -a --delete /home/pi/daten/ /mnt/data/backup_aktuell/
-showmount -e IP
 </code>
+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.
+====== Backupkonzept: Rotation und Automatisierung ======
+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.
+===== Backup-Rotation (Round Robin Prinzip) =====
+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.
-==== Manuell Mounten ====
 <code bash>
-sudo mkdir -p /mnt/nfs
+#!/bin/bash
-sudo mount -t nfs -o rw,soft,timeo=50,retrans=3 IP:/srv/nfs/data /mnt/nfs
+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/"
 </code>
+{{ :raspberry_pi:backup_1.png?400 |}}
-==== Automatisch Mounten ====
+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.
+===== Automatische Ausführung mit cron =====
+Skript speichern, z.B. als ''/home/pi/backup.sh'':
 <code bash>
-# /etc/fstab
+chmod +x /home/pi/backup.sh
+</code>
-IP:/srv/nfs/data  /mnt/nfs  nfs  _netdev,noatime,x-systemd.automount,x-systemd.device-timeout=10s,x-systemd.idle-timeout=600,soft,timeo=50,retrans=3,nofail  0  0
+Crontab öffnen:
-sudo systemctl daemon-reload
+<code bash>
-sudo mount -a
+crontab -e
 </code>
+Beispiel: tägliches Backup um 22:00 Uhr:
-===== Ergebnis =====
+<code bash>
+22 * * * /home/pi/backup.sh
+</code>
-  * Variante A: Schreibzugriff für Clients, serverseitige UID/GID-Vereinheitlichung
+Damit wird das Rotationsskript jeden Tag automatisch gestartet.
-  * Variante B: Reiner Lesezugriff
-  * Client bootet auch wenn Server offline ist
+<note>
-  * Mount erfolgt erst bei Zugriff (automount)
+**Ergebnis**
-  * Kein Boot-Blockieren
-  * Exportierte Verzeichnisse prüfbar mit ''exportfs -v'' oder ''showmount -e IP''
+  * Backups werden vom Client erzeugt
+  * Speicherung erfolgt zentral auf dem NFS-Server
+  * Mehrere Sicherungsstände durch Rotation
+  * Automatische Ausführung über cron
+  * Keine zusätzliche Backup-Software erforderlich
+</note>