L'évolution technologique actuelle de tous les aspects de la vie a rendu les données plus précieuses que l'or et l'argent. Si vous pouvez acquérir, développer et protéger des données, vous êtes sur le point d'être un dieu des données. Pourtant, les grandes entreprises qui contrôlent des aspects de la vie tels que le commerce électronique, le carburant, les transports et les paysages alimentaires comptent sur la protection des données pour se protéger d'un effondrement inévitable.
À l'heure actuelle, perdre des données, c'est comme perdre son assurance-vie. Ainsi, le système de gestion de base de données que vous utilisez doit avoir une orientation de sauvegarde. Si vous êtes un administrateur MySQL ou un utilisateur traitant de données croissantes, vous devriez envisager de mettre en place un plan d'automatisation des sauvegardes plus que fréquentes. Raison? Vous pourriez finir par être victime d'un piratage de données ou même modifier vos données par accident.
De telles circonstances peuvent entraîner des violations de données impitoyables, en particulier lorsque vous n'avez pas de plan de sauvegarde de base de données. Si vous êtes un utilisateur ou un administrateur MySQL investi, cet article est là pour résoudre vos soucis de sauvegarde de base de données. Nous répondrons à deux objectifs. Tout d'abord, vous comprendrez la mise en œuvre de l'exportation de bases de données via "mysqldump". Enfin, nous verrons comment l'utilisation de "crontab" peut faciliter l'ensemble de ce processus grâce à l'automatisation.
Préparer un répertoire de sauvegarde des données
Étant donné que Linux ne fait pas de recommandation d'utilisateur pour une destination de sauvegarde de données MySQL, c'est à vous de choisir un emplacement de sauvegarde approprié. Par exemple, dans ce guide du didacticiel, nous travaillerons sous un répertoire de sauvegarde dans "/var/www_my_backups/". Nous n'envisageons cette approche que pour comprendre les mécanismes de sauvegarde des données MySQL. Idéalement, il est recommandé que toutes les sauvegardes de données importantes aient lieu sur un serveur hors-jeu.
Vous pouvez créer votre répertoire de sauvegarde préféré sur votre machine locale via une commande de terminal similaire à la suivante :
$ sudo mkdir /var/www_my_backups/
Assurez-vous que la machine de sauvegarde sous Linux que vous utilisez vous a accordé des privilèges d'accès root ou sudo. Si vous n'avez pas d'accès propriétaire au répertoire de sauvegarde créé, vous serez confronté à des erreurs d'autorisations lors de l'exécution des tests mysqldump. La commande suivante doit répertorier l'utilisateur système actuellement actif et indiquer si vous disposez des privilèges de propriété sur le dossier de sauvegarde créé.
$ sudo chown $(whoami):$(whoami) /var/www_my_backups/
L'utilitaire client mysqldump
Cet outil MySQL réalise des sauvegardes logiques. Il en résulte plusieurs ensembles d'instructions SQL, qui recrée les données de la table de base de données d'origine et les définitions d'objet lors de l'exécution. De plus, un ou plusieurs vidages de base de données MySQL sont sauvegardés ou transférés vers un serveur de base de données SQL secondaire.
Une commande mysqldump standard est représentée par la syntaxe de commande suivante.
$ mysqldump -u [mysql_username] -p[mysql_password] [mysql_database_name] > /path/to/[mysql_dump_file_name].sql
- -u [mysql_username] : représente un utilisateur privilégié de la base de données MySQL. Cet utilisateur doit pouvoir exécuter des opérations de vidage de base de données.
- -p[mysql_password] : représente le mot de passe utilisateur de la base de données MySQL. N'ajoutez pas d'espace entre "-p" et "[mysql_password]".
- [mysql_dump_file_name] : représente le nom de votre base de données MySQL.
- > : pointe vers la destination du vidage de sortie
- /path/to/[mysql_dump_file_name].sql : pointe vers l'emplacement du chemin du fichier de vidage associé. Vous pouvez donner à ce fichier de vidage [mysql_dump_file_name] un nom personnalisé si vous le souhaitez.
Avant de poursuivre avec ce guide didacticiel, il convient de mentionner quelque chose à propos de "-p[mysql_password]". Bien que ce guide d'article se concentre sur l'association de son utilisation à plusieurs exemples de vidage MySQL, vous devez éviter de l'utiliser directement lors de la gestion de vos véritables vidages de sauvegarde MySQL, en particulier dans un réseau partagé.
Un vidage en cours d'exécution peut être piraté à l'aide d'une commande à deux dimensions telle que "ps ax", révélant le nom d'utilisateur et le mot de passe de la base de données associée. Cependant, l'utilisation de l'emplacement "~/.my.cnf" pour stocker le mot de passe de votre base de données MySQL rend inutile l'utilisation de "-p[mysql_password]" dans la commande de vidage indiquée. Si cette commande de vidage s'exécute via une tâche cron, l'option de commande "–defaults-extra-file=/path/to/.my.cnf" doit pointer la commande mysqldump vers l'emplacement du mot de passe de la base de données.
Quelques exemples de sauvegarde de base de données MySQL
Considérons plusieurs scénarios utilisateur dans lesquels nous pouvons utiliser la commande mysqldump pour sauvegarder les données de la base de données MySQL.
Sauvegarde de toutes les bases de données
L'utilisation de l'option de commande "–all-databases" dans votre commande mysqldump prendra soin de tous les vidages de base de données MySQL sur votre système Linux. Par exemple, la commande suivante montre comment vider toutes vos bases de données MySQL dans le fichier "/var/www_my_backups/" déjà existant. L'utilisateur de ce système Linux doit être root ou avoir des privilèges sudo.
Dans notre cas, et pour votre compréhension, nous avons nommé notre fichier de vidage "all-databases.sql", mais vous pouvez utiliser tout autre nom de votre choix. Étant donné que nous traitons avec toutes les bases de données, il est nécessaire d'être un utilisateur root du compte MySQL.
$ mysqldump -u root -p[mysql_password] --all-databases > /var/www_my_backups/all-databases.sql
Sauvegarder une base de données
Si une seule base de données MySQL est importante pour vous, la création de sa sauvegarde avec la commande mysqldump nécessite de remplacer l'option de commande "[mysql_database]" par le nom réel. Le nom du fichier de vidage peut prendre le nom de cette base de données "[mysql_database].sql" afin qu'il devienne facile de le tracer et de le restaurer ultérieurement. Vous pouvez également utiliser un autre nom de fichier de vidage personnalisé si vous le souhaitez.
Cet exemple de commande est implémenté à l'aide de l'utilisateur root, mais tout autre utilisateur ayant accès à la base de données ciblée est une option viable.
$ mysqldump -u root -p[mysql_password] [mysql_database_name] > /var/www_my_backups/[mysql_database_name].sql
Sauvegarde de plusieurs bases de données
Peut-être avez-vous une sélection spécifique de bases de données MySQL que vous souhaitez sauvegarder. Dans ce cas, l'option de commande "[mysql_database_name]" apparaîtra plus d'une fois, et chaque cas est associé au nom de la base de données que vous souhaitez sauvegarder. N'oubliez pas d'espacer les noms de ces bases de données sur la commande mysqldump. Le fichier de vidage "[mysql_database_name].sql" doit également être associé à un nom unique dont vous vous souviendrez.
$ mysqldump -u root -p[mysql_password] [mysql_database_1_name] [mysql_database_2_name] > /var/www_my_backups/[mysql_databases_1_2_names].sql
Sauvegarder une seule table
Lorsque votre routine de sauvegarde est uniquement après une table de base de données spécifique, la création de sa sauvegarde doit avoir à la fois le nom de la base de données et le nom de la table de la base de données comme options de commande de la commande mysqldump. Vous pouvez donner à votre fichier de vidage le même nom que la table de base de données ciblée, par ex. [mysql_database_table_name].sql.
$ mysqldump -u root -p[mysql_password] [mysql_database_name] [mysql_database_table_name] > /var/www_my_backups/[mysql_databases_table_name].sql
Sauvegarder plusieurs tables
Lorsque vous souhaitez sauvegarder de nombreuses tables de base de données MySQL spécifiques, une mention de tous les noms de table de base de données sélectionnés doit figurer après le nom de la base de données hébergeant ces tables. Le fichier de vidage ciblé pourrait prendre un nom comme [mysql_database_tables_1_2_names].sql
$ mysqldump -u root -p[mysql_password] [mysql_database_name] [mysql_database_table_1_name] [mysql_database_table_2_name] > /var/www_my_backups/[mysql_databases_tables_1_2_names].sql
Sauvegarder une ou plusieurs bases de données distantes
Cet exemple de mise en œuvre est également simple. La commande de vidage de la base de données MySQL devra inclure l'option de commande "-h" suivie du nom d'hôte de la machine distante ou de l'adresse IP associée. Toutes les autres syntaxes de commande de sauvegarde de base de données habituelles doivent alors suivre.
$ mysqldump -h [remote_computer_ip_or_hostname] -u root -p[mysql_password] [mysql_database_name] > /var/www_my_backups/[remote_mysql_database_name].sql
Vous pouvez ajuster cette commande mysqldump pour traiter les autres cas de sauvegarde de base de données déjà abordés, par exemple, les sauvegardes MySQL avec plusieurs bases de données ou tables.
Sauvegarder une base de données associée à des compressions
Si vous souhaitez associer vos sauvegardes de données à des compressions, le « | gzip -c>” L'option de commande mysqldump peut être utilisée pour diriger une sortie gzip.
$ mysqldump -u root -p[mysql_password] [mysql_database_name] | gzip -c > /var/www_my_backups/[mysql_database_name].sql.gz
Si votre base de données MySQL est énorme et que vous souhaitez suivre la progression de la compression, envisagez toujours d'implémenter l'option détaillée comme illustré dans l'exemple suivant.
$ mysqldump -u root -p[mysql_password] [mysql_database_name] | gzip -c --verbose > /var/www_my_backups/[mysql_database_name].sql.gz
Restauration de la base de données MySQL
Une fois que vous avez terminé la sauvegarde de votre base de données MySQL, que se passe-t-il ensuite ? Comment accédez-vous aux données que vous avez si soigneusement sécurisées ? La restauration de vos données nécessite le respect de la syntaxe de restauration MySQL suivante.
$ mysql -u [mysql_username] -p[mysql_password] [mysql_database_name] < /path/to/[mysql_database_name].sql
Comme vous ne l'avez peut-être pas remarqué, la seule différence entre cette commande de restauration de base de données et la commande de sauvegarde de base de données est que nous utilisons l'option "mysql" au lieu de l'option "mysqldump" et l'option "<" au lieu de l'option ">".
Automatisation des sauvegardes MySQL
Le système d'exploitation Linux est équipé de plusieurs services utiles qui n'ont pas de prix pour un administrateur de base de données comme celui du SGBDR MySQL. L'un de ces services est le service cron. Il est efficace pour programmer des commandes automatisées. Ces commandes, une fois créées, sont affectées à la table crontab cron. Vous pouvez accéder à crontab via la commande suivante.
$ sudo crontab -e
Si vous y êtes invité, cette commande peut vouloir associer son exécution à un éditeur de texte pour sélectionner l'éditeur de texte nano.
Un fichier avec un nom comme "/tmp/crontab.LVY6A9/crontab" s'ouvrira. Au bas de ce fichier crontab, entrez un calendrier cron viable avec une commande de vidage MySQL applicable. L'exemple illustré ci-dessous implémente l'utilisation de la compression gzip pour les sauvegardes quotidiennes de la base de données. Parfois, vous pouvez avoir de gros fichiers .sql programmés pour la sauvegarde. L'utilisation de gzip réduit ces fichiers à des tailles raisonnables avant le stockage de sauvegarde. Il aide à la gestion de la mémoire de sauvegarde.
00 03 * * * mysqldump -u root -p[mysql_password] [mysql_database_name] | gzip -c > /var/www_my_backups/[mysql_database_name].sql.gz
L'option de commande « 00 03 *** » peut être interprétée de la manière suivante. Toutes les 24 heures après 3 heures du matin, la commande mysqldump qui la suit est exécutée pour sauvegarder une base de données. Le fichier de sauvegarde de la base de données qui existait actuellement avant le lancement de ce processus de sauvegarde est écrasé. Dans votre cas, vous n'avez pas besoin d'attendre 24 heures pour voir l'automatisation de la sauvegarde de votre base de données en action via crontab.
Vous pouvez modifier l'option "00 03 ***" sur le fichier crontab en quelque chose comme "02 00 ***", et en seulement deux minutes, le processus de sauvegarde devrait s'auto-initialiser. Alternativement, si votre heure est 22h30, l'édition du fichier avec "34 22 ***" initialisera le processus de sauvegarde de la base de données à 22h34. Pensez à sauvegarder (Ctrl+X) ce fichier crontab avant de le fermer pour que cette commande devienne exécutable.
Une fois les minutes que vous avez définies écoulées, la tâche cron devrait avoir été exécutée. Ensuite, répertoriez le dossier de sauvegarde créé sur votre terminal et le fichier de sauvegarde .sql.gz créé devrait être présent.
$ ls -l /var/www_my_backups/
La sortie résultante doit ressembler à ce qui suit :
-rw-r--r-- 1 root root 36M Jul 29 22:24 [mysql_database_name].sql.gz
Si vous avez des problèmes pour repérer le fichier de sauvegarde MySQL .sql.gz, relisez votre temps crontab ou la commande entière. Il peut y avoir une erreur de syntaxe ou quelque chose peut manquer. Alternativement, le journal cron du système pourrait indiquer où il y a un problème.
$ sudo grep CRON /var/log/syslog
N'oubliez pas de réinitialiser l'entrée crontab à votre planification de base de données préférée une fois que vous avez confirmé que tout fonctionne correctement.
Utiliser my.cnf pour stocker les mots de passe de la base de données MySQL
Nous avons déjà évoqué les inconvénients de l'option « -p[mysql_password] » sur une commande mysqldump, notamment sous un réseau partagé. Nous devons discuter de la manière d'implémenter le stockage des mots de passe dans le fichier "~/.my.cnf". Les utilisateurs utilisant cron pour automatiser leurs sauvegardes de base de données devront comprendre l'implémentation de l'option de commande « –defaults-extra-file=/path/to/.my.cnf ».
Modifier mon fichier.cnf
Le répertoire personnel de votre système Linux contient ce fichier caché. Le chemin d'accès direct au système est "/home/your_username/.my.cnf". Utilisez l'éditeur de texte nano pour ouvrir ce fichier. L'option "~" pointe vers le répertoire personnel.
$ sudo nano ~/.my.cnf
Modifiez ce fichier ouvert selon la syntaxe suivante pour stocker avec succès votre mot de passe de base de données MySQL. La partie "YOUR_DB_PASS" est la seule entrée que vous devez modifier avec votre mot de passe de base de données réel. Entrez ces détails d'information au bas du fichier et enregistrez-les.
[mysqldump]
password=YOUR_DB_PASS
Utilisez Ctrl+X pour enregistrer ce fichier. Ce fichier "my.cnf" a également besoin de certains paramètres d'autorisation. Implémentez la commande suivante :
$ sudo chmod 600 ~/.my.cnf
Il est maintenant temps de voir la recréation de notre nouvelle commande mysqldump avec l'option de commande "-p[mysql_password]" éliminée.
$ mysqldump -u root [mysql_database_name] | gzip -c > /var/www_my_backups/[mysql_database_name].sql.gz
Comme vous pouvez le voir, nous n'avons rien ajouté. Il semble que la seule chose que nous ayons supprimée soit l'option de commande "-p[mysql_password]".
Crontab et –defaults-extrs-file
Pour les utilisateurs qui préfèrent automatiser les sauvegardes de la base de données, vous devrez récupérer le mot de passe de la base de données dans le fichier "~/.my.cnf" via l'option de commande "–defaults-extra-file". Cette approche facilite les choses pour la commande mysqldump lorsqu'elle doit référencer l'utilisateur de la base de données et l'authenticité du mot de passe. Vous devez être précis sur le chemin d'accès au fichier my.cnf et ne pas simplement utiliser le symbole "~". Considérez l'implémentation suivante dans le fichier crontab :
30 22 * * * mysqldump --defaults-extra-file=/home/system_username/.my.cnf -u root [mysql_database_name] | gzip -c > /var/www_my_backups/[mysql_database_name].sql.gz
Dans cet exemple, crontab s'exécute tous les jours à 22h30 pour créer une compression gzip sauvegardée de la base de données MySQL.
Remarque finale
Cet article a examiné les mécanismes de sauvegarde de la base de données locale concernant le répertoire de sauvegarde « /var/www_my_backups ». Puisque vous comprenez maintenant comment se déroule le processus de sauvegarde, vous devez évoluer et commencer à penser aux sauvegardes hors site. Cependant, une approche plus pratique consiste à configurer l'accès SFTP qui pointe vers ce répertoire de sauvegarde "/var/www_my_backups".
Avec une telle configuration en place, il est possible de créer une tâche cron SFTP via un serveur distant pour récupérer une copie de ces fichiers de base de données stockés localement pour le stockage d'assurance la nuit et tous les jours.
Alors que nous concluons ce guide d'article génial, vous êtes maintenant un fier maître des scénarios de sauvegarde de base de données MySQL, de la restauration de la sauvegarde de la base de données et de l'automatisation de la sauvegarde de la base de données. Vous devriez maintenant faire preuve de confiance et être confiant dans l'utilisation des tâches cron pour planifier et gérer l'automatisation de la sauvegarde de votre base de données MySQL. Les horaires d'automatisation ne doivent pas nécessairement être quotidiens car ils peuvent également être hebdomadaires et mensuels.
