La sauvegarde de la base de données mySql hébergée chez Free

Il est toujours vital de sauvegarder les données d'une base de données mysql comme celle du site 'Tendoryu'. Les sauvegardes permettent de restaurer totalement (ou en partie) les données perdues.
Chaque article, la configuration du site, les journaux font l'objet, chacun d'un enregistrement dans la base. Perdre la base, c'est perdre le travail de tous les contributeurs du site.

Evènements possibles:

• Le fai Free peut suspendre l'accès au site pur une raison ou une autre. (sécurité)
• Crash serveur(s) de Free.
• Incohérence dans le contenu de la base.
• Une migration de données mal engagée. (Joomla évolue)
• Une extension a mis le 'bordel'.
  
• Altération malveillante des données par un hacker ou autre
  
• ...

On voudrait également pouvoir 'cloner' simplement le site sur une clé usb pour des démonstrations. Etc...

Comme Free ne permet pas l'accès distant à leurs serveurs mySql avec une interface de programmation ( API), on contourne le manque de liberté en biaisant le système presque officiellement. ;-)
Pour se faire, je me suis inspiré de l'excellent script de Olivier BERGER (blob).

Au script, j'ai ajouté l'envoi du fichier 'dump' compressé en pièce jointe d'un courrier electronique à destination d'un compte Gmail dédié aux sauvegardes tendoryu.
Sur ce compte, j'ai créé un filtre de messages.
Si le message reçu provient de 'mon-adresse@monfai' et le sujet débute par 'MySql-backup:OK:' et qu'une pièce jointe est présente alors j'archive directement le message dans un dossier dédié aux backups.
Sinon, par défaut, si le fichier dump a été mal-généré ou pas du tout, alors j'envoie un courrier électronique avec pour sujet 'MySql-backup:KO:'. Je le laisse dans la "boite de réception" Gmail.

Le corps du message contient le fichier 'curl.headers'.
Voici un exemple.

HTTP/1.1 200 OK
Date: Fri, 04 Apr 2008 09:38:42 GMT
Server: Apache/1.3.39 (Unix)
Pragma: public
Expires: 0
Cache-Control: must-revalidate, post-check=0, pre-check=0
Cache-Control: private
Content-Disposition: attachment; filename="aiki_tendo-2008-04

-04-10-38-42.gz";
Content-Transfer-Encoding: binary
Content-Length: 54691
Connection: close
Content-Type: application/x-gzip

Je conserve les dix derniers fichiers dump sur le poste initiateur de la sauvegarde. (je vous laisse deviner où c'est. Bon, j'entends une mouche voler. La réponse: sur mon poste linux, à la maison). Les fichiers sont horodatés.
Le script est exécuté automatiquement par le cron à 06h00 tous les jours.
Pourquoi 06h00? Ben c'est juste avant mon réveil (raison principale mais il y en a d'autres). Je consulte normalement mes emails avant de partir au travail. Voilà, voilà.

Je ne gère pas de période de rétention pour les backups sur le compte Gmail. C'est parfaitement inutile. Un compte Gmail peut stocker pas loin de 6go actuellement. A raison de 80ko par sauvegarde, le compte ne sera saturé avant environ 215 ans... Oups. No comment. Merci Google.

On pourrait également fiabiliser l'externalisation des sauvegardes avec le même principe en créant d'autres comptes courriels. Au hasard, chez Yahoo. Chez eux, la capacité de stockage des emails est illimité. No comment. Un grand merci (virtuel) à Yahoo également.
Il suffirait de modifier une ligne du script:

cat curl.headers | mutt -a backup_mysql_$filename \
-s "MySql-backup:OK:${taille}ko:${filename}" mon-compte@gmail.com

par

cat curl.headers | mutt -a backup_mysql_$filename \
-s "MySql-backup:OK:${taille}ko:${filename}" mon-compte@gmail.com,mon-compte-secours@yahoo.fr

Que c'est facile, l'externalisation de données pour un particulier, n'est-ce pas? Et c'est gratuit.

On pourrait également chiffrer les fichiers dump. Inutile pour l'instant. Laissons à la NSA le soin d'analyser nos courriels correctement avec facilité. Hugh.