> 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é de tester les sauvegardes
Posté par IsNotGood . En réponse au journal Migration foirée. Évalué à 2.
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 ?