Forum général.cherche-logiciel Sauvegardes incrémentales en ligne, chiffrées localement ?

Posté par  . Licence CC By‑SA.
Étiquettes :
3
17
nov.
2016

Hello,

J'utilise pour l'instant Google pour sauvegarder mes photos, et j'aimerais arrêter de dépendre d'une boîte ayant la capacité de lire mes données.

Je cherche un moyen pratique (raisonnablement automatisable) de faire des sauvegardes en ligne (toujours dans les serveurs d'une entreprise donc), mais chiffrées en local. Et incrémentales, parce que je n'ai pas toujours une connexion à 100 Mbps.

Le tout pouvant être payant (je sais bien qu'on ne peut pas demander la gratuité et la confidentialité à une boîte privée), mais dont le prix n'explose pas trop : étudiant, je ne peux pas payer tant que ça.

Comme j'utilise aussi Windows, j'aimerais que ça fonctionne là aussi. Dans tous les cas, si ça demande un peu de travail (scripting par exemple), je ne suis pas contre.

Qu'utilisez-vous ?

Merci !

  • # EncFS

    Posté par  . Évalué à 4.

    Tu peux jeter un œil du coté de EncFS (https://github.com/vgough/encfs)

    Tu partages ensuite avec samba la version décryptée du montage de ton cloud pour tes pc windows.

    Pour les sauvegardes c'est un montage accessible sur ton fs donc tu peux utiliser rsync ou ton outil préféré.

    • [^] # Re: EncFS

      Posté par  . Évalué à 1.

      Le problème avec EncFS est que j'ai lu qu'il a un design pas très sérieux, parce qu'il n'a pas été fait par un cryptographe, et qu'on ne peut du coup pas lui faire très confiance. Comme pour ecryptfs, mais pire.

      Aussi, j'aimerais faire des sauvegardes automatiques depuis Windows aussi, du coup un simple montage samba ne suffirait pas, il faudrait un logiciel côté Windows qui ferait les sauvegardes. Plus, il faudrait un PC Linux qui gère le montage, et donc qui reste tout le temps allumé, et une connexion entre les deux machines qui supporte un tel volume de données. D'ailleurs, ça implique aussi de trouver un cloud qu'on puisse monter facilement comme dossier local, ce qui n'est pas le cas de tous !

      J'avais déjà pensé à ce genre de système de fichiers chiffré, mais je suis arrivé à la conclusion que ça ne marcherait pas pour moi. Merci quand même !

  • # Borg

    Posté par  (site web personnel, Mastodon) . Évalué à 9.

    Borg:

    • chiffré localement
    • transfert incrémental
    • dédupliqué au niveau des blocks, encore plus efficace qu'une déduplication au niveau des fichiers

    Support Linux, mais peut-être également Windows avec cygwin par exemple ? Sinon, tu peux sauvegarder ta partition Windows depuis Linux, si tu es en dual boot ?

    Pour simplifier/automatiser son utilisation (qui est déjà très simple), il existe Borgmatic.

    L'essayer, c'est l'adopter :)

    • [^] # Re: Borg

      Posté par  . Évalué à 1.

      Yep, c'est ce que j'utilisais avant ! J'avais même fait un script pour automatiser la sauvegarde de différents sets de données dans différentes locations avec des paramètres différents en une commande, le tout contrôlé par un fichier de config…

      Le plus gros problème est la compatibilité avec Windows : je crois qu'il est théoriquement compilable sous Windows, mais que personne ne s'occupe de l'y tester ni de le packager pour ce système. Ca me demanderait trop de travail, et je perdrais l'avantage de l'automatisation si je dois prendre les mises à jour moi-même.

  • # SpiderOak

    Posté par  (site web personnel) . Évalué à 3.

    MultiOS et le chiffrement se fait en local. Son seul défaut est de ne pas être libre.

    https://spideroak.com/

    • [^] # Re: SpiderOak

      Posté par  . Évalué à 5.

      J'ai lu « MultideskOS » sur le coup. Heureusement que j'ai revérifié… :-)

  • # CryFS en devenir...

    Posté par  (site web personnel) . Évalué à 2.

    J'aime bien ce projet LGPL CryFS :

    Titre de l'image

    Ce projet répond par exemple à la question que je pausais sur le forum, « loop device sur une série de "petits" fichiers ? (et non un seul gros) »

    Et donc, ils proposent déjà un comparatif avec VeraCrypt, EncFS et eCryptfs…

  • # eCryptfs

    Posté par  (site web personnel) . Évalué à 2. Dernière modification le 18 novembre 2016 à 12:48.

    Pour l'instant, j'utilise eCryptfs.

    La ligne dans /etc/fstab est longue et complexe :

    /lechemin/cloudsaves/crypted  /lechemin/cloudsaves/clear  ecryptfs  key=passphrase:passphrase_passwd_file=/root/cloudsavespass,ecryptfs_sig=bac0bf41ffd157b9,ecryptfs_fnek_sig=bac0bf41ffd157b9,no_sig_cache,ecryptfs_enable_filename_crypto=y,ecryptfs_key_bytes=32,ecryptfs_cipher=aes,ecryptfs_passthro 
    

    Mais il (…/clear) s'agit pour moi d'un dossier ne contenant lui-même que des sauvegardes journalières, effectuées elles-mêmes avec un script perso' genre rsnapshot.

    Par ailleurs, les noms des fichiers (et dossiers) ne peuvent pas être plus long que ± 128 caractères. J'ai donc un script qui tronque les noms…, et "détronque" si nécessaire… (→ le script en question)

    Je synchronise le dossier chiffré, (…/crypted) vers un serveur externe, manuellement actuellement, avec une commande du genre :

    time ionice -c 3 nice rsync -aH --delete --numeric-ids --rsync-path="sudo rsync" /lechemin/cloudsaves/crypted/ username@servername:/mnt/cloudsaves/username/crypted/
  • # Trouvé !

    Posté par  . Évalué à -2.

    Merci à tous pour vos suggestions ! Finalement je suis tombé sur la solution - non libre D: - Crashplan qui me convient. C'est automatisé, on peut chiffrer en local, y'a un stockage illimité et on peut même sauvegarder dans d'autres destinations non-cloud en même temps. Je pense que je vais garder ça. En bref, j'ai choisi la solution "je paye et vous vous débrouillez avec mes données".

    Encore merci.

    • [^] # Re: Trouvé !

      Posté par  . Évalué à 8.

      Rejeter encfs (ainsi que tous les autres) parce qu'il a un "design pas très sérieux" pour choisir un logiciel non-libre, donc dont on ne peut rien savoir sur la conception, c'est quand même osé…

      • [^] # Re: Trouvé !

        Posté par  . Évalué à -3. Dernière modification le 19 novembre 2016 à 12:00.

        Entre une boîte commerciale sérieuse dont même le support (que j'ai contacté) a de bonnes notions en crypto, et un projet dont le design est à l'évidence mauvais (c'était même ici !), je préfère largement le commercial. Non, je sais pas comment c'est codé, mais je sais qu'ils savent ce qu'ils font et qu'ils ont intérêt à le faire correctement.

        Je sais bien qu'on est sur un site sur le libre, mais c'est pas une raison pour le considérer comme la réponse à tout. Il a été PROUVÉ par un audit que EncFS n'est pas sécurisé, je vois pas pourquoi je me fais downvoter pour avoir choisi la solution la moins pire : c'est justement l'avantage du libre, de pouvoir détecter et éviter les design cryptographiques mauvais ! Faut pas inverser l'argument en faisant du libre une preuve de sécurité supérieure.

        Quant aux "autres", j'ai uniquement parlé d'ecryptfs, parce qu'il y a également eu un audit et qu'il a conclu qu'il était mal documenté, parfois la documentation contredit le code, et des choix assez bizarre ont été faits. Mieux que EncFS donc, mais pas idéal.

        Quant aux autres systèmes proposés, je les trouve très intéressants et je n'ai rien dit sur leur design. Ils répondent simplement un peu moins à mes besoins. Vus les choix que j'ai, je trouve ça raisonnable de choisir Crashplan.

        • [^] # Re: Trouvé !

          Posté par  . Évalué à 6. Dernière modification le 19 novembre 2016 à 15:12.

          Je sais bien qu'on est sur un site sur le libre, mais c'est pas une raison pour le considérer comme la réponse à tout.

          Un logiciel libre peut être vérifié/audité par tous.

          À l'inverse, un logiciel propriétaire ne repose que sur la confiance. Même si le logiciel propriétaire est audité, personne ne peut vérifier les dires de l'audit. Personne ne peut non plus vérifier que la version téléchargée est la même que la version auditée, puisqu'il est impossible de la recompiler. Personne ne peut vérifier ce que font les mises à jour du logiciel propriétaire, et dans quelle mesure les éventuels audits précédents sont toujours d'actualité.

          Faut pas inverser l'argument en faisant du libre une preuve de sécurité supérieure.

          Je ne dis pas cela, je dis que le critère "libre" est un critère minimum, obligatoire surtout quand on parle de logiciel concernant la sécurité.
          Une fois qu'on l'a, on peut commencer à juger le niveau de qualité du logiciel et sa cryptographie. Si l'on ne l'a pas, le logiciel n'est même pas bon à prendre en considération, car ses auteurs vous demandent de leur faire confiance, mais vous interdisent de vérifier leurs dires.

          • [^] # Re: Trouvé !

            Posté par  . Évalué à -4. Dernière modification le 19 novembre 2016 à 16:29.

            Un logiciel libre peut être vérifié/audité par tous.

            Exact, c'est ce qui a permis l'audit que j'ai cité, et c'est pourquoi j'ai choisi de l'éviter. Merci pour tout le speech habituel sur l'open source, je connais déjà.

            Sauf que quand toutes les alternatives libres qui répondent à mes besoins ont des failles, j'ai pas d'autre choix que de me rabattre sur autre chose. Et si on exclut la paranoïa, je vois pas pourquoi faire confiance à une boîte qui a l'air sérieuse et a une bonne réputation serait forcément une erreur.

            C'est la même chose avec les navigateurs. Regarde les deux seuls à peu près utilisables sur le marché sous Linux : Firefox et Chrome. Le premier n'a toujours pas de sandbox après des années, n'est même plus accepté à la Pwn2Own parce qu'ils le trouvent trop facile à attaquer, et rien ne va changer avant un bon paquet de mois/années encore de ce côté là. Donc je fais confiance à Chrome. C'est la même chose ici.

            Ta stratégie, ça semble être de refuser systématiquement de faire confiance à du proprio. Tu as le droit, mais dans ce cas ça ne te laisse que des alternatives trouées ou potentiellement trouées.

            Moi, j'ai choisi de faire confiance à cette entreprise pour designer correctement leur système, parce qu'ils font un service à destination des professionnels, et probablement des gens qui savent ce qu'ils font en matière de sécurité. Entre un système revu en interne par un cryptographe et un système open source revu en externe et considéré comme troué, je vais faire confiance au premier, merci bien.

            Quant au motif, oublie pas qu'en dehors d'un petit tas de logiciels libres et de qualité, les gens ne fournissent pas un service gratuitement. La protection de leurs revenus me paraît aussi plausible comme justification de leur licence non-libre que la malveillance que tu as l'air de prendre pour quasi acquise.

            • [^] # Re: Trouvé !

              Posté par  . Évalué à -1.

              Bon, je vois aux downvotes que tout le monde ici me considère comme un idiot pour avoir osé faire confiance à du proprio plutôt que de faire confiance à deux outils libres troués qui, en plus, ne me convenaient pas (inutilisables sous Windows). Merci de l'info, je demanderai ailleurs la prochaine fois.

              • [^] # Re: Trouvé !

                Posté par  . Évalué à 4.

                deux outils libres troués qui, en plus, ne me convenaient pas (inutilisables sous Windows).

                D'autres ont été proposés, comme Cryfs, et qui semble avoir une bonne sécurité, et n'est donc pas "troué". J'ai bien noté qu'il ne fonctionnait pas Windows.
                Puisque vous êtes prêt à payer, une solution potentielle serait de reporter l'argent que vous versez à Crashplan vers Cryfs, pour qu'ils fassent le portage sur Windows. Évidemment, le portage ne sera pas instantané, et cela ne vous convient donc probablement pas, mais sur le long terme ça pourrait être intéressant.

                • [^] # Re: Trouvé !

                  Posté par  . Évalué à 1.

                  Je suis d'accord, si une solution libre peut émerger qui soit compatible, je pense l'essayer. Le problème est que j'ai besoin immédiatement d'une solution de sauvegarde fiable et compatible, et que je ne croule pas exactement sous les billets.

                  • [^] # Re: Trouvé !

                    Posté par  . Évalué à 2. Dernière modification le 19 novembre 2016 à 20:24.

                    que je ne croule pas exactement sous les billets.

                    Oui, je pense que cela doit être réparti, mais cela n'est pas à votre charge. Peut-être suggérez aux auteurs de solliciter un financement participatif sur une plateforme bien en vue ?
                    L'information pourrait ensuite être relayée sur LinuxFR, avec un journal ou simplement en suggérant une dépêche.

            • [^] # Re: Trouvé !

              Posté par  . Évalué à 6.

              Moi, j'ai choisi de faire confiance à cette entreprise pour designer correctement leur système, parce qu'ils font un service à destination des professionnels, et probablement des gens qui savent ce qu'ils font en matière de sécurité.

              Qu'en savez-vous ? Des entreprises embauchent des incompétents tous les jours, ou font des erreurs, comme tout un chacun, et comme les projets libres, il n'y a aucune différence là dessus.
              La seule différence est que le projet libre a l’honnêteté d'être ouvert, ainsi on peut trier les bons projets libres des mauvais.

              Vous choisissez de vous reposer sur un critère complètement orthogonal à la sécurité : la structure légale de l'équipe développeurs.
              C'est votre choix, comme vous le dites, mais ne prétendez pas qu'il y a une quelconque corrélation entre ce critère et le critère de la sécurité.

              Sauf que quand toutes les alternatives libres qui répondent à mes besoins ont des failles, j'ai pas d'autre choix que de me rabattre sur autre chose. Et si on exclut la paranoïa, je vois pas pourquoi faire confiance à une boîte qui a l'air sérieuse et a une bonne réputation serait forcément une erreur.

              Je ne ferais pas confiance en un logiciel qui me cache ouvertement (oxymore amusant) des choses.
              Certains projets libres ne vous conviennent pas du point de vue sécurité, peut-être, mais vous ignorez totalement si crashplan est bon de ce point de vue là, et si vous vouliez le savoir, vous ne le pourriez pas, parce qu'ils ont décidé de vous le cacher.

              Moi, j'ai choisi de faire confiance à cette entreprise pour designer correctement leur système, parce qu'ils font un service à destination des professionnels, et probablement des gens qui savent ce qu'ils font en matière de sécurité. Entre un système revu en interne par un cryptographe et un système open source revu en externe et considéré comme troué, je vais faire confiance au premier, merci bien.

              L'histoire regorge d'exemples d'entreprises peu scrupuleuses ou tout bonnement ignorantes, que ce soit à destination des particuliers ou des professionnels.
              Vous faites confiance au costume qu'ils portent, pas à ce qu'ils sont réellement.

              C'est la même chose avec les navigateurs. Regarde les deux seuls à peu près utilisables sur le marché sous Linux : Firefox et Chrome. Le premier n'a toujours pas de sandbox après des années, n'est même plus accepté à la Pwn2Own parce qu'ils le trouvent trop facile à attaquer, et rien ne va changer avant un bon paquet de mois/années encore de ce côté là. Donc je fais confiance à Chrome. C'est la même chose ici.

              Il existe le projet Chromium qui repose sur la même base que Chrome, mais est libre et n'incorpore pas de composants non-libres.

              • [^] # Re: Trouvé !

                Posté par  . Évalué à -1.

                Vous choisissez de vous reposer sur un critère complètement orthogonal à la sécurité : la structure légale de l'équipe développeurs.

                Je ne comprends pas ça. J'ai choisi Crashplan par élimination : les solutions libres que j'ai trouvées ne me conviennent pas ou ne sont à l'évidence pas sécurisées, donc il me reste seulement le propriétaire.

                Je n'ai jamais dit avoir la preuve de la sécurité de Crashplan. Je sais seulement sue je n'ai pas le choix, et que la boîte a l'air sérieuse. Peut-être que le design n'est pas meilleur que celui des projets cités ; j'ai choisi de leur faire confiance, encore une fois parce que je n'ai pas le choix.

                Quant à Chromium, je l'utiliserait volontiers s'il était packagé dans ma distribution (apparemment leur mode de distribution ne facilite pas du tout la vie aux mainteneurs de la distribution, qui ont décidé de le faire passer à la trappe).

                En bref, je n'ai jamais dit que j'avais la preuve de la sécurité du service que j'ai choisi. J'ai dit que j'ai été obligé de le choisir car les alternatives ne me conviennent pas.

        • [^] # Re: Trouvé !

          Posté par  . Évalué à 5.

          il a été PROUVÉ par un audit que EncFS n'est pas sécurisé

          Est-ce qu'il a été prouvé que crashplan est sécurisé ?

  • # Duplicity

    Posté par  . Évalué à 4. Dernière modification le 19 novembre 2016 à 11:00.

    Duplicity est incrémental, et utilise GPG pour la cryptographie.

    • [^] # Re: Duplicity

      Posté par  (site web personnel) . Évalué à 2.

      Je ne peux que confirmer. J’utilise ça sur mes serveurs. Je n’est jamais entendu que GnuPG n’était pas fiable en terme de sécurité − je n’ai pas dit qu’il n’a jamais eu de failles, mais justement son code libre à permis de les identifier et de les corriger ; qu’en est-il de crashplan ?

      • [^] # Re: Duplicity

        Posté par  . Évalué à 0.

        Est-ce que c'est une tentative d'ironie par rapport à mon message du dessus ? Parce que si oui c'est idiot. GnuPG est l'un des outils auxquels je fais le plus confiance, et si j'avais un système qui répond à mes besoins (compatible avec windows donc, ce qui n'est pas du tout le cas de Duplicity), je l'adopterais immédiatement.

        Dans le cas des deux outils que j'ai cités, je le répète une troisième fois, les deux ont été audités et considérés comme non fiables.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.