Zum Inhalt

Soft-Delete & Papierkorb

Statt Items hart aus der DB zu entfernen, setzt Vesana ein deleted_at-Flag. Items landen im Papierkorb, sind aus normalen Sichten verschwunden, lassen sich 30 Tage lang restaurieren.

Welche Tabellen

8 Tabellen sind soft-delete-fähig:

  • tenants
  • hosts
  • host_services
  • alert_rules
  • notification_channels
  • dashboards
  • collectors
  • monitoring_scripts

Plus wiki_articles (separat, Migration 063+064).

Nicht soft-delete: users (haben active-Flag), profiles und profile_checks (global, Builtins kommen aus Seed).

Spalten

Pro Tabelle:

Feld Bedeutung
deleted_at Zeitstempel (NULL = aktiv)
deleted_by UUID des Users
deletion_batch_id gruppiert kaskadierende Deletes

apply_filters() in auth.py filtert automatisch deleted_at IS NULL weg — normale Endpoints sehen nichts gelöschtes.

Kaskade

Wenn ein Host gelöscht wird:

  • Host bekommt deleted_at
  • Alle host_services des Hosts ebenfalls — mit gleicher deletion_batch_id

Wenn ein Tenant gelöscht wird:

  • Tenant + alle Kinder (Hosts, Services, Alert-Rules, Channels, Dashboards) bekommen das gleiche deletion_batch_id

Beim Restore wird die ganze Familie wieder reaktiviert.

Papierkorb-UI

/trash zeigt alle gelöschten Items mit:

  • Tabs nach Typ (Hosts, Services, Alert-Rules, …)
  • Badge mit Anzahl
  • Zeitpunkt der Löschung
  • Author
  • Restzeit bis Auto-Purge (Countdown)
  • Restore- und Endgültig löschen-Buttons

Restore

Voraussetzung: Eltern-Item existiert (oder wird mit-restauriert).

Beispiel: Host wurde gelöscht, dabei auch Tenant. Wenn du jetzt nur den Host restaurieren willst — geht nicht, weil sein Tenant fehlt. Du musst den Tenant zuerst restaurieren (oder beide gemeinsam, was die Bulk-Funktion automatisch macht).

flowchart LR
    P[Tenant deleted] --> R{Restore Hosts?}
    R -->|Tenant fehlt| FAIL[Fehler — erst Tenant restaurieren]
    R -->|Tenant ok| OK[Host + alle deletion_batch_id Kinder zurück]

Endgültig löschen

Vor 30 Tagen Auto-Purge: explizites „Endgültig löschen" entfernt das Item aus der DB. Hypertable-Daten (check_results, logs) werden für den Service nicht mit-gelöscht, aber sie zeigen auf einen nicht-existierenden Service und sind aus normalen Sichten verschwunden — Auto-Cleanup räumt sie irgendwann via Retention.

Auto-Purge

Background-Job läuft täglich um 04:00 UTC:

  1. Alle deleted_at < NOW() - 30 days finden
  2. Hypertables für diesen Eintrag löschen
  3. Item aus der Tabelle entfernen
  4. Audit-Eintrag schreiben

Reihenfolge wichtig: Hypertables zuerst, weil ein Cascade-Delete sie nicht automatisch räumt.

Agent / Collector / Token

Item Soft-Delete Token-Verhalten
Host (mit Agent-Token) Token deaktiviert (active=false) Bei Restore reaktiviert
Collector (mit API-Key) Key deaktiviert Bei Restore reaktiviert

Damit ist ein versehentlicher Soft-Delete reversibel auch für Tokens. Hard-Delete (manuell oder nach 30 d) entfernt den Token-Hash für immer — der zugehörige Agent meldet sich dann mit 401.

Permissions

Permission Wirkung
trash.view Papierkorb sehen
trash.restore Items zurückholen
trash.purge endgültig löschen

trash.purge sollte nur für Admin-Rollen — der Schutz vor Versehen ist die Hauptfunktion des Papierkorbs.

Audit

Soft-Deletes und Restores stehen im Audit-Log mit action = <kind>.delete / restore.

Edge-Cases

Bestehende Alerts bei Soft-Delete

Wenn ein Service mit aktivem Hard-CRIT soft-deleted wird:

  • Notifications stoppen sofort (Service nicht mehr in der Auswertung)
  • Bestehende Alerts werden nicht „gelöscht" — sie verbleiben im Verlauf
  • Restore: Service zurück, Status wird neu ausgewertet beim nächsten eingehenden Result

Wiki-Artikel mit Service-Verknüpfung

Wenn ein Service gelöscht wird, dem Wiki-Artikel verknüpft sind: die Junction-Einträge bleiben erhalten, beim Restore funktionieren die Links wieder.

Anschluss