Sauvegarde et restauration de données

Les procédures suivantes permettent de sauvegarder et de restaurer des données sur IBM Watson® Discovery.

IBM Cloud Pak for Data IBM Software Hub

Ces informations s'appliquent uniquement aux déploiements installés.

Vous utilisez le même ensemble de scripts de sauvegarde et de restauration pour sauvegarder et restaurer des données dans l'un des chemins de mise à niveau pris en charge. Le script de sauvegarde stocke le numéro de version du service avec les données à sauvegarder à partir du déploiement existant. Le script de restauration détecte la version du service installée sur le nouveau déploiement, puis suit les étapes appropriées pour restaurer les données vers la version détectée.

Le tableau suivant répertorie les chemins de mise à niveau pris en charge par les scripts.

Chemins de mise à niveau pris en charge
Version en cours d'utilisation Version vers laquelle vous pouvez effectuer la mise à niveau
5.1.x Les versions ultérieures de 5.1.x, 5.2.0
5.0.x Versions ultérieures de 5.0.x, 5.1.x, 5.2.0
4.8.8, 4.8.9 5.1.1 ou versions ultérieures
4.8.7 Versions ultérieures de 4.8.x, 5.1.x, 5.2.0
4.8.6 Versions ultérieures de 4.8.x, 5.0.3, 5.1.x, 5.2.0
4.8.x Versions ultérieures de 4.8.x, 5.0.x, 5.1.x, 5.2.0
4.7.x 4.8.x, 5.0.x, 5.1.x
4.6.x 4.8.x, 5.0.x, 5.1.x
4.5.x 4.8.x, 5.0.x, 5.1.x
4.0.x 4.8.x sauf 4.8.0

Si vous effectuez une mise à niveau vers 5.2.x, une méthode plus simple pour effectuer la mise à niveau est décrite dans les rubriques suivantes :

Si vous effectuez une mise à niveau vers l' 5.1.x, une méthode plus simple pour terminer la mise à niveau est décrite dans les rubriques suivantes :

Si vous effectuez une mise à niveau vers 5.0.x, une méthode plus simple pour effectuer la mise à niveau est décrite dans les rubriques suivantes:

Si vous utilisez l'utilitaire de sauvegarde et de restauration IBM Cloud Pak for Data Red Hat OpenShift API for Data Protection (OADP) pour sauvegarder et restaurer hors ligne un cluster entier, quelques étapes supplémentaires sont requises. Pour plus d'informations, voir Utilisation de OADP pour sauvegarder un cluster dans lequel Discovery est installé. Pour plus d'informations sur la sauvegarde et la restauration en ligne OADP, voir Sauvegarde et restauration en ligne d'Cloud Pak for Data.

Vous pouvez effectuer une mise à niveau interne à partir d'une version 4.8.x vers une version 4.8.y ultérieure. Pour plus d'informations, voir Mise à niveau de Watson Discovery de la version 4.8.x vers une 4.8 ultérieure.

Vous pouvez effectuer une mise à niveau interne à partir d'une version 4.7.x vers une version 4.7.y ultérieure. Pour plus d'informations, voir Mise à niveau de Watson Discovery de la version 4.7.x vers une actualisation 4.7 ultérieure.

Vous pouvez effectuer une mise à niveau interne à partir d'une version 4.6.x vers une version 4.6.y ultérieure. Pour plus d'informations, voir Mise à niveau de Watson Discovery de la version 4.6.x vers une version 4.6 ultérieure.

Vous pouvez effectuer une mise à niveau interne à partir d'une version 4.5.x vers une version 4.5.y ultérieure. Pour plus d'informations, voir Mise à niveau de Watson Discovery vers la dernière actualisation de la version 4.5.

Vous pouvez effectuer une mise à niveau interne à partir d'une version 4.0.x vers une version 4.0.y ultérieure. Pour plus d'informations, voir Mise à niveau de Watson Discovery vers une 4.0 actualisationplus récente.

Présentation du processus

A un niveau élevé, le processus comprend les étapes suivantes:

  1. Sauvegardez vos données Discovery à l'aide du script de sauvegarde.
  2. Installez la dernière version de IBM Cloud Pak for Data.
  3. Installez la dernière version du service Discovery sur le cluster.
  4. Restaurez les données Discovery sauvegardées à l'aide du script de restauration.

Limites de la sauvegarde et de la restauration

Vous ne pouvez pas migrer les données suivantes :

  • Modèles de suggestion pour le dictionnaire. Ces modèles sont créés lorsque vous générez un dictionnaire. Le dictionnaire est inclus dans la sauvegarde, mais pas le modèle de suggestions de termes. Retraitez les collections migrées pour activer les suggestions de termes du dictionnaire.
  • Vous ne pouvez pas sauvegarder et restaurer des curations ou les migrer car les curations sont une fonction bêta.

Vous pouvez sauvegarder et restaurer certaines données à l'aide des scripts de sauvegarde et de restauration, mais vous devez sauvegarder et restaurer d'autres données manuellement. Les données suivantes doivent être sauvegardées manuellement:

  • Dossiers et documents de système de fichiers local que vous pouvez explorer à l'aide de la source de données Local File System.

Les mises à jour suivantes sont effectuées lors de la restauration de vos collections :

  • Toute collection contenant des documents créés par le téléchargement de données est automatiquement réexplorée et réindexée lors de la restauration. Ces documents se voient attribuer de nouveaux numéros d'identification dans les collections restaurées.
  • Les collections utilisées dans les projets Content Mining sont automatiquement réexplorées et réindexées lorsqu'elles sont restaurées. Seuls les documents ajoutés par le téléchargement de données se voient attribuer de nouveaux numéros d'ID de document dans les collections restaurées.

Méthodes de sauvegarde et de restauration

Vous pouvez sauvegarder et restaurer votre instance de Discovery manuellement ou à l'aide de scripts.

Vous devez disposer d'un accès administrateur à l'instance Discovery sur votre cluster Discovery (où sont stockées les données à sauvegarder) et d'un accès administrateur à la nouvelle instance (où les données seront restaurées).

Les scripts de sauvegarde et de restauration effectuent de nombreuses opérations et peuvent prendre un certain temps à s'exécuter. Pour éviter les problèmes de délai d'attente, exécutez un outil qui empêche les délais d'attente, tel que nohup.

Utilisation des scripts de sauvegarde

Étant donné que les modifications apportées aux données stockées sur IBM Watson® Discovery pendant une sauvegarde peuvent corrompre cette dernière et la rendre inutilisable, aucune demande en vol n'est autorisée pendant la période de sauvegarde.

Une demande en cours est une action IBM Watson® Discovery qui traite des données, y compris les actions suivantes:

  • Exploration de la source (planifiée ou non planifiée)
  • L'ingestion de documents
  • L'entraînement d'un modèle de requête entraîné

La quantité de stockage disponible sur le noeud sur lequel vous exécutez le script de sauvegarde doit être 3 fois plus grande que le plus grand fichier de sauvegarde du magasin de données que vous prévoyez de sauvegarder. Si votre magasin de données est volumineux, envisagez d'utiliser une réservation de volume persistant au lieu de compter sur le stockage éphémère du noeud. Pour plus d'informations, voir Configuration de travaux pour l'utilisation de la PVC.

Effectuez les étapes suivantes pour sauvegarder les données de IBM Watson® Discovery à l'aide des scripts de sauvegarde :

  1. Entrez la commande suivante pour définir l'espace de nom en cours dans lequel votre instance Discovery est déployée :

    oc project <namespace>

  2. Obtenez le script de sauvegarde à partir du référentielGitHub.

    Vous avez besoin de tous les fichiers du référentiel pour effectuer une sauvegarde et une restauration. Suivez les instructions de GitHub Help pour cloner ou télécharger un fichier compressé du référentiel.

  3. Faites de chaque script un fichier exécutable en exécutant la commande suivante:

    chmod +x <name-of-script>

    Remplacez <name-of-script> par le nom du script.

  4. Exécutez le script all-backup-restore.sh.

    ./all-backup-restore.sh backup [ -f backup_file_name ] [--pvc]

    Le paramètre -f backup_file_name est facultatif. Le nom watson_discovery_<timestamp>.backup est utilisé si vous n'indiquez pas de nom.

    Le paramètre --pvc est facultatif. Pour plus d'informations sur le moment où vous devez l'utiliser, voir Configuration des travaux pour l'utilisation de la réservation de volume persistant. Par défaut, les scripts de sauvegarde et de restauration créent un répertoire tmp dans le répertoire de travail utilisé par le script pour extraire ou compresser les fichiers de sauvegarde.

    Si vous rencontrez des problèmes avec la sauvegarde, réexécutez la commande backup et incluez le paramètre --use-job. Ce paramètre indique au script de sauvegarde d'utiliser un travail Kubernetes pour sauvegarder ElasticSearch et MinIO en plus de Postgres, qui utilise un travail Kubernetes par défaut. Si la taille des données dans ElasticSearch et MinIO est importante et que le stockage éphémère est insuffisant, incluez l'option --pvc. Dans ce cas, le script utilise la réservation de volume persistant spécifiée avec l'option --pvc au lieu du stockage éphémère emptyDir comme répertoire de travail temporaire pour le travail.

Extraction de fichiers à partir du fichier d'archive de sauvegarde

Les scripts génèrent un fichier archive, y compris les fichiers de sauvegarde des services répertoriés à l'étape 1.

  1. Vous pouvez extraire des fichiers du fichier archive en exécutant la commande suivante:

    tar xvf <backup_file_name>

Configuration des travaux pour l'utilisation de PVC

Le processus de sauvegarde et de restauration utilise des travaux Kubernetes. Les travaux utilisent des volumes temporaires qui utilisent le stockage temporaire. Il s'agit d'un montage de stockage temporaire sur le pod qui utilise le stockage local d'un noeud. Dans de rares cas, le stockage éphémère n'est pas assez grand. Vous pouvez éventuellement demander au travail de monter une réservation de volume persistant (PVC) sur son pod à utiliser pour stocker les données de sauvegarde. Pour ce faire, spécifiez l'option --pvc lorsque vous exécutez le script. Les scripts utilisent emptyDir de Kubernetes dans le cas contraire.

Dans la plupart des cas, vous n'avez pas besoin d'utiliser un volume persistant. Si vous choisissez d'utiliser un volume persistant, le volume doit être 3 fois plus grand que le plus grand fichier de sauvegarde du magasin de données. La taille du fichier de sauvegarde du magasin de données dépend de l'utilisation. Après avoir créé une sauvegarde, vous pouvez extraire des fichiers du fichier archive pour vérifier la taille des fichiers.

De plus, vous devez disposer de 2 fois plus d'espace disque disponible sur le système local que la taille du magasin de données car l'archivage des données est fractionné, puis recombiné pour éviter les problèmes qui pourraient se produire lorsque vous copiez des fichiers volumineux du noeud de cluster sur le système local.

Mappage de clusters à service partagé

Lorsque vous restaurez des données qui ont été sauvegardées à partir d'une version antérieure à 4.0.6 vers une édition ultérieure et que le déploiement sauvegardé comportait plusieurs instances du service mises à disposition, une étape supplémentaire est requise. Vous devez créer un fichier JSON qui mappe les ID d'instance de service entre le cluster sauvegardé et le cluster dans lequel les données sont restaurées.

Cette étape de mappage n'est pas requise si les ID d'instance n'ont pas été modifiés entre les étapes de sauvegarde et de restauration. Par exemple, vous pouvez ignorer cette étape si vous restaurez des données dans le même cluster à partir duquel elles ont été sauvegardées ou si vous restaurez des données dans un tout nouveau cluster qui ne comporte pas d'instances Discovery.

Pour créer une correspondance, procédez comme suit :

  1. Extrayez le fichier modèle de mappage du fichier d'archive de sauvegarde.

    tar xf <backup_file_name> tmp/instance_mapping.json -O > <mapping_file_name>

  2. Créez une liste des noms et des ID d'instance des instances de service qui sont mises à disposition dans le cluster où les données sont restaurées.

    L'ID de l'instance fait partie du site URL qui est spécifié dans la page de résumé de l'instance. Dans le menu principal du client Web IBM Cloud Pak for Data, développez Services, puis cliquez sur Instances. Recherchez votre instance, puis cliquez dessus pour ouvrir sa page récapitulative. Faites défiler la page jusqu'à la section Informations d'accès et recherchez l'identifiant de l'instance dans le champ URL dans le champ

    Par exemple, https://<host_name>/wd/<namespace>-wd/instances/<instance_id>/api.

    Répétez cette étape pour noter l'ID d'instance pour chaque instance mise à disposition.

  3. Editez le fichier de mappage.

    Ajoutez les ID d'instance pour les instances de service de destination que vous avez répertoriées à l'étape précédente. L'extrait suivant est un exemple de fichier de correspondance.

    {
  "instance_mappings": [
    {
      "display_name": "discovery-1",
      "source_instance_id": "1644822491506334",
      "dest_instance_id": "<new_instance_id>"
    },
    {
      "display_name": "discovery-2",
      "source_instance_id": "1644822552830325",
      "dest_instance_id": "<new_instance_id>"
    }
  ]
}

Lorsque vous exécutez le script de restauration, incluez le paramètre facultatif --mapping pour appliquer ce fichier de mappage lors de la restauration des données.

Sauvegarde manuelle des données

Sauvegardez manuellement les données qui ne sont pas sauvegardées à l'aide des scripts.

Pour sauvegarder manuellement vos données à partir d'une instance de Discovery, procédez comme suit :

  1. Entrez la commande suivante pour vous connecter à votre cluster Discovery :

    oc login https://<OpenShift administrative console URL> \
-u <cluster administrator username> -p <password>

  2. Entrez la commande suivante pour passer à l'espace de nom approprié :

    oc project <discovery-install namespace>

  3. Entrez oc get pods|grep crawler.

  4. Entrez la commande suivante :

    oc cp <crawler pod>:/mnt <path-to-backup-directory>

Utilisation des scripts de restauration

Si vous restaurez des données à partir d'une version antérieure à 4.0.6 et que vous restaurez un cluster à service partagé dans un cluster à service partagé, vous devez effectuer une étape supplémentaire avant de commencer. Pour plus d'informations, voir Mappage de clusters à service partagé.

Effectuez les étapes suivantes pour restaurer les données dans IBM Watson® Discovery à l'aide des scripts de restauration :

  1. Entrez la commande suivante pour définir l'espace de nom en cours dans lequel votre instance Discovery est déployée :

    oc project <namespace>

  2. Si ce n'est pas déjà fait, obtenez le script de restauration à partir du référentielGitHub.

    Vous avez besoin de tous les fichiers du référentiel pour effectuer une sauvegarde et une restauration. Suivez les instructions de GitHub Help pour cloner ou télécharger un fichier compressé du référentiel.

  3. Faites de chaque script un fichier exécutable en exécutant la commande suivante:

    chmod +x <name-of-script>

    Remplacez <name-of-script> par le nom du script.

  4. Restaurez les données du fichier de sauvegarde sur votre système local vers le nouveau déploiement Discovery en exécutant la commande suivante :

    ./all-backup-restore.sh restore -f backup_file_name [--pvc] [--mapping]

    Le paramètre --pvc est facultatif. Pour plus d'informations sur le moment où vous devez l'utiliser, voir Configuration des travaux pour l'utilisation de la réservation de volume persistant.

    Le paramètre --mapping est facultatif. Pour savoir quand l'utiliser, voir Mappage de clusters à service partagé.

    Par défaut, les scripts de sauvegarde et de restauration créent un répertoire tmp dans le répertoire de travail utilisé par le script pour extraire ou compresser les fichiers de sauvegarde. Si vous avez utilisé le paramètre --use-job lors de la sauvegarde des données, indiquez-le à nouveau lors de la restauration des données. Ce paramètre indique au script de sauvegarde d'utiliser un travail Kubernetes pour sauvegarder ElasticSearch et MinIO.

    Les pods gateway, ingestion, orchestrator, hadoop worker, et controller redémarrent automatiquement.

Restauration manuelle des données

Restaurez manuellement les données qui ne peuvent pas être restaurées à l'aide du script.

Pour restaurer manuellement des données à partir d'une instance de Discovery, procédez comme suit :

  1. Entrez la commande suivante pour vous connecter à votre cluster Discovery :

    oc login https://<OpenShift administrative console URL> \
-u <cluster administrator username> -p <password>

  2. Entrez la commande suivante pour passer à l'espace de nom approprié :

    oc project <discovery-install namespace>

  3. Entrez oc get pods|grep crawler.

  4. Entrez la commande suivante :

    oc cp <path-to-backup-directory> <crawler pod>:/mnt

Utilisation de OADP pour la sauvegarde hors ligne d'un cluster où Discovery est installé

Si vous prévoyez de sauvegarder et de restaurer une instance IBM Cloud Pak for Data complète à l'aide de l'utilitaire de sauvegarde et de restauration IBM Cloud Pak for Data Red Hat OpenShift API for Data Protection (OADP), vous devez effectuer des étapes supplémentaires afin que l'utilitaire fonctionne correctement lorsque Discovery est présent. Voir Cloud Pak for Data offline backup and restore(utilitaireOADP).

Sauvegarde d'un cluster hors ligne

Pour effectuer une sauvegarde hors ligne d'un cluster, procédez comme suit:

  1. Exécutez le script de sauvegarde Discovery.

  2. Utilisez l'utilitaire de sauvegarde OADP pour sauvegarder le cluster.

Restauration d'un cluster hors ligne

Pour restaurer un cluster hors ligne, procédez comme suit :

  1. Utilisez l'utilitaire de sauvegarde OADP pour restaurer le cluster.

  2. Désinstallez Discovery, puis réinstallez Discovery sur le cluster restauré.

    La réinstallation est requise car l'utilitaire ne réinstalle pas toujours correctement Discovery.

  3. Exécutez le script de restauration Discovery pour restaurer vos données.