이것을 구현할 때 벤치마크를 추가하고 특히 -benchmem 및 benchcmp를 사용하여 메모리 사용량을 살펴보십시오!

lz4, lzo, lzma, null. bz2는 다소 느립니다.

snappy는 적당한 압축으로 빠릅니다.

압축이 청크별로 수행되는 경우 워터마킹/지문 공격에 대한 일반 백업이 열려 있지 않도록 주의해야 합니다.

이것은 본질적으로 CDC 중복 제거 프로세스의 지문 채취와 관련하여 논의한 것과 동일한 문제입니다.
"순진한" CDC를 사용하면 공격자가 개별 블록의 크기를 관찰할 수 있는 경우 "알려진 일반 텍스트" 파일이 백업 내에 존재하는지 확인할 수 있습니다. 청크 길이.
앞서 논의한 바와 같이, 이것은 다락방에서 수행되는 것처럼 CDC 알고리즘을 비밀 값으로 솔트팅함으로써 어느 정도 완화될 수 있습니다.

솔티드 CDC를 사용하면 문제가 있는 파일을 청크로 분할한 후 각 개별 청크에서 압축이 발생한다고 가정합니다. Restic 청크의 범위는 512KB에서 8MB입니다(그러나 고르게 분산되지는 않습니다. 맞나요?).

• 공격자는 CDC 알고리즘이 비밀 솔트를 사용한다는 것을 알고 있으므로 공격자는 각 유효한 청크 길이에 대해 하나씩 파일의 처음 512KB에서 8MB로 구성된 청크 범위를 생성합니다. 공격자는 또한 압축된 청크의 길이를 결정할 수 있습니다.
• 그런 다음 공격자는 압축 알고리즘을 사용하여 해당 청크를 압축합니다.
• 공격자는 결과 청크의 길이를 나머지 백업 세트의 첫 번째 청크와 비교합니다.
• 일치하는 블록 길이가 발견되면 공격자는 다음 청크, 다음 청크, 다음 청크, ... 및 다음 청크로 연습을 반복합니다.
• 충분히 큰 파일을 사용하고 CDC 알고리즘이 약 1MB의 블록을 생성하는 쪽으로 "편향적"이라는 사실을 고려하면 이것이 특정 큰 파일이 백업에 있습니다.

항상 그렇듯이 편집증적이고 매우 비과학적인 의식의 흐름.

생각?

흥미로운. 나는 당신이 설명하는 공격이 압축 사용 여부에 따라 어떻게 달라지는지 이해하지 못합니다. 전혀 필요합니까? 이 공격은 압축을 사용하거나 사용하지 않고 작동하지 않습니까?

현재 #56을 구현하는 방법에 대해 생각하고 있습니다. 여러 Blob을 단일 파일로 묶는 것에 대해 어떻게 생각하십니까?

CDC 구현의 정확한 작동은 나에게 약간 불분명합니다.

• 정확한 바이트 경계로 분할합니까, 아니면 512KB - 8MB 블록이 무언가의 배수로 "반올림"됩니까?
• (진짜 질문은 (15 * 512 * 1024) / (AES-CTR 때문에 16) 가능한 청크 크기 또는 그 이하가 있습니까?)
• 나는 또한 알려진 파일의 충분한 덩어리가 주어지면 시드를 재구성하는 것이 얼마나 실현 가능한지 궁금합니다.

첫 번째 질문에 답하려면:
시드된 CDC를 사용하면 "지문"은 (내용 + 비밀 시드)에 따라 다르지만 청크 _후_ 압축이 완료되면 개별 블록을 서로 구별할 수 있다고 가정하면 지문/ 이 시나리오에서 알려진 일반 텍스트인 콘텐츠에만 의존하는 워터마크(특정 블록의 압축률).

예시:
워터마크가 있는 파일에 64MB(8-128 청크)의 "AAAA", 64MB의 "ABCABCABCABC", 64MB의 임의 데이터가 포함된 경우 처음 16-256 청크는 매우 작습니다(해당 시퀀스가 ​​매우 잘 압축되기 때문에 , 여기서 8-128 청크는 압축이 잘 되지 않습니다.)
공격자는 또한 가장 마지막(24~384번째) 청크부터 거꾸로 작업하여 공격자가 정확히 동일한 청크 크기로 압축되는 크기를 찾을 때까지 512KB-8MB를 압축할 수 있습니다. 그것이 발견되면 원래 평문의 "다음" 512KB-8MB가 압축되어 공격자가 만날 때까지 마지막에서 두 번째 블록(23번째 - 383번째)의 길이로 압축되는 길이를 찾는 식으로 진행됩니다. "AAAA" 문자열의 결과인 작은 청크.
이렇게 하면 공격자가 워터마크가 표시된 파일이 백업에 저장되어 있는지 긍정적으로 확인할 수는 없지만 충분한 데이터가 주어지면 통계적으로 상당히 명확한 결과를 생성할 수 있다고 생각합니다.

몇 가지 잠재적인 솔루션이 있습니다. 아마도 더 많은 아이디어가 있을 것입니다.

• 특정 디렉토리에 대한 압축 및/또는 중복 제거 허용(구현하기 가장 쉬움)
• 압축 사전 무작위화(이것은 실제로 생각해보지 않았지만 흥미로운 아이디어인 것 같습니다)
• 공격자가 개별 압축 청크의 길이를 학습하는 것을 방지합니다. 예를 들어 패딩(잠재적으로 상당히 비쌀 수 있음) 또는 여러 개의 작은 청크를 번들로 묶고 나머지 부분을 패딩(더 복잡하지만 더 효율적임)

설명해주셔서 감사합니다. 이제 시나리오를 이해했습니다.

restic에서 중복 제거를 해제하는 옵션은 없을 것입니다. 프로그램의 현재 구조를 감안할 때 그렇게 하기가 정말 어렵기 때문입니다. restic은 CDC를 기반으로 구축되었습니다. 압축 지원을 추가하는 것은 현재 우선 순위가 낮으며 알파 릴리스의 목표가 아닙니다.

귀하의 세 번째 아이디어는 #56(여러 청크 묶음)에서 구현될 것입니다. 지금 작업 중입니다. 그리고 아마도 청커의 작동 방식에 관해 doc/Design.md 에 더 많은 문서를 추가할 것입니다.

이 시나리오를 제시해 주셔서 다시 한 번 감사드립니다!

@cfcs를 따르는지 확실하지 않습니다. 압축된 크기가 엄청나게 나쁜 해시와 같지 않습니까? 압축된 파일 크기가 주어지면 해당 파일 크기를 생성하는 가능한 입력 수는 무한합니다. 하지만 아마도 나는 이해하지 못할 것입니다.

어쨌든. 내가 만든 수정된 deflate/gzip 라이브러리 를 뻔뻔하게 알려주고 싶었습니다. 모든 데이터에 대해 ~150MB/s/코어 처리량을 가능하게 하는 일정 시간 압축 모드 를 설정하면 백업 시나리오에서 거의 보이지 않습니다. 여러 코어에서 더 큰 파일을 gzip으로 압축하는 병렬 gzip 패키지 도 있습니다.

@klauspost : 우리는 파일이 아닌 개별 청크 의 압축된 크기에 대해 논의하고 있음을 명심하십시오. 평균 청크 크기가 1MB인 100GB 파일에는 약 100 x 1024 청크가 있으며 각 청크는 파일의 특정 부분에 대한 압축 비율을 누출합니다. 이것은 단일 압축 파일의 크기보다 훨씬 더 많은 통계 데이터를 생성하므로 CDC 솔트(따라서 청크의 정확한 정렬 경계)를 알 수 없는 경우에도 알려진 일반 텍스트를 압축 및 청크 파일과 비교할 수 있습니다.

그러나 151이 병합되었으므로 지금은 문제가 되지 않을 것입니다.

내 생각에, 이 정보 누출은 시드된 청커(사용자 지정 repo별 다항식을 통해)와 blob 패킹(공격자가 개별 청크를 볼 수 없지만 청크 그룹과 청크 수만 볼 수 있는 경우)이 있다는 점을 고려할 때 중요하지 않습니다. 그룹에서 일반 텍스트 헤더 길이를 통해). 속도나 개인 정보 보호 문제를 위해 압축을 완전히 비활성화하는 것이 좋은 아이디어라고 생각하지만 기본값(구현된 경우)은 아마도 "활성화"일 것입니다.

@klauspost 지적해 주셔서 감사합니다.

@fd0 위의 관찰에 동의하지만 이미 지정된 멀티미디어 형식을 백업할 때와 같이 특정 대상 파일/디렉토리/장치에 대한 압축을 선택적으로 비활성화하는 또 다른 중요한 사용 사례가 있을 수 있다고 생각합니다. 압축이 잘 되지 않는 높은 엔트로피를 가진 압축된 바이너리 파일 또는 암호화된 볼륨의 증분 백업을 수행할 때.

@cfcs - ok - 귀하의 텍스트에서 귀하가 데이터를 추론할 수 있음을 암시한다고 생각했습니다. 따라서 이것이 차이를 만들려면 드문 경우인 원본 데이터가 필요합니다.

압축할 수 없는 파일과 관련하여 내가 deflate에 넣은 일정한 시간 Huffman 전용 모드를 언급한 이유는 이름에서 알 수 있듯이 모든 데이터를 동일한 속도로 압축하고 압축되지 않은 데이터를 저장하는 데 자동 폴백이 있음을 의미합니다. 따라서 콘텐츠가 압축된 경우 최대 오버헤드는 약 0.04%입니다.

다음은 몇 가지 벤치마크 입니다. 백업에 가장 적합한 것은 아마도 "Medium Compression"(압축 가능 및 비압축 10GB 혼합 콘텐츠)일 것입니다.

기본적으로 gzip Huffman만 사용하고 CPU를 더 많이 사용하는 압축 수준을 지정하는 옵션이 있을 수 있습니다.

제 생각에는 데이터 및 트리 개체에 대해 별도로 압축을 선택적으로 활성화/비활성화하는 것이 중요할 수 있습니다. 특히 큰 나무 개체는 정말 잘 압축되어야 합니다.

압축을 삽입하는 것이 타당할 수 있는 몇 가지 "포인트"를 살펴보았습니다. 가장 투명하고 다재다능한 장소는 저장소와 백엔드 사이의 어딘가입니다.

Repository.Encrypt 및 Repository.DecryptTo 수정하는 방법을 간략하게 살펴보았지만 유형이 없고 크기가 다양하면 문제가 복잡해집니다.

내 제안은 압축과 _encryption_을 "백엔드"로 구현하는 것이며 둘 다 기본 백엔드에 작성합니다. 이렇게 하면 압축 및 암호화가 저장소에 투명하게 됩니다.

암호화를 분리해야 하는 이유는 암호화된 데이터가 압축되지 않기 때문입니다.

저장소.저장소

압축 알고리즘은 초기화 시에만 설정할 수 있으며 구성을 제외한 모든 항목은 해당 알고리즘으로 압축된 것으로 가정합니다.

저장소.구성

구성을 압축할 수 없습니다. 모든 것에 사용할 압축 해제 유형을 나타내는 문자열을 추가합니다. 비어 있음("")은 압축 해제됩니다. 그렇지 않으면 사용된 압축 라이브러리 패키지 이름의 마지막 부분입니다.

압축 수준은 각 실행/유형 간에 변경할 수 있습니다. 압축 해제기가 동일하다면 일부 스냅샷/유형이 deflate 수준 0(저장)이고 일부는 수준 9(최상의 압축)인 저장소를 갖는 데 문제가 없습니다.

type Config struct {
    Version           uint        `json:"version"`
    ID                string      `json:"id"`
    ChunkerPolynomial chunker.Pol `json:"chunker_polynomial"`
+   Compression       string
}

생성 매개변수로 압축이 추가됩니다.

-func CreateConfig(r JSONUnpackedSaver) (Config, error) {
+func CreateConfig(r JSONUnpackedSaver, compression string) (Config, error) {

백엔드는 LoadConfig/CreateConfig 후에 교체됩니다. 다음은 표시 방법의 예입니다.

// SearchKey finds a key with the supplied password, afterwards the config is
// read and parsed.
func (r *Repository) SearchKey(password string) error {
    key, err := SearchKey(r, password)
    if err != nil {
        return err
    }

-   r.key = key.master
-   r.keyName = key.Name()
    r.Config, err = LoadConfig(r)
+   r.be, err = FindCompressor(r.Config.Compression, Encryption(key, r.be))
    return err
}

압축 구현

압축기는 일부 유형에 대해 선택/조정 가능한 압축을 구현할 수 있습니다. "백엔드"로 표시되기 때문에 압축된 크기는 저장소에 표시되지 않습니다. 압축기는 모든 설정과 함께 요약되어야 합니다.

문제

HELPME/FIXME: 각 파일에서 암호화가 다시 시작되기 때문에 "포장된" 파일이 문제인 것 같습니다. 암호화가 백 엔드로 이동하는 경우 암호화는 각 파일이 아니라 전체 Blob에 대해 수행됩니다. 나는 그것이 문제라고 가정하고 좋은 해결책이 없습니다.

TODO: 매개변수/구성이 압축기로 전송되는 좋은 방법을 찾으십시오. 첫 번째 구현에는 필요하지 않습니다.

TODO: 디스크 크기에 관심이 있습니까? 위의 사항이 구현되면 저장소는 이를 알지 못합니다.

의견을 공유해 주셔서 감사합니다. 제 의견은 다음과 같습니다.

압축과 암호화가 서로 통합되어야 한다고 생각하는데, 이에 대해 생각해 보겠습니다. 현재로서는 압축/암호화 계층을 서로 완전히 추상화한다는 생각이 마음에 들지 않습니다. 이미 설명했듯이 암호화된 데이터를 압축하는 등 어리석은 일을 하지 않도록 주의해야 합니다. 또한 속도 및/또는 보안 문제를 위해 압축을 비활성화하는 옵션을 제공해야 합니다. 암호화와 관련하여: 나중에 나머지를 위한 비암호화 모드가 있을 수 있지만 현재로서는 암호가 선택 사항이 아닙니다.

또한 압축된 파일은 그 자체로 추상화 수준(예: 물건을 다시 압축할 수 있음)으로 암호화 추상화와 함께 작동하지 않습니다.

Repository 개체가 너무 복잡하고 이를 해결하기 전에 전반적인 점검이 필요하다고 생각합니다. 지금 당장은 좋은 계획이 없습니다.

다양한 압축 알고리즘 및 옵션에 대해: 데이터에 대해 하나의 알고리즘(매개변수 집합 포함)을 선택하고 JSON 트리 구조를 압축하는 데 두 번째 알고리즘을 선택해야 한다고 생각합니다. 하지만 그게 전부입니다. 모든 선택 사항(예: 다른 구성 가능한 압축 알고리즘 및/또는 매개변수)에 대해 추가된 코드의 복잡성과 양에 대한 이점에 가중치를 두는 건전한 고려를 하고 싶습니다.

저를 오해하지 마십시오. 나는 restic에 기능을 추가하고 싶습니다. 그러나 특히 온디스크 형식을 수정하는 변경 사항의 경우 매우 좋은 인수가 필요합니다. 압축을 추가하는 일반적인 경우에는 이점을 볼 수 있지만 온디스크 형식의 복잡성과 변경 사항을 관리할 수 있어야 합니다.

다른 알고리즘과 매개변수가 필요합니다(리포지토리당뿐만 아니라 백업 실행당). "모든 사용 사례에 가장 적합한" 압축은 없습니다.

실용적인 예로서:

회사 서버에서 집에 있는 백업 서버로 백업을 합니다. ~700kbit/s의 dsl 업링크
이를 위해 나는 최고의 압축(lzma + 높은 수준과 같은)을 원합니다. cpu는 다음 패킷을 수락하기 위해 형편없는 연결을 기다리는 동안 밤에 많은 여가 시간을 가집니다.

같은 저장소에 집에 있을 때도 랩톱을 백업합니다. 무선 "N" 연결이 있습니다. 물론 lzma + 높은 수준을 사용하여 연결 속도를 늦추고 싶지는 않지만 lz4와 같이 속도가 전혀 느려지지 않는 매우 빠른 것을 원합니다. 나는 여전히 압축을 원하지만 lz4를 사용하지 않으면 약 2배의 공간이 필요합니다.

나는 여기에 lzma를 원하지만 거기에는 lz4를 원합니다.

그게 전부입니다 imho... 합리적인 기본값을 선택하고 너무 많은 구성을 노출하지 않도록 합시다. 그러면 적은 이득을 위해 많은 복잡성이 도입될 것입니다. imho.

Repository 개체가 너무 복잡하고 이를 해결하기 전에 전반적인 점검이 필요하다고 생각합니다. 지금 당장은 좋은 계획이 없습니다.

그럴 수 있지. 나는 repository.go를 뒤지기 시작했고 압축/압축 해제 단계를 삽입할 모든 위치를 찾았고 추가된 복잡성은 좋지 않았습니다. backend 인터페이스로 구현하면 갑자기 모든 암호화를 제거하고 백엔드 체인의 일부로 만들 수 있습니다. 압축 및 암호화를 포함하여 백엔드 부분의 대칭을 보장하는 일반 테스트를 만들 수 있습니다.

암호화와 관련하여: 나중에 나머지를 위한 비암호화 모드가 있을 수 있지만 현재로서는 암호가 선택 사항이 아닙니다.

이것이 백엔드 체이닝이 좋은 이유입니다. 암호화를 생략하거나(또는 통과 백엔드를 생성) 원활하게 작동합니다.

압축을 추가하는 일반적인 경우에는 이점을 볼 수 있지만 온디스크 형식의 복잡성과 변경 사항을 관리할 수 있어야 합니다.

이것은 내가 볼 수있는 가장 방해가되지 않는 방법이었습니다. '압축 파일' 문제를 해결할 수 있는 방법이 있는 경우 압축되지 않은 저장소는 이전 버전과 완전히 호환됩니다. 이전 클라이언트는 새 클라이언트와 함께 이전처럼 작동할 수 있습니다.

압축된 저장소는 분명히 그렇지 않지만 저장소가 압축된 경우에만 version 를 2로 변경할 수 있습니다. 이렇게 하면 이전 클라이언트가 실패하게 됩니다. 그러면 확인이 분명히 if cfg.Version > RepoVersion { 로 변경되어야 하지만 호환성 문제는 없습니다.

그게 전부입니다 imho... 합리적인 기본값을 선택하고 너무 많은 구성을 노출하지 않도록 합시다. 그러면 적은 이득을 위해 많은 복잡성이 도입될 것입니다. imho.

동의하다. 대부분의 알고리즘(lzma/deflate)은 동일한 압축 해제 형식 내에서 많은 유연성을 가지고 있습니다.

압축성을 테스트하기 위해 DataSmoke가 있습니다: https://github.com/Bulat-Ziganshin/DataSmoke

또한 pcompress는 다양한 압축 알고리즘을 선택합니다. https://github.com/moinakg/pcompress

스쿼시 압축 추상화 라이브러리에는 좋은 알고리즘 목록과 벤치마크가 있습니다. https://quixdb.github.io/squash/

여기에 텍스트 압축 벤치마크가 있습니다: http://mattmahoney.net/dc/text.html

쉬운 접근 방식은 항상 crypto/crypto.go 암호화/복호화 기능 내부를 필터링하는 것입니다.

gzip-compression-v1.patch.txt 머리에 적용할 수 있는 개념 증명 diff입니다.

@mappu 를 사용해 주셔서 감사합니다. 하지만 이를 구현하기 전에 전략에 동의해야 합니다. 열린 질문 (내 머리 꼭대기에서)은 적어도 다음과 같습니다.

• 압축은 언제 적용됩니까? (데이터? 메타데이터/JSON?)
• 어떤 알고리즘을 구현해야 할까요? @klauspost 에 몇 가지 제안 사항이 있는 것 같습니다. :)
• 클라이언트를 손상시키지 않고 저장소에 이것을 어떻게 저장합니까?

압축은 언제 적용됩니까? (데이터? 메타데이터/JSON?)

데이터는 분명히 그렇습니다.
Metadata/json, 어쩌면 무의미할 수도 있지만 JSON 데이터는 대부분 ASCII이고 산술 코딩/허프만 단계(gzip이 있음)의 이점이 있기 때문에 큰 메타데이터 파일에 도움이 될 수 있다고 생각합니다.

데이터/메타데이터는 항상 암호화되기 때문에 암호화/복호화 루틴에 추가하는 것은 "repository.go를 살펴보기 시작했고 압축/압축 해제 단계를 삽입할 모든 위치를 찾았습니다. 추가된 복잡성은 좋지 않았습니다." @klauspost의 .
또한 blob은 hash(ciphertext)가 아닌 hash(plaintext)라는 이름으로 저장되기 때문에 {{분명히 중복 제거에 필요합니다. 그렇지 않으면 임의의 IV가 중복 제거를 파괴할 것입니다}}. 중복 제거를 손상시키지 않고 이 작업을 수행하는 것이 안전합니다.

어떤 알고리즘을 구현해야 할까요? @klauspost 에 몇 가지 제안 사항이 있는 것 같습니다. :)

신경쓰지 마세요. @ThomasWaldmann의 말에 동의하지만 구성할 수 있어야 합니다. 적어도 --best 및 --fast 사용 사례에서는.

나는 순수 이동이고 golang 표준 라이브러리에 있고 Google에서 성능주의를 받기 때문에 gzip을 제안합니다. xz는 훨씬 더 강력한 느린 압축입니다. lz4는 훨씬 약한 빠른 압축입니다. gzip은 균형이 잡히고 쉽게 조정되지만, 어느 쪽도 극단에 도달하지 않습니다.

클라이언트를 손상시키지 않고 저장소에 이것을 어떻게 저장합니까?

저장소는 한 방향으로만 호환되어야 합니다. new restic이 이전 repo를 읽을 수 있는 한 old restic이 새 repo를 읽을 수 없어도 괜찮다고 생각합니다.

MAC 뒤에 태그 바이트를 추가할 수 있습니다. 존재하지 않음 - 압축 없음(이전 제한). 그런 다음 바이트는 사용된 압축 알고리즘을 나타낼 수도 있습니다. 0x01 gzip 0x02 lz4 정도.

다락방과 동일한(또는 더 나쁜) 문제가 있는 것 같습니다(현재 형식에서 사용되는 압축 유형/매개변수 바이트 없음).

다락방(보그)에서는 이전 형식이 gzip 전용이었고 처음 2바이트에서 gzip 형식을 감지할 수 있었기 때문에 운이 좋았습니다. 그래서 추가 바이트 없이 gzip을 유지하고(이전 저장소와 동일) 유형 바이트(압축 없음 또는 기타 압축용)를 추가했으며 처음 2gzip 바이트와 절대 모호하지 않습니다.

이전 형식이 원시 데이터인 경우에는 분명히 그렇게 할 수 없습니다.

아니요. 하지만 이 정보를 알리는 다른 방법이 있습니다. 예를 들어 암호화된 청크의 시작 부분에 있는 IV가 정확히 "NEWFORMAT"(1 :: 2^xyz 충돌 가능성)이면 새 형식으로 구문 분석합니다. 그렇게 "깨끗한" 것은 아니지만 실제로는 괜찮다고 생각합니다.

nmdc 잠금 핸드 셰이크에서 EXTENDEDPROTOCOL로 수행되는 것처럼.

오, 우리는 이와 같이 추한 일을 하지 않을 것이며 그럴 필요도 없습니다. 이것을 구현하기로 결정한 경우 팩 파일에는 각 blob에 대한 type 필드가 있습니다. 이것은 uint8 이며 현재 data 및 tree 대해서만 정의되어 있으며 compressed data 및 compressed tree 쉽게 추가할 수 있습니다. https://github.com/restic/restic/blob/master/doc/Design.md#pack 형식

현재로서는 이 기능을 높은 우선 순위로 생각하지 않습니다.

팩 형식에 새 blob 유형을 추가하는 것은 데이터 압축에 적합하지만 인덱스 압축은 제공하지 않습니다. 인덱스가 커질 수 있고 JSON의 압축률이 좋고 인덱스에 로컬 캐시가 없을 수도 있으므로 인덱스도 압축하는 것이 중요하다고 생각합니다.

쉽게 업그레이드할 수 있도록 new-restic이 old-repo와 함께 작동하는 것이 중요합니다. 매끄럽거나(선호) restic upgrade-repo 도구가 있어야 합니다(선호하지 않음).

그럼 이건 어때요?

모든 restic 명령은 이미 config 먼저 로드+복호화합니다.

• 첫 번째 config 바이트가 { 이면(json 객체 첫 번째 바이트) 전체 저장소는 이전 형식(압축되지 않음)입니다.
• 그렇지 않으면 첫 번째 config 바이트는 {태그 바이트}이고 전체 저장소는 새 형식입니다. 복호화 데이터 시작 부분의 {태그 바이트}는 압축 형식을 나타냅니다. 예 0x00 압축되지 않은 0x01 gzip

제안해 주셔서 감사합니다. 구성을 압축할 필요가 없다고 생각합니다. 이 파일은 정말 작은 파일이고 항상 JSON 형식으로 유지될 수 있고 필요에 따라 필드를 추가할 수 있습니다(예: 인덱스 파일 압축 여부).

어제 좋은 백업 솔루션을 찾다가 겨우 찾았습니다. 내 주요 관심사 중 하나는 내 데이터가 차지하는 공간을 제한하는 것입니다. 특히 S3와 같이 내가 비용을 지불하는 곳으로 데이터를 보내는 경우. Dedup은 확실히 도움이 될 것이지만 예상되는 압축은 백업 솔루션의 일부일 것입니다... https://github.com/restic/restic/issues/21#issuecomment -185920429에서 당신은 ( @fd0 ) 이렇게 말합니다. 우선순위가 낮습니다. 이유를 설명해 주시겠습니까? 어디에서나 볼 수 있는 로드맵이 있습니까?

또한 +1. ;)

현재 오래된 백업 데이터(#518)를 제거하는 작업을 하고 있습니다. 올바른 압축과 보안을 동시에 얻는 것은 쉽지 않은데, 이것을 저장소 형식으로 통합하는 방법에 대해 조금 더 생각해야 합니다.

우리는 압축을 구현할 것입니다(이 문제가 무엇인지 알고 나면), 아직 수행되지 않았을 뿐입니다. restic은 다소 새로운 프로젝트입니다. 저희와 함께 해주세요 :)

이 문제는 #116과 관련이 있습니다. 암호화 때문에 다른 도구로 백업을 압축할 수 없잖아요? 압축과 암호화를 선택 사항으로 만드는 것 사이에 어떤 우선 순위가 있습니까? (나는 먼저 압축에 베팅합니다!)
_이 문제에 대해 압력을 가해 죄송합니다. 저장소 형식을 주의해서 사용해야 한다는 말씀이 맞습니다!_

이것은 대답하기 쉽습니다. 압축이 먼저 구현됩니다.

현재로서는 암호화를 선택 사항으로 만들 계획이 없기 때문입니다. 맞추는 것도 너무 힘든 것 같아요. 이것은 선택 사항이 아니어야 하지만 (적어도 현재로서는) 암호화와 밀접하게 연결되어 있기 때문에 무결성에 대해 생각해야 합니다.

@fd0 제 질문에 답변해 주셔서 감사합니다. 내 개발 기술이 이것에 도움이 되었으면 합니다. 하지만 go는 거의 건드리지 않았으며 다른 xp의 대부분은 webdev 또는 sysadmin 스크립트에 있습니다.

압축이 "올바르고 안전하게" 수행되었는지 확인해야 한다는 데 전적으로 동의합니다. 그것이 일을 지연시킨다면, 그렇게 하십시오. :웃다:

https://github.com/viric/restic/tree/snappy 에서 restic에서 빠른 압축을 구현했습니다.

그냥 제안입니다. 기본적으로 나는 팩에 있는 블롭에 대한 빠른 압축/압축 해제를 추가했으며 약간의 블롭 유형 바이트를 표시로 사용합니다. 또한 팩 인덱스에 필드를 추가했습니다. PLength(일반 텍스트 길이)는 그때까지 저장되지 않았지만 "bloblength - crypto.Extension"으로 계산되었습니다.

일부 백업의 경우 공간을 덜 차지할 뿐만 아니라 더 빠르게 작동합니다(처리할 데이터가 적음).

모든 restic 테스트는 잘 통과합니다. 이전 restic 리포지토리에서 작동할 수 있지만 일반 restic(마스터의 저장소)은 새 blob을 처리할 수 없습니다.

나는 @fd0의 속도 목표에 덜 영향을 줄 것이라고 생각했기 때문에 snappy(https://github.com/golang/snappy)를 사용했습니다.

마스터에 압축 착륙에 대한 $50 현상금 추가

위에서 언급했듯이 미디어, 암호화된 파일 또는 이미 압축된 파일과 같이 압축할 수 없는 파일을 압축하지 않도록 구성할 수 없는 자동화된 방법이 있어야 합니다. 이 문제는 내용이 압축 가능하거나 압축할 수 없는 PDF와 같은 일부 컨테이너 형식으로 인해 악화됩니다.

@klauspost의 첫 번째 댓글에서 언급한 일정 시간 압축 모드와 같이 이를 투명하게 처리하는 알고리즘을 사용하는 것이 가장 쉽습니다.

그렇지 않으면 파일 유형 목록이 필요합니다. 블랙리스트는 절대 압축되지 않고 화이트리스트는 항상 압축되며 나머지는 파일의 작은 부분을 압축하려고 시도하고 크기 축소가 실패하면 포기합니다. 주어진 임계값 이상.

이것이 파일 수준이 아닌 청크에서 얼마나 잘 매핑되는지 확실하지 않습니다.

나는 그것을 암호화/암호 해독 패스에 추가하는 것에 반대합니다.
일부는 예측할 수 있고 결과 팩/블롭 길이는 예측할 수 없는/비밀 데이터의 일반 텍스트에 대한 정보를 누출할 수 있기 때문에 서로 다른 종류의 데이터를 혼합하고 싶지 않습니다.
이것이 "덜 멋지다"고 해도 파일별로 해야 한다고 생각합니다. 그러나 파일을 읽기 위해 수많은 팩 파일(각 BLOB이 하나만 중요함)의 압축 해제를 수행할 필요가 없다는 이점이 있습니다.

@teknico

위에서 언급했듯이 미디어, 암호화된 파일 또는 이미 압축된 파일과 같이 압축할 수 없는 파일을 압축하지 않도록 구성할 수 없는 자동화된 방법이 있어야 합니다.

수정된 수축 패키지는 이미 압축된 데이터 건너뛰기를 구현하며 코어당 ~250MB/s의 속도로 수행합니다. Go 1.7 수축은 가장 빠른 압축 수준에서만 지원합니다.

Snappy 및 LZ4는 유사한 건너뛰기 기능을 지원합니다.

일정 시간 압축 모드와 같이 이를 투명하게 처리하는 알고리즘을 사용하는 것이 가장 쉽습니다.

반드시 선택사항이어야 합니다. Go 1.7(현재 HuffmanOnly 및 이에 상응하는 것으로 불림)에서 이 모드는 입력에 관계없이 코어당 ~200MB/s를 지원합니다. 그러나 압축은 일반적으로 80MB/s/코어에서 작동하는 "최고 속도"에 비해 심각하게 저하됩니다.

@cfcs

이것이 "덜 멋지다"고 해도 파일별로 해야 한다고 생각합니다.

일반적으로 동의합니다. 나는 restic에 위로 읽어야 할 것이다. 각 팩 크기의 바이너리 크기는 암호화되지 않은 상태에서 사용할 수 있습니까?

@klauspost 개선 사항 중 일부가 Go 1.7 DEFLATE "BestSpeed" 모드에 병합된 것 같습니다. 맞습니까? 어쩌면 그것은 합리적인 기본값이 될 것입니다.

DEFLATE 형식을 사용하는 장점은 호환 가능한 비트스트림을 생성하는 다양한 압축기가 있으므로 압축 해제기에 완전히 투명하다는 것입니다.

Restic 작동 방식의 특성(파일을 얼룩으로 분할하고 나중에 얼룩만 처리)으로 인해 압축을 추가하는 가장 쉬운 방법은 얼룩 수준에서 수행하는 것입니다. 블롭을 압축해야 하는지 여부를 결정하기 위해 몇 가지 경험적 방법을 추가할 수 있지만 이것이 두 번째 단계가 될 수 있습니다.

Blob은 팩 파일로 결합된 다음 리포지토리에 저장됩니다. 팩 파일에는 (개별적으로 암호화된) 많은 Blob, (암호화된) 헤더, (암호화되지 않은) 헤더 길이가 차례로 포함됩니다. 복호화 키가 없는 공격자는 암호문, 헤더 길이 및 파일 길이만 볼 수 있습니다. 따라서 공격자는 팩 파일의 크기와 헤더 길이를 기반으로 특정 팩 파일에 있는 얼룩의 평균 크기를 계산할 수 있지만 그게 전부입니다. 인덱스 파일에는 모든 데이터(크기, 암호화된 크기, 나중에 압축된 크기)도 포함되지만 이 데이터도 암호화됩니다. 나는 여기에 어떤 위험도 보이지 않는다.

"압축 가능한" 테스트 휴리스틱은 오류가 발생하기 쉽고 비용이 많이 듭니다. AMD64의 중복 제거 패키지 에서 1차 조회 속도인 200MB/s/코어를 훨씬 초과하는 것은 어려울 것으로 예상됩니다.

또한 사용하는 압축기에 따라 크게 달라집니다. Snappy는 임의의 base 64 데이터를 압축할 수 없지만, 예를 들어 deflate는 압축할 것이므로 그 부분은 압축기에 맡길 것입니다. 우리는 Snappy, LZ4 및 deflate를 위해 내장되어 있습니다.

@fd0 죄송합니다. 파일 단위가 아니라 blob 단위를 의미했습니다.
우리가 가벼운 알고리즘을 선택하지 않는 한, 다소 CPU를 많이 사용하는 압축은 병목 현상이 될 가능성이 높습니다(AES 옆에 있으며 향후 AES-NI에서 처리되기를 희망합니다).

@fd0 - 빠른 "압축성 추정기"를 만들었습니다. https://play.golang.org/p/Ve5z3txkyz - 임의 데이터의 예측 가능성과 엔트로피를 추정합니다. 그러나 내가 언급했듯이 결정하는 것은 압축기에 달려 있습니다.

borg 1.1에는 2개의 "압축 결정자"가 있습니다.

1. 경로 패턴 일치를 기반으로 파일별로 결정( *.zip , *.mp3 , /htdocs/photos/* , ...)
2. 결정되지 않은 경우 청크별로 결정하고 lz4를 압축성 테스트로 사용합니다. 압축되는 경우 원하는 압축(lz4, zlib, lzma)으로 다시 압축하고, 그렇지 않은 경우 압축하지 마십시오.

@klauspost 흠, 그 테스트는 내 컴퓨터에서 그렇게 나쁘지 않습니다.

BenchmarkCompressibility-4           100      10345544 ns/op     810.84 MB/s

벤치마크 코드는 여기: https://gist.github.com/908c23123dda275a479cf931f2784f5d

Lz4에는 엔트로피 코더가 없으므로 여러 번 위음성이 발생합니다.
아마?

세 가지 모드가 필요하다고 생각합니다(전역적으로).

• 선형 시간 압축기로 모든 데이터 Blob 압축(기본값)
• 압축 없음
• 최대 압축(CPU 성능은 높지만 대역폭이 작은 사용자용)

나는 항상 트리 객체(JSON)를 압축하고 싶기 때문에 ASCII 텍스트에 대한 적절한 알고리즘을 선택해야 합니다.

그렇지 않으면 프로토타입을 구축하기 위해 @viric 과 함께 작업할 것입니다.

생각?

@klauspost 흠, 그 테스트는 내 컴퓨터에서 그렇게 나쁘지 않습니다

나는 항상 새로운 Go 컴파일러가 얼마나 나쁜 일을 할 수 있는지 잊어버립니다. 내가 예상했던 것의 적어도 두 배.

세 가지 모드가 필요하다고 생각합니다(전역적으로).

더 효율적인 압축기(대부분 LZMA)가 있지만 Deflate는 3가지를 모두 잘 수행합니다. 압축 없는 수축은 물론 필요하지 않지만, 물론 빠르고 최소한의 오버헤드가 있으므로 나중에 다른 것을 지정할 가능성과 함께 일반적인 수축 접근 방식을 사용할 수 있습니다.

나는 속도와 압축면에서 레벨 1과 Huffman 사이에 있는 또 다른 속도 향상 을 보기 시작했습니다. 그러나 현재로서는 시간이 조금 소중하고 새로운 것으로 넘어가기 전에 최종 Go 1.7 변경 사항 중 일부의 백포트를 테스트해야 합니다.

단일 압축 알고리즘만 원한다면 새로운 경쟁자 zstd를 살펴봐야 합니다: https://github.com/facebook/zstd

lz4와 같은 개발자가 개발했으며 gzip보다 압축률이 높으면서 3배 이상 빠릅니다. https://code.facebook.com/posts/1658392934479273/smaller-and-faster-data-compression-with -z표준/

Go에서 구현을 찾을 수 없었지만 zstd는 매우 유망해 보입니다.

공식 사이트 http://facebook.github.io/zstd/#other -이 Go 구현에 대한 링크: https://github.com/DataDog/zstd

아니면 순수한 Go 구현을 의미합니까?

예, 순수한 Go 구현을 의미했습니다. 현재 restic은 C 코드에 의존하지 않으며 이상적으로는 그렇게 유지하고 싶습니다.

압축 구현에 대한 예측이 있습니까?

압축 구현은 저장소 형식 변경에 따라 달라지며(계획/아이디어는 #628에 있음) 세심한 주의가 필요합니다. 따라서 압축이 추가되는 정확한 날짜는 없습니다. ;)

이를 위해 우리가 할 수 있거나 기여할 수 있는 것이 있습니까?

그렇게 생각하지 않습니다. 죄송합니다 :wink: 시간이 필요할 뿐입니다.

그래서 #790의 테스트 베드를 한 번 더 사용할 수 있다고 생각했습니다. 내 restic 빌드에서 모든 암호화를 제거한 다음 다시 한 번 전체 백업을 만들었습니다. 암호화된 것과 동일한 크기로 제공됩니다. 여기에는 놀라운 일이 아닙니다. 그러나 나는 저장소를 압축했고 내가 찾은 것은 다음과 같습니다.

35G backup-unencrypted
6.4G    backup-unencrypted.tgz2

무슨 차이! 비교를 위해 압축된 단일 데이터베이스 덤프의 크기는 다음과 같습니다.

1.7G    single-backup.sql.gz

위의 29가지가 있습니다. 일반 백업 대비 약 100배 절감!

암호화가 추가된 모든 위치를 찾았기 때문에 주식 gzip 구현으로 매우 간단하게 구성 가능한 압축을 추가할 수 있고 향후 다른 압축 엔진을 사용할 가능성이 있다고 생각합니다. 이의가 있으신가요?

(나는 아마도 성공하거나 실패하기 위해 2주간의 저녁 시간을 나 자신에게 줄 것이다.)

조사해 주시고 결과를 여기에 올려주셔서 감사합니다! 비슷한 결과를 예상했습니다. 솔직히 말해서 암호화폐를 제거하거나 선택 사항으로 만드는 어떤 것도 병합하지 않을 것입니다. 그것은 우리가 나중에 할 수 있는 일이지만 신중하게 계획해야 합니다.

압축을 추가하는 것이 처음에는 쉬워 보일 수 있지만 그렇지 않습니다. 우리는 실수로 restic을 예기치 않은 공격에 취약하게 만들지 않도록 매우 주의해야 합니다(이는 TLS 프로토콜에 여러 번 연속으로 발생했습니다(예, 이것은 다른 상황임을 알고 있습니다).

전체 프로젝트에서 가장 중요한 것은 코드가 아니라 저장소 형식입니다. 사용자들은 우리에게 데이터를 신뢰하고 오래 사용하여 데이터를 복원할 수 있는지 여부에 의존하므로 저장소 형식의 안정성이 가장 중요합니다. 따라서 압축을 지원하려면 먼저 저장소 형식의 다음 버전을 결정(및 구현)해야 합니다. 토론은 여기: https://github.com/restic/restic/issues/628

나는 당신이 이것을 구현하기를 열망하고 있다는 것을 알 수 있습니다. 그러나 우리가 저장소 형식에 동의하고 이 문제의 모든 각도에 대해 논의할 때까지 이것에 시간을 할애하지 마십시오. 감사 해요!

제거된 암호화에 관해서는 병합을 제안하지 않을 것입니다. 압축이 작동하는지 확인하기 위해서만 그렇게 했습니다 . 그리고 예, 이것은 신중하게 계획되어야 했습니다(아무도 갑자기 암호화가 비활성화된 저장소를 확인하는 기능을 잃고 싶어하지 않습니다).

json.Unmarshal 를 사용하기 때문에 구성에 원하는 만큼 새 키를 추가할 수 있습니다. JSON에서 찾을 수 없는 경우 기본값을 그대로 유지합니다.

알고리즘 선택이 요점이 아니라 이해됨: 하지만 향후 참조를 위해 Brotli 는 강력한 경쟁자로 보입니다.

내가 아는 한 Brotli 압축은 매우 느리기 때문에(iirc 60 x gzip) 백업에 일반적이지 않은 쓰기 및 압축에 비해 매우 자주 읽는 데이터에 권장됩니다. 그러나 예, 아직 세부 사항으로 들어가지 않겠습니다. :)

이것은 다양한 압축 알고리즘에 대한 좋은 개요를 제공합니다.

Brotli는 항상 더 빠르거나 더 나은 압축을 제공합니다. 압축 수준에 따라 다릅니다.

@ibib 어떻게 그 결론에 도달합니까? 제 생각에는 brotli 가 다른 대부분(혼합 데이터 세트에서)보다 느리게 보이지만 특히 놀라운 압축률을 달성하지 못하는 것 같습니다. 특정 종류의 구조화된 데이터에 더 적합할까요?

Squash 벤치마크 의 비교에 나열된 것처럼 세 가지 매개변수를 따라야 합니다.

• 달성된 압축률: 디스크 공간(및 백엔드에 대한 I/O)을 절약하기 위해 압축률이 중요합니다.

• 압축 속도: 블록을 추가할 때마다 이 작업을 수행하기 때문에 중요하므로 AES-NI 및 일반 I/O를 따라갈 수 있어 병목 현상이 발생하지 않도록 해야 합니다. 이러한 새로운 알고리즘(예 zstd , lz4 , brotli 과 반대되는 웹 브라우저 사용 사례가 있기 때문에 압축 해제보다 느리게 압축하는 알고리즘을 선택하고 싶지 않을 것 입니다 brotli )에 최적화되어 있습니다("한 번 압축, 자주 압축 해제"와 대조적으로 "자주 압축, 거의 압축 해제"가 있음).

• 감압 속도: 감압 속도는 복원할 때만 관련이 있습니다. 느린 복원이 괜찮다면 느린 압축 해제 속도를 받아들일 수 있습니다. 반면에 천천히 압축을 풀고 싶지 않은 메타데이터도 있으므로 두 가지 다른 알고리즘이 필요할 수도 있습니다.

density 는 압축 비율 측면에서 특히 효율적이지는 않지만 가장 빠른 것 같습니다. 병목 현상이 없다는 점에서 (평균적으로) 거의 무료로 2:1 압축 비율을 얻을 수 있을 것 같습니다. 4:1을 원하면 다른 알고리즘을 선택해야 하지만 결국 앉아서 기다리게 될 것입니다.

우리는 또한 두 가지(적어도?) 다른 종류의 데이터를 가지고 있습니다. 및 데이터 청크. 둘은 다르게 사용되며 서로 다른 알고리즘을 선택하는 것이 의미가 있는지 논의할 수 있을 것 같습니다. 나는 개인적으로 우리가 하나의 알고리즘(우리가 무엇을 선택하든지 간에)을 고수하여 (새로운 언어로든 무엇이든) Restic을 재구현하는 것이 부당하게 어렵게 되지 않도록 해야 한다고 생각합니다. 그리고 코너 케이스에 대해 테스트하기 어렵기 때문에 두 가지 흥미로운 압축 알고리즘의 버그에 노출되지 않도록 합니다.

나는 당신이 제안한 절충안(trade-offs)에 동의하지 않을 수 없습니다. 백업은 편리한 시간에 백그라운드에서 실행할 수 있습니다(아마도 좋은 10). 그것들을 복원하는 것은 시간 압박 하에서 발생합니다. 내가 보는 관련 절충은 블록 크기와 압축 비율 사이입니다. 너무 작은 블록은 잘 압축되지 않고 메타데이터 오버헤드를 증가시킵니다. 블록이 너무 크면 중복 제거 비율이 감소합니다. 대부분의 압축 알고리즘에서 더 높은 수준의 설정은 작은 입력에 대한 압축 비율을 향상시키지 않습니다.

또한 압축률이 높으면 사용자가 동일한 공간에 더 많은 버전의 데이터를 보관할 수 있습니다.

snappy를 사용한 테스트 결과가 1) 더 작은 백업 크기(압축, 정상), 2) 더 빠른 백업 및 복원(더 적은 데이터 암호화, HMAC 및 전송)이라는 결과를 얻었음을 기억하십시오. 아주 저렴한 노트북을 사용합니다.

@cfcs gzip과 brotli의 비교를 참조했습니다.

여기에서 brotli는 항상 더 빠르고 더 나은 압축을 제공합니다.

@Crest 충분히 공평합니다. 아마도 다른 사용 사례가 있을 것입니다. 저는 restic 당신과 같은 방식으로 사용하지 않을 뿐입니다. 랩톱 백업을 수행하고 랩톱을 가지고 떠날 수 있도록 빨리 완료하기를 원합니다. 백업 속도가 그다지 중요하지 않은 서버 또는 지속적으로 연결된 기타 머신의 백업에 대해 이야기하고 있는 것으로 알고 있습니다. 마찬가지로 시간 압박을 받아 모든 데이터를 복원할 필요가 없습니다. 시간 압박이 있는 경우(전문적인 상황에서 사용하기 때문에?) 필요한 데이터를 선택적으로 복원하고 나머지 작업은 나중에 진행할 수 있습니다.

당신은 "여러 번 작은 입력"에 대해 아주 좋은 지적을 합니다.

@viric 당신이 언급하는 효과는 Transfer + Processing 섹션의 Squash 벤치마크에서 고려됩니다 :-)

@ibib 아, 잡았다!

@ibib 그 차트를 어디서

차트 출처: https://quixdb.github.io/squash-benchmark/

brotli 및 zstd로 몇 가지 테스트를 수행했으며 결과가 스쿼시 벤치마크의 결과와 전혀 일치하지 않는다는 것을 알았습니다. 그런 다음 그 벤치마크가 1,5년이라는 것을 이해했습니다.

zstd는 나를 위해 아주 잘 작동합니다. 빠른 + 높은 비율, 그리고 그 "레벨"은 빠른 비율과 높은 비율 사이에 매우 큰 범위를 허용합니다. 좋은 일이야.

Brotli는 저에게 매우 느리게 작동하며 훨씬 빠른 zstd보다 더 나은 압축 비율이 없습니다. 그리고 brotli는 영어 텍스트의 작은 파일에 초점을 맞춘 것 같습니다(영어 사전 포함). html 압축 또는 이와 유사한 경우.

내가 찾은 더 최근의 벤치마크: https://github.com/inikep/lzbench

그래서 LZMA 압축으로 zbackup 에 대해 테스트 베드를 한 번 더 던졌습니다.

35G backup-unencrypted
6.4G    backup-unencrypted.tgz
2.5G    zbackup

인상적이지 않나요?

zbackup에는 고유한 제한 사항과 단점이 있습니다.

따라서 @viric lzbench 링크에 따르면 가장 적절한 압축기는 백업 속도를 늦추지 않는 것(높은 압축 속도?, >200MB/sec)이고 실제로는 좋은 압축률(>=50)을 가지고 있는 것입니다. 맞죠?

그래서 나는 비율로 정렬된 표에서 결과를 걸러냈습니다.

또한 Go 구현에 대해 _빠른_ 검색을 수행했습니다(그래서 테이블에 보관했습니다). 취소선은 거의 모든 것을 제거한 구현을 찾지 못했음을 의미합니다. 빠른 검색이었기 때문에 결과를 보관했습니다. 래퍼에 불과한 zstd에 대한 예외입니다.

| 압축기 이름 | 압축| 압축을 풉니다.| 비교 크기 | 비율 |
| --------------- | -----------| -----------| ----------- | ----- |
| zstd 1.1.4 -1 | 242MB/s | 636MB/s | 73654014 | 34.75 |
| 도마뱀 1.0 -30 | 258MB/s | 867MB/s | 85727429 | 40.45 |
| 밀도 0.12.5 베타 -3 | 253MB/s | 235MB/s | 87622980 | 41.34 |
| 깁펠리 2016-07-13 | 233MB/s | 451MB/s | 87931759 | 41.49 |
| 쪼꼬미 2011-12-24 -9 | 257MB/s | 1263MB/s | 90360813 | 42.63 |
| 쪼꼬미 2011-12-24 -6 | 295MB/s | 1268MB/s | 92090898 | 43.45 |
| 퀵 1.5.0 -1 | 346MB/s | 435MB/s | 94720562 | 44.69 |
| 도마뱀 1.0 -20 | 284MB/초 | 1734MB/초 | 96924204 | 45.73 |
| 쪼꼬미 2011-12-24 -3 | 352MB/초 | 1222MB/s | 97255186 | 45.89 |
| lzrw 1991년 7월 15일 -4 | 243MB/s | 392MB/초 | 100131356 | 47.24 |
| lzo1x 2.09 -1 | 394MB/s | 551MB/s | 100572537 | 47.45 |
| lz4 1.7.5 | 452MB/s | 2244MB/s | 100880800 | 47.60 |
| fastlz 0.1 -2 | 243MB/s | 469MB/초 | 100906072 | 47.61 |
| lzo1y 2.09 -1 | 397MB/초 | 556MB/s | 101258318 | 47.78 |
| lzo1x 2.09 -15 | 406MB/s | 549MB/초 | 101462094 | 47.87 |
| 밀도 0.12.5 베타 -2 | 480MB/s | 655MB/s | 101706226 | 47.99 |
| lzf 3.6 -1 | 251MB/s | 565MB/s | 102041092 | 48.14 |
| 날렵한 1.1.4 | 327MB/s | 1075MB/s | 102146767 | 48.19 |
| blosclz 2015-11-10 -9 | 220MB/s | 696MB/초 | 102817442 | 48.51 |
| 쪼꼬미 2011-12-24 -0 | 384MB/s | 1221MB/s | 103072463 | 48.63 |
| lzo1x 2.09 -12 | 418MB/s | 550MB/s | 103238859 | 48.71 |
| 도마뱀 1.0 -10 | 360MB/s | 2625MB/s | 103402971 | 48.79 |
| fastlz 0.1 -1 | 235MB/s | 461MB/s | 104628084 | 49.37 |
| lzrw 1991년 7월 15일 -3 | 226MB/s | 449MB/초 | 105424168 | 49.74 |
| lzf 3.6 -0 | 244MB/초 | 550MB/s | 105682088 | 49.86 |
| lzo1x 2.09 -11 | 424MB/s | 560MB/s | 106604629 | 50.30 |
| lz4fast 1.7.5 -3 | 522MB/s | 2244MB/s | 107066190 | 50.52 |
| 토네이도 0.6a -1 | 233MB/s | 334MB/s | 107381846 | 50.66 |
| 멤피 | 8657MB/s | 8891MB/s | 211947520 |100.00 |

LZ4가 가장 적합한 압축기처럼 보입니까?

있는 경우 lz4(>=1.7.0 r129) 및 zstd(>=1.3.0)를 원한다고 가정합니다. 우리는 또한 borgbackup을 위해 이것을 사용합니다.

그러나 zstd는 lz4 속도에서 더 나은 속도까지 하나의 단일 정수로 매우 조정할 수 있습니다.
xz 압축보다. 그것은 밀도의 행복한 사용자를 느리게 만들 것입니다.
압축 및 빠른 압축. zstd는 말할 것도 없고
압축 노력에 관계없이 매우 빠르게 압축을 풉니다.

lz4는 목적이 매우 좁습니다.

2017년 12월 16일 토요일 09:50:49AM -0800에 TW는 다음과 같이 썼습니다.

있는 경우 lz4 및 zstd를 원한다고 가정합니다. 우리는 또한 borgbackup을 위해 이것을 사용합니다.

--
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/restic/restic/issues/21#issuecomment -352199097

--
(Escriu-me xifrat si saps PGP / Write ciphered if you know PGP)
PGP 키 7CBD1DA5 - https://emailselfdefense.fsf.org/

음.. https://github.com/restic/restic/issues/21#issuecomment -250983311 에 따르면 restic 종속성을 무료로 유지하기 위해 zstd는 현재로서는 옵션이 아닙니다. 또한 특허/라이선스 문제에 대한 몇 가지 스레드가 있습니다.

xz 및 높은 압축률의 경우 낮은 압축 설정에서도 표에 따르면 가장 빠른 압축률은 약 15MB/sec입니다.

빠른 백업에 대한 요구 사항이 낮아지면(예: >=30MB/sec) 다음을 추가할 수 있습니다.

| 압축기 이름 | 압축| 압축을 풉니다.| 비교 크기 | 비율 |
| --------------- | -----------| -----------| ----------- | ----- |
| xz 5.2.3 -9 | 1.70MB/s | 56MB/초 | 48745306 | 23:00 |
| xz 5.2.3 -6 | 1.89MB/s | 58MB/s | 49195929 | 23.21 |
| xz 5.2.3 -3 | 4.18MB/s | 55MB/s | 55745125 | 26.30 |
| zstd 1.1.4 -8 | 30MB/s | 609MB/s | 61021141 | 28.79 |
| 즐링 2016-01-10 -2 | 32MB/s | 136MB/초 | 61917662 | 29.21 |
| xz 5.2.3 -0 | 15MB/s | 44MB/s | 62579435 | 29.53 |
| 즐링 2016-01-10 -0 | 38MB/s | 134MB/s | 63407921 | 29.92 |
| zstd 1.1.4 -5 | 88MB/s | 553MB/s | 64998793 | 30.67 |
| lzfse 2017-03-08 | 48MB/s | 592MB/s | 67624281 | 31.91 |
| libdeflate 0.7 -6 | 64MB/s | 609MB/s | 67928189 | 32.05 |
| 브로틀리 2017-03-10 -2 | 98MB/s | 289MB/s | 68085200 | 32.12 |
| zstd 1.1.4 -2 | 185MB/s | 587MB/s | 70164775 | 33.10 |
| 토네이도 0.6a -4 | 91MB/초 | 197MB/s | 70513617 | 33.27 |
| libdeflate 0.7 -3 | 96MB/초 | 602MB/s | 70668968 | 33.34 |
| 엑스팩 2016-06-02 -1 | 98MB/s | 506MB/s | 71090065 | 33.54 |
| 토네이도 0.6a -3 | 119MB/초 | 188MB/s | 72662044 | 34.28 |
| libdeflate 0.7 -1 | 117MB/s | 570MB/s | 73318371 | 34.59 |
| 도마뱀 1.0 -42 | 90MB/s | 938MB/s | 73350988 | 34.61 |
| zstd 1.1.4 -1 | 242MB/s | 636MB/s | 73654014 | 34.75 |

여러 deflate 구현이 있지만 비교할 수 있는지 확실하지 않습니다.
참고를 위해 왼쪽 xz
zstd는 매우 유망해 보입니다. Go 구현이 없다는 것이 너무 아쉽습니다.

@viric zstd는

그러나 여러 압축기가 아닌 하나의 압축기만 갖고 싶다면 zstd가 더 유연합니다.

내 지각을 용서하십시오. 일부 의견:

압축 속도: 블록을 추가할 때마다 이 작업을 수행하기 때문에 중요하므로 AES-NI 및 일반 I/O를 따라갈 수 있어 병목 현상이 발생하지 않도록 해야 합니다. 우리는 이러한 새로운 알고리즘(zstd, lz4, brotli와 같은)이 최적화된 웹 브라우저의 반대 사용 사례가 있기 때문에 압축 해제보다 느리게 압축하는 알고리즘을 선택하고 싶지 않을 것입니다("자주 압축하고 드물게 압축 해제" "한번 압축하고 자주 압축 해제"와 반대).

아니요, 하드웨어 가속 AES 속도로 압축할 필요가 없습니다. 압축은 크기에 대한 거래 시간에 관한 것입니다. 압축된 백업은 더 오래 걸릴 것으로 예상됩니다.

예를 들어, 개인 백업에 restic을 사용하는 대신 Obnam을 계속 사용하고 있습니다. 왜냐하면 내가 저장하는 작은 서버 중 하나에서 압축하지 않으면 맞지 않기 때문입니다. 백업은 이미 몇 시간이 걸리며 백그라운드에서 실행되므로 나도 알아차리지 못합니다.

나는 restic의 압축 백업이 더 오래 걸리더라도 상관하지 않습니다. 사실, 나는 그들이 그렇게 하기를 기대하며, 그것은 내가 해야 할 절충안입니다. 이런 종류의 압축이 없으면 restic은 나에게 유용하지 않을 것입니다.

감압 속도: 감압 속도는 복원할 때만 관련이 있습니다. 느린 복원이 괜찮다면 느린 압축 해제 속도를 받아들일 수 있습니다. 반면에 천천히 압축을 풀고 싶지 않은 메타데이터도 있으므로 두 가지 다른 알고리즘이 필요할 수도 있습니다.

복원은 백업보다 훨씬 덜 자주 수행되므로 압축 해제 속도는 그다지 중요하지 않습니다. 누군가는 종종 시간 압박을 받아 수행된다고 언급했습니다. 이것은 사실이지만 복원이 백업만큼 빠르거나 백업에 가까운 곳에서 이루어져야 한다는 의미는 아닙니다.

우리는 또한 두 가지(적어도?) 다른 종류의 데이터를 가지고 있습니다. 및 데이터 청크. 둘은 다르게 사용되며 서로 다른 알고리즘을 선택하는 것이 의미가 있는지 논의할 수 있을 것 같습니다.

인덱스를 압축할 필요가 전혀 없을 수도 있습니다(또는 반드시 좋은 생각일 수도 있음). 인덱스는 고유한 데이터를 저장하는 것이 전체 목적이기 때문에 처음에는 잘 압축되지 않을 것 같습니다.

나는 개인적으로 우리가 하나의 알고리즘(우리가 무엇을 선택하든지 간에)을 고수해야 한다고 생각합니다. 그래야 (새로운 언어로든 무엇이든) Restic을 재구현하는 것이 비합리적으로 어렵게 되지 않습니다. 그리고 코너 케이스에 대해 테스트하기 어렵기 때문에 두 가지 흥미로운 압축 알고리즘의 버그에 노출되지 않도록 합니다.

이러한 우려를 이해하지만 그것은 실수라고 생각합니다. 최소한 repo 형식은 여러 압축 알고리즘을 허용해야 나중에 더 새로운 알고리즘이 추가될 수 있습니다. 사용자가 사용하려는 것을 선택할 수 있도록 압축을 위한 플러그형 모듈이 있어야 합니다. 예를 들어 사용자가 원하는 경우 설치할 수 있는 restic-xz , restic-zstd 등과 같은 데비안 패키지를 상상할 수 있습니다. 해당 알고리즘을 사용합니다. 백업 데이터의 압축은 restic이 압축 기능에 일부 데이터를 넘겨주고 다시 압축되도록 추상화해야 하며, restic은 그 사이에 무슨 일이 일어나는지 신경 쓰지 않아야 합니다. 감압도 마찬가지입니다.

빠른 백업에 대한 요구 사항이 낮아지면(예: >=30MB/sec) 다음을 추가할 수 있습니다.

그것은 나에게 합리적으로 보인다. 로컬 백업은 한 종류일 뿐입니다. 네트워크 백업은 압축 속도로 인해 병목 현상이 발생할 가능성이 적습니다.

그러나 사용자가 필요에 따라 적절한 솔루션을 선택할 수 있도록 조정할 수 있어야 합니다.

맥주에 10$ 현상금 추가::)

🍺++

다른 사람이 기여하고 싶은 경우 여기에 BountySource에 대한 링크가 있습니다.

https://api.bountysource.com/badge/issue?issue_id=6096108

이것이 사용자가 구성할 수 있는 방식으로 구현될 수 있는지 궁금합니다. 그래서 속도와 크기의 선택은 사용자가 결정할 수 있습니다. 기본값으로 더 높은 압축을 선호합니다.

언제 도착할지 결정합시다. 기록을 위해: 나는 속도 대 크기 측면에서 사용자에게 약간의 제어 권한을 주는 것이 좋습니다.

압축 구현이 필요한 나머지는 +1입니다. 나는 restic을 사용하여 VM 이미지를 backblaze에 백업하고 업로드하기 전에 압축할 수 있기를 원합니다. 내 사용 사례에서는 전송/저장된 데이터의 크기를 줄이기 위해 거의 무한한 시간/CPU를 교환할 것입니다. 나는 속도가 일부 사람들에게 더 중요한 문제라는 것을 알고 있습니다. 여러 알고리즘을 선택할 수 있는 플러그형 아키텍처가 핵심입니다.

이 문제에 대해 더 자세히 살펴보는 동안 테스트에 도움이 되어 기쁩니다.

@fd0 restic 코드 기반 작업을 한 지 꽤 되었습니다. 좋은 접근 방식과 내가 어디를 봐야하는지에 대한 빠른 방향을 제시할 수 있습니까?

@klauspost 기술적인 수준에서 압축을 추가하는 것이 아니라 수행하기 쉽지만 이전 버전과 호환되는 방식으로 repo 형식 업그레이드를 처리하는 방법입니다. 저는 현재 아카이버 부분을 다시 작성하느라 바쁩니다(#549와 같은 추악한 것들이 사라지도록). 그 후에 압축을 추가한 다음 repo v2로 전환하고 싶습니다.

우리가 사용해야 하는 압축 알고리즘에 대해 어떻게 생각하십니까? 세 가지 모드를 지원할 생각입니다.
1) 압축 없음
2) "선형 시간" 압축(많은 CPU 부하를 추가하지 않음)
3) "최대 압축"

첫 번째 모드와 두 번째 모드가 같을 수도 있지만 아직 확실하지 않습니다.

zstd와 같은 것을 기본 Go 코드로 사용할 수 있다면 가장 좋을 것입니다. Damian은 Java 또는 C 버전을 이식하는 것이 많은 작업이 아닐 수 있다고 암시했습니다. https://twitter.com/dgryski/status/947259359628738560, 시도해 볼 수 있도록 내가 할 수 있는 일이 있습니까? :)

나는 zstd 형식 사양을 보았고 나에게 구현하기가 쉽지 않습니다. Java 소스는 ​​압축 해제만 가능합니다.

빠른 압축을 위해 LZ4는 매우 잘 작동합니다. Go 포트는 훌륭합니다. zstd가 더 나을 것이지만 cgo 구현을 사용하지 않으려면 시도하고 테스트한 패키지를 사용하겠습니다.

중도의 경우 수축 압축은 여전히 ​​좋은 속도/압축입니다. 등의 테스트를 잘 받았습니다.

고압축은 조금 더 까다롭습니다. 그러나 github.com/ulikunitz/xz 패키지에 기본 LZMA(2) Go 구현이 있는

압축 단계를 삽입할 자연스러운 위치를 찾기 위해 소스를 살펴보았습니다. 나에게 의미가 있었던 것은 여기에서 압축을 하고 여기 에서 압축을 푸는 것이었

내가 만든 "압축성 추정기"를 살펴볼 수도 있습니다. 데이터 덩어리가 얼마나 압축 가능한지 빠르게 추정할 수 있습니다. 일반적으로 >500MB/s에서 작동하므로 압축하기 어려운 데이터를 빠르게 거부하는 데 사용할 수 있습니다.

내가 만든 "압축성 추정기"를 살펴볼 수도 있습니다. 데이터 덩어리가 얼마나 압축 가능한지 빠르게 추정할 수 있습니다. 일반적으로 >500MB/s에서 작동하므로 압축하기 어려운 데이터를 빠르게 거부하는 데 사용할 수 있습니다.

압축률 추정기를 좋아하십시오! 압축할 수 없는 데이터를 압축하려는 시도를 피하면 많은 속도를 얻을 수 있습니다.

Zstd에는 다음과 같은 것이 내장되어 있습니다. [1]

Zstd는 압축할 수 없는 데이터를 더 빠르게 전달합니다. > 1GB/s를 예상하십시오.

나는 그것에 대한 명시적인 벤치마크를 찾지 못했지만.

xz 패키지는 lzma에게 좋은 거래처럼 보입니다. 기본 설정으로 몇 가지 빠른 테스트를 수행했습니다.

| 알고리즘 | 수준 | 크기 | 특대 | 밀리 | 메가바이트/초 | 비율 |
|----------|-------|------------|----------|---- ----|--------|--------|
| lz4 | - | 1000000000 | 625968314 | 5454 | 174.85 | 62.60% |
| 플랫텍 | 1 | 1000000000 | 391051805 | 12367 | 77.11 | 39.11% |
| 플랫텍 | 5 | 1000000000 | 342561367 | 20164 | 47.3 | 34.26% |
| 플랫텍 | 9 | 1000000000 | 324191728 | 43351 | 22 | 32.42% |
| 이즈마2 | | 1000000000 | 291731178 | 149437 | 6.38 | 29.17% |
| 이즈마 | | 1000000000 | 291688775 | 161125 | 5.92 | 29.17% |

매우 합리적인 속도/압축 절충안. 모두 enwik9 - 중간 압축 가능한 텍스트 본문의 단일 코어 성능입니다. 분명히 저는 전체 VM 이미지나 더 혼합된 콘텐츠가 포함된 10GB 코퍼스 와 같은 것을 테스트할 시간이 없었습니다.

lzma2가 표준 lzma에 비해 현재 구현에서 많은 것을 제공하는 것 같지 않습니다. 작은 블록을 다루기 때문에 그 차이는 아주 작아야 합니다.

Zstd에는 이와 같은 것이 내장되어 있습니다.

예, lz4 및 deflate와 마찬가지로 전용 기능만큼 빠르지는 않습니다.

zstd는 의심할 여지 없이 정말 인상적입니다. cgo 구현을 사용한 벤치마크:

| 수준 | 크기 | 특대 | 밀리 | 메가바이트/초 | 비율 |
|---------|------------|--------------|--------|--------- -|--------|
| 1 | 1000000000 | 358512492 | 5100 | 186.96 | 35.85% |
| 2 | 1000000000 | 332265582 | 6264 | 152.24 | 33.23% |
| 3 | 1000000000 | 314403327 | 8099 | 117.75 | 31.44% |
| 4 | 1000000000 | 310346439 | 8588 | 111.04 | 31.03% |
| 5 | 1000000000 | 305644452 | 12739 | 74.86 | 30.56% |
| 6 | 1000000000 | 292551252 | 18531 | 51.46 | 29.26% |
| 7 | 1000000000 | 287414827 | 23212 | 41.08 | 28.74% |
| 8 | 1000000000 | 282783804 | 27811 | 34.29 | 28.28% |
| 9 | 1000000000 | 280432907 | 31752 | 30.03 | 28.04% |

내가 뭔가를 놓친 것을 용서하십시오. 그러나 이전에 이러한 질문에 대한 답변을 제대로 보지 못했습니다.

1. 파일 수준이 아닌 청크 수준의 압축에 대해 이야기하고 있는 것 같습니다. 맞습니까?
2. 그렇다면 단일 파일의 여러 청크에 중복된 데이터가 저장되고 각 청크에 대해 압축되므로 효율성이 분명히 제한됩니다.
3. 그러나 이는 분명히 청크 크기에도 달려 있습니다.
4. 그렇다면 평균 청크 크기는 얼마입니까? 이것이 압축이 얼마나 유용한지에 중요한 요소인 것 같습니다.
5. 청크 크기가 상당히 작은 경우 압축률이 높은 파일에 대해 전체 파일, 사전 청크 압축을 고려해야 합니다(예: @klauspost 의 추정기 사용). 예를 들어, 50MB 텍스트 파일(예: 로그 파일, 큰 조직 모드 파일 등)은 단일 파일로 압축될 가능성이 높습니다. 그러나 먼저 청크된 다음 각 청크가 인덱스를 공유하지 않고 개별적으로 압축되면 압축의 효율성(IIUC)이 크게 제한됩니다.

감사 해요.

전체 파일을 압축하면 중복 제거 알고리즘이 변조되어 효율성이 떨어질 수 있습니다.

그 외에 공간 측면 에서 준다는 사실을 잊지 마십시오. 압축된 데이터의 크기에서 데이터 내용에 대한 교육적인 추측을 할 수 있습니다. 나는 이것이 전에 언급되었다고 생각하지만 여전히 그렇습니다.

@알파파파

파일 수준이 아닌 청크 수준의 압축에 대해 이야기하고 있는 것 같습니다. 맞습니까?

예, 청크 수준에서.

그렇다면 단일 파일의 여러 청크에 중복된 데이터가 저장되고 각 청크에 대해 압축되므로 효율성이 분명히 제한됩니다. 그러나 이는 분명히 청크 크기에도 달려 있습니다. 그렇다면 평균 청크 크기는 얼마입니까? 이것이 압축이 얼마나 유용한지에 중요한 요소인 것 같습니다.

우리는 1MiB를 목표로 하고 있지만 최대 8MiB까지 클 수 있습니다.

청크 크기가 상당히 작은 경우 압축률이 높은 파일에 대해 전체 파일, 사전 청크 압축을 고려해야 합니다(예: @klauspost 의 추정기 사용). 예를 들어, 50MB 텍스트 파일(예: 로그 파일, 큰 조직 모드 파일 등)은 단일 파일로 압축될 가능성이 높습니다. 그러나 먼저 청크된 다음 각 청크가 인덱스를 공유하지 않고 개별적으로 압축되면 압축의 효율성(IIUC)이 크게 제한됩니다.

처음에는 청크 수준에서 압축을 통합하고 실제 시나리오에서 압축이 얼마나 잘 수행되는지 확인하고 싶습니다. 나중에 이 아이디어를 다시 살펴볼 수 있습니다.

@klauspost 시간을 내어 일부 알고리즘/구현 및 권장 사항을 벤치마킹해 주셔서 감사합니다. 감사합니다! zstd가 있으면 좋겠지 cgo 에 의존하지 않는 것이 프로젝트 전체에 훨씬 더 중요하다고 생각합니다. 압축률 추정기를 사용하는 것은 좋은 아이디어입니다. 저는 그것을 좋아합니다.

압축/압축 해제를 추가하기 위해 언급한 곳은 좋은 것 같지만 다른 곳에서 해당 메타데이터를 추적해야 합니다. 팩 헤더의 바이트에 있는 비트에 의미를 추가할 것이라고 생각합니다( http://restic.readthedocs.io/en/latest/100_references.html#pack -format 참조). 매우 신중하게 작업해야 하는 부분입니다.

자, #1494로 마치겠습니다. 그러면 이 문제가 해결되는 것을 볼 수 있습니다.

@sanmai re: side-channels: 원래 제가 가져왔습니다.
다양한 솔루션이 제안되었으며 개인적으로 다음 사항에 만족합니다.

• 압축 사용을 허용/차단하기 위한 구성 옵션이 있음(파일 포함을 위해 사용하는 것과 유사)

또 다른 아이디어는 팩 파일에서 청크 경계를 숨기려고 시도하는 것인데, 이론적으로 말하면 더 어렵게 만들지만 네트워크 쓰기 및 청크가 기록된 파일 시스템 범위 와 같은 사이드 채널은 여전히 ​​시간을 정할 수 있다고 생각합니다. 등등은 경계를 추론하는 데 사용될 수 있으므로 가장 안전하고 쉬운 것은 민감한 데이터를 압축하지 말라고 조언하는 것입니다.

이것은 굉장할 것입니다! :맥주: +$10

그냥 던지고 lzma 또는 더 일반적인 압축 알고리즘을 제쳐두고 실행 길이 인코딩이나 제로 스쿼싱은 어떻습니까? 아니면 충분한 사람들에게 충분히 유용하지 않을까요?

(나는 이 사냥에 개가 있고, 나는 종종 많은 침묵으로 거대한 WAV 파일을 백업하고 있습니다.)

+$15

그냥 던지고 lzma 또는 더 일반적인 압축 알고리즘을 제쳐두고 실행 길이 인코딩이나 제로 스쿼싱은 어떻습니까? 아니면 충분한 사람들에게 충분히 유용하지 않을까요?

또한 대부분 빈 공간/스파스 파일이 있는 VM 드라이브를 백업하는 데 유용합니다(restic이 스파스 파일 백업/복원을 이미 지원하는지 확실하지 않음)

@bherila restic은 아직 스파스 파일 보관/복원을 지원하지 않습니다. 파일은 0이 많이 포함된 것처럼 저장소에 저장됩니다. 이러한 큰 0 블록은 중복 제거되므로 저장소에서 많은 공간을 차지하지 않습니다. 그러나 복원의 경우 "구멍"이 없는 일반(희소하지 않은) 파일로 끝납니다.

방금 확인하고 싶었습니다. 이미 일종의 압축이 있습니까? 데이터가 50GB인 컴퓨터를 포함하여 여러 대의 컴퓨터를 백업했는데 서버에서 훨씬 적은 수를 얻었습니다.

# du -shc /home/restic/
40G     /home/restic/
40G     total

@Alwaysin 물론 일부 파일이 제외되지 않는 한 아마도 중복 제거 일 것입니다.

@rawtaz 감사합니다. 중복 제거에 대해 몰랐습니다.

@rawtaz 가 언급한 것처럼 큰 반복 블록의

@klauspost 이거 봤어 ? https://github.com/mvdan/zstd

예, 하지만 솔직히 스트림 디코더는 쉬운 부분입니다. FSE en/decoding을 마치고 Huffman 인코더를 준비했습니다. Huffman 디코딩이 완료되면 zstd 스트림 디코더는 매우 간단하며 전체 인코더가 최종 부분입니다.

LZ4는 완벽하게 충분하며 또한 빠른 승리가 될 것입니다.

lz4를 추가하고 zstd를 지원하기 위해 다른 PR을 생성하지 않는 이유는 무엇입니까?

lz4를 추가하고 zstd를 지원하기 위해 다른 PR을 생성하지 않는 이유는 무엇입니까?

@dave-fl은 저장소 형식을 수정할 때 매우 주의해야 하기 때문입니다. 이전 버전과 호환되는 방식으로 수행되어야 합니다. 전체 프로젝트에서 가장 중요한 부분은 구현이 아니라 repo 형식입니다. 사람들은 데이터를 복원할 수 있도록 형식을 망치지 않기 위해 우리에게 의존합니다. :)

압축으로 너무 많이 기다릴 수는 없다고 생각합니다. 방금 서버 백업의 몇 가지 리포지토리에서 몇 가지 테스트를 수행했습니다. 리포지토리를 gzip으로 압축할 때 정확히 아무것도 얻지 못했습니다! @Alwaysin 처럼 이미 중복 제거로 30%를

이전 버전과 호환되는 방식에 대해서는 Restic이 이전 형식에서 새 형식으로 마이그레이션하기 위해 두 형식 또는 도구를 모두 읽어야 한다는 의미입니까? Restic이 v1.0.0이 아닐 때는 그냥 마이그레이션해도 괜찮다고 생각합니다.

방금 서버 백업의 몇 가지 리포지토리에서 몇 가지 테스트를 수행했습니다. 리포지토리를 gzip으로 압축할 때 정확히 아무것도 얻지 못했습니다!

음, 예상됩니다. 리포지토리의 모든 데이터가 암호화되어 거의 압축할 수 없습니다. 압축을 사용하는 경우 데이터 를 암호화

LZ4를 사용하면 이전 버전과 어떻게 호환되지 않는지 모르겠습니다. 압축은 압축입니다. 여러 형식을 지원하지 않는 이유는 무엇입니까?

당신 말이 맞아, 나는 그것에 대해 생각하지 않았다.
그러나 소스를 gzip으로 압축할 때 30% 이상 승리하지 못했으며 중복 제거는 중복이 많은 큰 디렉토리에서 이미 매우 효율적입니다. 그러나 물론 둘 다 인상적일 수 있습니다.
압축 및 중복 제거를 수행하는 zpaq을 사용하면 그다지 많이 얻지 않고 조금 더 많이 얻을 수 있습니다.
저는 압축을 사용하여 분기를 테스트하는 데 매우 개방적입니다. 호환되지 않아도 상관 없습니다!

LZ4를 사용하면 이전 버전과 어떻게 호환되지 않는지 모르겠습니다. 압축은 압축입니다. 여러 형식을 지원하지 않는 이유는 무엇입니까?

두 클라이언트가 동일한 저장소를 사용하고 있지만 그 중 하나가 압축을 지원하지 않는 이전 버전의 restic을 사용하는 경우 어떻게 됩니까? 이 기능은 가능한 모든 모서리 케이스를 염두에 두고 신중하게 설계해야 합니다.

가능한 이전 백업을 중단할 수 있는 절반 작업 솔루션보다 압축을 선호하지 않습니다.

압축을 추가하는 문제에 대해서는 충분한 논의가 있었다고 생각합니다. 매우 기대되는 기능임을 알 수 있습니다. 새 아카이버 코드(#1494 참조)를 완료한 후 이 문제를 해결하겠습니다.

더 이상 의견을 추가하지 마십시오. 감사합니다!

@dimejo 당신이 말하는 것은 내가 제안한 것과 아무 관련이 없습니다. zstd 또는 lz4를 구현하도록 선택하는지 여부는 두 경우 모두에 영향을 미칩니다.

나는 감히 zstd의 CGO 버전이 다소 이식성이 있어 보인다고 말할 수 있습니다. :)

사양을 기반으로 매우 간략하게 zstd의 golang 구현을 작성하는 것이 얼마나 실현 가능한지 살펴보았습니다.

zstd는 대부분 사내 알고리즘이지만 (선택적으로) 오류 검사를 위해 xxHash-64 체크섬 에 의존하며 이에 대한 golang 포트가 있습니다. 선택적 비트는 선택 사항이므로 restic의 리더/라이터에 대한 zstd 지원을 얻기 위해 해당 부분을 구현할 필요가 없습니다. zstd는 압축을 최적화하기 위해 "사전"의 개념을 지원합니다. 이것이 restict와 어떻게 상호 작용할지 확신할 수 없지만 아카이브의 특정 부분(예: JSON 또는 메타데이터 스트림)을 압축하는 흥미로운 연구 영역이 될 것입니다. 그렇지 않으면 선택 사항이므로 해당 구현을 건너뛸 수도 있습니다.

물론 더 까다로워지는 곳은 엔트로피 코딩이 시작되는 곳입니다. zstd는 Finite State Entropy (FSE, [ANS]의 변형(https://en.wikipedia.org/wiki/Asymmetric_numeral_systems#, 그 중 C 구현만 존재합니다. 다른 엔트로피 코딩 비트는 허프만 코딩 으로 구현되며, 그 중 하나 는 compress.flate에 있고 다른 하나는 net.http2.hpack 에 있는 표준 라이브러리에 있는 두 가지를 포함하여 여러 구현이 있습니다. 오히려 이상하다.

내가 말할 수 있는 바에 따르면, 다른 모든 것은 그 위에 접착제입니다... 일부 허프만 트리, 시퀀스, 프레임 및 블록. 블록과 프레임이 빌드되는 방식에도 흥미로운 속성이 있는데, 이 속성은 restic blob에 잘 매핑될 수 있습니다. 이 속성을 사용하면 내부에 blob을 별도로 유지하면서 저장소 전체를 압축할 수 있지만 자세히 살펴보지는 않았습니다. . 또한 저장소 형식과 압축 사이의 결합을 허용할 수 없게 만들 수도 있습니다.

zstd는 각각 36k 및 12k에 비해 약 70k 라인(cloc에 따라)의 코드로 gzip 또는 xzip보다 훨씬 더 복잡합니다. 그러나 여기에는 수많은 테스트가 포함됩니다. 이러한 테스트를 무시하면 구현 자체가 gzip(~34k)과 거의 비슷합니다.

요약하자면, 이것이 go에서 구현되는 것은 시간 문제일 뿐입니다. zstd "프레임"이 서로 독립적이기 때문에 그러한 엔진이 golang의 병렬 처리를 활용할 수도 있다고 생각합니다. 그러나 프레임이 어떻게 사용되는지는 분명하지 않습니다. 내가 테스트한 대부분의 스트림에는 하나( zstd /etc/motd ) 또는 두 개( zstd isos/Fedora-Workstation-Live-x86_64-27-1.6.iso ) 프레임( binwalk -R "\x28\xb5\x2f\xfd" 에서 발견됨), 블록 이 상호 연관되고 덜 병렬화되기 때문에 아마도 그런 이득은 없을 것입니다...

어쨌든, 여기 누군가가 실제로 앉아서 그것을 이식하고 싶어하지 않는 한 모든 문제가 있지만, 나는 그것을 읽는 동안 내가 발견한 것을 공유할 것이라고 생각했습니다... zstd가 LZ77 컴프레서 제품군의 LZMA 부분의 확장이라는 점을 고려하면 이식이 불가능하다...

압축에 대한 업데이트가 있습니까? 많은 사람들이 zstd 를 기다리기를 원하지만 lz4 또는 lzo 또는 lzma 무엇이 문제가 될까요?

업데이트가 있었다면 이 문제가 업데이트되었을 것입니다.

그 동안 저자의 요청을 존중하려고 노력합시다.

더 이상 의견을 추가하지 마십시오. 감사합니다!

@fd0 , zstd 알고리즘 https://github.com/klauspost/compress/tree/master/zstd 의 순수한 Go 구현이 있는 것 같다는 점을 지적하고 싶었습니다. 나는 이것을 직접 시도하지 않았습니다. 그러나 이것은 restic에서 압축 지원의 가능성에 대해 흥분하게 했습니다.

Go zstd 항목(속도? 코드 품질? 유지 관리?)은 모르지만 C zstd 항목은 빠른/약간의 압축에서 느린/높은 압축까지 다양한 범위를 지원하므로 백업 도구에 필요한 모든 것입니다.

borgbackup에 다른 모든 압축 알고리즘(lz4, zlib, lzma)이 없고 지금 압축을 추가하기 시작한다면 zstd만 있으면 되고 아무 것도 사용할 수 없다고 생각하십시오.

취향/선호도에 따라 기본값은 없음(이전과 같이) 또는 매우 빠른 zstd 수준(전송할 데이터가 적기 때문에 전반적으로 여전히 대부분의 백업을 더 빠르게 함)일 수 있습니다.

안녕하십니까,
내 생각에 압축은 필수 기능이 아닙니다. Duplicati(압축 포함)와 restic(압축 없음)으로 수행한 데이터 백업을 비교했는데 전체 사용 공간이 정말 비슷했습니다.
빠르고 안정적인 증분 백업을 얻기 위해서만 restic이 필요합니다. 조금 깰 필요가 없습니다 ...
복원도 중요하며 restic은 재해 복구에 적합합니다. Duplicati는 로컬 db를 잃어버린 경우 복구 작업에 며칠이 걸리기 때문에 악몽입니다.

@fd0 과 모든 기여자에게 감사드립니다!

@filippobottega 실험에서 큰 차이를 보지 못했다면 다음을 의미합니다.

• 귀하의 데이터가 (많이) 압축 가능하지 않다는 것(그러나 이것은 일반적으로 해당되지 않음), 또는
• 복제는 다른 저장 형식, 세분성, 알고리즘 등으로 인해 압축과 관련하여 더 나쁜 저장 효율성을 가지고 있으므로 압축 절감은 다른 영역의 손실로 보상됩니다.

둘 다 압축이 무의미하다는 의미는 아닙니다.

@ThomasWaldmann 첫 번째 이유로 큰 차이를 보지 못합니다.
오늘날 데이터는 이미 여러 가지 방법으로 압축되어 있습니다. docx, xlsx, pptx, zip, 7z, jpeg, tif 등은 모두 압축 형식입니다. 또한 ISO 이미지에는 압축 파일이 포함되어 있습니다. 이러한 이유로 압축은 내가 생각하기에 무의미합니다.

@filippobottega 사람들이 백업에 어떤 데이터를 사용하는지에 대한 당신의 견해는 약간 편협합니다. SQL 덤프, 소스 코드, 데이터 세트, 원시 이미지 등은 어떻습니까? 중복 제거는 백업 간의 델타 크기를 줄이는 데는 큰 역할을 하지만 데이터 세트의 원래 크기를 줄이는 데는 아무 효과가 없습니다. 압축되지 않은 형식의 경우 이는 수 기가바이트를 의미할 수 있습니다. 압축되지 않은 형식을 저장한 다음 압축 + 중복 제거가 이미 압축된 파일을 중복 제거하는 것보다 더 나은 결과를 얻을 수 있다는 것은 말할 것도 없습니다.

SQL 덤프는 내 첫 번째 생각이었지만 restic은 내 메일 서버도 백업하며 Duplicati에서 restic으로 이동할 때 찍은 일부 RAR 스냅샷을 기반으로 하여 전체 압축이 더 나은 것 같습니다.

압축을 선택 사항으로 만들고 기본 파일 유형 목록을 갖는 사용 사례를 볼 수 있지만 압축을 통해 합리적인 금액을 절약할 수 있습니다.

@mrschyte

사람들이 백업에 어떤 데이터를 사용하는지에 대한 귀하의 견해는 다소 편협합니다.

이제 개인 정보를 얻을 필요가 없습니다. 그의 관점은 당신과 마찬가지로 유효하며 고려할 가치가 있습니다. 백업한 대부분의 데이터는 파일 형식으로 인해 이미 압축되어 있습니다.

SQL 덤프는 어떻습니까?

SQL 덤프를 압축하지 않고 정말 저장합니까? 나는 그것들을 원시 상태로 저장할 필요가 없기 때문에 백업하기 전에 모든 것을 gz합니다.

소스 코드, 데이터 세트, 원시 이미지 등

압축 백업의 유일한 유효한 사용 사례는 _활발하게 사용되고 있으므로 이미 압축된 상태로 저장되지 않은_ 반복이 많은 압축되지 않은 대용량 파일입니다. 내 경험(다른 사람의 데이터를 다년간 관리한 경험 포함)에 따르면 이 범주에 속하는 데이터는 거의 없습니다. 적어도 그러한 경우에 큰 차이를 만들기에는 충분하지 않습니다.

그러나 데이터 세트의 원래 크기를 줄이는 데는 아무 것도 하지 않습니다.

틀림없이 이것은 백업 프로그램의 작업이 아닙니다. 원본 데이터를 건드리면 안 됩니다.

압축되지 않은 형식을 저장한 다음 압축 + 중복 제거가 이미 압축된 파일을 중복 제거하는 것보다 더 나은 결과를 얻을 수 있다는 것은 말할 것도 없습니다.

많은 압축 알고리즘은 작업을 수행하기 위해 복제에 의존합니다(flate의 사전 참조). 따라서 나는 이것이 _일반적으로_ 확신할 수 없지만 적어도 몇 번은 이것이 옳다는 데 동의합니다.

(restic의 압축이 올바르게 수행될 때 _나쁘다고 말하는 것이 아닙니다. 특히 느린 성능 문제와 비교할 때 우선 순위가 될 필요가 없다고 주장하는 것입니다. 그리고 우리는 @fd0 의 시간 제약과 비전과 관련하여 바랍니다.)

@mholt 일반적으로 동의하지만 루트 백업(일부 덤프를 통해 또는 /의 내용 반복)을 수행하면 좋은 압축률을 얻을 수 있습니다. 필수 는 아니지만 사용된 총계가 이미 적기 때문에 약 50%를 절약할 수 있으며 최종 사용자에 관한 한 "무료"로 제공되는 것이 항상 좋습니다.

이 테스트를 시도하십시오.

1. SQL 덤프 또는 기타 압축되지 않은 파일을 가져옵니다. 압축한 다음
   백업을 사용하십시오.
2. SQL 데이터베이스에서 테이블을 제거하고 두 번째 덤프를 가져온 다음 압축합니다.
   그런 다음 restic을 사용하여 백업하십시오.

압축이 수행되기 전에
중복 제거를 사용하면 restics 중복 제거 알고리즘을 거의 완전히 물리칠 수 있습니다.
그러나 restic이 중복 제거 후 압축을 처리할 수 있다면
훨씬 더 작은 전체 출력을 얻어야 합니다.

DataDomain과 같은 도구를 사용하는 엔터프라이즈 스토리지 업계에서는 항상
압축되지 않은 상태로 저장 장치에 데이터를 공급하는 것이 좋습니다.
포맷하고 장치가 중복 제거 및 압축을 수행하도록 합니다. NS
이러한 도구를 적용해야 하는 일반적인 순서는 중복 제거입니다.
압축 후 암호화. 이것에 대해 잠시 생각하십시오 .... 당신은
동일한 데이터를 여러 번 압축하는 데 모든 추가 CPU를 사용하고 싶습니다.
중복 제거되고 어쨌든 본질적으로 폐기되는 경우에만 시간이 필요합니까? 그것의
일반적으로 먼저 중복 제거를 통해 데이터 세트를 줄이는 것이 가장 좋습니다.
압축을 수행하는 잠재적으로 무거운 작업을 수행하기 전에.

2019년 8월 2일 금요일 오후 1:29 Brandon Schneider [email protected]
썼다:

@mholt https://github.com/mholt 일반적으로 동의하지만
루트 백업(일부 덤프 또는 /의 내용 반복을 통해),
나에게 좋은 압축 비율을 제공합니다. 필수 는 아니지만 전체
중고는 이미 작지만 50% 정도 절약할 수 있고 항상 좋습니다.
최종 사용자에 관한 한 "무료"로 제공됩니다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/restic/restic/issues/21?email_source=notifications&email_token=AC3I762ZVGTTJL4TF3ODZILQCRVIXA5CNFSM4AXPP352YY3PNVWWK3TUL52HS4DFVEXG43VMVBW63LNMVX
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AC3I767IQQD3CZBIWM37C6TQCRVIXANCNFSM4AXPP35Q
.

SQL 덤프를 압축하지 않고 정말 저장합니까? 나는 그것들을 원시 상태로 저장할 필요가 없기 때문에 백업하기 전에 모든 것을 gz합니다.
틀림없이 이것은 백업 프로그램의 작업이 아닙니다. 원본 데이터를 건드리면 안 됩니다.

이런 종류의 보기가 데이터의 효율적인 저장을 방해하는 것처럼 느껴지나요? 모든 프로그램과 내보내기 작업이 자체 임시 압축 형식을 구현해야 한다는 아이디어는 중복 제거/압축/등이 사전 정의된 파일별(또는 디렉토리 tarball) 범위 이외의 모든 작업에서 작동하는 것을 방지하기 때문에 저는 멀리하려고 합니다. . 파일을 개별적으로 압축하면 서로 다른 파일/덤프 등의 공통점을 찾는 기능이 상실되고 결과적으로 중복 제거의 모든 이점을 잃게 됩니다. 압축되지 않은 상태로 유지하면 파일 시스템(zfs, btrfs 등)이 이 모든 작업을 수행할 수 있으며 폴더, 스냅샷 등을 압축 및 중복 제거하고 작업에 필요한 도구와의 호환성을 유지하면서 이 모든 것을 추상화할 수 있으므로 더 좋습니다. 압축되지 않은 데이터로

압축은 top restic의 중복 제거에 대한 추가 최적화로 볼 수 있지만 별도로 수행하면 서로 호환되지 않는 것 같습니다... 파일을 백업하기 전에 압축하고 사전 처리해야 한다고 제안하면 모든 것이 워크플로로 되돌아갑니다. 대신 rsync/rclone을 사용하십시오. 그렇다면 처음에는 restic을 사용하는 이유는 무엇입니까?

이런 종류의 보기가 데이터의 효율적인 저장을 방해하는 것처럼 느껴지나요? 모든 프로그램과 내보내기 작업이 자체 임시 압축 형식을 구현해야 한다는 아이디어는 중복 제거/압축/등이 사전 정의된 파일별(또는 디렉토리 tarball) 범위 이외의 모든 작업에서 작동하는 것을 방지하기 때문에 저는 멀리하려고 합니다. . 파일을 개별적으로 압축하면 서로 다른 파일/덤프 등의 공통점을 찾는 기능이 상실되고 결과적으로 중복 제거의 모든 이점을 잃게 됩니다. 압축되지 않은 상태로 유지하면 파일 시스템(zfs, btrfs 등)이 이 모든 작업을 수행할 수 있으며 폴더, 스냅샷 등을 압축 및 중복 제거하고 작업에 필요한 도구와의 호환성을 유지하면서 이 모든 것을 추상화할 수 있으므로 더 좋습니다. 압축되지 않은 데이터로

이는 데이터의 효율적인 저장일 뿐만 아니라 기존 워크플로이기도 합니다. 백업 제품이 시스템의 다른 측면에 워크플로를 적용하지 않고 안정적이고 효율적으로 데이터를 백업하기를 원합니다. 백업(잠재적으로 무기한으로 유지됨)이 효율적으로 저장되는 것이 훨씬 더 중요하지만 라이브 작업 데이터는 적극적으로 사용되는 방식에 가장 적합한 형식으로 저장해야 합니다.

이제 저장하기 전에 압축하는 것이 의미가 있는 경우가 있습니다. 특히 느린 저장 시스템에서 매우 압축 가능한 데이터를 사용하는 경우에 그렇습니다. 그러나 이것은 내 경험상 규칙보다 더 많은 예외입니다.

+1 압축은 정말 도움이 될 것입니다! 소프트웨어 엔지니어로 일할 때 압축되지 않은 소스 코드가 많이 있는 전체 홈 폴더를 백업합니다(그리고 ruby ​​또는 python과 같은 동적 언어에서는 거의 항상 소스 코드이며 대부분의 종속성 포함).

집에서 바이너리, man 파일, 리소스 파일 등과 같이 압축의 이점을 얻을 수 있는 많은 항목을 포함하여 전체 / 를 다시 백업합니다.

물론 백업하기 전에 모든 파일을 압축하고 많은 변환을 수행할 수 있지만, 이렇게 하면 매우 간단한 명령을 실행하고 백업을 받을 수 있는 편리함과 백업을 쉽게 얻을 수 없습니다. 물건을 복원합니다.

물론 압축이 잘 되지 않는 많은 종류의 파일이 있지만 누구도 강제로 압축해야 한다고 말하지 않습니다. 이 문제를 해결하기 위한 많은 접근 방식이 있습니다. 압축해야 하는 파일 유형을 허용 목록에 추가하고, 압축하지 않아야 하는 파일을 차단 목록에 추가하거나 가장 간단한 방법도 있습니다. 압축을 시도하고 결과 크기가 개선되지 않으면 압축되지 않은 상태로 저장합니다(ZFS 온디스크 압축이 활성화된 경우 이 접근 방식을 사용합니다.

결국 압축은 고전적인 공간 대 시간 트레이드오프의 한 예입니다. 더 많은 CPU를 지불하시겠습니까, 아니면 더 많은 스토리지를 사용하시겠습니까? 제 경우에는 스토리지가 비용의 대부분을 차지하므로 쿼드 코어가 조금 더 가열되고 파일 호스팅 비용이 줄어들면 좋을 것 같습니다.

마지막으로 4TB가 조금 넘는 용량을 클라우드 제공업체에 백업하고 업로드 속도가 약합니다. 따라서 보너스 압축으로 인해 백업 프로세스가 느려지지 않고 빨라집니다. 내 CPU는 내 가난한 VDSL 연결을 따라잡을 수 있습니다. .

네, 저는 여기에서 다른 모든 사람들의 의견에 동의할 수 있습니다. 압축은 매우 중요하며 왜 restic이 압축을 가져서는 안 되는가에 대한 논쟁이 없습니다.

@mholt 전적으로 동의합니다. 모든 단어.
예를 들어, 저는 TFS를 소스 제어로 사용하고 모든 소스는 이미 SQL 백업에서 압축되고 애플리케이션 이미지는 msi 설정 파일 또는 7z 아카이브에서 압축되기 때문에 제 도구 체인에서 압축은 나머지 중복 제거보다 먼저 옵니다. 매일 델타를 가져와 클라우드로 보내 안전한 재해 복구 계획을 구현하는 빠르고 간단한 방법만 있으면 됩니다.
@fd0 은 제품에 다른 복잡성을 추가하는 것보다 문제를 해결하는 데 시간을 집중해야 한다고 생각합니다.

auto,zstd 압축을 사용하는 보그와 압축 없음(압축 없음)을 약간 비교하면서 처음에는 / , 다음에는 /home 에서 VM 이미지 및 docker 이미지(실제 백업에서도 백업하지 않기 때문에). 테스트 머신은 저의 일상적인 소프트웨어 개발 머신이었습니다. 여기에는 많은 바이너리 파일, 압축된 사진 및 오디오 파일이 포함되어 있지만 꽤 잘 압축되어야 하는 상당한 양의 일반 텍스트 소스 코드도 포함되어 있습니다.

/ : 1053136 파일, 92.9GiB

• 보그, 없음: 17:27분, 64.1GiB
• 보그, zstd : 19시 29분 분, 40.6 지브
• 제한 시간: 09:45 분, 62.4GiB

/home : 221338개 파일, 58.3GiB

• 보그, zstd : 9시 6분 분, 30.7 지브
• 제한 시간: 04:36 분, 39.4GiB
  저장 공간에 관한 한 restic과 거의 동일하기 때문에 여기에서 압축 없이 borg를 생략했습니다.

첫째, 나는 그 테스트 케이스에서 거의 정확히 두 배 빨라진 restic에 박수를 보내고 싶습니다. 보그가 느려지는 것 외에도 압축은 전체 백업 기간에 ~2분(+11%)만 추가하지만 / 경우(-35 %). 내 홈 디렉토리의 경우 스토리지 절약이 약 20%입니다.

(그 경우를 위해 외부 디스크에 테스트를 수행했습니다. 원격 저장소에 백업할 때 백업에 걸리는 시간은 대부분 업로드 대역폭에 따라 달라집니다. 적어도 CPU 및 IO 속도가 네트워크보다 훨씬 높을 때) 테스트했습니다. 압축으로 인해 전송되는 데이터가 적기 때문에 압축을 사용하는 this 및 borg는 실제로 restic보다 빠릅니다. 대체로 저는 압축 지원을 받는 것을 매우 선호하며, 이상적으로는 청크가 압축의 이점이 있는지 확인하기 위해 자동 감지를 사용합니다.

@nioncode 내 계산이 맞다면 약 100/150MB/s를 백업합니다. 이는 zstd가 압축할 수 있는 것보다 낮습니다. 압축은 비동기식이므로 실제로 속도 저하가 없어야 합니다. 쓸 것이 적기 때문에 조금 더 빠를 수도 있습니다.

VM 보관이 사용 사례일 수 있다는 것을 알고 있지만 보관할 필요가 없도록 하려고 합니다.
ISO 및 설정 파일에서 시작하여 전체 VM 구축을 자동화하려고 합니다.
재해 복구의 경우 설정 파일, 문서 및 데이터베이스 백업의 백업을 사용하여 전체 VM을 복원할 수 있기를 원합니다. 그리고 사용자 상호 작용 없이 하려고 합니다.
이런 식으로 임시 파일, exe 및 dll과 같은 압축되지 않은 파일 등과 같이 VM에 포함된 많은 휴지통 파일을 압축하고 백업할 필요를 피할 수 있습니다.
나는 그것이 간단하지 않다는 것을 알고 있지만 디스크 공간과 대역폭을 절약하는 동일하고 유용하지 않은 GB의 파일을 압축하고 중복 제거하는 것을 피할 수 있습니다.

누가 어떻게 일을 하는지에 대해 이 스레드를 어지럽히지 맙시다. 충분했습니다.

압축은 많은 사람들(저 포함)이 원하는 기능이며 인터넷 연결 속도가 느린 경우 백업 스토리지와 업로드 시간을 모두 절약할 수 있습니다. 어떤 사람들은 30% 이상도 절약할 수 있습니다.

그러나 모든 사람이 이를 필요로 하는 것은 아니며 일부 사람들은 스마트한 방식으로 워크플로를 조정하여 이를 처리하거나 단순히 돈이나 대역폭 또는 둘 다에 신경 쓰지 않아도 됩니다.

어쨌든 양측은 대화를 나눴다.

@bjoe2k4 또는 지난 몇 년 동안 이 스레드에서 여러 번 논의된 것처럼 일반 텍스트 데이터에 대한 정보를 제공하는 암호화하기 전에 데이터를 압축하는 것의 부정적인 보안 영향에 대해 우려하고 있습니다. :)

압축이 필수가 되지 않는 한 압축의 보안 문제는 사용자가 할 수 있는 절충안일 뿐입니다. 이 이론적인 위험(내 데이터 세트가 크고 변경 사항을 예측할 수 없기 때문에 어쨌든 악용될 수 없는 위험, 따라서 소음으로 인해 압축 신호).

나는 아무도 압축을 의무화하는 것에 대해 이야기하고 있다고 믿지 않습니다.

내 특별한 사용 사례는 LARGE 세트의 CSV 및 SQL 덤프를 백업하는 것입니다. 이 파일은 매우 압축 가능하며... 미리 압축하고 싶지 않습니다.

모든 GB 온라인 스토리지에 대해 비용을 지불하기 때문에 압축 기능을 갖고 싶습니다.

이 토론이 이제 좀 더 활발해지고 있기 때문에 제가 발견한 몇 가지 발견을 제 친구의 패치 버전과 공유하고 싶습니다. 그들은 restic에 압축을 추가했으며(내가 아는 한 다소 빠르고 더럽습니다) 관심 있는 사람이 있으면 구현 세부 사항에 대해 언급할 수 있도록 이 게시물에 대해 알려드리겠습니다.
내 사용 사례는 자체 데이터베이스 형식이 있는 정말 못생긴 은행 소프트웨어입니다. 우리는 규제상의 이유로 이 소프트웨어를 사용해야 하며 우리가 가지고 있는 데이터는 원래 크기의 90%까지 압축할 수 있는 몇 TB의 다소 큰 파일입니다. 따라서 압축은 백업 스토리지, 백업 시간 및 복원 시간을 많이 절약할 수 있습니다.
Restic 업스트림, 압축이 적용된 패치된 Restic 및 tar가 있는 현재 백업 솔루션을 비교할 때 발견한 사항은 https://gist.github.com/joerg/b88bf1de0ce824894ffc38f597cfef5f 에서 확인할 수 있습니다.

| 도구 | 백업 시간(분:초) | 복원 시간(분:초) | 백업 공간(G) | 백업 공간(%) | 백업(MB/s) | 복원(MB/s) |
| --------------------------- | ------------------ | ------------------ | ---------------- | ---------------- | -------------- | -------------- |
| 타르 | 4:42 | 5:19 | 11 | 9.6% | 404 | 357 |
| Restic S3 로컬 업스트림 | 10:04 | 30:56 | 102 | 89.5% | 189 | 61 |
| Restic S3 로컬 압축 | 5:43 | 19:28 | 8.6 | 7.5% | 332 | 98 |
| 레스스틱 로컬 업스트림 | 8시 33분 | 26:06 | 102 | 89.5% | 222 | 73 |
| 레스스틱 로컬 압축 | 5시 21분 | 16:57 | 8.6 | 7.5% | 355 | 112 |
| Restic S3 원격 업스트림 | 17:12 | 46:06 | 102 | 89.5% | 110 | 41 |
| Restic S3 원격 압축 | 5시 27분 | 21:42 | 8.6 | 7.5% | 349 | 88 |

나는 restic이 거의 모든 것을 감소시키기 때문에 모든 종류의 선택적 압축으로 크게 얻을 것이라고 생각합니다.

모든 파일에 흥미로운 압축 비율이 있는 것은 아닙니다. 비디오 파일을 압축하는 것은 아마도 가치가 없지만 SQL 덤프를 압축하는 것은 가장 확실합니다. 그렇기 때문에 Btrfs와 같은 파일 시스템은 먼저 파일의 처음 128KB를 압축하려고 시도하고 상당한 압축 비율이 있으면 전체 파일을 압축합니다. 확실히 완벽하지는 않지만 빠르며 파일을 개별적으로 압축하기로 결정한 경우 대부분의 사용 사례에서 작동합니다.

압축을 옵션으로 제공하는 것에 반대하는 사람들을 위해 내 사용 사례는 콘텐츠를 제어할 수 없는 대부분의 압축 가능한 파일 형식을 혼합하여 백업하는 것입니다. 백업 작업을 수행하기 전에 여러 시스템(새 아카이브로 압축하는 경우 더 많은 로컬 디스크 공간을 차지하거나 제자리에 압축된 경우 관련 응용 프로그램에서 파일을 사용할 수 없게 함).

Restic을 DR 백업 도구로 사용할 수 있기를 원하지만 현재 압축 + 중복 제거로 인해 백업 작업당 네트워크 전송량이 기가바이트를 많이 절약할 수 있기 때문에 현재 borg(느림, 대용량 램 요구 사항 등)를 사용하고 있습니다. 내 백업 세트 전체에 걸쳐 클라우드에 있는 테라바이트 이상의 저장 공간(월별로 비용을 지불함)을 쉽게 초과할 수 있습니다. 압축을 지원하는 경우 백업을 더 오래 보관하거나 스토리지 비용을 줄일 수 있습니다.

안녕하세요 @joerg님 , 테스트를 공유해주셔서 감사합니다.
Tar 압축 작업의 출력을 제한하여 백업을 시도했습니까?
"Restic S3 Remote Compress"와 "Tar" + "Restic S3 Remote Upstream"을 비교하는 방법이 궁금합니다.
게다가 당신이 말하는 것은 사실이 아닌 것 같습니다.

나는 restic이 거의 모든 것을 감소시키기 때문에 모든 종류의 선택적 압축으로 크게 얻을 것이라고 생각합니다.

테스트 결과를 보면 restic에 필요한 CPU 시간은 로컬 백업의 경우 2배, 복원 시 6배 더 긴 것으로 보입니다. 타르에 비하면 별로입니다.

tar는 압축 알고리즘이 아닙니다. 당연히 빠릅니다.
편집: 아 그리고 btw. 디렉토리를 tar하면 파일당 여러 스레드를 사용하지 않으며 한 번에 두 개 이상의 파일에서도 작동하지 않습니다. 대신 디렉토리를 스캔하고 파일을 추가한 다음 다음으로 이동합니다. 꽤 느립니다. 그러나 문제는 다중 스레드로 추가하도록 설계되지 않은 아카이브 파일입니다.

테스트 결과를 보면, restic이 사용하는 CPU 시간은 로컬 백업에서 2배, 복원에서 6배 느린 것으로 보입니다. 타르에 비하면 별로입니다.

나는 여기서 당신의 요점을 완전히 확신하지 못합니다. restic은 물론 Tar보다 느리지만 압축이 있는 restic은 압축이 없는 restic보다 항상 빠르므로 restic이 분명히 이점이 있습니다.

Tar는 "이 하드웨어의 가장 좋은 경우"에서 유용한 비교이지만 대부분의 restic의 다른 기능이 부족합니다(스냅샷 및 데이터 중복 제거가 떠오릅니다). 압축을 추가하면 백업 제품에 중요한 백업 시간, 복원 시간 및 저장 비용만 향상되는 것으로 보입니다.

@joerg 친구들이 풀 리퀘스트를 열고 압축이 포함된 패치를 공개할 수 있습니까? 어떤 압축 알고리즘을 사용합니까?

@joerg @thedaveCA
죄송합니다. @joerg 주장의 의미를 잘못 이해했습니다. 압축을 한 상태에서 제한하는 것이 압축을 사용하지 않는 경우보다 확실히 좋습니다. 이제 내 질문은 다음과 같습니다. Tar + restic이 압축이 있는 restic과 비교하여 더 좋습니까?

우리는 베어 tar 아카이브를 사용하지 않고 특별한 병렬 zip 구현으로 gzip으로 압축된 tar 아카이브를 사용하고 있음을 명심하십시오. 그렇지 않으면 테라바이트의 데이터를 아카이브하는 데 지금 당장 걸리는 "단" 시간 대신 며칠이 걸릴 것입니다: https://gist.github. com/joerg/b88bf1de0ce824894ffc38f597cfef5f#tarpigz
@shibumi 나는 그들에게 이 문제와 내 게시물에 대해

압축은 암호화에 적합하지 않습니다. 이를 통해 공격자는 암호화된 리포지토리에 특정 파일이 포함되어 있는 경우 파일의 섹션(청크)이 사용된 암호화 키에 관계없이 동일한 크기로 압축되는지 추측할 수 있습니다. 이것은 암호화 프로토콜 의 매우 잘 알려진 취약점 이며 이것이 TLS 1.3에서 압축이 제거된 이유입니다.

없는 곳에서 알려진 문제를 만들지 맙시다, 그렇죠?

(이 문제는 이미 언급되었으며 아마도 한 번도 없을 것입니다. 여전히 이 문제는 열려 있습니다. 이 문제 때문에 한 번만 닫아야 한다고 생각합니다.)

문제를 스팸으로 보내는 이유는 무엇입니까? :(그것은 너무 많이 논의되어 거의 주제에서 벗어났습니다. 당신은 압축을 활성화하지 않을 것입니다!!

또한 공격 아이디어는 공격자가 압축 및 암호화할 데이터를 제어할 수 있어야 한다고 생각합니다(확실하지 않습니다!). https://en.m.wikipedia.org/wiki/CRIME

그러나 보안상의 문제일지라도 누군가는 단순히 저장 공간을 절약하기 위해 자신이 제어하는 ​​저장소에만 압축을 사용하고 싶어할 수 있습니다.

암호화를 약화시키는 선택적 기능이 있어도 잘못된 보안 감각을 불러일으킵니다. Restic은 _secure_ 백업 프로그램이라고 주장합니다. 선택적 압축을 추가하면 때때로, 항상 풀타임으로만 안전할 수 없기 때문에 이 약속이 무효화됩니다. 그리고 확실히 CVE 보고서가 있을 것입니다. 누가 자신의 소프트웨어에 이런 유형의 "인기"를 원합니까?

그러나 암호화와 함께 사용되지 않는 방식으로 압축을 추가하는 것은 실행 가능한 옵션이라고 생각합니다.

2017년 FWIW에서 저는 Restic에서 암호화를 제거한 데모를 만들었고 압축이 매우 효과적일 수 있음을 보여주었습니다 . 백배 효과적입니다. IIRC 압축은 암호화처럼 일종의 래퍼(wrapper)로 추가할 수 있지만 오랫동안 코드를 보지 않았기 때문에 요즘에는 더 어려울 수도 있고 더 쉬울 수도 있습니다.

실제로 CRIME은 암호문의 길이를 알아야 하며, 이는 기본적으로 restic에서 불가능합니다.
또한 "보안" 백업 프로그램이 없습니다. 제3자가 백업 파일에 액세스할 수 있는 경우 누군가가 데이터를 변조하거나 더 심하게 읽을 수 있는 가능성이 항상 있습니다.
압축이 더 악화된다는 말은 어리석은 일입니다.

실제로 CRIME은 암호문의 길이를 알아야 합니다.

CRIME은 필요하지만 당신은 그렇지 않습니다. 당신이 정보원으로부터 일급 비밀 파일 세트를 받은 탐사 기자라고 상상해 보십시오. 암호화로 백업하면 아무도 이 파일을 가지고 있다는 사실을 알 수 없습니다.

이제 당신이 압축을 가능하게 할 만큼 똑똑하지 않다고 상상해보십시오. 이제 이러한 파일을 가지고 있는 다른 모든 사람들은 압축된 후 암호화된 청크의 크기로 판단하여 압축 없이 이 아카이브에 이러한 일급 비밀 파일이 있다는 것을 알게 될 것입니다. 심지어 암호화 키를 알아야 합니다. 이것은 보안과는 거리가 멉니다. 사람들은 이 "기능" 때문에 감옥에 갈 수도 있고, 고문을 받거나, 더 나빠질 수도 있습니다.

"보안" 백업 프로그램이 없습니다.

그런 다음 업데이트가 필요합니다.

또한 기본적으로 보안에 유의하십시오.

restic은 압축된 청크만 저장하므로 청크의 크기가 명확하지 않습니다.
열쇠가 없는 사람.

2019년 8월 9일 금요일 02:09:23AM -0700에서 Alexey Kopytko는 다음과 같이 썼습니다.

압축은 암호화에 적합하지 않습니다. 이를 통해 공격자는 암호화된 리포지토리에 특정 파일이 포함되어 있는 경우 파일의 섹션(청크)이 사용된 암호화 키에 관계없이 동일한 크기로 압축되는지 추측할 수 있습니다. 이것은 암호화 프로토콜 의 매우 잘 알려진 취약성 이므로 TLS 1.3에서 압축이 제거되었습니다.

없는 곳에서 알려진 문제를 만들지 맙시다, 그렇죠?

--
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/restic/restic/issues/21#issuecomment -519844526

--
(Escriu-me xifrat si saps PGP / Write ciphered if you know PGP)
PGP 키 7CBD1DA5 - https://emailselfdefense.fsf.org/

이러한 보안 문제에 대해 더 알고 싶은 사람을 위해 http://www.iacr.org/cryptodb/archive/2002/FSE/3091/3091.pdf를 설명하는 멋진 문서가 있습니다
내가 알기로는 파일을 청크한 다음 압축 및 암호화하면 결함이 있을 수 있습니다. 그러나 청크 전에 파일을 압축하면 다른 파일과 마찬가지로 이진 파일이 되며 이러한 일반 텍스트 공격은 무용지물이 됩니다.

그러나 청크 전에 파일을 압축하면 다른 파일과 마찬가지로 이진 파일이 되며 이러한 일반 텍스트 공격은 무용지물이 됩니다.

맞아요. 그러나 압축 알고리즘이 파일의 각 버전에 대해 다른 어휘를 사용하여 매우 다른 바이너리 결과를 초래할 수 있기 때문에 올바르게 이해하면 효율적인 중복 제거에 정확히 도움이 되지 않습니다. 분명히 중복 제거되지 않습니다. 그렇지 않으면 결과 청크만 압축하는 것이 좋습니다.

restic은 압축된 청크만 저장하므로 키가 없는 사람에게는 청크의 크기가 분명하지 않습니다.

그것은 안도감이다.

내 요점은 여전히 ​​유효합니다. 암호화와 함께 압축을 구현할 때 숨겨진 약점을 프로그램에 추가할 수 있는 방법이 많이 있으므로 아예 추가하지 않는 것이 가장 좋습니다. TLS에 대해 결정하는 암호화 _전문가_조차도 압축을 제거하기로 결정했습니다. 비슷한 논리를 가지고 있었나 봅니다.

btw.:

However, it is important to note that these attacks have little security impact on, say, a bulkencryption application which compresses data before encrypting

...
당신은 암호화 된 파일의 여러 다른 버전이있는 경우도 범죄에만 작동합니다.
즉, 여러 백업 실행(공격자가 모든 백업을 얻은 다른 저장소로)
또한 적은 양의 데이터에 의해서만 작동합니다.

CRIME은 필요하지만 당신은 그렇지 않습니다. 당신이 정보원으로부터 일급 비밀 파일 세트를 받은 탐사 기자라고 상상해 보십시오. 암호화로 백업하면 아무도 이 파일을 가지고 있다는 사실을 알 수 없습니다.

이제 당신이 압축을 가능하게 할 만큼 똑똑하지 않다고 상상해보십시오. 이제 이러한 파일을 가지고 있는 다른 모든 사람들은 압축된 후 암호화된 청크의 크기로 판단하여 압축 없이 이 아카이브에 이러한 일급 비밀 파일이 있다는 것을 알게 될 것입니다. 심지어 암호화 키를 알아야 합니다. 이것은 보안과는 거리가 멉니다. 사람들은 이 "기능" 때문에 감옥에 갈 수도 있고, 고문을 받거나, 더 나빠질 수도 있습니다.

그건 헛소리야. 작은 샘플 크기에서만 작동하기 때문입니다. 또한 압축하지 않고 감옥에 갈 수도 있습니다. 특히 특정 시점에서 공격자가 백업 파일을 얻었을 때 나중에 이를 무차별 공격할 수 있습니다.
앞으로 나타날 다른 보안 문제 등이 있을 수 있습니다.
토론은 그저 무의미한 공포 조장으로 바뀌었습니다.

@sanmai , 나는이 예제를 얻지 못했습니다.

당신이 탐사 기자라고 상상해보세요... 이제 당신이 압축을 가능하게 할 만큼 영리하지 않다고 상상해 보세요. 이제 이러한 파일을 가지고 있는 다른 모든 사람들도 압축 후 암호화된 청크의 크기로 판단하여 다음과 같은 사실을 알게 될 것입니다. 암호화 키를 알 필요도 없이 이 아카이브에 이러한 일급 비밀 파일이 있습니다.

무슨 뜻인가요? 크기만 보고 암호화된 스냅샷에 이러한 파일이 있음을 추측 할 수 있습니까? 이것은 파일이 단독으로 압축되거나 다른 알려진 파일과 함께 압축된다고 가정합니다. 그러나 암호화되지 않은 shapshot으로 동일한 추측을 수행할 수 있습니다.

사실, 백업하기 전에 파일을 gzip으로 압축하는 것은 어떻습니까? 이것은 보안 취약점도 열어 줍니까?

이 예는 말도 안되는 소리라고 생각합니다. 스냅샷에 알려진 일부 (임의) 파일의 압축 버전이 포함되어 있는지 확인할 수 있다고 주장하면 압축되지 않은 파일이 포함되어 있는지 여부도 결정할 수 있습니다.

압축이 암호화를 훨씬 덜 안전하게 만들 수 있다고 생각하지 않습니다.

대부분의 압축 부채널 공격에는 다음과 같은 몇 가지 요소가 포함됩니다.
1) 공격자는 입력을 제어할 수 있습니다.
2) 공격자는 출력의 크기를 관찰할 수 있습니다.
3) 입력 데이터의 작은 변화로 인해 출력 크기에 측정 가능한 변화가 발생합니다.
4) 공격자는 입력을 변경하고 수십만 번 재시도 할 수 있습니다.

웹 기반 시스템과 달리 나머지 백업과 관련된 대다수에서 (1)과 (2)는 거의 동시에 유지되지 않습니다. 또한 블록 기반 압축(3)은 실제로 보장되지 않으며 대부분의 백업 체제(4)는 확실히 유지되지 않습니다. 백업 빈도는 일반적으로 하루에 한 번 정도이므로 데이터를 조작하고 압축된 출력 크기를 모니터링하여 상당한 차이를 확인하려면 수천 년이 걸리며 이는 다른 데이터가 변경되지 않는다고 가정하고 대부분의 경우 것입니다.

출력 크기가 표시되는 백업을 만드는 경우 압축 비활성화를 고려할 수 있습니다. 그렇지 않으면 실제로 이에 대한 실질적인 공격이 없으며 사용하도록 설정하는 것이 덜 안전하지 않습니다.

restic은 이미 중복 제거를 수행하여 어쨌든 압축 부채널과 동일한 이론적 공격에 노출되며 아무도 이에 대해 불평하지 않았습니다.

사실은 단점이 전혀 없는 압축 기능의 이점을 누릴 수 있는 수백 또는 수천 명의 사용자가 있다는 것입니다. 이 5년 된 문제를 작업 중인 개발자에게 맡겨도 될까요?

솔직히 말해서 .... 나는 restic의 개념을 선호하지만 ... 내 유스 케이스 (많은 CSV 파일 및 SQL 덤프)에서 테스트를 수행하고 borg로 전환해야했습니다.

4세대 증분 백업으로 테스트했으며 파일 압축률은 7:1이고 중복 제거와 함께 > 20:1을 달성했습니다. 이미 GB당 온라인 백업 스토리지 비용을 지불한다고 말했기 때문에 이를 무시할 수 없습니다.

root<strong i="7">@xxxx</strong>:~# borg list
2019-08-08_14:37                     Thu, 2019-08-08 14:37:10 [5e113a8102f2bd7e40d100343f849dc73843d145011c7214d5fa0895927eb6d1]
2019-08-08_22:28                     Thu, 2019-08-08 22:28:21 [17d815d000212a576610b2fd5688ab87cce00039bb89f63722c6a7819dec1821]
2019-08-09_02:00                     Fri, 2019-08-09 02:00:23 [217c53b07f30dfbca584c49468cfa624a2445a005890220509c97715f7007e81]
2019-08-10_02:00                     Sat, 2019-08-10 02:00:10 [5dd45b8ccf0aa382bf00d5b08e1d5d88daae014f0a1a42b3e2b0fc368623bba0]
root<strong i="8">@xxxx</strong>:~# borg info
Repository ID: xxxx
Location: ssh://xxxx
Encrypted: Yes (repokey)
Cache: /var/lib/borg/cache/xxxx
Security dir: /var/lib/borg/security/xxxx
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
All archives:               69.02 GB             11.24 GB              2.80 GB

                       Unique chunks         Total chunks
Chunk index:                    9227                41812

무슨 뜻인가요? 크기만 보고 암호화된 스냅샷에 이러한 파일이 있다는 것을 누군가가 _추측_할 수 있습니까? 이것은 파일이 단독으로 압축되거나 다른 알려진 파일과 함께 압축된다고 가정합니다. 그러나 암호화되지 않은 shapshot으로 동일한 추측을 수행할 수 있습니다.

정확히. 일반 텍스트 파일을 동일한 조각으로 자르고 압축한 다음 암호화합니다. 다시 슬라이스하고 압축하고 암호화합니다. 암호화된 파일의 크기는 AES 방식으로 변경되지 않으므로 두 경우 모두 지문처럼 서로 일치하는 범위 크기가 있음을 알 수 있습니다. 그들은(주로 이란이나 러시아와 같은 압제적인 정권의 행정부를 의미합니다) 이러한 파일이 여기에 있다고 합리적으로 가정할 수 있으며, 따라서 용의자를 계속 고문해야 할 이유를 제공합니다. 저는 왜 여러분이 이러한 아이디어에 대해 그렇게 기분이 상했는지 이해하지 못합니다. 이해하기 쉽지 않습니까? 이것은 그 자체로 범죄가 아닙니다. 그렇죠?

그러나 @viric이 언급 한 것처럼 기술적으로 Restic은 암호화 키 없이는 청크의 크기를 볼 수 없기 때문에 이러한 취약점의 영향을 받지 않습니다. 그러나 어느 시점에서 압축이 추가되면 Restic은 아직 영향을 받지 않을 수 있지만 나중에 영향을 받을 수 있습니다.

이미 중복 제거를 수행하는 경우 압축을 추가하면 Restic이 추가 취약점에 노출됩니까?

공격자가 압축되지 않은 크기를 유추하기 위해 압축된 블록 크기를 추측하는 것이 문제라면 알겠지만 압축으로 인해 상황이 악화됩니까? 공격자는 동일한 기본 정보를 가지고 있지 않습니까?

공격자가 각 파일의 압축되지 않은 크기와 압축된 크기를 볼 수 있다면 식별이 더 현실적이 될 수 있지만 제한적에서는 불가능합니다.

궁극적으로 중복 제거는 압축이 영향을 미치는 것으로 볼 수 있는 모든 이론적 공격에 이미 노출되어 있으며, 상황에 더 잘 맞는 경우 압축을 비활성화하여 현재 상태를 유지할 수 있습니다.

암호화된 청크의 크기를 보고 파일 존재를 추측하는 것에 대한 가상의 보안 문제에 대해 논의하는 이유를 이해하지 못합니다.,,

ZIP 또는 GZ를 사용합니까? 그럼 당신은 괜찮을거야.

이란 당국이 내 콘텐츠를 크기로 추측할 수 있다고 생각합니까? 그런 다음 압축(!)을 사용하지 마십시오. 단순히 압축을 사용할 수 없다는 의미는 아닙니다.

나는 우리가 restic에 압축을 추가하는 모든 관련 각도를 다뤘다고 생각합니다. 모든 의견에 감사드립니다.

기본적으로 압축을 추가하고 활성화해야 하지만 사용자가 압축을 비활성화할 수 있도록 해야 한다고 생각합니다. 작업할 시간이 더 있을 때까지 기다려 주십시오.

이 토론이 손에 잡히지 않는 것 같아서 지금은 이 문제를 잠그고 있습니다. 이 토론을 계속 하려면 포럼으로 이동하십시오 . 감사 해요!