On ne le répétera jamais assez : faites des sauvegardes ! Et non, ça n’est pas compliqué, oui il existe des dizaines et des dizaines de solutions possibles, donc vous n’avez pas d’excuse pour ne pas le faire.
Si vous utilisez WordPress, vous avez peut-être déjà installé l’extension BackWPUp qui fonctionne à merveille. Si ça n’est pas le cas, ou si vous souhaitez sauvegarder d’autres projets en même temps, je vous propose ce petit script de sauvegarde en shell (pour ubuntu par exemple) qui vous permettra de :
- sauvegarder tous les fichiers d’un répertoire ;
- mettre à jour votre répertoire à partir d’un serveur distant ;
- créer un dump de vos bases de données, une par une ;
- mettre à jour vos bases de de données à partir d’un serveur distant ;
- créer une archive gzippée de votre sauvegarde.
Et tout ça en moins de 50 lignes, commentaires compris.
Ainsi vous n’aurez qu’à planifier un lancement de ce script à la fréquence qui vous convient pour ne pas avoir à vous soucier de vos backups.
Mon script de sauvegarde d’un serveur Linux
Que contient ce script ?
- Avant tout une section de paramétrage : vous définissez les valeurs qui vous intéressent afin d’accéder à votre serveur distant et de choisir où vont être sauvegardées vos données ;
- Ensuite une copie bête et méchante d’un dossier, dans le cas qui m’intéresse il s’agit du dossier contenant tous mes codes sources ;
- Après la copie, le serveur local est mis à jour pour avoir les mêmes fichiers que le serveur distant : les nouveaux fichiers seront ajoutés, les mises à jour prises en compte et les fichiers inexistants sur le serveur distant seront effacés du serveur local ;
- Puis vient le tour du traitement des bases de données. Le script de sauvegarde commence par lister toutes les bases de données herbergées sur le serveur local puis :
- crée une archive par base de données avec mysqldump. De cette façon il est plus simple de restaurer une base de données en particulier sans avoir à la retrouver au milieu de toutes les autres si on avait créé un gros dump contenant toutes les bases de données ;
- met à jour les bases de données locales en injectant directement le dump fait à partir du serveur distant ;
- Compresse tous les fichiers sauvegardés dans une belle archive .tar.gz
- Efface le dossier temporaire contenant tous les fichiers sauvegardés pour ne conserver que l’archive .tar.gz et le journal des opérations .log
Un script de backup, mais pas que
Vous avez pu constater que le script s’occupe aussi de rapatrier des données d’un environnement vers un autre. En fait, si vous le lancez toutes les nuits il vous permettra d’avoir le matin une archive contenant l’état à J-1 de votre serveur local et un serveur local contenant les même informations (à J0) que votre serveur distant.
Cela peut être pratique dans un grand nombre de cas : si vous souhaitez synchroniser plusieurs serveurs entre eux, pour mettre à jours des serveurs secondaires selon les données d’un serveur primaire (si vous ne l’avez pas déjà fait je vous invite à lire mon billet sur la mise en place d’une architecture serveurs distribuée), pour avoir tous vos dossiers avec vous quand vous prenez votre ordinateur portable… ou dans mon cas pour être sûr que votre serveur de développement travaille avec des données actuelles et pas du lorem ipsum créé par un utilisateur “toto”.
Ensuite, chacun est libre d’adapter le script pour, par exemple ne pas sauvegarder ni mettre à jour les bases de données de développement, mais rapatrier simplement un dump des bases de données distantes, le code ressemblera alors à ça :
Par contre si vous souhaitez simplement faire une copie des fichiers, tous les jours ou toutes les semaines, je vous conseille de conserver quand même le répertoire local à synchroniser plutôt que de le créer et de l’effacer à chaque fois : de cette façon seules les modifications seront transférées et non l’intégralité des données. Si vous souhaitez faire un backup complet, en transférant toutes les données et toutes les bases de données, rien de plus simple :
Je ne vais pas multiplier les exemples de personnalisation mais vous aurez bien compris qu’il ne s’agit que d’une base de travail (même si le script fonctionne en l’état) et que chaque besoin étant unique, vous n’aurez probablement pas la même version finale que celles que j’utilise.
Mais au fait, quels sont vos besoins ? Est-ce que vous gérez vos sauvegardes à la main, avec des scripts ou des logiciels complets ? A quelle fréquence lancez-vous vos backups ? Et combien de temps les conservez-vous ? Les commentaires sont à vous, n’hésitez pas à partager votre expérience.