Atomicité de la sauvegarde du système de fichiers Linux

En ce qui concerne les bases de données, il est parfois plus sûr de vider les données et de les sauvegarder. Par exemple, MySql est livré avec l'outil mysqldump qui peut accomplir cette tâche.

J'utilise Bacula pour faire mes sauvegardes, et je l'ai configuré pour exécuter mysqldump pour vider les bases de données dans un répertoire pour les vidages et ensuite bacula sauvegarde ce répertoire. Je fais quelque chose de similaire pour SVN.

Je n'ai pas automatisé la procédure de restauration, mais au moins j'ai les données dans un format facile à importer dans MySql et probablement dans d'autres bases de données puisque le fichier de vidage est juste du SQL.

Oui, ils peuvent toujours être copiés. Comme suggéré ci-dessus, je viderais les bases de données dans un fichier, je les compresserais pour une bonne compression et je les enverrais par rsync à l'endroit où vous le souhaitez.

# mysqldump --all-databases -u user -p | bzip2 -c > mysqlbackup.sql.bz2
# <rsync stuff here>

Ensuite, pour le charger dans la nouvelle base de données

# bzip2 -d mysqlbackup.sql.bz2
# mysql -u user -p < mysqlbackup.sql

Pour atténuer encore plus la paranoïa, j'ai parfois recours à lsof -F | grep <keyword> pour voir si le fichier que je veux transférer est effectivement utilisé, ou ouvert. Si lsof renvoie null, je sais que je peux continuer. Vous pourriez l'utiliser pour rechercher une table MySQL ouverte pendant que MySQL y écrit. Une fois que lsof renvoie null, vous pouvez continuer à transférer des fichiers.

Selon cette page vous devez sauvegarder la base de données dans un fichier et l'arrêter avant le rsync. Ce n'est pas idéal car vous devez sauvegarder toute la base de données à chaque fois. Une procédure spécialisée de sauvegarde de la base de données est préférable.