Restic: Sauvegardes non cryptées

J'ai entendu cette demande de fonctionnalité à quelques reprises maintenant, et j'avais à l'esprit qu'il y avait un problème à ce sujet. Comme je n'arrive pas à le trouver, cette demande de fonctionnalité est suivie ici. La version courte est la suivante : nous pourrions éventuellement ajouter une option pour désactiver le cryptage, mais ce n'est pas sur la feuille de route pour le moment.

La version longue est :

• Le cryptage n'est plus cher, du moins pas si vous avez AES-NI (cryptage accéléré par matériel), ce qui est assez courant de nos jours (au moins dans les ordinateurs portables et les serveurs)
• restic se soucie non seulement du cryptage, mais aussi de l'authenticité et de la signature des données. Nous devons trouver un moyen d'implémenter cela sans cryptage, nous devrons donc de toute façon conserver une clé/un mot de passe.
• Une fois que nous avons un chemin de code qui autorise les sauvegardes non chiffrées, il est possible que les attaquants trouvent un moyen de tromper un client pour qu'il enregistre les données sans chiffrement dans un référentiel chiffré (à l'origine). Cela s'est déjà produit avec d'autres programmes de sauvegarde, nous devons donc être très prudents, ce qui prend du temps et des ressources que nous n'avons pas pour le moment.

J'ajouterai peut-être d'autres points lorsque je les trouverai.

Une autre raison de vouloir des sauvegardes non cryptées (localement) est qu'un référentiel central puisse être partagé par plusieurs utilisateurs - c'est-à-dire que sur mon serveur domestique, j'aimerais lui envoyer une sauvegarde via HTTPS, mais laissez-les tous être dédupliqués dans un référentiel commun, même s'ils sont présentés comme étant logiquement séparés des utilisateurs individuels.

il est possible que les attaquants trouvent un moyen de tromper un client pour qu'il enregistre les données sans cryptage dans un référentiel crypté (à l'origine).

Hm, je pensais que l'idée était qu'un référentiel soit crypté ou non, il ne serait donc pas possible d'enregistrer des données non cryptées dans un référentiel crypté... Et si un référentiel crypté est en quelque sorte remplacé par un non crypté avec le même nom et emplacement, l'utilisateur doit remarquer qu'aucun mot de passe n'a été demandé. Peut-être qu'un avertissement en gras clignotant en rouge peut être imprimé, indiquant que le référentiel n'est pas crypté :).

@wrouesnel, vous pouvez déjà le faire, en faisant la distinction par nom d'hôte ! (Je me demandais la même chose l'autre jour) :)

@alexeymuranov comment déterminez-vous si le mot de passe entré par l'utilisateur est le mot de passe de cryptage pour un répertoire crypté, ou le mot de passe MAC pour vérifier l'authenticité d'un répertoire non crypté ? plus --switches ? Cela devient très salissant très vite.

J'aimerais avoir cette option pour faire des sauvegardes locales. Par exemple, chaque jour, j'exécute une sauvegarde de mon répertoire ~/Music sur mon serveur, mais je n'ai pas besoin que cela soit crypté. La sauvegarde n'est pas pour se protéger contre les pannes ou les pertes matérielles (j'ai d'autres sauvegardes pour ça), mais simplement pour se protéger contre les accidents et le bitrot. Et le serveur est plutôt de faible puissance, donc la surcharge de chiffrement est un problème.

@alphapapa pour ça il y a rsync .
EDIT : Et les permissions/attributs de fichiers. BTW, quelle est la différence entre « défaillance matérielle » et « bitrot » ?

@cfcs , rsync ne déduplique pas.

pour cela il y a rsync.

@cfcs Comme nous le savons tous, un miroir n'est pas une sauvegarde. ;) En utilisant Obnam, je garde une série de sauvegardes, similaire à restic : keep = 7d,8w,12m,3y Depuis que j'ai failli perdre ma clé GPG (car elle a été mystérieusement tronquée à 0 octet sans que je m'en rende compte, et le fichier tronqué a été sauvegardé à plusieurs reprises), et j'ai dû le déterrer d'une sauvegarde vieille de plusieurs années sur un CD-R, je reconnais l'importance de conserver les anciennes données de sauvegarde.

BTW, quelle est la différence entre « défaillance matérielle » et « bitrot » ?

Bitrot n'est généralement pas détecté jusqu'à ce que vous ayez besoin des données pourries et ne rend pas l'ensemble de l'appareil illisible. Une défaillance matérielle est, par exemple, une défaillance totale du disque, un échec du démarrage du système, etc.

Et comme le souligne Alexey, rsync ne déduplique pas, ne permet pas non plus d'élaguer les anciennes données de sauvegarde, ni de vérifier l'intégrité des données, etc. rsync est un bon outil, et je l'utilise régulièrement, mais pas pour faire des sauvegardes .

Le cryptage n'est plus cher, du moins pas si vous avez AES-NI (cryptage accéléré par matériel), ce qui est assez courant de nos jours (au moins dans les ordinateurs portables et les serveurs)

Sauf si votre logiciel est écrit en go. Go's crypro est un logiciel uniquement pour tout sauf Intel - donc avec un appareil bras, vous êtes bloqué avec "durée de sauvegarde estimée - 14 jours" pour le même ensemble de fichiers qui est terminé en moins de 30 minutes avec la solution de sauvegarde officielle basée sur openssl sur mon NAS .

J'aimerais aussi voir cette fonctionnalité. J'utilise SSH pour le transfert et je stocke mes sauvegardes sur des volumes chiffrés LUKS/cryptsetup, donc le chiffrement ne fait qu'ajouter le risque de perdre la clé de chiffrement. De plus, le cryptage ajoute plus de risques d'erreurs et ajoute une charge inutile au processeur.

Néanmoins, le cryptage est très utile lorsque je sauvegarde sur une cible non fiable.

Les gens peuvent être motivés pour sécuriser un fichier texte comprenant le mot de passe ainsi que la sauvegarde...

J'utilise également une cible de sauvegarde chiffrée luks/dm-crypt. C'est un disque USB externe que je monte sur /Backup/
Vous pouvez simplement créer un fichier de mot de passe à cet emplacement (/Backup/restic_password) et le transmettre à restic en utilisant --password-file. Le référentiel va sous /Backup/restic_repo/
Il est important de rendre le fichier de mot de passe immuable, ou vous êtes foutu s'il est perdu par accident : chattr +i /Backup/restic_password
De plus, j'utilise simplement "restic" comme mot de passe, juste au cas où.

La fonction de cryptage de Restic est très utile si vous sauvegardez sur des cibles non fiables comme les fournisseurs de cloud. Mais si vous utilisez simplement des disques externes que vous stockez à la maison ou un NAS dans votre sous-sol, le cryptage forcé est un peu fou. L'utilisateur moyen oubliera de toute façon le mot de passe.

Autoriser les sauvegardes non chiffrées permettrait à ZFS, BtrFS ou NTFS ou tout autre système de fichiers de compresser les sauvegardes.

(Le cryptage peut être effectué via dmcrypt à une couche inférieure si vous le souhaitez)

Autoriser les sauvegardes non chiffrées permettrait à ZFS, BtrFS ou NTFS ou tout autre système de fichiers de compresser les sauvegardes.

Idem ici, pas de compression et le cryptage obligatoire prend trop de place sur mon serveur de sauvegarde. Mon cas d'utilisation (quelques images, beaucoup de petits fichiers xml/txt/csv) bénéficierait grandement de l'absence de cryptage (donc ZFS pourrait faire son travail) ou de la compression (~ 2,3 taux de compression avec zstd,5).

Si vous utilisez ZFS, pourquoi ne pas simplement utiliser des instantanés zfs send ?

Les instantanés ZFS ne sont pas suffisants pour la sauvegarde dans de nombreux cas. Si vous avez une corruption non détectée dans un fichier, ou si vous voulez avoir des années d'ensembles de sauvegardes, les instantanés ZFS n'aident pas beaucoup. Par exemple, disons que vous utilisez FreeNAS et que vous souhaitez maintenir un an de sauvegardes hebdomadaires. La planification et la gestion des instantanés intégrées à FreeNAS ne sont pas _vraiment_ suffisantes pour y parvenir correctement. Ce n'est pas "l'entreprise".

Si vous avez un système de planification plus élaboré, cela fonctionnera probablement beaucoup mieux. Il y a aussi le problème de zfs send nécessitant l'existence d'un instantané avant de pouvoir l'expédier ; vous devez également gérer une planification d'instantané et vous assurer que votre instantané et votre envoi planifié sont synchronisés (manuellement) afin que vous atteigniez votre RTO/RPO.

Et oui.. Je parle des fonctionnalités d'entreprise sur FreeNAS. Mais c'est le souci...

Le cryptage n'est plus cher, du moins pas si vous avez AES-NI

L'exigence AES-NI exclut de nombreux serveurs plus anciens (qui, dans certains cas, sont _particulièrement importants_ à sauvegarder !).

J'aide quelqu'un à obtenir de meilleures sauvegardes en cours d'exécution sur une collection de serveurs en Afrique rurale, sur du matériel donné depuis plus de 10 ans (certains sont même encore en 32 bits !). Je crains que le cryptage n'ajoute simplement trop de temps système, donc je suppose que pour l'instant je devrai chercher ailleurs.

+1 pour aucun cryptage

ce serait utile

+1 pour aucun cryptage

ce serait utile

Veuillez utiliser la fonction de pouce levé sur le numéro d'origine au lieu de '+1'-ing pour éviter d'inonder les boîtes de réception des observateurs. Merci!

Quel est le statut de cette fonctionnalité ?

J'ai besoin de sauvegarder des fichiers (documents partagés comme des traductions de manuels d'utilisation) à partir du serveur samba interne auquel tous les utilisateurs de l'entreprise ont accès de toute façon, ils ne sont pas vraiment confidentiels dans les limites de l'entreprise. Le cryptage des sauvegardes dans ce cas est inutile, j'utilise de toute façon jailkit pour une sécurité supplémentaire pour les sauvegardes, et j'utilise le système de fichiers btrfs avec la compression activée. Je sauvegarde des trucs comme les vidages de disque VM d'une autre manière de toute façon. Le cryptage n'est pas un problème dans mon cas d'utilisation, la prévention de la perte de données est à peu près la seule priorité. L'utilisation d'un mot de passe comme « restic » est une solution de contournement idiote.

Veuillez implémenter ceci.

@mrkafk Quel est le problème réel pour vous avec le chiffrement de restic ? Même si vous n'en avez pas besoin, vous auriez besoin de raisons très spécifiques pour que ce soit un problème, car vos processeurs prennent très probablement en charge le cryptage matériel.

J'ai décrit mon problème réel : étant donné le contexte spécifique, je n'en ai pas besoin, alors que si je comprends bien, cela élimine au moins les gains de compression dans le système de fichiers btrfs. J'ai des tonnes de fichiers à sauvegarder, c'est pourquoi j'utilise btrfs avec la compression activée en premier lieu car avec RAID-1 pour la redondance matérielle, j'ai besoin de beaucoup d'espace disque (si ce n'était pas pour ça, je préférerais de loin utiliser poste4). De plus, chiffrer avec ce qui équivaut à un faux mot de passe et effectuer un chiffrement semble inutilement… idiot.

D'accord, parmi les choses que vous avez écrites, je comprends un problème réel , à savoir que la compression BTRFS n'est pas aussi efficace qu'elle pourrait l'être sans cryptage. C'est un bon point. En plus de cela, je ne vois rien qui vous limite en raison du cryptage de restic.

Il est impossible de perdre la clé de cryptage si elle n'est pas cryptée. C'est particulièrement pertinent pour les sauvegardes.

Mébus

Il est impossible de perdre la clé de cryptage si elle n'est pas cryptée. C'est particulièrement pertinent pour les sauvegardes.

Cela a déjà été discuté comme si le monde se terminerait demain :) https://github.com/restic/restic/issues/1786