Stand: 2026-08-05 (erhoben per SSH auf den Proxmox-Host + pct exec)
| Eigenschaft |
Wert |
| Hostname |
Grafana |
| Container-ID (VMID) |
110 |
| Proxmox-Node |
proxmox (192.168.2.230) |
| Rolle |
Grafana — Dashboards/Visualisierung, vermutlich für InfluxDB (LXC 109) |
| IP-Adresse |
192.168.2.240 (DHCP, /24) |
| Root-Storage |
Fotos:110/vm-110-disk-0.raw (CIFS-Storage "Fotos"), 8 GB |
| Eigenschaft |
Wert |
| Architektur |
amd64 |
| CPU-Kerne (Limit) |
2 |
| RAM-Limit |
1024 MB |
| Swap-Limit |
512 MB |
| Netzwerk |
eth0, Bridge vmbr0, Firewall aktiv, MAC BC:24:11:B7:C1:98, DHCP |
| Features |
nesting=1 |
| Unprivileged |
ja |
| Storage-Besonderheit |
Root-Disk liegt auf dem CIFS-Storage "Fotos" — derselbe Storage wie Immich (LXC 106) |
- Ein manuelles Backup vorhanden:
vzdump-lxc-110-2026_03_30-16_44_26.tar.zst (~151 MB), erstellt am 2026-03-30. Kein automatisierter Job.
- Keine Snapshots vorhanden.
Bei der Erhebung wurde festgestellt, dass auch dieser Container seit 2026-07-14 im Nur-Lese-Modus (emergency_ro) lief — exakt derselbe Zeitpunkt und dieselbe Ursache wie bei Immich (LXC 106). Der grafana-server-Dienst lief zwar durchgehend weiter ("active/running"), konnte aber seit ~3 Wochen keine Änderungen mehr in seine SQLite-Datenbank schreiben (Dashboards, Alerts, Nutzereinstellungen).
Root-Ursache (Verdacht): Beide betroffenen Container (Immich, Grafana) liegen auf dem CIFS-Storage "Fotos". Ein Aussetzer dieser Netzwerkfreigabe am 2026-07-14 hat vermutlich beide Loop-Device-Dateisysteme gleichzeitig in den Fehlerzustand versetzt.
Behebung: Container wurde per pct reboot 110 neu gestartet — Root-Filesystem ist danach wieder rw gemountet, Schreibtest erfolgreich.
- OS: Ubuntu 22.04.5 LTS
- Kernel:
7.0.12-1-pve (Proxmox-Host-Kernel)
- Uptime: neu gestartet am 2026-08-05 (im Rahmen dieser Erhebung)
| Ressource |
Wert |
| CPU-Kerne |
2 |
| RAM |
1,0 GiB (davon ~139 MiB belegt) |
| Root-Disk |
7,8 GB gesamt, 2,2 GB belegt (29 %), ext4 |
- Interface:
eth0, MAC BC:24:11:B7:C1:98, IP 192.168.2.240/24, DHCP
| Port |
Protokoll |
Dienst |
| 22 |
TCP |
SSH |
| 25 |
TCP (nur localhost) |
Postfix (lokal) |
| 3000 |
TCP |
Grafana Web-UI |
| Eigenschaft |
Wert |
| Version |
Grafana 13.0.2 |
| Installationsart |
natives Debian/Ubuntu-Paket (kein Docker) |
| Datenverzeichnis |
/var/lib/grafana (~52 MB belegt) |
| Autostart |
ja, systemd-Service grafana-server.service, enabled |
| Läuft seit |
2026-06-28 (bis zum Reboot am 2026-08-05 durchgehend) |
| Datasources |
nicht über Provisioning-Dateien konfiguriert (nur unveränderte sample.yaml vorhanden) → Datasources wurden manuell über die Web-UI angelegt und liegen in der SQLite-DB unter /var/lib/grafana |
- Kein Docker installiert — reiner nativer Dienst.
- Kein projektspezifischer Cron-Job gefunden.
- Backup aktualisieren: Letztes Backup vom 2026-03-30 (~4 Monate alt) — Dashboards/Einstellungen seitdem nicht gesichert.
- Datenintegrität nach dem Vorfall prüfen: Änderungen an Dashboards/Alerts zwischen 2026-07-14 und dem Reboot am 2026-08-05 könnten verloren gegangen sein, da nicht persistiert werden konnte.
- Storage-Ursache klären: Siehe Empfehlung bei Immich — beide Container hängen vom selben CIFS-Storage "Fotos" ab. Ein erneuter Aussetzer dieser Freigabe würde vermutlich wieder beide Container betreffen. Ggf. lohnt sich, kritische Dienste künftig nicht auf Netzwerk-Storage, sondern auf
local-lvm zu legen.
- Monitoring: Ein automatisierter Check auf
ro-Mounts (z. B. via Uptime-Kuma/Skript) hätte diesen Vorfall früher sichtbar gemacht.