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¶

Soft-delete-fähig sind unter anderem:

Tenants
Hosts
Host-Services (Checks)
Sites (Standorte)
Aggregate
Alert-Rules
Notification-Channels
Dashboards
Collectors
Monitoring-Scripts
Wiki-Artikel (eigener Papierkorb-Zweig)
Benutzer (der Benutzername wird beim Löschen sofort wieder frei; der Papierkorb-Eintrag trägt das Löschdatum im Namen)
Geräteprofile, Policies und Symbole (Icons) — mit eigenem Reiter

Profil-Checks hängen am Profil. Die früheren Reiter „Service-Definitionen" und „Vorlagen" gibt es nicht mehr.

Gelöschte Hosts, Collectors und Checks belegen kein Lizenz-Kontingent mehr (ab v1.9.437) — wer löscht, hat sofort wieder Platz.

Spalten¶

Pro Tabelle:

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

Ein zentraler Filter blendet gelöschte Zeilen automatisch aus — normale Endpunkte und Ansichten sehen nichts Gelöschtes, ohne dass jede einzelne Abfrage das selbst berücksichtigen muss.

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¶

Admin → Protokolle & Support → Papierkorb 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¶

Wiederherstellen ist Anlegen. Es gelten dieselben Grenzen wie beim Neuanlegen:

Du brauchst zusätzlich zu trash.restore das Recht, den Typ anzulegen (für einen Host also hosts.create).
Die lizenzierte Hostzahl und das Mandanten-Kontingent werden geprüft — auch für die Checks, die an einem wiederhergestellten Mandanten hängen. Reicht das Budget nicht, nennt die Meldung die freien Plätze und es entsteht nichts halb Wiederhergestelltes.
Ein wiederhergestellter Check startet auf „Wartet auf Daten" statt mit seinem eingefrorenen alten Status.
Ein wiederhergestelltes Gerät hängt nie an einem inzwischen gelöschten Collector; seine Checks laufen sofort wieder über den Active-Checker.

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:

Alle deleted_at < NOW() - 30 days finden
Hypertables für diesen Eintrag löschen
Item aus der Tabelle entfernen
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¶

Der Papierkorb kennt drei Sichtbarkeits-Stufen statt nur Ja/Nein, plus zwei Aktions-Permissions:

Permission	Wirkung
`trash.view_own`	nur selbst gelöschte Items sehen
`trash.view_tenant`	alle gelöschten Items im eigenen Tenant sehen
`trash.view_global`	tenant-übergreifend sehen (Super-Admin-only)
`trash.restore`	Items zurückholen
`trash.purge`	endgültig löschen

Instanzweite Objekte ohne Mandanten-Bezug (Benutzer, Geräteprofile, Mandanten selbst) sieht und löscht nur, wer trash.view_global hat — trash.view_tenant reicht dafür nicht.

trash.purge sollte nur für Admin-Rollen — der Schutz vor Versehen ist die Hauptfunktion des Papierkorbs. trash.view_global bleibt bewusst Super-Admin vorbehalten, da es Tenant-Grenzen überschreitet.

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¶

Audit-Log
Users & Tenants — Delete-Verhalten