Le 17/03/21 à 17:20, Thomas Pedoussaut <tho...@pedoussaut.com> 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, je fais ça depuis des années (avec du snapshot lvm) et ça marche bien, mais j'ai quand même eu une fois un pb avec des journaux innoDb corrompus, donc pas sûr que ce soit complètement fiable. À l'époque j'ai pas creusé car le snapshot de la veille me suffisait et que j'avais vraiment pas le temps ce jour là (ok, mauvaise excuse j'aurais dû creuser). > 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. Y'a des ENT qui tournent avec mysql ? ;-) Pas sûr que ce soit un bon exemple, y'a au moins un ENT qui a été HS de longues heures après l'incendie ;-) Mais quand on en est à remonter les backups, c'est que c'est vraiment une grosse cata et qu'on est pas à qq heures près, pour une reprise sur incident plus courant la réplication est quand même bcp plus efficace. C'est pas pour la durée de reprise que je fais du backup raw, c'est pour la durée du dump et la conso disque que ça génère (j'en fais quand même, à partir des backup raw dans une VM qui fait que ça, mais moins souvent que les snapshots disque). -- Daniel Un conducteur dangereux, c'est celui qui vous dépasse malgré tous vos efforts pour l'en empêcher. Woody Allen --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
