Einen Arcserve UDP-Check konfigurieren

Einen Arcserve UDP-Check konfigurieren

Der Arcserve UDP-Check liest die Konsolendatenbank von Arcserve UDP und meldet den Backup-Zustand jedes geschützten Knotens an einer Stelle: wie alt der neueste Recovery Point ist, wie viele Recovery Points existieren, das Ergebnis des letzten Backup-Jobs und wie viel Platz am Backup-Ziel noch frei ist. Ein Check deckt deine gesamte UDP-Landschaft ab — auf den geschützten Knoten selbst installierst du nichts.

Weil der Check mit SQL Server spricht und nicht mit Arcserve, passiert fast die gesamte Einrichtung auf der Datenbankseite: die richtige SQL-Instanz finden und dem Check Lesezugriff geben. Darum geht es in diesem Artikel. Die Schwellenwerte stehen im Check-Editor selbst, und Schritt 3 weiter unten erklärt, was jeder von ihnen tut.

Den Agent auf dem Konsolenserver installieren

Das ist die Entscheidung, die bei diesem Check die meiste Zeit kostet — triff sie also zuerst. Der Check braucht einen Netzwerkweg zu der SQL Server-Instanz, die die Datenbank arcserveUDP hält, und ein Login, das daraus lesen darf — eine Arcserve-Rolle auf dem Gerät, auf dem er läuft, erkennt oder verlangt er nicht. In der Praxis ist die Maschine mit der Arcserve UDP Console der richtige Ort dafür, denn der mitgelieferte Standardwert localhost\ARCSERVE_APP zeigt auf das Gerät, auf dem der Check läuft, und bei einer Standardinstallation liegt diese Instanz auf der Konsole. Geräte, die wie Kandidaten aussehen, es aber nicht sind:

• ein geschützter Knoten. Knoten führen einen UDP-Agent aus, die Konsolendatenbank liegt aber nicht dort
• ein Recovery Point Server, der nicht zugleich die Konsole ist, falls du diese Rollen auf mehrere Maschinen verteilt hast — aus demselben Grund
• jedes Gerät ohne Netzwerkweg zur SQL-Instanz, falls deine Konsolendatenbank auf einen separaten SQL Server verschoben wurde

Liegt die Konsolendatenbank tatsächlich auf einem separaten SQL Server, brauchst du auf diesem Datenbankserver keinen Agent. Belasse den Check auf dem Konsolenhost (oder auf einem beliebigen Windows-Gerät, das die Instanz erreicht) und richte ihn über den Hostnamen auf die Datenbank.

Voraussetzungen

• Arcserve UDP Console auf einem Windows-Server installiert
• Der octoja-Agent auf einem Windows-Gerät installiert — üblicherweise ist das der Konsolenserver selbst, der Check verlangt auf dem Gerät, auf dem er läuft, aber keine Arcserve-Rolle. Er wird nur für Windows veröffentlicht, ein Linux- oder macOS-Agent erhält ihn also nie
• Netzwerkzugriff vom Agent zu der SQL Server-Instanz mit der Konsolendatenbank
• Ein Login, das drei Tabellen in dieser Datenbank lesen darf (wird weiter unten angelegt)
• Ein octoja-Konto mit der Berechtigung Monitoring-Check-Verwaltung — sie ist nötig, um einem Gerät einen Check hinzuzufügen

Schritt 1 — Die SQL-Instanz finden

Der Check wird mit den Werten ausgeliefert, die eine Standardinstallation von Arcserve UDP erzeugt: Instanz localhost\ARCSERVE_APP, Datenbank arcserveUDP. Viele Installationen brauchen hier gar keine Änderung — prüfe es trotzdem, statt es anzunehmen, denn ein falscher Instanzname bedeutet, dass der Check die Datenbank nie erreicht. Geht es schief, zeigt das Ergebnis den rohen Fehlertext von SQL Server, ein falscher Instanzname und ein Rechteproblem lesen sich also unterschiedlich — die Tabelle unter Fehlerbehebung trennt beides.

Liste auf dem Konsolenserver die installierten SQL Server-Instanzen auf:

Get-Service 'MSSQL*' | Select-Object Name, DisplayName, Status

Eine benannte Instanz läuft als Dienst mit dem Namen MSSQL$<instance>, der Teil nach dem $ ist also der Instanzname — MSSQL$ARCSERVE_APP zu sehen bestätigt, dass der Standardwert des Checks stimmt. Die unbenannte Standardinstanz ist die Ausnahme: Der zugehörige Dienst heißt schlicht MSSQLSERVER, ohne $ und ohne Instanznamen.

Bestätige dann den Datenbanknamen auf dieser Instanz. Arcserve nennt sie arcserveUDP:

SELECT name FROM sys.databases ORDER BY name;

Eine benannte Instanz auf einem anderen Server. Um SQLHOST\INSTANCE zu erreichen, muss der Client die Instanz zu einem TCP-Port auflösen, wofür normalerweise der Dienst SQL Server Browser auf dem Datenbankhost laufen muss. Läuft er nicht und kannst du ihn nicht starten, trage die Instanz als Host, Komma, Port ein — zum Beispiel SQLHOST,1433 — und überspringe die Auflösung ganz.

Schritt 2 — Dem Check Lesezugriff geben

Der Check liest ausschließlich. Er führt ein einziges SELECT gegen drei Tabellen der Konsolendatenbank aus: dbo.as_edge_host, dbo.as_edge_host_d2dStatusInfo und dbo.as_edge_recovery_point_summary. Er schreibt nie, und er fasst die Arcserve-Konfiguration nie an.

Wähle eine der beiden Optionen unten und führe die Anweisungen auf der Konsoleninstanz mit einem Konto aus, das Logins anlegen darf (ein SQL Server-sysadmin).

Option A — Windows-Authentifizierung

Lässt du SQL-Benutzername und SQL-Passwort leer, verbindet sich der Check mit der Identität des octoja-Agent-Dienstes. Unter Windows läuft dieser Dienst als LocalSystem, was SQL Server als das Login NT AUTHORITY\SYSTEM sieht. In octoja muss nichts gespeichert werden, und es gibt kein Passwort zu rotieren.

USE master;
IF SUSER_ID('NT AUTHORITY\SYSTEM') IS NULL
    CREATE LOGIN [NT AUTHORITY\SYSTEM] FROM WINDOWS;
GO

USE arcserveUDP;
IF USER_ID('NT AUTHORITY\SYSTEM') IS NULL
    CREATE USER [NT AUTHORITY\SYSTEM] FOR LOGIN [NT AUTHORITY\SYSTEM];
GO

GRANT SELECT ON dbo.as_edge_host TO [NT AUTHORITY\SYSTEM];
GRANT SELECT ON dbo.as_edge_host_d2dStatusInfo TO [NT AUTHORITY\SYSTEM];
GRANT SELECT ON dbo.as_edge_recovery_point_summary TO [NT AUTHORITY\SYSTEM];

Das ist die einfachste Option, wenn Agent und SQL Server auf derselben Maschine liegen. Unhandlich wird sie, wenn nicht: Über das Netzwerk authentifiziert sich LocalSystem als Computerkonto (DOMAIN\CONSOLESERVER$), du müsstest die Rechte also stattdessen diesem Konto geben. Nimm für eine entfernte Konsolendatenbank Option B.

Option B — ein eigenes SQL-Login

Lege ein Login an, das nur für octoja existiert. Das funktioniert unabhängig davon, wo die Datenbank liegt, und du kannst das Passwort rotieren, ohne den Agent anzufassen.

USE master;
CREATE LOGIN octoja_udp_monitor
    WITH PASSWORD = N'ReplaceThisWithAStrongPassword', CHECK_POLICY = ON;
GO

USE arcserveUDP;
CREATE USER octoja_udp_monitor FOR LOGIN octoja_udp_monitor;
GO

GRANT SELECT ON dbo.as_edge_host TO octoja_udp_monitor;
GRANT SELECT ON dbo.as_edge_host_d2dStatusInfo TO octoja_udp_monitor;
GRANT SELECT ON dbo.as_edge_recovery_point_summary TO octoja_udp_monitor;

Ein SQL-Login funktioniert nur, wenn die Instanz SQL Server-Authentifizierung akzeptiert, also im gemischten Modus läuft. Meldet der Check „Login failed for user“, während dich dieselbe Instanz mit einem Windows-Konto bereitwillig hereinlässt, ist der gemischte Modus das, was du prüfen solltest.

Warum nicht einfach db_datareader? Das Login dieser Rolle hinzuzufügen ist eine Zeile kürzer und funktioniert auch — aber es gewährt Lesezugriff auf jede Tabelle der Konsolendatenbank, einschließlich der Knoten- und Zielkonfiguration. Die drei Grants oben sind genau das, was der Check liest, und nicht mehr.

Schritt 3 — Den Check hinzufügen

1. Stelle sicher, dass der octoja-Agent auf dem Arcserve UDP-Konsolenserver installiert ist.
2. Geh zu Geräte und öffne diesen Server.
3. Klicke auf den Reiter Checks → Check hinzufügen → Arcserve UDP.
4. Lass Zu überwachende Knoten leer, um jeden Knoten zu überwachen, den die Konsole kennt. Das ist für die meisten Installationen die richtige Einstellung — neue Knoten werden automatisch erfasst. Fülle das Feld nur aus, wenn du eine Teilmenge willst, und trage die Namen dann so ein, wie die UDP-Konsole sie anzeigt. Beim Abgleich sind Groß- und Kleinschreibung sowie umgebende Leerzeichen egal, die Schreibweise aber nicht.
5. Passe Backup-Alter-Warnung (Stunden), Backup-Alter kritisch (Stunden) und Ziel-Speicherplatz-Warnung (GB) an, wenn deine Backup-Fenster von den Standardwerten (26, 50 und 50) abweichen. Beide Alterswerte werden gegen das Alter des neuesten Recovery Points eines Knotens gemessen — Warnung beim ersten, Kritisch beim zweiten. Der Speicherplatzwert wird mit dem verglichen, was am Backup-Ziel des Knotens übrig ist, und 0 schaltet diesen Alarm ab. Der Editor zeigt Hilfetext unter dem Warnungsfeld und unter dem Speicherplatzfeld, aber nicht unter Backup-Alter kritisch (Stunden).
6. Schalte Erweiterte Optionen anzeigen ein und trage die oben ermittelten Verbindungsdaten ein.
7. Klicke auf Check hinzufügen.

Was löst einen Alarm aus?

Jeder überwachte Knoten wird für sich bewertet, und das schlechteste Knotenergebnis wird zum Status des Checks.

Fehlerbehebung

Tipps

• Der Check läuft alle 60 Minuten. Dieses Intervall ist vom Check fest vorgegeben und lässt sich im Editor nicht ändern — was zum Backup-Monitoring passt, denn der Backup-Zustand ändert sich im Takt eines Backup-Fensters und nicht im Minutentakt.
• Setze Ziel-Speicherplatz-Warnung (GB) auf 0, um diesen Alarm abzuschalten. Das lohnt sich bei deduplizierenden Zielen oder Cloud-Zielen, wo der gemeldete freie Speicherplatz keine aussagekräftige Zahl ist.
• Das Alter eines Knotens wird ab dem neuesten Recovery Point gemessen und ersatzweise ab der letzten Backup-Startzeit, wenn kein Recovery Point erfasst ist — ein Job, der startet und nie einen Wiederherstellungspunkt erzeugt, altert also trotzdem aus.
• Betreibst du mehr als eine UDP-Konsole, installiere den Agent auf jedem Konsolenserver und füge pro Konsole einen Check hinzu. Um dieselben Einstellungen auf einmal überall auszurollen, packe den Check in ein Konfigurationspaket, statt ihn Gerät für Gerät hinzuzufügen.
• Halte das Login nur lesend. Der Check hat keinen Schreibpfad, ein breiterer Grant bringt also nichts und vergrößert nur, was ein abhandengekommener Zugangsdatensatz preisgibt.

Nach dem ersten Check-Intervall erscheint das Ergebnis im Reiter Checks des Geräts: eine Liste der aktuellen Probleme, gefolgt von einer Zeile pro Knoten mit dem Alter des neuesten Recovery Points, der Anzahl seiner Recovery Points und dem freien Speicherplatz an seinem Ziel.

Siehe auch: Checks · Checks mit Konfigurationspaketen zuweisen