Cloud Backup:Database backup FAQ

Problèmes liés aux instances de base de données

• Que faire si l'enregistrement d'une instance de base de données dans Database Backup échoue ?

• Comment résoudre le statut « Inactivated » d'une instance de base de données ?

• Comment résoudre le statut « DB Offline » d'une instance de base de données ?

• Pourquoi plusieurs instances de base de données apparaissent-elles dans l'onglet ECS Database Instance après l'enregistrement d'une instance ?

• Que faire si l'état de la base de données ne peut pas être récupéré après l'enregistrement d'une instance ?

Problèmes liés au client

• Comment consulter l'état du processus client, trouver le chemin du journal et redémarrer le client ?

• Comment résoudre le statut « Offline » d'un client de base de données ?

• Comment résoudre l'erreur « Failed to run install script:exit status 4 » lors de l'installation du client de sauvegarde pour une base de données SQL Server locale ?

• Comment résoudre un échec d'installation du client de sauvegarde lors de la sauvegarde d'une base de données SQL Server locale ?

• Comment résoudre un échec d'installation du client Database Backup sur une instance ECS ?

Problèmes liés à la sauvegarde

• Comment obtenir un essai gratuit de la fonctionnalité de sauvegarde de bases de données locales ?

• Quelles sont les exigences réseau pour la sauvegarde d'une base de données locale ?

• Quel est l'intervalle minimum pour la sauvegarde en temps réel ? Puis-je configurer simultanément la sauvegarde en temps réel et la sauvegarde incrémentielle ?

• Comment modifier le nom d'utilisateur et le mot de passe pour Database Backup ?

• Les sauvegardes de bases de données sont-elles chiffrées ?

• Que faire en cas d'échec d'une sauvegarde de base de données ?

• Que faire si une sauvegarde de données Oracle échoue et que le journal contient l'erreur « Failed to get install path from registry » ?

• Que faire si une sauvegarde incrémentielle des données Oracle prend autant de temps, voire plus, qu'une sauvegarde complète ?

• Comment résoudre l'erreur « RMAN reports a non-fatal error » lors d'une sauvegarde incrémentielle Oracle ?

• Que faire s'il est impossible d'afficher les détails de la base de données lors de la sauvegarde d'une base de données SQL Server 2019 ?

• Que faire si l'adresse IP d'une base de données SQL Server locale enregistrée, affichée dans la console Cloud Backup, ne correspond pas à son adresse IP réelle ?

• Puis-je sauvegarder une base de données SQL Server vers Alibaba Cloud après avoir activé le Transparent Data Encryption (TDE) ?

• Que faire si le client est hors ligne, ne peut pas être désinstallé et que la politique anti-ransomware ne peut pas être supprimée après le déploiement du service anti-ransomware pour une base de données SQL Server ?

• Que faire si je ne peux pas installer ou utiliser correctement Database Backup après avoir transféré une instance ECS d'un compte Alibaba Cloud à un autre ?

• Quelles versions de bases de données MySQL et quels systèmes d'exploitation sont pris en charge pour la sauvegarde ?

• Comment sauvegarder une base de données nouvellement créée dans MySQL ?

• Comment annuler une sauvegarde de base de données ?

• Pourquoi l'historique des sauvegardes contient-il des enregistrements de sauvegarde dupliqués ou inattendus ?

• Pourquoi une sauvegarde échoue-t-elle et pourquoi l'état du plan de sauvegarde indique-t-il « Error » ?

• Pourquoi l'heure de l'alerte diffère-t-elle de l'heure réelle de l'erreur ?

• Pourquoi recevoir une alerte d'échec alors que l'historique des sauvegardes affiche à la fois un enregistrement de sauvegarde réussi et un enregistrement échoué pour la même heure ?

Problèmes liés à la restauration

• Comment fonctionne la fonctionnalité « View Offline Instances Only » ?

• Que faire en cas d'échec de la restauration d'une base de données SQL Server ?

• Comment résoudre un échec de restauration SQL Server lorsque le journal de l'agent indique une erreur d'initialisation de fichier ?

• Comment effectuer une restauration croisée entre une base de données locale et une base de données sur une instance ECS ?

Problèmes liés au coffre de sauvegarde

• Qu'est-ce qu'un coffre de sauvegarde de base de données ?

• Comment les données expirées sont-elles purgées d'un coffre de sauvegarde de base de données ?

• Comment consulter la taille des données de sauvegarde et l'utilisation du coffre de sauvegarde ? Comment la facturation est-elle calculée ?

Échec de l'enregistrement de l'instance

Vérifiez d'abord si le client de sauvegarde est installé sur votre serveur (serveur local ou instance ECS). Si tel est le cas, désinstallez-le et supprimez ses fichiers de configuration en suivant les instructions indiquées dans la section Désinstallation du client. Tentez ensuite de nouveau d'enregistrer l'instance.

Statut inactif de l'instance

Statut hors ligne de l'instance

Multiples instances après l'enregistrement

Si plusieurs instances de base de données sont déployées sur une seule instance ECS, la console Cloud Backup les détecte et les affiche toutes lors de l'enregistrement.

Sous l'onglet ECS database instance, la console affiche les multiples instances de base de données présentes sur la même instance ECS sous forme d'enregistrements distincts. Chaque enregistrement correspond à un nom d'instance et à un numéro de port différents.

Impossible de récupérer le statut de la base de données

• Symptôme

  Après l'enregistrement d'une instance de base de données, la console Cloud Backup ne parvient pas à récupérer son statut.

  Dans la console, la colonne du statut de la base de données affiche continuellement une icône de chargement.

• Cause

  Le système d'exploitation actuel n'est pas pris en charge par la base de données.

• Solution

  Basculez vers un système d'exploitation pris en charge et réessayez.

Vérification du statut du client, chemin d'accès aux journaux et redémarrage

• Linux

  1. Vérifiez l'état du processus du client de sauvegarde.

     Exécutez la commande systemctl status dbackup3-agent ou service dbackup3-agent status pour vérifier l'état du processus du client de sauvegarde de base de données.

     Une sortie affichant active ou dbackup3-agent is running... indique que le client fonctionne correctement.

     ● dbackup3-agent.service - dbackup3 agent daemon
        Loaded: loaded (/usr/lib/systemd/system/dbackup3-agent.service; enabled; vendor preset: disabled)
        Active: active (running) since Mon 2023-12-11 13:47:34 CST; 1min 13s ago
      Main PID: 22192 (dbackup3-agent)
        CGroup: /system.slice/dbackup3-agent.service
                └─22192 /opt/scutech/dbackup3/bin/dbackup3-agent -f /etc/opt/scutech/dbackup3/agent/svc.conf.d
     
     Dec 11 13:47:34 iZbp1******gktZ systemd[1]: Started dbackup3 agent daemon.

  2. Redémarrez le client de sauvegarde.

     Après avoir redémarré le processus client en exécutant la commande systemctl restart dbackup3-agent ou service dbackup3-agent restart, le statut du client revient à la normale si le Client Status de la base de données dans la console est défini sur Installed.

  Le chemin d'accès au journal du client est : /var/log/dbackup3/agent.log

• Windows

  1. Appuyez sur les touches Win + R pour ouvrir la boîte de dialogue « Run ».

  2. Saisissez services.msc et appuyez sur Entrée pour ouvrir la console des services.

  3. Dans la liste des services, recherchez le service dbackup3-agent.

  4. Vérifiez si le statut du service est « Running ». Si ce n'est pas le cas, cliquez avec le bouton droit sur le service dbackup3-agent et sélectionnez « Restart » pour le démarrer.

  Le chemin d'accès au journal du client est : C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log

Résolution du statut « Offline » du client

• Symptôme

  Le Client Status de la base de données est Offline.

  À ce stade, le Client Status est Offline et le statut de la base de données est Unknown.

• Cause

  Le statut Offline indique une perte de signal heartbeat du client, généralement causée par l'arrêt du processus client en raison d'une mémoire insuffisante ou par la mise hors tension de l'hôte.

• Solution

  Vérifiez et redémarrez le client comme décrit dans la section Comment vérifier l'état du processus client, trouver le chemin d'accès aux journaux et redémarrer le client ?. Une fois que le statut du client passe à Running, attendez que le Client Status de la base de données dans la console passe à Installed. Cela indique que le client est de nouveau opérationnel.

Résolution de l'erreur d'installation « exit status 4 »

Cette erreur se produit car le paramètre de stratégie de sécurité locale « User Account Control: Admin Approval Mode for the Built-in Administrator account » n'est pas activé. Cette stratégie doit être définie sur Enabled.

1. Appuyez sur les touches Win+R pour ouvrir la commande Exécuter, saisissez gpedit.msc pour lancer l'éditeur de stratégie de groupe locale.

2. Dans l'éditeur de stratégie de groupe locale, accédez à Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. Dans le volet de droite, recherchez User Account Control: Admin Approval Mode for the Built-in Administrator account et changez son statut en Enabled.

Résoudre les échecs d'installation du client pour SQL Server local

1. Connectez-vous au serveur et consultez le journal de sauvegarde.

   Chemin du journal du client Windows : C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log

2. Dans le journal, examinez les entrées correspondant à l'heure de l'échec de la tâche.

   Si le journal de sauvegarde contient le message d'erreur Failed to install dbackup3-agent service, errno=1783, The stub received bad data, le système a peut-être rejeté l'installation. Vérifiez si un antivirus ou un logiciel de sécurité a bloqué l'installation et examinez les journaux de blocage. Ajoutez le programme d'installation à la liste d'autorisation ou désactivez temporairement le logiciel de sécurité, puis recommencez l'installation.

Résoudre les échecs d'installation du client sur ECS

Pour garantir une installation réussie, vérifiez les points suivants :

1. Statut de Cloud Assistant : vérifiez que Cloud Assistant est installé sur l'instance ECS et fonctionne correctement.

   En cas d'échec de l'installation, vous trouverez généralement un enregistrement de commande ayant échoué dans la console Cloud Assistant. Copiez la commande et exécutez-la manuellement sur l'hôte ECS. Lors de l'installation manuelle, des messages d'erreur spécifiques s'affichent en cas de problème réseau ou d'exécution du script. Utilisez ces messages pour résoudre les problèmes, par exemple en ajustant les paramètres réseau.

   Une fois les problèmes résolus et le script exécuté avec succès, le client est installé. Déclenchez ensuite à nouveau l'installation depuis la console pour terminer le processus.

2. Espace sur le lecteur C : assurez-vous que le lecteur C dispose de suffisamment d'espace libre. Un espace insuffisant empêche l'installation du client.

Essai gratuit pour la sauvegarde de base de données locale

La procédure d’essai gratuit pour la sauvegarde de base de données locale est identique à celle de la sauvegarde de base de données ECS. Pour plus d’informations, consultez Essai gratuit de 30 jours.

Exigences réseau

Vous devez connecter votre serveur de base de données sur site à un VPC Alibaba Cloud via une ligne louée ou un VPN. Vous devez également configurer le routage depuis votre réseau local vers les plages CIDR suivantes dans le cloud : 100.64.0.0/10 et 100.96.0.0/11.

Intervalle de sauvegarde en temps réel et sauvegarde incrémentielle

Une sauvegarde en temps réel permet d’atteindre un objectif de point de récupération (RPO) de l’ordre de quelques secondes et prend actuellement en charge les bases de données MySQL et Oracle. Lorsque vous activez la sauvegarde en temps réel, vous ne pouvez pas configurer de sauvegarde traditionnelle des journaux séparée. Toutefois, vous pouvez la combiner avec une sauvegarde incrémentielle pour renforcer la protection de vos données.

Modifier les identifiants de sauvegarde de la base de données

Utilisez Reactivate pour modifier les identifiants de sauvegarde, par exemple lorsqu’un mot de passe expire. La réactivation n’affecte pas les plans de sauvegarde existants, mais impacte les tâches de sauvegarde en cours. Pour minimiser l’impact, procédez comme suit :

1. Dans l’onglet Backup Plans, suspendez toutes les sauvegardes de journaux en temps réel.

2. Dans la colonne actions de la base de données, choisissez More > Reactivate.

Chiffrement des sauvegardes de base de données

Oui, les sauvegardes de bases de données sont chiffrées afin de protéger vos données contre les risques de sécurité. Cela inclut le chiffrement des données en transit et au repos.

• Chiffrement en transit : par défaut, les données sont chiffrées lors du transfert via HTTPS, qui s’appuie sur SSL/TLS (Secure Sockets Layer/Transport Layer Security). SSL/TLS garantit la confidentialité et l’intégrité des données entre les applications communicantes.

• Chiffrement au repos : Cloud Backup chiffre vos données de sauvegarde dans le coffre-fort de sauvegarde à l’aide de l’algorithme AES-256 et de clés gérées par le fournisseur.

Gestion des échecs de sauvegarde de base de données

Erreur de sauvegarde Oracle : échec de récupération du chemin d'installation depuis le registre

• Symptôme

  La sauvegarde des données Oracle échoue et le journal contient le message d'erreur suivant :

  Failed to get install path from registry.
  Failed import $APPDATA\scutech\dbackup3\common\conf/config.ini: No such file or directory
  (Failed to open '$APPDATA\ scutech\dbackup3\common\conf/config ini' as default global config.

• Cause

  Oracle 12c et les versions ultérieures permettent d'exécuter le service Oracle en tant qu'utilisateur virtuel. Toutefois, le client Cloud Backup s'exécute en tant qu'utilisateur système. Cette différence peut entraîner un conflit de permissions empêchant Oracle d'accéder aux répertoires créés par le logiciel de sauvegarde.

• Solution

  Accordez manuellement l'autorisation Full Control au groupe Users. Procédez comme suit :

  1. Ouvrez l'Éditeur du Registre. Accédez à la clé HKEY_LOCAL_MACHINE\SOFTWARE\scutech\dbackup3, cliquez avec le bouton droit sur la clé agent, puis sélectionnez Permissions.

  2. Dans la boîte de dialogue Permissions for agent, sélectionnez le groupe Users, cochez la case Allow correspondant à Full Control, puis cliquez sur OK.

La sauvegarde incrémentielle est aussi lente que la sauvegarde complète

• Symptôme

  Une sauvegarde incrémentielle ou une sauvegarde des journaux prend presque autant de temps, voire plus, qu'une sauvegarde complète.

• Solution

  Activez le suivi des modifications de blocs (BCT) dans votre base de données Oracle. La fonctionnalité BCT accélère les sauvegardes incrémentielles RMAN en suivant les modifications des blocs de données, ce qui réduit la durée de sauvegarde. Cette fonctionnalité est désactivée par défaut et doit être activée manuellement.

  Avantages et inconvénients de BCT

  Avantages

  Inconvénients

  Accélère les sauvegardes incrémentielles RMAN Le fichier BCT enregistre les modifications apportées aux blocs de données. Lors d'une sauvegarde incrémentielle RMAN, le processus localise les blocs modifiés en lisant le fichier BCT au lieu d'analyser l'intégralité de la base de données. Pour les bases de données volumineuses, cette approche peut réduire le temps de sauvegarde incrémentielle de plus de 90 %. Par exemple, une analyse complète d'une base de données de 1 To peut prendre une heure, tandis qu'une sauvegarde incrémentielle utilisant BCT ne prend que quelques minutes. Réduit la charge des E/S Cette méthode limite les lectures physiques. Pendant la sauvegarde, le fichier BCT est lu directement, ce qui évite une analyse complète des tables et réduit l'impact sur l'environnement de production. Faible consommation de ressources La surcharge mémoire est quasi nulle. Le fichier BCT ne représente généralement que quelques centaines de mégaoctets. Par exemple, pour une base de données de 1 To, la taille du fichier BCT est d'environ 100 à 200 Mo. Compatibilité Prend en charge toutes les versions d'Oracle à partir de 10g R2. Oracle 12c et les versions ultérieures permettent des configurations redondantes avec plusieurs copies du fichier BCT pour améliorer la tolérance aux pannes.

  Nécessite un espace de stockage supplémentaire Taille du fichier : bien que le fichier ne représente que quelques centaines de mégaoctets, vous devez vous assurer que le chemin de stockage dispose d'un espace suffisant. Configuration redondante : si vous configurez plusieurs copies, par exemple avec REDUNDANCY 2, l'espace de stockage requis double. Impact mineur sur les performances Surcharge des opérations d'écriture : lorsqu'un bloc de données est modifié, le fichier BCT doit également être mis à jour. Cela peut légèrement affecter les performances sur les systèmes soumis à une charge d'écriture élevée. Exemple de scénario : dans un système de traitement transactionnel en ligne (OLTP) gérant des dizaines de milliers de transactions par seconde, l'impact des performances de BCT est généralement négligeable. Toutefois, il convient de surveiller les performances dans les scénarios de concurrence extrême. Risque de corruption de fichier Point de défaillance unique : si le fichier BCT est corrompu et qu'aucune redondance n'est configurée, les sauvegardes incrémentielles peuvent échouer. Complexité de la réparation : il peut être nécessaire de réactiver BCT et de reconstruire le fichier, ce qui pourrait requérir une brève interruption de service.

  Scénarios recommandés pour l'activation de BCT :

  • Systèmes effectuant des sauvegardes incrémentielles RMAN quotidiennes ou horaires.

  • Bases de données à l'échelle du téraoctet nécessitant des sauvegardes incrémentielles plus rapides.

  • Environnements de production exigeant une haute disponibilité et une récupération rapide, s'appuyant sur des sauvegardes incrémentielles.

  Faites preuve de prudence lors de l'activation de BCT dans les scénarios suivants :

  • Très petites bases de données, telles que celles de moins de 1 Go, pour lesquelles les avantages de BCT sont minimes.

  • Systèmes OLTP avec une charge d'écriture extrêmement élevée, tels que ceux traitant des dizaines de milliers de transactions par seconde, où vous devez évaluer l'impact potentiel sur les performances.

  • Environnements disposant d'un espace de stockage limité, où vous devez évaluer les besoins en stockage du fichier BCT.

Erreur non fatale RMAN lors d'une sauvegarde incrémentielle Oracle

• Symptôme

  Une sauvegarde complète de votre base de données Oracle aboutit, mais les sauvegardes incrémentielles échouent systématiquement. Vous recevez un message d'erreur similaire au suivant :

  oracle.phxxdb.18472|RMAN reports a non-fatal error:
  ORA-19505: failed to identify file "/arch/1_5137021_976544044.dbf"
  ORA-27037: unable to obtain file status
  Linux-x86_64 Error: 2: No such file or directory
  Additional information: 3

• Cause

  Ce problème est dû à des journaux d'archive manquants. Un autre script ou une autre tâche de sauvegarde a peut-être déplacé les journaux, empêchant Cloud Backup de trouver les fichiers requis pour la sauvegarde incrémentielle.

• Solution

  N'utilisez pas Cloud Backup simultanément avec d'autres logiciels ou scripts de sauvegarde. L'exécution simultanée de plusieurs outils de sauvegarde peut provoquer des conflits, entraînant des échecs de sauvegarde ou empêchant la réussite des restaurations.

Échec de l'affichage des détails de la base de données SQL Server 2019

• Symptôme

  Lorsque vous créez ou modifiez un plan de sauvegarde pour SQL Server 2019 et sélectionnez une instance de base de données, la console affiche le message d'erreur : « Failed to list unibackup instance detail ».

• Cause

  Cette erreur se produit si un autre logiciel ou script de sauvegarde exécute une sauvegarde simultanée sur SQL Server 2019 pendant que vous créez ou modifiez un plan de sauvegarde.

  La console affiche alors une boîte de dialogue d'erreur avec le message : « Failed to list unibackup instance detail ».

• Solution

  1. Supprimez le fichier C:\ProgramData\scutech\dbackup3\agent\mssql\(local)\data.db.

  2. Dans la console Services (services.msc), recherchez et redémarrez le service dbackup3-agent.

Adresse IP locale incorrecte pour SQL Server

• Symptôme

  Après avoir enregistré une base de données SQL Server locale auprès de Cloud Backup, l'adresse IP affichée dans la console Cloud Backup ne correspond pas à l'adresse IP locale de l'hôte. Ce problème survient même lorsque le client local fonctionne normalement et que son adresse IP n'a pas été modifiée.

  Dans l'onglet Local Database Instance, l'adresse IP figurant dans la colonne Client IP address appartient à la plage 169.x.x.x, qui diffère de l'adresse IP locale.

• Cause

  Dans un environnement comportant plusieurs cartes réseau, Cloud Backup récupère l'adresse IP d'une interface réseau inutilisée sur l'hôte.

• Solution

  Pour résoudre ce problème, désactivez l'interface réseau inutilisée, puis réinstallez le client.

Sauvegarde TDE SQL Server

Non, cette fonctionnalité n'est pas prise en charge.

Dépannage d'un client hors ligne impossible à désinstaller

• Symptôme

  Après avoir déployé le service anti-ransomware pour une instance SQL Server, le client apparaît hors ligne, les tentatives de suppression de la politique anti-ransomware échouent et vous ne pouvez pas désinstaller le client.

  Sur la page de gestion anti-ransomware de la console, le statut du client pour l'instance SQL Server est Offline et vous ne pouvez pas supprimer la politique anti-ransomware.

  Dans le Gestionnaire des tâches Windows, le service dbackup3-agent est arrêté et le journal de l'agent contient des entrées similaires à « Stopping all jobs ».

  Attempting to connect database ...
  ...
  Stopping all jobs

• Cause

  Un logiciel antivirus a bloqué le client. Vérifiez votre logiciel antivirus pour détecter d'éventuels enregistrements de blocage correspondants autour de cette période.

• Solution

  Ajoutez le client à la liste d'autorisation de votre logiciel antivirus et redémarrez le service client (ou réinstallez le client).

Problèmes de sauvegarde de base de données après un transfert d'instance ECS

Lorsqu'une instance ECS est transférée de son compte Alibaba Cloud d'origine vers un nouveau compte, ses métadonnées ECS ne sont pas automatiquement synchronisées avec le service Cloud Backup. Vous devez synchroniser les métadonnées ECS dans le backend du service Cloud Backup avant de pouvoir installer et utiliser la fonctionnalité de sauvegarde de base de données. Pour obtenir les étapes détaillées, contactez le support Cloud Backup ou rejoignez le groupe DingTalk de support en ligne Cloud Backup.

• Cloud Backup Technical Support Group

  Obtenez des réponses rapides à vos questions sur les tarifs, les fonctionnalités et l'utilisation. Cliquez pour rejoindre le support en ligne Cloud Backup (Chrome est recommandé). Recherchez et rejoignez le groupe public en utilisant l'ID DingTalk 88650005148.

• Cloud Backup Expert Support

  Des experts techniques fournissent une analyse en direct pour résoudre rapidement les problèmes liés aux produits. Cliquez pour contacter le support Cloud Backup (Chrome est recommandé). Ajoutez le contact sur DingTalk en utilisant l'ID : d37_g935gslgo.

Limitations de version MySQL et du système d'exploitation

Il existe des limitations concernant les versions de base de données prises en charge, les systèmes d'exploitation et les fonctionnalités de sauvegarde. Par exemple, les bases de données MySQL déployées sur Windows ne sont pas prises en charge. Pour plus d'informations, consultez la rubrique Liste de compatibilité et limites.

Sauvegarde d'une nouvelle base de données

Les sauvegardes MySQL étant effectuées au niveau de l'instance, toutes les nouvelles bases de données sont automatiquement incluses dans le prochain cycle de sauvegarde sans configuration manuelle requise.

Annuler une sauvegarde de base de données

Enregistrements de sauvegarde dupliqués ou inattendus

Ce problème survient lorsque vous clonez un serveur (serveur local ou instance ECS) sur lequel le client de sauvegarde de base de données est installé, ou lorsque vous créez une nouvelle instance ECS ou un nouveau serveur local à partir d'une image contenant ce même client. Le serveur cloné conserve certaines informations client du serveur d'origine, ce qui entraîne la duplication des enregistrements de sauvegarde. Pour résoudre ce problème, connectez-vous au serveur cloné et désinstallez le client. Pour désinstaller le client de sauvegarde de base de données, suivez les instructions ci-dessous.

Erreur du plan de sauvegarde

En cas d'échec d'une sauvegarde et si l'état du plan de sauvegarde est « Error », vérifiez tout d'abord si le serveur (serveur local ou instance ECS) sur lequel le client est installé a été cloné, si son système d'exploitation a été réinstallé ou si son disque système a été réinitialisé. Ces opérations peuvent rompre l'association entre le plan de sauvegarde et le client. Pour résoudre ce problème, suivez les étapes ci-dessous :

1. Désinstallez le client et supprimez son fichier de configuration du serveur cloné. Pour plus d'informations, consultez la section Désinstaller le client.

2. Vérifiez que l'état du client sur le serveur actuel est « Installed ».

3. Supprimez le plan de sauvegarde d'origine dans la console et créez un nouveau plan de sauvegarde.

Incohérence de l'heure d'alerte

Avec la suppression nocturne, les alertes par SMS déclenchées entre 20 h 00 et 8 h 00 ne sont envoyées qu'après 8 h 00. En revanche, les alertes par e-mail sont envoyées immédiatement.

Doublons dans les enregistrements de sauvegarde réussis et échoués

Ce problème survient lorsque vous clonez un serveur (serveur local ou instance ECS) sur lequel le client de sauvegarde de base de données est installé, ou lorsque vous créez une nouvelle instance ECS ou un nouveau serveur local à partir d'une image incluant ce même client. Le serveur cloné conserve certaines informations du client provenant du serveur d'origine, ce qui génère des enregistrements de sauvegarde en double. Pour résoudre ce problème, connectez-vous au serveur cloné et désinstallez le client. Suivez les instructions ci-dessous pour désinstaller le client de sauvegarde de base de données.

Fonctionnalité Afficher uniquement les instances hors ligne

La fonctionnalité View Offline Instances Only s'applique aux scénarios où un client ne peut plus se connecter à son instance d'origine, rendant nécessaire la restauration des données depuis une sauvegarde. Cela peut se produire si le système d'exploitation du client est réinstallé ou si le processus client et sa configuration sont supprimés, par exemple par un programme malveillant. Dans ce cas, si vous installez un nouveau client, le système lui attribue un ID d'instance différent pour le distinguer de l'instance hors ligne et éviter toute confusion. Vous pouvez ensuite restaurer les données de l'instance hors ligne vers la nouvelle instance. Pour plus d'instructions, consultez les rubriques Restaurer MySQL, Restaurer Oracle et Restaurer SQL Server.

Résolution des échecs de restauration SQL Server

1. Connectez-vous au serveur et consultez le journal de sauvegarde.

   Chemin du journal du client Windows : C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log

2. Dans le journal, vérifiez les entrées correspondant à l'heure de l'échec de la tâche.

   Si le journal de sauvegarde contient le mot-clé RestoreContainer::ValidateTargetForCreation, cela indique que l'opération de restauration a échoué car vous avez modifié le chemin de la base de données sans changer son nom, provoquant ainsi un conflit de noms. Pour réussir la restauration de la base de données, modifiez à la fois le nom de la base de données et son chemin.

Échec de la restauration SQL Server : erreur d'initialisation de fichier

• Symptôme

  Lorsqu'une restauration SQL Server échoue, le journal de l'agent indique qu'un fichier n'a pas pu être initialisé correctement. Le journal affiche les messages suivants :

  2025-11-10 11:25:53.967@iZrxhug********@2208@LM_INFO@dbackup3-agent|[SQLSERVER] output: 100 percent processed.
  2025-11-10 11:25:53.968@iZrxhug********@2208@LM_INFO@dbackup3-agent|[SQLSERVER] output: Processed 51595000 pages for database 'xxx', file 'xxx' on file 1.
  2025-11-10 11:25:53.985@iZrxhug********@2208@LM_INFO@dbackup3-agent|[SQLSERVER] output: Processed 3865 pages for database 'xxx', file 'xxx_log' on file 1.
  2025-11-10 11:25:53.987@iZrxhug********@2208@LM_INFO@dbackup3-agent|[SQLSERVER] output: File "xxx_log" failed to initialize correctly. See the error log for details.
  2025-11-10 11:25:53.989@iZrxhug********@2208@LM_INFO@dbackup3-agent|[SQLSERVER] output: RESTORE DATABASE is terminating abnormally.

  De plus, le journal des erreurs SQL Server (ErrorLog) signale le message the file "xxx_log" failed to initialize correctly.

• Cause

  Cette erreur peut survenir lors de la restauration d'une sauvegarde d'une base de données SQL Server 2008 R2 précédemment chiffrée. Même après la désactivation du chiffrement, des informations résiduelles peuvent subsister dans le jeu de sauvegarde, entraînant une erreur d'initialisation de fichier lors de la restauration. Voici le processus d'analyse.

  Remarque

  Si la base de données source est SQL Server 2008 R2 et que le chiffrement transparent des données (TDE) est activé, l'opération de restauration échoue même si l'instance cible est une version ultérieure, telle que SQL Server 2014. L'échec s'accompagne d'une erreur « Certificat introuvable ». Pour mener à bien la restauration, vous devez restaurer manuellement le certificat et la clé privée.

  1. Confirmez la version de la base de données à partir du journal des erreurs SQL Server (ErrorLog).

     Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64)

  2. Ce problème est souvent lié au chiffrement transparent des données (TDE). Vérifiez si le TDE a été activé sur la base de données source, même s'il est actuellement désactivé.

     Exécutez l'instruction SQL suivante sur la base de données. Si les colonnes key_algorithm et key_length de votre base de données ne sont pas NULL dans le résultat de la requête, la base de données a probablement été chiffrée par le passé.

     USE master;
     SELECT 
         d.name,
         d.is_encrypted,
         drs.database_id,
         drs.encryption_state,
         drs.percent_complete,
         drs.key_algorithm,
         drs.key_length
     FROM sys.databases AS d
     LEFT JOIN sys.dm_database_encryption_keys AS drs
         ON d.database_id = drs.database_id;

     Voici un exemple de résultat de requête.

     Dans les résultats de la requête, si les valeurs des champs key_algorithm et key_length pour une base de données ne sont pas NULL, cela indique que le chiffrement TDE a été activé pour cette base de données.

• Solution

  • Mettez à niveau la base de données source vers une version ultérieure et créez une nouvelle sauvegarde. Utilisez le nouveau jeu de sauvegarde pour effectuer l'opération de restauration. Les jeux de sauvegarde précédents ne sont plus valides.

  • Restaurez la clé privée et le certificat depuis l'instance source vers l'instance cible, puis effectuez l'opération de restauration.

    Une fois la restauration terminée, supprimez le certificat TDE et la clé de chiffrement de la base de données de l'instance cible. Ensuite, sauvegardez l'instance cible. Les opérations de sauvegarde et de restauration ultérieures sur l'instance cible fonctionneront correctement.

    Remarque

    Même si la sauvegarde des données a été créée après la désactivation du TDE, le processus de restauration nécessite toujours la clé privée et le certificat. Ils sont requis pour gérer les métadonnées chiffrées résiduelles présentes dans la sauvegarde. Toutefois, la base de données restaurée elle-même n'est pas chiffrée et peut fonctionner normalement sans le certificat par la suite.

    # On the source instance, run the following commands.
    USE master;
    
    # 1. Query the certificate name for the TDE-encrypted database.
    SELECT d.name AS DatabaseName,
           k.encryption_state,
           c.name AS CertificateName
    FROM sys.dm_database_encryption_keys AS k
    JOIN sys.certificates AS c
        ON k.encryptor_thumbprint = c.thumbprint
    JOIN sys.databases AS d
        ON k.database_id = d.database_id
    
    # Assume the CertificateName in the result is TDECert. Back up the TDE certificate and private key to a custom path.
    BACKUP CERTIFICATE TDECert
       TO FILE = 'C:\Backup\TDECert.cer'  -- Specify a custom file path.
       WITH PRIVATE KEY (
            FILE = 'C:\Backup\TDECert_PrivateKey.pvk',    -- Specify a custom file path.
            ENCRYPTION BY PASSWORD = 'Strong_Password_123!'    -- Remember this password.
       );
    
    -- Copy the certificate and private key from the preceding path to the target instance.
    
    # 2. On the target instance, run the following commands.
    USE master;
    
    # Restore the master key. If you receive the message 'The master key already exists in the database. Drop the master key before you perform this statement.', skip this step.
    CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Another_Strong_Password_456!';
    
    # Restore the TDE certificate.
    CREATE CERTIFICATE TDECert -- Specify a custom certificate name. You will use it later for deletion.
        FROM FILE = 'C:\TDE_Test\TDECert.cer' -- The path where the copied files are located.
        WITH PRIVATE KEY (
            FILE = 'C:\TDE_Test\TDECert_PrivateKey.pvk',
            DECRYPTION BY PASSWORD = 'Strong_Password_123!'  -- The password used when backing up the private key.
        );
    
    # 3. Perform the restore in the Cloud Backup console as usual.
    
    # 4. After the restore, delete the database encryption key.
    USE TDE_TestDB_Restore -- The name of the target database.
    DROP DATABASE ENCRYPTION KEY;
    
    # 5. Delete the certificate.
    USE master;
    DROP CERTIFICATE TDECert;

Restauration entre bases de données : environnements local et ECS

La restauration directe entre ces deux environnements n'est pas prise en charge. Vous devez d'abord enregistrer la base de données sur l'instance ECS en tant qu'instance de base de données locale. Après l'enregistrement, vous pouvez restaurer les données entre différentes instances de bases de données locales.

Qu'est-ce qu'un coffre-fort de sauvegarde de base de données ?

Vous devez créer un coffre-fort de sauvegarde de base de données avant de pouvoir créer un plan de sauvegarde de base de données.

Un coffre-fort de sauvegarde de base de données est un référentiel qui stocke vos sauvegardes de base de données. Le coût d'une sauvegarde de base de données dépend des frais de location du coffre-fort et de sa capacité. Pour plus d'informations, consultez la rubrique Méthodes de facturation et éléments facturables.

Purge des sauvegardes expirées

Les sauvegardes incrémentielles, les sauvegardes incrémentielles cumulatives et les sauvegardes des journaux dépendent toutes d'une chaîne de sauvegarde complète. Cette chaîne comprend la sauvegarde complète initiale ainsi que toutes les sauvegardes incrémentielles, incrémentielles cumulatives et des journaux suivantes. Dans une chaîne de sauvegarde, toutes les sauvegardes dépendantes sont conservées et consomment de l'espace de stockage jusqu'à l'expiration de la dernière sauvegarde de la chaîne. Configurez soigneusement votre cycle de sauvegarde et la durée de rétention afin de maîtriser les coûts de stockage.

Par exemple, si vous effectuez une sauvegarde complète le 1er septembre et une sauvegarde incrémentielle chaque jour du 2 au 7 septembre avec une période de rétention de sept jours, les sept sauvegardes créées entre le 1er et le 7 septembre seront automatiquement supprimées uniquement après l'expiration de la chaîne entière, soit le 14 septembre.

Taille des données, utilisation et facturation

Le champ Source Data Size représente le volume total de données que vous avez sauvegardé. Par exemple, si vous sauvegardez deux fois un fichier de 1 To, Cloud Backup stocke deux copies indépendantes et la Source Data Size est calculée à 2 To. Cloud Backup utilise la déduplication et la compression pour réduire l'espace de stockage consommé par vos sauvegardes, ce qui vous permet de réaliser des économies. La facturation est basée sur la Storage Vault Data Size réelle. Vous pouvez consulter la Source Data Size et la Storage Vault Data Size d'un coffre-fort de sauvegarde de base de données sur la page Gestion des coffres-forts.