Restauration d'une base de données de serveur jusqu'à un instant précis

Editer en ligne

Pour restaurer l'état d'une base de données de serveur pour IBM Storage Protect à un point de cohérence, vous avez besoin de la sauvegarde intégrale la plus récente avant le point de cohérence. Vous avez également besoin de la sauvegarde incrémentielle créée immédiatement après cette dernière sauvegarde intégrale. Vous pouvez également utiliser des sauvegardes de base de données d'images instantanées pour restaurer une base de données à un point de cohérence spécifique.

Avant de commencer

Important :

Après avoir restauré une base de données de serveur à un point de cohérence, vous devez exécuter la commande PROTECT STGPOOL sur le serveur source avec le paramètre FORCERECONCILE=YES avant d'exécuter les commandes REPAIR STGPOOL ou REPLICATE NODE . La première fois que vous exécutez la commande REPLICATE NODE après une restauration de base de données, assurez-vous d'avoir défini le paramètre FORCERECONCILE=YES.

Lors de la restauration d'une base de données de serveur à un point de cohérence, le serveur peut rencontrer les erreurs suivantes :
  • Dans la base de données du serveur, des enregistrements sont manquants pour certaines données sur disque et sur bande.
  • Dans la base de données du serveur, des enregistrements existent pour des données qui n'existent plus.
Ces incohérences génèrent les erreurs ANR1330E et ANR1331E ou les messages ANR0340E pour les serveurs qui utilisent la réplication de noeud. Pour résoudre ces incohérences, suivez les étapes de cette procédure.

Avant de restaurer la base de données, procédez comme suit :

  1. Recherchez les fichiers de configuration d'infrastructure suivants :
    • Fichier d'options du serveur
    • Fichier historique des volumes
    • Fichier de configuration d'unité
    • sortie des requêtes détaillée sur la base de données et le journal de reprise
  2. Copiez le fichier historique des volumes référencé par le fichier d'options du serveur. La copie de sauvegarde doit posséder un nom de fichier différent du nom indiqué dans le fichier d'options du serveur d'origine. Si la restauration échoue et que vous devez essayer à nouveau la procédure, vous pourriez avoir besoin de la copie de sauvegarde du fichier d'historique de volume. Une fois que la base de données a été restaurée, les informations d'historique des volumes référencées par le fichier d'options du serveur sont perdues. Ces informations sont nécessaires pour identifier les volumes faisant l'objet d'un audit.
  3. Si nécessaire, modifiez le fichier de configuration d'unité en fonction du matériel disponible sur le site de reprise. Le site de reprise requiert peut-être une autre classe d'unités, ainsi que des définitions d'unité et de bandothèque différentes.
Conditions de mise à jour du fichier de configuration d'unité:
Si l'une des conditions suivantes est remplie, vous devrez peut-être mettre à jour manuellement le fichier de configuration des unités sur le site de reprise :
  • Les définitions des chemins sont incluses lorsque le paramètre SRCTYPE=SERVER est défini.
  • Une bandothèque automatique est utilisée sur le site de reprise.
  • Des volumes virtuels de serveur à serveur sont utilisés.

Pour plus d'informations, voir : Mise à jour du fichier de configuration d'unité.

Prévention des incohérences entre les inventaires de volumes: Une restauration à un point de cohérence d'un serveur de gestionnaire de bibliothèque peut créer des incohérences entre les inventaires de volumes du gestionnaire de bibliothèque et des serveurs de client de bibliothèque. Vous devez prendre des précautions pour éviter ce problème. Pour plus d'informations, voir Restauration à un point de cohérence pour un serveur de gestionnaire de bibliothèque.
Prévention du retrait de volumes: Une restauration à un point de cohérence d'un serveur de client de bibliothèque peut entraîner le retrait de volumes de l'inventaire de volumes d'un serveur de client de bibliothèque et leur remplacement ultérieur. Pour plus d'informations, voir Restauration à un point de cohérence d'un serveur de client de bibliothèque.

A propos de cette tâche

Si des fichiers ont été récupérés ou transférés après une sauvegarde, ils peuvent être perdus et l'espace qu’ils occupaient a pu être réutilisé. Dans le futur, pour minimiser cette perte, utilisez le paramètre REUSEDELAY lors de la définition ou de la mise à jour de pools de stockage d'accès séquentiel.

Si votre ancien fichier historique des volumes affiche les conditions suivantes pour les volumes requis pour la restauration des pools de stockage, vous ne pourrez peut-être pas restaurer tous vos fichiers :
  • Volumes de pool de stockage de copie réutilisés. Ces volumes sont répertoriés en définissant le paramètre STGREUSE.
  • Volumes de pool de stockage de copie supprimés. Ces volumes sont répertoriés en définissant le paramètre STGDELETE.
Dans le futur, vous pourrez éviter ce problème en incluant le paramètre REUSEDELAY lorsque vous définissez des pools de stockage de copie.

Pour plus d'informations, voir UPDATE STGPOOL.

Procédure

Pour restaurer la base de données du serveur à un point de cohérence, procédez comme suit :

  1. Si les répertoires de la base de données ou du journal de reprise ont été perdus, recréez-les. Exemple :
    Systèmes d'exploitation LinuxSystèmes d'exploitation AIX
    
mkdir /tsmdb001
mkdir /tsmdb002
mkdir /tsmdb003
mkdir /activelog
mkdir /archlog
mkdir /archfaillog
    Systèmes d'exploitation Windows
    
mkdir e:\tsm\db001
mkdir f:\tsm\db001
mkdir f:\tsm\db001
mkdir h:\tsm\activelog
mkdir i:\tsm\archlog
mkdir j:\tsm\archfaillog
  2. Facultatif: Pour empêcher les opérations client ou serveur d'accéder aux données des volumes de pool de stockage jusqu'à la fin de l'opération de restauration de la base de données, vous pouvez désactiver temporairement les processus de maintenance du serveur et les sessions client. Pour désactiver ces processus, démarrez le serveur en mode maintenance. Pour plus d'informations, voir Démarrage du serveur pour les tâches de maintenance ou de reconfiguration.
  3. Exécutez la commande DSMSERV RESTORE DB . Par exemple, pour restaurer la base de données à une série de sauvegardes créée le 19 avril 2016, exécutez la commande suivante :
    dsmserv restore db todate=04/19/2016

    Vous pouvez utiliser plusieurs paramètres avec la commande DSMSERV RESTORE DB. Par exemple, si votre environnement utilise des pools de stockage de conteneur chiffrés dans un environnement de cloud, vous pouvez utiliser les paramètres RESTOREKEYS et PASSWORD. D'autres paramètres spécifient les chemins d'accès utilisés pour la base de données et les informations de journalisation et la possibilité de prévisualiser l'opération. Pour plus d'informations, voir DSMSERV RESTORE DB.

    Le serveur exécute les actions suivantes :
    1. Lecture du fichier historique des volumes permettant de localiser la dernière sauvegarde complète effectuée avant ou à la date et l'heure spécifiées.
    2. A l'aide du fichier de configuration des unités, demandez un montage du premier volume. Le premier volume contient le début de la sauvegarde complète.
    3. Restauration des données de sauvegarde du premier volume.
    4. Poursuivez par la demande des montages et restaurez les données à partir des volumes de sauvegarde qui contiennent la sauvegarde complète et les sauvegardes incrémentielles exécutées à la date indiquée, ou avant celle-ci.
  4. Exécutez la commande QUERY VOLHISTORY pour obtenir la liste de tous les volumes qui ont été réutilisés, ajoutés et supprimés depuis la sauvegarde d'origine. Utilisez cette liste pour exécuter les étapes restantes de cette procédure. Il se peut que le fichier de configuration des unités dans la base de données restaurée doive également être mis à jour. Pour vous assurer que les volumes sont correctement audités dans la base de données restaurée, vous pouvez temporairement désactiver l'accès aux volumes séquentiels de la liste jusqu'à ce que les étapes restantes de cette procédure soient terminées.
  5. Facultatif: Pour désactiver temporairement l'accès aux volumes séquentiels, exécutez la commande suivante:
    UPDATE VOLUME volume_name ACCESS=UNAVAILABLE

    Si vous désactivez l'accès aux volumes, vous devez exécuter la commande suivante avant d'exécuter les commandes AUDIT VOLUME dans les étapes restantes :

    UPDATE VOLUME volume_name ACCESS=READONLY
  6. Exécutez la commande AUDIT VOLUME et spécifiez le paramètre FIX=YES pour les types de volume suivants:
    • Tous les volumes de disque
    • Les volumes réutilisés et les volumes supprimés des volumes TAPE, VTL et FILE non dédoublonnés
    Le processus de volume d'audit identifie les fichiers enregistrés dans la base de données qui ne figurent plus sur un volume. Si une copie du fichier se trouve dans un pool de stockage de copie ou un pool de stockage de données actives, le fichier du volume faisant l'objet de l'audit est marqué comme endommagé. Sinon, le fichier est supprimé de la base de données et ses données sont perdues.
    Audit des volumes FILE dans un pool de stockage dédoublonné: N'exécutez pas la commande AUDIT VOLUME avec le paramètre FIX=YES sur les volumes FILE dans un pool de stockage dédoublonné. Pour plus d'informations sur les considérations spéciales relatives aux volumes FILE dans un pool de stockage dédoublonné, voir l'étape 9.d dans cette procédure.
  7. Si le processus d'audit de volume détecte des fichiers endommagés, exécutez la commande RESTORE STGPOOL pour restaurer les fichiers.
  8. Procédez comme suit :
    1. Marquez les volumes introuvables comme supprimés de la base de données. Pour marquer les volumes comme supprimés, vous pouvez utiliser la commande DELETE VOLUME avec le paramètre DISCARDDATA=YES. Cette action supprime les entrées de base de données qui permettent au serveur d'accéder aux fichiers sur le volume si les fichiers sont ultérieurs.
    2. Si votre environnement de stockage inclut des pools de stockage de conteneur de répertoire, des étapes supplémentaires risquent d'être nécessaires pour récupérer des données dans les pools de stockage. Pour des instructions, voir Reprise après une perte de données ou des indisponibilités du système.
    3. Si la réplication de noeud est configurée dans votre environnement système, examinez les informations et prenez les mesures appropriées. Une restauration de base de données avec point de cohérence d'un serveur de réplication source désactive les opérations de réplication provenant du serveur source pour empêcher la suppression des éventuelles copies de données qui existent sur les serveurs de réplication cible. Pour protéger les données existant sur les serveurs de réplication cible, déterminez si les copies de données situées sur le serveur de réplication cible sont nécessaires. Dans ce cas, vous devez répliquer les données du serveur de réplication cible sur le serveur de réplication source. Suivez les étapes du message ANR0340E.
    4. Pour les volumes FILE d'un pool de stockage dédoublonné, vous devez effectuer d'autres actions. Suivez les instructions de la note technique 1883611.
    5. Récupérez les autres volumes des sauvegardes de pool de stockage de copie. Si aucune sauvegarde n'est disponible, supprimez les volumes de la base de données à l'aide de la commande DELETE VOLUME avec le paramètre DISCARDDATA=YES .
  9. Redéfinissez tous les volumes du pool de stockage ajoutés depuis la sauvegarde de base de données.

Etape suivante

  • Après une opération de restauration de base de données sur un serveur de réplication source ou cible, exécutez la commande PROTECT STGPOOL sur le serveur source avec le paramètre FORCERECONCILE=YES avant d'exécuter les commandes REPAIR STGPOOL ou REPLICATE NODE . Pour plus d'informations, voir PROTECT STGPOOL.
    Exécution de la commande REPLICATE NODE: Si vous prévoyez d'exécuter la commande REPLICATE NODE après une restauration de base de données, veillez à définir le paramètre FORCERECONCILE=YES pour le premier appel après l'opération de restauration de base de données.
  • Après une restauration, les inventaires de volume du serveur et de votre système de gestion de bande risquent d'être incohérents. C'est notamment le cas si vous ajoutez un nouveau volume au serveur après une sauvegarde de base de données. L'inventaire du système de gestion de bande enregistre le volume comme appartenant au serveur. Si la base de données est restaurée à partir de la sauvegarde, le serveur ne contient aucun enregistrement du volume ajouté contrairement au système de gestion de bande. Synchronisez ces inventaires. De même, les inventaires de volume du serveur et des bandothèques automatiques risquent d'être également incohérents. Exécutez la commande AUDIT LIBRARY pour synchroniser ces inventaires.
  • Lorsque vous restaurez une base de données sur un serveur qui utilise des volumes virtuels, vous devez résoudre les différences entre les volumes virtuels du serveur source et les fichiers archivés du serveur cible. Pour plus d'informations, voir RECONCILE VOLUMES.
  • Si le serveur source n'est plus synchronisé avec le serveur d'annuaire LDAP, des erreurs inattendues sont susceptibles de se produire. Pour synchroniser les données, exécutez la commande AUDIT LDAPDIRECTORY . Pour plus d'informations, voir AUDIT LDAPDIRECTORY.
  • Une opération de restauration de base de données avec point de cohérence peut invalider la clé de vérification serveur à serveur. Exécutez la commande suivante pour créer une clé de vérification de serveur à serveur :
    UPDATE SERVER server_name FORCESYNC=YES

    Pour plus d'informations, voir UPDATE SERVER.