이 문제를 신고 해 주셔서 감사합니다. 버그라고 생각합니다.

아마도 최상위 디렉토리가 같은 이름을 가질 때마다 발생할 것입니다. 전체 경로는 복원되지 않으므로 최상위 디렉토리 만 복원됩니다.

해결책은 복원시 전체 경로를 재구성하고 각 트리를 전체 경로로 복원하는 것입니다. 따라서 결과 경로는 /tmp/restic/tmp/restic/FILESNEW0{1,2}/Dir01/ . 나는 그것이 받아 들여질 것이라고 생각한다.

복원의 일부로 패치를 구현해야합니까?
또는 전체 경로 구성 요소를 포함하는 다른 최상위 트리를 작성하여 백업 중에 수행해야 할 수도 있습니다.

나는 또한 이것이 사실이라고 생각합니다. 현재 restic은 다음과 같이 작동합니다.

restic backup A/foo B/foo 로 호출되면 다음과 같은 저장소에 트리 구조가 생성됩니다.

├── foo
└── foo

따라서 backup 명령에 대한 인수의 마지막 경로 구성 요소 만 가져 오므로 이러한 스냅 샷을 복원 할 때 문제가 발생합니다.

이 문제를 해결하기 위해 tar 와 동일한 동작을 구현할 것을 제안합니다.이 경우 다음 트리를 생성합니다.

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

이것은 restic의 아카이버 부분에서 약간의 작업이 필요합니다. 복원을 전혀 손댈 필요가 없다고 생각합니다.

588 나도 같은 것을보고했다. 하지만 여기에는 사용할 수있는 테스트 케이스가 있습니다.

@ fd0 백업 대상의 전체 '실제'경로를 명시 적으로 저장하는 백업 옵션 (--store-full-path)도 포함 할 것을 제안합니다.

그 이유는 tar의 경우와 다른 여러 백업 도구를 사용하여 약간 복잡한 복원 트리를 얻을 수 있기 때문입니다. 이것은 정상적인 기본값이지만 복원이 호스트 백업을위한 원래 파일 시스템의 전체 레이아웃과 유사하다면 개인적으로 원합니다. (복원이 복원 위치에 호스트 이름 접두사를 붙일 수도 있다면 더 좋습니다)

@trbs 나는 기본값이 상대 경로를 사용하는 특수한 경우 스위치와 함께 전체 경로를 저장해야한다고 생각합니다. rel 경로는 예상치 못한 또는 정의되지 않은 동작을 생성 할 수 있지만 abs는 그렇지 않기 때문입니다. 접두사 또는 다른 형태의 경로 맹 글링을 요청하려면 완전히 별개의 문제라고 제안합니다.

나는 이것에 대해 생각했고 항상 전체 경로 (명령 줄에 주어진)가 저장되도록 백업 동작을 변경해야한다고 생각합니다. 이것이 tar 역할이며 매우 잘 작동합니다. 이것은 안타깝게도 개발 초기에 잘못된 설계 결정의 유물입니다.

--store-full-path +1

+1 만 싫어하지만이 버그에 대한 해결책에도 관심이 많습니다. 이 버그는 안타깝게도 눈에 띄는 몇 가지 보류중인 restic 설치가 있습니다.

이것에 대한 귀하의 작업에 대해 @ fd0 에게 감사드립니다. 지금 긴장을 풀기가 쉽지 않다는 것을 이해합니다.

-1 : --store-full-path . 차라리 전체 경로가 항상 백업에 포함 된 다음 복원시 필요하지 않은 경우 --strip-components <N> 를 사용하여 부품을 제거하는 것이 좋습니다. 즉, 백업에서 항상 전체 데이터를 사용할 수 있으며 사용자가 복원시 경로에서 너무 많은 구성 요소를 제거하여 하위 디렉터리를 결합하면 복구 가능한 사용자 오류가됩니다.

호스트 이름을 백업 위치에 접두사로 지정하는 것과 관련하여 대부분의 사람들이 미리 복원 할 호스트를 알고 있기 때문에 cmdline에서 쉽게 수행 할 수 있습니다. :)

당신이 아직 1.0이 아니라는 점을 감안할 때, 이상적인 수정을 위해 중요한 변경을해야한다면 나중에보다는 빨리 진행하도록하겠습니다.

@mholt 동의합니다. 이미 작업 중입니다. 내가 말했듯이 이것은 초기에 잘못된 설계 결정으로 인해 발생하며 수정해야합니다.

안녕하세요 @ fd0- 방금 0.7이 릴리스되었음을 확인했습니다. 0.7.1의지도에이 (및 # 910 및 # 909)가 있습니까?

0.7.1이 아니라 0.8.0 정도일 수 있습니다. 나는 이미 작업을 시작했습니다. 약간의 배경 지식 : 이것은 restic에 존재하는 가장 오래된 코드 인 아카이버 코드로 인해 발생합니다. 불행히도 (2013/2014에서 Go back을 배우기 시작했을 때) 아카이버 코드는 매우 복잡하고 초보자 실수를 많이했습니다 (너무 많은 동시성, 너무 많은 채널). 나는 또한 전혀 문제가되지 않는 것으로 판명 된 것들에 대해 걱정하고 문제가 된 것 (예 : 인덱스 처리)을 간과했습니다.

그래서 저는 이미 합리적 일 때만 (즉, 개별 청크 처리) 동시성을 사용하고 디스크에서 20 개의 파일을 병렬로 읽지 않고 아카이버 코드를 완전히 다시 구현하기 시작했습니다. 이 코드는 또한 적절한 디렉토리 이동을 포함하며 전체 경로를 저장소에 삽입합니다.

다행히도 이것은 실제로 만져야 할 아카이버이며 나머지 코드는 (restic 및 repo의 디자인 덕분에) 계속 잘 작동합니다.

이 변경 사항은 기존 저장소에 영향을 미치며 그렇다면 어떻게해야합니까?

"새 백업은 구조가 약간 다를 것입니다"라는 측면에서 "영향을 미친다". 네, 그게 다입니다. migrate 또는 필요한 것이 없습니다.

따라서 # 1209가 병합되었으며 이름 충돌을 감지하고 이름을 변경하여 해결하여 상황을 개선했지만이 문제는 아직 완전히 해결되지 않았습니다. 나는 그것에 노력하고있다 :)

@ fd0 전체 원본 경로가 포함 된 스냅 샷을 언제 기대할 수 있을지 생각하십니까? 현재 restic을 사용하여 백업 및 복원을 자동화하는 작업을 진행 중입니다.

복원을 자동화 할 때 원본 경로를 그대로 유지하는 것이 중요합니다.

두 개의 'data'디렉토리가 백업되는 서버가있는 경우 (이론적이지 않은 경우 백업해야하는 Confluence 및 JIRA 'data'디렉토리가있는 서버가 여러 대 있습니다)-복원 프로세스는 다음을 알아야합니다. 데이터 디렉토리는 Confluence에 속하고 어떤 데이터 디렉토리는 JIRA에 속하는지. 'data'및 'data-1'과 같은 이름은 분명히 여기에서 잘라 내지 않습니다.

현재 가장 좋은 해결 방법은 별도의 스냅 샷에 데이터 디렉터리를 백업하고 'JIRA'또는 'Confluence'태그를 지정하는 것입니다.

타임 라인이 없습니다. 죄송합니다.

현재 가장 좋은 해결 방법은 별도의 스냅 샷에 데이터 디렉터리를 백업하고 'JIRA'또는 'Confluence'태그를 지정하는 것입니다.

예,하지만 # 1225에 따라 나중에 쉽게 하나의 리포지토리로 병합 할 수 없습니다.

옵션 --store-full-path : rsync 에는 -R , --relative 있습니다.
restic에 동일한 옵션 이름을 사용할 수 있습니까?

전체 시스템 백업의 경우 여기에 해결 방법을 설명했습니다. https://forum.restic.net/t/full-system-restore/126/8 예쁘지는 않지만 # 1494가 완료 될 때까지 작업을 수행합니다.

이 버그는 저를 약간 걱정했지만 제공된 단계로 0.8.3에서 재현 할 수 없습니다. 여전히 미해결 문제입니까?

예, 안타깝게도 여전히 문제입니다.

흠, 나는 어떻게 든 문제를 재현 할 수 없으므로 내가 뭘 다르게하고 있는지 확실하지 않습니다. 테스트 스크립트를 첨부했습니다.

test_restic_549.zip

다음과 같이 재현 할 수 있습니다.

$ 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

두 개의 하위 디렉토리의 경우 restic은 하위 디렉토리의 기본 이름을 저장소의 최상위 디렉토리로 사용하므로 dir1/subdir 및 dir2/subdir 모두 subdir 입니다. 충돌.

최신 스냅 샷을 나열하면 다음과 같이 표시됩니다.

$ 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

테스트 케이스에서 $TESTDIR/dir1 및 $TESTDIR/dir2 의 기본 이름이 다르므로 ( dir1 대 dir2 ) 버그가 발생하지 않습니다.

버전 0.9의 릴리스 정보에서 :

이 restic 릴리스를 사용한 첫 번째 백업은 모든 파일을 로컬에서 다시 읽을 수 있으므로 시간이 훨씬 오래 걸립니다. 그 후의 다음 백업은 다시 빨라집니다.

몇 가지 통계를 제공하고 싶습니다.

첫 번째 백업 :

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

두번째 것:

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

그래서 훨씬 더 길다는 것은 훨씬 더 길다는 것을 의미합니다 :-)
앞으로도 힘써주세요! 👍

@ fd0 , 멋진 작업입니다! 정말 고마워! 귀하의 백업 도구는 모든 오프 사이트 백업 (b2 사용)에서 제가 가장 좋아하는 도구가되었습니다. :-)