Runtime Backup Validation

Stand: 2026-05-26

Ziel

runtime_backup_validation_v1 ist der erste produktiv aktivierte Read-only-Golden-Path. Er prüft, ob Backup-Pfade und Restore-Runbooks für die Lanstyle AI Suite sichtbar, plausibel und operativ nutzbar sind.

Der Workflow führt keine Restore-Aktion aus, ändert keine Infrastruktur und liest keine Backup-Inhalte.

Der Workflow ist zusätzlich als Scheduled Read-only Workflow eingebunden. Details: Scheduled Workflows.

Scope

Geprüfte Komponenten:

Komponente	Zweck
agent_runtime_backups	Backups der Agent Runtime und ihrer Betriebsdaten
proxmox_config_snapshot_backup_paths	sichtbare Proxmox Config-/Snapshot-/Backup-Referenzen
npm_backup_paths	NPM API-/DB-/Config-Backup-Pfade
qdrant_snapshots	Qdrant Collection Snapshots
openwebui_backups	Open WebUI Datenbank-/App-Backups
gb10_ollama_config_backups	GB10/Ollama Konfigurationsbackups
mkdocs_gitea_doc_backups	MkDocs/Gitea Doku-Backups
controlled_execution_backups	Controlled-Execution Exporte und Backup-Referenzen
sqlite_lock_db_backup_readiness	SQLite Lock DB Backup-Readiness
audit_logs	Audit- und Betriebslogs

Erhobene Metadaten

Pro Komponente werden nur Metadaten geprüft:

• Pfad
• Sichtbarkeit aus der Runtime
• Existenz
• Zeitstempel des neuesten sichtbaren Backups
• Backup-Alter
• Größe
• Dateirechte
• Restore-Runbook-Referenz
• bekannter Restore-Test-Status
• Risiko und empfohlene Aktion

Zusätzlich können externe Zielsysteme über einen standardisierten Metadaten-Snapshot eingebunden werden. Dieser Snapshot liegt unter:

/var/lib/lanstyle-agent/controlled-execution/backup-metadata/

Schema je Eintrag:

Feld	Zweck
component_id	eindeutige Komponente, z. B. openwebui_backups
backup_type	Art des Backups, z. B. qdrant_collection_snapshots
source_host	Quellsystem, z. B. openwebui-lxc-250
path	Pfad des neuesten sichtbaren Backups
exists	Existenz des Nachweises
latest_timestamp	Zeitstempel des neuesten sichtbaren Backups
age_hours	wird im Validator berechnet
size_bytes	Dateigröße
permissions	Dateirechte
owner	Owner/Group
restore_runbook	zugehörige Restore-Dokumentation
visibility_status	Sichtbarkeitsstatus
risk_level	durch den Validator bewertet
recommended_action	durch den Validator bewertet

Nicht geprüft werden:

• Datei- oder Datenbankinhalte
• Secret-Werte
• Tokenwerte
• Restore-Dumps
• produktive Daten innerhalb eines Backups

Bewertung

Status je Komponente:

Status	Bedeutung
grün	Pfad sichtbar, aktuelles Backup plausibel, Rechte unauffällig
gelb	Pfad sichtbar, aber Backup zu alt, leer oder Restore-Readiness unvollständig
rot	Pfad fehlt oder ist aus der Runtime nicht sichtbar

Ein roter Status bedeutet nicht automatisch, dass kein Backup existiert. Er bedeutet, dass der Golden Path den Backup-Nachweis aus seiner Runtime-Perspektive nicht belastbar sehen kann.

Output

Der Workflow erzeugt:

• unified_operator_response
• backup_readiness_summary
• component_matrix
• risk_summary
• recommended_actions
• changeplan_artifact
• Markdown-Report
• JSON-Report

Artefakte liegen unter dem Controlled-Execution-Artefaktpfad der Agent Runtime.

API

POST /workflow-catalog/runtime-backup-validation
Authorization: Bearer <tools-api-token>
Content-Type: application/json

{}

Alternativ über den Golden-Path-Preflight:

{
  "workflow_id": "runtime_backup_validation_v1",
  "inputs": {},
  "mode": "read_only_live"
}

Sicherheitsgrenzen

• Keine Approval-ID nötig, weil read-only.
• Kein Dependency Lock nötig, außer später optional als read_warning.
• Kein Restore.
• Keine Backups löschen.
• Keine Inhalte lesen.
• Keine Infrastruktur-Writes.

Nächste Verbesserung

Die größte operative Aussagekraft entsteht, wenn alle Backup-Pfade entweder direkt in der Agent Runtime sichtbar sind oder der Workflow über definierte read-only Metadaten-Exporter je Zielsystem ergänzt wird.

Erster produktiver Lauf

Ergebnis am 2026-05-26:

Status	Anzahl
grün	5
gelb	0
rot	5

Grün:

• Proxmox Config-/Snapshot-/Backup-Pfade
• NPM Backup-Pfade
• Controlled Execution Backups
• SQLite Lock DB Backup-Readiness
• Audit Logs

Rot, weil aus der Runtime nicht sichtbar:

• Agent Runtime Backup-Pfade
• Qdrant Snapshots
• Open WebUI Backups
• GB10/Ollama Config Backups
• MkDocs/Gitea Doku-Backups

Empfehlung: Backup-Nachweise dieser Komponenten entweder in die Agent Runtime mounten oder über klar definierte read-only Metadaten-Exporter bereitstellen. Keine Backup-Inhalte in den Report aufnehmen.

Metadaten-Sichtbarkeit

Um keine Runtime-Mounts zu ändern, wurde zunächst die risikoärmste Variante gewählt: regelmäßige read-only Metadaten-Snapshots. Der Snapshot enthält keine Backup-Inhalte, keine Secrets und keine DB-Dumps.

Eingebundene Snapshot-Quellen:

Komponente	Quelle	Variante
agent_runtime_backups	LXC 259, /opt/agent-runtime/backups	lokaler Metadaten-Snapshot
qdrant_snapshots	LXC 259, /opt/agent-runtime/backups/qdrant	lokaler Metadaten-Snapshot
openwebui_backups	LXC 250, /root/ai-stack-backups	Proxmox read-only Metadata Snapshot
gb10_ollama_config_backups	GB10, /home/admin/config-backups	SSH read-only Metadata Snapshot
mkdocs_gitea_doc_backups	LXC 251 und LXC 253	Proxmox read-only Metadata Snapshot

Lauf nach Integration der Metadaten-Snapshots:

Status	Anzahl
grün	9
gelb	1
rot	0

Gelb:

• gb10_ollama_config_backups, weil der neueste sichtbare Backup-Nachweis gruppenschreibbar ist (-rw-rw-r--).

Update 2026-05-26: Die GB10/Ollama-Backup-Rechte wurden ohne Inhaltszugriff gehärtet. Der aktuelle Lauf ist grün:

Status	Anzahl
grün	10
gelb	0
rot	0

GB10/Ollama:

• Backup-Dateien unter /home/admin/config-backups sind nicht mehr gruppen- oder weltbeschreibbar.
• Admin-eigene Backup-Dateien wurden auf 0600 normalisiert.
• Admin-eigene Backup-Verzeichnisse wurden auf 0700 normalisiert.
• Ollama blieb erreichbar; kein Service-Restart wurde durchgeführt.