Avec MySQL comme avec les autres SGBDr, la façon la plus portable de sauvegarder ses données est d'en extraire des fichiers sql susceptibles de servir à reconstruire la base et y replacer ses données ce qui s'appelle en anglais un « dump ».

MySQL propose un script du nom de mysqldump qui fait ça très bien. Il produit des fichiers texte qui contiennent des instructions sql. Ces fichiers se compressent très bien, et comme les bases sont souvent grandes, les utilitaires comme gzip sont très utiles pour gagner de l'espace disque.

Le problème commence lorsqu'on envisage des sauvegardes incrémentales. Avec les utilitaires comme rsnapshot qui utilise rsync et les liens en dur, seuls les fichiers modifiés depuis la dernière sauvegarde sont sauvegardés. On économise ainsi de l'espace disque et de la bande passante. Mais les fichiers de dump sont à chaque fois nouveaux, car même si leur contenu n'a pas changé, le fichier lui est nouveau. Du coup rsync le télécharge. Et si vous faites un dump des bases de votres serveur MySQL toutes les quatre heures vous allez télécharger six fois par jour la même chose si vos bases reçoivent rarement des modifications.

Lire la suite de Horodatage des sauvegardes de dump de base de donnée

Pourquoi changer de shell ?

Depuis Debian 6.0 Squeeze, le Shell générique par défaut n'est plus bash mais dash qui est beaucoup plus rapide à charger. Dash est un shell plus limité que Bash (voir ce comparatif en anglais). Pour une utilisation sur un serveur que l'on ne passe pas son temps à démarrer, l'argument du temps de démarrage n'a pas beaucoup de sens  et si comme moi vous avez certains scripts qui ne fonctionnent pas sous dash, pouvoir revenir à bash par défaut n'est pas sans intérêt.

Lire la suite de Choix du shell sur Debian et dérivé