Plattformbetrieb, Backups und Schnittstellengesundheit überwachen

Zweck und Einsatzbereich

Diese Seite verbindet fünf betriebliche Kontrollbereiche, die gemeinsam betrachtet werden müssen:

Der öffentliche Basisstatus prüft, ob der Anwendungsdienst antwortet und eine einfache Datenbankabfrage gelingt.
Unter Einstellungen → Backups kann ein Plattformadministrator den anwendungsinternen Sicherungsweg konfigurieren, manuell starten und erfolgreiche Datenbanksicherungen zur Wiederherstellung auswählen.
Unter Einstellungen → Schnittstellen zeigt die Schnittstellen-Workbench den gespeicherten Modus, letzten Test und Fehlerzustand jedes konfigurierten Providers.
Deploymentabhängige Laufzeitwerte steuern unter anderem Simulation, Lizenzdurchsetzung, technische API-Dokumentation, Fehlertracking und Providerverfügbarkeit.
Ein interner Nutzungsmesser speichert Verbrauchsereignisse im Hintergrund und erzeugt beim Überschreiten eines KI-Tokenkontingents eine mandantenweite Warnung.

Diese Signale sind keine gegenseitigen Ersatzprüfungen. healthy bestätigt weder Dateispeicher, Backup, Scheduler, Queue noch externen Provider. SUCCESS bestätigt beim anwendungsinternen Backup nur die aktivierte Artefaktprüfung. Live bereit ist keine fachliche Providerquittung. Ein dokumentierter Wiederanlauf erfordert deshalb immer Basisstatus, fachliche Stichprobe, Sicherungsnachweis, Schedulerzustand und Alarmweg.

Voraussetzungen und Berechtigungen

Aufgabe	Plattformadministrator	Betriebsverantwortliche ohne Plattformkonto
Öffentlichen Basisstatus prüfen	Ja	Ja, keine Anmeldung erforderlich
Einstellungen → Backups öffnen, speichern oder manuell starten	Ja	Nein
Wiederherstellung in der Backup-Maske anstoßen	Ja	Nein
Plattformweite Schnittstellenkonfiguration ansehen	Ja	Nur mit eigenem autorisiertem Betriebsweg
Laufzeitwerte, Scheduler, Schlüssel und Offsite-Ziel verwalten	Nicht über die Anwendung	Nur über freigegebenes Deployment- und Secret-Management
Betriebsalarm und Host-/Datenträgerzustand prüfen	Keine eigene Anwendungsansicht	Über den eingerichteten Monitoringkanal

Die sichtbare Backup-Verwaltung ist ausschließlich an das Plattformmerkmal gebunden. Eine Mandantenrolle wie ADMIN oder MANAGER genügt nicht. Umgekehrt ist Betriebsverantwortliche keine belegte Produktrolle; sie bezeichnet hier Personen mit einem getrennt autorisierten Infrastrukturauftrag.

Vor jeder Sicherungsänderung benötigen Sie einen freigegebenen Speicher-, Verschlüsselungs-, Offsite-, Aufbewahrungs- und Restore-Plan. Vor jeder Wiederherstellung benötigen Sie zusätzlich Wartungsfenster, Verantwortliche, dokumentierten Zielstand, aktuelle Sicherung, Rückfallplan und eine getrennte Testumgebung. Ein Restore darf niemals erstmals in Produktion erprobt werden.

Tragen Sie keine Schlüssel, Tokens, Zugangsdaten oder echten Hostdetails in Screenshots, Tickets oder dieses Handbuch ein. Der sichtbare Speicherpfad ist eine Hostkonfiguration und muss in Nachweisen maskiert werden.

Schritt-für-Schritt-Anleitung

Basisgesundheit und Betriebsalarm prüfen

Rufen Sie den freigegebenen Basisstatus über das Betriebsmonitoring auf. Ein erfolgreicher Zustand lautet healthy und enthält die Anwendungskennung sowie eine Version.
Bei unhealthy mit database_unreachable stoppen Sie fachliche Schreibvorgänge und prüfen den Datenbankdienst. Wiederholen Sie nicht wahllos Benutzeraktionen.
Prüfen Sie zusätzlich den vorgesehenen Infrastruktur-Healthcheck. Der bereitgestellte Betriebsprüfer kann Anwendung, Webserver, Datenbankbereitschaft und die Belegung des Anwendungsdatenträgers kontrollieren sowie bei Fehlern einen Chat- oder E-Mail-Alarm auslösen.
Vergewissern Sie sich außerhalb der Anwendung, dass dieser Prüfer tatsächlich geplant ausgeführt wird und der Alarmempfänger erreichbar ist. Das Repository belegt keinen aktiven Timer und keine konkrete Ausführungsfrequenz.
Prüfen Sie bei einem grünen Basisstatus dennoch die betroffene Fachfunktion und den Providerstatus. Der Basisstatus führt keine Anmeldung und keinen externen Schnittstellentest aus.

Sichtbaren Backup-Stand kontrollieren

Öffnen Sie als Plattformadministrator Einstellungen → Backups.
Wählen Sie zuerst Aktualisieren und lesen Sie Letzter Lauf, Letzter Status sowie einen angezeigten Fehler.
Prüfen Sie unter Backup-Läufe Start, Ende, Status und die angezeigte Größe von Datenbank- und Uploadartefakt. Die Liste zeigt höchstens die 30 zuletzt abgefragten Läufe.
Bewerten Sie nur einen Lauf mit SUCCESS und vorhandenem Datenbankartefakt als Kandidaten für einen späteren Datenbank-Restore. Ein Eintrag ersetzt keinen Offsite-, Entschlüsselungs- oder Wiederherstellungstest.
Bleibt Backups werden geladen… dauerhaft sichtbar, behandeln Sie dies als Ladefehler. Die Ansicht zeigt dafür keinen eigenen Fehlerzustand.

Anwendungsinternes Backup konfigurieren und starten

Ändern Sie den Speicherpfad nur nach freigegebener Infrastrukturprüfung. Der aktuelle Weg besitzt keine sichere Pfad-Auswahlliste; ein falscher Wert kann Sicherungen und Aufbewahrungsbereinigung an einen ungeeigneten Ort lenken.
Setzen Sie Aufbewahrung in Tagen zwischen 1 und 365. Die Bereinigung läuft erst nach einem erfolgreichen anwendungsinternen Backup und entfernt alte Dateisystemeinträge, nicht die zugehörigen Verlaufszeilen.
Aktivieren Sie mindestens Datenbank sichern. Uploads sichern ergänzt die Dateien, sofern der konfigurierte Uploadordner vorhanden ist. Ohne Datenbankartefakt bietet die Oberfläche keinen Restore an.
Schalten Sie Automatische Backups aktiv nur ein, wenn ein externer Scheduler für genau diesen anwendungsinternen Runner nachgewiesen ist. Der Schalter selbst plant keinen Lauf.
Wählen Sie Speichern und warten Sie auf Backup-Konfiguration gespeichert.
Starten Sie für einen kontrollierten Test Backup jetzt starten. Ein paralleler Lauf wird mit Es läuft bereits ein Backup abgewiesen.
Wählen Sie anschließend Aktualisieren und prüfen Sie den neuen Lauf. Bei aktivierter Artefaktprüfung muss der Datenbankkatalog lesbar, das Uploadarchiv öffnbar und das Manifest gültig sein, bevor SUCCESS gesetzt wird.

Der sichtbare Weg schreibt Datenbankdump und Uploadarchiv ohne eigene Inhaltsverschlüsselung in den konfigurierten Speicher. Er kopiert nicht automatisch offsite. Die Anwendung enthält zusätzlich einen getrennten betrieblichen Sicherungsweg, der Datenbank und Uploads vor der Ablage asymmetrisch verschlüsselt, Prüfsummen dokumentiert und optional unveränderlich an ein externes Ziel kopiert. Dieser Betriebsweg erscheint nicht in Backup-Läufe und wird nicht durch den sichtbaren Automatikschalter gesteuert. Erst ein freigegebener Betriebsnachweis entscheidet, welcher Weg tatsächlich geplant läuft.

Wiederherstellung vorbereiten

Stellen Sie eine erfolgreiche Wiederherstellung zuerst in einer getrennten Umgebung nach. Prüfen Sie Datenbank, Uploads, Version, Migrationen, Mandantentrennung und fachliche Stichproben.
Beachten Sie: Die sichtbare Restore-Aktion stellt nur das Datenbankartefakt eines anwendungsinternen SUCCESS-Laufs wieder her. Sie stellt das gesicherte Uploadarchiv nicht wieder her und kann verschlüsselte Betriebsartefakte nicht direkt verwenden.
Öffnen Sie Restore nur für den freigegebenen Lauf und vergleichen Sie Zeitpunkt und Lauf-ID mit dem Restore-Plan.
Geben Sie zur Bestätigung RESTORE ein. Wählen Sie Restore ausführen ausschließlich im freigegebenen Wartungsfenster.
Behandeln Sie Restore wurde ausgefuehrt nicht allein als Abnahme. Prüfen Sie danach Dienststatus, Datenbank, Anmeldung, Mandanten- und OE-Trennung, Dateien, Hintergrundjobs und mindestens einen synthetischen Fachablauf.

Der sichtbare Restore stoppt und startet den Anwendungsdienst über den Host. Dieser Ablauf ist dienst- und berechtigungsabhängig; ein vollständiger, automatisierter End-to-End-Nachweis fehlt. Verwenden Sie ihn daher nicht produktiv, bevor ein isolierter Restore-Drill genau diese Ausführungsart bestätigt hat.

Schnittstellengesundheit und Laufzeitmodi prüfen

Öffnen Sie Einstellungen → Schnittstellen und lesen Sie die Kennzahlen Bereit, Blueprint, Simulation und Fehler.
Filtern Sie nacheinander nach Fehler, Simulation und Deaktiviert. Prüfen Sie pro Provider Modus, Letzter Test, Meldung und Latenz.
Ein Test in Simulation speichert Erfolg mit 0 ms und der Meldung Simulationsmodus aktiv — kein echter Verbindungstest. Verwenden Sie ihn niemals als Live-Nachweis.
Bei einem Live-Test bedeuten eine erfolgreiche HTTP-Antwort und gemessene Latenz nur technische Erreichbarkeit des hinterlegten Prüfpfads. Führen Sie zusätzlich den fachlichen Sende-, Empfangs- und Quittungsablauf mit synthetischen Daten aus.
Ein externer Prüflauf kann die gespeicherten Testwerte aller Schnittstellen aktualisieren. Sein vorgesehener ungefährer Takt ist nur als Kommentar vorhanden; ein tatsächlich aktiver Scheduler ist nicht belegt. Ein alter Testzeitpunkt muss deshalb alarmiert und nicht als fortlaufende Überwachung interpretiert werden.
Prüfen Sie im Plattform-Lizenzbereich den sichtbaren Enforcement-Modus. ENFORCE blockiert Lizenzverstöße, AUDIT protokolliert und lässt den Altweg weiterlaufen, OFF setzt nicht durch. Der Wert wird außerhalb der Anwendung konfiguriert.
Lassen Sie durch den Betrieb bestätigen, dass Produktion Simulation sperrt, technische API-Dokumentation deaktiviert, Fehlertracking bewusst konfiguriert und nur freigegebene Provider und Fallbacks verwendet. Die aktiven Zielwerte sind nicht aus dem Repository ableitbar.

Nutzungswarnungen einordnen

Prüfen Sie Nutzungs- und KI-Anzeigen regelmäßig gegen den Provider- oder Abrechnungsnachweis. Der interne Nutzungsmesser arbeitet asynchron und soll den Fachaufruf nicht verzögern.
Bei Überschreitung des monatlichen KI-Tokenlimits erzeugt er höchstens eine mandantenweite Meldung KI-Kontingent überschritten pro Monat.
Diese Warnung ist kein Hard-Limit. KI-Automatisierung läuft weiter; entscheiden Sie anhand des Vertrags- und Kostenprozesses über weitere Maßnahmen.
Wird eine Warnung erwartet, fehlt aber, prüfen Sie Laufzeitprotokoll und Datenbank auf USAGE_QUEUE_FULL beziehungsweise USAGE_BATCH_FAILED. Verlorene In-Memory-Metriken werden nicht automatisch nachgeliefert.

Feldreferenz

Feld	Pflicht	Bedeutung	Validierung
Basisstatus	Systemseitig	Antwort- und Datenbankgrundzustand	healthy bei erfolgreicher einfacher Datenbankabfrage; unhealthy und database_unreachable bei Fehler. Kein Provider- oder Backupnachweis.
Version	Systemseitig	Vom Basisstatus gemeldete Anwendungsversion	Mit freigegebenem Release abgleichen; die Meldung allein bestätigt keinen vollständigen Buildstand.
Speicherpfad	Ja für anwendungsinternes Backup	Lokales Zielverzeichnis des sichtbaren Sicherungswegs	Freitext ohne belegte Pfad-Auswahlliste. Nur freigegebenes, isoliertes Verzeichnis verwenden; in Nachweisen maskieren.
Aufbewahrung in Tagen	Ja	Alter, ab dem lokale Einträge nach erfolgreichem Lauf bereinigt werden	Ganze Zahl von 1 bis 365. Bereinigt Dateisystemeinträge, nicht Verlaufszeilen oder ein externes Ziel.
Datenbank sichern	Nein, für Restore erforderlich	Erstellt einen Datenbankdump	Ohne Datenbankartefakt kein sichtbarer Restore.
Uploads sichern	Nein	Erstellt ein komprimiertes Archiv des konfigurierten Uploadordners	Fehlt der Quellordner, kann der Lauf ohne Uploadartefakt erfolgreich werden. Der sichtbare Restore spielt Uploads nicht zurück.
Automatische Backups aktiv	Ja für manuellen oder vorgesehenen geplanten Anwendungslauf	Erlaubt dem anwendungsinternen Runner die Ausführung	Plant selbst keinen Lauf und steuert nicht den getrennten verschlüsselten Betriebsrunner.
Letzter Lauf	Systemseitig	Abschlusszeitpunkt des zuletzt gespeicherten Laufs	Nur zusammen mit Status, Artefakten und Aktualität bewerten.
Letzter Status	Systemseitig	Zuletzt gespeicherter Zustand SUCCESS oder FAILED	Ein fehlgeschlagener manueller Lauf kann derzeit aus dem Verlauf zurückgerollt werden; Betriebsalarm zusätzlich erforderlich.
Backup-Laufstatus	Systemseitig	RUNNING, SUCCESS oder FAILED	SUCCESS erst nach optionaler Artefaktprüfung. Laufzeile ist kein Entschlüsselungs- oder Restore-Nachweis.
`RESTORE`	Ja für sichtbaren Restore	Bestätigung einer destruktiven Datenbankwiederherstellung	Großgeschrieben exakt eingeben. Ersetzt keine Vier-Augen-Freigabe oder Wartungsplanung.
Schnittstellenstatus	Systemseitig	Bereit, Blueprint, Simulation, Fehler oder Deaktiviert	Aus Aktivität, Modus, Zugangsdaten und letztem Test abgeleitet; Bereit ist keine fachliche Abnahme.
Letzter Test	Systemseitig nach Prüfung	Zeitpunkt des gespeicherten Providerchecks	Alter gegen den freigegebenen Solltakt prüfen. Kein Takt ist im aktuellen Deployment belegt.
Testmeldung / Latenz	Systemseitig	Ergebnis des letzten technischen Prüfpfads	Simulation liefert 0 ms ohne externen Kontakt; Live-Erfolg akzeptiert HTTP-Erfolg, nicht die fachliche Quittung.
Enforcement-Modus	Deploymentwert, sichtbar	Verhalten bei negativer Modulentscheidung	ENFORCE, AUDIT oder OFF; nur außerhalb der Anwendung änderbar.
Simulationsfreigabe	Deploymentwert	Erlaubt simulierte Providerergebnisse	Muss in Produktion ausdrücklich gesperrt sein; der sichtbare Schnittstellenschalter allein ist keine Umgebungsgrenze.
Fehlertracking	Deploymentwert	Optionaler Versand technischer Fehler an den konfigurierten Beobachtungsdienst	Nur aktiv, wenn Zielkonfiguration und Bibliothek verfügbar sind; Standardversand personenbezogener Daten ist deaktiviert.
KI-Tokenlimit	Nein	Monatlicher Vergleichswert für die Kontingentwarnung	Überschreitung erzeugt höchstens eine Warnung je Mandant und Monat, blockiert KI aber nicht.

Status und mögliche Übergänge

Objekt	Ausgang	Auslöser	Ergebnis und Grenze
Basisstatus	Datenbank erreichbar	Prüfung	healthy; andere Komponenten bleiben ungeprüft.
Basisstatus	Datenbank nicht erreichbar	Prüfung	unhealthy mit database_unreachable und technischer Fehlerstatus.
Backup-Konfiguration	Inaktiv	Automatische Backups aktiv und Speichern	Runner darf starten; noch kein Scheduler oder Backup erzeugt.
Backup-Lauf	Start	Sperre frei	RUNNING im laufenden Vorgang.
Backup-Lauf	RUNNING	Erzeugung und gegebenenfalls Verifikation erfolgreich	SUCCESS, Artefaktpfade und Größen werden gespeichert, lokale Retention wird ausgeführt.
Backup-Lauf	RUNNING	Dump-, Archiv-, Pfad-, Sperr- oder Prüffehler	Vorgesehen FAILED; beim sichtbaren manuellen Fehler kann der Datenbankeintrag jedoch zurückgerollt werden.
Backup-Lauf	SUCCESS mit Datenbankartefakt	Bestätigter Restore	Datenbank wird ersetzt und Dienstneustart versucht; Uploadarchiv bleibt unberührt.
Schnittstelle	Aktiv und simuliert	Prüflauf	Gespeicherter Simulationserfolg ohne Providerkontakt.
Schnittstelle	Aktiv und live	Prüflauf erfolgreich	Gespeicherter technischer Erfolg mit Zeitpunkt und Latenz.
Schnittstelle	Aktiv und live	Prüfpfad nicht erreichbar oder abgewiesen	Gespeicherter Fehler; Fachwirkung stoppen und prüfen.
Lizenzprüfung	AUDIT oder OFF	Negative Modulentscheidung	Fachaufruf läuft im Altweg weiter; nur AUDIT protokolliert die Ablehnung.
Lizenzprüfung	ENFORCE	Negative Modulentscheidung	Anfrage oder Hintergrundjob wird abgewiesen.
Nutzungsmetrik	Erzeugt	Queue hat Platz	Wird eingereiht und batchweise gespeichert.
Nutzungsmetrik	Erzeugt	Queue voll oder Persistenzfehler	Metrik wird verworfen beziehungsweise nicht erneut versucht; Fachaufruf bleibt grundsätzlich unberührt.
KI-Kontingent	Verbrauch über Limit	Batchspeicherung	Eine mandantenweite Warnung für den laufenden Monat wird erzeugt; keine Sperre.

Was im Hintergrund passiert

Der Basisstatus ist öffentlich, damit Load Balancer und externe Überwachung ihn ohne Benutzersitzung verwenden können. Er führt genau eine einfache Datenbankabfrage aus. Ein zusätzlicher Betriebsskript kann Dienstzustände, Datenbankbereitschaft und Datenträgerfüllstand prüfen und optional per Chat oder System-E-Mail alarmieren. Ob und wie oft dieser Prüfer in einer Zielumgebung läuft, bleibt deploymentabhängig.

Der sichtbare Backup-Weg erzeugt einen Datenbankdump, optional ein komprimiertes Uploadarchiv und ein Manifest in einem zeitgestempelten Unterverzeichnis. Eine nicht blockierende Dateisperre verhindert parallele Läufe desselben Speicherorts. Bei aktivierter Prüfung werden Datenbankkatalog, Archivlesbarkeit und Manifestformat kontrolliert. Das ist eine Strukturprüfung, kein vollständiger Restore. Der anwendungsinterne Weg verschlüsselt die Artefakte nicht selbst und besitzt keine Offsite-Kopie.

Der getrennte betriebliche Sicherungsweg prüft die Klartextartefakte, verschlüsselt sie mit einem Empfängerschlüssel, dokumentiert Prüfsummen, kann sie unveränderlich an ein externes Ziel kopieren und löscht lokale alte Laufverzeichnisse nach seiner eigenen Aufbewahrungsfrist. Klartext entsteht dabei nur temporär und wird beim Ende bereinigt. Ob Empfängerschlüssel, Offsite-Ziel, Zeitplan, Alarm und Wiederherstellungsgeheimnis korrekt eingerichtet sind, ist nicht in der Anwendung sichtbar. Ein Releaseablauf verlangt vor einer Schemaänderung eine frische verschlüsselte Sicherung; dies belegt keinen regelmäßig aktiven Backup-Timer.

Die sichtbare Aufbewahrung löscht alte Einträge unter dem konfigurierten Speicherstamm anhand des Dateialters. Da der Pfad nicht auf eine freigegebene Wurzel begrenzt wird, darf er nicht frei ausprobiert werden. Gelöschte Artefakte entfernen ihre Verlaufszeile nicht; ein alter SUCCESS-Lauf kann daher weiterhin erscheinen, obwohl seine Datei fehlt.

Der Schnittstellen-Prüfer lädt plattformweite und mandantenbezogene Konfigurationen im kontrollierten Plattformkontext, testet jede einzeln und speichert Zeitpunkt sowie Ergebnis. Simulation antwortet ohne Netzwerkzugriff. Liveprüfungen validieren die Zieladresse, verwenden verschlüsselt gespeicherte Zugangsdaten und TLS und rufen den hinterlegten Gesundheitsweg ab. Der Lauf verarbeitet Einzelproviderfehler weiter; ein übergeordneter Skriptfehler kann den Gesamtlauf abbrechen. Ein Scheduler ist nicht Bestandteil des belegten Deployments.

Laufzeitmodi werden außerhalb der Anwendung verwaltet. Der Umgebungsname begrenzt bestimmte Demo-Startdaten, erzwingt aber nicht in jedem Providerpfad allein die Simulationssperre; dafür muss die separate Simulationsfreigabe korrekt gesetzt sein. Technische API-Dokumentation folgt dem Debugwert. Fehlertracking, Push, Scanner, Backup und externe Provider bleiben ohne vollständige Zielkonfiguration inaktiv oder schlagen geschlossen fehl. Der aktuelle Produktionswert dieser Flags ist nicht aus dem Quellstand ableitbar.

Der Nutzungsmesser verwendet eine begrenzte Warteschlange im Arbeitsspeicher des Anwendungsprozesses und speichert bis zu 100 Ereignisse je Batch. Beim geordneten Herunterfahren wird die Queue geleert. Ein Prozessabbruch, eine volle Queue oder ein fehlgeschlagener Batch kann Metriken verlieren; der Fachaufruf wartet nicht auf die Speicherung. KI-Token werden monatlich gegen das Modulvolumen verglichen. Die resultierende Warnung besitzt keinen Benutzer- oder OE-Bezug und erscheint daher mandantenweit in den KI-Hinweisen. Sie hat derzeit keine eigene typisierte Darstellung, bleibt aber über Titel und Text sichtbar und kann ignoriert werden.

Automatisierte Tests belegen den öffentlichen gesunden Basisstatus, parallele Basisabfragen, die Trennung von Simulation und fehlerhaftem Livebetrieb, Warteschlange und Speicherung des Nutzungsmessers, die nicht blockierende KI-Kontingentwarnung sowie positive und negative Strukturprüfungen von Backup-Artefakten. Shellskripte werden syntaktisch geprüft. Nicht gezielt abgedeckt sind Backup-Rollen und Oberfläche, vollständiger manueller oder geplanter Lauf, Fehlerpersistenz, Pfadgrenze, Aufbewahrungsbereinigung, Verschlüsselung und Offsite-Kopie, Wiederherstellung mit Dienstneustart und Uploads, Schnittstellen-Gesamtrunner, Scheduler, Alarmzustellung, Queueüberlauf und Prozessabbruch.

Typische Fehler und Lösungen

Meldung oder Beobachtung	Ursache	Lösung
unhealthy / database_unreachable	Der Dienst antwortet, aber die Datenbankgrundprüfung ist fehlgeschlagen.	Schreibbetrieb stoppen, Datenbank und Verbindung durch Betrieb prüfen, danach fachliche Stichprobe ausführen.
Basisstatus ist healthy, Fachfunktion fällt aus	Provider, Lizenz, Queue, Dateispeicher oder Fachlogik wird nicht geprüft.	Betroffene Komponente separat prüfen; grünen Basisstatus nicht als Gesamtfreigabe verwenden.
Backups werden geladen… bleibt stehen	Laden der Konfiguration ist fehlgeschlagen; ein eigener sichtbarer Fehlerzustand fehlt.	Nicht speichern oder wiederherstellen. Sitzung und Plattformrecht prüfen, neu laden und Betriebsprotokoll auswerten.
Backup-Konfiguration konnte nicht gespeichert werden	Wert, Plattformrecht oder Serverzugriff wurde abgewiesen.	Aufbewahrung, Pfad und Rolle prüfen; keinen alternativen Pfad ohne Freigabe ausprobieren.
Backups sind deaktiviert	Der Anwendungsschalter ist aus.	Nur mit belegtem Sicherungsplan aktivieren und speichern; danach manuellen Test kontrollieren.
Es läuft bereits ein Backup	Die Dateisperre am Speicherziel ist belegt.	Lauf nicht parallel erzwingen; aktiven Prozess und letzten Start prüfen.
Backup-Verifikation fehlgeschlagen; Lauf wird nicht als erfolgreich markiert	Datenbankdump, Uploadarchiv oder Manifest ist nicht strukturell lesbar.	Artefakt nicht verwenden; Werkzeugversion, Speicher, Rechte und freien Platz prüfen, anschließend neuen Lauf starten.
Manueller Fehler erscheint nicht unter Backup-Läufe	Der Fehler wird an die Oberfläche zurückgegeben, während die Lauftransaktion zurückgerollt werden kann.	Fehlerzeitpunkt extern sichern und Serverprotokoll prüfen; Verlauf nicht als vollständiges Fehlermonitoring behandeln.
Automatik ist aktiv, aber es entsteht kein Lauf	Der Schalter plant keinen Task oder der eingerichtete Scheduler verwendet den getrennten Betriebsrunner.	Aktiven Timer, Runner und letzte Ausführung außerhalb der Anwendung nachweisen.
SUCCESS-Lauf lässt sich nicht wiederherstellen	Artefakt wurde bereinigt, verschoben oder ist kein anwendungsinterner Datenbankdump.	Nicht weiter versuchen; Dateinachweis und Restore-Plan prüfen, gültiges Artefakt in Testumgebung verifizieren.
Restore meldet Dienststopp- oder Werkzeugfehler	Hostdienst, Berechtigung oder Datenbankwerkzeug passt nicht zum vorgesehenen Ablauf.	Restore abbrechen, Dienstzustand sichern und freigegebenen manuellen Wiederanlauf verwenden. Nicht wiederholt klicken.
Datenbank ist wiederhergestellt, Dateien fehlen	Der sichtbare Restore spielt Uploads nicht zurück.	Passendes Uploadartefakt im freigegebenen Betriebsablauf separat wiederherstellen und referenzielle Stichprobe durchführen.
Schnittstelle zeigt Simulation und 0 ms	Es fand kein externer Kontakt statt.	Nur als Simulationspfad werten; kontrollierten Live- und Fachtest separat durchführen.
Fehler beim Laden der Schnittstellen-Konfiguration	Plattform-/Mandantenkontext oder Serverzugriff ist fehlgeschlagen.	Keine Modusänderung vornehmen; Rolle, Zielkontext und Dienststatus prüfen.
Letzter Test ist alt	Periodischer Prüfer läuft nicht, Scheduler fehlt oder Gesamtlauf ist abgebrochen.	Scheduler- und Laufprotokoll prüfen; manuellen Test nur nach fachlicher Freigabe durchführen.
Lizenzverstoß wird nicht blockiert	Enforcement steht auf AUDIT oder OFF.	Sichtbaren Modus dokumentieren und Zielwert kontrolliert außerhalb der Anwendung korrigieren.
Simulation ist in Produktion möglich	Separate Simulationsfreigabe ist falsch gesetzt; der Umgebungsname allein schützt nicht jeden Providerpfad.	Externe Wirkungen stoppen, Laufzeitkonfiguration korrigieren und alle Providerwege erneut testen.
KI-Kontingent überschritten	Monatlicher Tokenverbrauch liegt über dem Modulwert.	Verbrauch und Providerrechnung prüfen; Warnung ist keine Sperre. Kontingent oder Nutzung nach Freigabe anpassen.
Erwartete Nutzungsdaten fehlen	Queue war voll, Batch ist fehlgeschlagen oder Prozess wurde vor Speicherung beendet.	Laufzeitprotokolle und Abrechnung abgleichen; fehlende Metrik nicht als Nullverbrauch interpretieren.