헤더를 앞으로 옮기는 건 잘 모르겠습니다. 이것이 현재 구현되어 있지 않다는 것을 알고 있지만 로컬 저장소의 경우 끝에 헤더가 있다는 것은 파일 사본을 저장할 수 있다는 것을 의미합니다.

흥미로운 점, 감사합니다. 뭐가 더 낫다는 판단은 아직 잘 모르겠습니다. 원격 백엔드의 경우 (백엔드 인터페이스를 약간 변경한 후) io.Reader 를 전달하면 stdlib가 sendfile 를 사용하여 디스크에서 직접 파일을 스트리밍할 수도 있습니다. 흠.

참고로 왜 GCM을 사용하지 않는지 궁금해서 벤치마크를 실행했습니다. AES-CTR + Poly1305는 CPU에 AES-NI가 없는 경우 꽤 빠릅니다(Go 내장 GCM보다 50% 빠름). AES-NI를 사용하면 Go의 최적화된 GCM 어셈블리 코드가 무적일 것입니다.

인텔 제온 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(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

이것은 이 문제에 속하지 않지만 어쨌든 대답하겠습니다.

내가 restic을 시작할 당시 Go에는 최적화된 GCM 버전이 없었습니다. 또한 GCM을 이해하지 못해서 사용하기 불편했던 반면, Poly1305 논문은 훨씬 읽기 쉽고 이해하기 쉬웠습니다.

귀하의 벤치마크는 훨씬 더 작은 데이터 덩어리를 처리한다고 생각합니다. 아마도 덩어리가 더 클 때 더 가까워질 것입니다.

내가 참조. 네, 최적화된 GCM은 꽤 최근에 나온 것입니다. Cloudflare가 Go 1.5를 위해 이를 기증했다고 생각합니다.

블록 크기와 관련하여 restic 벤치마크 는 8 MiB 를 사용하는 반면 studgcm 은 4kiB 를 사용합니다. 어리석은 gcm에 대해 8MiB 블록 크기로 다시 시도했지만 결과는 거의 동일합니다.

그래서 이것에 시간을 낭비하지 말자. 나는 CTR+Poly1305가 충분히 빠르다고 생각한다.

인덱스 파일이나 팩 바닥글에 압축되지 않은 크기를 갖는 것이 중요합니까? 블롭 내에서만 알면 괜찮을 것이라고 생각합니다. 그러면 restic에서 더 적은 변경 사항이 필요합니다. 새로운 기능이 이 추가 위치에 알려지게 합니까?

제 생각에는 저장소 형식 2 == blob 데이터의 첫 번째 바이트는 압축 형식을 나타내며 필요한 모든 것입니다. 255개의 가능한 형식 중 하나가 {64비트 비압축 길이}{압축 데이터}일 수 있습니다.

오류 수정은 백업에 좋은 아이디어라고 생각합니다. 그러나 나는 그것이 파일 시스템의 책임이라고 생각합니다. 당신은 또한 restic 내부에 RAID를 구현 하시겠습니까?

인덱스 파일이나 팩 바닥글에 압축되지 않은 크기를 갖는 것이 중요합니까?

예: 팩 헤더는 팩의 내용을 설명하고 추출 프로세스에 예상되는 사항을 알려줍니다(압축 알고리즘, 압축되지 않은 크기 및 나중에 암호화에 사용된 키와 같은 기타 속성 측면에서). restic이 팩 헤더의 모든 blob을 조회할 필요가 없도록 도입된 인덱스에서도 동일한 사항을 표시해야 합니다. 따라서 동일한 정보가 거기에 있어야 합니다.

제 생각에는 저장소 형식 2 == blob 데이터의 첫 번째 바이트는 압축 형식을 나타내며 필요한 모든 것입니다. 255개의 가능한 형식 중 하나가 {64비트 비압축 길이}{압축 데이터}일 수 있습니다.

저는 이 아이디어가 마음에 들지 않습니다. 파일 형식이 더 복잡해집니다. Blob의 시작 부분과 헤더의 두 가지 다른 위치에 제어 정보가 있습니다. 헤더는 정확히 제어 정보를 포함하는 위치입니다.

오류 수정은 백업에 좋은 아이디어라고 생각합니다. 그러나 나는 그것이 파일 시스템의 책임이라고 생각합니다.

원칙적으로 동의하지만 파일 시스템은 매우 복잡하고 오류 전파(예: 매체의 읽기/쓰기 오류)는 종종 차선책입니다. 고도로 감소된(예: 중복 제거의 관점에서) 백업 데이터의 경우 다른 오류 수정 계층을 추가(또는 추가 제안)하는 것이 좋습니다.

Reed-Solomon 코드의 경우 일부 성능 데이터가 포함된 순수 Go 구현이 https://github.com/klauspost/reedsolomon 에 있습니다.

https://www.usenix.org/legacy/event/fast09/tech/full_papers/plank/plank_html/ 에 따르면 ZFEC가 더 빨라야 합니다. 구현은 https://pypi.python.org/pypi/zfec 를 기반으로 하는 https://gitlab.com/zfec/go-zfec에 있습니다.

ECC는 압축 후에 적용되고 일반적으로 데이터 파일에 인터리브됩니다. 왜냐하면 데이터가 신뢰할 수 없거나 잡음이 많은 통신 채널을 통해 전송되는 경우 ECC를 배포하면 더 강력해지기 때문입니다.

Usenet 바이너리 그룹에서는 ECC 정보가 포함된 별도의 파일(https://en.wikipedia.org/wiki/Parchive 참조)을 사용합니다. 그것은 저장소 레이아웃에 또 다른 하위 디렉토리를 추가하고 저장소 관리 정보(config, index, ...)에 ECC를 적용하는 것도 쉬울 것입니다. 그러나 그렇게 하면 ECC 스키마가 약해질지 확신이 서지 않습니다(ECC 정보 내에서 클러스터 오류에 대한 견고성이 감소할 수 있음).

힌트를 주셔서 감사합니다. 여기에서 PDF 버전의 문서를 찾았습니다. https://www.usenix.org/legacy/event/fast09/tech/full_papers/plank/plank.pdf

ZFEC Go 구현은 C 라이브러리를 둘러싼 래퍼일 뿐입니다.

ZFEC의 경우 [https://github.com/korvus81/jfec]에 jfec이라는 추가 기능(고루틴 사용)이 있는 Go 포트가 있습니다.

새로운 리포지토리 형식 구현을 추적하기 위해 "프로젝트"(최근 GitHub에 추가됨)를 추가했습니다. https://github.com/restic/restic/projects/3

이전 버전과의 호환성을 중단할 때 조사할 수 있는 몇 가지 아이디어:

• sha256에서 sha512로 변경

sha256 대신 sha512(또는 sha512/256)를 사용하면 백업 속도가 빨라집니까? 내가 볼 수있는 한 이것은 ARM을 제외한 대부분의 플랫폼에 해당됩니다.

동기화 토론 (https://github.com/syncthing/syncthing/issues/582)

보그 토론 (https://github.com/jborg/attic/issues/209)

sha512/256에 대한 논문(https://eprint.iacr.org/2010/548.pdf)

• 단순 암호 대신 공개 키 암호화 사용

현재 저장소에 대한 쓰기 권한이 있는 모든 사람은 저장소에서 읽을 권한이 있습니다. 공개 키 암호화는 이를 제거하고 해시를 기반으로 하는 중복 제거를 계속 허용합니다.

공개 키 암호화를 데이터 BLOB에 적용하면 작동하지만, Restic이 트리 구조를 성공적으로 구현할 수 있는지 여부를 알기 위해 트리 구조를 처리하는 방법에 대해 충분히 익숙하지 않습니다. 그것은 아마도 많은 복잡성을 유발할 수 있습니다. 데이터 얼룩만 숨겨져도 트리에는 여전히 많은 정보가 있습니다.

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

• 저장소 식별

현재로서는 저장소를 우연히 발견했을 때 여러분이 보고 있는 저장소가 단순 저장소임을 알 수 있는 방법이 없습니다. 현재 키 파일에서 "created":"TIMESTAMP","username":"XXXXX","hostname":"XXXXX" 이 누출되고 있습니다. 이 정보를 숨기고 대신 restic repository version X 와 같은 restic에 대한 일부 정보를 포함하는 것이 좋습니다. README처럼 간단할 수 있습니다.

이전 논의에 관하여; 나는 어떤 형태의 오류 수정을 구현하는 것에 매우 찬성합니다.

@oysols 아이디어를 추가해주셔서 감사합니다!

아래에 내 생각을 추가하겠습니다.

sha256에서 sha512로 변경(속도용)

현재로서는 속도에 관심이 없습니다(restic은 이미 매우 빠름). 따라서 적어도 저에게 이 항목은 우선 순위가 낮습니다. 우리가 간단히 전환할 수 있는 SIMD 지원 프로세서용으로 최적화된 SHA256 버전도 있습니다. 반면에 우리가 속도를 높이기로 결정하고 해시에 대해 논의해야 할 때 나는 Keccak(SHA3) 또는 Blake2를 선호할 것입니다. 훨씬 더 빨리.

그래서 제 관점에서 이 항목은 일단 연기되었습니다.

단순 암호 대신 공개 키 암호화 사용

이 기능은 계획되어 있지만(#187 참조) 복잡하고 많은 생각과 몇 가지 주요 인프라 변경이 필요합니다. 나는 또한 이것을 연기하고 모든 것을 변경 -> 연기하는 대신 더 작은 증분 업데이트를 수행하고 싶습니다.

리포지토리 식별(리포지토리에 README 파일 추가)

아주 좋은 점, 우리는 아무것도 중단하지 않고 지금 추가할 수도 있습니다.

리포지토리 "정보 누출"(키 파일에서 사용자 이름, 호스트 이름 및 생성된 타임스탬프 제거)

그것도 좋은 지적입니다. 현재 이 정보는 key list 명령에서 키 ID와 함께 표시하는 데만 사용됩니다. username 및 host 를 쉽게 삭제할 수 있습니다. 타임스탬프는 많은 정보를 제공하지 않으며 대부분의 경우 파일 생성 날짜와 동일합니다.

username 및 host 를 삭제하고 생성된 타임스탬프를 그대로 두고 싶습니다. 생각이 있으신가요?

저는 오늘 https://github.com/klauspost/reedsolomon 을 가지고 놀았고 팩 파일의 끝에 오류 수정 코드를 더 쉽게 추가할 수 있다고 생각합니다(팩 헤더를 파일의 시작 부분으로 이동하면 ). 하지만 두 가지 단점이 있습니다.

• 파일 크기는 reed-solomon에 대해 선택한 매개변수에 따라 ~14-30% 증가합니다.
• 우리는 팩 파일 자체에 있는 팩 파일 섹션의 체크섬(반드시 암호화 해시는 아님)을 저장해야 합니다. 재구성을 위한 알고리즘은 파일의 어느 부분이 손상되었는지 알아야 하기 때문에 재구성에 필요합니다. 따라서 빠른 체크섬(CRC 등)을 사용하도록 선택할 수 있지만 계산하는 데 시간이 조금 더 걸립니다.

생각?

그렇다면 데이터 로드 보호는 선택 사항이 될 수 있습니까? 나는 크기 증가가 한계보다 더 크다고 생각합니다 (다른 사람들에게는 훌륭한 기능이라고 생각하지만!)

ECC가 압축과 결합될 때 저장소가 얼마나 더 큰지(또는 더 작은지?) 느낌을 얻을 수 있도록 이것으로 조금 플레이하겠습니다. 두 종류의 코드를 추가할 수 있습니다. 하나는 팩 헤더용이고 다른 하나는 데이터용(선택 사항일 수 있음)입니다.

사용자 이름 및 호스트 삭제

좋은 생각 같습니다. 정보를 유지하려면 마스터 키와 동일한 방식으로 별도의 암호화된 필드에 정보를 추가할 수 있습니다.

ECC: 파일 크기가 ~14-30% 증가합니다.

팩 파일 자체에 ECC를 포함하는 것은 좋은 생각이 아니라고 생각합니다. 일반적인 복원 시나리오에서는 사용되지 않으며 팩 파일이 손상된 경우에만 사용됩니다.

패리티 데이터를 별도의 디렉토리에 두는 것이 좋습니다.

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

• 패리티는 완전히 선택 사항이며 백업 후 생성될 수 있습니다.
• 복원 작업이 느려지지 않습니다. 복원에 추가 대역폭이 필요하지 않습니다.
• 동일한 파일 이름을 사용하면 올바른 패리티 데이터를 쉽게 식별할 수 있습니다. 이것은 패리티 데이터가 자체 sha256 해시의 이름을 따서 명명되지 않았지만 추가 인덱스가 필요하지 않음을 의미합니다. (패리티 데이터의 확인은 어쨌든 팩 파일을 확인하여 수행해야 합니다.)
• 사용자는 패리티 데이터의 양을 알 수 있습니다.

구현 방법에 관계없이; 압축 및 암호화 계층이 많기 때문에 일종의 ECC가 필요하다고 생각합니다. 하나의 잘못된 비트가 많은 문제를 일으킬 수 있습니다.

귀하의 의견에 감사드립니다. 토론을 제가 방금 만든 별도의 문제인 #804로 옮기겠습니다.

나는 restic의 정방향 오류 정정 코드에 대해 서로 과거에 이야기하는 두 그룹이 있다는 인상을 받지 않을 수 없습니다. 한 그룹은 비트플립이 중복 제거된 리포지토리에서 큰 문제를 일으킬 수 있기 때문에 비트로트로부터 리포지토리를 (그냥) 보호하려고 합니다. 다른 그룹은 삭제 코드를 사용하여 저장소를 여러 장애 도메인(예: 비 RAID 디스크)에 분산하려고 합니다. 두 목표 모두 Reed-Solomon 코드로 제공될 수 있지만 서로 다른 매개변수와 저장 레이아웃이 필요합니다.

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

146GB 백업 중 트리 blob은 54MB에 불과하며 압축을 구현할 때 원래 공간의 약 1/3로 압축됩니다.

데이터 blob에서 트리 blob을 분리하면 성능이 향상됩니까?

복원 중에 수행되는 대부분의 작업은 실제로 데이터를 복원하기 전에 트리 Blob을 기반으로 수행되는 것 같습니다. 이들을 별도의 팩 파일로 분리하면 백업 트리를 구문 분석하기 위해 다운로드해야 하는 데이터의 양이 최소화됩니다. 나무 덩어리의 작은 크기를 감안할 때 복원 프로세스를 시작하기 전에 모든 나무 덩어리를 다운로드하는 것이 더 빠를 수 있습니다.

물론; 이 분포는 모든 저장소에 대해 동일하지 않을 수 있습니다.

이것이 더 조사할 가치가 있다고 생각하십니까?

데이터 blob에서 트리 blob을 분리하면 성능이 향상됩니까?

아마도 이것은 내가 미래를 위해 염두에 두고 있는 최적화 중 하나일 것입니다.

이 외에도 메타데이터에 대한 로컬 캐시를 추가하여 리포지토리에서 가져올 필요가 전혀 없도록 하고 싶습니다. 이것은 많은 작업의 속도를 크게 향상시킬 것입니다.

데이터 blob에서 트리 blob을 분리하면 성능이 향상됩니까?

이것은 이론적으로 prune 작업을 개선할 수 있습니다. 트리 덩어리와 데이터 덩어리가 별도의 팩 파일에 있는 경우 재패킹이 덜 필요하기 때문입니다(이전 팩 파일을 재패킹하는 대신 일괄 삭제하는 것이 가능할 수 있음).

#842에서 이미 보고 있습니다.

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

sym 대 asym: 아이디어는 "세션" 키를 pubkey-encrypt하는 것입니다. 맞습니까?

지금은 연기되었으므로 이 문제에서 암호화에 대해 논의하지 맙시다. 비대칭 암호화 토론과 관련된 문제는 #187입니다. 또한 사용 사례를 확정할 때까지 논의를 높은 수준으로 유지하고 싶습니다. 그런 다음 저수준 암호화에 대해 이야기할 수 있습니다.

키 파일에서 사용자 이름과 호스트 이름을 제거합니다.

엄청난 메타데이터 유출!
예를 들어 "username":"WorldBank\\JimYongKim" 는 상위 소유자 를 명확하게 나타냅니다.

2017년 1월에 첫 번째 Windows 바이너리 가 컴파일된 이후 이것이 _제거_(또는 _암호화_)되기를 기다리고 있습니다.
다행스럽게도 개인 정보 보호에 관심이 있는 사람들에게 Restic을 업로드하거나 추천하기 전에 백업을 검토했습니다.

편집: 사용자의 시간대도 일반 텍스트로 언급되며 이는 기밀 원칙에도 위배됩니다.

Re: SHA3 -- 채택할 가치가 없는 이유에 대한 한 가지 의견(아직?): https://www.imperialviolet.org/2017/05/31/skipsha3.html

따라서 SHA-3을 사용해서는 안 된다고 생각합니다. SHA-2에 비해 강력한 이점을 제공하지 않으며 많은 비용이 듭니다. 내가 믿을 수 있는 유일한 주장은 백업 해시 기능이 있다는 것이 좋지만 SHA-256과 SHA-512는 모두 일반적으로 지원되며 다른 코어를 가지고 있다는 것입니다. 그래서 우리는 이미 두 개의 보안 해시 함수를 배포했으며 다른 것이 필요하지 않다고 생각합니다.

나는 게시물을 읽고 agl의 주장을 이해합니다. 우리는 암호화 프로토콜의 빌딩 블록이 아니라 blob을 (고유하게) 식별하기 위해 해시 함수를 사용하고 있습니다. 다른 해시 함수를 살펴보려는 제 생각은 주로 SHA-256이 특히 로우엔드 시스템에서 계산 속도가 느리다는 것이었습니다. 다른 해시 함수는 훨씬 빠릅니다(예: blake2).

이것이 repo 형식인지 확실하지 않습니다. 암호화를 선택 사항으로 만드는 것은 어떻습니까? 이미 암호화된 디스크가 있는 신뢰할 수 있는 백업 서버에 저장될 백업을 생각하고 있습니다.

@mschiff 해당 토론은 #1018을 참조하세요. ;)

부품 크기를 옵션으로 만드는 것은 어떻습니까?
현재 파일당 4-6MB가 있습니다. 파일은 적지만 크기가 크면 원격 백업이 훨씬 빨라집니다.

@fd0 은 다음과 같이 썼습니다.

현재로서는 속도에 관심이 없습니다(restic은 이미 매우 빠름). 따라서 적어도 저에게 이 항목은 우선 순위가 낮습니다. 우리가 간단히 전환할 수 있는 SIMD 지원 프로세서용으로 최적화된 SHA256 버전도 있습니다. 반면에 우리가 속도를 높이기로 결정하고 해시에 대해 논의해야 할 때 나는 Keccak(SHA3) 또는 Blake2를 선호할 것입니다. 훨씬 더 빨리.

더 빠르고 덜 CPU 집약적인 해시 알고리즘(예: Blake2)에 대한 또 다른 고려 사항은 전원에 연결되어 있지 않은 상태에서 백업을 수행할 때 랩톱에서 배터리 사용량을 줄이는 것입니다.

첫 번째 게시물에 대한 답변:

키 파일에서 사용자 이름과 호스트 이름을 제거합니다.

이것이 키 이름이나 일종의 설명으로 대체됩니까? 다른 키를 구별하는 어떤 방법(예: 일부 시스템에 대한 액세스 권한을 취소할 때 키 자체에 대한 액세스 없이)이 키 관리를 유용하게 만드는 데 유용하다고 생각합니까?

한 가지 새로운 제안: 얼룩, 나무 및 스냅샷에 다른 키를 사용하는 것은 어떻습니까? 이것은 AFAICS를 사용하여 클라이언트가 아닌 백업 스토리지 서버에서 잊어버리고 정리하는 시나리오를 가능하게 합니다. 스토리지 서버에 트리 및 스냅샷 개체에 대한 액세스 권한을 부여하면 어떤 스냅샷에 필요한 개체와 더 이상 사용되지 않는 개체를 결정할 수 있는 충분한 정보가 있어야 합니다. 스토리지 서버가 손상될 때마다 트리 메타데이터에 액세스할 수 있지만 실제 파일 내용에는 액세스할 수 없습니다.

메타데이터의 나머지 부분에 대한 액세스는 허용하지 않고 트리에서 참조하는 개체 ID 목록에만 액세스할 수 있도록 하여 이 기능을 약간 더 강력하게 만들 수 있습니다(그러나 이렇게 하려면 각 트리에 대한 추가 데이터 구조가 필요함).

위의 사항이 가능하다면 자동화된 정리를 희생하지 않고도 쓰기 전용/추가 전용 유형의 스토리지(백업된 클라이언트가 백업을 삭제할 수 없는 곳, #784 참조)를 사용할 수 있는 방법이 열립니다. 데이터 보안.

내 이전 의견(데이터에 대한 전체 액세스가 필요하지 않은 가지치기)과 관련하여: 이는 백업 확인 에도 적용됩니다(더 강력할 수 있음). 효율성을 위해 저장소 서버에서 저장소를 확인하는 것이 합리적입니다(AFAICS에서 저장소를 원격으로 확인하려면 모든 콘텐츠를 전송해야 함) 또는 진정한 쓰기 전용 지원을 구현할 때(https://github.com/ncw/rclone/issues 참조) /2499).

또한 진정한 쓰기 전용 접근 방식의 경우 읽어야 하는 파일을 제한하도록 변경해야 합니다(https://github.com/ncw/rclone/issues/2499#issuecomment-418609301 참조). 저장소 형식 변경이 필요한지 확실하지 않습니다. 그렇다면 여기에 포함하는 것이 유용할 수 있습니까?

원격 서버에서 저장소를 확인하고 정리하는 것은 정말 좋습니다. 여러 호스트를 백업하기 위해 restic을 설정하는 중이며 클라이언트 설정이 가능한 한 쉽고 백업이 정기적으로 실행되기만 하면 되도록 원격에서 모든 유지 관리 작업을 수행하고 싶습니다.

스냅샷 파일 형식에 대한 몇 가지(선택 사항일 수 있음) 추가 사항에 대해 논의하고 싶습니다.

• 사용된 인덱스 파일 목록 추가(#1988 참조)
• 사용자 정의 데이터에 대한 가능성 추가(예: 추가 설명 등, 지금은 문제를 찾지 못함)
• 파일/블롭 수, 사용된 공간 등과 같은 통계 데이터를 추가합니다. 이렇게 하면 통계 표시가 훨씬 빨라지고 추가 검사도 가능합니다.

팩 파일 형식에 대해 헤더를 완전히 제거하지 않는 이유를 묻고 싶습니다.
정보는 색인 파일에 중복으로 포함됩니다. 오류 수정을 위한 중복성을 추가하는 것에 대한 논의가 있었지만 IMO는 일반 repo 형식과 분리되어야 하고 그 위에 추가되거나 추가되지 않을 수 있습니다.

간단히 말해서 오류 수정을 위한 추가 정보가 필요하지 않거나 원하는 경우 팩 헤더 및 인덱스 파일에 정보를 복제할 필요가 없습니다. 인덱스 파일은 작업 수행에 필요하며 모든 곳에서 사용됩니다. 팩 헤더는 거의 사용되지 않으며, 이중 확인 또는 오류 수정을 위해서만 사용됩니다.

또 다른 제안: 사용자 이름, 호스트 이름 및 구성 파일의 내용을 키 파일의 data 섹션에 추가합니다. 따라서 구성 파일을 완전히 제거하십시오.

이미 제안된 대로 사용자 이름과 호스트는 암호화된 형식으로만 존재해야 합니다. KDF 파생 키가 유효한지 확인하려면 암호화된 data 섹션의 MAC을 확인하는 것으로 이미 충분합니다.
IMO에서는 키를 식별하는 데 필요한 모든 정보를 거기에 두는 것이 합리적입니다. config 파일에 저장된 정보 추가 ATM은 repo에서 추가 파일을 제거하고 repo 초기화를 더 쉽게 만듭니다.

"멍청한" 질문에 대해 죄송합니다. 하지만 곧 개선된 형식을 도입하려는 진지한 노력이 있습니까? 나는 몇 년 동안이 문제를 따라 왔습니다. restic은 현재 대용량 데이터 세트나 스냅샷이 많고 메모리가 많이 필요한 경우에는 잘 작동하지 않습니다. 압축 부족과 JSON 인코딩 메타데이터의 큰 오버헤드가 restic의 큰 문제인 것 같습니다. "완벽함"을 달성해야 한다는 인식 때문에 노력이 중단된 것은 아닐까요?

나는 또한 미래가 무엇을 가져올지 관심이 있습니다. 특히 비대칭 암호화 및 압축에서.
그건 그렇고, 새로운 해시 함수의 경우 매우 새롭고 매우 빠른 blake3도 있습니다. https://github.com/BLAKE3-team/BLAKE3
해시 함수의 변경에 대해 아직 결정이 내려지지 않았다면 흥미로울 수 있습니다.

repo.v2에 대한 몇 가지 추가 아이디어:

• 트리 및 데이터 blob을 다른 디렉토리에 저장합니다(과거 트리와 데이터는 혼합되었지만 캐시 도입으로 더 이상 사용되지 않음).
• 데이터 Blob에 '생성된 시간' 정보를 추가합니다.

이것은 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).

이 아이디어가 마음에 들지 않습니다.. 이점을 보지 못하는 동안 백업의 파일 크기를 훨씬 쉽게 추측할 수 있습니다.

* add 'created time' info to data blobs.

"생성된 시간"을 추가하는 데 사용되지 않습니다. 사용 사례를 줄 수 있습니까?

이것은 amazon Glacier와 같이 매우 느리거나 비용이 많이 드는 다운로드로 '콜드' 스토리지에 대한 지원을 단순화해야 합니다.

"콜드 스토리지" 지원은 로컬 캐시와 같이 자주 사용되는 파일을 제한하고 이중 저장하는 몇 가지 미세 조정 가능성을 추가함으로써 현재의 repo 형식으로 이미 달성할 수 있다고 말하고 싶습니다. 참조 #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).

이 아이디어가 마음에 들지 않습니다.. 이점을 보지 못하는 동안 백업의 파일 크기를 훨씬 쉽게 추측할 수 있습니다.

이점은 바로 이 문제에 대한 이전 의견에 잘 설명되어 있습니다.
https://github.com/restic/restic/issues/628#issuecomment -280436633
https://github.com/restic/restic/issues/628#issuecomment -280833405
첫 번째 주석의 결과는 또한 이 두 가지 유형의 얼룩을 혼합해도 의미 있는 방식으로 파일 크기를 가리지 않는다는 것을 보여줍니다.

관련 포럼 게시물:
https://forum.restic.net/t/feature-using-an-index-for-restic-find/1773

@cfbao 당신이 언급하는 주석은 하나의 데이터 파일(팩) 내에서 트리와 데이터 블롭을 혼합하는 것에 관한 것입니다. 이것을 분리하면 캐시 처리를 활성화하는 데 유용합니다. 이것은 또한 restic 내에서 이미 변경되었습니다.

그러나 다른 디렉토리에 트리 및 데이터 BLOB을 저장 하는 것의 이점은 여전히 ​​없습니다. 사용 사례를 줄 수 있습니까? (IMO 찾기 포럼 주제는 관련이 없습니다. 거기에서 답변해 드리겠습니다.)

그러나 별도의 인덱스 파일(예: "index-data" 및 "index-tree" 디렉토리)에서 트리 및 데이터 blob 항목을 분리하면 일부 개선이 가능합니다.

트리 블롭은 이미 별도의 팩 파일에 저장되어 있습니다(캐시와 함께 도입됨).
다른 디렉토리에 쓰기만 하면 다운로드 속도가 매우 느린 스토리지(Amazon Glacier 표준의 경우 3-5시간)에 대한 지원을 개선할 수 있습니다. 모든 메타데이터(일반 S3의 인덱스+스냅샷+트리, Glacier의 데이터)를 저장하는 것과 같습니다.

2504는 그것을 약간 개선하지만 '로컬 캐시'에 의존하거나 캐시를 채우기 위해 많이 기다리는 아이디어를 좋아하지 않습니다.

일반 S3 또는 다른 장소에 tree+index+snapshots 를 저장하지만 데이터를 딥 아카이브에 저장하는 리버스 프록시를 갖는 것이 훨씬 더 좋습니다.
어쨌든 restic 를 그대로 사용할 수는 있지만 몇 가지 제한이 있습니다. 그러나 일부 형식 변경은 상황을 개선/단순화할 수 있습니다.

restic find 코드에서 내가 보는 한 @cfbao 는 이점을 얻지 못할 것입니다. 그것은 이미 스냅샷을 통해 이동합니다. 기본적으로 restic ls <all-snapshots> | grep something 와 거의 동일합니다.

@dionorgua
데이터 팩을 제외한 모든 항목이 캐시되는 "추가" 캐시로 임의의 저장소를 추가하는 아이디어가 마음에 듭니다. 이것은 리포지토리 레이아웃을 변경할 필요가 없으며 IMO는 훨씬 더 유연합니다.
저는 이미 이 작업을 하고 있습니다. #2516, 마지막 댓글도 참조하세요.

어리석은 생각일 수도 있지만 borg 또는 kopia와 호환되는 형식은 어떻습니까?

@aawsome

당신이 언급하는 주석은 하나의 데이터 파일(팩) 내에서 트리와 데이터 블롭을 혼합하는 것에 관한 것입니다.

진실. 내 잘못이야. 네, 제가 신경 쓰는 것은 이것뿐입니다.

이것은 또한 restic 내에서 이미 변경되었습니다.

이것이 변경된 PR/버전을 알고 있습니까? 마지막으로 내 리포지토리를 확인했을 때 동일한 팩 파일에 데이터와 트리 블롭이 혼합된 것을 발견했습니다. 어떤 방법으로든 내 저장소를 더 잘 분리되도록 변환할 수 있습니까?

다른 디렉터리에 트리 및 데이터 Blob을 저장하는 것의 이점은 여전히 ​​없습니다. 사용 사례를 줄 수 있습니까?

나는 아무 생각이 없다. 앞서 언급했듯이 나는 이것에 대해 별로 신경 쓰지 않습니다.

@dionorgua

내가 코드에서 보는 한 restic find는 이것의 이점을 얻지 못할 것입니다. 그것은 이미 스냅샷을 통해 이동합니다. 기본적으로 restic ls와 거의 동일합니다.| 그렙 뭔가.

데이터 blob에서 트리 blob을 분리하면 찾기에 필요한 API 호출 수가 줄어들지 않습니까? 집중되면 트리 덩어리가 포함된 팩 파일의 수가 줄어들고 restic은 많은 팩 파일에서 많은 세그먼트를 가져오는 대신 더 적은 수의 전체 파일을 다운로드할 수 있습니다. 이는 상대적으로 느리고 속도 제한이 더 엄격한 백엔드(예: Google 드라이브)에 중요합니다.

어떻게 해서든 내 repo를 더 나은 것으로 변환할 수 있습니다.
분리?

최신 버전의 restic을 사용하여 'prune'을 실행하면 이러한 혼합 팩을 다시 빌드해야 합니다.
'prune'의 실제 구현은 원격 저장소에 대해 많은 트래픽을 생성한다는 점에 유의하십시오. #2718의 실험적인 재구현을 통해 트래픽을 최소화하면서 혼합 팩만 재포장할 수 있습니다.

데이터 blob에서 트리 blob을 분리하지 않으면 API 수가 줄어듭니다.
찾기에 필요한 호출?

최신 버전과 혼합 팩이 없는 리포지토리에서는 필요한 모든 정보가 로컬로 캐시됩니다.

개선된 저장소 형식에 대한 또 다른 아이디어:

우리가 보았듯이 blob 유형별로 팩 파일을 분리하는 것이 좋습니다(트리 및 데이터 blob은 다른 팩 파일로 이동). Blob 유형별로 인덱스 파일도 분리하는 것이 좋지 않을까요? 최근 인덱스 PR은 이미 메모리 내 표현에서 트리 및 데이터 BLOB에 대한 인덱스 항목을 분리하는 방향으로 가고 있습니다.
또한 인덱스의 일부만 로드하도록 최적화할 수 있습니다.

저장소에서도 이 작업을 수행하면 보다 간결한 표현이 가능합니다. 예를 들어

{
  "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
        }
      ]
    }, [...]
  ]
}