Je ne suis pas sûr de déplacer l'en-tête vers l'avant. Je sais que ce n'est pas implémenté actuellement, mais pour un référentiel local, avoir l'en-tête à la fin signifie que nous pouvons enregistrer une copie de fichier.

Point intéressant, merci. Je ne sais pas encore comment juger ce qui est mieux. Pour les backends distants, nous pourrions également (après quelques modifications de l'interface backend) simplement passer un io.Reader et peut-être que la stdlib pourra utiliser sendfile pour diffuser le fichier directement depuis le disque. hum.

Juste pour votre information, je me demandais pourquoi vous n'utilisiez pas GCM, alors j'ai exécuté les tests de performance. AES-CTR + Poly1305 est assez rapide si le CPU n'a pas AES-NI (50% plus rapide que Go intégré GCM). Avec AES-NI, le code d'assemblage optimisé de Go pour GCM est probablement imbattable.

Intel Xeon E312xx

restic:
BenchmarkEncrypt-4        50      32470322 ns/op     258.35 MB/s

stupidgcm:
Benchmark4kEncStupidGCM-4     200000         10620 ns/op     385.67 MB/s
Benchmark4kEncGoGCM-4         300000          5540 ns/op     739.22 MB/s

Intel Pentium G630 (pas d'AES-NI)

restic:
BenchmarkEncrypt-2            10     108468078 ns/op      77.34 MB/s

stupidgcm:
Benchmark4kEncStupidGCM-2          50000         24182 ns/op     169.38 MB/s
Benchmark4kEncGoGCM-2              20000         96391 ns/op      42.49 MB/s

Cela n'appartient pas à ce problème, mais je répondrai quand même:

Je pense qu'à l'époque où j'ai commencé restic, Go n'avait pas de version optimisée de GCM. De plus, je ne me sentais pas à l'aise d'utiliser GCM car je ne le comprenais pas, alors que le papier Poly1305 était beaucoup plus facile à lire et à comprendre.

Je pense que votre benchmark traite des blobs de données beaucoup plus petits, peut-être qu'il se rapprochera lorsque les blobs seront plus grands.

Je vois. Ouais le GCM optimisé est assez récent, je pense que Cloudflare en a fait don pour Go 1.5.

En ce qui concerne la taille des blocs, le benchmark restic utilise 8 MiB tandis que stupidgcm utilise 4kiB . J'ai réessayé avec une taille de bloc de 8 MiB pour stupidgcm mais les résultats sont pratiquement identiques.

Alors ne perdons pas de temps là-dessus, je pense que CTR+Poly1305 est assez rapide.

Est-il important d'avoir une taille non compressée dans le fichier d'index ou le pied de page du pack ? Je pense que ce serait bien de le savoir uniquement dans le blob, alors moins de changements sont nécessaires dans restic. Permet-il à de nouvelles fonctionnalités de le faire connaître à cet endroit supplémentaire ?

À mon avis, le format de référentiel 2 == le premier octet de données blob indique le format de compression, c'est tout ce qui est nécessaire. Peut-être que l'un des 255 formats possibles pourrait être {64 bits de longueur non compressée}{données compressées}.

Je pense que la correction d'erreur est une bonne idée pour la sauvegarde. Mais je pense que c'est une responsabilité du système de fichiers. Souhaitez-vous également implémenter RAID à l'intérieur de restic ?

Est-il important d'avoir une taille non compressée dans le fichier d'index ou le pied de page du pack ?

Oui : l'en-tête du pack décrit le contenu du pack et indique au processus d'extraction à quoi s'attendre (en termes d'algorithme de compression, de taille non compressée, et plus tard également d'autres attributs comme la clé qui a été utilisée pour le chiffrement). La même chose doit être représentée dans l'index, qui a été introduit pour que restic n'ait pas besoin de rechercher chaque blob dans un en-tête de pack. Donc, la même information doit être présente ici.

À mon avis, le format de référentiel 2 == le premier octet de données blob indique le format de compression, c'est tout ce qui est nécessaire. Peut-être que l'un des 255 formats possibles pourrait être {64 bits de longueur non compressée}{données compressées}.

Je n'aime pas cette idée, cela complique le format du fichier : nous aurons des informations de contrôle à deux endroits différents : au début d'un blob et dans l'en-tête. L'en-tête est précisément l'emplacement qui contient les informations de contrôle.

Je pense que la correction d'erreur est une bonne idée pour la sauvegarde. Mais je pense que c'est une responsabilité du système de fichiers.

En principe, je suis d'accord, mais les systèmes de fichiers sont des choses très compliquées, et la propagation des erreurs (par exemple des erreurs de lecture/écriture du support) est souvent sous-optimale. Pour les données de sauvegarde très réduites (en termes de redondance, par exemple dédupliquées), je pense toujours que c'est une bonne idée d'ajouter (ou de proposer d'ajouter) une autre couche de correction d'erreurs.

Pour les codes Reed-Solomon, il existe une implémentation Go pure sur https://github.com/klauspost/reedsolomon avec quelques données de performances.

Selon https://www.usenix.org/legacy/event/fast09/tech/full_papers/plank/plank_html/ ZFEC devrait être plus rapide. Une implémentation se trouve dans https://gitlab.com/zfec/go-zfec qui semble être basée sur https://pypi.python.org/pypi/zfec.

Les ECC sont appliqués après compression et sont normalement entrelacés dans le fichier de données, car leur distribution les rend plus robustes si les données sont transférées sur des canaux de communication peu fiables ou bruyants.

Dans les groupes binaires Usenet, ils utilisent des fichiers séparés (voir https://en.wikipedia.org/wiki/Parchive) qui contiennent les informations ECC. Cela ajouterait juste un autre sous-répertoire à la disposition du référentiel et appliquer ECC aux informations de gestion du référentiel (config, index, ...) serait également facile. Mais je ne sais pas si cela affaiblirait le schéma ECC (peut-être que la robustesse contre les erreurs de cluster dans les informations ECC diminue).

Merci pour les conseils. J'ai trouvé la version PDF de l'article ici : https://www.usenix.org/legacy/event/fast09/tech/full_papers/plank/plank.pdf

L'implémentation ZFEC Go n'est qu'un wrapper autour de la bibliothèque C.

Pour ZFEC il existe un port Go avec des ajouts (utilisation de goroutines) nommé jfec sur [https://github.com/korvus81/jfec].

J'ai ajouté un "projet" (un ajout récent à GitHub) pour suivre la mise en œuvre du nouveau format de référentiel : https://github.com/restic/restic/projects/3

Quelques idées qui pourraient être examinées lors de la rupture de la rétrocompatibilité :

• Passer de sha256 à sha512

L'utilisation de sha512 (ou sha512/256) au lieu de sha256 entraînera-t-elle une augmentation de la vitesse de sauvegarde ? Autant que je sache, cela est vrai pour la plupart des plates-formes, à l'exception d'ARM.

Discussion sur la synchronisation (https://github.com/syncthing/syncthing/issues/582)

Discussion Borg (https://github.com/jborg/attic/issues/209)

Article sur sha512/256 (https://eprint.iacr.org/2010/548.pdf)

• Utiliser le cryptage à clé publique au lieu d'un simple mot de passe

Actuellement, tous ceux qui ont accès en écriture au référentiel ont accès en lecture à partir de celui-ci. Le chiffrement à clé publique éliminerait cela et permettrait toujours la déduplication basée sur les hachages.

L'application d'un cryptage à clé publique aux blobs de données fonctionnerait, mais je ne suis pas assez familier avec la façon dont restic traite la structure arborescente pour savoir si elle pourrait être implémentée avec succès pour cela également. Cela pourrait éventuellement introduire beaucoup de complexité. Si seuls les blobs de données sont masqués, il y a encore beaucoup d'informations dans les arbres.

NaCl - https://godoc.org/golang.org/x/crypto/nacl/box

• Identification du référentiel

Actuellement, il n'y a aucun moyen de savoir que vous regardez un référentiel restic lorsque vous tombez sur le référentiel. Nous divulguons actuellement "created":"TIMESTAMP","username":"XXXXX","hostname":"XXXXX" dans les fichiers clés. Je suggérerais de masquer ces informations et d'inclure à la place des informations sur restic, telles que restic repository version X . Peut-être aussi simple qu'un README.

Concernant les discussions précédentes ; Je suis très favorable à la mise en œuvre d'une forme de correction d'erreurs.

@oysols Merci de vous avoir ajouté des idées !

J'ajouterai mes pensées ci-dessous:

Passer de sha256 à sha512 (pour la vitesse)

Pour le moment, je ne suis pas concerné par la vitesse (restic est déjà très rapide), donc au moins pour moi, cet élément n'est pas prioritaire. Il existe même une version optimisée de SHA256 pour les processeurs compatibles SIMD vers laquelle nous pouvons simplement basculer. Par contre, quand on décide d'accélérer le restic et que le hash est à discuter, je préférerais sans doute Keccak (SHA3) ou Blake2, ce sont (pour autant que je sache, je n'ai pas encore fait de benchmarks) Plus vite.

Donc, de mon point de vue, cet article est reporté pour le moment.

Utiliser le cryptage à clé publique au lieu d'un simple mot de passe

Cette fonctionnalité est prévue (voir #187), mais elle est compliquée et demande beaucoup de réflexion et plusieurs modifications majeures de l'infrastructure. J'aimerais aussi reporter cela et plutôt faire des mises à jour incrémentielles plus petites au lieu d'une où nous changeons tout -> reporté.

Identification du référentiel (ajoutez un fichier README dans le référentiel)

Très bon point, on peut même en rajouter maintenant sans rien casser.

"Fuite d'informations" du référentiel (suppression du nom d'utilisateur, du nom d'hôte et de l'horodatage créé des fichiers clés)

C'est aussi un bon point. Nous n'utilisons actuellement ces informations que pour les afficher à côté de l'ID de clé dans la commande key list . On peut facilement déposer username et host , l'horodatage ne donne pas beaucoup d'informations, dans la plupart des cas ce sera le même que la date de création du fichier.

Je voudrais déposer username et host et laisser l'horodatage créé.

J'ai joué avec https://github.com/klauspost/reedsolomon aujourd'hui et je pense que nous pouvons ajouter des codes de correction d'erreurs assez facilement à la fin du fichier pack (une fois que nous avons déplacé l'en-tête du pack au début du fichier ). Il y a cependant deux inconvénients :

• La taille du fichier augmentera d'environ 14 à 30 %, en fonction des paramètres que nous choisissons pour Reed-Solomon
• Nous devrons stocker les sommes de contrôle (pas nécessairement les hachages cryptographiques) des sections du fichier pack dans le fichier pack lui-même, celles-ci sont nécessaires pour la reconstruction car l'algorithme de reconstruction doit savoir quelles parties du fichier ont été endommagées. Cela prend donc un peu plus de temps à calculer, bien que nous puissions choisir d'utiliser une somme de contrôle rapide (comme CRC ou autre).

Les pensées?

La protection des tiges de données pourrait-elle alors être facultative? Je considère que l'augmentation de la taille est plus que marginale (c'est une fonctionnalité intéressante pour les autres, même si je crois !)

Permettez-moi de jouer un peu avec cela, afin que je puisse avoir une idée de la taille (ou de la taille) du dépôt lorsque l'ECC est combiné à la compression. Nous ajoutons peut-être deux types de codes : un pour l'en-tête du pack et un (peut-être facultatif) pour les données.

supprimer le nom d'utilisateur et l'hôte

Ça semble être une bonne idée. Si nous voulons conserver les informations, elles pourraient être ajoutées à un champ crypté séparé, de la même manière que la clé principale.

ECC : la taille du fichier augmentera d'environ 14 à 30 %,

Je ne pense pas que ce soit une bonne idée d'inclure l'ECC dans les fichiers du pack eux-mêmes. Ils ne sont d'aucune utilité dans un scénario de restauration typique et ne sont utilisés que si les fichiers du pack sont endommagés.

Je suggère que les données de parité soient placées dans un répertoire séparé :

repo/data/1e/1ef7267...
repo/parity/1e/1ef7267...

• La parité sera complètement facultative et pourra être créée après la sauvegarde.
• Aucun ralentissement des opérations de restauration. Aucune bande passante supplémentaire nécessaire pour la restauration.
• Des noms de fichiers identiques facilitent l'identification des données de parité correctes. Cela signifie que les données de parité ne sont pas nommées d'après leur propre hachage sha256, mais aucun index supplémentaire ne sera nécessaire. (La vérification des données de parité doit être effectuée en vérifiant les fichiers du pack, de toute façon.)
• L'utilisateur a une idée de la quantité de données de parité.

Peu importe comment il est mis en œuvre; Avec de nombreuses couches de compression et de cryptage, je pense qu'une sorte d'ECC est nécessaire. Un mauvais morceau peut causer beaucoup de problèmes.

Merci pour vos commentaires, déplaçons la discussion vers un problème séparé que je viens de créer : #804.

Je ne peux pas m'empêcher d'avoir l'impression qu'il y a deux groupes qui se parlent des codes de correction d'erreur directe en restic. Un groupe veut (juste) protéger le repo du bitrot, car même un seul bitflip peut créer un énorme problème dans un repo dédupliqué. L'autre groupe souhaite utiliser des codes d'effacement pour répartir le référentiel sur plusieurs domaines défaillants (par exemple, des disques non RAID). Les deux objectifs peuvent être servis par les codes Reed-Solomon, mais ils nécessitent des paramètres différents et des dispositions de stockage différentes.

J'ai effectué une vérification rapide de mon référentiel avec mon script python (https://github.com/oysols/restic-python).

header_length:        8688549
tree_length:         53898054
data_length:     146443506727
treeblobs:               8466
datablobs:             200975
packfiles:              29351
---- repo size by dir ----
            155   config
146 510 470 574   data
     27 538 629   index
          4 545   keys
          4 243   locks
         14 041   snapshots
          4 096   tmp
-----
Currently 116071 original files contained in the backup.

Sur une sauvegarde de 146 Go, les blobs d'arborescence ne font que 54 Mo et se compresseront bien à environ un tiers de l'espace d'origine, lorsque nous implémenterons la compression.

Y aurait-il une amélioration des performances en séparant les blobs d'arbres des blobs de données ?

Il semble que la plupart des opérations effectuées lors d'une restauration soient effectuées sur la base des blobs de l'arbre, avant de restaurer réellement les données. Les séparer dans des fichiers de pack séparés minimiserait la quantité de données devant être téléchargées pour analyser l'arborescence d'une sauvegarde. Étant donné la petite taille des blobs d'arborescence, il peut même être plus rapide de télécharger tous les blobs d'arborescence avant de démarrer le processus de restauration.

Bien sûr; Cette distribution peut ne pas être la même pour tous les dépôts.

Pensez-vous que cela mérite d'être approfondi ?

Y aurait-il une amélioration des performances en séparant les blobs d'arbres des blobs de données ?

C'est peut-être l'une des optimisations que j'ai en tête pour l'avenir.

En dehors de cela, j'aimerais également ajouter un cache local pour les métadonnées, afin qu'elles n'aient pas du tout besoin d'être extraites du référentiel. Cela devrait grandement améliorer la vitesse de nombreuses opérations.

Y aurait-il une amélioration des performances en séparant les blobs d'arbres des blobs de données ?

Cela pourrait théoriquement améliorer le fonctionnement prune , car moins de remballage serait nécessaire si les blobs d'arbres et les blobs de données étaient dans des packfiles séparés (il pourrait devenir possible de supprimer en gros un ancien packfile au lieu de le reconditionner).

Je regarde déjà ça pendant #842

gcm contre ctr : http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html

sym vs asym : l'idée est de chiffrer par pubkey une clé de "session", n'est-ce pas ?

Ne parlons pas de crypto dans ce numéro, car il est reporté pour le moment. Le problème pertinent pour les discussions sur la cryptographie asymétrique est le #187. De plus, j'aimerais maintenir la discussion à un niveau élevé jusqu'à ce que nous ayons défini le cas d'utilisation. Ensuite, nous pouvons parler de crypto de bas niveau.

Supprimez le nom d'utilisateur et le nom d'hôte des fichiers clés.

Énorme fuite de métadonnées !
Par exemple, "username":"WorldBank\\JimYongKim" indique clairement un propriétaire de haut rang .

En attendant que cela soit _supprimé_ (ou _crypté_) depuis la compilation du premier binaire Windows en janvier 2017.
Heureusement, j'ai examiné la sauvegarde avant de télécharger ou de recommander Restic à des personnes soucieuses de la confidentialité.

Edit : le fuseau horaire de l'utilisateur est également mentionné en texte brut, ce qui va également à l'encontre du principe de confidentialité .

Re : SHA3 - voici une opinion expliquant pourquoi cela ne vaut pas la peine d'être adopté (encore ?) : https://www.imperialviolet.org/2017/05/31/skipsha3.html

Ainsi, je pense que SHA-3 ne devrait probablement pas être utilisé. Il n'offre aucun avantage convaincant par rapport à SHA-2 et entraîne de nombreux coûts. Le seul argument que je peux créditer est qu'il est agréable d'avoir une fonction de hachage de sauvegarde, mais SHA-256 et SHA-512 sont généralement pris en charge et ont des cœurs différents. Nous avons donc déjà déployé deux fonctions de hachage sécurisées et je ne pense pas que nous en ayons besoin d'une autre.

J'ai lu le post et je comprends les arguments d'agl. Pour restic, ce n'est pas si pertinent : nous utilisons la fonction de hachage pour identifier (de manière unique) les blobs, et non comme un élément constitutif d'un protocole cryptographique. Mon idée de regarder d'autres fonctions de hachage était principalement que SHA-256 est lent à calculer, en particulier sur les systèmes bas de gamme. D'autres fonctions de hachage sont beaucoup plus rapides (par exemple blake2).

Vous ne savez pas s'il s'agit d'un truc au format repo : que diriez-vous de rendre le cryptage facultatif ? Je pense aux sauvegardes qui seront stockées sur un serveur de sauvegarde de confiance qui a déjà des disques chiffrés.

@mschiff Voir # 1018 pour cette discussion. ;)

Que diriez-vous de faire de la taille des pièces une option ?
Actuellement, j'ai 4-6 Mo par fichier. Avec moins de fichiers mais plus volumineux, la sauvegarde à distance sera beaucoup plus rapide.

@fd0 a écrit :

Pour le moment, je ne suis pas concerné par la vitesse (restic est déjà très rapide), donc au moins pour moi, cet élément n'est pas prioritaire. Il existe même une version optimisée de SHA256 pour les processeurs compatibles SIMD vers laquelle nous pouvons simplement basculer. Par contre, quand on décide d'accélérer le restic et que le hash est à discuter, je préférerais sans doute Keccak (SHA3) ou Blake2, ce sont (pour autant que je sache, je n'ai pas encore fait de benchmarks) Plus vite.

Une autre considération pour un algorithme de hachage plus rapide et moins gourmand en CPU (comme Blake2) serait la réduction de l'utilisation de la batterie sur les ordinateurs portables lors des sauvegardes sans connexion à une source d'alimentation.

Réponse au premier post :

Supprimez le nom d'utilisateur et le nom d'hôte des fichiers clés.

Cela serait-il remplacé par un nom de clé ou une description quelconque ? Je pense qu'un moyen de distinguer différentes clés (sans avoir accès à la clé elle-même, par exemple lors de la révocation de l'accès à une machine) est utile pour rendre la gestion des clés utile ?

Une nouvelle suggestion : que diriez-vous d'utiliser une clé différente pour les blobs, les arbres et les instantanés ? Cela permettrait, AFAICS, un scénario où l'oubli et l'élagage se produisent sur le serveur de stockage de sauvegarde, plutôt que sur les clients. En accordant au serveur de stockage l'accès à l'arborescence et aux objets d'instantané, il doit disposer de suffisamment d'informations pour déterminer quels objets sont nécessaires à quels instantanés et quels objets ne sont plus utilisés. Si le serveur de stockage est compromis, l'accès est obtenu aux métadonnées de l'arborescence, mais pas au contenu réel du fichier.

Cela peut être légèrement renforcé en n'autorisant l'accès qu'à la liste des identifiants d'objets référencés par un arbre, sans autoriser l'accès au reste des métadonnées (mais cela nécessiterait une structure de données supplémentaire pour chaque arbre).

Si ce qui précède était rendu possible, cela ouvrirait la voie à l'utilisation d'un type de stockage en écriture seule / ajout uniquement (où le client sauvegardé ne peut pas supprimer les sauvegardes, voir #784), sans avoir à sacrifier l'élagage automatisé, ou sécurité des données.

Concernant mon commentaire précédent (élagage sans avoir besoin d'un accès complet aux données) : cela s'applique également (peut-être même plus fort) à la vérification de la sauvegarde. Il est logique de vérifier un référentiel sur le serveur de stockage pour des raisons d'efficacité (AFAICS pour vérifier un référentiel à distance nécessite le transfert de tout le contenu), ou lors de la mise en œuvre d'un véritable support en écriture seule (voir https://github.com/ncw/rclone/issues /2499).

De plus, pour une véritable approche en écriture seule, des modifications sont nécessaires pour restreindre les fichiers à lire (selon https://github.com/ncw/rclone/issues/2499#issuecomment-418609301). Je ne sais pas si cela nécessite également des changements de format de référentiel, si tel est le cas, il pourrait être utile de les inclure ici?

Vérifier et élaguer un référentiel sur le serveur distant serait vraiment génial. Je suis en train de configurer restic pour sauvegarder plusieurs hôtes et j'aimerais effectuer toutes les tâches de maintenance à distance afin que la configuration du client soit aussi simple que possible et ne nécessite que la sauvegarde pour s'exécuter régulièrement.

J'aimerais discuter de certains ajouts (peut-être facultatifs) au format de fichier d'instantané :

• Ajouter la liste des fichiers d'index utilisés (voir #1988)
• Ajouter la possibilité pour les données définies par l'utilisateur (comme les descriptions d'ajouts, etc., n'a pas trouvé le problème pour le moment)
• Ajoutez des données statistiques telles que le nombre de fichiers/blobs, l'espace utilisé, etc. Cela pourrait rendre l'affichage des statistiques beaucoup plus rapide et permettre également des vérifications supplémentaires

À propos du format de fichier pack, je voudrais demander pourquoi ne pas supprimer complètement l'en-tête.
Les informations sont incluses de manière redondante dans les fichiers d'index. Il y a eu des discussions sur l'ajout de redondance pour la correction d'erreurs, mais IMO cela devrait (et peut) être séparé du format de dépôt général et peut être ajouté ou non ajouté en plus de cela.

Pour faire court : si vous n'avez pas besoin ou si vous ne souhaitez pas d'informations supplémentaires pour la correction des erreurs, il n'est pas nécessaire de dupliquer les informations dans les fichiers d'en-tête et d'index du pack. Les fichiers d'index sont nécessaires pour un fonctionnement performant et utilisés partout. Les en-têtes de pack sont rarement utilisés - et si c'est le cas uniquement pour une double vérification ou une correction d'erreur.

Autre proposition : ajoutez le nom d'utilisateur, le nom d'hôte et le contenu du fichier de configuration à la section data du fichier de clé. Supprimez donc complètement le fichier de configuration.

Comme déjà proposé, le nom d'utilisateur et l'hôte ne doivent être présents que sous forme cryptée. Pour vérifier si la clé dérivée de KDF est valide, il suffit déjà de vérifier le MAC de la section chiffrée data .
IMO, il est logique d'y mettre toutes les informations nécessaires à l'identification de la clé. L'ajout des informations stockées dans le fichier config ATM supprime simplement un fichier supplémentaire du référentiel et facilite l'initialisation du référentiel.

Désolé pour la question "stupide", mais y a-t-il des efforts sérieux en cours pour introduire prochainement un format amélioré ? Je suis ce problème depuis des années. restic ne fonctionne actuellement pas bien pour les grands ensembles de données, ou lorsqu'il y a de nombreux instantanés, et qu'il nécessite beaucoup de mémoire. Il semble que le manque de compression et la surcharge importante des métadonnées encodées JSON soient les gros problèmes de restic. Peut-être que l'effort s'est arrêté parce qu'il y a un besoin perçu d'atteindre la « perfection » ?

Je m'intéresse aussi à ce que l'avenir apportera à restic. Surtout en crypto asymétrique et en compression.
Au fait, pour une nouvelle fonction de hachage, il y a aussi blake3 qui est tout nouveau et aussi extrêmement rapide : https://github.com/BLAKE3-team/BLAKE3
Si aucune décision n'a déjà été prise concernant un changement de fonction de hachage, cela pourrait être intéressant.

Quelques idées supplémentaires pour repo.v2 :

• enregistrer l'arborescence et les blobs de données dans différents répertoires (dans le passé, l'arborescence et les données étaient mélangées, mais cela a été déprécié avec l'introduction du cache).
• ajouter des informations sur le "temps de création" aux blobs de données.

Cela devrait simplifier la prise en charge du stockage "froid" avec un téléchargement très lent ou coûteux comme Amazon Glacier.

* save tree and data blobs to different directories (in the past tree and data was mixed, but this was deprecated with introduction of cache).

Je n'aime pas cette idée .. Cela facilite beaucoup l'estimation de la taille des fichiers de sauvegarde alors que je n'en vois pas l'avantage.

* add 'created time' info to data blobs.

Je ne vois aucune utilité à ajouter un "temps créé". Pouvez-vous donner un cas d'utilisation?

Cela devrait simplifier la prise en charge du stockage "froid" avec un téléchargement très lent ou coûteux comme Amazon Glacier.

Je dirais que la prise en charge du "stockage à froid" peut déjà être obtenue avec le format de dépôt actuel en ajoutant des possibilités de réglage fin au restic et au double stockage des fichiers jamais moins fréquemment utilisés, par exemple dans un cache local. Voir aussi #2504

* save tree and data blobs to different directories (in the past tree and data was mixed, but this was deprecated with introduction of cache).

Je n'aime pas cette idée .. Cela facilite beaucoup l'estimation de la taille des fichiers de sauvegarde alors que je n'en vois pas l'avantage.

L'avantage est bien présenté dans les commentaires précédents sur cette question :
https://github.com/restic/restic/issues/628#issuecomment -280436633
https://github.com/restic/restic/issues/628#issuecomment -280833405
Les résultats du premier commentaire montrent également que le mélange de ces deux types de blobs ne masque pas la taille des fichiers de manière significative.

message connexe sur le forum :
https://forum.restic.net/t/feature-using-an-index-for-restic-find/1773

@cfbao Les commentaires auxquels vous faites référence concernent le mélange d'arborescence et de blob de données dans un seul fichier de données (pack). Séparer cela était utile pour activer la gestion du cache. Ceci est également déjà modifié dans restic.

Cependant, je ne vois toujours aucun avantage à enregistrer des arbres et des blobs de données dans différents répertoires . Pouvez-vous donner un cas d'utilisation? (IMO le sujet du forum de recherche n'est pas lié - je vous répondrai là-bas)

Séparer les entrées d'arbre et de blob de données dans des fichiers d'index séparés (par exemple, les répertoires "index-data" et "index-tree") permettrait cependant quelques améliorations.

Les blobs d'arbres sont déjà stockés dans des fichiers de pack séparés (cela a été introduit avec le cache).
Le simple fait de les écrire dans un répertoire différent ouvrira un moyen d'améliorer la prise en charge des stockages très lents à télécharger (3 à 5 heures pour la norme Amazon Glacier). Comme stocker toutes les métadonnées (index + instantanés + arborescence dans S3 standard et données dans Glacier).

2504 l'améliore un peu, mais je n'aime pas l'idée de compter sur le "cache local" ou d'attendre beaucoup pour remplir le cache.

J'aime beaucoup plus l'idée d'avoir un proxy inverse qui stockera tree+index+snapshots sur S3 normal ou tout autre endroit, mais placera les données dans une archive approfondie.
Dans tous les cas, il est sûrement possible d'utiliser restic tel quel avec certaines limitations. Mais certains changements de format peuvent améliorer/simplifier les choses.

@cfbao pour autant que je sache d'après le code restic find n'en bénéficiera pas. Il marche déjà sur les instantanés. Fondamentalement, c'est la même chose que restic ls <all-snapshots> | grep something .

@dionorgua
J'aime l'idée d'ajouter un référentiel arbitraire en tant que cache "supplémentaire" où tout sauf les packs de données est mis en cache. Cela ne nécessite pas de modification de la disposition du référentiel et IMO est beaucoup plus flexible.
J'y travaille déjà, voir aussi #2516, dernier commentaire.

C'est peut-être une idée stupide mais qu'en est-il d'un format compatible avec borg ou kopia ?

@aawsome

Les commentaires auxquels vous faites référence concernent le mélange d'arbres et de blob de données dans un seul fichier de données (pack).

Vrai. Ma faute. Oui, c'est la seule chose qui m'intéresse.

Ceci est également déjà modifié dans restic.

Savez-vous dans quel PR/version cela a été modifié ? La dernière fois que j'ai vérifié mon référentiel, j'ai remarqué un mélange de données et d'arbres dans les mêmes fichiers de pack. Comment puis-je (probablement lentement) convertir mon dépôt pour avoir une meilleure séparation ?

Je ne vois toujours aucun avantage à enregistrer des arbres et des blobs de données dans différents répertoires. Pouvez-vous donner un cas d'utilisation?

Je n'ai aucune idée. Comme mentionné précédemment, je ne m'en soucie pas vraiment.

@dionorgua

pour autant que je sache d'après le code restic find n'en bénéficiera pas. Il marche déjà sur les instantanés. Fondamentalement, c'est la même chose que restic ls| grep quelque chose.

La séparation des blobs d'arbres des blobs de données ne réduirait-elle pas le nombre d'appels d'API nécessaires à la recherche ? S'il est concentré, le nombre de fichiers de pack contenant des blobs d'arborescence serait réduit et restic peut télécharger un plus petit nombre de fichiers entiers au lieu de récupérer de nombreux segments à partir de nombreux fichiers de pack. Cela est important pour les backends qui sont relativement lents et ont une limitation de débit plus stricte (par exemple, Google Drive).

De toute façon, je peux (probablement lentement) convertir mon repo pour avoir mieux
séparation?

Avec une version récente de restic, une série de 'prune' devrait reconstruire ces packs mixtes..
Notez que l'implémentation réelle de 'prune' génère beaucoup de trafic pour les référentiels distants. Avec la réimplémentation expérimentale dans # 2718, vous ne pourrez remballer que des packs mixtes tout en ayant un trafic minimal.

La séparation des blobs d'arbres des blobs de données ne réduirait-elle pas le nombre d'API
appels nécessaires pour trouver?

Dans une version récente et avec un référentiel qui n'a pas de packs mixtes, toutes les informations nécessaires sont mises en cache localement.

Une autre idée pour un format de référentiel amélioré :

Comme nous l'avons vu, il est avantageux de séparer les fichiers de pack par type de blob (les blobs d'arborescence et de données vont dans des fichiers de pack différents). Ne serait-il pas judicieux de séparer également les fichiers d'index par type de blob ? Les PR d'index récents vont déjà dans le sens de la séparation des entrées d'index pour les arbres et les blobs de données dans la représentation en mémoire.
Il existe également des optimisations possibles pour ne charger qu'une partie de l'index

Faire cela également dans le référentiel permettrait une représentation plus compacte, par exemple

{
  "supersedes": [
    "ed54ae36197f4745ebc4b54d10e0f623eaaaedd03013eb7ae90df881b7781452"
  ],
  "type": "data",
  "packs": [
    {
      "id": "73d04e6125cf3c28a299cc2f3cca3b78ceac396e4fcf9575e34536b26782413c",
      "blobs": [
        {
          "id": "3ec79977ef0cf5de7b08cd12b874cd0f62bbaf7f07f3497a5b1bbcc8cb39b1ce",
          "offset": 0,
          "length": 25
        },{
          "id": "9ccb846e60d90d4eb915848add7aa7ea1e4bbabfc60e573db9f7bfb2789afbae",
          "offset": 38,
          "length": 100
        },
        {
          "id": "d3dc577b4ffd38cc4b32122cabf8655a0223ed22edfd93b353dc0c3f2b0fdf66",
          "offset": 150,
          "length": 123
        }
      ]
    }, [...]
  ]
}