Bonjour !
 
Je n'arrive pas a trouver de solution a un "système" que je voudrais mettre en place.
 
Je souhaiterai sur un "serveur" de fichiers (que j'ai déjà, sous debian) chez moi avoir mes données accessibles sur mon LAN (jusque là je maîtrise depuis bien longtemps), et qu'en plus sur cette machine les fichiers soit dupliqués (partition ou dossier, peu importe) mais chiffrés, avant envoie sur le net (rsync sur un NAS pas chez moi et synchro avec Hubic).
Pour que les données qui ne sont pas chez moi ne puissent être lues.
 
Bref, c'est la partie chiffrement a la volée des fichiers qui coince, je n’arrive pas a trouver comment faire pour que le fichier "toto.jpg" en clair sur une partition soit copié en "toto.jpg" chiffré sur une autre partition avant de pouvoir le synchro ailleurs.
J'ai vu qu'il existe des systèmes de conteneurs chiffrés, mais je ne souhaite pas réupload XXX To de données a chaque fois qu'un fichier est ajouté dans le conteneur. Idem pour les partitions chiffrées, étant donnée que le système doit pouvoir accéder a la partition pour faire son backup incrémental de la partition non chiffrer, quand il va envoyer le fichier, il va le déchiffrer non ?
 
Je suis perdu, j'ai besoin d'aide !
 
Me dites pas qu'il va falloir que je me tape un script pour faire un genre de GPG sur chaque fichiers mis a jour ou nouveau qui sera écrit dans la partition déchiffrée  
 
 
Merci !

Duplicity fait à peu près ce que tu veux: chiffrement, sauvegarde différentielle, upload vers différents type de serveurs, etc.
 
Par contre les fichiers ne sont pas stockés tels quels, ils sont dans des archives tar, qui sont ensuite chiffrées avec GPG.

Merci, je regarde ça !
 
J'ai pas réussi a comprendre si c'est :
1 fichier = 1 tar  
ou
1 dossier = 1 tar
 
Si c'est le second cas, ça va difficilement être possible avec l'upload de l'adsl...

Duplicity découpe les données en plusieurs .tar de 10MB chacun, justement pour optimiser l'upload. Il garde un manifeste pour savoir quel fichier est dans quel tar.
 
Du point de vue utilisateur c'est totalement transparent.

Le cryptage de fichiers préalable rend la synchronisation différentielle de rsync presque inopérante. En clair, ça implique de re balancer tout le fichier à chaque fois. De même que la compression d'ailleurs, sauf le gzip rsyncable du moins en théorie.
 
Pour faire ce que tu veux il existe rsyncrypto mais c'est un projet non maintenu.
 
En options fiables et maintenues il y a le système de fichiers local crypté (style luks) puis dupliqué sur un serveur distant, ou le tar crypté (avec openssl,gpg ou tout ce qu'on veut).
 
Si tu as l'accès administrateur au serveur distant tu peux utiliser rsync en tant que serveur et écrire un fichier de configuration qui spécifie des scripts de pré-exécution et post-exécution. Cela te permettra de monter dans une loop un système de fichiers crypté LUKS stocké sous forme d'un fichier standard, puis de le refermer. Lors de la fenêtre de synchro les données seront exposées mais c'est tout. Attention, à l'inverse du cryptage avant émission, cela ne dispose pas de crypter les données lors du transfert avec le tunneling SSH classique ou un VPN.

Merci ! Je regarde tout ça !
 
J'ai un peu de temps, l'alim de mon PC ayant grillé, j'ai récupéré l'alim du serveur ... du coup il ne peut plus tourner