J'ai un gros fichier (une image truecrypt) que je trimballe sur une clef USB. Quand je reste longtemps sur un poste, je fais une copie sur le disque local pour profiter de meilleure performance et éviter de faire trop d'écritures sur ma clef.
Pour synchroniser le fichier sur le disque local et le fichier sur la clef, j'utilise rsync avec l'option --inplace.
Malheureusement c'est assez lent. Est-ce qu'il existe d'autres logiciels pour mettre à jour un fichier de façon différentielle plus rapide?
# diff
Posté par pralines . Évalué à 1. Dernière modification le 02 décembre 2011 à 22:42.
ce que je crois savoir (attention, à prendre avec des pincettes, surtout la conclusion) :
rsync c'est que c'est surtout intéressant pour les transferts réseau entre 2 machines
- la machine qui envoie les données, lit son fichier, calcul une somme de contrôle sur un bloc de données
- cette somme est envoyée à l'autre machine qui va lire le même bloc de données de son côté, calculer la somme de contrôle et la comparer avec celle qui a été reçue
- si les 2 sommes de contrôle sont différentes, ce bloc du fichier est donc différent, il est donc transféré, sinon on passe au bloc de données suivant
si tu fais un rsync entre 2 répertoires d'une même machine, tu es tout de même obligé de lire les 2 fichiers pour faire la comparaison avant d'écrire, ça n'est intéressant que si la lecture est nettement plus rapide que l'écriture (ou dans ton cas pour épargner tes cellules de flash)
mais je crois bien qu'avec un fichier chiffré, le moindre octet modifié fait que l'ensemble du fichier est différent, ce qui rend l'option de copie différentielle encore moins intéressante qu'une copie intégrale
quelqu'un pour confirmer, svp (pas taper, bon pas sur la tête) ?
Envoyé depuis mon Archlinux
[^] # Re: diff
Posté par pralines . Évalué à 1.
et la dernière remarque s'applique probablement aussi aux fichiers non chiffrés lorsqu'ils sont compressés (selon la méthode de compression), et si en plus le fichier compressé est stocké sur un volume chiffré...
mais encore une fois il ne s'agit pas d'affirmations solide et vérifiées, aussi je repasserai dans le coin pour voir les scores de mes 2 réponses (et surtout pour apprendre des choses) :-)
Envoyé depuis mon Archlinux
[^] # Re: diff
Posté par pralines . Évalué à 2.
je dois louper quelque chose, parce que je doute qu'une partition truecrypt soit entièrement ré-écrite au moindre changement de fichier, il doit y avoir un notion de bloc (cluster size ?)
j'ai eu beau parcourir la doc de truecrypt et quelques tutos, je n'ai pas trouvé confirmation
Envoyé depuis mon Archlinux
[^] # Re: diff
Posté par BFG . Évalué à 3. Dernière modification le 03 décembre 2011 à 00:31.
C'est presque ça. Pour étaler ma culture : c'est la machine qui reçoit qui calcule la somme de contrôle de ses blocs ({[0;N[, [N;2*N[, [2*N;3*N[, ...}), et transmet cette liste à la machine qui envoie. Celle qui envoie cherche des endroits (à chaque octet, et non pas uniquement aux octets {0, N, 2*N, ...}, ce qui permet de gérer efficacement le cas où un octet aurait été inséré au début d'un fichier) où l'on a N octets consécutifs qui donneraient une des sommes de contrôles trouvées. Ensuite, est transmis des instructions pouvant être une suite d'octets à écrire littéralement, ou bien l'écriture d'un des blocs qui existe déjà du côté récepteur. (voir Rsync#Algorithme)
Pour du chiffrement de fichiers qui ne changent pas aussi souvent qu'un disque ou de petits fichiers, vous avez raison. On s'arrange (avec CBC par exemple) pour qu'un bloc chiffré ne ressemble pas à un autre même si son texte clair est identique (exemple imagé).
En revanche, pour le chiffrement d'un disque, c'est impraticable : imaginez si changer le premier octet de votre disque de 500 Go vous forçait à réécrire 500 Go ! On a par contre une technique pour au moins empêcher que 2 blocs clairs identiques ne soient aussi identiques une fois chiffrés. Pour cela, on ajoute au chiffrement une donnée qui dépend de la position (pour être précis, on réinitialise CBC (ou autre mode) à chaque secteur disque, avec un vecteur d'initialisation qui dépend de la position) (Voir également en:Disk_encryption_theory)
Effectivement, rsync fait plus de travail qu'il n'est nécessaire (chercher à faire correspondre un bloc à une position à une autre position notamment, alors qu'il est impossible qu'un bloc chiffré se retrouve ailleurs identique). Si la lecture est vraiment plus rapide ou vraiment plus économique (sans doute pour une clef USB), alors un outil qui se contente de comparer les octets 1 à 1 (ou par secteurs) et réécrire uniquement ceux qui sont différents est ce qu'il faut. Sinon, "cp" (ou dd) est l'outil qu'il vous faut.
[^] # Re: diff
Posté par pralines . Évalué à 2. Dernière modification le 03 décembre 2011 à 10:04.
Merci 1000x BFG (intéressant comme pseudo, me rappelle bien des choses :-) pour ces précisions/corrections.
Comme je disais je sentais que le chiffrement d'une partition devait être différent de celui d'une fichier.
J'avais aussi lu que les utilisateurs de dropbox se plaignait que leurs rsync était devenu super long avec le chiffrement.
Existe-t-il une solution efficace pour faire des sauvegarde différentielle d'1 machine locale qu'on contrôle et en laquelle on a confiance (fichiers ou volumes chiffrés, local protégé, etc...), vers une machine hébergée chez un prestataire externe (internet) auquel on ne veut pas confier de secrets ?
Une solution que j'imagine (si il n'y a pas de postes sous Haiku/Windaube) :
Utiliser localement EncFS sur son serveur de fichier (GNU/Linux/BSD,OSX) et envoyer sur le serveur distant uniquement les fichiers modifiés depuis la dernière sauvegarde.
Si il y a des postes ne gérant pas EncFS, il faut travailler sur des fichiers en clair (ou stockés en truecrypt), puis avant de faire la sauvegarde chiffrer chaque fichier individuellement...
Une autre solution (peut-être) : calculer localement les différences entre les sauvegardes N et N-1, puis ne transmettre que le patch (qui sera, éventuellement, appliqué sur la sauvegarde N-1 distante) ?
Peut-être que je délire ou que j'essaie de résoudre un problème insoluble qu'en penses tu ?
Envoyé depuis mon Archlinux
[^] # Re: diff
Posté par BFG . Évalué à 2.
Tout à fait. Il existe même un mode inversé de encfs (--reverse) permettant, non pas de stocker les fichiers chiffrés, et avoir des fichiers en clairs "virtuels", mais de stocker les fichiers en clair, et d'avoir les fichiers chiffrés "virtuels" (pour ne payer le coût d'encfs qu'au moment de faire une sauvegarde distante, si l'on a confiance en la machine locale, par exemple si l'on chiffre déjà l'ensemble du disque).
Pour référence, ajoutons rdiff-backup comme alternative à rsync (car il ajoute la conservation des versions précédentes des fichiers, avec la possibilité de jeter ce qui est ancien (contrairement aux sauvegardes basées sur git))
Si l'on travaille avec des fichiers en clair (ou avec les fichiers en clair "virtuels"), on peut utiliser duplicity qui ne nécessite pas FUSE, mais je n'ai aucune idée de sa portabilité. Je ne l'ai jamais utilisé, mais voici comment il se décrit :
(Si vous parlez d'un seul fichier comme avec LUKS/TrueCrypt) Comme le fait rsync ? Pour référence, l'outil rdiff permet de faire manuellement les mêmes étapes que rsync (générer une signature du fichier N-1, générer un delta à partir du fichier N et de la signature N-1, puis appliquer le patch au fichier N-1, ce qui est dommage est qu'il n'a pas le --inplace de rsync).
# encfs
Posté par B16F4RV4RD1N . Évalué à 3.
si tes postes de travail sont tous sous linux, tu peux tester encfs qui chiffre chaque fichier individuellement
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: encfs
Posté par BFG . Évalué à 2.
Je ne peux qu'abonder dans ce sens, les chiffrements de type LUKS/TrueCrypt sont très mauvais s'il s'agit de les copier/synchroniser (certains utilisent ce type de chiffrement avec des logiciels comme DropBox, c'est profondément inefficace...).
À noter que EncFS ne fonctionne pas que sous Linux mais aussi FreeBSD et MacOSX (mais pas Haiku ni Windows).
[^] # Re: encfs
Posté par alice . Évalué à 3.
C'est malheureusement une clef pour travailler en environnement hostile.
Peut être que le plus simple est de faire un rsync sur le contenu plutôt que l'image disque Truecrypt...
[^] # Re: encfs
Posté par BFG . Évalué à 2.
Monter les 2 volumes TrueCrypt N-1 et N, puis faire un rsync entre les 2 points de montage ? Vous avez raison, c'est une meilleure idée, car dans le meilleur des cas (où aucune donnée n'a changé), seuls les parties contenant les métadonnées seront relues, et non pas les volumes entiers.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.