@ xDave

Ça fait plaisir d'en voir un qui lit et raisonne sainement...
La sauvegarde locale n'implique évidement pas qu'on laisse le support dans le même lieu que l'original, c'est le bon sens même...

«une sauvegarde à distance mais dont on maîtrise les choses.»
Je suis evidement d'accord sur le principe ( c'est ce que j'utilise) mais le probleme «c'est dont on maîtrise les choses»

Une solution de sauvegarde distante, meme entre ses lieux de residences ou ceux de sa famille ou amis, ça passe donc par internet et donc ça presente toujours un risque

A la complexité technique de realisation se rajoute la gestion du chiffrement, et donc il faut installer un serveur, un système de chiffrement et un VPN... et ça demande un certain niveau technique.
Y a bien des NAS pour particuliers qui offrent ce type de service, mais en terme de securité c'est tres insuffisant et surtout faut que les donnees sortent chiffrées de la machine a sauvegarder et ne soit jamais dechiffrées, meme dans le NAS.

Perso, j'applique cette solution: des PC reconvertis en serveurs (backup, git, WEB,...) avec VPN et tout ce qui sort vers ces serveurs est chiffré. Mais cela m'a pris du temps (entre trouver la bonne distrib Unix, trouver le bon compromis entre l'archivage local et le backup incremental distant, trouver une solution assez futée pour tenir sur les contrainte d'une ligne de particulier,...), bref c'est pas a la portée du premier venu, et objectivement meme si les Unix sont fiables, y a toujours de l'admin a faire. Si on a les competences techniques, donc oui, c'est une solution, mais sinon c'est pire que passer par des encloudeurs. Bref la methode de la sauvegarde locale (en mettant en lieu securisé le support) c'est ce qui reste la meilleure solution pour les particuliers.

"Ben oui, si tu as les connaissances techniques pour garantir que le niveau de chiffrement est suffisant, systematique et que seules tes données chiffrées sortent de ta machine, en transitant via un VPN, et que tu maitrise toute la chaine jusqu'au "service d'archivage", ok. Mais combien de pourcent de la masse d'utilisateurs a les competences techniques pour le faire?"

Oui, on peut être irrationnellement paranoïaque, auquel cas il faut de vraies compétences techniques pour être sûr que tout est bien chiffré.

Sinon, on peut aussi être rationnel... Les services de sauvegarde dans le cloud proposent souvent une option "zero knowledge", qui assure que le chiffrement des données est fait avec une clé non stockée sur le serveur. C'est le cas de CrashPlan. Et ce n'est pas une option cachée, bien au contraire, elle est largement mise en avant comme argument commercial.

Alors bien sûr, on peut, encore une fois, être irrationnellement parano et considérer que CrashPlan nous ment, qu'en fait les données ne sont pas chiffrées, ou encore qu'ils récupèrent la clé sur le serveur pour pouvoir les déchiffrer de leur côté. Mais quand on est rationnel, on a de bonnes raisons de leur faire confiance. Un service comme CrashPlan, très populaire, avec des millions de clients, dont des très grandes entreprises et entités (Adobe, Google, le MIT, Samsung...), ça a forcément été audité plus d'une fois par les gros clients en question, mais aussi par pas mal de white hat. S'il y avait des raisons de croire que la clé soit éventuellement transmise aux serveurs, on le saurait sans doute déjà.

Ensuite, quand bien même les données ne seraient pas chiffrées et CrashPlan se ferait infiltrer par les autorités ou des hackers. Et bien je n'ai pas la prétention d'imaginer que parmi les millions de clients de CrashPlan, ce seront mes données qui intéresseront les infiltrés. Bien au contraire, je suis même absolument convaincu que mes données de les intéresseront pas.

Après, si tu es complètement parano, je comprends que tu ne veuilles en aucun cas utiliser un service de ce genre. Mais à ce moment là, je me demande bien aussi ce que tu fais connecté à Internet, à moins que tu ais une machine spécifiquement dédiée pour ça, avec aucune de tes données dessus ^^

"CrashPlan, tu le defends, je peux comprendre que vu ton niveau technique tu puisses te penser en securité en l'utilisant. Mais pour l'utilisateur normal, c'est un foutage de gueule depuis de debut."
En quoi avoir un niveau technique plus faible fait que le même service est moins sûr ?

"Le DVD comme le DD ont un avantage enorme, ils sont locaux..."
Ce qui est aussi un désavantage énorme, en cas d'incendie, de catastrophe naturelle, etc... Et les stocker ailleurs ne résoud que partiellement le problème, parce que les sauvegardes faites en local et stockées ailleurs seront forcément en retard sur la version courante... Surtout chez le grand public, qui aura bien du mal à s'astreindre à un rythme de sauvegarde régulier s'il faut à chaque fois envoyer les DVD chez quelqu'un à l'autre bout du pays... Par dizaines d'expériences, je peux te dire que dès lors qu'une solution de sauvegarde n'est pas totalement automatisée, avec le grand public, les intervalles entre les sauvegardes augmentent irrémédiablement, jusqu'au jour où il y a besoin de la sauvegarde, et où on n'a plus que ses yeux pour pleurer quand on se rend compte que la dernière date d'il y a un an...

Après, je dis pas que les sauvegardes en lignes doivent remplacer les sauvegardes locales. Elle ne doivent même surtout pas les remplacer, vu qu'elles peuvent disparaitre du jour au lendemain. Mais elles en sont un très bon complément, en étant la seule solution de sauvegarde distante à la fois suffisamment simple (CrashPlan, c'est à peu de choses près aussi simple à utiliser que Time Machine...) et suffisamment peu coûteuse pour un usage grand public.

" alors que c'est le cas pour le cloud ( affaire de l'iPhone du terroriste de San Bernardino...)"
Je vois pas comment tu peux te baser sur cette affaire pour prétendre que les fournisseurs de cloud ont obligation de limiter le chiffrement et de donner accès aux autorités. Les données stockées dans le cloud d'Apple ne sont pas chiffrées avec une clé privée (privée vis à vis du serveur, ie le serveur n'a pas accès à la clé, pas même sous forme chiffrée), c'est un choix d'Apple, mais ça n'est pas une obligation. Et sur l'iPhone par contre, la clé est privée, et là Apple n'a pas pu être forcée à donner accès aux données.

Ce choix de ne pas utiliser une clé privée, choix qui est fait par la plupart des services de cloud orientés "synchronisation" (iCloud, Google, Dropbox, Amazon...), c'est un choix pour simplifier les choses pour l'utilisateur et pour apporter des fonctionnalités supplémentaires. Mais la plupart des services de cloud orienté "sauvegarde", ont fait le choix de la clé privé en option, pour garantir plus de sécurité.

Il y a plusieurs indices qui permettent de savoir si la clé n'est pas privée et de supposer si elle l'est :
* s'il est possible de réinitialiser le mot de passe en cas de perte sans pour autant perdre les données, c'est que la clé n'est pas privée,
* s'il est possible de partager les données avec des tiers sans redonner le mot de passe, c'est que la clé n'est pas privée,
* s'il est possible de télécharger les données avec un navigateur web, c'est que la clé n'est pas privée, sauf si on doit ressaisir un mot de passe pour faire le téléchargement même quand on est déjà identifié (dans le cas de CrashPlan, c'est le seul cas où le serveur a connaissance de la clé : si on veut faire une restauration via un navigateur web, il faut envoyer la clé au serveur... mais normalement il ne va pas la stocker, ce n'est qu'un accès temporaire),
* s'il n'y a qu'un seul mot de passe, c'est généralement que la clé n'est pas privée (parce que quand la clé est privée, les services font généralement la distinction entre le simple accès au compte, avec un premier mot de passe, et l'accès aux données, avec un second mot de passe qui sert à générer la clé),
* si tous les mots de passe peuvent être changés sans renvoyer les données, c'est généralement que la clé n'est pas privée (éventuellement, elle peut l'être, avec un déchiffrement/rechiffrement par le serveur au moment où on change le mot de passe de la clé privée, mais ça veut dire que le serveur a un accès temporaire à la clé et aux données déchiffrées, accès qui peut être plus ou moins long selon le volume de données... de mémoire CrashPlan ne fait pas ça, si on change le mot de passe privé, il ne rechiffre pas les données existantes, ce qui est déjà sur le serveur reste accessible uniquement avec l'ancien mot de passe et tous les nouveaux envois sont accessibles uniquement avec le nouveau).