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 <noreply@anthropic.com>
This commit is contained in:
@@ -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
|
⚠️ **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
|
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
|
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
|
Backup-Job genommen. ~~Die 14 PBS-Snapshots bleiben bewusst stehen.~~ **Am 2026-08-25 auf
|
||||||
etwaiger Dashboards. Wiederaufbau spaeter als eigener Punkt, dann nach TP32-Systematik.
|
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
|
#### ✅ 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
|
Dienst `active`+`enabled`, Probe von einem **zweiten Host** (pve, VLAN20) mit
|
||||||
|
|||||||
Reference in New Issue
Block a user