[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: système simple pour sauvegarder partitions os en train de tourner.




On 06/04/2023 14:31, Michel Verdier wrote:
Le 6 avril 2023 Jean-François Bachelet a écrit :

oui rsync est bien , mais si tu rsync une partition en train de tourner avec
des bases de données mysql ou autre en route moi je chope des messages comme
quoi le contenu de mes bdd à changé pendant la copie rsync :(
Pour les bases je fais un dump à chaud et je rsync les dumps. Je fais les
dump table par table comme ça seules les tables modifiées doivent être
reprises. Avec postgresql c'est encore mieux le dump est garanti
globalement au niveau transactionnel. Je fais ça aussi pour openldap et
ça doit pouvoir se faire pour tes autres applis.


A mon avis le problème n'est pas lié à rsync. Il est plus général.

La question originelle posée par Benoît était:


Existe-t-il un moyen sûr de sauvegarder les partitions montées d'un système en train de tourner ?
Du coup le logiciel de clonage serait installé sur le système lui même et pas sur un disque externe...

De mon point de vue cette sauvegarde ne sera jamais complètement sûre.


Je vois des cas où elle poserait problème:

En particulier en pensant à de gros fichiers (gros veut dire ici supérieur en taille à la RAM disponible, donc plusieurs gigaoctets ou au moins certains fichiers dont la génération ou l'écriture prend plus d'un dixième de secondes).

Le système en train de tourner est utilisé en développement (en C, C++, Rust, ou Go, avec un compilateur comme GCC)

Le fichier objet produit par le compilateur est, à certains instants, incomplet et incorrect. S'il était sauvegardé dans cet état partiel, il n'est pas utilisable (mais induirait en erreur un utilitaire comme GNU make). Le sauvegarder est donc erroné. Un gros fichier executable ELF en cours de génération par GNU binutils (songez aux contributeurs de Mozilla ou de GCC)

Dans des cas de métaprogrammation (utilisation de générateur de code C ou C++ comme GNU bison ou maison -comme RefPerSys- ou de GNU lightning)

De même, les sauvegardes automatiques et périodiques possibles avec GNU emacs ou d'autres éditeurs (ou logiciels comme LibreOffice) ne sont pas sûres.

La sortie d'un indenteur comme GNU indent n'est ni correcte, ni complète si on la sauvegarde pendant le processus d'indentation.

Un fichier indexé, par exemple GDBM ou Redis, n'est pas (toujours) correct si on le sauvegarde durant son exploitation ou mise à jour.

Une base de donnée MySQL ou PostGreSQL n'est pas correcte ou sûrement réutilisable si on tente de réutiliser les fichiers pendant que le SGBD met à jour cette base.

Un fichier de log n'est pas correct ou exploitable si le serveur (Apache-HTTPD ou Lighttpd par exemple)

Et j'imagine qu'un gros fichier de tableur Gnumeric ou Libreoffice n'est pas correct si le tableur est en train de l'écrire...

Un gros fichier en train d'être compressé par GNU gzip ou bzip2 n'est pas correct durant la compression.

Une video (ou une grosse photo) en train d'être manipulée (par GIMP par exemple) n'est pas stable durant son écriture! De même pour un gros dessin vectoriel (au format SVG) avec InkScape.

Mon point de vue est donc qu'il faut sauvegarder un système peu actif, et pour les données importantes, les sauvegarder consciemment et explicitement, quand on est sûr que l'original est stable et n'est pas en train d'être traité ou modifié par un processus.

En conclusion: ne faites pas trop confiance aux sauvegardes automatiques. Pour des données importantes, pensez à utiliser un versionneur comme git.

Librement

-- 
Basile Starynkevitch                  <basile@starynkevitch.net>
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/ & refpersys.org


Reply to: