Le 2021-03-17 17:20, Thomas Pedoussaut a écrit :
Le 17/03/2021 à 13:13, Richard DEMONGEOT a écrit :
Le snapshot est (selon moi) viable pour des VM avec peu d'écritures
(genre PHP, ....) mais pas pour les serveurs de bases de données par
exemple. Ou alors, il faut - dans l'arbo - faire un dump SQL propre
qui lui est snapshot-safe.
En MySQL on peut faire un "FLUSH TABLE WITH READ LOCK" pour figer une
image disque "safe" afin de faire un snapshot (lvs, zfs, ceph...) puis
liberer le lock.
Oui, c'est une solution aussi :). C'est proche de ce que j'utilise :p.
Un détail près, je le fait sur un slave dédié au backup, et donc je me
permet de couper le démon complètement.
Les ENT de plusieurs académies francaises sont backupées comme cela,
avec une vitesse de reprise sur incident sans commune mesure avec une
remontée de backup classique.
L'avantage du démon arrêté, y compris avec le "innodb-fast-shutdown = 0"
c'est que je n'ai plus les redo logs à rejouer lorsque je restaure le
backup.
Revers de la médaille:
- tu ne peut pas restaurer une table. (donc mysqldump, reste intéressant
pour ça);
- Si tu as une corruption binaire (déjà vu :/) , tu la traine dans les
backups.
Cordialement,
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
