Soft-Delete & Papierkorb¶

Was du löschst, verschwindet nicht sofort aus der Datenbank. Es landet im Papierkorb, ist aus allen normalen Sichten verschwunden und lässt sich 30 Tage lang wiederherstellen. Danach löscht Vesana es endgültig.

Was im Papierkorb landet¶

Der Papierkorb hat einen Reiter je Art:

Tenants
Hosts
Checks (Host-Services)
Benutzer (der Benutzername wird beim Löschen sofort wieder frei; der Papierkorb-Eintrag trägt das Löschdatum im Namen)
Dashboards
Alert-Rules
Benachrichtigungskanäle
Collectors
Monitoring-Scripts
Geräteprofile
Icons
Karten
Status-Seiten, Berichts-Zeitpläne und Wiki-Artikel — nur, solange die jeweilige Vorschau-Funktion eingeschaltet ist

Profil-Checks hängen am Profil. Gelöschte Hosts, Collectors und Checks belegen kein Lizenz-Kontingent mehr — wer löscht, hat sofort wieder Platz.

Kaskade¶

Wird ein Host gelöscht, gehen alle seine Checks mit in den Papierkorb — als eine Löschgruppe. Wird ein Tenant gelöscht, gehen alle seine Objekte (Hosts, Checks, Alert-Rules, Kanäle, Collectors …) mit. Beim Wiederherstellen kommt die ganze Gruppe zurück.

Dashboards gehören einem Benutzer, nicht einem Tenant — sie sind kein Teil der Tenant-Kaskade und bleiben beim Löschen eines Tenants erhalten. Ein Dashboard, das noch aus der Zeit der Tenant-Dashboards ohne Besitzer im Papierkorb liegt, bekommt beim Wiederherstellen einen: seinen Ersteller, wenn der es heute noch sehen darf, sonst den, der es zurückholt. Wird ein Tenant aus dieser Zeit wiederhergestellt, kommen seine Dashboards mit.

Papierkorb-Ansicht¶

Admin → Protokolle & Support → Papierkorb zeigt die gelöschten Einträge, die du sehen darfst:

Reiter nach Art, mit Anzahl
Zeitpunkt der Löschung und wer gelöscht hat
Restzeit bis zum automatischen Löschen
Wiederherstellen und Endgültig löschen, oben Alle löschen

Je nach Recht heißt die Ansicht „Eigener Papierkorb", „Tenant-Papierkorb" oder „System-Papierkorb (alle Tenants)". Außerhalb des Admin-Bereichs gibt es unter /trash den persönlichen Papierkorb mit dem, was du selbst gelöscht hast; endgültig löschen geht nur im Admin-Bereich.

Wiederherstellen¶

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) — und zwar im Tenant des Objekts.
Die lizenzierte Hostzahl und die Grenzen je Tenant werden geprüft — auch für die Checks, die an einem wiederhergestellten Tenant hängen. Reicht das Budget nicht, nennt die Meldung die freien Plätze und es entsteht nichts halb Wiederhergestelltes.
Gibt es inzwischen einen aktiven Host mit demselben Namen, lehnt Vesana das Wiederherstellen mit einer Meldung ab.
Ein wiederhergestellter Check startet auf PENDING 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: Das Eltern-Objekt existiert (oder wird mit wiederhergestellt). Wurde ein Host zusammen mit seinem Tenant gelöscht, stellst du zuerst den Tenant wieder her — der Host kommt dann mit.

Agents, Collectors und Schlüssel¶

Beim Löschen eines Hosts, Collectors oder Tenants fragt Vesana, was mit der Software auf den Geräten passiert:

Installiert lassen (Standard) — Agent bzw. Collector ruht: keine Checks, keine Logs, keine Discovery.
Deinstallieren — er entfernt sich beim nächsten Kontakt vom Gerät. Geräte mit aktiver Lokaler Freigabe lehnen das ab und ruhen stattdessen.

Beim Löschen werden außerdem das Agent-Token des Hosts bzw. die API-Schlüssel des Collectors oder Tenants deaktiviert.

Beim Wiederherstellen:

Schlüssel und Tokens, die durch dieses Löschen deaktiviert wurden, werden wieder gültig. Ein ruhender Agent oder Collector arbeitet dann innerhalb von etwa 5 Minuten von selbst weiter.
Schlüssel und Tokens, die du vorher bewusst widerrufen hattest, bleiben widerrufen. Die Meldung nach dem Wiederherstellen sagt dann, dass ein neues Agent-Token (Host → Agent einrichten) bzw. neue API-Schlüssel nötig sind.
Der Wiederherstellen-Dialog zeigt je Gerät, was passieren wird — kommt von selbst zurück, muss neu installiert werden (war „Deinstallieren" gewählt), Deinstallation wird abgebrochen, oder hat sich seit dem Löschen nicht gemeldet.

Beim endgültigen Löschen halten ruhende Agents und Collectors endgültig an; ihre Dateien bleiben auf dem Gerät. Ein Agent mit gelöschtem Token wird danach abgewiesen.

Endgültig löschen¶

Vor Ablauf der 30 Tage entfernt Endgültig löschen einen Eintrag sofort, mitsamt seinen Messwerten und Logs. Alle löschen leert den ganzen sichtbaren Papierkorb (Bestätigung durch Eintippen von PURGE). Beides verlangt trash.purge und eine frische Identitätsbestätigung.

„Alle löschen" lässt Einträge von Vorschau-Bereichen liegen, die auf der Instanz gerade ausgeschaltet sind. Ein endgültig gelöschter Tenant nimmt auch seine gespeicherten Zugangsdaten, Notizen und offenen Benachrichtigungen mit.

Auto-Purge¶

Einmal täglich (erstmals eine Stunde nach dem Start der API) löscht Vesana alle Einträge endgültig, die länger als 30 Tage im Papierkorb liegen — samt Messwerten und Logs — und schreibt einen Audit-Eintrag.

Permissions¶

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

Permission	Wirkung
`trash.view_own`	nur selbst gelöschte Einträge sehen
`trash.view_tenant`	alle gelöschten Einträge im Tenant sehen; Dashboards nur die eigenen oder selbst gelöschten
`trash.view_global`	tenant-übergreifend sehen — wirkt nur in einer Zuweisung mit Bereich „Alle Tenants"
`trash.restore`	Einträge zurückholen
`trash.purge`	endgültig löschen

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

trash.purge gehört nur in Admin-Rollen — der Schutz vor Versehen ist die Hauptfunktion des Papierkorbs. Die eingebaute Admin-Rolle hat es nicht; standardmäßig darf nur der Super-Admin endgültig löschen.

Audit¶

Löschen, Wiederherstellen und endgültiges Löschen stehen im Audit-Log.

Sonderfälle¶

Offene Alarme beim Löschen¶

Wird ein Check mit aktivem CRITICAL gelöscht:

Benachrichtigungen stoppen sofort (der Check wird nicht mehr ausgewertet)
Bestehende Alarme bleiben im Verlauf
Nach dem Wiederherstellen wird der Status mit dem nächsten Ergebnis neu bewertet

Wiki-Artikel mit Check-Verknüpfung¶

Wird ein Check gelöscht, dem Wiki-Artikel zugeordnet sind, bleibt die Zuordnung erhalten; nach dem Wiederherstellen funktionieren die Links wieder.