Service de sauvegarde et de reprise après sinistre pour MySQL
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
MySQL est la base de données Open Source la plus populaire au monde, utilisée par des propriétés Web de premier plan.
Cette page explique comment protéger les données de base de données cohérentes de l'application MySQL avec la sauvegarde et la reprise après sinistre dans un environnement Linux.
API de sauvegarde MySQL utilisée par Backup and DR
Sauvegardes au niveau du volume (suivi des blocs de modification Linux et instantané LVM) : API MySQL Flush tables overwriting the data area. With read lock et Unlock tables.
Sauvegardes complètes et incrémentielles (traditionnelles basées sur des fichiers): API MySQL mysqldump. Vous obtenez ainsi la sauvegarde complète de la base de données au format de sauvegarde. Lors de la récupération, l'API de restauration de la base de données récupère la base de données en écrasant physiquement la zone de données.
Sauvegarde des journaux MySQL: lors d'une sauvegarde de journaux, Backup & DR copie physiquement tous les journaux binaires MySQL. L'API MySQL purge binary logs before est utilisée pour purger les journaux binaires.
Fonctionnement: sauvegarde et reprise après sinistre basées sur les volumes avec CBT Linux
Seuls les blocs modifiés sont suivis dans le bitmap: pas de copie sur écriture, pas d'opérations gourmandes en E/S.
La sauvegarde et la récupération de données se déroulent comme suit:
L'agent de sauvegarde et de reprise après sinistre dispose d'un CBT pour suivre les blocs modifiés dans la zone de données de la base de données.
L'agent appelle l'API de la base de données pour la congeler ou la suspendre afin de sauvegarder les données.
L'agent crée un instantané LVM de la zone de données de la base de données et synthétise un bitmap.
Appel de l'agent à l'API de la base de données pour dégeler la base de données.
L'agent copie les blocs modifiés sur l'appareil de sauvegarde/restauration, qui supprime ensuite l'instantané et catalogue la sauvegarde.
L'appliance génère un instantané interne et synthétise une sauvegarde complète virtuelle à un moment précis.
Pour la récupération de données, la sauvegarde et la reprise après sinistre installent instantanément un disque d'espace de préparation réécrivable et mettent la base de données en ligne.
Fonctionnement: sauvegarde basée sur des fichiers
Les instructions suivantes décrivent comment effectuer la sauvegarde et la récupération de données à l'aide d'images de sauvegarde basées sur des fichiers:
L'agent de sauvegarde et de reprise après sinistre est déployé sur le serveur de base de données.
Montez le disque de préproduction sur le serveur de base de données.
Appelez une sauvegarde complète à l'aide de la commande de sauvegarde de vidage, en écrivant la sauvegarde sur le disque monté.
Backup and DR prend un instantané interne.
Les sauvegardes des journaux sont effectuées de manière similaire directement à partir du système de fichiers à une fréquence que vous configurez.
Pour la récupération de données, la sauvegarde et la reprise après sinistre installent instantanément le disque d'espace de préparation sur le serveur de base de données et lancent l'opération de restauration de la base de données.
Les journaux peuvent être lus à n'importe quel moment après la restauration de la base de données.
Cette page fait partie d'une série de pages spécifiques à la protection et à la récupération des bases de données MySQL avec la sauvegarde et la reprise après sinistre. Pour en savoir plus, consultez les pages suivantes:
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[[["\u003cp\u003eBackup and DR protects MySQL databases in Linux environments using both volume-level backups with Linux change block tracking (CBT) and LVM snapshots, and file-based backups via the \u003ccode\u003emysqldump\u003c/code\u003e API.\u003c/p\u003e\n"],["\u003cp\u003eVolume-level backups utilize MySQL APIs to freeze and unfreeze the database, create LVM snapshots, track changed blocks with CBT, and copy only changed blocks to the backup/recovery appliance.\u003c/p\u003e\n"],["\u003cp\u003eFile-based backups use the \u003ccode\u003emysqldump\u003c/code\u003e API to write full backups to a mounted staging disk, and log backups are performed directly from the file-system.\u003c/p\u003e\n"],["\u003cp\u003eFor recovery, Backup and DR mounts a rewritable staging disk and brings the database online instantly in the volume-level method, and in the file-based method, it mounts the staging disk and restores the database, with logs being able to be played to any point in time after restoration.\u003c/p\u003e\n"],["\u003cp\u003eMySQL binary logs can be purged via the \u003ccode\u003epurge binary logs before\u003c/code\u003e API during a log backup, which also copies all the binary logs.\u003c/p\u003e\n"]]],[],null,["# Backup and DR Service for MySQL\n\nMySQL is the world's most popular open source database, used by high profile web\nproperties.\nThis page explains how to protect MySQL application consistent database\ndata with Backup and DR in a Linux environment.\n\n**MySQL backup API used by Backup and DR**\n\n- **Volume level (Linux change block tracking and LVM snapshot) backups** :\n MySQL `Flush tables overwriting the data area. With read lock` and\n `Unlock tables` API.\n\n- **Full+Incremental (file-based traditional) backups** : MySQL `mysqldump`\n API. This provides the full backup of the database in backup\n format. On recovery, the restore db API recovers the database by physically\n overwriting the data area.\n\n- **MySQL log backup** : During a log backup, Backup and DR physically copies\n all the MySQL binary logs. The MySQL `purge binary logs before` API is used\n to purge the binary logs.\n\nHow it works: Backup and DR volume-based backup with Linux CBT\n--------------------------------------------------------------\n\nOnly changed blocks are tracked in the bitmap: no copy-on-writes, no I/O-intensive operations.\n\nData backup and recovery follows these steps:\n\n1. The Backup and DR agent has CBT to track changed blocks in the database data\n area.\n\n2. The agent calls the database API to freeze or pause database for data backup.\n\n3. Agent creates LVM snapshot of database data area and synthesizes a bitmap.\n\n4. Agent call to database API to unfreeze database.\n\n5. Agent copies changed blocks to backup/recovery appliance, which then deletes\n the snapshot and catalogs the backup.\n\n6. The appliance issues an internal snapshot and synthesizes a point-in-time\n virtual full backup.\n\n7. For data recovery, Backup and DR instantly mounts a rewritable staging disk\n and brings the database online.\n\nHow it works: file-based backup\n-------------------------------\n\nThe following instructions describe the process for how to perform data backup\nand recovery with file-based backup images:\n\n1. Backup and DR agent is deployed in the database server.\n\n2. Mount staging disk on the database server.\n\n3. Invoke full backup using the dump backup command, writing the backup\n to the mounted disk.\n\n4. Backup and DR takes an internal snapshot.\n Log backups are done in a similar fashion directly from the file-system at\n any schedule that you configure.\n\n5. For data recovery, Backup and DR instantly mounts the staging disk to the\n database server and initiates the database restore operation.\n Logs can be played to any point in time after the database is restored.\n\nWhat's next\n-----------\n\n[Prepare the database for Backup and DR](/backup-disaster-recovery/docs/configuration/otherdb-prep-database)\n\nOther documentation for Backup and DR for MySQL\n-----------------------------------------------\n\nThis page is one in a series of pages specific to protecting and recovering\nMySQL databases with Backup and DR.\nYou can find additional information at:\n\n- [Backup and DR for MySQL](/backup-disaster-recovery/docs/concepts/mysql-intro)\n- [Prepare the database for Backup and DR](/backup-disaster-recovery/docs/configuration/otherdb-prep-database)\n- [Add a MySQL database host and discover databases](/backup-disaster-recovery/docs/configuration/otherdb-add-host)\n- [Define policy templates and resource profiles](/backup-disaster-recovery/docs/create-plan/create-template)\n- [Set application details and settings](/backup-disaster-recovery/docs/backup/app-details-settings-otherdb)\n- [Check staging disk format and backup method](/backup-disaster-recovery/docs/backup/backup-method-staging-disk-otherdb)\n- [Protect the MySQL database and its logs](/backup-disaster-recovery/docs/backup/otherdb-protect)\n- [Mount a MySQL database](/backup-disaster-recovery/docs/access-data/otherdb-mounts)\n- [Recover MySQL Backups](/backup-disaster-recovery/docs/restore-data/otherdb-restore)\n- [Create a MySQL Backup and DR Workflow](/backup-disaster-recovery/docs/access-data/otherdb-workflow)"]]