정말 좋을 것입니다.

또한 무의식적으로 포함된 민감한 데이터를 제거할 수 있습니다.

이것은 좋은 기능이 될 것입니다!

이 아이디어에 대한 개발자의 피드백이 있습니까? 아주 좋을 것입니다. 예를 들어, git checkouts에서 빌드한 프로그램이 엄청난 바이너리(거의 100MB)를 생성하고 있다는 것을 방금 발견했으며 이러한 바이너리가 Restic 백업에 불필요하게 백업되고 있습니다. 저는 아직 테스트 단계에 있기 때문에 매우 오랫동안 Restic을 사용하지 않았습니다. 따라서 문제의 이전 스냅샷을 삭제하는 것은 문제가 되지 않습니다. 그러나 이 문제는 매우 쉽게 발생할 수 있으며 모든 스냅샷을 잊어버리는 것 외에는 장기적인 해결책이 있는 것이 좋습니다.

모든 스냅샷을 복원하고, 원하지 않는 파일을 삭제하고, 날짜를 수동으로 설정하여 스냅샷을 다시 백업하는 스크립트를 작성하는 것이 가능할 것이라고 생각하지만 분명히 매우 오랜 시간이 걸릴 것입니다. Restic이 기본적으로 이것을 할 수 있다면 좋을 것입니다.

감사 해요.

이에 대한 여러 유효한 사용 사례가 있다고 생각합니다. 있으면 정말 좋은 기능인 것 같습니다. 언젠가는 직접 사용하게 될 것 같아요.

아마도 구현 노력을 실제로 변경하지는 않지만 UX 관점에서 이것은 완전히 새로운 명령을 추가하는 대신 backup 명령을 확장하여 다소 낮은 프로필로 수행될 수 있습니다.

restic backup [flags] FILE/DIR/SNAPSHOT [FILE/DIR/SNAPSHOT] ...

따라서 스냅샷을 수정하는 명령을 제공하는 대신 기존 스냅샷 ID를 기반으로 새 백업을 만들 수 있습니다. 파일 삭제는 제외 규칙을 사용하여 수행됩니다.
restic backup 에 대한 모든 문서는 기본적으로 "재사용"될 수 있습니다(즉, 이 새 기능에 대해 거의 아무것도 추가할 필요가 없음).

@dnnr 참조 https://github.com/restic/restic/issues/1550#issuecomment -358536554

그러나 나는 여기에서 당신을 따르지 않습니다. 이전 스냅샷에서 데이터를 제거하는 것은 확실히 별개의 작업이며 자체 명령이 있어야 합니다. 다음과 같은 것:

restic purge --snapshots abcd1234 deadbeef --paths /path/to/file1 /path/to/file2

그리고 --snapshots 는 모든 스냅샷(또는 --tag 이 지정된 모든 스냅샷)에서 작동하려면 all 키워드를 허용해야 합니다. 그리고 명령은 yes 를 입력하여 확인이 필요할 것입니다.

주어진 패턴과 일치하는 경로를 삭제하는 --patterns 옵션을 갖는 것도 좋습니다.

purge 는 명령 이름에 대한 한 가지 가능성입니다. erase 뿐만 아니라 delete 도 좋은 선택이 될 수 있습니다. 무엇을 선택하든 작업이 데이터를 영구적으로 삭제 한다는 것을 분명히 해야 합니다. 이것은 우리가 말하는 백업 소프트웨어이며 위험한 작업은 명확하고 명시적이어야 하며 확인이 필요합니다.

글쎄, 나는 그것이 명백하다고 생각했기 때문에 나중에 소스 스냅샷을 삭제하는 단계를 생략했습니다( forget , prune ).

제 생각에는 이렇게 하면 기존 명령의 기능과 겹치는 새 명령을 추가하는 것보다 명령 집합을 더 직교적으로 유지할 수 있습니다. 현재 backup , forget 및 prune 있으며 모두 완전히 별도의 작업을 수행합니다. 설명하는 대로 purge 추가하면 변경됩니다. 내 제안은 그렇지 않습니다.

하나의 파일 작업을 제안하기 때문에 이름을 바꿀 수 있으면 좋을 것입니다.

나는 이러한 유형의 작업에 대해 별개의 명령이 있어야 한다는 @alphapapa의 의견에 동의합니다. 그것은 purge 일 수 있으며, 그것은 나쁜 이름이 아닙니다. 그러면 @alvarolm이 이미 파일 이름을 바꿀 수 있다고 제안한 것과 같이 미래에 다른 유사한 작업이 있을 수 있습니다.

이러한 이유로 rewrite 명령을 추가하는 것이 이 경우 가장 좋은 대안이라고 생각하고 해당 명령에 --purge 및 --rename 옵션이 포함되도록 합니다. 구현하다. 따라서 최종 명령은 restic -r foo rewrite --purge snap1,snap2 path1 path2 ... 및 restic -r foo rewrite --rename snap1,snap2 pathFrom pathTo 입니다.

즉, 이름 바꾸기가 구현하기에 합당한 것인지 완전히 확신할 수는 없습니다. 백업 프로그램이 의미하는 것과는 거리가 꽤 멉니다. 하지만 확실합니다.

삭제 항목을 백업 명령의 일부로 포함하는 것은 현명하지 않다고 생각합니다. 한 가지 관점에서는 백업에 대한 작업을 수행하는 것이 괜찮다고 주장할 수 있습니다. 그러나 이러한 근거로 정리 및 잠금 해제 및 잊어버리기 작업도 백업 명령의 일부여야 합니다. 나는 그것이 의미가 없다고 생각하므로 실제로 별도의 작업/명령(예: rewrite 또는 purge 이어야 한다고 생각합니다.

@dnnr

글쎄, 나는 그것이 명백하다고 생각했기 때문에 나중에 소스 스냅샷을 삭제하는 단계를 생략했습니다.

확실히 명확하지 않습니다. 또한 사용자가 변경되어 잊어버려야 하는 스냅샷 ID를 추적해야 하는 것보다 사용자를 위해 Restic이 처리하는 것이 더 좋습니다. 이는 사용자가 저장소의 모든 스냅샷을 다시 작성하는 경우 상당한 부담이 될 것입니다.

제 생각에는 이렇게 하면 기존 명령의 기능과 겹치는 새 명령을 추가하는 것보다 명령 집합을 더 직교적으로 유지할 수 있습니다.

무슨 말인지 이해가 안 돼요. 반대의 경우입니다. 이 제안된 제거/삭제/재작성 명령은 backup 와 전혀 겹치지 않으며 기존 스냅샷에서 데이터를 삭제합니다 . 그것은 기존의 명령에 직교한다.

현재 백업, 잊어 버리기 및 정리가 있으며 모두 완전히 별도의 작업을 수행합니다. 설명하는 것처럼 퍼지를 추가하면 변경됩니다. 내 제안은 그렇지 않습니다.

여기서도 무슨 생각을 하고 있는지 모르겠다. purge 는 백업, 삭제 및 정리와 완전히 별개입니다.

• backup : 주어진 경로의 새 스냅샷을 생성합니다.
• forget : 기존 스냅샷을 제거합니다.
• prune : 잊혀진 스냅샷에서 사용하지 않는 Blob을 가비지 수집합니다.
• purge / rewrite /whatever: 기존 스냅샷에서 파일을 삭제합니다.

backup 명령이 두 가지 모드로 작동하도록 제안합니다. 하나는 데이터를 백업하고 다른 하나는 데이터를 삭제합니다.

@rawtaz 예, rewrite 는 기존 스냅샷을 말 그대로 다시 쓰기 때문에 좋은 제안입니다. 다음과 같은 UI를 제안합니다.

restic --repo REPO rewrite --snapshots abcd1234 deadbeef --delete /path/to/file1 "*.unwanted-file-extension-glob"

스크립트에서 명령줄을 훨씬 더 복잡하게 만들기 때문에 쉼표를 구분 기호로 사용하지 않는 것이 좋습니다.

백업: 주어진 경로의 새 스냅샷을 생성합니다.

어떤 의미에서 스냅샷의 내용을 수정하면 새 스냅샷 이 생성됩니다(이전과 동일한 스냅샷이 아니기 때문에). 기존 커밋을 기반으로 새 커밋을 생성하는 git commit --amend 생각해 보세요. 이 티켓은 Git을 재창조하는 방향으로 빠르게 이동하는 것 같기 때문에 이 비유는 실제로 매우 적합합니다.

백업 명령이 데이터를 백업하는 모드와 데이터를 삭제하는 모드의 두 가지 모드로 작동하도록 제안하고 있습니다.

나는 그런 말을 하지 않았다. 왜 그럴까요? forget 및 prune 있으며, 이는 물건을 제거하는 데 완벽합니다.

어떤 의미에서 스냅샷의 내용을 수정하면 새 스냅샷이 생성됩니다(이전과 동일한 스냅샷이 아니기 때문에). 기존 커밋을 기반으로 새 커밋을 생성하는 git commit --amend를 생각해 보세요. 이 티켓은 Git을 재창조하는 방향으로 빠르게 이동하는 것 같기 때문에 이 비유는 실제로 매우 적합합니다.

네가 옳아. 그러나 동시에 Restic은 git이 아니며 작동하기 위해 콘텐츠 기반 주소 지정에 대한 지식을 요구하도록 설계되지 않았습니다. 그것이 내부에서 어떻게 작동하는지에 관계없이 사용자에게 제안하는 명령은 새 스냅샷을 만드는 것이 아니라 기존 스냅샷을 수정하는 것으로 간주되어야 하므로 별개의 명령이어야 한다고 생각합니다.

나는 그런 말을 하지 않았다. 왜 그럴까요?

글쎄, 당신은 말했다 :

UX 관점에서 이것은 완전히 새로운 명령을 추가하는 대신 백업 명령을 확장하여 다소 낮은 프로필로 수행될 수 있습니다.

더 자세히 설명해야 할 수도 있습니다.

무엇을 제거하기에 완벽하게 좋은 forget과 prune이 있습니다.

구체적으로 말해봅시다. forget 는 스냅샷을 제거하고 prune 는 얼룩을 제거합니다. 스냅샷 내에서 파일 을 제거하는 명령을 제안합니다. 별개의 명령이어야 합니다.

내 의견을 추가하고 싶습니다.

얼마나 많은 사람들이 이와 같은 것을 갖고 싶어하는지 피드백을 기반으로 리포지토리에서 스냅샷을 수정할 수 있는 방법을 갖는 것이 중요하다고 생각합니다.

명령은 backup 명령과 독립적이어야 합니다. 직교성 이유(매우 Go와 비슷함)뿐만 아니라 실용적인 고려 사항도 없습니다. backup 명령은 이미 충분히 복잡하므로 저는 다른 명령을 분리하고 싶습니다.

prune 와 유사하기 때문에 purge 라는 이름이 마음에 들지 않습니다. change 어떻습니까? 그러면 restic backup , restic restore 및 restic change 있습니다.

지원되는 명령 작업에 대해 다음 요청을 보았습니다.

• 파일 삭제(예: --delete
• 파일 이름 바꾸기(예: --rename

전자는 정확히 이 문제(원래)에 관한 것이지만 파일 이름을 바꾸는 사용 사례가 실제로 있습니까?

change 는 내용을 수정하는 것보다 뭔가를 꺼내서 넣는 것처럼 들립니다.

repo/backup/snapshot이 버킷이라고 상상해보십시오. 변경은 양동이에서 무언가를 집어 들고 약간 수정하고 다시 넣는 것이 아니라 양동이 자체를 다른 것으로 바꾸거나, 꺼내서 다른 것을 넣는 것과 같습니다.

아마도 일부 영어/미국인은 어느 것이 더 적절한지 알고 있을 것입니다. :) 그것은 언어학으로 요약됩니다.

흠, 그럼 modify ?

modify 가 change 보다 확실히 좋습니다. 따라서 지금까지 제안된 것 중 rewrite 또는 modify 중 하나입니다. 다른 분들은 어떻게 생각하시는지 궁금합니다 :)

이것이 파일 삭제에 관한 것이라면 forget 명령이 스냅샷 및 파일과 함께 작동하도록 향상시키는 것이 합리적입니까? 아니면 너무 복잡할까요?

이 새로운 기능이 삭제 및 이름 변경(또는 다른 것)에 관한 것이라면 저는 modify 투표할 것입니다.

입력 해 주셔서 감사합니다

나는 당신이 이름을 바꾸거나 삭제할 때 forget 하지 않는다고 생각합니다(적어도 전자의 경우는 아닙니다).

IMHO "rewrite"는 의미를 가장 잘 전달합니다.

forget 명령도 매우 복잡합니다. 도움이 된다면 추가하지 않겠습니다 ;)

그것을 호출, 별도의 명령이 될 거라면 modify 가 될 것이다 나의 마음에 드는뿐만 아니라 (I 좋겠 또한 같은 modify-snapshot 가 다소 긴 경우에도). 또한 모든 종류의 수정 파일 작업(이름 변경, 추가)에 적합한 위치에 충분히 일반적입니다. 그러나 나는 여전히 파일을 제거하는 것 외에는 기능 크리프의 냄새가 강하다고 생각합니다.

그건 그렇고, 나는 restic이 배관 명령과 함께 Git이 가지고 있는 것과 유사한 명령 범주의 이점을 얻을 것이라고 생각합니다. 현재 restic -h 는 모든 명령을 어휘 순서로 나열하고 저수준 명령(예: cat , list , "일반" 사용자에게는 절대 필요하지 않음)과 기본 상위 수준 명령.

update 고려할 수도 있습니다.

rewrite 경우 +1 , 멋진 Orwellian 고리가 있습니다. :-)

alter
discard
evict
expel
expunge
extrude
oust
...
nuke ? 😄

새로운 edit 명령을 제안하고 싶습니다. 이 문제에 대한 모든 피드백을 바탕으로 edit 하나 또는 여러 스냅샷에 대해 여러 작업을 수행하게 될 수 있습니다.

당분간은 다음과 같을 수 있습니다.

$ restic edit 40dc1520 remove dir/file

미래에는 여러 스냅샷(스냅샷 ID 또는 날짜 범위의 입력 목록)에서 하나의 파일 삭제를 구현할 수 있습니다.

편집 컨텍스트의 다른 명령은 다음과 같을 수 있습니다.

• rename 파일 및 폴더 이름 바꾸기
• move 변경되었을 수 있는 파일/디렉토리 구조 수정

하나 이상의 스냅샷에서 이러한 작업을 실행할 수 있도록 하는 것이 중요하다고 생각합니다(ID 또는 여러 날짜 또는 범위 기준).

백업된 데이터로 얼마나 많은 restic을 수행할 수 있는지 아직 확실하지 않습니다. 내 말은, 그것은 특정 시점에서 사물이 어떻게 생겼는지 보존하기 위해 데이터를 백업하기 위한 것입니다. NAS용이 아닙니다.

나는 특히 파일의 이름을 바꾸고 제거하는 유스 케이스에서 유효성을 보지 못합니다. 내 말은, 왜 로컬 디스크의 파일을 변경한 다음 파일 트리를 현재 데이터와 동기화된 상태로 유지하기 위해 백업을 만지작거릴까요? 그것은 나에게 의미가 없습니다. 그 사용 사례에 대해 자세히 설명해 주시겠습니까?

@rawtaz
내 생각 (거의) 정확히.

파일 제거의 유효성은 해당 규칙으로 이미 백업을 만든 후 제외 규칙에서 실수를 발견한 시나리오에 있다고 주장합니다. 따라서 파일 제거는 기본적으로 제외 규칙의 소급 적용 역할을 합니다. 이 스레드의 논쟁에 관계없이 모든 사람이 특정 사용 사례에 동의하는 것 같습니다.

그 이상의 작업(예: 이름 변경, 추가)에 대해서는 귀하의 의심을 공유합니다. 그것은 기능 크리프이며 백업 도구 인 IMHO의 범위가 아닙니다.

동의합니다. 스냅샷에서 파일을 삭제하는 것이 중요합니다. 의도하지 않은 파일을 실수로 백업하기가 매우 쉽기 때문입니다. 이는 보안 및 디스크 사용상의 이유로 종종 필요합니다. 이 기능이 있다는 것은 오래된 백업 데이터를 유지할 수 있는지 아니면 "아기를 목욕물과 함께 버려야" 하는지의 차이를 의미할 수 있습니다.

그러나 스냅샷 내에서 파일의 이름을 바꾸거나 이동하는 것은 좋은 생각이 아닙니다. 솔직히 말해서 이 작업을 수행할 수 있는 백업 소프트웨어에 대해 들어본 적이 없으며 이상한 기능처럼 보입니다. 사용자가 이것을 절대적으로 필요로 하는 경우 스냅샷을 복원하고 파일을 재정렬하고 명시적으로 설정된 날짜로 다시 백업하여 Restic 외부에서 구현할 수 있습니다(하지만 Restic이 절대 경로를 사용하기 시작하면 나중에 더 복잡해질 수 있음) .

물론 스냅샷에서 경로 제거 기능도 이런 방식으로 구현할 수 있지만 훨씬 더 필요할 것 같기 때문에 Restic에 포함시키는 것이 합리적이라고 생각합니다.

피드백을 주신 모든 분들께 감사드리며, 앞으로 나아갈 길은 명확합니다. 기존 스냅샷에서 파일을 제거할 수 있는 명령을 구현하는 것입니다. 명령의 이름은 우리가 거기에 도착했을 때 결정될 것입니다. 필요할 때 다른 사용 사례를 다시 살펴볼 수 있습니다.

여기에 더 많은 토론이 필요하지 않다고 생각합니다. 참여해주셔서 감사합니다!

명령 이름에 대한 제안: restic purge .

이 기능을 기대하고 있습니다. 감사 해요

@fd0
이 기능에 대한 업데이트가 있습니까? 사용하시면 좋을 것 같아요 :)
우리는 정부 환경에서 restic을 사용하고 있으며 백업에서 단일 파일 삭제가 필요합니다. 필요한 경우 일부 작업에 자금을 지원할 수 있습니다!

이것도 기대되네요! restic find 대한 기본 구조와 같은 것을 사용할 것을 제안합니다.

restic purge [flags] PATTERN

purge 를 host (-H) snapshots (-s) or paths (--path) 제한할 수 있는 곳

그러면 아마도 restic prune 가 나중에 실제 삭제를 수행할 것입니다.

이것은 예기치 않은 파일이 오류로 인해 백업되었을 때 매우 유용할 것입니다(문서 폴더의 큰 비디오 또는 일부 기밀 파일). 지금은 restic find 를 실행한 다음 파일이 포함된 모든 스냅샷을 삭제합니다. 파일이 리포지토리에 있는 경우(시간상) 바람직하지 않습니다.

감사 해요 !

업데이트가 없습니다. 죄송합니다. 문제가 발생하면 이 호를 구독하면 알림을 받게 됩니다.

대부분의 사람들은 백업의 메타데이터를 clone 할 수 있기를 원하지만 문제가 되는 파일은 스크래치 위치에 모두 복원할 필요 없이 제외할 수 있기를 원하는 것 같습니다. 백업을 복제한다는 아이디어는 특정 포인터를 제거할 수 있는 기능과 함께 메타데이터를 복사합니다.

이것이 사용 사례입니까?

• restic backup --exclude <something> --clone <original backup id> [new feature]
• restic forget <original backup id>
• restic prune

rewrite 및 modify 는 위의 프로세스에 대한 매크로일 수 있습니다.

나를 위해, 그것은 참으로 충분할 것입니다 @nullcake

나쁘지 않습니다, @nullcake.

하지만 과거 경험에 따르면 보통 며칠 또는 몇 주 후에 쓸모없는 로드를 백업한다는 사실을 알게 되었습니다. 조사할 시간이 있을 때. 이것이 의미하는 바는 내가 특정한 --제외가 필요하다는 것을 이해할 때까지 영향을 받는 백업이 12개 이상 있다는 것입니다.

물론 어떤 종류의 정리가 단일 백업을 기반으로 구현되더라도 귀하가 제안한 대로 여전히 큰 진전이 될 것입니다. 물론 우리는 스크립트를 작성하는 방법을 알고 있습니다. ;)

엄지손가락을 치켜세우세요. :)

이것은 흥미로운 아이디어이지만 backup 명령이 이미 너무 복잡하고 백업을 위해 다른 "소스"를 추가하면 더 복잡해질까 두렵습니다. 또한 이 기능은 이미 리포지토리에 있는 데이터에서만 작동합니다(정확하게는 메타데이터에서만). 별도의 명령(예: purge 등)은 기능을 멋지게 캡슐화할 수 있습니다.

CrashPlan에는 파일이 제외될 때 기존의 모든 스냅샷에서 제거된다는 흥미로운 동작이 있었습니다. 고려해야 할 사항일 수 있습니다.

이것은 훌륭한 기능이 될 것입니다. 추가되었나요?

아니요.

@fd0 이에 대한 진전이 있었습니까? 방금 내가 생각했던 것처럼 캐시를 제외하지 않고 제거하고 싶다는 것을 발견했습니다.

명령 이름에 대한 또 다른 제안: scrub ( purge 도 괜찮지 --rename 플래그는 나에게 이상하게 보일 것입니다). 내 생각:

restic scrub [--dry-run] [--replace=<clean|prune>] [--diff] [--all | snapshot-ID...]

--replace=clean 는 수정된 모든 스냅샷을 제거하고 prune 는 이후에 prune 정리하고 실행합니다. --diff 는 수정된 스냅샷에 대한 차이점을 보여줍니다. --dry-run 리포지토리에 대한 변경 사항을 커밋하지 않습니다.

restic backup 모든 --exclude 플래그도 유효합니다. --host 및 --time 도 의미가 있다고 생각합니다(각각 기존 스냅샷의 값을 대체함). --tag 편집은 이미 restic tag 처리하고 있습니다.

구현 방법에 대한 지침이 있는 개발자가 있습니까? 내가 보기에는 대부분의 코드가 cmd_scrub.go 파일에 들어갈 수 있습니다. 주로 인덱스 작업인 것처럼 보이기 때문에 내부 라이브러리에 몇 가지 API 추가가 필요할 수 있지만 순진한 것일 수 있습니다. 예상되는 어려움(어쨌든 테스트가 대부분일 것으로 가정)?

이것은 매우 오래된 문제이기 때문에 ..이 기능을 얻을 가능성이 있습니까?

이 업데이트를 모니터링하고 Google에서 문제를 해결하는 모든 사람들은 이 문제가 결실을 맺을 때까지 기다릴 필요가 없습니다. 잠시 동안 복제를 사용하기만 하면 됩니다. 스냅샷에서 사후 파일 제거를 위한 일급 지원을 제공합니다.

이 업데이트를 모니터링하고 Google에서 문제를 해결하는 모든 사람들은 이 문제가 결실을 맺을 때까지 기다릴 필요가 없습니다. 잠시 동안 복제를 사용하기만 하면 됩니다. 스냅샷에서 사후 파일 제거를 위한 일급 지원을 제공합니다.

저는 지금 약 1년 동안 restic을 사용해 왔으며 기능이 구현되기를 기다리지 않았습니다. 나는 모든 것이 restic에 추가되어야 한다는 것을 의미하지는 않지만 거기에 있어야 할 기본적인 것들이 있습니다. 나는 restic에서 벗어나는 것을 고려하고 있습니다. 저장소는 매우 취약하고 매우 쉽게 손상될 수 있습니다.

어제 백업에 있어서는 안 되는 파일이 포함되어 있어 스냅샷을 삭제했습니다(제외를 추가하는 것을 잊었습니다). 그 이후로 내 저장소에 오류가 있고 아직 복구할 수 없습니다. 일부 파일이 실수로 포함되어 있기 때문에 전체 스냅샷을 삭제할 필요가 없습니다.

@MorgothSauron 나는 일반적으로 그것이 포함된 스냅샷도 제거했는데, 이것이 유일한 해결책인 것처럼 보이지만 잠시 동안은 단일 명령을 통해 duplicati가 수행할 수 있으므로 그 이후로 변경했으며 문제가 없었습니다.

이 문제에 대한 의견을 주신 모든 분들께 감사드립니다. 우리가 보았듯이 많은 사람들은 특히 스냅샷에서 파일을 제거하는 기능을 원했습니다. 우리 모두는 백업할 때 한 번씩 실수를 하는 것 같아요 ;)

이 시점에서 사용 가능한 유지 관리자 및 개발자 시간은 restic의 다른 부분에 필요하므로 가까운 장래에 이 문제가 구현되지 않을 것이라고 생각합니다. 또한 가능한 한 빨리 새로운 rest-server를 출시하고 다른 문제를 조사하기 시작할 것입니다.

즉, 누군가가 훌륭하고 명확하게 작성되고, 테스트를 거치고 , 버그가 없는 견고한 PR을 만들고 유지 관리자와 협력하여 생성한 경우 반드시 포함 대상으로 고려될 것입니다. 이 특정 문제는 @fd0 이 이미 그 방향에 대해 축복을 준 문제이므로 "이 기능을 추가해야 하는가"보다는 견고한 구현(우리가 알고 있는 repos가 손상되지 않을 것임을 알고 있음)을 생성하는 데 주로 초점을 맞출 수 있습니다. .

이러한 PR은 기본적이어야 하며 필요한 경우 구축할 수 있는 출발점으로 작용해야 합니다. 내가 의미하는 바의 예는 초보자를 위한 것입니다.

• 하나의 새로운 명령이 되십시오(예: 이번 호에서 가장 많이 투표된 rewrite ).
• 스냅샷 목록을 기본 인수로 사용합니다( all 지원 포함)(예: all 또는 098db9d5 또는 098db9d5 af92db33 .
• 하나 이상의 --exclude <pattern> 목록을 가져와 스냅샷에서 제외/제거해야 하는 경로를 나열합니다(즉, 백업할 때 누락된 --exclude 입니다). 예: --exclude="*.o" , --exclude=*.unwanted , --exclude="*.o" --exclude=*.unwanted --exclude=.DS_Store .

여기에서 근거는 개념 증명과 최소한의 실행 가능한 제품으로 최소한의 시작을 하는 것입니다. 테스트를 마치면 backup 명령에서 다른 --exclude-* 인수를 추가하여 필요에 따라 조정할 수 있습니다. rewrite 명령을 다음과 같이 만들면 "수정"하기 위한 backup 명령과 거의 동일한 인터페이스를 갖게 됩니다.

~restic -r /some/repo 모두 다시 작성 --exclude=" .o" --exclude= .unwanted --exclude=.DS_Storerestic -r /some/repo 다시 쓰기 098db9d5 af92db33 --exclude=". o" --exclude= .unwanted --exclude=.DS_Store~

관련 메모에서 https://github.com/restic/restic/issues/323 에서 @middelink 가 수행한 작업은 기존 스냅샷의 일부 처리를 수행하기 때문에 구현을 위한 영감이나 기초로 사용될 수 있습니다. 나는 우리가 이것을 가지고 너무 빨리 움직일 수 있는지 볼 것입니다.

@rawtaz

사려 깊은 피드백에 감사드립니다!

안녕하세요.

@rawtaz의 댓글에 가까운 rewrite 구현 초안을 추가 했습니다.

여기에서 테스트 리포지토리와 함께 작동하고 오류 없이 restic check --read-data 를 전달하지만 많이 테스트하지는 않았습니다. 따라서 중요한 데이터와 함께 사용하지 않는 것이 좋습니다.

backup 명령에 매우 가까운 구문을 얻으려고 했습니다. 따라서 --exclude , --iexclude 및 --exclude-file 가 지원되지만 테스트되지는 않았습니다. 이상적으로는 --exclude-if-present 옵션도 보고 싶습니다(나에게 이상적인 워크플로는 '아, 백업할 필요가 없으며 CACHEDIR.TAG 및 restic rewrite '와 같은 것입니다). 그러나 이러한 경우 백업이 수행된 동일한 호스트에서 rewrite 를 수행하고 이러한 파일을 수집하기 위해 파일 시스템에 액세스해야 하기 때문에 매우 복잡합니다. 그래서 지금은 안...

또한 기본적으로 스냅샷을 대체하는 아이디어를 좋아하지 않으므로 현재 기본 동작은 rewrite 태그로 새 스냅샷을 생성하는 것입니다. 그러나 --inplace arg로도 교체가 가능합니다.

모든 피드백을 주시면 감사하겠습니다.

이봐 드미트리,

이 구현에 감사드립니다. 수고하셨습니다!

지금까지 600개 파일과 여러 테스트 스냅샷의 작은 테스트 저장소로 Linux에서 완벽하게 작동합니다. 복원 작업 및 diff가 올바르게 제외된 폴더를 표시합니다. 나는 100개 이상의 스냅샷이 있는 많은 GB의 데이터가 있는 "복제" 실제 리포지토리에 대해 보다 집중적인 테스트를 수행할 것입니다. 또한 Windows 소스 저장소를 사용해 볼 것입니다.

한 가지 제안: 재작성 단계에서 제외가 포함된 스냅샷에 대한 태그를 지정하는 옵션이 있습니다. (새로 생성된 스냅샷에 " rewrite " 태그를 유지합니다.)

restic rewrite --add-tag mytag -i thisfileshouldberemoved.txt all

이렇게 하면 "_thisfileshouldberemoved.txt_"가 포함된 스냅샷을 식별하는 데 도움이 됩니다. 반면에 더 직접적인 --inplace 는 예상대로 작동합니다.

다시 아주 좋은 작품입니다.

@NovacomExperts 네, 저의 초기 동기는 '히스토리 편집을 가능한 한 안전하게 유지하는 것'이었습니다. --exclude * 중요한 것을 제외하는 것은 매우 쉽고 이것에서 복구할 방법이 거의 없습니다(백업을 사용하면 새 백업을 다시 시작하는 문제일 뿐입니다). --dry-run 와 비슷하지만 실제 스냅샷을 가져오고 정상인지 확인한 후 소스 스냅샷을 명시적으로 삭제할 수 있는 기능이 있습니다.

나는 현재 이것이 완전히 달성되지 않았다는 데 전적으로 동의합니다. 새 스냅샷을 '관찰'하는 것은 쉽지만 이전 스냅샷을 삭제하는 것은 너무 어렵습니다. 게다가 저는 하드코딩된 rewrite 스냅샷 이름을 좋아하지 않습니다. 기본적으로 --inplace 및 ---keep-source-tagged before-rewrite --tag-destination after-rewrite 또는 이와 유사한 것이 더 나을 수도 있습니다. ( --add-tag 는 이전 스냅샷인지 새 스냅샷인지 여부가 약간 불분명합니다.)

어쨌든 관리자의 피드백을 기다리겠습니다. 잘못된 방향으로 움직이면 많은 시간을 보내고 싶지 않습니다.

추신. 내 기본 저장소는 현재 약 2TB입니다. LVM 스냅샷을 만든 후 나중에 시도합니다.

@dionorgua 당신의 초기 동기가 완전히 맞습니다. 저는 "위험한" 옵션 --inplace 를 사용자로부터 최대한 멀리(확실히 기본적으로는 아님)하여 그렇게 유지하기 위해 한 표를 던질 것입니다. 기본적으로 --inplace 보다 --keep-source-tagged / --tag-destination 의 누락된 인수 오류를 선호합니다.

하지만 동의합니다. 이에 대한 피드백을 기다리겠습니다.

어제, 나는 밤새 restic에 의해 백업된 폴더 안에 복제된 테스트 저장소(65GB)를 잊어버렸습니다. 어제의 스냅샷을 forget 가질 수 있지만 "올인"하여 구현을 시도했습니다. forget + prune 후 400GB 저장소에서 65GB를 성공적으로 제거했습니다. 모두 정상이며 오류가 발견되지 않았습니다.

여러 스냅샷에 걸쳐 있는 데이터로 더 집중적으로 테스트합니다.

건배

잘못된 #2720 풀 리퀘스트를 마스터 브랜치에서 생성했기 때문에 새로운 풀 리퀘스트를 교체했습니다. 누락된 오류 검사를 하나만 추가했습니다. 추가 소음 죄송합니다

흠, 그럼 modify ?

매우 늦었지만 _rectify_는 백업에서 특정 파일 삭제 명령에 대한 제 제안입니다.

2731은 흥미진진합니다. 감사합니다!

매우 늦었지만 rectify는 백업에서 특정 파일 삭제 명령에 대한 제 제안입니다.

나는 그것이 그것에 대한 훌륭한 이름이 아니라고 말해야합니다. Rectify는 수정/수정이 필요한 문제가 있음을 의미합니다. 이것은 사용 사례 중 하나에서 사실일 수 있지만 항상 그런 것은 아닙니다. 사용자는 기존 스냅샷에서 일부 데이터를 제거하여 우리가 알고 있는 모든 것을 위한 공간을 확보하고 나머지 스냅샷은 유지하기를 원할 수 있습니다. 표현은 수정보다 중립적이어야 한다고 생각합니다.