Obrigado por relatar esse problema, acho que é um bug.

Provavelmente acontecerá sempre que os diretórios de nível superior tiverem o mesmo nome. Porque o caminho completo não é restaurado, apenas o diretório de nível superior.

A solução é reconstruir o caminho completo na restauração e restaurar cada árvore no caminho completo. Portanto, o caminho resultante seria /tmp/restic/tmp/restic/FILESNEW0{1,2}/Dir01/ . Eu acho que é aceitável.

O patch precisa ser implementado como parte da restauração?
Ou talvez tenha que ser feito durante o backup, construindo uma árvore de nível superior diferente que inclua os componentes do caminho completo?

Também suspeito que seja esse o caso. No momento, o restic funciona assim:

Quando chamado de restic backup A/foo B/foo ele cria uma estrutura em árvore no repositório que se parece com esta:

├── foo
└── foo

Portanto, apenas o último componente do caminho dos argumentos para o comando backup é usado, o que causa um problema ao restaurar esse instantâneo.

Para corrigir isso, proponho implementar o mesmo comportamento de tar , o que, neste caso, criaria a seguinte árvore:

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

Isso exigirá algum trabalho na parte do arquivo do restic. Não acho que precisaremos tocar na restauração.

588 Eu relatei a mesma coisa. Mas aquele tem um caso de teste que você pode usar.

@ fd0 Proponho incluir também uma opção (--store-full-path) para fazer backup, onde armazena explicitamente o caminho 'real' completo do destino de backup.

O raciocínio é que, no caso do tar e com várias outras ferramentas de backup, você pode obter uma pequena árvore de restauração complicada. Embora este seja um bom padrão, eu pessoalmente gostaria que minhas restaurações lembrassem todo o layout do sistema de arquivos original para backups de host. (Melhor ainda se a restauração também pudesse prefixar o nome do host para o local de restauração)

@trbs Acho que o padrão precisa ser armazenar caminhos completos, com uma opção para o caso especial de usar caminhos relativos. A razão é que os caminhos rel podem produzir um comportamento inesperado ou indefinido, mas os abdominais não. Se você quiser solicitar prefixos ou alguma outra forma de alteração de caminho, sugiro que seja um problema totalmente separado.

Já pensei sobre isso e acho que precisamos mudar o comportamento do backup para que sempre o caminho completo (conforme fornecido na linha de comando) seja salvo. Isso é o que tar faz, e funciona muito bem. Infelizmente, isso é um resquício de uma má decisão de design no início do desenvolvimento do Restic.

+1 para --store-full-path

Odeio apenas +1, mas também estou muito interessado na solução para esse bug. Têm várias instalações pendentes do restic, onde este bug infelizmente é um obstáculo.

Obrigado @ fd0 por seu trabalho nisso, entendo que não seja fácil descomprimir agora.

-1 para --store-full-path . Eu preferiria ver o caminho completo sempre indo no backup e ter um --strip-components <N> para retirar as peças se você não precisar delas no momento da restauração. Isso significa que os dados completos estão sempre disponíveis no backup e se o usuário remover muitos componentes do caminho no momento da restauração e, portanto, combinar subdiretórios, isso se tornará um erro recuperável do usuário.

Quanto a prefixar o nome do host para o local do backup, parece que pode ser feito facilmente a partir do cmdline, já que a maioria das pessoas sabe de qual host eles vão restaurar de antemão :)

Dado que você ainda não é 1.0, eu voto que, se uma alteração significativa tiver que ser feita para a correção ideal, vá em frente e faça isso mais cedo ou mais tarde.

@mholt : Concordo, já estou trabalhando nisso. Como eu disse, isso é causado por uma má decisão de design no início e precisa ser corrigido.

Ei @ fd0 - acabei de ver que o 0.7 foi lançado. Isto está (e # 910 e # 909) no mapa para 0.7.1?

Talvez não para 0.7.1, mas para 0.8.0 ou assim. Já comecei a trabalhar nisso. Talvez um pouco de fundo: Isso é causado pelo código do arquivador, que é o código mais antigo presente no restic. Infelizmente (como eu estava apenas começando a aprender em 2013/2014), o código do arquivador é muito complexo e eu cometi muitos erros de iniciante (muita simultaneidade, muitos canais). Também me preocupei com coisas que acabaram não sendo um problema, e esqueci as coisas que se tornaram um problema (por exemplo, o manuseio do índice).

Portanto, já comecei a reimplementar o código do arquivador completamente, usando simultaneidade apenas quando faz sentido (ou seja, processando partes individuais) e não lendo 20 arquivos do disco em paralelo. Este código também inclui uma caminhada de diretório adequada e irá inserir os caminhos completos no repo.

Felizmente, este é realmente apenas o arquivador que precisa ser alterado, o resto do código (graças ao design do restic e do repo) continuará a funcionar bem.

essa mudança afetará os repositórios existentes e, em caso afirmativo, como?

"afetando" em termos de "novos backups terão uma estrutura ligeiramente diferente", sim, mas isso é tudo. Não migrate ou qualquer coisa necessária.

Portanto, # 1209 foi mesclado e melhora a situação ao detectar conflitos de nomes e resolvê-los (renomeando), mas esse problema ainda não foi totalmente resolvido. Eu estou trabalhando nisso :)

@ fd0 Alguma ideia de quando podemos esperar instantâneos que contenham o caminho original completo? No momento, estamos trabalhando para automatizar backups e restaurações usando o restic.

Ao automatizar a restauração, é essencial ter o caminho de origem intacto.

Se eu tiver um servidor com dois diretórios de 'dados' em backup (e isso não é teórico, temos vários servidores com diretórios de 'dados' do Confluence e JIRA que precisam de backup) - o processo de restauração precisa saber quais O diretório de dados pertence ao Confluence e qual diretório de dados pertence ao JIRA. Um nome como 'dados' e 'dados-1' obviamente não cabe aqui.

Acho que a melhor solução por enquanto é fazer backup dos diretórios de dados em instantâneos separados e marcá-los com 'JIRA' ou 'Confluence'.

Não há cronograma, desculpe.

Acho que a melhor solução por enquanto é fazer backup dos diretórios de dados em instantâneos separados e marcá-los com 'JIRA' ou 'Confluence'.

Sim, mas de acordo com o número 1225, você não poderá mesclá-los facilmente em um repo posteriormente.

Com relação à opção --store-full-path : rsync tem esta opção: -R , --relative .
Talvez use o mesmo nome de opção para restic?

Para backups de todo o sistema, descrevi uma solução alternativa aqui: https://forum.restic.net/t/full-system-restore/126/8 Não é bonito, mas fará o trabalho até que # 1494 esteja pronto.

Este bug me preocupou um pouco, mas não consigo reproduzi-lo no 0.8.3 com os passos fornecidos. Este ainda é um problema em aberto?

Sim, infelizmente, isso ainda é um problema.

Hm, de alguma forma não consigo reproduzir o problema, então não tenho certeza do que estou fazendo diferente. Anexei meu script de teste.

test_restic_549.zip

Você pode reproduzi-lo assim:

$ 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

Para os dois subdiretórios, o restic usa o nome de base do subdiretório como o diretório de nível superior no repo, então para dir1/subdir e dir2/subdir são ambos subdir , isso é o que causa a colisão.

Listar o instantâneo mais recente mostra:

$ 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

Em seu caso de teste, os nomes de base de $TESTDIR/dir1 e $TESTDIR/dir2 são diferentes ( dir1 vs. dir2 ), então o bug não ocorre.

Das notas de lançamento da versão 0.9:

O primeiro backup com esta versão do restic provavelmente resultará na releitura de todos os arquivos localmente, por isso demorará muito mais. O próximo backup depois disso será rápido novamente.

Eu só quero dar a você algumas estatísticas:

primeiro backup:

-------------------------------------------------------------
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
-------------------------------------------------------------

o segundo:

-------------------------------------------------------------
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
-------------------------------------------------------------

muito mais tempo, significa muito mais tempo :-)
Continue com o ótimo trabalho! 👍

@ fd0 , trabalho incrível! Muito obrigado! Sua ferramenta de backup se tornou minha favorita para todos os meus backups externos (usando b2) :-)