NetWorker : Guide de dépannage d’Azure Snapshot Protection

NetWorker 19.11 a introduit la protection des snapshots Azure dans NetWorker. Cette intégration implique l’installation du logiciel NetWorker Extended-Client sur des machines virtuelles (VM) Azure. Les clients sont ajoutés sur le serveur NetWorker à l’aide du type « Cloud ». Le système de fichiers local du client n’est pas sauvegardé. Au lieu de cela, les savesets sont configurés en tant que RESOURCE_GROUP:VM_NAME. Ces clients agissent en tant que « proxys » et effectuent des sauvegardes client directes des snapshots de machines virtuelles Azure vers le stockage Data Domain. Pour plus d’informations sur les configurations et les limitations, reportez-vous au Guide d’intégration des snapshots de machines virtuelles Azure spécifique à la version de NetWorker. La documentation NetWorker est disponible via le Support pour NetWorker | Manuels et documents. Vous devez vous connecter au site de support Dell à l’aide de votre compte de support pour avoir accès aux guides NetWorker.

Communication:

• NetWorker nécessite une communication entre le NetWorker Server et les clients « proxy » sur les ports de service NetWorker (7937-9936 par défaut). Voir : 
  • NetWorker : Dépannage des problèmes réseau
  • Processus et ports NetWorker
• Le NetWorker Server et les clients « proxy » doivent disposer des communications de port 111, 3009, 2049, 2052 avec les systèmes Data Domain.
  • Linux : curl -v DD_HOSTNAME:PORT
  • Windows (PowerShell) : tnc DD_HOSTNAME -p PORT

Ressources d’abonnement Azure :

Les abonnements Azure sont enregistrés dans NetWorker à partir de la ligne de commande ou de l’interface utilisateur Web (NWUI) NetWorker :
 

Les abonnements Azure sont également visibles à partir d’un nsradmin sur le serveur NetWorker :

1. À partir d’une invite avec élévation de privilèges, exécutez : nsradmin
2. À partir de l’invite nsradmin, exécutez : print type nsr azure subscription

azure-nve:~ # nsradmin
NetWorker administration program.
Use the "help" command for help, "visual" for full-screen mode.
nsradmin> print type: nsr azure subscription
                        type: NSR Azure Subscription;
                        name: AZURE_SUBSCRIPTION_RESOURCE_NAME;
                     comment: ;
                   tenant id: 94XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX2dd;
             subscription id: 50XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXfe3;
                   client id: 3bXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX38b;
               client secret: *******;
                    endpoint: management.azure.com;
                     command: nsrazure_discovery;
nsradmin> quit

L’ID de client, l’ID d’abonnement, l’ID client et le code secret client sont tous collectés à partir du portail Azure.

Si l’abonnement Azure est visible à partir de nsradmin, mais qu’il est absent de NWUI, consultez :

• • NetWorker : Abonnement Azure manquant dans l’interface NWUI « Impossible de récupérer le secret client »
  • NetWorker : abonnements Azure manquants après la modification de la phrase de passe de la zone de données NetWorker.

Découverte de machines virtuelles Azure :

La découverte des machines virtuelles Azure s’exécute en tant que tâche automatisée qui s’exécute toutes les heures.

Le processus de découverte Azure utilise la commande nsrazure_discovery . 

Les logs du processus de découverte se trouvent sur le NetWorker Server sous :

• • Linux : /nsr/logs/azure_subscription/SUBSCRIPTION-NAME_TIMESTAMP.log
  • Windows (par défaut) : C:\Program Files\EMC NetWorker\nsr\logs\azure_subscription\SUBSCRIPTION-NAME_TIMESTAMP.log

La découverte peut être exécutée à partir de la ligne de commande :

nsrazure_discovery [-D <Debug_level_1-9>] [-s <NW Server>] -n <NSR Azure Subscription Resource Name> [-L] [-r <resource_group>]

Exemple :

azure-nve:~ # nsrazure_discovery -n Azure -L -r DD-PERF
nsrazure_discovery starting on host azure-nve.local.
                Azure Subscription Azure VM List:
| Resource group | VM Name                          | VM Id                                | Location       |
| DD-PERF        | dd-perf-scheduler-osl-longrun    | d4a47d4a-85dd-4e3b-bdbb-58b96b7fcc82 | westus         |
| DD-PERF        | perf-ddperf-client-osl-longrun-0 | 187ac9de-5739-426d-bfb2-720fa92abc0f | westus         |
| DD-PERF        | perf-ddperf-client-osl-longrun-1 | 19fb8c4e-e6c8-4f67-96ec-28c48c2d9629 | westus         |
| DD-PERF        | perf-ddperf-client-osl-longrun-2 | 989144cc-5eae-44b6-9857-b2f062c1230d | westus         |
| DD-PERF        | perf-ddperf-client-osl-longrun-3 | e8adac3a-995a-4d84-b5ef-d751d5ee2512 | westus         |
| DD-PERF        | perf-ddperf-client-osl-longrun-4 | 1d27b303-f5d8-44e0-bb1a-4ffb63260cfe | westus         |
| DD-PERF        | perf-ddperf-client-osl-longrun-5 | b21a902a-e8fc-4f70-8194-a1cab6b8cf19 | westus         |
| DD-PERF        | perf-ddperf-client-osl-longrun-6 | c231e32c-70c3-4739-96b2-e175829a4d28 | westus         |
| DD-PERF        | perf-ddperf-client-osl-longrun-7 | 3d64d531-a472-48b7-9181-c4a1cbc814c8 | westus         |
| DD-PERF        | perf-westus-256tb-1              | 15965ad9-f1fa-4234-91bd-f8669ab9c218 | westus         |
| DD-PERF        | perf-westus-linux-jumpbox        | 6514f563-cb47-4ec4-99a8-d113a2d7af53 | westus         |
| DD-PERF        | azure-ubuntu                     | be6d6dd8-d5b8-43ec-9602-d77e2d6d701a | southcentralus |
| DD-PERF        | azure-win2k22                    | a7b8cc3d-aa7f-4d2b-918f-579fd97a5509 | southcentralus |
| DD-PERF        | perf-ddperf-jumpbox-sles-longrun | 4859e7aa-da2f-4bef-9ba0-cea3ef8f9676 | southcentralus |
| DD-PERF        | test_recover_summary_fix         | 36e9f900-2e17-4bca-af15-590eb0237af5 | southcentralus |
| DD-PERF        | test_recover_summary_fix2        | caa86cba-9eda-4cc1-90bd-8ffa06202874 | southcentralus |
| DD-PERF        | test_recover_summary_wrong       | 7614dc1d-d799-46b3-9881-03927923fea6 | southcentralus |
nsrazure_discovery exiting successfully.

Autorisations:

Les autorisations requises sont documentées dans le Guide d’intégration des snapshots de machines virtuelles Azure sous le processus d’authentification Azure. Si les opérations de sauvegarde ou de restauration échouent avec une erreur liée aux autorisations, vous devez vérifier que les autorisations documentées sont disponibles sur l’abonnement Azure.

Utilisez la commande suivante à partir de Cloud Shell dans le portail de gestion Azure :

az role definition list --custom-role-only true --output json

La commande ci-dessus répertorie tous les rôles personnalisés. Le Guide d’intégration des snapshots de machines virtuelles Azure recommande de créer le rôle avec le nom NWBackupAdminRole. Pour vérifier les autorisations de ce compte, exécutez :

az role definition list --name "NWBackupAdminRole" --output json > NWBackupAdminRole.json

Les erreurs liées aux autorisations s’affichent généralement avec des codes d’erreur HTTP, par exemple :

"Response Code: 403. This request is not authorized to perform this operation"

Problèmes de sauvegarde :

Les sauvegardes Azure sont effectuées à l’aide de nsrazure_save sur le client NetWorker. Le client sauvegarde les disques de machine virtuelle Azure en fonction de RESOURCE_GROUP:VM_NAME Savesets définis dans la ressource Client.

Le nombre de sessions de disque de machine virtuelle exécutées simultanément dépend de la valeur de parallélisme du client dans les propriétés du client.

Les sauvegardes de machines virtuelles Azure réussies s’affichent dans la base de données des supports (mm) comme :

azure-nve:~ # mminfo -avot
 volume        type   client           date     time         size ssid      fl   lvl name
azure_nve.local.dddefault.002 Data Domain azure-nve.local 01/26/26 21:00:11 10 GB 4135066668 cb full DD-PERF:azure-win2k22:Data_Disk-1
azure_nve.local.dddefault.002 Data Domain azure-nve.local 01/26/26 21:00:12 133 GB 4118289452 cb full DD-PERF:azure-win2k22:azure-win2k22_OsDisk_1_423227d3ef284695803c23cd47e8b839
azure_nve.local.dddefault.002 Data Domain azure-nve.local 01/26/26 23:40:26 10 KB 4101521850 cb full Azure

Journaux :

Les logs de sauvegarde se trouvent à l’emplacement des logs de règle sur le NetWorker Server :

• • Linux : /nsr/logs/policy/POLICY_NAME/WORKFLOW_NAME/backup_JOBID_logs
  • Windows (par défaut) : C:\Program Files\EMC NetWorker\nsr\logs\policy\POLICY_NAME/WORKFLOW_NAME/backup_JOBID_logs

Il n’y a qu’un seul journal pour le savefs et un autre journal pour le nsrazure_save processus.

Débogage :

Le débogage peut être activé dans le client NetWorker en ajoutant un niveau de débogage [1-5] au champ Commande de sauvegarde :

Problèmes de restauration :

La restauration de la machine virtuelle Azure est effectuée à l’aide de nsrazure_recover processus. Ce processus est généralement démarré sur le serveur NetWorker lorsque la restauration est démarrée via NWUI.

Comme indiqué dans la section Problèmes de sauvegarde , afin d’effectuer une restauration de machine virtuelle Azure à partir de NWUI, psuedo_saveset doit enregistrer avec succès le fichier Azure saveset. Si le saveset Azure ne parvient pas à se créer, les sauvegardes peuvent sembler manquantes dans NWUI.

Voir : NetWorker : les sauvegardes de machines virtuelles Azure ne s’affichent pas dans l’onglet de récupération NWUI

Le processus général de restauration d’une machine virtuelle Azure est décrit dans : NetWorker : comment effectuer une restauration de snapshot de machine virtuelle Azure à partir de NWUI

Surveillance et journaux :

• • NWUI : Surveillance → restauration des tâches
  • NMC: Sessions actives
  • Ligne de commande du NetWorker Server : nsrwatch
  • Surveillez le log de restauration :
    • Linux NetWorker Server : /nsr/logs/adhoc/adhoc_job_JOBID
    • NetWorker Server Windows (chemin par défaut) : C:\Program Files\EMC NetWorker\nsr\logs\adhoc\adhoc_job_JOBID

Les journaux terminés sont répertoriés sous :

• • • Linux : /nsr/logs/adhoc/nsrazure_recover
    • Windows (par défaut) : C:\Program Files\EMC NetWorker\nsr\logs\adhoc\nsrazure_recover

Vous pouvez également obtenir des informations spécifiques sur la récupération à partir de jobquery.

1. À partir d’une invite élevée sur le serveur NetWorker, exécutez : jobquery
2. À partir de l' jobquery Invite, exécutez : print type: recover job

Exemple :

azure-nve:~ # jobquery
NetWorker jobs query utility.
Use the "help" command for help.
jobquery> show command; job id; start time; end time; job log file; job state; completion status
jobquery> print type: recover job
                     command: \
"nsrazure_recover -N 'Azure' -R 'DD-PERF' -A 'networkerstorageaccount' -n 'DD-\
PERF:azure-win2k22' -V 'azure-win2k22-RESTORE' -E 'DPADDFS-storage-pe-vnet' -T\
 'DPADDFS-storage-pe-subnet-1' -c 'azure-nve.local' -t \"01/26/2026 11:40:26 P\
M\" -D5";
           completion status: succeeded;
                    end time: 1769383282;
                      job id: 2912131;
                job log file: /nsr/logs/adhoc/nsrazure_recover/2912131.log;
                   job state: COMPLETED;
                  start time: 1769377505;
jobquery> q
azure-nve:~ #

Débogage :

Le débogage peut être appliqué dans l’Assistant de restauration NWUI :

Les restaurations par ligne de commande peuvent également être effectuées à l’aide du débogage :

• • NetWorker : comment effectuer une restauration de snapshot de machine virtuelle Azure à partir de la ligne de commande
  • NetWorker : Comment effectuer une restauration en mode fichier sur une machine virtuelle Azure à l’aide de nsrazure_flr_recover commande

Problèmes de performances :

Pour la protection des machines virtuelles Azure, il est important de comprendre les composants sous-jacents impliqués. Les performances peuvent être considérablement affectées en fonction de différents facteurs :

• • Certaines tailles de machines virtuelles sont soumises à des limitations qui peuvent avoir un impact sur la cohérence des snapshots ou le délai d’expiration. Les disques volumineux peuvent nécessiter des temps de gel de snapshot plus longs. Azure prend cela en compte dans le temps d’exécution de la sauvegarde.
  • Les sauvegardes de machines virtuelles Azure sont uniquement prises en charge sur les périphériques Data Domain. 
    • Le système Data Domain est-il un Data Domain physique ou DD Virtual Edition (DDVE) dans le Cloud Azure ?
    • Pour DDVE, le type de DDVE (dimensionnement) et la configuration du disque peuvent avoir un impact sur les performances de lecture/écriture.
  • Environnement Azure :
    • Est-ce que tout (NetWorker Server, NetWorker Client, machines virtuelles Azure sauvegardées, Data Domain) se trouve dans le même abonnement Azure ?
    • Configurations de réseau Azure.
    • Le trafic de sauvegarde traverse-t-il les abonnements Azure, les régions Azure ou le WAN ?

Les touches DDPCONCHK L’utilitaire peut être exécuté à partir du client NetWorker pour vérifier les performances d’écriture de DD Boost : NetWorker : Utilisation de l’outil DDPCONNCHK pour tester la connectivité DD ddboost à partir des hôtes
NetWorker pendant DDPCONCHK peut fournir une vue d’ensemble du débit entre le client et DD, mais ne reflète pas une relation 1:1 avec les opérations de sauvegarde ou de restauration.

Collecte de journaux :

1. Collectez les bundles de logs NSRGET à partir du NetWorker Server (et des clients concernés, pour les problèmes de sauvegarde) : NetWorker : utilisation de l’outil de collecte de données NSRGet NetWorker
2. Compressez les journaux spécifiques au processus identifiés dans cet article, ils peuvent ne pas être collectés par NSRGET.
3. En fonction du problème, il peut également être nécessaire de collecter un bundle de support DD :
    

Étant donné que les opérations de protection Azure utilisent NWUI, les problèmes spécifiques aux actions effectuées à partir de NWUI peuvent nécessiter une analyse ou un débogage des journaux NWUI : NetWorker Management Web UI (NWUI) : Guide de tri et de dépannage