{"id":2931,"date":"2017-12-30T14:00:15","date_gmt":"2017-12-30T13:00:15","guid":{"rendered":"http:\/\/www.unicoda.com\/?p=2931"},"modified":"2019-04-05T23:26:19","modified_gmt":"2019-04-05T21:26:19","slug":"sauvegarde-de-base-de-donnees-avec-mysqldump-et-logrotate","status":"publish","type":"post","link":"https:\/\/www.unicoda.com\/?p=2931","title":{"rendered":"Sauvegarde de base de donn\u00e9es avec mysqldump et logrotate"},"content":{"rendered":"

Cela faisait plus d’un an que j’avais vaguement mentionn\u00e9 la question de la sauvegarde d’Unicoda et des autres services que j’h\u00e9berge. Jusqu’\u00e0 pr\u00e9sent, je m’\u00e9tais content\u00e9 de quelques sauvegardes manuelles effectu\u00e9es de temps \u00e0 autre, lorsque le contenu avait bien \u00e9volu\u00e9 ou que la sauvegarde pr\u00e9c\u00e9dente commen\u00e7ait \u00e0 dater. Je me suis donc int\u00e9ress\u00e9 aux diff\u00e9rentes solutions qu’on rencontre sur le net : rsync, rclone, duplicity, script bash, bacula, pour ne citer que quelque-uns des outils. Si l’automatisation de la sauvegarde ne m’avait jamais sembl\u00e9 essentielle, c’est que j’\u00e9tais conscient des risques et me reposait sur la duplication RAID de l’h\u00e9bergeur (pour le risque de d\u00e9faut mat\u00e9riel), mais surtout, parce que la majorit\u00e9 des informations \u00e9tait g\u00e9n\u00e9ralement pr\u00e9sente en local sur l’une ou l’autre de mes machines. Apr\u00e8s les r\u00e9cents changements de serveurs et le passage \u00e0 l’auto-h\u00e9bergement de nombreux services, la sauvegarde devient critique. Commen\u00e7ons donc par nous pencher sur la sauvegarde des donn\u00e9es du serveur SQL.<\/p>\n

Pour exporter les donn\u00e9es d’un serveur MySQL, la commande mysqldump est tout indiqu\u00e9e. Pour sauvegarder l’int\u00e9gralit\u00e9 des bases du serveur avec l’utilisateur root, on pourra par exemple utiliser :<\/p>\n

mysqldump -u root -p --all-databases > all_databases.sql<\/pre>\n
De la m\u00eame mani\u00e8re, il est possible de n’extraire qu’une seule base de donn\u00e9es :<\/p>\n
mysqldump -u [user] -p maBase > maBDD.sql<\/pre>\n
Il est possible de sp\u00e9cifier le mot de passe de l’utilisateur directement dans la commande via -p[motDePasse] ou encore -p'[motDePasse]’.\u00a0 Une fois en possession d’une copie de notre base, l’import s’effectue simplement en utilisant :<\/p>\n
mysql -u [user] -p maNouvelleBase < maBDD.sql<\/pre>\n
J’ai eu l’occasion de mettre \u00e0 l’\u00e9preuve cette m\u00e9thode lors des diff\u00e9rentes migrations d’Unicoda; toujours avec succ\u00e8s et sans jamais rencontrer de probl\u00e8me.<\/p>\n
Maintenant que nous avons une fa\u00e7on de sauvegarder les donn\u00e9es de MySQL, il est temps de s’int\u00e9resser \u00e0 l’automatisation du processus.\u00a0 Afin de r\u00e9gler la question de l’accumulation des fichiers de sauvegarde, j’ai d\u00e9cid\u00e9 d’utiliser logrotate, en d\u00e9tournant quelque peu son usage pour l’appliquer \u00e0 mes sauvegardes SQL et non \u00e0 des fichiers de logs. Avant toutes choses, je cr\u00e9e un nouvel utilisateur au niveau de MySQL en le limitant aux droits Lock Tables et Select sur la base que je veux sauvegarder.<\/p>\n
GRANT LOCK TABLES, SELECT ON maBase.* TO '<user>'@'localhost' IDENTIFIED BY '<password>';<\/pre>\n
On passe ensuite \u00e0 la configuration de logrotate pour notre fichier de sauvegarde. J’ajoute donc un fichier dans \/etc\/logrotate.d\/sauvegarde-base-sql avec le contenu suivant :<\/p>\n
\/var\/backups\/mysql\/maBDD.sql.gz {\r\n  daily\r\n  dateext\r\n  rotate 21\r\n  nocompress\r\n  create\r\n  postrotate\r\n  mysqldump --single-transaction --add-drop-table -u user -pmonMotDePasse baseASauvegarder > \/var\/backups\/mysql\/maBDD.sql\r\n  gzip -9f \/var\/backups\/mysql\/maBDD.sql\r\n  chown user:user \/var\/backups\/mysql\/maBDD.sql.gz\r\n  chmod 640 \/var\/backups\/mysql\/maBDD.sql.gz\r\n  endscript\r\n}<\/pre>\n
C\u00f4t\u00e9 param\u00e8tres :<\/p>\n