From eea9bbe3f893e0695f0f2c4e4f6d842b1bde8eef Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Wed, 26 Aug 2026 00:32:19 +0200 Subject: [PATCH] ct/104-Snapshots weg; Doku nachgezogen User-Entscheid: auch die Grafana-Backups loeschen. Gegenprobe direkt am Datastore (ct/104 = 0), nicht ueber 'pvesm list --vmid' -- dessen Filter ist nach dem destroy nicht mehr aussagekraeftig. Co-Authored-By: Claude Opus 5 --- docs/teilprojekte.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 1ad82e2..6171a9c 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -1472,8 +1472,9 @@ Grafana **nie gab**. Im FQDN-Smoke-Test lieferte `grafana.emsenhuber.net` trotzd ⚠️ **Das ist exakt die Falle aus TP16.3 §8, diesmal in freier Wildbahn:** ein Statuscode vom oeffentlichen FQDN sagt nichts ueber das Origin, solange Access davor steht. **Ein toter Dienst sieht monatelang gesund aus.** ⇒ Caddy-Zeile entfernt (16 Sites), **LXC 104 zerstoert** und aus dem -Backup-Job genommen — die **14 PBS-Snapshots bleiben bewusst stehen**, sie sind die einzige Kopie -etwaiger Dashboards. Wiederaufbau spaeter als eigener Punkt, dann nach TP32-Systematik. +Backup-Job genommen. ~~Die 14 PBS-Snapshots bleiben bewusst stehen.~~ **Am 2026-08-25 auf +User-Entscheid ebenfalls weg** — direkt gegen den Datastore gegengeprueft (`ct/104` = 0), nicht nur +gegen `pvesm list --vmid`, dessen Filter nach dem `destroy` nicht mehr aussagekraeftig ist. Wiederaufbau spaeter als eigener Punkt, dann nach TP32-Systematik. #### ✅ Abnahme 2026-08-25 (spaet) — 16 von 16 Sites gegen den Host-Header gemessen Dienst `active`+`enabled`, Probe von einem **zweiten Host** (pve, VLAN20) mit