Les sauvegardes ultimes distantes en milieu hostile

Version 1.

Je fais mes sauvegardes via rsync over ssh sur un serveur de confiance.

Version 2.

Un espace de stockage distant dit de confiance a un cout.
Souvent il faut payer pour avoir un serveur dédié.
Par contre les espace de stockages sans garantie de fiabilité
et surtout sans garantie de confiance, sont bien plus facile a trouver.

On peut détourner des comptes emails gratuit offrant un espace de quelque Go (exemple: gmail.com)
Ou des ftp gratuit (exemple: free.fr)

Mais sauvegarder des données sensible la dessus serait suicidaire.
Il faut donc les chiffrer.
Notre copain gpg est la!

Je fais donc mes sauvegardes de fichiers crypté avec gpg et transféré via rsync over ssh (ou autre).

Version 3.

Dans la branche de solution de transfert, partons du principe que l'on a toujours la possibilité d'utiliser rsync over ssh.
Le problème de la version 2, est que l'on sauvegarde des version chiffré des données.
Il est fortement probable que même si les données ne changent pas, leur version chiffrées changent.
Donc on se retrouve a sauvegarder quasiment tout, a chaque fois.
On perd donc en temps/bande passante.
Le problème est donc de déterminer les éléments a sauvegarder de ceux inchangés.
Solution, il suffit de constituer un catalogue des sommes de controle (md5sum par exemple) de chaque éléments.
a coté de chaque fichier .encrypted on aura un .md5sum (de son original non chiffré).

Il suffit donc de comparer les sommes de control.

Version 4.
(a reflechir)

Le problème de la version 3 apparait lors de la manipulation des gros fichiers.
Imaginons le cas d'un gros fichier de log. Une ligne est ajouté dans ce gros
fichier de logs, sa somme de controle change, il faut donc sauvegardé ce fichier.
La version 3 transferait tout le fichier, grosse perte de temps/bande passante.
Il serait difficile de transferer les diffs (encore plus dur pour reconstruire le fichier apres une multitude de modification...)
Je ne choisi pas cette voix (car j'ai déjà les version suivante en tete).
Note: il faudra étudier la faisabilité des diff ;-)

Je choisi de faire des segments, découper les gros fichier en plusieurs morceau et appliquer exactement la meme chose qu'en version 3.
On peux aussi envisager de faire varier la taille des segments et/ou de rajouter des données aléatoires de padding pour tromper sur la quantité de données utiles qu'il
contient.

Version 5.

Je ne souhaite pas que quelqu'un ayant accès a mes sauvegardes puisse comprendre quel partie a de la valeur.
Si sur l'espace de sauvegarde les segments chiffrés sont rangé dans une arborescence identique a celui du serveur d'origine.
Une personne malvaillante pourra facilement identifier ou sont placé mes clefs, ou certificats et tenter alors de cracker uniquement ces segments précis.

Il faut donc cacher l'arborescence des éléments sauvegardés.
L'idee est simple, chaque segment est nommé par un numero unique (meme principe que les inodes sur un FS), et le catalogue identifit leur chemin.

Version 6.
(a reflechir)

Le problème du catalogue.
Si le catalogue reste sur la machine d'origine, si l'on perd le disk et ses données, sans catalogue impossible de restaurer correctement l'archive.
Il faudrait penser a ce que dans chaque segment, soit indiqué sa ou ses position dans le filesystem.
mais on risque de tomber dans les cas ou on est face a un ensemble de segment plus ou moins recent et de ne plus savoir lequel il faut restaurer.
Note: le probleme n'a pas encore ete assez creusé.

Version 7.

Pour les fan de parano ultime...
On peux envisager de camoufler tous ces segments chiffré dans des images ou dans d'autres éléments.
mais cela implique de bien maitriser les ratio de données camouflable/données totale.
Autant c'est facile a faire pour des petites données autant je doute que ca le soit pour de grande quantitée.

A suivre ;-D