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