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
Posté par Mouns . En réponse au journal Migration foirée. Évalué à 5.
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.