Merci d'avoir signalé ce problème, je pense que c'est un bogue.

Cela se produira probablement chaque fois que les répertoires de niveau supérieur portent le même nom. Étant donné que le chemin d'accès complet n'est pas restauré, seul le répertoire de niveau supérieur.

La solution consiste à reconstruire le chemin complet lors de la restauration et à restaurer chaque arbre dans le chemin complet. Ainsi, le chemin résultant serait comme /tmp/restic/tmp/restic/FILESNEW0{1,2}/Dir01/ . Je pense que c'est acceptable.

Le correctif doit-il être implémenté dans le cadre de la restauration?
Ou peut-être que cela doit être fait pendant la sauvegarde en créant une autre arborescence de niveau supérieur qui inclut les composants du chemin complet?

Je soupçonne également que c'est le cas. Pour le moment, restic fonctionne comme ceci:

Lorsqu'il est appelé comme restic backup A/foo B/foo il crée une structure arborescente dans le référentiel qui ressemble à ceci:

├── foo
└── foo

Ainsi, seul le dernier composant de chemin des arguments vers la commande backup est pris, cela conduit à un problème lors de la restauration d'un tel instantané.

Afin de corriger cela, je propose d'implémenter le même comportement que tar , ce qui créerait dans ce cas l'arbre suivant:

.
├── A
│   └── foo
└── B
    └── foo

Cela nécessitera du travail dans la partie archiveur de restic. Je ne pense pas que nous devrons toucher du tout à la restauration.

588 J'ai rapporté la même chose. Mais celui-ci a un cas de test que vous pouvez utiliser.

@ fd0 Je propose d'inclure également une option (--store-full-path) pour sauvegarder où elle stocke explicitement le chemin «réel» complet de la cible de sauvegarde.

Le raisonnement est que dans le cas tar et avec plusieurs autres outils de sauvegarde, vous pouvez obtenir un petit arbre de restauration alambiqué. Bien que ce soit une bonne valeur par défaut, je voudrais personnellement que mes restaurations ressemblent à la disposition entière du système de fichiers d'origine pour les sauvegardes d'hôte. (Encore mieux si la restauration peut également préfixer le nom d'hôte à l'emplacement de restauration)

@trbs Je pense que la valeur par défaut doit être de stocker les chemins complets, avec un commutateur pour le cas particulier de l'utilisation de chemins relatifs. La raison étant que les chemins rel peuvent produire un comportement inattendu ou indéfini, mais pas abs. Si vous souhaitez demander des préfixes ou une autre forme de modification de chemin, je suggère que ce soit un problème entièrement distinct.

J'ai réfléchi à cela et je pense que nous devons changer le comportement de sauvegarde afin que toujours le chemin complet (comme indiqué sur la ligne de commande) soit enregistré. C'est ce que fait tar , et cela fonctionne très bien. Il s'agit malheureusement d'une relique d'une mauvaise décision de conception au début du développement de Restic.

+1 pour --store-full-path

Je déteste juste +1, mais je suis également très intéressé par la solution à ce bug. Avoir plusieurs installations en attente de restic, où ce bogue est malheureusement un showstopper.

Merci @ fd0 pour votre travail à ce sujet, je comprends que ce n'est pas facile de se détendre maintenant.

-1 pour --store-full-path . Je préférerais de beaucoup voir le chemin complet toujours dans la sauvegarde, puis avoir un --strip-components <N> pour retirer des pièces si vous n'en avez pas besoin au moment de la restauration. Cela signifie que toutes les données sont toujours disponibles dans la sauvegarde et si l'utilisateur supprime trop de composants du chemin au moment de la restauration et combine donc des sous-répertoires, cela devient une erreur utilisateur récupérable.

En ce qui concerne le préfixe du nom d'hôte à l'emplacement de sauvegarde, cela semble pouvoir être facilement fait à partir de la ligne de commande, car la plupart des gens savent à partir de quel hôte ils vont restaurer à l'avance :)

Étant donné que vous n'êtes pas encore la version 1.0, je vote que, si un changement radical doit être apporté pour obtenir la solution idéale, allez-y et faites-le le plus tôt possible.

@mholt Je suis d'accord, je travaille déjà là-dessus. Comme je l'ai dit, cela est causé par une mauvaise décision de conception au début et doit être corrigé.

Hey @ fd0 - je viens de voir que 0.7 est sorti. Est-ce que c'est (et # 910 et # 909) sur la carte pour 0.7.1?

Peut-être pas pour 0.7.1, mais pour 0.8.0 environ. J'ai déjà commencé à y travailler. Peut-être un peu d'arrière-plan: Ceci est dû au code de l'archiveur, qui est le plus ancien code présent dans restic. Malheureusement (comme je commençais tout juste à apprendre Go en 2013/2014), le code de l'archiveur est très complexe et j'ai fait beaucoup d'erreurs de débutant (trop de concurrence, trop de canaux). Je m'inquiétais aussi des choses qui se sont révélées ne pas être un problème du tout, et j'ai oublié des choses qui sont devenues un problème (par exemple la gestion des index).

Donc, j'ai déjà commencé à réimplémenter complètement le code de l'archiveur, en utilisant la concurrence uniquement quand cela a du sens (c'est-à-dire en traitant des morceaux individuels) et en ne lisant pas 20 fichiers du disque en parallèle. Ce code inclut également la marche de répertoire appropriée et insérera les chemins complets dans le dépôt.

Heureusement, ce n'est vraiment que l'archiveur qui doit être touché, le reste du code continuera (grâce à la conception de restic et du repo) de fonctionner correctement.

ce changement affectera-t-il les référentiels existants et si oui, comment?

«affectant» en termes de «nouvelles sauvegardes auront une structure légèrement différente», oui, mais c'est à peu près tout. Aucun migrate ou quoi que ce soit nécessaire.

Ainsi, # 1209 a été fusionné et améliore la situation en détectant les conflits de noms et en les résolvant (en les renommant), mais ce problème n'est toujours pas entièrement résolu. J'y travaille :)

@ fd0 Une idée du moment où nous pourrions nous attendre à des instantanés contenant le chemin d'origine complet? Nous travaillons actuellement sur l'automatisation des sauvegardes et des restaurations à l'aide de restic.

Lors de l'automatisation de la restauration, il est essentiel d'avoir le chemin source intact.

Si j'ai un serveur avec deux répertoires de `` données '' en cours de sauvegarde (et ce n'est pas théorique, nous avons un certain nombre de serveurs avec des répertoires de `` données '' Confluence et JIRA qui doivent être sauvegardés) - le processus de restauration doit savoir lequel Le répertoire de données appartient à Confluence et quel répertoire de données appartient à JIRA. Un nom comme «data» et «data-1» ne le coupe évidemment pas ici.

Je pense que la meilleure solution de contournement pour le moment est de sauvegarder les répertoires de données dans des instantanés séparés et de les étiqueter avec «JIRA» ou «Confluence»?

Il n'y a pas de calendrier, désolé.

Je pense que la meilleure solution de contournement pour le moment est de sauvegarder les répertoires de données dans des instantanés séparés et de les étiqueter avec «JIRA» ou «Confluence»?

Oui, mais par # 1225, vous ne pourrez pas les fusionner facilement en un seul dépôt plus tard.

Concernant l'option --store-full-path : rsync a cette option: -R , --relative .
Peut-être utiliser le même nom d'option pour restic?

Pour les sauvegardes du système complet, j'ai décrit une solution de contournement ici: https://forum.restic.net/t/full-system-restore/126/8 Ce n'est pas joli mais fera le travail jusqu'à ce que # 1494 soit terminé.

Ce bug m'a un peu inquiété, mais je ne peux pas le reproduire en 0.8.3 avec les étapes fournies. Est-ce toujours un problème ouvert?

Oui, malheureusement, c'est toujours un problème.

Hm, je ne peux pas reproduire le problème, donc je ne sais pas ce que je fais différemment. J'ai joint mon script de test.

test_restic_549.zip

Vous pouvez le reproduire comme ceci:

$ mkdir dir1/subdir
$ echo foo > dir1/subdir/foo

$ mkdir dir2/subdir
$ echo bar > dir2/subdir/bar

$ restic backup dir1/subdir dir2/subdir
password is correct
scan [/home/user/dir1/subdir /home/user/dir2/subdir]
scanned 2 directories, 2 files in 0:00
/home/user/dir2: name collision for "subdir", renaming to "subdir-1"
[...]
snapshot f6138d06 saved

Pour les deux sous-répertoires, restic utilise le nom de base du sous-répertoire comme répertoire de niveau supérieur dans le dépôt, donc pour dir1/subdir et dir2/subdir c'est à la fois subdir , c'est ce qui cause la collision.

La liste du dernier instantané le montre:

$ restic ls latest
password is correct
snapshot f6138d06 of [/home/user/dir1/subdir /home/user/dir2/subdir] at 2018-03-21 20:38:33.58232292 +0100 CET):
/subdir
/subdir/foo
/subdir-1
/subdir-1/bar

Dans votre cas de test, les noms de base de $TESTDIR/dir1 et $TESTDIR/dir2 sont différents ( dir1 vs dir2 ) donc le bogue ne se produit pas.

À partir des notes de publication de la version 0.9:

La première sauvegarde avec cette version de restic entraînera probablement la relecture de tous les fichiers localement, donc cela prendra beaucoup plus de temps. La prochaine sauvegarde après cela sera à nouveau rapide.

Je veux juste vous donner quelques statistiques:

première sauvegarde:

-------------------------------------------------------------
Start: Do 24. Mai 05:15:01 CEST 2018
437 snapshots

Files:           0 new,     0 changed, 40524 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 40524 files, 14.805 GiB in 1:38
snapshot f724ff21 saved

Files:         556 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 556 files, 914.493 GiB in 2:15:29
snapshot 3c0e0f1b saved

Files:       11570 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 11570 files, 66.044 GiB in 16:21
snapshot 312fd29c saved

Files:        2309 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 2309 files, 163.332 GiB in 24:13
snapshot 2baab573 saved

Files:         312 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 312 files, 1.503 TiB in 4:48:23
snapshot 02dfe40c saved

Files:       743172 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      84.927 MiB

processed 743172 files, 89.131 GiB in 2:48:59
snapshot dcee3e70 saved

Files:         441 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 441 files, 727.575 GiB in 1:56:36
snapshot 676adc45 saved
End:   Do 24. Mai 17:46:46 CEST 2018
Duration: 12h:31m:45s
-------------------------------------------------------------

deuxième:

-------------------------------------------------------------
Start: Fr 25. Mai 05:15:01 CEST 2018
444 snapshots

Files:           0 new,     0 changed, 40524 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 40524 files, 14.805 GiB in 1:42
snapshot 9c7cf320 saved

Files:           0 new,     0 changed,   556 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 556 files, 914.493 GiB in 0:15
snapshot 533e2155 saved

Files:           0 new,     0 changed, 11570 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 11570 files, 66.044 GiB in 0:17
snapshot 1c1235c3 saved

Files:           0 new,     0 changed,  2309 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 2309 files, 163.332 GiB in 0:13
snapshot d5ef168d saved

Files:           0 new,     0 changed,   312 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 312 files, 1.503 TiB in 0:16
snapshot 76e94946 saved

Files:         292 new,     0 changed, 743172 unmodified
Dirs:            0 new,     2 changed,     0 unmodified
Added:      32.790 MiB

processed 743464 files, 89.163 GiB in 1:06
snapshot 12fa66e8 saved

Files:           0 new,     0 changed,   441 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 441 files, 727.575 GiB in 0:15
snapshot ab2d29bb saved
End:   Fr 25. Mai 05:19:12 CEST 2018
Duration: 0h:4m:11s
-------------------------------------------------------------

donc beaucoup plus longtemps, c'est beaucoup plus long :-)
Continuez ce bon travail! 👍

@ fd0 , travail formidable! Merci beaucoup! Votre outil de sauvegarde est devenu mon préféré pour toutes mes sauvegardes hors site (en utilisant b2) :-)