NetVault Plug-in for MySQL 12.2 - Guide de l'utilisateur

Finalisation et soumission de la tâche

Les dernières étapes consistent à configurer les options supplémentaires des pages Planification, Options sources et Options avancées, à soumettre la tâche et à surveiller la progression sur les pages État de la tâche et Afficher les journaux. Ces pages et ces options sont communes à tous les plug-ins NetVault Backup. Pour plus d'informations, reportez-vous au Guide de l'administrateur de Quest NetVault Backup.

IMPORTANT: n’utilisez pas de caractères spéciaux qui ne sont pas pris en charge dans un nom de fichier sur le système d’exploitation cible. Par exemple, les caractères /,\,*, et @ ne doivent pas être utilisés sous Windows. Cette exigence est due au fait que Plug‑in for MySQL tente de créer un dossier portant le même nom que le titre de la session pour restaurer temporairement les données.

CONSEIL: vous pouvez également cliquer sur Choisir, puis localiser et sélectionner le client approprié dans la boîte de dialogue Choisir le client cible.

IMPORTANT: Si vous utilisez MySQL Enterprise Backup dans un environnement Linux ou UNIX, vérifiez que les informations de propriété et d’autorisation sur les données restaurées correspondent à ce qu’elles étaient avant la sauvegarde des données. Comme l’utilitaire mysqlbackup n’enregistre pas ces informations pendant le processus de sauvegarde, elles peuvent être différentes une fois la restauration terminée. Pour plus d’informations, voir https://docs.oracle.com/cd/E17952_01/mysql-enterprise-backup-3.11-en/bugs.backup.html.

Exemples de scénarios de restauration pour MySQL Standard/Community

Pour une reprise réussie après une panne ou une corruption de données, divers réglages doivent être effectués lors de la configuration de la session concernant les données sélectionnées pour la restauration et les options disponibles dans l’onglet Options. Les rubriques suivantes offrent des exemples de différents types de restauration et couvrent les options spécifiques requises.

Scénarios de restauration de sauvegarde complète uniquement

Dans les exemples suivants, l’administrateur de bases de données MySQL a défini une stratégie de sauvegarde dans laquelle les sauvegardes complètes sont effectuées quotidiennement à 23 h 00.

Lundi à 9 h 00, l’administrateur de bases de données apprend que les utilisateurs rencontrent des erreurs « tableau non trouvé » sur le tableau des commandes. Il se rend compte que le tableau n’existe plus parce qu’un développeur l’a supprimé sans le savoir à 6 h 00 le lundi avant l’arrivée de l’administrateur de bases de données au travail.

L’administrateur de bases de données décide de procéder à une récupération jusqu’à l’heure juste avant l’exécution de la commande Supprimer le tableau. Cette décision signifie que l’administrateur de base de données doit restaurer la sauvegarde complète du dimanche et exécuter la récupération PIT sur les journaux binaires actuels.

L’administrateur de bases de données décide de procéder à une récupération jusqu’à l’heure juste avant l’exécution de la commande Supprimer le tableau. L'administrateur de bases de données veut aussi récupérer les transactions qui se sont produites dans les tableaux restants après le moment où l'instruction erronée a été émise, et jusqu'à la fin des journaux binaires actuels. Cette décision garantit qu’il a récupéré autant de transactions que possible, en plus de récupérer le tableau supprimé.

Lundi à 9 h 00, l’administrateur de bases de données apprend que les utilisateurs rencontrent des erreurs « tableau non trouvé » sur le tableau des commandes. Il se rend compte que le tableau n’existe plus parce qu’un développeur l’a supprimé sans le savoir à 6 h 00 le lundi avant l’arrivée de l’administrateur de bases de données au travail.

L’administrateur de bases de données décide de procéder à une récupération jusqu’à l’heure juste avant l’exécution de la commande Supprimer le tableau. De plus, comme l’administrateur de bases de données veut une récupération plus précise que l’estimation de l’heure à laquelle le développeur a supprimé le tableau, il choisit d’utiliser une récupération en fonction de la position. Pour accomplir ce processus, l’administrateur de base de données doit restaurer la sauvegarde complète du dimanche et effectuer une récupération PIT sur les journaux binaires actuels.

IMPORTANT: les positions d’arrêt et de début doivent être des positions réelles listées dans un journal binaire, et non des nombres arbitraires qui sont supérieurs à la position de la transaction indésirable.

L’administrateur de bases de données décide de procéder à une récupération jusqu’à l’heure juste avant l’exécution de la commande Supprimer le tableau. Il veut aussi récupérer les transactions qui se sont produites dans les autres tableaux après le moment où le tableau des commandes a été supprimé et jusqu’à la fin des journaux binaires actuels. Cette décision garantit qu’il a récupéré autant de transactions que possible, en plus de récupérer le tableau supprimé. De plus, l’administrateur de base de données veut une récupération plus précise, c'est pourquoi il décide d'utiliser une récupération en fonction de la position. Pour accomplir ce processus, l’administrateur de base de données doit restaurer la sauvegarde complète du dimanche et effectuer une récupération PIT sur les journaux binaires actuels.

IMPORTANT: les positions d’arrêt et de début doivent être des positions réelles listées dans un journal binaire, et non des nombres arbitraires qui sont supérieurs à la position de la transaction indésirable.

Scénarios de restauration de sauvegarde complète et incrémentielle

L’administrateur de bases de données a établi une stratégie de sauvegarde selon laquelle les sauvegardes complètes sont effectuées chaque dimanche à 23 h et les sauvegardes incrémentielles sont effectuées du lundi au samedi, à 23 h. Comme l’administrateur de bases de données effectue des sauvegardes incrémentielles, les journaux binaires sont supprimés après chaque sauvegarde incrémentielle. Ce processus accélère la sauvegarde globale, mais nécessite plus de temps et d'étapes lors de la restauration.

Jeudi à 9 h 00, l’administrateur de bases de données apprend que les utilisateurs rencontrent des erreurs « tableau non trouvé » sur le tableau des commandes. Il se rend compte que le tableau n’existe plus parce qu’un développeur a supprimé sans le savoir le tableau tôt jeudi avant l’arrivée de l'administrateur de bases de données au travail.

L'administrateur de bases de données décide d'effectuer une restauration complète jusqu'au point de la dernière sauvegarde incrémentielle, soit la sauvegarde effectuée le mercredi soir.

Dans les exemples suivants, un scénario de sauvegarde complète et incrémentielle est en place, et l’administrateur de bases de données souhaite récupérer les données à un moment précis.

Jeudi à 9 h 00, l’administrateur de bases de données apprend que les utilisateurs rencontrent des erreurs « tableau non trouvé » sur le tableau des commandes. Il se rend compte que le tableau n’existe plus parce qu’un développeur l’a supprimé sans le savoir à 20 h 00 le mercredi.

L’administrateur de base de données doit restaurer la base de données jusqu’à l’heure juste avant que le développeur ne supprime le tableau à 20 h 00 le mercredi. Par conséquent, les phases suivantes seront effectuées :

Jeudi à 9 h 00, l’administrateur de bases de données apprend que les utilisateurs rencontrent des erreurs « tableau non trouvé » sur le tableau des commandes. Il se rend compte que le tableau n’existe plus parce qu’un développeur l’a supprimé sans le savoir à 20 h 00 le mercredi.

L’administrateur de base de données décide de faire une restauration jusqu’à l’heure juste avant l’exécution de la commande Supprimer le tableau à 20 h 00. Il veut également récupérer les transactions qui se sont produites sur les autres tableaux après le moment où le tableau des commandes a été supprimé, et jusqu’à la fin des journaux binaires sauvegardés. Cette décision garantit qu’il a récupéré autant de transactions que possible, en plus de récupérer le tableau supprimé. Par conséquent, les phases suivantes seront effectuées :

Jeudi à 9 h 00, l’administrateur de bases de données apprend que les utilisateurs rencontrent des erreurs « tableau non trouvé » sur le tableau des commandes. Il se rend compte que le tableau n'existe plus parce qu'un développeur l'a supprimé sans le savoir à 6h00 le jeudi.

L'administrateur de base de données doit restaurer la base de données jusqu'à l'heure juste avant que le développeur ne supprime le tableau à 06h00 le jeudi.

Jeudi à 9 h 00, l’administrateur de bases de données apprend que les utilisateurs rencontrent des erreurs « tableau non trouvé » sur le tableau des commandes. Il se rend compte que le tableau n’existe plus parce qu’un développeur l’a supprimé sans le savoir à 6 h 00 le jeudi.

L’administrateur de bases de données décide de procéder à une récupération jusqu’à l’heure juste avant l’exécution de la commande Supprimer le tableau. Il veut aussi récupérer les transactions qui se sont produites dans les autres tableaux après le moment où le tableau des commandes a été supprimé et jusqu’à la fin des journaux binaires actuels. Cette décision garantit qu'il a récupéré autant de transactions que possible, en plus de récupérer le tableau supprimé. Par conséquent, les phases suivantes seront effectuées :

Dans les exemples suivants, un scénario de sauvegarde complète et incrémentielle est en place, et l’administrateur de base de données souhaite récupérer les données à un moment précis, mais utiliser une méthode plus définitive pour définir l’heure. Cette restauration se fait en utilisant les « valeurs de position » identifiées qui existent dans les journaux binaires MySQL.

Jeudi à 9 h 00, l’administrateur de bases de données apprend que les utilisateurs rencontrent des erreurs « tableau non trouvé » sur le tableau des commandes. Il se rend compte que le tableau n’existe plus parce qu’un développeur l’a supprimé sans le savoir à 20 h 00 le mercredi.

L’administrateur de bases de données décide de procéder à une récupération jusqu’à l’heure juste avant l’exécution de la commande Supprimer le tableau. De plus, l’administrateur de base de données veut une récupération plus précise, c’est pourquoi il décide d’utiliser une récupération en fonction de la position. Pour accomplir ce processus, l’administrateur de bases de données doit restaurer la sauvegarde complète du dimanche et les sauvegardes incrémentielles suivantes effectuées le lundi et le mardi, puis effectuer une récupération PIT en fonction de la position en utilisant la sauvegarde incrémentielle du mercredi. Les phases suivantes illustrent ce processus :

Dans cette phase, seuls les journaux binaires enregistrés dans la sauvegarde incrémentielle du mercredi soir sont restaurés dans un emplacement temporaire. Ce processus permet à l’administrateur de bases de données de localiser la position spécifique dans le journal qui marque le moment où le tableau des commandes a été supprimé.

Utiliser l'utilitaire mysqlbinlog sur les journaux binaires restaurés : cette étape est exécutée en dehors de NetVault Backup pour identifier la position de la commande Supprimer le tableau que l’administrateur de bases de données ne veut pas restaurer. Pour plus d’informations sur cet utilitaire et ce processus, consultez le MySQL Reference Guide (Guide de référence MySQL). Dans ce processus, l’administrateur de bases de données a identifié la commande Supprimer le tableau comme position de journal « 805 » dans le journal binaire « MYSQLSVR-bin.000009 » qui a été restauré à l’emplacement temporaire sur le serveur MySQL, et les deux valeurs ont été notées.

Une fois la position identifiée à partir du journal binaire restauré, une restauration PIT est effectuée en utilisant la sauvegarde incrémentielle du mercredi.

Jeudi à 9 h 00, l’administrateur de bases de données apprend que les utilisateurs rencontrent des erreurs « tableau non trouvé » sur le tableau des commandes. Il se rend compte que le tableau n’existe plus parce qu’un développeur l’a supprimé sans le savoir à 20 h 00 le mercredi.

L’administrateur de bases de données décide de procéder à une récupération jusqu’à l’heure juste avant l’exécution de la commande Supprimer le tableau. Il veut aussi récupérer les transactions qui se sont produites dans les autres tableaux après le moment où le tableau des commandes a été supprimé et jusqu’à la fin des journaux binaires sauvegardés. De plus, l’administrateur de base de données veut une récupération plus précise, c’est pourquoi il décide d’utiliser une récupération en fonction de la position. Pour accomplir ce processus, l’administrateur de bases de données doit restaurer la sauvegarde complète du dimanche et les sauvegardes incrémentielles suivantes effectuées le lundi et le mardi, puis effectuer une récupération PIT en fonction de la position en utilisant la sauvegarde incrémentielle du mercredi. Les phases suivantes illustrent ce processus :

Dans cette phase, seuls les journaux binaires enregistrés dans la sauvegarde incrémentielle du mercredi soir sont restaurés dans un emplacement temporaire. Cette étape permet à l’administrateur de bases de données de localiser la position spécifique dans le journal qui marque le moment où le tableau des commandes a été supprimé.

Utiliser l'utilitaire mysqlbinlog sur les journaux binaires restaurés : cette étape est exécutée en dehors de NetVault Backup pour identifier la position de la commande Supprimer le tableau que l’administrateur de bases de données ne veut pas restaurer. Pour plus d’informations sur cet utilitaire et ce processus, consultez le MySQL Reference Guide (Guide de référence MySQL). Dans ce processus, l’administrateur de bases de données a identifié la commande Supprimer le tableau comme position de journal « 805 » dans le journal binaire « MYSQLSVR-bin.000009 » qui a été restauré à l’emplacement temporaire sur le serveur MySQL, et les deux valeurs ont été notées.

Une fois la position identifiée à partir des journaux binaires restaurés, la restauration PIT est ensuite effectuée en utilisant la sauvegarde incrémentielle du mercredi.

IMPORTANT: les positions d’arrêt et de début doivent être des positions réelles listées dans un journal binaire, et non des nombres arbitraires qui sont supérieurs à la position de la transaction indésirable.

Jeudi à 9 h 00, l’administrateur de bases de données apprend que les utilisateurs rencontrent des erreurs « tableau non trouvé » sur le tableau des commandes. Il se rend compte que le tableau n’existe plus parce qu’un développeur l’a supprimé sans le savoir à 6 h 00 le jeudi.

L’administrateur de base de données doit restaurer la base de données jusqu’à l’heure juste avant que le développeur ne supprime le tableau à 6 h 00 le jeudi. De plus, l’administrateur de base de données veut une récupération plus précise, c’est pourquoi il décide d’utiliser une récupération en fonction de la position. Pour accomplir ce processus, l’administrateur de bases de données doit restaurer la sauvegarde complète du dimanche et les sauvegardes incrémentielles suivantes effectuées le lundi et le mardi, puis effectuer une récupération PIT en fonction de la position en utilisant la sauvegarde incrémentielle du mercredi. Les phases suivantes illustrent ce processus :

Utiliser l’utilitaire mysqlbinlog sur les journaux binaires actuels : cette étape est exécutée en dehors de NetVault Backup pour identifier la position de la commande Supprimer le tableau que l’administrateur de bases de données ne veut pas restaurer. Pour plus d’informations sur cet utilitaire et ce processus, consultez le MySQL Reference Guide (Guide de référence MySQL). Dans ce processus, l’administrateur de bases de données a identifié la commande Supprimer le tableau comme position de journal « 805 » dans le journal binaire actuel, « MYSQLSVR-bin.000009 ».

Une fois la position identifiée à partir des journaux binaires restaurés, la restauration PIT est ensuite effectuée en utilisant la sauvegarde incrémentielle du mercredi.

Jeudi à 9 h 00, l’administrateur de bases de données apprend que les utilisateurs rencontrent des erreurs « tableau non trouvé » sur le tableau des commandes. Il se rend compte que le tableau n’existe plus parce qu’un développeur l’a supprimé sans le savoir à 6 h 00 le jeudi.

L’administrateur de base de données doit restaurer la base de données jusqu’à l’heure juste avant que le développeur ne supprime le tableau à 6 h 00 le jeudi. De plus, l’administrateur de base de données veut une récupération plus précise, c’est pourquoi il décide d’utiliser une récupération en fonction de la position. Pour accomplir ce processus, l’administrateur de bases de données doit restaurer la sauvegarde complète du dimanche et les sauvegardes incrémentielles suivantes effectuées le lundi et le mardi, puis effectuer une récupération PIT en fonction de la position en utilisant la sauvegarde incrémentielle du mercredi. Les phases suivantes illustrent ce processus :

Utiliser l’utilitaire mysqlbinlog sur les journaux binaires actuels : cette étape est exécutée en dehors de NetVault Backup pour identifier la position de la commande Supprimer le tableau que l’administrateur de bases de données ne veut pas restaurer. Pour plus d’informations sur cet utilitaire et ce processus, consultez le MySQL Reference Guide (Guide de référence MySQL). Dans ce processus, l’administrateur de bases de données a identifié la commande Supprimer le tableau comme position de journal « 805 » dans le journal binaire actuel, « MYSQLSVR-bin.000009 ».

Une fois la position identifiée à partir des journaux binaires restaurés, la restauration PIT est ensuite effectuée en utilisant la sauvegarde incrémentielle du mercredi.

IMPORTANT: les positions d’arrêt et de début doivent être des positions réelles listées dans un journal binaire, et non des nombres arbitraires qui sont supérieurs à la position de la transaction indésirable.