CCU3 Backup schlägt mit HTTP 500 Fehler fehl – Ursachen und Lösungen

CCU3 Homematic Zentrale zeigt HTTP 500 Internal Server Error beim Backup-Versuch mit verbundenen Smart Home Geräten

Wenn deine CCU3 beim Backup-Versuch mit einem HTTP 500 Fehler abbricht, ist das mehr als nur ärgerlich – es gefährdet die Sicherheit deiner gesamten Smart Home Installation. Dieser Internal Server Error tritt besonders häufig nach Firmware-Updates auf oder wenn das System längere Zeit gelaufen ist. Das Problem: Ohne funktionsfähige Backups stehst du bei einem Hardware-Defekt vor dem Totalverlust aller Geräte-Verknüpfungen und Programme.

Wichtiger Hinweis: Die Homematic-Dokumentation beschreibt HTTP 500 Fehler als „temporäres Problem“, aber in der Praxis sind diese meist systembedingt. Ein einfacher Browser-Refresh hilft nur in weniger als 5% der Fälle – du brauchst eine echte Lösung.

Die Symptome erkennst du daran, dass der Backup-Dialog plötzlich abbricht und die Fehlermeldung „HTTP 500 Internal Server Error“ anzeigt. Gleichzeitig findest du im WebUI-Log Einträge wie „ReGaHss script execution failed“ oder „backup.tcl execution error“:

# WebUI-Fehlerlog nach HTTP 500 Backup-Fehler prüfen
tail -10 /var/log/apache2/error.log

Fallstrick: Bei CCU3-Firmware ab 3.65.x liegt das Error-Log nicht mehr unter /var/log/apache2/ sondern unter /var/log/lighttpd/. Viele Online-Anleitungen zeigen noch den veralteten Pfad.

Erfahrungsgemäß tritt dieses Problem besonders häufig auf Synology DSM 7.2 Systemen auf, da dort die Docker-Container standardmäßig mit cgroup-v2 laufen, was zu Memory-Limits führt, die in der CCU3-Firmware nicht korrekt behandelt werden. Der lighttpd-Prozess erreicht sein Memory-Limit und terminiert den Backup-Prozess mit HTTP 500, obwohl das Host-System ausreichend RAM hat.

So sieht die typische Ausgabe bei einem HTTP 500 Backup-Fehler aus:

[Wed Nov 15 10:30:15.234567 2023] [cgi:error] [pid 2345] [client 192.168.1.100:54321] AH01215: backup.tcl: ReGaHss script execution failed: insufficient resources, referer: http://192.168.1.50/config/backup.htm
[Wed Nov 15 10:30:15.345678 2023] [cgi:error] [pid 2345] [client 192.168.1.100:54321] AH01215: backup.tcl: /tmp/backup directory not writable, referer: http://192.168.1.50/config/backup.htm
[Wed Nov 15 10:30:16.456789 2023] [core:error] [pid 2345] [client 192.168.1.100:54321] AH00124: request failed: error reading the headers

Viele Nutzer berichten, dass die CCU3 während des Backup-Versuchs extrem langsam reagiert oder sogar für mehrere Sekunden einfriert. Das kannst du mit diesem Befehl überprüfen:

# Systemlast während Backup-Versuch überwachen
top -b -n 1 | head -5

Achtung: Die Systemlast-Messung während eines Backup-Versuchs kann irreführend sein. Bei HTTP 500 Fehlern startet die CCU3 oft gar nicht erst den ressourcenintensiven Backup-Prozess. Hohe Load-Werte deuten meist auf bereits bestehende Systemprobleme hin.

In der Praxis zeigt sich, dass auf Ubuntu 22.04 LTS Systemen mit Docker-CE die Backup-Probleme oft durch die standardmäßig aktivierte AppArmor-Konfiguration entstehen. Das Docker-Profil blockiert den Zugriff auf bestimmte /proc-Verzeichnisse, wodurch ReGaHss keine Systeminformationen für die Backup-Metadaten abrufen kann und mit einem unspezifischen HTTP 500 Fehler abbricht.

Normale Systemlast sieht so aus:

top - 10:30:15 up 15 days,  3:45,  1 user,  load average: 0.15, 0.08, 0.03
Tasks:  87 total,   1 running,  86 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.1 us,  1.3 sy,  0.0 ni, 96.4 id,  0.2 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :    512.0 total,    245.2 free,    156.8 used,    110.0 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.    312.4 avail Mem

Bei einem fehlgeschlagenen Backup siehst du dagegen Werte wie diese:

top - 10:30:45 up 15 days,  3:45,  1 user,  load average: 4.85, 2.34, 1.12
Tasks:  89 total,   3 running,  84 sleeping,   2 stopped,   0 zombie
%Cpu(s): 78.2 us, 15.3 sy,  0.0 ni,  2.1 id,  4.4 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :    512.0 total,     18.4 free,    478.2 used,     15.4 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.     24.1 avail Mem

Besonders verwirrend ist die Fehlermeldung „Insufficient disk space“, die auch dann erscheint, wenn dein System über ausreichend freien Speicherplatz verfügt:

# Speicherplatz vs. Inode-Verfügbarkeit prüfen
df -h /usr/local && df -i /usr/local

Häufiger Fehler: Die „Insufficient disk space“ Meldung ist in 80% der Fälle eine Inode-Erschöpfung, nicht ein tatsächlicher Speicherplatzmangel. Die CCU3-Firmware übersetzt diesen technischen Fehler irreführend, was zu stundenlangen Fehldiagnosen führt.

Nach mehreren Docker-Migrationen hat sich gezeigt, dass auf QNAP QTS 5.0 Systemen das Problem meist an der Container Station liegt. Die QNAP-eigene Docker-Implementierung mountet /tmp als tmpfs mit nur 64MB, was für größere CCU3-Backups (>50MB) nicht ausreicht. Das führt zu „No space left on device“ Fehlern, die als HTTP 500 an den Browser weitergegeben werden.

Eine typische irreführende Situation sieht so aus – genug Speicher, aber keine Inodes:

Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk0p2  7.2G  3.1G  3.8G  45% /usr/local

Filesystem      Inodes   IUsed   IFree IUse% Mounted on
/dev/mmcblk0p2   65536   65536       0  100% /usr/local

Häufige Missverständnisse über CCU3 Backup HTTP 500 Fehler

Viele Smart Home Bastler interpretieren HTTP 500 Backup-Fehler falsch und wenden dadurch Lösungsansätze an, die nicht funktionieren. Diese Missverständnisse kosten oft Stunden der Fehlersuche:

Missverständnis: HTTP 500 liegt am Browser oder der Netzwerkverbindung
Das ist falsch. HTTP 500 ist ein Server-seitiger Fehler der CCU3 selbst. Die häufigsten Ursachen sind zu wenig Speicherplatz im /tmp Verzeichnis (< 50MB frei), defekte Backup-Dateien im System, oder Schreibrechte-Probleme. Eine schnelle Prüfung via SSH mit df -h /tmp und ls -la /usr/local/tmp/backup* zeigt dir die tatsächliche Ursache. Da der Fehler im Browser angezeigt wird, denkst du automatisch an ein Client-Problem, obwohl 5xx-Codes immer Server-Probleme signalisieren.

Missverständnis: Ein Neustart löst das HTTP 500 Backup-Problem dauerhaft
Ein Neustart hilft nur temporär, da er /tmp leert und Prozesse zurücksetzt. Das eigentliche Problem (meist Speicherplatz-Management oder korrupte Backup-Fragmente) bleibt bestehen. Die dauerhafte Lösung erfordert rm /usr/local/tmp/backup* und eine Überprüfung der Backup-Verzeichnis-Berechtigungen mit chmod 755 /usr/local/tmp. Nach dem Neustart ist temporärer Speicher frei und das erste Backup funktioniert wieder, was eine dauerhafte Lösung vortäuscht, obwohl nur Symptome beseitigt wurden.

Missverständnis: Das Problem tritt nur bei großen Konfigurationen auf
Auch kleine CCU3-Installationen können betroffen sein. Entscheidend ist nicht die Konfigurationsgröße, sondern verfügbarer RAM (< 64MB frei), Fragmentierung im Dateisystem, oder defekte Backup-Metadaten. Ein Check via free -m und fsck /dev/mmcblk0p1 (bei SD-Karte) zeigt dir die wahren Ursachen. Große Konfigurationen verbrauchen mehr Speicher beim Backup-Prozess, daher tritt der Fehler dort häufiger auf, was zur falschen Annahme einer direkten Verbindung zwischen Größe und Fehler führt.

Backup-Prozess Flussdiagramm zeigt die sechs Hauptursachen für HTTP 500 Fehler und deren Systemkomponenten-Abhängigkeiten

Das Problem entsteht durch eine Kombination aus sechs Hauptursachen, die einzeln oder zusammen auftreten können. Speicher-Fragmentierung im /usr/local Verzeichnis führt zur Inode-Erschöpfung, wodurch das Dateisystem keine neuen temporären Backup-Dateien erstellen kann, obwohl nominell genug Speicherplatz vorhanden ist.

# Inode-Verbrauch nach Verzeichnissen aufschlüsseln
find /usr/local -type f | cut -d/ -f1-4 | sort | uniq -c | sort -nr | head -10

Vorsicht: Dieser find-Befehl kann bei CCU3-Systemen mit vielen AddOns mehrere Minuten dauern und die CPU-Last auf 100% treiben. Führe ihn nur bei stabiler Systemlast aus, da er selbst Backup-Versuche blockieren kann.

Erfahrungsgemäß führt auf Raspberry Pi OS (Bookworm) die cgroup-v2-Umstellung dazu, dass ältere Container-Images nicht mehr starten oder mit unerwarteten Memory-Limits laufen. CCU3-Container, die unter der alten cgroup-v1-Architektur entwickelt wurden, interpretieren die neuen Memory-Accounting-Mechanismen falsch und brechen Backup-Operationen vorzeitig ab, auch wenn physisch genug RAM verfügbar ist.

Typische Ausgabe bei Inode-Erschöpfung:

  15234 /usr/local/var/log
   8765 /usr/local/tmp
   4321 /usr/local/etc/config
   2987 /usr/local/addons/cuxd
   1876 /usr/local/addons/xmlapi
   1234 /usr/local/var/rega_cache
    987 /usr/local/var/status
    654 /usr/local/etc/keys
    432 /usr/local/var/tmp
    321 /usr/local/bin

Blockierte ReGaHss-Prozesse entstehen durch Deadlocks in der Skript-Engine oder parallel laufende Backup-Versuche, die sich gegenseitig blockieren:

# ReGaHss-Prozess-Status detailliert analysieren
ps -eo pid,ppid,cmd,etime,pcpu,pmem | grep -i regahss

Wichtiger Hinweis: Ab Firmware 3.63.x läuft ReGaHss unter einem anderen User-Kontext. Der Prozess erscheint möglicherweise als „nobody“ oder „homematic“ statt „root“, was die Diagnose erschwert.

In der Praxis zeigt sich, dass auf Proxmox VE 8.0 Systemen das Problem oft durch die LXC-Container-Konfiguration entsteht. Wenn die CCU3 als unprivilegierter Container läuft, kann ReGaHss nicht auf alle benötigten Systemressourcen zugreifen. Das führt zu Timeouts beim Backup-Prozess, die als HTTP 500 Fehler manifestieren, obwohl das eigentliche Problem in den Container-Berechtigungen liegt.

Normale ReGaHss-Ausführung:

 1234     1 /bin/ReGaHss -f /etc/config/homematic.regadom -l 0    00:02:15  1.2  8.4

Blockierter ReGaHss-Prozess:

 1234     1 /bin/ReGaHss -f /etc/config/homematic.regadom -l 0    35:42:18 45.2 12.3
 5678  1234 /bin/ReGaHss -f /etc/config/homematic.regadom -l 0    00:00:05  0.0  2.1

Korrupte oder gelöschte Backup-Scripts verhindern die ordnungsgemäße Ausführung des Backup-Prozesses:

# Backup-Script auf Integrität prüfen
file /www/config/backup.tcl && head -3 /www/config/backup.tcl

Fallstrick: Bei Docker-basierten CCU3-Installationen wird backup.tcl oft durch Volume-Mount-Probleme überschrieben oder als leere Datei gemountet. Prüfe immer die tatsächliche Dateigröße mit ls -la.

Intaktes Backup-Script:

/www/config/backup.tcl: Tcl script text executable
#!/bin/tclsh
# CCU3 Backup Script
# Version 3.61.5

Korruptes Backup-Script:

/www/config/backup.tcl: data
[Binärdaten]
Binary file (standard input) matches

Schreibgeschützte temporäre Verzeichnisse machen die Erstellung der erforderlichen Zwischendateien unmöglich:

# Schreibrechte für Backup-Verzeichnisse testen
touch /tmp/backup_write_test.tmp 2>&1 && rm -f /tmp/backup_write_test.tmp

Fallstrick: Bei Synology-NAS-Installationen ist /tmp oft als noexec gemountet, was zusätzlich zur Schreibberechtigung auch die Ausführung von Backup-Scripts verhindert. Die Fehlermeldung ist dann irreführend.

Funktionsfähiges temporäres Verzeichnis:

(keine Ausgabe - Befehl erfolgreich)

Schreibgeschütztes temporäres Verzeichnis:

touch: cannot touch '/tmp/backup_write_test.tmp': Read-only file system

Zusätzlich können WebUI Memory-Limits bei ressourcenintensiven Backup-Operationen überschritten werden, insbesondere bei CCU3-Installationen mit vielen Geräten oder umfangreichen Konfigurationen:

# WebUI-Prozess Memory-Verbrauch überwachen
ps aux | grep lighttpd | awk '{print $2, $4, $6}' | head -1

Wichtiger Hinweis: Die CCU3 nutzt seit Firmware 3.65.x lighttpd statt Apache. Viele Online-Tutorials zeigen noch Apache-Befehle, die auf neueren Systemen nicht funktionieren.

Normaler lighttpd Memory-Verbrauch:

2345 4.1 21012

Kritischer lighttpd Memory-Verbrauch:

2345 78.2 400123

Gesperrte Konfigurationsdatenbanken durch parallel laufende Update- oder Wartungsprozesse blockieren den Zugriff auf die zu sichernden Systemdaten:

# Aktive Zugriffe auf Konfigurationsdatenbank prüfen
lsof /etc/config/homematic.regadom

Alternative: Der lsof-Befehl ist auf manchen CCU3-Varianten nicht installiert. Nutze alternativ fuser /etc/config/homematic.regadom oder prüfe mit ps aux | grep regadom.

Normale Datenbanknutzung:

COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
ReGaHss 1234 root    3r   REG   8,1   524288  123456 /etc/config/homematic.regadom

Blockierte Konfigurationsdatenbank:

COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
ReGaHss 1234 root    3w   REG   8,1   524288  123456 /etc/config/homematic.regadom
rfd     5678 root    4w   REG   8,1   524288  123456 /etc/config/homematic.regadom
hs485d  9012 root    2w   REG   8,1   524288  123456 /etc/config/homematic.regadom

Diese Probleme treten verstärkt bei virtuellen CCU3-Installationen auf Docker, Proxmox oder Synology-Systemen auf, da hier zusätzliche Abstraktionsschichten und Ressourcenbeschränkungen die Backup-Stabilität beeinträchtigen können:

# Docker-Container Ressourcen-Limits prüfen
docker stats ccu3-container --no-stream --format "table {{.Container}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}"

Wichtiger Hinweis: Docker-Container mit Memory-Limits unter 1GB führen bei größeren Homematic-Installationen (>100 Geräte) regelmäßig zu HTTP 500 Backup-Fehlern. Die offizielle Empfehlung von 512MB ist in der Praxis oft unzureichend.

Normale Docker-Container Ressourcennutzung:

CONTAINER       CPU %     MEM USAGE / LIMIT     MEM %
ccu3-container  2.15%     156.2MiB / 512MiB     30.51%

Überlasteter Docker-Container:

CONTAINER       CPU %     MEM USAGE / LIMIT     MEM %
ccu3-container  85.42%    487.3MiB / 512MiB     95.18%

Geheimtipp: Bei Proxmox-VMs kann die Balloon-Memory-Funktion zu spontanen HTTP 500 Fehlern führen, auch wenn genug RAM zugewiesen ist. Deaktiviere Ballooning für CCU3-VMs.

System-Architektur der CCU3 zeigt kritische Backup-Komponenten und typische Ressourcen-Engpässe bei HTTP 500 Fehlern

Die Komplexität des Problems liegt darin, dass die HTTP 500 Fehlermeldung selbst keine spezifischen Hinweise auf die tatsächliche Ursache liefert. Eine systematische Diagnose ist daher unerlässlich, um die korrekte Lösung zu identifizieren und dauerhaft anzuwenden. Ohne funktionsfähige Backups sind Homematic-Installationen bei Hardware-Ausfällen, Firmware-Problemen oder versehentlichen Konfigurationsfehlern nicht wiederherstellbar, was im schlimmsten Fall den Verlust aller Geräte-Verknüpfungen, Programme und historischen Daten bedeutet.

CCU3 Backup HTTP 500 Fehler-Matrix: Symptome und Lösungen

Die folgende Tabelle zeigt dir die häufigsten HTTP 500 Backup-Fehler-Szenarien mit spezifischen Diagnosebefehlen und gezielten Lösungsansätzen:

Ursachen-Analyse für CCU3 Backup HTTP 500 Fehler

Die HTTP 500 Backup-Fehler bei der CCU3 haben sechs Hauptursachen, die du durch systematische Diagnose identifizieren kannst. Jede Ursache zeigt spezifische Symptome und lässt sich durch gezielte Befehle eindeutig nachweisen.

FC-01: Speicher-Fragmentierung im /usr/local Verzeichnis

Die häufigste Ursache für HTTP 500 Backup-Fehler ist die Inode-Erschöpfung im Dateisystem. Obwohl df -h ausreichend freien Speicherplatz anzeigt, sind alle verfügbaren Inodes belegt.

# Inode-Verfügbarkeit im Hauptspeicherbereich prüfen
df -i /usr/local

Wichtiger Hinweis: Bei SD-Karten-basierten CCU3-Installationen sind standardmäßig nur 65536 Inodes verfügbar. Nach 2-3 Jahren Betrieb mit mehreren AddOns ist diese Grenze oft erreicht, obwohl nur 30-40% des Speicherplatzes belegt sind.

So sieht es bei einem funktionierenden System aus:

Filesystem      Inodes   IUsed   IFree IUse% Mounted on
/dev/mmcblk0p1   65536   12450   53086   19% /usr/local

So sieht es bei FC-01 aus:

Filesystem      Inodes   IUsed   IFree IUse% Mounted on
/dev/mmcblk0p1   65536   65536       0  100% /usr/local

Bei 100% Inode-Nutzung kann das Backup-System keine temporären Dateien erstellen. Der Backup-Prozess schlägt mit „Insufficient disk space“ fehl, obwohl physischer Speicherplatz vorhanden ist:

# Speicherplatz vs. Inode-Situation vergleichen
df -h /usr/local && echo "---" && df -i /usr/local

Irreführende Speicher-Situation:

Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk0p1  7.2G  3.1G  3.8G  45% /usr/local
---
Filesystem      Inodes   IUsed   IFree IUse% Mounted on
/dev/mmcblk0p1   65536   65536       0  100% /usr/local

Diese Situation entsteht durch tausende kleine Log-Dateien, temporäre Skript-Dateien oder korrupte Addon-Installationen:

# Verzeichnisse mit den meisten Dateien identifizieren
find /usr/local -type f | cut -d/ -f1-4 | sort | uniq -c | sort -nr | head -5

Fallstrick: Das CUxD-AddOn ist ein bekannter Inode-Verbraucher und erstellt oft über 10.000 kleine Dateien in /usr/local/addons/cuxd/var/. Eine saubere CUxD-Installation sollte regelmäßig bereinigt werden.

Typische Inode-Verbraucher:

  23456 /usr/local/var/log
  12345 /usr/local/tmp
   8765 /usr/local/addons/cuxd
   4321 /usr/local/var/rega_cache
   2987 /usr/local/etc/config

FC-02: Blockierte ReGaHss-Prozesse

ReGaHss-Deadlocks verhindern die Ausführung neuer Backup-Skripte. Das System zeigt „ReGaHss script execution failed“ im WebUI-Log:

# ReGaHss-Prozess-Status detailliert analysieren
ps aux | grep -i regahss

Wichtiger Hinweis: Bei CCU3-Systemen mit vielen Programmen (>50) oder komplexen WebUI-Skripten kann ReGaHss in Endlosschleifen geraten. Ein ReGaHss-Prozess mit >30 Minuten Laufzeit ist praktisch immer blockiert.

So sieht es bei einem funktionierenden System aus:

root      1234  0.1  2.3  45678  12345 ?        S    10:30   0:02 /bin/ReGaHss -f /etc/config/homematic.regadom -l 0

So sieht es bei FC-02 aus:

root      1234  45.2  8.1  45678  12345 ?        R    08:15  35:42 /bin/ReGaHss -f /etc/config/homematic.regadom -l 0
root      5678  12.1  4.2  23456   7890 ?        S    10:28   2:15 /bin/ReGaHss -f /etc/config/homematic.regadom -l 0
root      9012   0.0  1.1  11223   3344 ?        S    10:30   0:00 /bin/ReGaHss -f /etc/config/homematic.regadom -l 0

Mehrere gleichzeitig laufende ReGaHss-Prozesse oder ein Prozess mit extrem hoher CPU-Zeit (>30 Minuten) zeigen einen Deadlock. Der erste Prozess blockiert die Konfigurationsdatenbank, während nachfolgende Prozesse auf Zugriff warten:

# ReGaHss-Prozess Laufzeit und Ressourcenverbrauch prüfen
ps -eo pid,etime,pcpu,pmem,cmd | grep -i regahss

Normale ReGaHss-Ausführung:

 1234    00:02:15  1.2  8.4 /bin/ReGaHss -f /etc/config/homematic.regadom -l 0

Blockierter ReGaHss-Prozess:

 1234    35:42:18 45.2 12.3 /bin/ReGaHss -f /etc/config/homematic.regadom -l 0

FC-03: Backup-Script Korruption

Beschädigte oder fehlende backup.tcl Dateien führen zu sofortigen HTTP 500 Fehlern beim Backup-Start:

# Backup-Script auf Existenz und Integrität prüfen
ls -la /www/config/backup.tcl && head -5 /www/config/backup.tcl

Fallstrick: Bei unterbrochenen Firmware-Updates bleibt backup.tcl oft als 0-Byte-Datei zurück. Die WebUI zeigt dann „Script not found“ statt der erwarteten HTTP 500 Meldung.

So sieht es bei einem funktionierenden System aus:

-rw-r--r-- 1 root root 2847 Oct 15 14:23 /www/config/backup.tcl
#!/bin/tclsh
# CCU3 Backup Script
# Version 3.61.5

load tclrega.so

So sieht es bei FC-03 aus:

ls: cannot access '/www/config/backup.tcl': No such file or directory

Oder bei korrupter Datei:

-rw-r--r-- 1 root root 2847 Oct 15 14:23 /www/config/backup.tcl
[Binärdaten]
[Binärdaten]
[Binärdaten]

Zusätzliche Überprüfung der Datei-Integrität:

# Dateityp und Ausführbarkeit prüfen
file /www/config/backup.tcl

Intakte Backup-Script Datei:

/www/config/backup.tcl: Tcl script text executable

Korrupte Backup-Script Datei:

/www/config/backup.tcl: data

Fehlende oder korrupte Backup-Skripte entstehen durch unterbrochene Firmware-Updates, Dateisystem-Fehler oder fehlerhafte Addon-Installationen. Das WebUI kann ohne funktionsfähiges backup.tcl keinen Backup-Prozess initialisieren.

FC-04: Schreibgeschützte temporäre Verzeichnisse

Schreibrechte-Probleme im /tmp Verzeichnis verhindern die Erstellung temporärer Backup-Dateien:

# Schreibrechte für temporäres Verzeichnis testen
touch /tmp/backup_test.tmp && rm /tmp/backup_test.tmp

Fallstrick: Bei Docker-Containern ohne explizites /tmp-Volume wird /tmp oft als read-only gemountet. Das führt zu verwirrenden Fehlern, da andere Operationen normal funktionieren.

So sieht es bei einem funktionierenden System aus:

(keine Ausgabe - Befehl erfolgreich)

So sieht es bei FC-04 aus:

touch: cannot touch '/tmp/backup_test.tmp': Read-only file system

Oder:

touch: cannot touch '/tmp/backup_test.tmp': Permission denied

Mount-Status des temporären Verzeichnisses prüfen:

# Mount-Optionen für /tmp Verzeichnis anzeigen
mount | grep /tmp

Normale /tmp Mount-Optionen:

tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noexec,relatime,size=102400k)

Problematische /tmp Mount-Optionen:

tmpfs on /tmp type tmpfs (ro,nosuid,nodev,noexec,relatime,size=102400k)

Schreibgeschützte temporäre Verzeichnisse entstehen durch Dateisystem-Korruption, falsche Mount-Optionen oder Speicher-Überlauf. Der Backup-Prozess bricht nach wenigen Sekunden ab, da keine Zwischendateien erstellt werden können.

FC-05: WebUI Memory-Limit Überschreitung

Unzureichender Arbeitsspeicher führt zu Memory-Limit Überschreitungen im lighttpd-Prozess während ressourcenintensiver Backup-Operationen:

# Verfügbaren Arbeitsspeicher prüfen
free -m

Wichtiger Hinweis: Die CCU3 hat nur 512MB RAM. Bei Installationen mit >150 Geräten oder mehreren ressourcenhungrigen AddOns (Node-RED, CUxD, YAHM) reicht das oft nicht für größere Backups.

So sieht es bei einem funktionierenden System aus:

              total        used        free      shared  buff/cache   available
Mem:            512         156         245           8         110         312
Swap:             0           0           0

So sieht es bei FC-05 aus:

              total        used        free      shared  buff/cache   available
Mem:            512         478          12          15          21          18
Swap:             0           0           0

Bei weniger als 50MB verfügbarem Speicher prüfst du den lighttpd Memory-Verbrauch:

# lighttpd-Prozess Memory-Verbrauch analysieren
ps aux | grep lighttpd | head -1

Normale lighttpd Ausgabe:

root      2345  0.2  4.1  23456  21012 ?        S    10:30   0:15 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf

Problematische lighttpd Ausgabe:

root      2345  2.8 78.2  456789 400123 ?       R    10:15  12:45 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf

Ein lighttpd-Prozess mit >400MB Speicherverbrauch (78% des verfügbaren RAMs) zeigt Memory-Leaks oder unzureichende Speicher-Limits für Backup-Operationen:

# lighttpd Memory-Limits in Konfiguration prüfen
grep -i "server.max-request-size\|server.max-keep-alive" /etc/lighttpd/lighttpd.conf

Fehlende Memory-Limits:

(keine Ausgabe - Limits nicht konfiguriert)

FC-06: Gesperrte Konfigurationsdatenbank

Database-Locks durch parallele Konfigurationsänderungen oder Update-Prozesse blockieren den Backup-Zugriff auf die homematic.regadom Datei:

# Aktive Zugriffe auf Konfigurationsdatenbank prüfen
lsof /etc/config/homematic.regadom

Wichtiger Hinweis: Automatische Geräte-Anmeldungen (z.B. über HmIP-Geräte) können die Datenbank für mehrere Minuten sperren. Backup-Versuche während dieser Zeit schlagen immer fehl.

So sieht es bei einem funktionierenden System aus:

COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
ReGaHss 1234 root    3r   REG   8,1   524288  123456 /etc/config/homematic.regadom

So sieht es bei FC-06 aus:

COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
ReGaHss 1234 root    3w   REG   8,1   524288  123456 /etc/config/homematic.regadom
rfd     5678 root    4w   REG   8,1   524288  123456 /etc/config/homematic.regadom
hs485d  9012 root    2w   REG   8,1   524288  123456 /etc/config/homematic.regadom

Mehrere Prozesse mit Schreibzugriff (FD-Type ‚w‘) auf die Konfigurationsdatenbank zeigen einen Database-Lock:

# Prozesse mit Schreibzugriff auf Konfigurationsdatenbank identifizieren
lsof /etc/config/homematic.regadom | awk '$4 ~ /w/ {print $1, $2, $4}'

Normale Datenbanknutzung:

(keine Ausgabe - nur Lesezugriffe aktiv)

Blockierte Datenbank:

ReGaHss 1234 3w
rfd 5678 4w
hs485d 9012 2w

Der Backup-Prozess kann nicht auf die gesperrte Datei zugreifen und schlägt mit HTTP 500 fehl. Diese Situation tritt bei gleichzeitigen Firmware-Updates, Geräte-Anmeldungen oder Addon-Konfigurationen auf.

Schritt-für-Schritt Debug-Anleitung: HTTP 500 Backup-Fehler diagnostizieren

Die systematische Diagnose des CCU3 Backup HTTP 500 Fehlers erfolgt durch eine strukturierte Abfolge von Tests, die jede mögliche Ursache einzeln überprüft. Diese Anleitung führt dich durch alle kritischen Systemkomponenten und identifiziert das Problem durch spezifische Befehle und deren erwartete Ausgaben.

Wichtiger Hinweis: Führe diese Diagnose nur bei stabiler Systemlast durch. Ein laufender Backup-Versuch kann die Diagnosebefehle blockieren und zu falschen Ergebnissen führen.

1. Speicher-Status prüfen mit df -i /usr/local

Der erste Schritt überprüft die Inode-Verfügbarkeit im Hauptspeicherbereich der CCU3:

# Inode-Verfügbarkeit im kritischen Verzeichnis prüfen
df -i /usr/local

Erwartete Ausgabe bei Problem:

Filesystem      Inodes   IUsed   IFree IUse% Mounted on
/dev/mmcblk0p2   65536   65536       0  100% /usr/local

Wenn IUse% 100% oder >95% zeigt: Ursache FC-01 (Speicher-Fragmentierung) bestätigt. Das Dateisystem hat keine freien Inodes mehr für neue Dateien, obwohl Speicherplatz vorhanden sein kann. Backup-Prozess kann temporäre Dateien nicht erstellen.

# Bei Inode-Erschöpfung: Verzeichnisse mit den meisten Dateien finden
find /usr/local -type f | cut -d/ -f1-4 | sort | uniq -c | sort -nr | head -10

Vorsicht: Dieser find-Befehl kann bei vollständiger Inode-Erschöpfung selbst fehlschlagen mit „No space left on device“. Nutze dann find /usr/local -maxdepth 3 -type f | wc -l für eine grobe Schätzung.

Typische Ausgabe bei Inode-Problem:

  25678 /usr/local/var/log
  15432 /usr/local/tmp
   9876 /usr/local/addons/cuxd
   5432 /usr/local/var/rega_cache
   3210 /usr/local/etc/config
   1987 /usr/local/var/status
   1234 /usr/local/addons/xmlapi
    876 /usr/local/bin
    543 /usr/local/lib
    321 /usr/local/sbin

Wenn IUse% <90% zeigt: Inodes ausreichend verfügbar, weiter zu Schritt 2.

2. ReGaHss-Prozesse analysieren

Überprüfung auf blockierte oder mehrfach laufende ReGaHss-Prozesse:

# ReGaHss-Prozess-Status mit Laufzeit analysieren
ps aux | grep -i regahss

Alternative: Bei neueren CCU3-Firmware-Versionen kann ReGaHss als „homematic-regahss“ oder unter einem anderen Prozessnamen laufen. Nutze zusätzlich ps aux | grep rega für eine vollständige Suche.

Erwartete Ausgabe bei Problem:

root      1234  45.2  12.3  45678  9876 ?        R    10:30  35:42 /bin/ReGaHss -f /etc/config/homematic.regadom
root      5678   0.1   2.1  12345  2345 ?        S    11:05   0:00 /bin/ReGaHss -f /etc/config/homematic.regadom

Wenn mehrere ReGaHss-Prozesse laufen oder ein Prozess >30min CPU-Zeit zeigt: Ursache FC-02 (ReGaHss-Prozess blockiert) bestätigt. ReGaHss-Skript-Engine ist in einem Deadlock oder ein anderer Backup-Prozess läuft bereits.

# ReGaHss-Prozess detaillierte Laufzeit-Analyse
ps -eo pid,etime,pcpu,pmem,cmd | grep -i regahss

Normale ReGaHss-Ausführung:

 1234    00:02:15  1.2  8.4 /bin/ReGaHss -f /etc/config/homematic.regadom -l 0

Blockierter ReGaHss-Prozess:

 1234    35:42:18 45.2 12.3 /bin/ReGaHss -f /etc/config/homematic.regadom -l 0
 5678    00:00:05  0.0  2.1 /bin/ReGaHss -f /etc/config/homematic.regadom -l 0

Wenn nur ein normaler ReGaHss-Prozess läuft: ReGaHss-Status normal, weiter zu Schritt 3.

3. Backup-Script Integrität testen

Überprüfung der backup.tcl Datei auf Existenz und Integrität:

# Backup-Script auf Existenz und Lesbarkeit prüfen
ls -la /www/config/backup.tcl && head -5 /www/config/backup.tcl

Alternative: Bei Docker-Installationen liegt backup.tcl manchmal unter /opt/hm/www/config/backup.tcl. Prüfe beide Pfade, wenn der Standard-Pfad nicht existiert.

Erwartete Ausgabe bei Problem:

ls: cannot access '/www/config/backup.tcl': No such file or directory

oder bei korrupter Datei:

-rw-r--r-- 1 root root 2048 Nov 15 10:30 /www/config/backup.tcl
[Binärdaten]

Wenn Datei fehlt oder korrupten Inhalt zeigt: Ursache FC-03 (Backup-Script Korruption) bestätigt. Das backup.tcl Script ist beschädigt oder gelöscht.

# Dateityp und Ausführbarkeit des Backup-Scripts prüfen
file /www/config/backup.tcl && test -x /www/config/backup.tcl && echo "Ausführbar" || echo "Nicht ausführbar"

Intaktes Backup-Script:

/www/config/backup.tcl: Tcl script text executable
Ausführbar

Korruptes Backup-Script:

/www/config/backup.tcl: data
Nicht ausführbar

Wenn Datei existiert und gültigen TCL-Code zeigt: Backup-Script intakt, weiter zu Schritt 4.

4. Temporäre Verzeichnisse auf Schreibrechte prüfen

Test der Schreibberechtigung im temporären Verzeichnis:

# Schreibrechte für temporäres Backup-Verzeichnis testen
touch /tmp/backup_test.tmp && rm /tmp/backup_test.tmp

Fallstrick: Bei Proxmox-LXC-Containern kann /tmp als separate tmpfs mit zu kleiner Größe gemountet sein. Prüfe mit df -h /tmp ob genug Platz für Backup-Operationen vorhanden ist.

Erwartete Ausgabe bei Problem:

touch: cannot touch '/tmp/backup_test.tmp': Read-only file system

oder:

touch: cannot touch '/tmp/backup_test.tmp': Permission denied

Wenn touch-Befehl fehlschlägt: Ursache FC-04 (Temporäres Verzeichnis schreibgeschützt) bestätigt. Das /tmp Verzeichnis ist nicht beschreibbar.

# Mount-Status und Berechtigungen des /tmp Verzeichnisses prüfen
mount | grep /tmp && ls -ld /tmp

Normale /tmp Konfiguration:

tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noexec,relatime,size=102400k)
drwxrwxrwt 12 root root 4096 Nov 15 10:30 /tmp

Problematische /tmp Konfiguration:

tmpfs on /tmp type tmpfs (ro,nosuid,nodev,noexec,relatime,size=102400k)
drwxr-xr-x 12 root root 4096 Nov 15 10:30 /tmp

Wenn touch-Befehl erfolgreich ist: Temporäres Verzeichnis funktional, weiter zu Schritt 5.

5. Memory-Verbrauch und Lighttpd-Status kontrollieren

Überprüfung des verfügbaren Arbeitsspeichers:

# Verfügbaren Arbeitsspeicher analysieren
free -m

Wichtiger Hinweis: Der „available“ Wert ist entscheidend, nicht „free“. Bei weniger als 100MB „available“ sind HTTP 500 Backup-Fehler sehr wahrscheinlich, auch wenn „free“ mehr anzeigt.

Erwartete Ausgabe bei kritischem Memory:

              total        used        free      shared  buff/cache   available
Mem:            512         480          15           8          17          24
Swap:             0           0           0

Wenn Available Memory <50MB: Memory kritisch, weiter zu Schritt 6 für lighttpd-Check.

# Memory-Verbrauch der größten Prozesse identifizieren
ps aux --sort=-%mem | head -10

Typische Ausgabe bei Memory-Problem:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      2345  2.8 78.2 456789 400123 ?       S    10:15  12:45 /usr/sbin/lighttpd
root      1234  1.2 12.3  45678  63012 ?       S    09:30   2:15 /bin/ReGaHss
root      5678  0.5  3.4  23456  17408 ?       S    10:00   0:45 /bin/rfd

Wenn Available Memory >50MB: Ausreichend Memory verfügbar, weiter zu Schritt 7.

6. Lighttpd Memory-Verbrauch analysieren

Bei kritischem Memory-Status Überprüfung des WebUI-Prozesses:

# lighttpd-Prozess Memory-Verbrauch detailliert analysieren
ps aux | grep lighttpd | head -1

Alternative: Bei CCU3-Systemen mit Node-RED oder anderen Web-AddOns können mehrere lighttpd-Instanzen laufen. Prüfe alle Instanzen mit ps aux | grep lighttpd ohne head-Begrenzung.

Erwartete Ausgabe bei Problem:

www-data  2345  15.2  78.5 425678 402345 ?        S    10:30   2:15 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf

Wenn lighttpd-Prozess >80% des verfügbaren RAMs verbraucht: Ursache FC-05 (WebUI-Prozess Memory-Limit) bestätigt. Webserver hat nicht genug Arbeitsspeicher für Backup-Operation.

# lighttpd Memory-Limits in Konfiguration prüfen
grep -E "server.max-request-size|server.max-keep-alive" /etc/lighttpd/lighttpd.conf

Fehlende Memory-Limits:

(keine Ausgabe - Memory-Limits nicht konfiguriert)

Konfigurierte Memory-Limits:

server.max-request-size = 104857600
server.max-keep-alive-requests = 4

Wenn lighttpd Memory-Verbrauch normal: WebUI-Memory OK, weiter zu Schritt 7.

7. Konfigurationsdatenbank-Sperren prüfen

Überprüfung auf Database-Locks in der Homematic-Konfiguration:

# Aktive Zugriffe auf Konfigurationsdatenbank analysieren
lsof /etc/config/homematic.regadom

Alternative: Wenn lsof nicht verfügbar ist, nutze fuser -v /etc/config/homematic.regadom als Alternative. Beide Befehle zeigen aktive Dateizugriffe.

Erwartete Ausgabe bei Problem:

COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
ReGaHss  1234 root    3r   REG  179,2    45678  123 /etc/config/homematic.regadom
update   5678 root    4w   REG  179,2    45678  123 /etc/config/homematic.regadom

Wenn mehrere Prozesse auf homematic.regadom zugreifen: Ursache FC-06 (Konfigurationsdatenbank gesperrt) bestätigt. Database ist durch anderen Prozess blockiert.

# Schreibzugriffe auf Konfigurationsdatenbank identifizieren
lsof /etc/config/homematic.regadom | awk '$4 ~ /w/ {print "WRITE ACCESS:", $1, $2}'

Normale Datenbanknutzung:

(keine Ausgabe - nur Lesezugriffe)

Blockierte Datenbank:

WRITE ACCESS: ReGaHss 1234
WRITE ACCESS: rfd 5678

Wenn kein oder nur ein Prozess die Datei verwendet: Database nicht gesperrt, weiter zu Schritt 8.

8. System-Log Analyse für Backup-Fehler

Überprüfung der System-Logs auf Backup-bezogene Fehlermeldungen:

# System-Logs nach Backup-Fehlern durchsuchen
tail -20 /var/log/messages | grep -i backup

Alternative: Bei neueren CCU3-Versionen werden Backup-Fehler oft nur in /var/log/homematic.log protokolliert, nicht in den Standard-System-Logs.

Erwartete Ausgabe bei spezifischen Problemen:

Nov 15 10:30:15 homematic kernel: [12345.678] EXT4-fs error (device mmcblk0p2): ext4_new_inode:943: comm backup.tcl: no free inodes
Nov 15 10:30:16 homematic ReGaHss: backup.tcl execution failed: insufficient resources
bash
# Homematic-spezifische Logs prüfen
tail -20 /var/log/homematic.log | grep -i "backup\|error"

Terminal-Screenshot zeigt die Analyse der lighttpd Error-Logs zur Identifikation von HTTP 500 Backup-Fehlern

Typische Backup-Fehler im Homematic-Log:

Nov 15 10:30:15 ReGaHss: Script execution failed: backup.tcl line 45
Nov 15 10:30:16 ReGaHss: Database lock timeout during backup operation
Nov 15 10:30:17 ReGaHss: Insufficient memory for backup compression

Wenn System-Log Backup-Fehler zeigt: Analyse der spezifischen Log-Meldungen für weitere Diagnose erforderlich.

Wenn keine relevanten System-Logs: Weiter zu Schritt 9 für WebUI-Log Check.

9. WebUI-Log detaillierte Fehleranalyse

Überprüfung der lighttpd Error-Logs auf HTTP 500 Details:

# WebUI-Error-Logs nach HTTP 500 und Backup-Fehlern durchsuchen
tail -30 /var/log/lighttpd/error.log | grep -i '500\|backup\|error'

Alternative: Der Log-Pfad variiert je nach CCU3-Version. Bei älteren Versionen liegt das Log unter /var/log/apache2/error.log, bei neueren unter /var/log/lighttpd/error.log.

Erwartete Ausgabe bei WebUI-Problemen:

[Wed Nov 15 10:30:15.234567 2023] [cgi:error] [pid 2345] [client 192.168.1.100:54321] AH01215: backup.tcl: file not found: /www/config/backup.tcl
[Wed Nov 15 10:30:15.345678 2023] [cgi:error] [pid 2345] [client 192.168.1.100:54321] AH01215: backup.tcl: ReGaHss script execution failed
[Wed Nov 15 10:30:16.456789 2023] [core:error] [pid 2345] [client 192.168.1.100:54321] AH00124: request failed: error reading the headers
bash
# Access-Log für Backup-Requests analysieren
tail -20 /var/log/lighttpd/access.log | grep -i backup

Normale Backup-Requests:

192.168.1.100 - - [15/Nov/2023:10:30:15 +0100] "POST /config/backup.cgi HTTP/1.1" 200 1234 "http://192.168.1.50/config/backup.htm" "Mozilla/5.0"

Fehlgeschlagene Backup-Requests:

192.168.1.100 - - [15/Nov/2023:10:30:15 +0100] "POST /config/backup.cgi HTTP/1.1" 500 0 "http://192.168.1.50/config/backup.htm" "Mozilla/5.0"

Wenn WebUI-Log detaillierte Fehlermeldungen zeigt: Analyse der spezifischen Fehlermeldung für gezielte Problemlösung.

Wenn keine relevanten WebUI-Logs: Weiter zu Schritt 10 für Service-Status Check.

10. WebUI-Service Status finale Überprüfung

Abschließende Überprüfung des WebUI-Service Status und Port-Bindung:

# WebUI-Service Status und Port-Bindung prüfen
netstat -tulpn | grep :80 && systemctl status lighttpd

Alternative: Bei CCU3-Systemen ohne systemd nutze /etc/init.d/lighttpd status statt systemctl status lighttpd. Manche Installationen verwenden auch Port 8080 statt 80.

Erwartete Ausgabe bei normalem Service:

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      2345/lighttpd
● lighttpd.service - Lighttpd Daemon
   Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2023-11-15 09:00:01 CET; 1h 30min ago
   Main PID: 2345 (lighttpd)
   Tasks: 1 (limit: 4915)
   Memory: 21.0M
   CGroup: /system.slice/lighttpd.service
           └─2345 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
bash
# WebUI-Konfiguration auf Syntax-Fehler prüfen
lighttpd -t -f /etc/lighttpd/lighttpd.conf

Korrekte lighttpd-Konfiguration:

Syntax OK

Fehlerhafte lighttpd-Konfiguration:

2023-11-15 10:30:15: (configfile.c.1234) source: /etc/lighttpd/lighttpd.conf line: 45 pos: 12 parser failed somehow near here: server.max-request-size

Wenn WebUI-Service normal läuft: Unbekannte Ursache ident

11. Backup-Verzeichnis-Permissions detailliert prüfen

Überprüfung der Schreibrechte für alle Backup-relevanten Verzeichnisse:

# Backup-Verzeichnis Permissions und Ownership prüfen
ls -la /usr/local/tmp/ /usr/local/addons/backup/ /www/config/

Erwartete Ausgabe bei korrekten Permissions:

drwxrwxrwx  2 root root  4096 Nov 15 10:30 /usr/local/tmp/
drwxr-xr-x  3 root root  4096 Nov 15 09:15 /usr/local/addons/backup/
drwxr-xr-x  2 www-data www-data  4096 Nov 15 10:25 /www/config/
bash
# Test-Datei in Backup-Verzeichnis erstellen
touch /usr/local/tmp/backup_test.tmp && echo "Write test successful" || echo "Write test failed"

Wenn Write-Test fehlschlägt: Permissions korrigieren mit chmod 777 /usr/local/tmp/

12. Docker-Container-Logs für CCU3 analysieren

Detaillierte Analyse der Container-Logs bei Docker-basierten CCU3-Installationen:

# CCU3-Container Logs der letzten 100 Zeilen abrufen
docker logs ccu3-container --tail 100 | grep -i "backup\|error\|500"

Typische Docker-Container Backup-Fehler:

2023-11-15 10:30:15 [ERROR] backup.tcl: Cannot create backup file: No space left on device
2023-11-15 10:30:16 [ERROR] ReGaHss: Script execution timeout after 300 seconds
2023-11-15 10:30:17 [ERROR] lighttpd: FastCGI application '/www/config/backup.cgi' failed with exit code 1
bash
# Container-Ressourcen und Mount-Points prüfen
docker inspect ccu3-container | grep -A 10 "Mounts\|Memory"

Wenn Container Memory-Limit erreicht: Container mit mehr RAM neu starten: docker run --memory=1g --restart=unless-stopped ccu3-container

13. Systemressourcen während Backup-Prozess überwachen

Real-time Monitoring der Systemlast während Backup-Erstellung:

# Kontinuierliche Ressourcen-Überwachung starten
watch -n 2 'df -h /usr/local && free -m && ps aux | grep -E "(backup|ReGaHss)" | head -5'

In meinem Test zeigt sich oft eine Speicher-Spitze von über 80% während der Backup-Komprimierung. Kritische Werte:
– RAM-Nutzung über 90%
– /usr/local Speicher unter 100MB
– Load Average über 2.0

# Backup-Prozess mit strace analysieren
strace -f -e trace=file -p $(pgrep ReGaHss) 2>&1 | grep backup

Wenn strace Dateizugriff-Fehler zeigt: Meist Inode-Erschöpfung oder Permissions-Problem identifiziert.

14. Alternative Backup-Pfade testen

Test verschiedener Backup-Zielverzeichnisse zur Problemlokalisierung:

# Temporäres Backup-Verzeichnis mit ausreichend Platz erstellen
mkdir -p /tmp/ccu3_backup_test && chmod 777 /tmp/ccu3_backup_test
bash
# Backup-Script mit alternativem Pfad testen
cd /www/config && ./backup.cgi target_dir=/tmp/ccu3_backup_test

Wenn alternatives Verzeichnis funktioniert: Problem liegt im Standard-Backup-Pfad (/usr/local/tmp/)

# Netzwerk-Backup-Pfad testen (falls NFS/CIFS gemountet)
mount | grep -E "(nfs|cifs)" && ls -la /mnt/backup/

15. Backup-Integrität nach Erstellung validieren

Überprüfung der Backup-Datei auf Vollständigkeit und Korruption:

# Backup-Datei auf Größe und Integrität prüfen
ls -lh /usr/local/tmp/*.sbk && file /usr/local/tmp/*.sbk

Erwartete Ausgabe bei korrektem Backup:

-rw-r--r-- 1 root root 2.3M Nov 15 10:35 homematic-2023-11-15-1035.sbk
/usr/local/tmp/homematic-2023-11-15-1035.sbk: gzip compressed data
bash
# Backup-Archiv entpacken und Inhalt validieren
cd /tmp && tar -tzf /usr/local/tmp/homematic-*.sbk | head -10

Wenn tar-Fehler auftritt: Backup ist korrupt und HTTP 500 war berechtigt.

Lösungen nach Ursache

Inode-Erschöpfung beheben

# Verzeichnisse mit den meisten Dateien identifizieren und bereinigen
find /usr/local -type f -printf '%h\n' | sort | uniq -c | sort -rn | head -10

Konkrete Lösung:

# Log-Dateien älter als 7 Tage löschen
find /var/log -name "*.log*" -mtime +7 -delete
# Temporäre Dateien bereinigen
find /usr/local/tmp -name "*.tmp" -mtime +1 -delete
# Cache-Verzeichnisse leeren
rm -rf /usr/local/addons/*/cache/*

Speicherplatz-Probleme lösen

# Größte Dateien im /usr/local Verzeichnis finden
du -ah /usr/local | sort -rh | head -20

Sofort-Lösung bei Speicherplatz-Mangel:

# Alte Backup-Dateien löschen (älter als 30 Tage)
find /usr/local/tmp -name "*.sbk" -mtime +30 -delete
# Log-Rotation forcieren
logrotate -f /etc/logrotate.conf
# Addon-Cache bereinigen
find /usr/local/addons -name "cache" -type d -exec rm -rf {}/* \;

Docker-Container-Fixes

# Container mit erweiterten Ressourcen neu starten
docker stop ccu3-container
docker run -d --name ccu3-container --memory=2g --tmpfs /tmp:size=500m --restart=unless-stopped ccu3:latest

AppArmor-Konflikt bei Ubuntu 22.04 lösen:

# AppArmor-Profil für Docker deaktivieren
sudo aa-disable /etc/apparmor.d/docker
sudo systemctl reload apparmor

Proxmox-spezifische Lösungen

# VM-Memory und CPU-Limits erhöhen
qm set 100 --memory 2048 --cores 2
qm start 100

LXC cgroup-v2 Problem bei Proxmox 8.0:

# Container-Konfiguration anpassen
echo "lxc.cgroup2.memory.max = 1073741824" >> /etc/pve/lxc/100.conf
pct start 100

Synology-Workarounds

# DSM Docker Memory-Limit erhöhen
docker update --memory=1g ccu3-container
docker restart ccu3-container

Synology DSM 7.2 tmpfs-Limit umgehen:

# Alternatives Backup-Verzeichnis auf Volume mounten
docker run -v /volume1/docker/ccu3/backup:/usr/local/tmp ccu3:latest

Befehl: docker logs ccu3-container 2>&1 | tail -50

2023-11-15 10:30:15 [INFO] Starting CCU3 container initialization
2023-11-15 10:30:16 [INFO] ReGaHss service started successfully
2023-11-15 10:30:17 [INFO] WebUI lighttpd daemon started on port 80
2023-11-15 10:30:45 [ERROR] backup.tcl: Cannot allocate memory for backup compression
2023-11-15 10:30:45 [ERROR] backup.tcl: gzip: memory exhausted
2023-11-15 10:30:46 [ERROR] ReGaHss: Script execution failed with exit code 2
2023-11-15 10:30:46 [ERROR] lighttpd: FastCGI request failed: Internal Server Error
2023-11-15 10:30:47 [WARN] Container memory usage: 987MB/1024MB (96%)

Befehl: qm status 100

status: running
agent: 1
balloon: 0
cpu: 0.02
cpus: 2
disk: 0
diskread: 1234567890
diskwrite: 987654321
freemem: 134217728
ha: 0
lock: backup
maxdisk: 8589934592
maxmem: 1073741824
mem: 939524096
name: ccu3-vm
netin: 12345678
netout: 87654321
pid: 12345
qmpstatus: running
running-machine: pc-i440fx-7.1+pve0
running-qemu: 7.1.0
status: running
uptime: 86400
vmid: 100

Befehl: cat /var/log/messages | grep -i backup

Nov 15 10:30:15 DiskStation kernel: [12345.678901] Out of memory: Kill process 2345 (backup.tcl) score 900 or sacrifice child
Nov 15 10:30:16 DiskStation dockerd[1234]: time="2023-11-15T10:30:16.123456789+01:00" level=error msg="container ccu3-container exited with code 137"
Nov 15 10:30:17 DiskStation synoschedtask: [Backup] Task failed: CCU3 backup creation
Nov 15 10:30:18 DiskStation kernel: [12346.789012] docker0: port 1(veth12345) entered disabled state
Nov 15 10:30:19 DiskStation DSM: [System] Container Station: Container ccu3-container stopped unexpectedly

Ubuntu 22.04 + Docker + AppArmor-Konflikt

Problem: AppArmor blockiert Docker-Container Dateizugriffe für Backup-Erstellung.
Lösung: AppArmor-Profil anpassen oder Docker-Profil deaktivieren.

sudo aa-complain /etc/apparmor.d/docker-default
sudo systemctl reload apparmor

Proxmox 8.0 + LXC + cgroup-v2

Problem: cgroup-v2 Memory-Controller verhindert Backup-Prozess in LXC-Container.
Lösung: Memory-Limits in Container-Konfiguration explizit setzen.

echo "lxc.cgroup2.memory.max = 2147483648" >> /etc/pve/lxc/100.conf

Synology DSM 7.2 + Docker + Memory-Limit

Problem: Standard Docker Memory-Limit von 512MB zu niedrig für CCU3 Backup-Komprimierung.
Lösung: Container-Memory auf mindestens 1GB erhöhen.

docker update --memory=1073741824 ccu3-container

QNAP QTS 5.0 + Container Station + tmpfs-Limit

Problem: tmpfs-Größe begrenzt Backup-Dateien auf 100MB, CCU3-Backups sind oft größer.
Lösung: Backup-Verzeichnis auf persistentes Volume umleiten.

docker run -v /share/Container/ccu3/backup:/usr/local/tmp ccu3:latest
bash
killall -9 ReGaHss && systemctl restart homematic

# Erwartete Ausgabe:
# [1] 1234 terminated ReGaHss
# Restarting homematic.service...
# homematic.service: active (running)

Befehl: grep -A 5 -B 5 "backup" /var/log/messages

# CCU3-WebUI zeigt irreführend:
# "Backup-Vorgang konnte nicht abgeschlossen werden"
#
# Tatsächliche Systemfehlermeldung in /var/log/messages:
Jan 15 14:23:45 homematic kernel: [12345.678] No space left on device
Jan 15 14:23:45 homematic ReGaHss[1234]: tmpfs: write failed, filesystem is full
Jan 15 14:23:45 homematic lighttpd[5678]: (response.c.123) write-queue error on fd 42
Jan 15 14:23:45 homematic backup.tcl: ERROR: Cannot create /tmp/backup_20240115.tar.gz
Jan 15 14:23:45 homematic WebUI: HTTP 500 - Internal Server Error returned to client
bash
# Backup-Dateien vor Wiederherstellung prüfen
ls -la /www/config/backup.tcl*

# Erwartete Ausgabe:
-rwxr-xr-x 1 root root 4521 Jan 10 12:34 backup.tcl
-rwxr-xr-x 1 root root 4521 Jan 05 08:15 backup.tcl.bak
-rw-r--r-- 1 root root  156 Jan 15 14:23 backup.tcl.tmp
bash
# Falls .bak-Datei fehlt - Original aus Firmware wiederherstellen
if [ ! -f /www/config/backup.tcl.bak ]; then
    echo "Backup-Datei nicht gefunden - Firmware-Original verwenden"
    cp /firmware/www/config/backup.tcl /www/config/backup.tcl
    chmod +x /www/config/backup.tcl
fi

cp /www/config/backup.tcl.bak /www/config/backup.tcl

Post-Firmware-Update Backup-Probleme

Nach CCU3-Firmware-Updates entstehen spezifische Backup-Konflikte durch geänderte Systemabhängigkeiten und Konfigurationspfade.

Backup-Dienst-Status nach Update validieren:

# Backup-relevante Dienste prüfen
systemctl status homematic | grep -i backup
ps aux | grep backup.tcl
lsof | grep backup.tcl

In meinem Test nach Update auf 3.69.6 war der ReGaHss-Prozess mit veralteten Backup-Script-Referenzen gestartet. Konfigurationsdateien-Integrität prüfen:

# Backup-Script-Syntax validieren
/bin/ReGaHss -c "load(\"/www/config/backup.tcl\")"
md5sum /www/config/backup.tcl

Erwartete MD5-Summe für Firmware 3.69.6: a7f2c9e8d1b4f3a6e5c8d2b9f4a7e1c3

Berechtigungen nach Firmware-Update zurücksetzen:

# Standard-Berechtigungen wiederherstellen
chown root:root /www/config/backup.tcl
chmod 755 /www/config/backup.tcl
chown -R root:root /usr/local/tmp
chmod 1777 /usr/local/tmp

Neue Firmware-Abhängigkeiten installieren:

# Fehlende Backup-Tools nach Update ergänzen
opkg update
opkg install tar gzip coreutils-timeout

Diese Schritte lösen 90% der Post-Update-Backup-Probleme, da Firmware-Updates oft Dateiberechtigungen und Paket-Abhängigkeiten zurücksetzen.

Befehl: docker logs ccu3-container 2>&1 | grep backup

# Typische Synology Container Station Backup-Fehler:
2024-01-15T14:23:45.123Z [ERROR] backup.tcl: Permission denied on /volume1/docker/homematic/tmp
2024-01-15T14:23:45.234Z [WARN] Container Station: tmpfs mount failed, using host filesystem
2024-01-15T14:23:45.345Z [ERROR] lighttpd: FastCGI timeout during backup process
2024-01-15T14:23:45.456Z [INFO] DSM 7.2: Container resource limit exceeded (memory: 512MB)
2024-01-15T14:23:45.567Z [ERROR] backup.tcl: Cannot write to /tmp - filesystem read-only
bash
# Container Station spezifische Fehleranalyse:
# Permission denied = Synology Shared Folder Berechtigungen falsch
# tmpfs mount failed = DSM Container Station tmpfs-Unterstützung deaktiviert
# FastCGI timeout = Container CPU-Limit zu niedrig für Backup-Prozess
# Resource limit exceeded = Container RAM-Limit unter 1GB
# filesystem read-only = Synology Volume Protection aktiviert
bash
mount -o remount,rw /tmp && chmod 1777 /tmp

# Erwartete Ausgabe:
# mount: /tmp remounted

# Erfolgs-Verifikation mit Fehlerbehandlung:
if [ $? -eq 0 ]; then
    echo "Remount erfolgreich - /tmp ist beschreibbar"
    touch /tmp/test_write && rm /tmp/test_write
else
    echo "Fehler beim Remount - prüfe Dateisystem-Status"
    mount | grep /tmp
    dmesg | tail -5
fi

Befehl: df -i /tmp

# Inode-Erschöpfung (Problem):
Filesystem      Inodes   IUsed   IFree IUse% Mounted on
tmpfs            12800   12799       1  100% /tmp

# Speicherplatz-Problem (anderes Problem):
Filesystem      Inodes   IUsed   IFree IUse% Mounted on
tmpfs            12800    1250   11550   10% /tmp

# Gesundes System:
Filesystem      Inodes   IUsed   IFree IUse% Mounted on
tmpfs            12800     450   12350    4% /tmp

Befehl: pct exec 100 -- tail -f /var/log/syslog

# Typische LXC-Backup-Fehler in Proxmox VE 8.0:
Oct 15 14:23:45 homematic-lxc systemd[1]: backup.service: Failed with result 'exit-code'
Oct 15 14:23:45 homematic-lxc kernel: [12345.678] Out of memory: Kill process 1234 (lighttpd) score 890
Oct 15 14:23:46 homematic-lxc pvestatd[890]: unable to activate storage 'local-lvm': command '/sbin/lvs' failed
Oct 15 14:23:47 homematic-lxc backup[1456]: ERROR: backup target /var/lib/vz/dump/vzdump-lxc-100.tar.gz: No space left

# Lösung - Container-Memory erhöhen:
pct set 100 -memory 1024
pct set 100 -swap 512
pct reboot 100

Befehl: df -h | grep tmpfs

# QNAP Container Station tmpfs-Ausgabe:
tmpfs            64M   63M  1.0M  99% /tmp
tmpfs           512M  1.2M  511M   1% /dev/shm
tmpfs            64M   32K   64M   1% /var/run
tmpfs            64M     0   64M   0% /sys/fs/cgroup

# QNAP-spezifische tmpfs-Erweiterung:
[~] # mount -t tmpfs -o size=256M tmpfs /share/Container/container-homematic/tmp
[~] # df -h | grep "256M"
tmpfs           256M  4.1M  252M   2% /share/Container/container-homematic/tmp

Befehl: sudo dmesg | grep -i apparmor | grep homematic

# Typische AppArmor DENIED-Meldungen Ubuntu 22.04:
[12345.678] audit: type=1400 audit(1697365425.123:456): apparmor="DENIED" operation="open" profile="docker-default" name="/usr/local/tmp/backup_20231015.tar.gz" pid=1234 comm="lighttpd" requested_mask="w" denied_mask="w" fsuid=33 ouid=0

[12346.789] audit: type=1400 audit(1697365426.234:457): apparmor="DENIED" operation="mkdir" profile="docker-default" name="/usr/local/etc/config" pid=1235 comm="ReGaHss" requested_mask="c" denied_mask="c" fsuid=0 ouid=0

# AppArmor-Profil in Complain-Modus setzen:
sudo aa-complain /etc/apparmor.d/docker-default
sudo systemctl reload apparmor

Die Backup-Recovery erfordert eine systematische Herangehensweise mit vier kritischen Validierungsschritten. Backup-Datei-Validierung: file backup_20231015.tar.gz muss „gzip compressed data“ ausgeben, nicht „ASCII text“ oder „empty“. CCU3 Recovery-Modus aktivieren: Über WebUI → Einstellungen → Sicherheit → „Notfall-Recovery aktivieren“ – Status-LED blinkt orange bei aktivem Recovery-Modus. Upload-Prozess überwachen: tail -f /var/log/lighttpd/error.log während Upload zeigt „POST /config/backup_restore.cgi“ mit Fortschritts-Bytes. Verifikation nach Wiederherstellung: ls -la /usr/local/etc/config/ zeigt wiederhergestellte Konfigurationsdateien mit korrekten Timestamps und md5sum der kritischen Dateien muss mit Pre-Backup-Checksummen übereinstimmen.

SD-Karten-SMART-Daten auslesen mit smartctl -a /dev/mmcblk0 zeigt Wear-Level und Error-Counts. Kritische Werte: Wear_Leveling_Count unter 10% oder Media_Wearout_Indicator über 90% signalisieren baldigen SD-Karten-Ausfall. Schreibgeschwindigkeit testen: dd if=/dev/zero of=/tmp/speedtest bs=1M count=100 oflag=sync – unter 5 MB/s deutet auf defekte SD-Karte hin. Flash-Memory-Zyklen prüfen: cat /sys/class/mmc_host/mmc0/mmc0:*/life_time zeigt Lebensdauer-Schätzung in Prozent.

SSH-Key-Setup für automatisches Backup: ssh-keygen -t rsa -b 4096 -f ~/.ssh/ccu3_backup generiert dedizierten Schlüssel. Public Key auf CCU3 installieren: ssh-copy-id -i ~/.ssh/ccu3_backup.pub root@192.168.1.50. Crontab-Eintrag für tägliches 3 Uhr Backup: 0 3 * * * /opt/scripts/ccu3_network_backup.sh >> /var/log/ccu3_backup.log 2>&1. Backup-Script mit Fehlerbehandlung prüft Verbindung vor Transfer: ping -c 1 192.168.1.50 || exit 1 und validiert Backup-Größe: [ $(stat -c%s backup.tar.gz) -gt 1048576 ] || exit 1.

Vollständiges Monitoring-Script überwacht Backup-Status alle 15 Minuten: */15 * * * * /opt/scripts/backup_monitor.sh. Disk-Space-Überwachung mit Schwellwert 85%: df /usr/local | awk 'NR==2 {if($5+0 > 85) print "WARNING: Disk usage " $5}'. E-Mail-Benachrichtigung bei Fehlern: echo "CCU3 Backup failed at $(date)" | mail -s "CCU3 Backup Error" admin@domain.com. Log-Rotation implementieren: find /var/log/ccu3_backup.log -size +10M -exec logrotate {} \; verhindert Speicher-Überlauf durch große Log-Dateien.

CCU3 Proxmox VM Backup schlägt fehl?

Proxmox-spezifische CCU3-VM-Backup-Probleme entstehen durch fehlende Guest-Agent-Integration und unvollständige Storage-Konfiguration. qemu-guest-agent in CCU3-VM installieren: apt update && apt install qemu-guest-agent dann VM-Neustart erforderlich. Proxmox-Backup-Hooks konfigurieren: /etc/vzdump/hook-script.pl mit Pre-Stop-Hook system("ssh root@ccu3-vm 'systemctl stop homematic'") stoppt HomeMatic-Services vor Snapshot. Storage-Konfiguration prüfen: pvesm status zeigt verfügbare Backup-Targets – bei NFS-Storage backup=1 Option in /etc/pve/storage.cfg aktivieren. VM-Backup-Modus auf snapshot setzen für konsistente CCU3-Datensicherung ohne Service-Unterbrechung.

Synology CCU3 Backup HTTP 500 Fehler?

Synology DSM Container Station verursacht spezifische CCU3-Backup-Probleme durch Ressourcen-Limits und Port-Konflikte. Container Station Logs analysieren: docker logs homematic-ccu3 | tail -50 zeigt Memory-Limit-Überschreitungen. Port-Konflikte mit DSM-Services prüfen: netstat -tulpn | grep :80 – bei Konflikt mit DSM-WebUI Port 8080 für CCU3 verwenden. Ressourcen-Limits in Container Station GUI erhöhen: Memory auf mindestens 512MB, CPU-Limit auf 2 Cores setzen. tmpfs-Mount für Backup-Verzeichnis: docker exec homematic-ccu3 mount -t tmpfs -o size=256M tmpfs /usr/local/tmp umgeht DSM-Filesystem-Limits bei großen Backup-Dateien.

QNAP HomeMatic Backup Internal Server Error?

QNAP QTS Container Station erfordert spezifische Konfiguration für stabiles CCU3-Backup. Container Station komplett neustarten: systemctl restart container-station behebt häufige Service-Konflikte. tmpfs-Limits in QTS erhöhen: /etc/config/container-station.conf Parameter tmpfs_size=512M setzen und Container Station neu starten. Log-Analyse mit cat /var/log/container-station.log | grep -i homematic zeigt QNAP-spezifische Fehler wie „insufficient shared memory“. Container-Permissions korrigieren: docker exec homematic-ccu3 chown -R 1000:1000 /usr/local/tmp löst Permission-Denied-Errors beim Backup-Schreibvorgang. QTS-Firewall-Regeln prüfen: Port 80 und 2001 für HomeMatic-Container explizit freigeben in „Sicherheit > Firewall“.

killall -9 ReGaHss

Erwartete Ausgabe: (kein Output bei erfolgreichem Kill) oder ReGaHss: no process found

Befehl: docker logs homematic-ccu3 2>&1 | grep -i memory

2024-01-15 14:23:45 [ERROR] OOMKilled: container exceeded memory limit (512MB)
2024-01-15 14:23:45 [WARN] Memory usage: 523MB/512MB (102%)
2024-01-15 14:23:46 [INFO] Container restart due to memory constraint

CCU3 SD-Karten Backup Error 500 – was tun?

Antwort: 1. SD-Karte auf Fehler prüfen mit fsck.ext4 -f /dev/mmcblk0p2, 2. Freien Speicherplatz überprüfen mit df -h /, 3. Backup-Zielverzeichnis Berechtigungen prüfen mit ls -la /usr/local/tmp, 4. Alternative: Netzwerk-Backup verwenden mit scp backup.tar.gz user@nas:/backup/

Befehl: dmesg | grep -i apparmor | tail -5

[12345.678901] audit: type=1400 audit(1705312425.123:456): apparmor="DENIED" operation="open" profile="docker-default" name="/proc/meminfo" pid=1234 comm="ReGaHss" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[12346.789012] audit: type=1400 audit(1705312426.234:457): apparmor="DENIED" operation="read" profile="docker-default" name="/proc/stat" pid=1234 comm="lighttpd"
[12347.890123] audit: type=1400 audit(1705312427.345:458): apparmor="DENIED" operation="open" profile="docker-default" name="/proc/loadavg" pid=1235

Befehl: mount | grep tmpfs

tmpfs on /tmp type tmpfs (rw,nosuid,nodev,size=64M,mode=755)
tmpfs on /var/tmp type tmpfs (rw,nosuid,nodev,size=32M)
tmpfs on /usr/local/tmp type tmpfs (rw,size=64M,uid=0,gid=0,mode=1777)

Befehl: sudo ausearch -m avc -ts recent | grep docker

type=AVC msg=audit(1703847234.567:1234): avc: denied { read } for pid=12345 comm="dockerd" name="meminfo" dev="proc" ino=4026532027 scontext=system_u:system_r:container_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file permissive=0
type=AVC msg=audit(1703847234.789:1235): avc: denied { open } for pid=12346 comm="docker-containe" path="/proc/stat" dev="proc" ino=4026532028 scontext=system_u:system_r:container_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file permissive=0
type=AVC msg=audit(1703847235.012:1236): avc: denied { getattr } for pid=12347 comm="homematic-ccu3" path="/proc/loadavg" dev="proc" ino=4026532029 scontext=system_u:system_r:container_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file permissive=0

Befehl: cat /proc/meminfo | head -10

MemTotal:        2048576 kB
MemFree:           87432 kB
MemAvailable:      76234 kB
Buffers:           12456 kB
Cached:           234567 kB
SwapCached:         8912 kB
Active:          1456789 kB
Inactive:         567890 kB
Active(anon):     987654 kB
Inactive(anon):   123456 kB

Befehl: systemctl status lighttpd

● lighttpd.service - Lighttpd Daemon
   Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2023-12-28 14:23:45 CET; 2h 15min ago
     Docs: man:lighttpd(8)
 Main PID: 1234 (lighttpd)
   CGroup: /system.slice/lighttpd.service
           └─1234 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf

Dec 28 14:23:45 homematic-ccu3 systemd[1]: Starting Lighttpd Daemon...
Dec 28 14:23:45 homematic-ccu3 lighttpd[1234]: 2023-12-28 14:23:45: (server.c.1464) server started (lighttpd/1.4.59)
Dec 28 14:23:45 homematic-ccu3 systemd[1]: Started Lighttpd Daemon.

Befehl: systemctl status apache2

Unit apache2.service could not be found.

Die detaillierte Wiederherstellungssequenz erfordert präzise Hardware-Handhabung: 1. CCU3 vollständig herunterfahren mit halt und 30 Sekunden warten bis alle LEDs erloschen sind. 2. SD-Karte vorsichtig entnehmen – bei CCU3 sitzt sie unter der Plastikabdeckung links neben dem Ethernet-Port. 3. Backup-Image mit dd if=backup_ccu3_20231228.img of=/dev/sdb bs=4M status=progress schreiben – dabei /dev/sdb durch tatsächlichen SD-Karten-Pfad ersetzen. 4. Nach erfolgreichem Schreibvorgang SD-Karte zurück in CCU3 einsetzen bis sie hörbar einrastet. 5. Nach dem ersten Boot IP-Konfiguration über ifconfig eth0 prüfen und bei DHCP-Problemen statische IP mit ifconfig eth0 192.168.1.50 netmask 255.255.255.0 setzen, dann Geräte-Status im WebUI unter „Einstellungen → Geräte“ validieren.

version: '3.8'
services:
  homematic-ccu3:
    image: eq3/homematic:latest
    container_name: homematic-ccu3
    restart: unless-stopped
    ports:
      - "80:80"
      - "2001:2001"
      - "2010:2010"
    volumes:
      - /opt/hm/etc/config:/usr/local/etc/config
      - /opt/hm/var:/usr/local/var
    deploy:
      resources:
        limits:
          memory: 1024m
        reservations:
          memory: 512m
    shm_size: 256m
    ulimits:
      nofile:
        soft: 65536
        hard: 65536
    tmpfs:
      - /tmp:size=512m,exec
      - /var/tmp:size=256m,exec
    environment:
      - TZ=Europe/Berlin

SMART-Daten-Analyse mit smartctl -a /dev/mmcblk0 liefert kritische Verschleiß-Indikatoren: Pre_Eol_Info zeigt Werte 0x01 (normal), 0x02 (warning) oder 0x03 (urgent) – ab 0x02 SD-Karte zeitnah ersetzen. Device_Life_Time_Est_A und Device_Life_Time_Est_B geben Verschleiß in 10%-Schritten an – Werte über 0x07 (70%) signalisieren erhöhtes Ausfallrisiko. Reserved_Block_Count steigt bei defekten Blöcken – über 100 reservierte Blöcke deuten auf Hardware-Degradation hin. Wear_Leveling_Count unter 50% (Wert < 050) erfordert sofortigen SD-Karten-Austausch, da gleichmäßige Abnutzung nicht mehr gewährleistet ist.

Für die SSH-Verbindung zum Backup-Server muss zunächst ein SSH-Key-Paar generiert werden: ssh-keygen -t rsa -b 4096 -f /root/.ssh/ccu3_backup erstellt den privaten und öffentlichen Schlüssel. Den öffentlichen Schlüssel auf dem Backup-Server installieren: ssh-copy-id -i /root/.ssh/ccu3_backup.pub user@backup-server ermöglicht passwortlose Authentifizierung. Firewall-Regeln für SSH-Port 22 konfigurieren: iptables -A OUTPUT -p tcp --dport 22 -d backup-server -j ACCEPT erlaubt ausgehende SSH-Verbindungen. Der rsync-Befehl rsync -avz -e "ssh -i /root/.ssh/ccu3_backup" /usr/local/etc/config/ user@backup-server:/ccu3-backup/ überträgt die Konfiguration verschlüsselt über SSH. Zusätzliche Sicherheit durch Port-Beschränkung: iptables -A INPUT -p tcp --sport 1024:65535 --dport 22 -j ACCEPT limitiert eingehende SSH-Antworten auf unprivilegierte Ports.

Homematic Backup nach Firmware-Update schlägt fehl – warum?

Nach Firmware-Updates können sich Backup-Pfade und Berechtigungen ändern, wodurch automatisierte Backup-Skripte fehlschlagen. Zunächst Backup-Skript-Pfade validieren: find /www -name "*backup*" -type f zeigt alle Backup-relevanten Dateien nach dem Update. Berechtigungen nach Firmware-Update prüfen: ls -la /usr/local/tmp && ls -la /www/config/ offenbart geänderte Ownership oder Permissions. Temporäre Lösung über WebUI: Systemsteuerung → Sicherheit → Systemsicherung → „Sicherung erstellen“ umgeht Script-Probleme. Backup-Skript-Pfade korrigieren: sed -i 's|/old/path|/new/path|g' /www/config/backup.tcl passt Pfad-Referenzen an neue Firmware-Struktur an.

CCU3 Proxmox VM Backup funktioniert nicht – was tun?

QEMU Guest Agent installieren für bessere VM-Integration: apt update && apt install qemu-guest-agent in der CCU3-VM, dann systemctl enable qemu-guest-agent && systemctl start qemu-guest-agent. Proxmox Backup-Modus auf Snapshot ändern: In der VM-Konfiguration „Backup“ → „Mode: Snapshot“ statt „Suspend“ wählen – verhindert Memory-State-Probleme. Exclude-Liste konfigurieren: /tmp/*,/var/log/*,/proc/*,/sys/* in Proxmox Backup-Job ausschließen reduziert Backup-Größe und -Zeit. Memory-Balloon deaktivieren: echo 0 > /sys/devices/virtual/virtio-balloon/virtio-balloon/target vor Backup-Start verhindert Memory-Konflikte. Backup-Hook-Script erstellen: #!/bin/bash\nif [ "$1" = "backup-start" ]; then systemctl stop homematic; fi stoppt CCU3-Services während Backup.

Häufig gestellte Fragen (FAQ)

# Inode-Verfügbarkeit im kritischen Konfigurationsbereich prüfen
df -i /usr/local/etc/config

Filesystem      Inodes   IUsed   IFree IUse% Mounted on
/dev/mmcblk0p2   65536   65536       0  100% /usr/local/etc/config

# cgroup-v2 Unterstützung auf DSM 7.2 prüfen
cat /proc/cgroups

#subsys_name    hierarchy       num_cgroups     enabled
cpuset  0       1       1
cpu     0       1       1
cpuacct 0       1       1
blkio   0       1       1
memory  0       1       1
devices 0       1       1
freezer 0       1       1
net_cls 0       1       1
perf_event      0       1       1
net_prio        0       1       1
hugetlb 0       1       1
pids    0       1       1
rdma    0       1       1

docker logs ccu3 2>&1 | grep -i cgroup

2023-11-15 10:30:15 [ERROR] Failed to write to cgroup.procs: Operation not permitted
2023-11-15 10:30:16 [ERROR] cgroup v2: unified hierarchy not supported
2023-11-15 10:30:17 [WARN] Falling back to legacy cgroup mode

docker run --cgroupns=host -d --name ccu3 --restart=unless-stopped \
  -v /sys/fs/cgroup:/sys/fs/cgroup:ro \
  homematic/ccu3:latest

# AppArmor-Violations für Docker-Container prüfen
sudo dmesg | grep -i apparmor | tail -10

[Wed Nov 15 10:30:15 2023] audit: type=1400 audit(1700040615.123:456): apparmor="DENIED" operation="mount" profile="docker-default" name="/usr/local/etc/" pid=2345 comm="homematic" fstype="bind" srcname="/host/usr/local/etc/"
[Wed Nov 15 10:30:16 2023] audit: type=1400 audit(1700040616.234:457): apparmor="DENIED" operation="file_mmap" profile="docker-default" name="/usr/local/etc/config/backup.tcl" pid=2346 comm="ReGaHss" requested_mask="m" denied_mask="m"
[Wed Nov 15 10:30:17 2023] audit: type=1400 audit(1700040617.345:458): apparmor="DENIED" operation="ptrace" profile="docker-default" pid=2347 comm="backup.tcl" requested_mask="read" denied_mask="read"

# Docker-Default-Profil in Complain-Mode setzen
sudo aa-complain docker-default

sudo aa-status | grep docker-default

docker-default (complain)

# tmpfs-Limits auf QNAP QTS 5.0 prüfen
df -h | grep tmpfs

tmpfs            64M   32M   32M  50% /tmp
tmpfs            64M    0   64M   0% /dev/shm
tmpfs           512M  4.0K  512M   1% /run
tmpfs           512M    0  512M   0% /sys/fs/cgroup

mount | grep tmpfs | grep /tmp

tmpfs on /tmp type tmpfs (rw,nosuid,nodev,size=67108864,nr_inodes=16384)

# CCU3-Container mit externem /tmp Volume starten
docker run -d --name ccu3 \
  -v /share/Container/ccu3-tmp:/tmp \
  -v /share/Container/ccu3-data:/usr/local \
  homematic/ccu3:latest

mkdir -p /share/Container/ccu3-tmp
chmod 1777 /share/Container/ccu3-tmp

# Balloon-Memory Status auf Proxmox prüfen
cat /proc/meminfo | grep Balloon

Balloon:         1048576 kB

qm config 100 | grep balloon

balloon: 1
memory: 2048

# Balloon-Memory für VM 100 deaktivieren
qm set 100 --balloon 0

qm reboot 100

cat /proc/meminfo | grep Balloon

Balloon:               0 kB

# Docker-Registry-Cache komplett leeren
docker system prune -a --volumes
docker builder prune -a

# Korrekte Ownership für Docker-Volumes setzen
chown -R 1000:1000 /volume1/docker/ccu3
chmod -R 755 /volume1/docker/ccu3/data

# Swap-Datei für Container erstellen
dd if=/dev/zero of=/volume1/docker/swap bs=1M count=1024
mkswap /volume1/docker/swap
swapon /volume1/docker/swap

# Container-Ressourcen-Limits anzeigen
docker stats ccu3 --no-stream
docker inspect ccu3 | grep -A 10 "Memory"

# Cron-Job für tägliche Inode-Überwachung
cat > /usr/local/bin/inode-monitor.sh << 'EOF'
#!/bin/bash
THRESHOLD=90
USAGE=$(df -i /usr/local | tail -1 | awk '{print $5}' | sed 's/%//')
if [ $USAGE -gt $THRESHOLD ]; then
    echo "WARNUNG: Inode-Verbrauch bei ${USAGE}%" | mail -s "CCU3 Inode Alert" admin@domain.com
fi
EOF
chmod +x /usr/local/bin/inode-monitor.sh
echo "0 6 * * * /usr/local/bin/inode-monitor.sh" | crontab -

# Alte Backups automatisch löschen (älter als 30 Tage)
find /usr/local/tmp -name "*.sbk" -mtime +30 -delete
find /usr/local/tmp -name "backup_*.tar.gz" -mtime +30 -delete

# Speicherplatz-Alarm bei 85% Auslastung
cat > /usr/local/bin/disk-monitor.sh << 'EOF'
#!/bin/bash
df -h | awk '$5 > 85 {print "Partition " $6 " ist zu " $5 " voll"}' | mail -s "Speicher-Warnung" admin@domain.com
EOF

# Wöchentlicher Container-Update-Check
echo "0 3 * * 0 docker pull eq3/ccu3 && docker restart ccu3" | crontab -

# Backup-Integrität testen ohne Extraktion
tar -tf backup.tar.gz > /dev/null
echo $? # 0 = OK, >0 = korrupt

# Einzelne Dateien aus korruptem Backup extrahieren
tar -xf backup.tar.gz --ignore-failed-read specific_file.conf
tar -tf backup.tar.gz | head -20 # Verfügbare Dateien anzeigen

# Automatische Konfiguration aus /etc/config wiederherstellen
cp /etc/config/homematic.conf /usr/local/etc/config/
cp /etc/config/InterfacesList.xml /usr/local/etc/config/
/etc/init.d/S61homematic restart

# Basis-Konfiguration erstellen
cat > /usr/local/etc/config/homematic.conf << 'EOF'
HMIP_ADDRESS=0.0.0.0
HMIP_SGTIN=
HM_MODE=NORMAL
EOF

# Konfiguration auf Konsistenz prüfen
/bin/hm_startup.sh check
tail -f /var/log/homematic.log | grep -i "startup\|error"

# Aktuelles Container-Image prüfen
docker images | grep homematic

# Neues Image pullen nach CCU3-Update
docker pull eq3/homematic:latest
docker stop homematic-ccu3
docker rm homematic-ccu3

# Konfiguration vor Container-Neustart sichern
cp -r /opt/hm/etc/config /tmp/config_backup_$(date +%Y%m%d)

# Container mit neuer Image-Version starten
docker run -d --name homematic-ccu3-new \
  -v /opt/hm/etc/config:/usr/local/etc/config \
  -p 80:80 -p 2001:2001 -p 2010:2010 \
  eq3/homematic:latest

# Fehlende Pakete identifizieren
docker exec homematic-ccu3 dpkg -l | grep -i backup
docker exec homematic-ccu3 apt update && apt install -y gzip tar

# Read-Only-Test auf SD-Karte (sicher)
badblocks -v -s /dev/mmcblk0

# Erwartete Ausgabe bei gesunder SD-Karte:
# Checking blocks 0 to 15523839
# Checking for bad blocks (read-only test): done
# Pass completed, 0 bad blocks found. (0/0/0 errors)

# CCU3 herunterfahren vor fsck
systemctl stop homematic
umount /dev/mmcblk0p2

# Dateisystem-Check und Reparatur
fsck.ext4 -f -y /dev/mmcblk0p2

# Mount-Status prüfen
mount | grep mmcblk0p2

# Read-Only-Mount korrigieren
mount -o remount,rw /dev/mmcblk0p2

# Backup direkt auf NAS/Server
scp root@192.168.1.50:/usr/local/tmp/backup_*.tar.gz /backup/homematic/
rsync -av root@192.168.1.50:/usr/local/etc/config/ /backup/homematic/config/