Restaurer les sauvegardes conservées à long terme

Vous pouvez récupérer les sauvegardes conservées à long terme directement à partir de vos buckets Cloud Storage à l'aide d'un utilitaire autonome, ce qui vous permet d'accéder aux données même sans appliances Backup and DR actives.

Ce document explique comment utiliser cet utilitaire de récupération autonome pour découvrir, valider, monter et restaurer les images de sauvegarde OnVault et Compute Engine de Backup and DR.

Présentation

Les sauvegardes conservées à long terme sont stockées dans des buckets Cloud Storage à l'aide de règles OnVault pour la conformité et l'archivage. Pour garantir l'accessibilité des données indépendamment de l'infrastructure de sauvegarde, vous pouvez utiliser un utilitaire de récupération autonome pour découvrir, vérifier et restaurer ces données directement à partir du bucket de stockage. C'est essentiel pour les scénarios de reprise après sinistre ou de mise hors service où l'appliance de sauvegarde/récupération d'origine peut ne pas être disponible.

Avant de commencer

Avant de commencer à restaurer les sauvegardes conservées à long terme, lisez les sections suivantes.

Obtenir les rôles requis

Pour obtenir les autorisations nécessaires pour restaurer des sauvegardes conservées à long terme, demandez à votre administrateur de vous accorder le rôle IAM Opérateur Backup and DR Cloud Storage (roles/backupdr.cloudStorageOperator) sur le bucket Cloud Storage cible. Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.

Autres conditions préalables

Avant de restaurer des sauvegardes conservées à long terme, assurez-vous de remplir les conditions préalables suivantes :

  1. Avant de lancer une récupération, vérifiez que vos données sont disponibles dans le stockage OnVault. Vérifiez les sauvegardes existantes dans le pool de dispositifs de sauvegarde/récupération et migrez-les vers OnVault en attribuant la stratégie de protection OnVault appropriée.

  2. Pour les scénarios de récupération impliquant des instantanés Persistent Disk, vérifiez que toutes les métadonnées de sauvegarde sont répliquées dans le bucket Cloud Storage cible. L'utilitaire de récupération dépend de ces métadonnées pour cataloguer et traiter les images instantanées. Pour faciliter le transfert de données et confirmer que les métadonnées sont présentes dans le bucket Cloud Storage, contactez le Cloud Customer Care.

  3. Assurez-vous que le système hôte sur lequel vous exécutez cet outil répond aux exigences suivantes :

    • gcloud CLI : installée et accessible dans votre variable d'environnement PATH (plus précisément gcloud storage).
    • Authentification : configurée avec des identifiants actifs en exécutant gcloud auth login, ou à l'aide des Identifiants par défaut de l'application (ADC) ou des clés de compte de service.

  4. Identifiez et conservez une liste des noms de bucket Cloud Storage et des ID de projets Google Cloud correspondants à utiliser avec l'utilitaire de récupération.

Déployer l'utilitaire de récupération

Configurez une instance de VM pour qu'elle serve de proxy de récupération ou d'hôte de l'application de destination, puis déployez l'outil de récupération autonome.

Découvrir les appliances, les hôtes et les images

L'utilitaire de récupération autonome accepte une paire de valeurs de bucket et de projet (--bucket et --project) pour les commandes. L'utilitaire accepte les opérations suivantes :

  • Lister les applications
  • Répertorier des sauvegardes
  • Expiration des sauvegardes
  • Monter une image de sauvegarde
  • Démonter une image de sauvegarde

Monter l'image de sauvegarde

Pour effectuer un montage de récupération, vous devez d'abord identifier le nom de l'image de sauvegarde.

Répertoriez les sauvegardes disponibles pour identifier le nom de l'image de sauvegarde :

python3 ~/gcbdr-onvault-cli/python/gcbdr_onvault.py \
  --bucket BUCKET_NAME \
  --project PROJECT_ID \
  --cluster APPLIANCE_NAME \
  --host HOST_NAME \
  --app APPLICATION_NAME \
  --list-images

Ensuite, pour effectuer un montage de récupération non interactif, utilisez une commande semblable à l'exemple suivant pour monter l'image de sauvegarde sélectionnée directement sur le serveur de base de données cible ou sur le proxy de récupération désigné :

python3 ~/gcbdr-onvault-cli/python/gcbdr_onvault.py \
  --bucket BUCKET_NAME \
  --project PROJECT_ID \
  --cluster APPLIANCE_NAME \
  --host HOST_NAME \
  --app APPLICATION_NAME \
  --image IMAGE_NAME \
  --mountpoint MOUNT_POINT \
  --auto-mount

Remplacez les éléments suivants :

  • BUCKET_NAME: nom du bucket Cloud Storage.
  • PROJECT_ID : ID de votre projet Google Cloud .
  • APPLIANCE_NAME : nom ou ID de l'appliance de sauvegarde/récupération.
  • HOST_NAME : nom d'hôte ou ID de l'hôte source.
  • APPLICATION_NAME : nom ou ID de l'application protégée.
  • IMAGE_NAME : nom de l'image de sauvegarde active à installer.
  • MOUNT_POINT : (facultatif) chemin d'accès au répertoire local dans lequel la sauvegarde est installée. La valeur par défaut est /tmp/recovery_folder.

Une fois l'extraction terminée, vous pouvez afficher les données sauvegardées dans le répertoire du point de montage.

Restaurer des applications

Pour accéder aux fichiers bruts de la base de données, accédez à MOUNT_POINT/restored_data/. Sélectionnez le chemin de récupération pour votre type de charge de travail et votre configuration de montage :

Microsoft SQL

  1. Localisez les fichiers : identifiez les fichiers de base de données .mdf et .ldf principaux dans le répertoire db_volume/.
  2. Attachement direct (même hôte) : arrêtez l'instance de base de données cible. Ouvrez SQL Server Management Studio, sélectionnez Attach Database (Joindre une base de données), puis spécifiez les chemins d'accès aux fichiers de données et journaux dans le répertoire du point de montage de récupération.
  3. Copier et associer (hôte différent) : arrêtez l'instance de base de données cible. Transférez les fichiers .mdf et .ldf vers les lecteurs de stockage local du serveur cible, puis associez-les à l'aide de SQL Server Management Studio.

Oracle

  1. Localiser les fichiers : l'utilitaire détecte automatiquement les fichiers init.ora ou spfile et les fichiers de données .dbf tout en mettant en ligne la sauvegarde de la base de données RMAN et les groupes de volumes Archive log.
  2. Récupérer la base de données : arrêtez l'instance Oracle cible ou démarrez-la en mode NOMOUNT. Mettez à jour les paramètres d'initialisation (tels que les fichiers de contrôle) pour qu'ils pointent vers les fichiers .dbf montés pour la validation directe, ou copiez les fichiers .dbf dans un espace de stockage local ou dans un espace de stockage ASM (Automatic Storage Management) pour une récupération permanente.
  3. Ouvrez la base de données : définissez l'état de l'instance sur MOUNT, appliquez les journaux de récupération requis à partir du groupe de volumes TransactionLog monté, puis ouvrez la base de données.

VM VMware Engine

Au-delà de la récupération des applications de base de données, la protection des machines virtuelles Google Cloud VMware Engine (VMware Engine) englobe l'ensemble de la configuration matérielle ainsi que les étendues de disque virtuel.

  1. Monter et localiser les fichiers : montez l'image de sauvegarde comme décrit dans Monter l'image de sauvegarde. L'utilitaire génère le disque virtuel clairsemé (vol00.raw) dans le chemin d'accès au point de montage principal. Il associe ensuite le disque pour exposer le système de fichiers du système d'exploitation invité sous le répertoire db_volume/, tandis que les métadonnées de configuration VMware (y compris .ovf, .vmx et Catalog.xml) sont organisées dans le dossier log_files/.
  2. Restaurer directement la VM : désactivez la VM cible pour sécuriser son disque de base pour l'analyse du fichier manifeste. Un processus de calcul lit les blocs de données à partir du stockage local, les écrit dans le VMDK à l'aide des bibliothèques VMware Virtual Disk Development Kit (VDDK), puis redémarre automatiquement la VM.

Instantanés de disque persistant Compute Engine

Contrairement aux sauvegardes OnVault montées en tant que systèmes de fichiers locaux, les instantanés de disque persistant Compute Engine sont restaurés en initialisant de nouveaux disques persistants et en les associant directement à une instance Compute Engine cible.

  1. Identifier la sauvegarde et les métadonnées cibles : vérifiez que le fichier catalogue des métadonnées d'instantané de disque persistant (pdsnapshot_catalog.json) est présent dans votre bucket Cloud Storage. Utilisez l'utilitaire Persistent Disk Manager pour examiner les sauvegardes disponibles listées dans le catalogue et sélectionner le IMAGE ID spécifique destiné à la récupération.
  2. Restaurer et associer des volumes : utilisez la commande attach pour automatiser la génération de disques persistants à partir d'instantanés de sauvegarde. Cette action unique gère la création et la connexion de tous les volumes concernés à votre machine virtuelle de destination.
  3. Installer des appareils au niveau du système d'exploitation : une fois l'association terminée, connectez-vous à l'instance Compute Engine cible pour identifier les nouveaux périphériques de bloc mappés à l'aide d'outils tels que lsblk. Montez manuellement les systèmes de fichiers pour accéder aux données récupérées ou lancez le processus de récupération de l'application.

SAP HANA PD

Contrairement aux sauvegardes OnVault, qui sont montées directement en tant que systèmes de fichiers locaux, la restauration des instantanés de disque persistant SAP HANA implique le provisionnement de nouveaux disques persistants et leur association à l'instance Compute Engine cible.

  1. Vérifiez les métadonnées et localisez l'image de sauvegarde : assurez-vous que le fichier de catalogue des métadonnées du snapshot de disque persistant est disponible dans le bucket Cloud Storage. Utilisez l'outil de gestion des disques persistants pour inspecter les sauvegardes cataloguées et choisir le IMAGE ID requis pour la récupération.
  2. Provisionner des disques et associer des volumes : exécutez la commande attach pour automatiser la génération de disques persistants à partir de l'instantané de sauvegarde choisi. Cette étape permet de créer tous les volumes requis et de les associer à la machine virtuelle cible en une seule opération.
  3. Monter les périphériques au niveau du système d'exploitation : une fois les disques associés, connectez-vous à la VM SAP HANA de destination et recherchez les périphériques de blocs nouvellement attribués à l'aide d'outils tels que lsblk. Installez manuellement les systèmes de fichiers pour accéder aux données récupérées ou commencer la restauration au niveau de l'application.
  4. Récupérer SAP HANA : après avoir installé les volumes de données, de journaux et de journaux d'archive SAP HANA, démarrez la base de données système (y compris la récupération à un moment précis si nécessaire), puis la récupération et l'initialisation des bases de données locataires.

IBM Db2 PD

Contrairement aux sauvegardes OnVault, qui sont montées directement en tant que systèmes de fichiers locaux, la restauration des instantanés de disque persistant IBM Db2 nécessite le provisionnement de nouveaux disques persistants et leur association à l'instance Compute Engine de destination.

  1. Localisez l'image de sauvegarde et validez les métadonnées : vérifiez que le fichier de catalogue des métadonnées de l'instantané de disque persistant est présent dans le bucket Cloud Storage désigné. Utilisez l'outil de gestion des disques persistants pour inspecter les sauvegardes cataloguées afin d'identifier et de sélectionner le IMAGE ID cible requis pour la récupération.
  2. Associez des volumes et provisionnez des disques : exécutez la commande attach pour créer automatiquement des disques persistants à partir de l'instantané de sauvegarde spécifié. Cette étape unique provisionne tous les volumes nécessaires et les associe directement à la machine virtuelle cible.
  3. Installer les systèmes de fichiers du système d'exploitation : après avoir associé les disques, connectez-vous à la VM IBM Db2 cible pour identifier les nouveaux périphériques de blocs mappés à l'aide d'outils tels que lsblk. Montez manuellement les systèmes de fichiers pour accéder aux données restaurées ou procédez à la récupération de l'application.
  4. Récupérer la base de données de l'application : après avoir installé les volumes de données, de journaux de transactions et de journaux d'archive Db2, cataloguez chaque instance de base de données Db2, effectuez la récupération de la base de données si nécessaire et mettez la base de données en ligne.

MySQL/MariaDB

  1. Localisez les fichiers : localisez le répertoire de données principal dans db_volume/, qui contient les bases de données utilisateur, le schéma système et les espaces de table InnoDB.

  2. Restaurer la base de données : arrêtez le service MySQL ou MariaDB actif. Pour effectuer un test direct, ajustez l'entrée datadir dans my.cnf afin de cibler le dossier de montage de récupération. Pour une restauration permanente, copiez les fichiers de base de données dans un espace de stockage local (tel que /var/lib/mysql/) et assurez-vous que le système de fichiers est correctement configuré en termes de propriété et d'autorisations.

  3. Remettre en ligne et récupérer : redémarrez le service de base de données. Si des journaux de transactions binaires existent, effectuez une récupération à un moment précis à l'aide de l'utilitaire mysqlbinlog.

PostgreSQL

  1. Localisez les fichiers : dans le répertoire db_volume/, identifiez les composants PGDATA, y compris les bases de données principales (base/, global/ et pg_wal/) et le fichier de configuration postgresql.conf.

  2. Restaurer la base de données : arrêtez l'instance PostgreSQL de destination. Pour valider directement à partir du montage, pointez la variable d'environnement data_directory ou PGDATA vers le chemin de récupération. Pour effectuer une restauration définitive, transférez la structure complète du répertoire vers le stockage local de l'hôte cible.

  3. Base de données ouverte : redémarrez le service pour mettre l'instance en ligne. Si la récupération à un moment précis est requise, appliquez les journaux WAL archivés du dossier log_files/ en définissant un fichier recovery.conf ou en configurant restore_command dans postgresql.conf (pour PostgreSQL 12 et versions ultérieures), puis mettez la base de données en ligne.

SAP ASE

  1. Localisez les fichiers : identifiez l'appareil maître principal, ainsi que les appareils de base de données utilisateur et de journaux spécifiques, situés dans le dossier db_volume/ monté.

  2. Restaurer la base de données : arrêtez l'instance SAP ASE de destination. Pour le montage direct, mettez à jour la configuration RUN_server afin de rediriger le paramètre de l'appareil maître (tel que -d) vers le chemin de récupération. Vous pouvez également transférer tous les composants de l'appareil vers leurs emplacements de stockage permanents.

  3. Ouvrir la base de données : démarrez le processus SAP ASE dataserver. Si des journaux de transactions sont présents, exécutez l'opération LOAD TRAN pour effectuer une récupération à un moment précis avant de mettre la base de données en ligne.

SAP MaxDB

  1. Localisez les volumes : accédez au chemin d'accès au point de montage db_volume/ pour trouver les fichiers journaux et de données SAP MaxDB principaux.

  2. Restaurer ou rediriger la configuration : arrêtez le processus SAP MaxDB de destination. Utilisez le gestionnaire de base de données (dbmcli) pour mettre à jour des paramètres tels que DataVolumeName afin de pointer vers le montage de récupération, ou copiez les fichiers directement dans le stockage local pour une restauration complète.

  3. Démarrer et mettre en ligne : démarrez l'instance de base de données et définissez son état opérationnel sur ONLINE à l'aide du Gestionnaire de bases de données.

SAP IQ

  1. Localiser les fichiers : accédez au répertoire db_volume/ pour identifier le magasin principal SAP IQ, le magasin de catalogue (.db) et tous les éléments de magasin temporaires associés.

  2. Restaurer la base de données : arrêtez l'instance SAP IQ de destination. Pour effectuer une validation directe à partir du montage de récupération, modifiez les paramètres de démarrage afin de faire référence au fichier de catalogue monté. Pour une restauration permanente, transférez tous les volumes du magasin vers le stockage local en vous assurant que la propriété et les autorisations appropriées du système de fichiers sont conservées.

  3. Ouvrez la base de données : exécutez l'utilitaire start_iq pour mettre l'instance en ligne et vérifier l'intégrité des données.

IBM Db2 LVM/dump

  1. Localisez les fichiers : accédez aux chemins de montage db_volume/ et log_files/. En fonction de la méthode de protection, identifiez les volumes de données et de journaux LVM ou les composants d'image de sauvegarde spécifiques pour la récupération basée sur le vidage.
  2. Récupérer la base de données (LVM) : arrêtez l'instance Db2 de destination. Transférez les données de la base de données et les volumes de journaux de transactions actifs du montage de récupération vers le stockage local cible, en veillant à ce que le système de fichiers soit correctement attribué à l'utilisateur et au groupe Db2.
  3. Restaurer la base de données (vidage complet et incrémentiel) : arrêtez les connexions actives et supprimez la base de données cible si elle existe. Utilisez l'outil db2ckrst avec le code temporel de sauvegarde spécifique pour cataloguer la séquence incrémentielle nécessaire. Exécutez l'opération RESTORE pour chaque image dans l'ordre prescrit.
  4. Ouvrir la base de données : démarrez l'instance Db2. Si la base de données reste à l'état "En attente" ou nécessite une récupération à un moment précis, appliquez les journaux de transactions à l'aide de l'utilitaire db2 rollforward pour terminer la récupération et mettre l'instance en ligne.

Effectuer un nettoyage des ressources

Après avoir copié ou détaché tous les fichiers de base de données nécessaires du moteur de base de données, démontez les volumes actifs de manière sécurisée, détachez tous les périphériques de boucle associés et supprimez les répertoires de transfert locaux pour éviter les verrous résiduels ou les références orphelines.

Pour démonter les volumes et nettoyer le répertoire de récupération, exécutez les commandes suivantes :

python3 ~/gcbdr-onvault-cli/python/gcbdr_onvault.py \
  --mountpoint MOUNT_POINT \
  --unmount
rm -rf MOUNT_POINT

Remplacez les éléments suivants :

  • MOUNT_POINT : chemin d'accès au répertoire local où la sauvegarde a été montée, par exemple /tmp/recovery_folder.

Étapes suivantes