NetWorker: RPS-fähiges Cloning schlägt nach dem Upgrade auf 19.11 fehl, wenn der Reverse-DNS-Status des Servers auf "Bann" gesetzt ist

Nach dem Upgrade auf NetWorker 19.11 reagieren Clone-Jobs scheinbar nicht und protokollieren die folgende Meldungsschleife:

01/13/25 16:51:19.000291 nsrclone-D5 find_clone_backend_job(): ENTER
01/13/25 16:51:19.000323 nsrclone-D5 extend_mmd_reservation_all_clone_backend_jobs: ENTER
01/13/25 16:51:19.000335 nsrclone-D5 extend_mmd_reservation_all_clone_backend_jobs: EXIT
01/13/25 16:51:20.001007 nsrclone-D5 extend_mmd_reservation_all_clone_backend_jobs: ENTER
01/13/25 16:51:20.001070 nsrclone-D5 extend_mmd_reservation_all_clone_backend_jobs: EXIT
01/13/25 16:51:21.000097 nsrrecopy-D3 main 0x342e850 wait timed out (locked)

Das Problem tritt in folgenden Fällen auf:

• Server hat umgekehrten DNS-Status: Verboten in der lokalen Agent-Datenbank (nsrladb)
• Der Clone-Job ist so konfiguriert, dass er einen Remote-Storage-Node anstelle des Servers als Quell-Node (Lese-Node) verwendet
• Für den Clone-Job ist RPS erforderlich – entweder global in der NSR-Ressource (Server) festgelegt (deaktivieren Sie RPS-Clone: Nein) oder aufgrund des Saveset-Typs (vProxy/OAPP) automatisch aufgerufen

Der Job wird nicht abgeschlossen, schlägt fehl oder muss abgebrochen werden.

Die Ursache scheint mit Kommunikationsänderungen in NetWorker 19.11 zusammenzuhängen. Mit dem neuen Reverse-DNS-Statuswert können Administratoren Anforderungen für den Reverse-Lookup-Abgleich entfernen, die seit den ersten Versionen von NetWorker enthalten sind.

Diese wichtige Änderung scheint jedoch zu Problemen geführt zu haben, die derzeit untersucht werden. Obwohl der Reverse-DNS-Status nicht standardmäßig "verboten" ist, haben Administratoren, die ihn auf dem Server verwenden, Probleme mit dem RPS-Cloning, wenn ein separater Storage Node verwendet wird.

Die Korrektur wird im Bug NETWORKER-111382 untersucht. Zum Zeitpunkt der Erstellung dieses Artikels wird diese Korrektur frühestens mit NetWorker 19.11.0.5 oder NetWorker 19.12.0.1 verfügbar sein. 

Kurzfristig gibt es drei mögliche Problemumgehungen für das Problem:

• Verwenden Sie den umgekehrten DNS-Status: zwischengespeichert oder nicht zwischengespeichert, anstatt auf dem Server gesperrt zu sein. Wenn Sie derzeit auf die Einstellung "Bann " für nicht rückwärts auflösbare Clientbackups angewiesen sind, um erfolgreich zu sein, müssen Sie sicherstellen, dass für die IP-Adressen dieser Clients Einträge für die rückwärtsgerichtete DNS-Lookupzone erstellt werden, die vom NetWorker-Server und den Nodes abgefragt werden können, damit sie weiterhin funktionieren. Um diese Einstellung auf dem Server zu ändern, führen Sie an einer Eingabeaufforderung mit erhöhten Rechten Folgendes aus: 

(echo . type: nsrla & echo upd reverse DNS state: cached) | nsradmin -p nsrexec -i -

printf ". type: nsrla\nupd reverse DNS state: cached\n" | nsradmin -p nsrexec -i -

Starten Sie dann die Services nach der Änderung neu:

nsr_shutdown
systemctl start networker

net stop nsrexecd /y
net start nsrd
net start gstd
*Starting gstd is only required if NMC server is installed on the same host as the NetWorker server.

• Ändern Sie die Quell- und Ziel-Nodes in der Klonaktion, um den Server (nsrserverhost) anstelle eines Speicher-Node zu verwenden, falls möglich. Für Data Domain-Clone-Jobs ist der Storage Node weitgehend irrelevant, da die Data Domains selbst den Datenverkehr verarbeiten und nur vom Zugriff des Servers auf jede Data Domain abhängig ist.
• Deaktivieren Sie RPS global. Warnung: Dies ist nicht hilfreich bei Saveset-Typen, die RPS erfordern und automatisch im Rahmen des Klonvorgangs aufrufen, z. B. vProxy- und OAPP-Savesets. Wenn Sie diese Saveset-Typen nicht klonen, Reverse-Lookups verboten werden müssen und den Server aus irgendeinem Grund nicht als Node verwenden können, stellt dies eine dritte, wenn auch am wenigsten ideale Option dar (da nach Möglichkeit RPS bevorzugt wird). Führen Sie dazu auf dem Server an einer Eingabeaufforderung mit erhöhten Rechten Folgendes aus: 

(echo . type: nsr & echo upd Disable RPS Clone: Yes) | nsradmin -i -

printf ". type: nsrla\nupd Disable RPS Clone: Yes\n" | nsradmin -i -

Ein Neustart des Dienstes ist nicht erforderlich – der nächste Clone-Job sollte mit deaktivierter RPS gestartet werden.

Informationen zu ähnlichen Problemen mit NetWorker 19.11, die mit Backupfehlern im Zusammenhang mit den neuen umgekehrten DNS-Statuseinstellungen umgehen, finden Sie unter: NetWorker: Nach dem Upgrade auf 19.11 schlägt das Backup fehl und meldet "Hostnamensauflösung fehlgeschlagen"