Guide du kit de développement logiciel Veritas NetBackup Parallel Streaming Framework pour développeurs
- Protection de vos charges de travail à l'aide de NetBackup Parallel Streaming Framework
- Architecture du plug-in NetBackup Parallel Streaming Framework
- Déploiement du kit de développement logiciel NetBackup Parallel Streaming Framework
- Préparation pour le développement du plug-in
- Gestion des hôtes de sauvegarde
- Utilisation d'un exemple de plug-in
- Développement du plug-in de charge de travail
- À propos de la phase de découverte de la charge de travail
- Déploiement du plug-in de charge de travail
- Références de l'API NetBackup Parallel Streaming Framework
- Consignation et dépannage
À propos de la phase de restauration
Pour un travail de restauration, l'utilisateur sélectionne le serveur NetBackup depuis lequel les objets sont restaurés et le client dont les données de sauvegarde doivent être restaurées. Cette opération exécute un processus bpbrm sur le serveur de médias pour lancer l'opération de restauration sur le serveur NetBackup à partir duquel les objets doivent être restaurés. Vous pouvez restaurer des objets à un même emplacement ou à un emplacement différent. Pour la restauration, un seul hôte de sauvegarde est utilisé. Se reporter à Processus de restauration avec Parallel Streaming Framework.
La tâche de restauration est pilotée par le processus nbtar comme illustré ci-dessous :
En cas de restauration alternative, le chemin d'accès de restauration de l'objet est remplacé par un chemin d'accès de restauration alternatif à partir du chemin d'accès de l'objet sauvegardé.
Par exemple, si le chemin d'accès de l'objet de sauvegarde est
/obj-container1/obj-container2/file.txt
, il est remplacé par/mnt/vol-1/obj-container1/obj-container2/file.txt
où l'emplacement alternatif estmnt/vol-1
L'API aapi_get_object_prop_byname est appelée avec le chemin d'accès de restauration de l'objet afin d'obtenir les propriétés d'objet.
Par exemple, l'API aapi_get_object_prop_byname fournira les propriétés de métadonnées pour
/mnt/vol-1/obj-container1/obj-container2/file.txt
4. Si le chemin d'accès de restauration de l'objet existe déjà et :
L'option d'écrasement est définie sur false, la restauration de l'objet est ignorée.
L'option d'écrasement est définie sur true, l'API aapi_delete_object est appelée pour supprimer l'objet existant.
Un nouvel objet est créé à l'aide de l'implémentation de l'API aapi_create_object.
Les informations d'objet telles que le nom, la taille, l'autorisation, les données u/mtime, le propriétaire sont transmises à l'appel aapi_create_object qui peut être utilisé pour définir les propriétés d'objet.
L'API aapi_create_object est appelée pour tous les objets dans le chemin d'accès de restauration, à partir du premier objet jusqu'à l'objet terminal. Par conséquent, des conteneurs d'objet sont également créés s'ils ne sont pas présents.
Par exemple, pour restaurer
/mnt/vol-1/obj-container1/obj-container2/file.txt
, l'API aapi_create_object est appelée cinq fois, une fois pour chaque valeur dans la hiérarchie./mnt, - conteneur d'objet
/mnt/vol-1 - conteneur d'objet
/mnt/vol-1/obj-container1, - conteneur d'objet
/mnt/vol-1/obj-container1/obj-container2, - conteneur d'objet
/mnt/vol-1/obj-container1/obj-container2/file.txt - conteneur de données
L'objet est restauré en lisant son contenu sauvegardé à partir de l'image de sauvegarde et restauré en appelant l'API aapi_write_object.
Ce processus est effectué de manière itérative et séquentielle jusqu'à ce que l'objet entier soit lu.
L'API aapi_set_object_utimes est appelée pour restaurer les heures d'accès et de modification de l'objet
Une fois tous les objets restaurés, l'API aapi_set_object_utimes est appelée à nouveau pour restaurer les heures d'accès et de modification du conteneur d'objet.
L'objet de données est fermé en appelant l'API aapi_close_object qui effectue le nettoyage de l'objet associé.
Pendant la phase de restauration, les processus NetBackup suivants sont déclenchés séquentiellement :
Le processus bpbrm s'exécute sur le serveur de médias.
Le processus nbtar exécute la sauvegarde sur tous les hôtes de sauvegarde.
Pendant la phase de restauration, les API suivantes sont appelées séquentiellement :
Tableau : Séquence des appels d'API lors de la phase de restauration
Phase |
Appels d'API |
Référence de l'exemple de plug-in |
---|---|---|
Le plug-in s'initialise |
| |
PSF demande le plug-in |
| |
Configuration de la connexion |
| |
Phase de restauration |
| |
Le plug-in se décharge |
|
Outre les erreurs existantes, vous remplissez les journaux personnalisés dans les fichiers journaux de débogage associés.
Se reporter à Activation de la consignation pour le plug-in.
Quand vous testez un plug-in lors du développement, examinez les journaux de la phase de développement correspondante. Le travail peut échouer jusqu'à ce que le plug-in soit créé dans son intégralité. Vous devez vérifier les journaux de réussite pour la phase spécifique.
Par exemple, si vous avez terminé le développement de la phase de découverte, la sauvegarde peut échouer, mais la découverte doit être réussie.
Se reporter à Vérification et test du plug-in au cours du développement.
Se reporter à Processus de restauration avec Parallel Streaming Framework.
Se reporter à À propos de l'exemple de plug-in.