NetWorker: Azure-VM-Backupworkflow schlägt am Ende des Backups auf Pseudo_saveset fehl

Azure-VM-Momentaufnahme-Backups abgeschlossen; Der Workflow schlägt jedoch am Ende des Backups fehl.

Der folgende Fehler wird im Backupaktionsprotokoll angezeigt:

• Linux: /nsr/logs/policy/POLICY_NAME/WOKFLOW_NAME/backup_JOBID.raw
• Windows (Standardeinstellung): C:\Program Files\EMC NetWorker\nsr\logs\POLICY_NAME\WOKFLOW_NAME\backup_JOBID.raw
• NetWorker: Wie benutzt man nsr_render_log zum Rendern .raw Protokolldateien

174900 MM/DD/YY HH:mm:SS  1 5 0 2442626880 17965 0 NETWORKER_SERVER_NAME savegrp NSR notice Step (5 of 5): Creating a pseudo_saveset job for all the configured clients.
174901 MM/DD/YY HH:mm:SS  1 5 0 2442626880 17965 0 NETWORKER_SERVER_NAME savegrp NSR notice Creating a save job for the save set 'pseudo_saveset' on the host 'NETWORKER_SERVER_NAME'.
174895 MM/DD/YY HH:mm:SS  1 5 0 2442626880 17965 0 NETWORKER_SERVER_NAME savegrp NSR notice Executing a 'pseudo_saveset' job on the host 'NETWORKER_SERVER_NAME'. This job is an anchor save set for the workflow, and will be completed at the end of the client's backup.
83643 MM/DD/YY HH:mm:SS  1 5 0 2442626880 17965 0 NETWORKER_SERVER_NAME savegrp NSR notice NETWORKER_SERVER_NAME:pseudo_saveset                             started
...
174289 MM/DD/YY HH:mm:SS  2 5 0 2442626880 17965 0 NETWORKER_SERVER_NAME savegrp NSR warning Aborting inactive job (1184047) NETWORKER_SERVER_NAME:pseudo_saveset. It has been inactive from 'DAY MONTH DATE HH:mm:SS YYYY'(1756325582) to 'DAY MONTH DATE HH:mm:SS YYYY'(17563DATE399) for 1817 seconds.
128139 MM/DD/YY HH:mm:SS  0 0 2 2442626880 17965 0 NETWORKER_SERVER_NAME savegrp NSR info NETWORKER_SERVER_NAME:pseudo_saveset aborted, inactivity timeout has been reached.
7224 MM/DD/YY HH:mm:SS  1 5 0 2442626880 17965 0 NETWORKER_SERVER_NAME savegrp NSR notice NETWORKER_SERVER_NAME:pseudo_saveset Termination request was sent to job 1184047 as requested; Reason given: Inactive
0491 MM/DD/YY HH:mm:SS  1 5 0 2442626880 17965 0 NETWORKER_SERVER_NAME savegrp NSR notice NETWORKER_SERVER_NAME:pseudo_saveset failed.

Die Backupaktion enthält ein Inaktivitäts-Timeout, dessen Standardwert 30 Minuten beträgt. Standardmäßig gibt es einen Wiederholungsvorgang, aber in einigen Fällen tritt das gleiche Timeout auf oder eine andere Bedingung führt zu einer Unterbrechung des Workflows.

Der obige Fehler zeigt, dass der Job 1817 Sekunden (ca. 30 Minuten) inaktiv war. 

Es gibt viele Bedingungen, die dazu führen können, dass ein Job ein Inaktivitäts-Timeout erreicht. 

Erhöhen Sie das Inaktivitäts-Timeout oder setzen Sie es auf Null, um es vorübergehend zu deaktivieren. Legen Sie eine Baseline für die typische Abschlusszeit jedes Workflows fest, bevor Sie ihn erneut aktivieren. Sobald die Benchmarks vorhanden sind, können Sie wieder geeignete Timeout-Werte einführen, um den Abschluss von Jobs mit der Überwachung von Inaktivität in Einklang zu bringen. 

Wenn das Problem konsistenter ist oder psuedo_saveset aufgrund anderer Probleme fehlschlägt oder abgebrochen wird, beachten Sie Folgendes:

1. Die entsprechende Einstellung für die Serverparallelität wird angewendet: NetWorker: Azure-VM-Snapshot-Backups schlagen fehl "Aktuelle Speichersitzung hat die Parallelität des NetWorker-Servers überschritten"
2. Angemessene Anzahl von VMs und gesamter Datendurchsatz pro Azure-Client. Azure-VMs werden als unter einem NetWorker-Client konfiguriertes Saveset gesichert. Im NetWorker Azure Snapshot Integration Guide Manuals & Documents steht, dass die Clientparallelität auf einen Wert von 1 bis 4 festgelegt werden muss. Diese Parallelität steuert die Anzahl der Festplatten, die Sie gleichzeitig sichern können. 
   1. Stellen Sie sicher, dass genügend Azure-Clientressourcen erstellt werden, um einen effizienten Lastenausgleich für VM-Backups in einem Workflow durchzuführen. Azure-Clients, die viele VMs oder mehrere große VMs enthalten, können viel Zeit in Anspruch nehmen, um die psuedo_saveset abzuschließen, wodurch die Wahrscheinlichkeit eines Inaktivitätstimeouts steigt. Die Anzahl der erforderlichen Clients ist für die Umgebung einzigartig und berücksichtigt die Anzahl der Azure-VMs, die Anzahl der Festplatten, die Größe der Festplatten, die Workflowplanung und die Anzahl der Ziel-Data Domains.
   2. Vermeiden Sie es, Backups mit derselben Azure-Clientressource so zu planen, dass mehrere nsrazure_save -Prozesse, insbesondere für Clients, die viele VMs oder mehrere große Azure-VMs enthalten.