Bonjour à tous,

J'ai une question au sujet de sauvegardes de MySQL.
Je vois souvent dans les forums l'explication de faire un dump pour la sauvegarde des bases de données MySQL.

Ma question:
Pourquoi ne pas faire une simple copie du dossier mysql ? (/var/lib/mysql par exemple)
Et en cas de restore, remettre simplement les fichier des bases à la place des autres...

Merci pour l'info et meilleures salutations!
oui, ça marche aussi très bien (on évitera juste de restaurer sur une autre machine / arch / version ou OS)

Et ça peut même permette des sauvegardes à chaud en minimisant l'indisponibilité, et sans arrêt (qui a aussi l'inconvénient de vider les caches et donc diminuer les perfs le temps qu'ils se rechargent)

Un truc du genre (utilisé en prod)

En quelques secondes
- FLUSH TABLES WITH READ LOCK
- création d'un snapshot dur FS (LVM, ZFS, ...)
- UNLOCK TABLES

Sauvegardes réelles
- sauvegarde du snapshot
- destruction du snapshot

Ne pas aussi oublier de sauvegarder régulièrement les log binaires qui permettent de reconstituer une base, à partir d'une "vieille" sauvegarde à froid.

Bref, il y a plein de "solutions" pour mettre en place une stratégie de sauvegarde MySQL, en fonction des besoins
Je vois souvent dans les forums l'explication de faire un dump pour la sauvegarde des bases de données MySQL.
Grosso modo la plupart propose un dump car ce dernier peut répondre au 3/4 des situations de restauration de bases ; inconvénient, c'est le plus lourd.
Ne faut-il pas aussi que les tables soient en MyISAM pour faire une copie du dossier?
Le dossier /var/lib/mysql contient aussi les données des bases InnoDb (ibdata* et ib_log*)
Merci pour les réponses 🙂

Admettons que je fasse le gros lourd, en sauvegardant le dossier copier-coller sans lock des tables, sans dump ou autre.
Et que en cas de crash, je fasse le chemin en sens inverse copier-coller et lancer le service MySQL, Est-ce que ca poserait problème ?
Quels sont les risques ?
T'as toute les chances d'avoirs un base corrompue.
Après ça dépends aussi de la taille de la base et de la charge sur le serveur au moment de la sauvegarde

Mais si l'activité et la taille sont limitées, tu peux sans doute te permettre d’arrêter le serveur et avoir une sauvegarde à froid qui reste la solution la plus fiable.

Encore une fois, on n'applique pas la même stratégie à une base gérant un blog (quelques Mio) qui reçoit quelques dizaines de visites par jour, et une base sur une application critique, genre plusieurs Gio et plusieurs centaines de requêtes par minute, 24h/24 (et je parle pas des sites genre Facebook ou Wikipedia)
OK
Si je comprend bien ce qui peut rendre la base de donnée corrompue, c'est le fait d'avoir une requête au même moment que la copie du fichier de la base.

Bon là entre autre ce n'est pas un serveur web, c'est une entreprise de création de programmes et ils ne bossent pas la nuit 🙂
Donc le mieux pour moi est d'arrêter le service le temps du backup (2min 30 sur ce serveur) et relancer le service après coup...
5 jours plus tard
swisstico wrote:OK
Si je comprend bien ce qui peut rendre la base de donnée corrompue, c'est le fait d'avoir une requête au même moment que la copie du fichier de la base.

Bon là entre autre ce n'est pas un serveur web, c'est une entreprise de création de programmes et ils ne bossent pas la nuit 🙂
Donc le mieux pour moi est d'arrêter le service le temps du backup (2min 30 sur ce serveur) et relancer le service après coup...
Oui c'est en général ce que font les boîtes, sauf pour les applications critiques comme l'a dit remi. De plus pour les applications très critiques (chaîne de production par exemple), il y a en général un deuxième serveur clôné qui peut servir de back up.