Bonjour
je cherche un logiciel de chiffrement(asymétrique ou symétrique) de grosses volumes de données (serveur contenant plusieurs disques ou plusieurs serveurs).
Et aussi un logiciel de compression de ces même données qui seront par la suite sauvegardées.
Ma distribution linux est mandriva 2007.
Merci d'avance j'en ai besoin c'est urgent
# GPG
Posté par Xarli (site web personnel) . Évalué à 1.
"gpg --help" te donnera les algorithmes de compression supportés.
[^] # Re: GPG
Posté par coumbiss . Évalué à 1.
c'est superbe puisqu'il peut faire les deux en même temps.
Mon seul souci se situe sur le volume important de données à sauvegarder par serveur.
Car par serveur j'ai 15 GO de données et j'aimerai faire 24 sauvegardes par jour, 12
sauvegardes hebdomadaires, 4 sauvegardes mensuelles.
Donc j'aimerai savoir si GPG pourra compresser ce volume et son taux de compression.
Merci d'avance
# encfs
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 1.
http://arg0.net/wiki/encfs
La gelée de coings est une chose à ne pas avaler de travers.
[^] # Re: encfs
Posté par Raphaël G. (site web personnel) . Évalué à 0.
Si tu cherche a chiffrer une partition, c'est facile.
Sauvegarde le contenu, puis repartitionne la avec drakdisk.
Passe en mode expert, puis dans les options coche encrypted.
En validant il va te demander le mot de passe (+ de 20caractères) + niveau de chiffrement.
Puis tu formates, tu sauve (et sûrtout tu vérifies que la partition est pas monté en quittant diskdrake).
Puis tu n'as plus qu'a monter via :
# mount /mnt/etonpointdemontage
Password:
#
Et voila.
A chaque démarrage il te demandera si tu veux monter la partition, auquel cas il faudra entrer le mot de passe pour la partition en question.
Après il existe une autre méthode basé sur luks qui est semble-t-il nettement meilleur.
L'aventage de cette méthode est qu'elle marche depuis Mandrake 10.0-10.1 si je me souviens bien.
L'automatisation dans le /etc/fstab date de 10.2(LE2005)-2006.0
Après il y a les dossiers chiffrés, mais il me semble que la version de noyau de mandriva ne les supportent pas.
Quand au performance c'est acceptable, seule l'écriture est vraiment pénalisant.
(ici je lis des vidéos sans ralentissement)
[^] # Re: encfs
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 2.
De plus, sur un serveur, s'il te demande si tu veux monter ta partition au boot, c'est pas une super idée :)
La gelée de coings est une chose à ne pas avaler de travers.
[^] # Re: encfs
Posté par Raphaël G. (site web personnel) . Évalué à 2.
Ton encfs il est pas simplement dispo ici par exemple.
Bon j'ai pas listé tous les aventages, mais le système que j'ai mis en avant s'intercale entre ton système de fichier ET le disque dur.
En fait luks fait pareil mais avec un système qui permet d'avoir 4clef au lieu d'une pour accéder a la partition.
Ensuite ma solution a l'avantage de son support PAR défaut dans mandriva depuis 9.1-9.2 (je me souviens plus quand j'y suis passé).
Après je ne connais pas ton système de fichier, mais les luks, cryptoloop et répertoire chiffré (sur noyau récent) a d'autres avantages.
Tu bénéficies des fonctions du système (XFS ici, donc backup, ACL et compagnie), tu n'as pas a te prendre la tête a patcher ton système a chaque installation.
La reprise après crash (et perte du /) et connue.
Bref, ta solutions est peut-être très bien, mais permet moi quand même de pousser nettement plus une solution que je teste grandeur réelle depuis pas mal de temps !
[^] # Re: encfs
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 2.
La gelée de coings est une chose à ne pas avaler de travers.
[^] # Re: encfs
Posté par Raphaël G. (site web personnel) . Évalué à 2.
Bon si c'est pas toi tant pis.
Pour la petite histoire je suis passé au chiffrage de mes données lors des descentes sur les hébergeurs de serveurs direct connect.
En fait je regrette pas, le sur-coût de ces chiffrement c'est avéré acceptable...
# Sauvegarde
Posté par eon2004 . Évalué à 2.
http://wiki.mandriva.com/fr/Unison
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.