HomelabNerds

HOME LAB · SELFHOSTING · NETZWERK

Kategorie: NAS & Storage

Speicher, ZFS, Backups und NAS-Lösungen.

Immich Wartung im Alltag: Updates, Datenbank-Backup, Speicherhygiene
Schwierigkeit: Mittel · Dauer: 35–65 Min · Ziel: Immich Wartung im Alltag: Updates, Datenbank-Backup, Speicherhygiene

Kurzproblem und Zielbild
In vielen Homelabs funktioniert die Erstinstallation, aber der Dauerbetrieb wird schnell unübersichtlich. Dieses Tutorial zeigt einen reproduzierbaren Ablauf für Immich Wartung im Alltag mit Fokus auf Stabilität, klare Checks und einfache Fehlerbehebung.
Ziel ist ein Setup, das nicht nur heute läuft, sondern auch nach Updates und Änderungen beherrschbar bleibt.

Voraussetzungen
- Aktuelles Debian/Ubuntu oder kompatible Appliance
- Administrative Rechte und Wartungsfenster
- Backup- oder Snapshot-Möglichkeit vor Änderungen
Schnellstart (funktionierende Basis)
```
# Basisprüfung
hostnamectl
ip a
# Dienste prüfen
systemctl --failed
# Logs kurz prüfen
journalctl -p 3 -xb --no-pager | tail -n 30
```
Was macht das? Du prüfst erst den Grundzustand und vermeidest, dass Altfehler in neue Änderungen hineinwirken.

Schritt-für-Schritt Umsetzung

1) Ausgangszustand dokumentieren
```
date -Iseconds
uname -a
# versions/relevante configs sichern
```
Erklärung: Mit einer kurzen Bestandsaufnahme lassen sich spätere Fehler schneller eingrenzen.

2) Kernkonfiguration sauber setzen
```
cd /opt/immich
docker compose pull
docker compose ps
docker exec -t immich_postgres pg_dump -U postgres immich > immich-$(date +%F).sql
ls -lh immich-*.sql
docker compose up -d
```
Erklärung: Änderungen gezielt umsetzen, danach direkt den Dienst-/Funktionszustand prüfen.
3) Dienst kontrolliert neu laden
```
sudo systemctl daemon-reload
sudo systemctl restart 
sudo systemctl status  --no-pager
```
4) Betriebsgrenzen testen
```
docker compose ps
docker compose logs --tail=120 server
docker compose logs --tail=120 microservices
curl -I http://127.0.0.1:2283
```
Validierung / Checks
```
docker compose ps
docker exec -t immich_postgres psql -U postgres -d immich -c "select now();"
docker volume ls | grep immich
df -h
```
Troubleshooting
Konfiguration wird nicht übernommen
Ursache: Syntax-, Reload- oder Parameterfehler.
```
docker compose logs --tail=200 server
docker compose logs --tail=200 microservices
docker compose logs --tail=200 immich_postgres
```
Dienst läuft, Funktion aber fehlerhaft
Ursache: Abhängigkeiten, Routing oder Berechtigungen sind inkonsistent.
```
createdb -U postgres immich_restore_test
psql -U postgres immich_restore_test < immich-YYYY-MM-DD.sql
psql -U postgres -d immich_restore_test -c "\dt"
```
Fazit
Mit einem klaren Ablauf für Immich Wartung im Alltag reduzierst du Ausfälle und erhöhst die Wartbarkeit deutlich. Der wichtigste Hebel ist die Kombination aus kleiner Änderung, sofortigem Check und dokumentiertem Ergebnis.
Nächster Schritt: den Ablauf als monatliche Betriebsroutine einplanen und regelmäßig gegen echte Störfälle testen.

Quellen
16.02.2026
Home Assistant Backups verlässlich machen: Full/Partial, Restore-Drill
Schwierigkeit: Mittel · Dauer: 35–65 Min · Ziel: Home Assistant Backups verlässlich machen: Full/Partial, Restore-Drill

Kurzproblem und Zielbild
In vielen Homelabs funktioniert die Erstinstallation, aber der Dauerbetrieb wird schnell unübersichtlich. Dieses Tutorial zeigt einen reproduzierbaren Ablauf für Home Assistant Backups verlässlich machen mit Fokus auf Stabilität, klare Checks und einfache Fehlerbehebung.
Ziel ist ein Setup, das nicht nur heute läuft, sondern auch nach Updates und Änderungen beherrschbar bleibt.

Voraussetzungen
- Aktuelles Debian/Ubuntu oder kompatible Appliance
- Administrative Rechte und Wartungsfenster
- Backup- oder Snapshot-Möglichkeit vor Änderungen
Schnellstart (funktionierende Basis)
```
# Basisprüfung
hostnamectl
ip a
# Dienste prüfen
systemctl --failed
# Logs kurz prüfen
journalctl -p 3 -xb --no-pager | tail -n 30
```
Was macht das? Du prüfst erst den Grundzustand und vermeidest, dass Altfehler in neue Änderungen hineinwirken.

Schritt-für-Schritt Umsetzung

1) Ausgangszustand dokumentieren
```
date -Iseconds
uname -a
# versions/relevante configs sichern
```
Erklärung: Mit einer kurzen Bestandsaufnahme lassen sich spätere Fehler schneller eingrenzen.

2) Kernkonfiguration sauber setzen
```
ha backups list
ha backups new --name "full-$(date +%F)" --all
ha backups list | head -n 40
```
Erklärung: Änderungen gezielt umsetzen, danach direkt den Dienst-/Funktionszustand prüfen.
3) Dienst kontrolliert neu laden
```
sudo systemctl daemon-reload
sudo systemctl restart 
sudo systemctl status  --no-pager
```
4) Betriebsgrenzen testen
```
ha backups list
# Partial-Restore auf Test-Entität prüfen
# danach Automationen/Entities gegenchecken
```
Validierung / Checks
```
ha core info
ha backups list
ha addons list
ha supervisor logs --lines 150
```
Troubleshooting
Konfiguration wird nicht übernommen
Ursache: Syntax-, Reload- oder Parameterfehler.
```
ha core info
ha supervisor info
ha supervisor logs --lines 200
```
Dienst läuft, Funktion aber fehlerhaft
Ursache: Abhängigkeiten, Routing oder Berechtigungen sind inkonsistent.
```
ha backups info BACKUP_SLUG
ha backups new --name "full-verify-$(date +%F)" --all
```
Fazit
Mit einem klaren Ablauf für Home Assistant Backups verlässlich machen reduzierst du Ausfälle und erhöhst die Wartbarkeit deutlich. Der wichtigste Hebel ist die Kombination aus kleiner Änderung, sofortigem Check und dokumentiertem Ergebnis.
Nächster Schritt: den Ablauf als monatliche Betriebsroutine einplanen und regelmäßig gegen echte Störfälle testen.

Quellen
16.02.2026
TrueNAS SMB Shares sicher aufsetzen: Rechte, Snapshots, Restore
Schwierigkeit: Mittel · Dauer: 35–65 Min · Ziel: TrueNAS SMB Shares sicher aufsetzen: Rechte, Snapshots, Restore

Kurzproblem und Zielbild
In vielen Homelabs funktioniert die Erstinstallation, aber der Dauerbetrieb wird schnell unübersichtlich. Dieses Tutorial zeigt einen reproduzierbaren Ablauf für TrueNAS SMB Shares sicher aufsetzen mit Fokus auf Stabilität, klare Checks und einfache Fehlerbehebung.
Ziel ist ein Setup, das nicht nur heute läuft, sondern auch nach Updates und Änderungen beherrschbar bleibt.

Voraussetzungen
- Aktuelles Debian/Ubuntu oder kompatible Appliance
- Administrative Rechte und Wartungsfenster
- Backup- oder Snapshot-Möglichkeit vor Änderungen
Schnellstart (funktionierende Basis)
```
# Basisprüfung
hostnamectl
ip a
# Dienste prüfen
systemctl --failed
# Logs kurz prüfen
journalctl -p 3 -xb --no-pager | tail -n 30
```
Was macht das? Du prüfst erst den Grundzustand und vermeidest, dass Altfehler in neue Änderungen hineinwirken.

Schritt-für-Schritt Umsetzung

1) Ausgangszustand dokumentieren
```
date -Iseconds
uname -a
# versions/relevante configs sichern
```
Erklärung: Mit einer kurzen Bestandsaufnahme lassen sich spätere Fehler schneller eingrenzen.

2) Kernkonfiguration sauber setzen
```
midclt call pool.dataset.query | head -n 20
midclt call sharing.smb.query | head -n 40
# ACL und SMB-Share im TrueNAS Web-UI setzen
# Snapshot Task auf Dataset-Ebene aktivieren
```
Erklärung: Änderungen gezielt umsetzen, danach direkt den Dienst-/Funktionszustand prüfen.
3) Dienst kontrolliert neu laden
```
sudo systemctl daemon-reload
sudo systemctl restart 
sudo systemctl status  --no-pager
```
4) Betriebsgrenzen testen
```
smbstatus
testparm -s
zfs list -t snapshot | tail -n 20
zpool status -x
```
Validierung / Checks
```
systemctl status smbd --no-pager
midclt call sharing.smb.query | sed -n "1,120p"
getfacl /mnt/POOL/DATASET | head -n 40
```
Troubleshooting
Konfiguration wird nicht übernommen
Ursache: Syntax-, Reload- oder Parameterfehler.
```
getfacl /mnt/POOL/DATASET
midclt call user.query | head -n 80
midclt call group.query | head -n 80
```
Dienst läuft, Funktion aber fehlerhaft
Ursache: Abhängigkeiten, Routing oder Berechtigungen sind inkonsistent.
```
zfs list -t snapshot -o name,creation | tail -n 30
# Rollback nur im Wartungsfenster durchführen
```
Fazit
Mit einem klaren Ablauf für TrueNAS SMB Shares sicher aufsetzen reduzierst du Ausfälle und erhöhst die Wartbarkeit deutlich. Der wichtigste Hebel ist die Kombination aus kleiner Änderung, sofortigem Check und dokumentiertem Ergebnis.
Nächster Schritt: den Ablauf als monatliche Betriebsroutine einplanen und regelmäßig gegen echte Störfälle testen.

Quellen
16.02.2026
Proxmox Storage sauber planen: ZFS, LVM-Thin und Backup-Ziele
Schwierigkeit: Mittel · Dauer: 35–65 Min · Ziel: Proxmox Storage sauber planen: ZFS, LVM-Thin und Backup-Ziele

Kurzproblem und Zielbild
In vielen Homelabs funktioniert die Erstinstallation, aber der Dauerbetrieb wird schnell unübersichtlich. Dieses Tutorial zeigt einen reproduzierbaren Ablauf für Proxmox Storage sauber planen mit Fokus auf Stabilität, klare Checks und einfache Fehlerbehebung.
Ziel ist ein Setup, das nicht nur heute läuft, sondern auch nach Updates und Änderungen beherrschbar bleibt.

Voraussetzungen
- Aktuelles Debian/Ubuntu oder kompatible Appliance
- Administrative Rechte und Wartungsfenster
- Backup- oder Snapshot-Möglichkeit vor Änderungen
Schnellstart (funktionierende Basis)
```
# Basisprüfung
hostnamectl
ip a
# Dienste prüfen
systemctl --failed
# Logs kurz prüfen
journalctl -p 3 -xb --no-pager | tail -n 30
```
Was macht das? Du prüfst erst den Grundzustand und vermeidest, dass Altfehler in neue Änderungen hineinwirken.

Schritt-für-Schritt Umsetzung

1) Ausgangszustand dokumentieren
```
date -Iseconds
uname -a
# versions/relevante configs sichern
```
Erklärung: Mit einer kurzen Bestandsaufnahme lassen sich spätere Fehler schneller eingrenzen.

2) Kernkonfiguration sauber setzen
```
pvesm status
zpool list
lsblk -f
sudo pvesm add dir local-backup --path /srv/proxmox-backups --content backup
pvesm status
```
Erklärung: Änderungen gezielt umsetzen, danach direkt den Dienst-/Funktionszustand prüfen.
3) Dienst kontrolliert neu laden
```
sudo systemctl daemon-reload
sudo systemctl restart 
sudo systemctl status  --no-pager
```
4) Betriebsgrenzen testen
```
pvesm status
zpool status -x
lvs -a -o+seg_monitor
```
Validierung / Checks
```
pvesm status
pvesh get /nodes/$(hostname)/storage --output-format yaml
zpool list -v
vgs; lvs -a
```
Troubleshooting
Konfiguration wird nicht übernommen
Ursache: Syntax-, Reload- oder Parameterfehler.
```
grep -n . /etc/pve/storage.cfg
pvesm status
systemctl restart pvedaemon pveproxy
```
Dienst läuft, Funktion aber fehlerhaft
Ursache: Abhängigkeiten, Routing oder Berechtigungen sind inkonsistent.
```
lvs -a -o lv_name,lv_size,data_percent,metadata_percent
pvesm list local-backup | head -n 40
```
Fazit
Mit einem klaren Ablauf für Proxmox Storage sauber planen reduzierst du Ausfälle und erhöhst die Wartbarkeit deutlich. Der wichtigste Hebel ist die Kombination aus kleiner Änderung, sofortigem Check und dokumentiertem Ergebnis.
Nächster Schritt: den Ablauf als monatliche Betriebsroutine einplanen und regelmäßig gegen echte Störfälle testen.

Quellen
16.02.2026
Proxmox Backup richtig prüfen: Restore-Tests statt Backup-Illusion
Schwierigkeit: Mittel · Dauer: 40–70 Min · Ziel: Proxmox-Backups regelmäßig verifizieren und Restore-Pfade praktisch testen.

Kurzproblem und Zielbild
Backups ohne Restore-Test geben trügerische Sicherheit. Ziel ist ein kurzer, reproduzierbarer Prüfprozess mit klaren Kriterien: Backup vorhanden, konsistent, in vertretbarer Zeit wiederherstellbar.

Voraussetzungen
- Proxmox VE + Backup-Storage/PBS
- Mindestens eine VM/CT für Test-Restore
- Wartungsfenster
Schnellstart (funktionierende Basis)
```
vzdump --all 1 --mode snapshot --compress zstd --storage <STORAGE>
pvesm status
qm list
pct list
```
Schritt-für-Schritt Umsetzung

1) Backup-Jobs und Logs prüfen
```
grep -R "vzdump" /etc/pve/jobs.cfg
journalctl -u pvedaemon -n 200 --no-pager
```
2) Test-VM wiederherstellen
```
qmrestore /path/to/backup.vma.zst 9001 --storage <TARGET>
qm start 9001
```
3) Funktions-Check
```
qm status 9001
# optional: service checks in restored VM
```
4) Ergebnis dokumentieren
```
echo "$(date -Iseconds) restore test OK" >> /root/restore-tests.log
```
Validierung / Checks
```
pvesm status
qm status 9001
ls -lh /var/log/ | head
```
Troubleshooting
Restore bricht mit Storage-Fehler ab
```
pvesm status
# Storage online/space prüfen
```
VM bootet nach Restore nicht
```
qm config 9001
qm terminal 9001
```
Fazit
Restore-Tests machen aus Backups einen verlässlichen Betriebsprozess. Nächster Schritt: monatlichen Restore-Drill fix im Kalender verankern.

Quellen
16.02.2026