NAKIVO Backup & Replication
Überwache mit dem Check NAKIVO Backup & Replication Jobs, fehlerhafte Objekte und Repositories direkt aus der Datenbank des NAKIVO Director.
Der Check NAKIVO Backup & Replication liest die PostgreSQL-Datenbank des NAKIVO Director schreibgeschützt aus. Er meldet je Job das Ergebnis des letzten Laufs, das Alter des letzten erfolgreichen Laufs, lange und übersprungene Läufe, fehlerhafte Objekte (VMs) sowie den Zustand und freien Speicherplatz der Backup-Repositories. Der Check läuft alle 60 Minuten auf dem octoja-Agenten unter Windows, Linux und macOS (jeweils als x64- und Arm64-Build). Er verbindet sich per Netzwerk mit PostgreSQL und kann deshalb auf jedem Agent-Gerät laufen, das die Datenbank erreicht.
Voraussetzungen
- Der octoja-Agent erreicht die PostgreSQL-Datenbank des NAKIVO Director über Host und Port. Läuft der Check auf dem Director selbst, verwende
127.0.0.1. - Eine eigene Datenbankrolle mit Lesezugriff auf die NAKIVO-Datenbank. Der Check liest die Tabellen
jobs,jobexecutions,jobexecutionsummary,jobexecutionsteps,backuprepositories,backuprepositorystateinfo,backuprepositorystatsundsavepoints. - Die Berechtigung Monitoring-Check-Verwaltung, um den Check hinzuzufügen.
Schritte
Füge den Check auf dem Gerät hinzu, das die Datenbank erreicht – in der Regel auf dem Director selbst.
- Öffne das Gerät unter Geräte.
- Wähle Checks → Check hinzufügen → NAKIVO Backup & Replication.
Für mehrere Director kannst du den Check mit Konfigurationspaketen zuweisen.
Einstellungen
Die folgenden Felder erscheinen erst, wenn du Erweiterte Optionen anzeigen aktivierst:
Sind die Warn- und Kritisch-Schwellen vertauscht eingegeben, tauscht der Check sie vor der Auswertung.
Ergebnisse
Jeder überwachte Job und jedes Repository wird einzeln bewertet. Das schlechteste Einzelergebnis bestimmt den Status des Checks.
Die Altersschwellen gelten mit „mindestens so alt“: Ein Lauf, der genau 26 Stunden zurückliegt, löst bei Standardwerten bereits die Warnung aus.
Erfasste Metriken
- Je Job: Name, Zustand des letzten Laufs, ob der Job deaktiviert ist, Alter des letzten erfolgreichen Laufs, Alter des neuesten Recovery Points und die Anzahl geplanter, erfolgreicher, fehlgeschlagener und gestoppter Objekte des letzten Laufs
- Je Repository: Name, ob es angehängt und konsistent ist, Kapazität, freier Speicherplatz in GB und Prozent
- Bis zu 20 Objekte mit den meisten fehlgeschlagenen oder gestoppten Läufen im Auswertungsfenster
- Anzahl deaktivierter und nie gelaufener Jobs sowie vergangener Läufe mit Objektfehlern, unerklärter Skips, langer Läufe und Objekte ohne Datenübertragung
Hinweise
- Der Check öffnet eine schreibgeschützte Sitzung und prüft vor dem Lesen, ob der Server sie übernommen hat. Andernfalls bricht er ohne Datenzugriff ab.
- Ein deaktivierter oder noch nie gelaufener Job wird nur gemeldet, wenn die jeweilige Alarm-Option aktiviert ist. Andere Prüfungen entfallen für diese Jobs.
- Die Zeitplan-Lücken-Erkennung braucht mindestens vier Läufe im Auswertungsfenster und greift nur, wenn für den Job nicht bereits eine Altersmeldung vorliegt. Setze bei gemischten täglichen und wöchentlichen Zeitplänen beide Altersschwellen auf
0und verlasse dich auf die Zeitplan-Lücken-Erkennung.
Siehe auch: Alarmierung für einen Check einrichten
War dies hilfreich?
Mehr in Backup
Acronis BackupAcronis Cyber Protect CloudAltaro BackupArcserve UDPBrauchen Sie noch Hilfe? Team fragen