Sauvegarde automatique de la base de données

Version imprimable

Bonjour,

Je possède un site internet avec Cpanel et je souhaite mettre en place une sauvegarde automatique de la base de données qui se lance via une tâche cron.

Je sais qu'on peut procéder ainsi:

Code:

0 0 * * * /usr/bin/mysqldump -u db_username -p db_password db_name > /backup/path/backup.sql

Sauf que je souhaite si possible passer par un fichier .sh lancé par la tâche cron et qui créé cette sauvegarde.
Code:

1 2 3 4 5 6 7 8 9 #!/bin/bash STAMP=`date +%Y-%m-%d_%H-%M-%S` SOURCE=/home/monsite/public_html DEST=/home/monsite/bck /usr/bin/mysqldump -u utilisateur -p'motdepasse' basededonnes > $SOURCE/basededonnes$STAMP.sql env GZIP=-9 tar czf $DEST/basededonnes$STAMP.tar.gz $SOURCE/ #sql dump file is packaged in the tar.gz and then removed. rm $SOURCE/basededonnes$STAMP.sql
Mais j'ai alors reçu cet email à chaque fois que la tâche cron est lancée:
Code:

1 2 3 4 mysqldump: Got error: 1044: "Access denied for user 'utilisateur'@'localhost' to database 'basededonnes'" when using LOCK TABLES tar: Removing leading `/' from member names tar (child): /home/monsite/bck/basededonnes-02-21_20-24-01.tar.gz: Cannot open: No such file or directory tar (child): Error is not recoverable: exiting now
J'ai ajouté rajouté --skip-lock-tables dans la ligne débutant par /usr/bin/mysqldump

Mais ça ne fonctionne toujours pas:
Code:

1 2 3 tar: Removing leading `/' from member names tar (child): /home/monsite/bck/basededonnees2023-02-21_20-44-02.tar.gz: Cannot open: No such file or directory tar (child): Error is not recoverable: exiting now
Je ne souhaite pas que la tâche soit bloquée lors de la sauvegarde sinon il y aura des erreurs si une requête est lancée au même moment.

Même si je donne tous les privilège à l'utilisateur MySql et que je supprime le --skip-lock-tables ça ne fonctionne pas:
Code:

1 2 3 tar: Removing leading `/' from member names tar (child): /home/monutilisateur/bck/basededonnees2023-02-21_20-49-02.tar.gz: Cannot open: No such file or directory tar (child): Error is not recoverable: exiting now
Sauriez vous où est mon erreur ?

Actuellement, dans CPanel la tâche cron se lance simplement avec:

Code:

/home/monutilisateur/public_html/bck/script.sh

Merci d'avance

21/02/2023, 21h04
N_BaH

Citation:

Code:

tar (child): /home/monsite/bck/basededonnes-02-21_20-24-01.tar.gz: Cannot open: No such file or directory

un (ou plusieurs) des éléments du chemin n'existerait pas.
cf. help test
21/02/2023, 21h08
Sve@r

Bonjour

Ce serait peut-être plus un souci MySQL que bash...

Mais déjà pour essayer de trouver l'erreur il serait peut-être utile d'exécuter le script bash manuellement voir s'il fait les choses bien avant de le mettre dans un cron...
21/02/2023, 21h43
encoremoi21258

Le problème semble lié à l'utilisation de

Code:

/usr/bin/mysqldump

malgré le fait que ce soit indiqué ainsi dans l'exemple:
https://github.com/zmrfzn/Cpanel-Bac...anel_Backup.sh

En me contentant d'indiquer

Code:

mysqldump

ça fonctionne. Cela explique que le fichier .sql n'était pas créé, ce qui a entraîné l'impossibilité de le compresser.

Il ne reste plus qu'à le faire pour chaque base de données sans oublier de traiter les anciennes sauvegardes pour ne pas saturer le disque.

Je vous remercie, c'est toujours utile d'échanger quelques mots avec une personne n'ayant jamais vu le code quand on cherche sans trouver :)
21/02/2023, 21h52
N_BaH

l'erreur affichée par tar porte sur la destination de la compression, pas sur la source à compresser.
22/02/2023, 08h10
Christophe

Le problème vient du fait que ton utilisateur MySQL n'a pas le droit de poser des locks. L'export ne se faisant pas, tar affiche une erreur, son fichier source n'existant pas.
22/02/2023, 10h04
Sve@r
Citation:

Envoyé par encoremoi21258

En me contentant d'indiquer

Code:

mysqldump

ça fonctionne. Cela explique que le fichier .sql n'était pas créé, ce qui a entraîné l'impossibilité de le compresser.

Ben c'est vrai que quand on crée un script de ce genre style "je crée un fichier; je compresse le fichier dans un tar; j'efface le fichier d'origine" il serait plus prudent de rajouter des points de contrôle style "je crée un fichier; je vérifie que le fichier a été correctement créé; je compresse le fichier dans un tar; je vérifie si la compression s'est bien effectuée; j'efface le fichier d'origine".

Je te conseillerais aussi de remplacer env GZIP=-9 tar czf $DEST/basededonnes$STAMP.tar.gz $SOURCE/ par tar cf - "$SOURCE" |gzip -c9 >"$DEST/basededonnes$STAMP.tar.gz" pour 2 raisons
- je n'aime pas les commandes qui font papa+maman alors que la commande "maman" existe déjà. Au mieux le "papa+maman" fera pareil que "papa" d'abord puis "maman" après et au pire elle fera moins bien. La commande "tar" son but est d'archiver. La compression a été rajoutée après et (de mon point de vue) pour rien vu que gzip existait déjà et faisait parfaitement le job.
- c'est plus souple en utilisation. Hier c'était gzip, aujourd'hui ça peut être "xz" (plus puissant) => tar cf - "$SOURCE" |xz -9 >"$DEST/basededonnes$STAMP.tar.xz" ; et demain ça peut être encore autre chose.
Et les guillemets c'est qu'on encadre toujours une string de double quotes. Cela permet au shell de gérer correctement les espaces éventuels de la string.

Citation:

Envoyé par encoremoi21258

sans oublier de traiter les anciennes sauvegardes pour ne pas saturer le disque.

Perso j'ai créé différents type de sauvegarde
- la sauvegarde annuelle => le fichier se nomme "bdd_yyyy.sql.xz". Permet de faire plusieurs sauvegardes dans la même année sur le même fichier
- la sauvegarde mensuelle=> le fichier se nomme "bdd_yyyy_mm.sql.xz". Permet de faire plusieurs sauvegardes dans le même mois sur le même fichier
- la sauvegarde hebdomadaire => le fichier se nomme "bdd_yyyy_no_semaine.sql.xz". Permet de faire plusieurs sauvegardes dans la même semaine sur le même fichier
- la sauvegarde journalière => le fichier se nomme "bdd_yyyy_mm_jj.sql.xz". Permet de faire plusieurs sauvegardes dans la même journée sur le même fichier
- la sauvegarde horaire => le fichier se nomme "bdd_yyyy_mm_jj_hhH.sql.xz". Permet de faire plusieurs sauvegardes dans la même heure sur le même fichier
Ainsi l'utilisateur peut affiner au choix l'espace disque, ou la granularité de l'historique attendu. Sinon tu peux utiliser l'outil standard "logrotate"...

Citation:

Envoyé par chrtophe

Le problème vient du fait que ton utilisateur MySQL n'a pas le droit de poser des locks. L'export ne se faisant pas, tar affiche une erreur, son fichier source n'existant pas.

quand un fichier source n'existe pas j'ai un autre message (cannot stat) :
Code:

1 2 3 4 $ LC_ALL=C tar czf monTest.tar.gz nExistePas tar: nExistePas: Cannot stat: No such file or directory tar: Exiting with failure status due to previous errors $
alors que lorsqu'il y a une erreur dans le chemin destination, le message ressemble davantage à celui reçu par encoremoi21258 (cannot open) :
Code:

1 2 3 4 5 6 7 $ LC_ALL=C tar czf /no/way/monTest.tar.gz lorem\ ipsum tar (child): /no/way/monTest.tar.gz: Cannot open: No such file or directory tar (child): Error is not recoverable: exiting now tar: /no/way/monTest.tar.gz: Cannot write: Broken pipe tar: Child returned status 2 tar: Error is not recoverable: exiting now $
NB : ça ne contredit pas que le dump ne se fait peut-être pas.

23/02/2023, 08h42
Christophe

Tu peux essayer avec l'option --single-transaction de mysqldump. Si tu as des tables assez grosses, ajoutes --quick.
25/02/2023, 17h50
encoremoi21258

Bonjour,

Selon ce que je sais, le lock sert uniquement à éviter une écriture dans la base de données pendant la sauvegarde. Mais si le site ou autre chose essaye d'écrire pendant le lock, cela provoquera une erreur. C'est pourquoi je ne souhaite pas de lock et j'ai donc ajouté

Code:

--skip-lock-tables

, je pense que ça ne provoquera pas de problème particulier de procéder ainsi.

Le fichier .sql est créé, la compression est effectuée, le fichier .sql est supprimé. Cela signifie donc selon moi que le chemin est indiqué correctement, sinon l'une des étapes ne se ferait pas car le fichier nécessaire à l'étape ne serait pas trouvé. Mais

Code:

tar: Removing leading `/' from member names

n'a pas encore disparu de l'email reçu après chaque exécution de la tâche cron. En soit ce n'est pas gênant mais je ne comprends pas encore pourquoi il y a ce message.

J'ai fais de nombreux essais, et le fichier est toujours créé. Je ne vois pas vraiment pourquoi il faudrait contrôler l'existence du fichier avant de le compresser. En faite, est-il vraiment possible qu'un jour le fichier n'existe pas lors de la tentative de compression ? Ou est-ce une vérification juste comme ça car ça ne coûte rien de le faire ? J'aime bien comprendre ce que j'ajoute dans le script.

Pour la compression, en utilisant

Code:

tar cf - "$SOURCE" |gzip -c9 >"$DEST/basededonnes$STAMP.tar.gz"

ça m'a l'air (sans certitude totale) un peu plus rapide.

En utilisant

Code:

tar cf - "$SOURCE" |xz -9 >"$DEST/basededonnes$STAMP.tar.xz"

c'est (à la louche) 3 fois plus lent, mais le fichier compressé occupe 44% moins d'espace disque.

Le but principal est de disposer de sauvegardes plus régulières. C'est trop contraignant selon moi de me connecter chaque soir pour sauvegarder manuellement car parfois je peux oublier, ou ne pas avoir le temps. Et puis automatiser le tout permet de faire des sauvegardes encore plus souvent pour perdre un minimum de données en cas de problème.

Un autre obstacle à l'automatisation du processus arrive. Je télécharge toujours les sauvegardes, puis je chiffre le fichier avec un logiciel présent sur mon ordinateur, puis je transferts la sauvegarde chiffrée vers l'Object Storage d'OVH, et je supprime la copie locale de la sauvegarde et sur le FTP de mon site. Pour le moment je ne vois pas comment automatiser ça.

J'ai ajouté

Code:

--single-transaction

et la création du fichier .sql est nettement plus rapide, voir immédiate. Contre une durée de quelques secondes auparavant. Cela me semble donc être extrêmement positif pour utiliser moins de RAM et de CPU, en tout cas moins longtemps.

Je ne vois par contre pas de changement en ajoutant

Code:

--quick

pour que ça donne

Code:

--single-transaction --quick

quel est précisément l'effet de

Code:

--quick

dans cette situation ?

Désolé pour ce message très long, j'ai essayé de répondre à tout.
25/02/2023, 18h04
Sve@r

Citation:

Envoyé par encoremoi21258

Mais

Code:

tar: Removing leading `/' from member names

n'a pas encore disparu de l'email reçu après chaque exécution de la tâche cron. En soit ce n'est pas gênant mais je ne comprends pas encore pourquoi il y a ce message.

Ah ça c'est une sécurité. Cela permet de ne pas écraser un dossier système si tu restaures l'archive sur un autre OS.
Imagine que tu archives "/etc" et que cette sécurité n'y soit pas (comme c'était le cas à l'origine). Puis tu vas sur un autre système et tu restaures l'archive sans faire gaffe, tu pêtes le "/etc" de l'autre système.
En supprimant le "/", les fichiers sont archivés en relatif et si l'archive est restaurée plus tard, elle le sera dans le home de l'utilisateur (je présume qu'il travaille dans son HOME quand il travaille). Ensuite charge à lui de prendre le "etc/" local nouvellement créé et remettre manuellement ce qu'il faut où il faut si besoin.
Mais il y a une option (me souviens plus laquelle) pour supprimer cette sécurité si tu le désires.

Citation:

Envoyé par encoremoi21258

En utilisant

Code:

tar cf - "$SOURCE" |xz -9 >"$DEST/basededonnes$STAMP.tar.xz"

c'est (à la louche) 3 fois plus lent, mais le fichier compressé occupe 44% moins d'espace disque.

Hé oui. Compression très puissante mais (fatalement) plus lente. Tu peux aussi jouer avec la force de compression (9) pour affiner. Perso je m'en fouts du temps que ça prend (parfois plusieurs minutes) car chez moi l'opération n'a pas besoin d'aller vite mais mes priorités ne sont pas forcément les tiennes donc à toi de voir. Tu as les deux méthodes.
26/02/2023, 08h36
Christophe

Citation:

Selon ce que je sais, le lock sert uniquement à éviter une écriture dans la base de données pendant la sauvegarde. Mais si le site ou autre chose essaye d'écrire pendant le lock, cela provoquera une erreur. C'est pourquoi je ne souhaite pas de lock

Sauf qu'un lock va te permettre d'avoir une sauvegarde cohérente, empêchant par exemple que pendant le backup de la table B, la table A soit modifiée rendant la base incohérente.