[Bug] Backup-Luecke: CT 122 (OpenMemory) seit 03.01.2026 nicht gesichert #105

New issue

Open

opened 2026-06-13 22:15:54 +00:00 by orbitalo · 0 comments

orbitalo commented

2026-06-13 22:15:54 +00:00

Owner

Befund (geprueft 14.06.2026)

Der vzdump-Job backup-daily auf pve-hetzner ist all 1, enabled 1, taeglich 03:00, Ziel pbs-muldenstein, prune keep-daily=7/weekly=4/monthly=3. Storage pbs-muldenstein ist active und funktioniert.

ABER die letzten Backups pro CT auf pbs-muldenstein:

CT	letztes Backup	Zustand
101	2026-06-13 (taeglich, 22:00)	OK
122 (OpenMemory)	2026-01-03	5 Monate alt
100	2026-04-01	stale
103	2026-04-15	stale
104	~2026-03	stale

CT 101 wird taeglich gesichert (um 22:00 - andere Zeit als der 03:00-Job!) -> Backup-Ziel & PBS funktionieren. Das Problem ist der pve-hetzner-Job, der seine Gaeste (122, 100, 103, 104, ...) faktisch nicht mehr sichert.

Warum kritisch

CT 122 = OpenMemory, das gemeinsame Langzeitgedaechtnis von Cursor UND Cline. Single Point of Failure ohne frisches Backup. Stirbt CT 122, ist das Wissen aus Monaten weg.

Hypothesen (zu pruefen)

Job laeuft, schlaegt aber pro CT fehl (Snapshot-Mode + laufender DB-Container? fleeting lock?). Task-Log pruefen: /var/log/pve/tasks/ bzw. pvenode task list.
CT 101 (22:00) wird durch einen ANDEREN Job/Host gesichert -> es gibt evtl. mehrere Jobs, der 03:00-all-Job auf hetzner ist effektiv kaputt/uebersprungen.
Cross-Site (Quelle Hetzner -> Ziel Muldenstein) Timeout/Abbruch.

TODO

Backup-Task-Logs auf pve-hetzner pruefen (warum 122/100/103/104 nicht laufen).
Klaeren warum CT 101 22:00 laeuft (separater Job? anderer Host?).
Job fixen, sodass CT 122 wieder taeglich gesichert wird.
Verifizieren: frischer CT-122-Snapshot vorhanden.
Restore-Drill: CT 122 testweise zuruckspielen (Backup ungetestet = Hoffnung).
Pruefen, ob weitere produktive CTs (116 hausmeister-bot, 999 docs, 147 paperless) aktuelle Backups haben.

## Befund (geprueft 14.06.2026) Der vzdump-Job `backup-daily` auf **pve-hetzner** ist `all 1`, `enabled 1`, taeglich 03:00, Ziel `pbs-muldenstein`, prune keep-daily=7/weekly=4/monthly=3. Storage `pbs-muldenstein` ist **active** und funktioniert. **ABER** die letzten Backups pro CT auf pbs-muldenstein: | CT | letztes Backup | Zustand | |---|---|---| | 101 | 2026-06-13 (taeglich, 22:00) | OK | | 122 (OpenMemory) | **2026-01-03** | **5 Monate alt** | | 100 | 2026-04-01 | stale | | 103 | 2026-04-15 | stale | | 104 | ~2026-03 | stale | CT 101 wird taeglich gesichert (um 22:00 - andere Zeit als der 03:00-Job!) -> Backup-Ziel & PBS funktionieren. Das Problem ist der **pve-hetzner-Job**, der seine Gaeste (122, 100, 103, 104, ...) faktisch nicht mehr sichert. ## Warum kritisch CT 122 = **OpenMemory**, das gemeinsame Langzeitgedaechtnis von Cursor UND Cline. Single Point of Failure ohne frisches Backup. Stirbt CT 122, ist das Wissen aus Monaten weg. ## Hypothesen (zu pruefen) - Job laeuft, schlaegt aber pro CT fehl (Snapshot-Mode + laufender DB-Container? fleeting lock?). Task-Log pruefen: `/var/log/pve/tasks/` bzw. `pvenode task list`. - CT 101 (22:00) wird durch einen ANDEREN Job/Host gesichert -> es gibt evtl. mehrere Jobs, der 03:00-all-Job auf hetzner ist effektiv kaputt/uebersprungen. - Cross-Site (Quelle Hetzner -> Ziel Muldenstein) Timeout/Abbruch. ## TODO - [ ] Backup-Task-Logs auf pve-hetzner pruefen (warum 122/100/103/104 nicht laufen). - [ ] Klaeren warum CT 101 22:00 laeuft (separater Job? anderer Host?). - [ ] Job fixen, sodass CT 122 wieder taeglich gesichert wird. - [ ] Verifizieren: frischer CT-122-Snapshot vorhanden. - [ ] Restore-Drill: CT 122 testweise zuruckspielen (Backup ungetestet = Hoffnung). - [ ] Pruefen, ob weitere produktive CTs (116 hausmeister-bot, 999 docs, 147 paperless) aktuelle Backups haben.