C'est avec douleur que je dois donner raison à celui ou celle qui a dit qu'il faut faire des backups réguliers et des dumps de ses bases de données. J'ajouterai simplement une petite chose apprise à mes dépens : Si on parle de faire des sauvegarde des données d'un serveur, ne pas oublier de rapatrier tout ça chez soi ou en tous cas loin de la source (d'un point de vue de proximité réseau).
Plantons le décor. La fin de contrat dans un data center approche. Il faut déménager les services ailleurs. On prend les devants et on cherche un autre, pas trop cher pour y mettre notre machine. C'est pas gagné :-/ Finalement on va squatter chez une bonne âme pour tout ce qui est dev et asso. Pour le pro (rien pour le moment) on y mettra les frais et on se payera un truc en temps voulu.
On prend tout notre temps. On devrait être prévenus quand ce sera le moment de faire le ménage et de rendre les clefs. On migre les sites, les services et tout et tout. Un simple
Driiiiiing ! Coup de téléphone doublé d'un mail : c'est demain que ça coupe. On n'a plus trop le temps de faire le rsync, d'autant qu'on n'a plus des masses d'espace sur la nouvelle machine. Faut trancher dans le vif ! Tiens les bases de données mysql de type InnoDB ne peuvent que grossir. On essaye de suivre la procédure pour limiter la casse décrite sur le blog de crazytoon [1]. Tout roule... sauf que mysql veut plus se lancer. Bon, pas trop grave pour le moment, vu que les données sont bien sagement rapatriées dans le /tmp de la nouvelle machine. Attention, vous venez de lire un élément important.
On galère, on cherche et au final on trouve. Peut-être un problème de quotas sur la nouvelle machine, peut-être aussi un problème d'options de mysql lors du mysql_install_db. Bref on peut maintenant importer les données. Sauf que les données, elles sont plus là :(( Un reboot intermédiaire a fait le ménage dans /tmp. Pas grave, on refait une copie du fichier depuis l'ancienne machine et ça devrait marcher. Sauf que ça marche pas : la machine est down. Murphy's law diront certains. Qu'on y croit ou pas, en tous cas, ça fait bien suer (je pensais à un autre mot, je l'avoue) !
Acte trois, téléphone de droite et de gauche pour accéder à la machine. "Pas moyen", elle est prise en otage car la société qui payait l'espace dans la baie ne payait plus, et ce depuis quelques mois ! Douche froide... et on est réduit à se demander : on paye et on récupère nos données, ou on cherche un backup en attendant que la situation se règle toute seule. Faute de moyen, ce sera la solution 2. Mais pour le coup, le backup le plus récent (en fait le seul que j'ai pu retrouver) datait de fin 2006.
Mine de rien, en subissant une migration foirée, on a inventé la machine à remonter le temps !
[1]http://crazytoon.com/2007/04/03/mysql-ibdata-files-do-not-sh(...)
Plantons le décor. La fin de contrat dans un data center approche. Il faut déménager les services ailleurs. On prend les devants et on cherche un autre, pas trop cher pour y mettre notre machine. C'est pas gagné :-/ Finalement on va squatter chez une bonne âme pour tout ce qui est dev et asso. Pour le pro (rien pour le moment) on y mettra les frais et on se payera un truc en temps voulu.
On prend tout notre temps. On devrait être prévenus quand ce sera le moment de faire le ménage et de rendre les clefs. On migre les sites, les services et tout et tout. Un simple
rsyncà la fin devrait suffire pour la synchro finale des machines.
Driiiiiing ! Coup de téléphone doublé d'un mail : c'est demain que ça coupe. On n'a plus trop le temps de faire le rsync, d'autant qu'on n'a plus des masses d'espace sur la nouvelle machine. Faut trancher dans le vif ! Tiens les bases de données mysql de type InnoDB ne peuvent que grossir. On essaye de suivre la procédure pour limiter la casse décrite sur le blog de crazytoon [1]. Tout roule... sauf que mysql veut plus se lancer. Bon, pas trop grave pour le moment, vu que les données sont bien sagement rapatriées dans le /tmp de la nouvelle machine. Attention, vous venez de lire un élément important.
On galère, on cherche et au final on trouve. Peut-être un problème de quotas sur la nouvelle machine, peut-être aussi un problème d'options de mysql lors du mysql_install_db. Bref on peut maintenant importer les données. Sauf que les données, elles sont plus là :(( Un reboot intermédiaire a fait le ménage dans /tmp. Pas grave, on refait une copie du fichier depuis l'ancienne machine et ça devrait marcher. Sauf que ça marche pas : la machine est down. Murphy's law diront certains. Qu'on y croit ou pas, en tous cas, ça fait bien suer (je pensais à un autre mot, je l'avoue) !
Acte trois, téléphone de droite et de gauche pour accéder à la machine. "Pas moyen", elle est prise en otage car la société qui payait l'espace dans la baie ne payait plus, et ce depuis quelques mois ! Douche froide... et on est réduit à se demander : on paye et on récupère nos données, ou on cherche un backup en attendant que la situation se règle toute seule. Faute de moyen, ce sera la solution 2. Mais pour le coup, le backup le plus récent (en fait le seul que j'ai pu retrouver) datait de fin 2006.
Mine de rien, en subissant une migration foirée, on a inventé la machine à remonter le temps !
[1]http://crazytoon.com/2007/04/03/mysql-ibdata-files-do-not-sh(...)
> Lire le journal (67 commentaires, moyenne: 3).
Vous avez demandé le commentaire #920152.
Run by 
Cette page a été générée par Templeet en 0.0863s (dont 0.0076 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
De la nécessité de tester les sauvegardes
Ça l'air idiot comme ça mais il vaut mieux prévoir une procédure mensuelle de restauration d'un des systèmes gérés et de ses données (sur un serveur de secours, évidemment) afin de s'assurer que, le jour J, la restauration ne posera pas de problèmes majeures (genre, s'apercevoir que les données les plus « fraîches » datent de deux ans...).
Par contre, ton expérience semble surtout démontrer la négligence des personnes chargées des contrats d'hébergement : prévenir la veille, c'est beaucoup trop tard. Évidemment, si la date de fin de contrat était précisément le lendemain, c'est que vous aviez pris trop de temps pour vous préparer.
Par contre, ça n'explique pas pourquoi le loyer n'était plus payé depuis des mois. Parfois, l'informatique n'est pas qu'une question de technologies et il faut que tout le monde coopère et partage les informations (oui, un admin a besoin de savoir quand un contrat d'hébergement se termine, si, si).
[^]Re: De la nécessité de tester les sauvegardes
de la nécessité de ne pas compresser les sauvegarde ... comme ca, l'intégrité du support ne nuit que très faiblement à la qualité de la sauvegarde.
1bit de modifié sur un tgz, et c'est le tgz qui est bon pour la poubelle.
1bit sur une image FS, ca se récupère plus facilement.
donc ne jamais faire des fichiers tar et encore moins de tar.gz pour de la sauvegarde !
le tar ne doit être utilisé que comme outil qui à l'origine archivait sur bande ... donc avec un lecteur de bande.
sur un disque, rsync c'est très bien ( par contre, je ne sais pas si il existe une FS avec systeme de correction d'erreur pour l'intégrité des données - genre backupFS et non e2fs over RAID )
Au pire, tu prend un MACOS X léopard avec time-machine + time capsule ( pas de truc équivalent au niveau backup en libre ).
http://www.apple.com/fr/timecapsule/
[^]Re: De la nécessité de tester les sauvegardes
donc ne jamais faire des fichiers tar et encore moins de tar.gz pour de la sauvegarde !
le tar ne doit être utilisé que comme outil qui à l'origine archivait sur bande ... donc avec un lecteur de bande.
Pourquoi on utilise ça partout sur le net pour diffuser sur le net
des sources ?
You got the money, I got the soul.
[^]Re: De la nécessité de tester les sauvegardes
La chose qui peut se faire en plus d'une archive tar.gz, c'est un test de l'archive en question après sa création et le calcul d'un somme de contrôle.
À partir de là, on peut vérifier la validité du fichier et éviter des problèmes de copie ou de support non fiable.
Bien évidemment, ce n'est pas forcément adaptable à tous les cas (en particulier pour les gros jeux de données où ces opérations vont prendre du temps).
[^]Re: De la nécessité de tester les sauvegardes
Faire une sauvegarde avec quoi alors ?
zip ?
rar ?
cat * > mongrosfichier ?
[^]Re: De la nécessité de tester les sauvegardes
Non ce qu'il voulait dire, ce n'est pas que ça ne marche pas.
Le problème des archives compressées (zip, tar.gz, tar.bz2, rar, ce que vous voulez) c'est que on élimine la redondance d'informations (au sens large), d'où la compression. Mais de ce fait c'est beaucoup plus sensible aux altérations.
Par exemple, mon super format de compression :
"aaaabccddd" est compressé en "4abcc3d"
Si dans la chaine originale je modifie le 2ème caractère "a" -> "e" on a "aeaabccddd"
Si c'est dans la chaine compressée, on obtient "4ebcc3d" et à la décompression, patatatra, ça empire, on obtient "eeeebccddd".
Dans un cas : 1 erreur, dans le second : 4 erreurs.
Bon mon exemple est bidon mais l'idée est là.
Le cas des archives tar (sans gzip, bzip2) est un peu différent, parce que ce n'est jamais que la concaténation des données telles quel avec quelques métadatas. Donc c'est assez robuste.
En gros si on stocke les fichiers tels quels sur un filesystem ailleurs, ce sera plus robuste aux altérations que l'archive .tar.gz/rar/... correspondante.
Par contre on perd beaucoup de place.
Donc sur le net on fait des tar.gz parce que ce qui importe c'est la bande passante alors que pour des sauvegardes, en générale c'est les données qui sont importantes.
[^]Re: De la nécessité de tester les sauvegardes
Oui mais il a d'abord jeter l'opprobe sur tar, outil qui était (et est encore) utilisé pour gérer des archives notamment sur des lecteurs de bandes mais il n'y a que GNU tar pour permettre de compresser en même temps qu'on créé l'archive en question.
Si l'on suit l'importance des données, tar n'est pas à remettre en cause.
Et il y encore beaucoup de lecteurs de bandes magnétiques utilisées pour la sauvegarde, les disques dur ne les ont pas encore remplacés.
[^]Re: De la nécessité de tester les sauvegardes
je me cite moi meme :
le tar ne doit être utilisé que comme outil qui à l'origine archivait sur bande ... donc avec un lecteur de bande.
je ne jette pas l'oprobe sur tar !
nous parlons de sauvegarde, et tar rend service sur un lecteur de bande pas sur un disque !
le format tar.gz est un détournement de l'usage originel de tar ( un peu comme cliquer sur "démarrer" pour éteindre son windows :p )
un des critères les plus important d'une sauvegarde est la fiabilité d'une information.
je parle de cela.
Compresser une information dans le but de sauvegarde est pire que ne pas faire de sauvegarde.
Pourquoi je parle de cela ? parce que les problèmes nécessitant une sauvegarde sont :
- risque de corruption des données
- risque de perte des données
- risque d'indisponibilité partielle ou totale des données ( hard cassé )
Donc une sauvegarde doit garantir :
- une étanchéité vis à vis du support = support un peu défaillant, données lisibles
- une étanchéité vis à vis du format = format plus ou moins corrompu, format quand meme exploitable
- une étanchéité vis à vis des outils = le soft de restitution est out, il faut pouvoir retablir
- une étanchéité vis à vis de l'accessibilité = il faut pouvoir vérifier rapidement l'intégrité du support, du format, des outils de restitution
Donc :
A. il ne faut pas stocker dans un format compressé.
L'exemple du RLE était parfait pour comprendre.
sur un algorithme de la famille des LZ qui est à dictionnaire dynamique ( cas de compress, zip, gzip & co ), une erreur de reconstitution du dictionnaire produit un arret de l'algorithme donc tout est perdu après l'erreur
B. il faut un format le plus proche du format natif
le mieux pour sauvegarder des données SQL est un fichier texte contenant des INSERT.
le mieux pour un fichier HTML est HTML.
le mieux pour un binaire, c'est le binaire lui meme et ses sources.
un binarydump des tables ou une copie à chaud des tables, introduit un risque d'erreur indetectabe. on peut détecter une erreur de charset ( en UTF16 ou UTF32 ) d'un fichier texte, pas une erreur dans un binaire sans un parser pour chaque format.
C. il faut que le support ( logique ou/et physique ) offre une redondance des données
souvenir souvenir, les lignes séries, les bits de terminaison, les sommes de controles & co ...
on envoyait plus d'info sur une liaison de type série longue distance, ce qui induisait un debit effectif largement inférieur au débit réel : pour éviter de rejouer l'ensemble d'une communication, il était préférable de pouvoir détecter les séquences à problèmes et les corriger automatiquement et d'envoyer un signal d'erreur pour qu'il rejoue la fenetre de séquence.
Au niveau du support logique et physique, il faut la même chose :
- des sommes de contrôles non pas sur un tar ou une iso, mais sur chaque fichier de l'iso ou du tar
- pouvoir automatiser les corrections les plus fréquentes ( plusieurs fois 1 bits unique dans un bloc signé )
D. l'outil doit s'assurer qu'il sauvegarde bien ce qu'il doit sauvegader
Sur une sauvegarde, il faut que le support physique puisse offrir une redondance exploitable mais il faut aussi que l'outil de sauvegarde ( le cas de rsync me semble t il moyennant le mode batch et checksum ) puisse garantir que ce qui a été copié est bien ce qui devait être copié ( comparaison post copie ).
Sur une FS subissant beaucoup d'ecriture, un LVM snapshot sera nécessaire au préalable après s'être assuré du lock de la FS pour sauvegarder un état sans écriture en cours.
Conclusion :
un tar + gz + ftp ( ou autre ) n'offre pas la même garantie au niveau sauvegarde que ce dont je parle.
Si c'est pour sauvegarder ses photos de voyage, un tgz sur cd gravé est parfait.
Si c'est des données d'une entreprise, il faut s'assurer que ce qui est fait est bien fait, et il faut donc vérifier/Tester ( et je rejoins celui à qui je répondais ).
mais vérifier 1 sauvegarde, ne fait que vérifier 1 sauvegarde au moment de la vérification, cela n'offre aucune garantie qu'au bout de 1 semaine les données sont toujours exploitable ... c'est un pari sur une croyance pas un fait garanti.
La sauvegarde ne s'improvise pas ... et les bons outils de sauvegardes libres sont très rare, et ceux qui sont simple à mettre en oeuvre, sont inexistant.
Donc je maintiens, si la time machine d'apple n'est pas parfaite, elle doit servir de modèle.
[^]Re: De la nécessité de tester les sauvegardes
> La sauvegarde ne s'improvise pas ...
Oui.
Mais j'ai l'impression que tu es limite dans un délire. Tu peux faire des checksum, mais à dans ce cas de parano, il faut aussi auditer les outils qui font les dumps, etc...
Le tar.gz c'est bien. Ce n'est pas parfait, mais c'est bien. S'il manque un 1 bit, gzip et tar savent gérer ça. Mais OK, tu perds plus d'un 1 bit.
Notons que tous les archivages vidéo sont en compressé... Sinon c'est impossible.
Autre avantage de tar, il stocke les informations du système de fichier. Comment tu fais pour sauvegarder les droit rwxrwxrwx sur Windows ? Comment tu fais pour sauvegarder les propriétaires si tu n'as accès qu'à un compte sur le serveur de backup ? Comment tu fais si tu as les fichiers TOTO et toto et le serveur de backup est Windows ?
On ne devrait pas parler d'un backup mais de plusieurs backups. Car il faut toujours au moins deux backups (sur deux bécanes différentes ou qu'une bécane mais archiver les bandes dans des lieux différents).
Enfin il faut mettre dans le contexte. Pour un serveur, je fais des sauvegardes en cpiio.gz, dump de base de données, etc. Je gardes sur 2 mois (10 backups fait la nuit et 10 backups fait le week). Mais surtout je m'impose de faire un test de restauration tous les mois ! Si je n'arrive pas à restaurer mon serveur rapidement, alors j'ai un problème dans mes procédures de backup/restauration. Que j'utilise du cpio.gz est accessaire. Évidemment, c'est pour mon cas particulier et d'autres cas demande d'autres procédures.
[^]Re: De la nécessité de tester les sauvegardes
S'il manque un 1 bit, gzip et tar savent gérer ça.
http://en.wikipedia.org/wiki/Gzip ( http://www.ietf.org/rfc/rfc1952.txt pour le format ) algo http://en.wikipedia.org/wiki/DEFLATE ( mix de LZ77 et Huffman ) connu sous la RFC 1951 ( http://www.ietf.org/rfc/rfc1951.txt ).
donc en fait tu stockes dans un gzip, ton arbre de token via un arbre de huffman ( = le token le plus fréquent sera le plus court ), puis tes données sous forme de liste de token.
Donc, une erreur dans l'arbre de token, sur un token long est peu génant, une erreur sur un token court est grave.
Apres une erreur dans la liste des tokens est génante ... tu peux imaginer des sommes de controle sur ton block mais bof.
Du coté de tar, tu as l'option -t qui permet de verifier l'intégrité d'un tar. en cas de problème, le tar considère que tout le reste est foiré ... sauf bidouille assez infect dans le format tar, cela n'est pas top.
Donc sur ton tar.gz, il suffit d'une petite erreur ( facile à obtenir ), pour chier ton archive.
je n'appelle pas cela un format de sauvegarde, c'est bien pour un truc qui est "in the cloud" ( pour faire dans la hype actuelle - sinon pour faire dans le revival du film "antitrust", "la solution est dans la bande passante !" ).
un exemple avec tes photos argentiques :
tu entasses et presse au sers-join les negatifs et les photos ou tu les séparent proprement en isolant chacun de manière plus ou moins hermetique de l'humidité, de la lumière, de la poussière ?
dans un cas, ca prend moins de place et au moindre probleme tout par à la poubelle ... dans l'ordre, ca prend beaucoup plus de place mais au moins tu les conserve pendant très longtemps et si un negatif ou une photo à un probleme, c'est juste un petit probleme dans une immensité bien conservé.
[^]Re: De la nécessité de tester les sauvegardes
> Donc sur ton tar.gz, il suffit d'une petite erreur ( facile à obtenir ), pour chier ton archive.
Mais c'est comme ça pour tout !
T'as une merde dans le dump de base de donnée, et le dump peut être foiré. Et les dumps en pure SQL tu ne peux pas toujours les faires (sinon ça prend des prombe). T'as une merde dans l'outil qui fait le dump, et le dump est foiré. T'as un merde dans le SGBD, et le dump est foiré. T'as une merde dans le FS, et tous tes backups sont foireux, etc.
Mais pour une raison que j'ignore, tu fais une fixation sur tar et gzip.
Tu m'expliques ?
Je ne fais pas une fixation sur tar ou pg_dump ou autre. Je fais une fixation sur l'ensemble de la chaine. D'où l'importance de faire des restaures réguliers pour tester l'ensemble.
Un exemple de "petit problème". .Tes backups et dumps de base de données roulent nickel. Un l'admin fait une mise à jour de la base de donnée. Manque de chance, pour les dumps t'utilise une option qui n'est plus supportée. Bref, tes backups sont nazes.
Ou avec la nouvelle version de la base donnée, l'admin de la base de donnée utilise de nouvelle fonctionnalité qui sont sauvegardées que si tu utilises la nouvelle option "-z" de l'outils de dump de base. Mais comme cette option n'est pas activée...
Bref, ça peut merder à 50 endroits, alors pourquoi cette fixation sur tar ?
Et rsync peut aussi merder (ça m'est déjà arrivé).
[^]Re: De la nécessité de tester les sauvegardes
> Et rsync peut aussi merder (ça m'est déjà arrivé).
Et j'ai aussi eu cpio qui merdait (et pas pour faire une archive, mais un cpio -p). Les droit et propriétaire des fichiers étaient perdus (ce qui est très casse couille).
[^]Re: De la nécessité de tester les sauvegardes
pourquoi cette fixation sur tar ?
JE n'ai aucun problème particulier avec tar ou gzip :D
JE les utilise là où JE considère qu'ils satisfassent mes attentes.
par contre, JE expose MON opinion en disant "tar et gzip c'est bien pour certaines choses mais JE ne l'utilise pas au niveau backup disk pour diverses raisons"
Et quand une personne m'interpelle sur le pourquoi, j'expose plus précisement MES raison qui ME permettent de justifier MON opinion.
par contre TU as un problème de lecture du francais, TU sembles avoir une lecture orientée de MON propos.
Maintenant, si tu as des arguments au niveau algorithmique justifiant le fait que gzip est génial pour du backup ( je te rappelle que j'ai dit que tar etait bien pour les backup sur bande ), expose les.
Personnellement, JE t'ai sorti plein d'infos avec des sources tel que les RFC, les descriptions des algorithmes qui permettent de se faire une opinion argumenté ... TOI, TU n'as exposé que TON sentiment, aucun argument laissant entendre une preuve avec une démonstration.
"RFC" contre "croyance benoite" ... ben ca dépend si tu es croyant parce qu'il faut croire ou tu crois à ce que tu peux expliquer.
Donc ton exemple de on upgrade un SGBD ... je te pose une question simple :
Pour quel raison faire un upgrade d'une version majeur d'un SGBD alors que tu as une prod qui fonctionne ( hors faille de sécurité ) ?
TU N'AS AUCUNE RAISON !
ON NE COUPE PAS UN SERVICE QUI FONCTIONNE !
TU NE COUPE QUE POUR DES PROBLEMES DE SECURITE OU D'INTEGRITE DES DONNEES !
en fait, je pense qu'elle est là la différence entre MA vision et TA vision :
pour moi, si il y a une mise à jour du sgbd, il y a test, recette et donc vérification de la compatibilité de tous le systeme d'information
pour toi, tu fais le jacgeek, tu fais du tuning de soft plutot que que voiture, mais c'est pareil, plus le numero de version est gros et plus tu es content.
tu fais ta prod en unstable, tu as 300 gentoo différentes ( compilé chacune à la mano avec amour ).
Moi, j'ai une vie, je veux que mon SI soit stable, je m'en fous d'avoir une truc top moumoute, je veux pouvoir dormir la nuit, pouvoir aller au ciné ... en fait, ne pas avoir à dire "je suis informaticien, le boulot m'appelle" chaque fois que je sors diner avec ma femme ... donc, validation, vérification, controle, redondance, redondance, duplication.
Concretement, un tar étendu via un BASE64+controle sur les 4x2bits vacants , ca me semble largement plus sur que le meme tar suivi d'un gzip
Ton gzip prend peu de place à coté de mon bloat ...
maintenant, essaie de corrompre la totalité de mon bloat autrement qu'en passant au pilon le support :p
Par contre, prend une image, gzip là, change 1 octet quelque part, et ungzip apres ...
je pense que tu vois la différence ... sauf si tu n'as rien compris au seul interêt de la compression de données.
[^]Re: De la nécessité de tester les sauvegardes
> Maintenant, si tu as des arguments au niveau algorithmique justifiant le fait que gzip est génial pour du backup
Je n'ai pas dit ça.
Je n'ai pas dit que X ou Y est génial.
En passant, je n'utilise pas tar.
> Personnellement, JE t'ai sorti plein d'infos avec des sources tel que les RFC, les descriptions des algorithmes qui permettent de se faire une opinion argumenté ...
Ton raisonnement est : si ça va de travers, ben ça va de travers. Et si tu utilises tar ou gzip, ça ira encore plus de travers.
ON EST D'ACCORD !
Mais si mon fichier tar ou gzip est pourri, ben je le sais. Et je récupère un sauvegarde précédante. Je ne vais pas prendre le risque de vaguement restaurer un truc. Et toi ? Et restaure vaguement des trucs ?
Si un backup a un problème, ben il a un problème. Et même si ce n'est qu'un fichier, va savoiir quelles sont répercutions.
Oui, si un secteur de disque dur ou bande magnétique déconne ben t'aura plus de problème avec tar/gzip que si tu utilises rien. C'est évident, pas besoin de RFC pour savoir ça.
Mais tu (ou je) peux aussi dire, arguments (ou RFC) à l'appuis, qu'un système de fichier c'est dangereux pour les backups car si il déconne t'es dans la merde et qu'il vaut mieux et "tar .... > /dev/sdm" qu'un "cp -r ... [destination]". Que ODF qui groupe des fichiers dans une archive c'est plus dangereux que si c'est non compressé et dispersé sur plusieurs fichiers. Qu'un système de fichier + journalisation + lvm + raid c'est HYPER dangereux car il suffit qu'un seul déconne pour être dans une merde noir. A chaque fois que tu ajoutes un truc, il y a un risque.
Mais si tar (ou cpio, ou rsync ou gzip ou...) marche, ben il marche (et ce n'est pas de la croyance, c'est un constat). Si ton système raid/lwn/ext3/pg_dump marche, ben il marche. Si les archives compressées de ODF marchent, ben elle marchent. Au fais, tu décompresses systématiquement tes fichiers ODF ?
J'imagine que tu dois rêver d'un SDB qui mets chaque enregistrement et chaque champs dans un fichier séparé... Pour le "au cas où" (comme pour le "au cas où un bit de ton gzip ....")
Tu peux aussi éviter les disques durs, les bandes magnétiques, etc car ils finissent tous par planter et privilégier la pierre gravée tant que tu y es.
Il y a toujours un risque. Mais il doit être évalué.
Es-ce que utiliser tar un gros risque ?
Je ne crois pas. Du moins si l'ensemble sauvegarde/restauration est sérieusement testé ET plusieurs sauvegardes archivées (rotation).
Si je peux éviter tar, ben j'évite tar. Si tar me rend service, ben je l'utilise.
J'utilise, et ça va être un standal pour toi, le format "custom" de pg_dump (PosgreSQL) qui par défaut est compressé. Et je ne suis VRAIMENT pas le seul. Ça présente plein d'avantage par rapport au dump SQL "plain". Es-ce un risque ? Oui. Mais ridicule. Et ça marche (comme tes serveurs en prod).
> "RFC" contre "croyance benoite"
Lis ce que j'ai écris.
Si j'avais une "croyance benoite" tu crois que je vérifierais mes backup et procédures de restauration tous les mois ?
> "RFC"
Ben lit la doc sur ext3, et ext3 comme tar, s'il y a un problème de disque (secteur ou autres) ou qu'un problème d'OS, ou la mémoire vive qui déconne, ben tu n'es pas à l'abris de perdre des donnés (un secteur, un cluster, un group ou 1000 fois pire). C'est hypra clair. Pourtout tu utilises bien des systèmes de fichier ?
Tar est une sorte de un système de fichier, ça a les mêmes problèmes.
> Pour quel raison faire un upgrade d'une version majeur d'un SGBD alors que tu as une prod qui fonctionne ( hors faille de sécurité ) ?
Car tu ne sauvegardes pas les serveurs de développement, pré-production ?
C'est les développeurs qui vont être heureux d'entendre ça...
Puis le "ça marche je n'y touche pas" il est vrai pour une période donnée. Sinon les admins seraient au chômage.
Il y a plein de serveur en production qui doivent évoluer. Et parfois tu ne peux pas avoir la base de production complète en test (trop cher) et faire des tests exhautif.
> ON NE COUPE PAS UN SERVICE QUI FONCTIONNE !
BEN MES BACKUPS GZIP, PG_DUMP, ETC MARCHENT !
> pour moi, si il y a une mise à jour du sgbd, il y a test, recette et donc vérification de la compatibilité de tous le systeme d'information pour toi, tu fais le jacgeek, tu fais du tuning de soft plutot que que voiture, mais c'est pareil, plus le numero de version est gros et plus tu es content.
Puisque tu le dis...
T'as trouvé ça dans une RFC ?
> je m'en fous d'avoir une truc top moumoute
T'es seulement obsédé à avoir un truc théoriquement sans point faible. Mais il ne l'ai pas et ne le sera jamais (idem pour moi).
Je te laisse dans ta croyance absolue de ton système parfait.
> Par contre, prend une image, gzip là, change 1 octet quelque part, et ungzip apres ...
Change un secteur d'un système de fichier au hazard. Tu m'en diras des nouvelles. Si t'as un peu de chance, tu tombes sur un secteur non utilisé. Si t'as moins de chance, ça va te prendre des semaines pour constater les dégâts, remonter le problème et récupérer un backup vieux de 2 semaines.
Mais dis moi, si pour toi c'est dangeureux d'utiliser tar ou gzip, pourquoi tu utilises les systèmes fichiers ?
[^]Re: De la nécessité d'aller se boire une bière entre geeks
mais vous êtes chiants ! allez régler ça autour d'une bière ! arf... le pire c'est qu'ils sont d'accord c'pas possible ça...
"L'informatique, c'est comme le sexe : c'est mieux quand c'est gratuit" [Linus]
[^]Re: De la nécessité de tester les sauvegardes
* smack * ( bruit d'un bisou amical )
debugfs est mon meilleur ami depuis decembre 95 :D
tu confond un systeme parfait avec un système dont on sait qu'il peut tomber en panne.
Si tu as de la chance, cela ne tombe pas en panne.
Si tu n'en as pas, en cas de panne, tu peux identifier ce qui merde.
Entre restaurer un fichier client intégral datant de J-14 ou la quasi intégralité du fichier qui a J-7 et juste ce qui manque dans le fichier J-14 ... il y a une différence ;)
Détail, l'intégrité des données est importante, et cela se gere aussi du coté backup ... donc, il faut pouvoir identifier les informations manquantes pour agir en conséquence.
maintenant, un secteur complet d'une FS qui est corrompu, fsck en mode -n ( le -y etant le piège à con ) pour identifier les problèmes, debugfs pour reconstruire ... c'est plus mieux quand meme qu'un tgz intégralement bon pour la poubelle.
je me repete :
tar n'est pas un probleme, c'est juste un format d'archivage linéaire/séquentiel ... donc parfait pour une lecteur de bande, inutile pour un disque avec des accès aléatoire.
il faut d'autres modèles d'archivage sur disque qu'un archivage de type bande ... surtout pour de la sauvegarde incrémental ( et le mode batch de rsync est cool pour déterminer le delta à archiver et le delta qui a été archivé ).
maintenant, gzip/compress/rar/zip/uc2/bzip/... sont des algorithmes de compression de données ... le but de la compression n'est pas de faire des archives, mais de faire que l'information prenne le moins de place possible en éliminant la redondance, les bits inutiles.
Donc plus ton taux de compression est important plus chaque bit du fichier compressé comporte de l'information. Si tu introduit une corruption dans un fichier compressé, cette corruption n'a pas un impact local, mais à un impact global sur toute le document.
Si tu corromps un tar non compressé, tu peux détecter la corruption et essayer de passer outre ( histoire de vanter tar tout court ) ... même si ce n'est pas facile à faire, c'est faisable.
par contre, sur ton tar.gz, si tu le corromps, tout est bon pour la poubelle.
maintenant, un systeme de fichier offre des outils comme fsck et un systeme d'accès non linéaire ... alors que pour sortir un fichier d'une grosse archive tar, il faut :
init - aller au début
1 - lire les entete
2 - si le nom correspond on extrait le fichier et on s'arrete
3 - sinon deplacer la tete de la taille en octet déclaré dans les entetes puis aller à l'etape 1
donc un tar de 1Go de plein de petits fichiers, c'est une plaie au niveau acces ... alors qu'une filesystem de 1Go avec les memes petits fichiers, offre un moyen de trouver rapidement le fichier que l'on cherche.
maintenant, rien ne t'empeche de compresser ton image disque, mais cela sera comme un tar.gz ;)
Quand tu rétablis une sauvegarde, tu ne rétabli pas nécessairement toute cette sauvegarde ... par exemple tu n'as besoin que de rétablir 2 fichiers et non le reste.
l'image disque offre donc un moyen d'acces rapide quand on stocke ses sauvegardes sur des disques ... sur un lecteur de bande, tar est largement plus efficace.
Est ce plus clair ?
[^]Re: De la nécessité de tester les sauvegardes
> Est ce plus clair ?
Mais c'est clair depuis le début.
M'enfin tu ne peux (ou ne devrais pas) sous-entendre qu'un tar (gzip en plus ou pas) n'est pas un backup. C'est un backup avec ses faibles comme tous les backups.
Tu peux le juger moins fiable, c'est tout à fait recevable et compréhensible.
J'évite les archives et la compression seulement car c'est moins pratique (ça ne se prête pas à un rsync par exemple). Pas car c'est (forcément) moins fiable.
Si tu fais un mirroir de kernel.org, tu n'as pratiquement que des fichiers compressés, mais c'est un backups. Évidemment si tu mets le tout dans un gros tar de 10 To, ce n'est pas malin.
[^]Re: De la nécessité de tester les sauvegardes
GRRR tar n'est pas moins fiable ou plus fiable ... tar est bien pour un lecteur de bande.
tu fais pas 3 000 kilometres de désert en smart, tu fais pas tous les jours tes 10 blocs d'immeuble à paris avec un 4x4 :
- un 4x4 c'est adapté au désert
- une smart c'est adapté à la ville
tu ne stockes pas une FS sur une bande, c'est contre performant au niveau des IO.
de la même manière utilisé un tar plutôt qu'une image disque sur un disque est contre performant au niveau des IO.
tar est linéaire, une fs est un arbre ... et si tu prend une fs pensé de manière judicieuse, tu te garantie une profondeur d'au plus log(total fichier)/log(densité)
et cette profondeur représente le nombre maximum d'accès disque pour trouver un fichier.
donc si tu veux une densité de 256, pour une profondeur de 4, tu gères 4 milliards de fichiers :)
donc tu peux identifier un fichier parmis 4 000 000 000 en seulement 4 acces disques ! sur un tar, au mieux tu auras 1 acces disque au pire tu en auras 4 000 000 000 :)
donc, sur une bande linéraire ou tu ne peux que dérouler ou enrouler, tar est parfait, et il te faudra dérouler les 4 000 000 000 de fichiers si celui que tu cherches est tout à la fin de la bande.
sur un disque, tar est contre productif. ca ne veut pas dire que c'est un mauvais outil, non, tar est un bon outil ... mais il faut l'utiliser là ou c'est utile :)
maintenant, c'est une question de liberté individuelle, comme pour les 4x4 en ville : certaines aiment les 4x4 en ville d'autre trouvent cela absurde ;)
[^]Re: De la nécessité de tester les sauvegardes
Donc ton exemple de on upgrade un SGBD ... je te pose une question simple :
Pour quel raison faire un upgrade d'une version majeur d'un SGBD alors que tu as une prod qui fonctionne ( hors faille de sécurité ) ?
TU N'AS AUCUNE RAISON !
ON NE COUPE PAS UN SERVICE QUI FONCTIONNE !
TU NE COUPE QUE POUR DES PROBLEMES DE SECURITE OU D'INTEGRITE DES DONNEES !
Au hasard : l'éditeur du logiciel (propriétaire) que tu utilise ne supporte plus la version qui tourne sur ton SI, et tu dois upgrader car il y a un bug emmerdant parce que ton applicatif a évolué un chouia et fait apparaitre ce bug.
[^]Re: De la nécessité de tester les sauvegardes
Si j'avais ce genre de choses à faire (bon mes fichiers importants doivent tenir dans 30Mo donc pas besoin de comprimer), je ferais comme les messants pirates sur les newsgroups:
Couper l'archive en plusieurs morceaux et utiliser par2, qui permet de récuperer des morceaux à partir de ceux existant grace à l'algorithme de Reed-Salamon, qui utilise quelques blocs de correction (comme du raid5 grosso modo mais en beaucoup plus souple en % de données utilisées pour les codes de correction) ( http://fr.wikipedia.org/wiki/Code_de_Reed-Solomon ), qui est franchement efficace à mon avis (et permet de garder une restauration automatique et avec, je penses plus de chances de réussites)
[^]Re: De la nécessité de tester les sauvegardes
Et tu postes régulièrement tes fichiers sur fr.comp.sauvegardes.perso, histoire d'être sûr de pouvoir les y retrouver le jour J ? ;-)