Discussion :

[encoremoi21258]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Merci d'avance

[N_BaH]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[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...

[encoremoi21258]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[N_BaH]

l'erreur affichée par tar porte sur la destination de la compression, pas sur la source à compresser.

[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.

[Sve@r]

En me contentant d'indiquer

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

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"...

[N_BaH]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Christophe]

Tu peux essayer avec l'option --single-transaction de mysqldump. Si tu as des tables assez grosses, ajoutes --quick.

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

--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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

--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 :

Sélectionner tout - Visualiser dans une fenêtre à part

--quick

pour que ça donne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

--single-transaction --quick

quel est précisément l'effet de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

--quick

dans cette situation ?

Désolé pour ce message très long, j'ai essayé de répondre à tout.

[Sve@r]

Mais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

En utilisant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Christophe]

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.