백업 파트 4: zbackup, restic, borgbackup 검토 및 테스트

이 기사에서는 데이터 스트림을 별도의 구성 요소(청크)로 나누어 저장소를 형성하는 백업 소프트웨어를 고려합니다.

리포지토리 구성 요소는 추가로 압축 및 암호화될 수 있으며, 가장 중요한 것은 반복되는 백업 프로세스 중에 재사용될 수 있다는 것입니다.

이러한 저장소의 백업 복사본은 예를 들어 다양한 해시 함수를 기반으로 서로 연결된 명명된 구성 요소 체인입니다.

유사한 솔루션이 여러 가지 있는데, 여기서는 zbackup, borgbackup 및 Restic의 3가지에 중점을 두겠습니다.

예상 결과

모든 신청자는 어떤 방식으로든 저장소 생성을 요구하므로 가장 중요한 요소 중 하나는 저장소의 크기를 추정하는 것입니다. 이상적으로 크기는 허용된 방법론에 따라 13GB를 넘지 않아야 하며, 최적화가 잘 된 경우에는 그보다 더 작아야 합니다.

tar와 같은 아카이버를 사용하지 않고 파일의 백업 복사본을 직접 생성할 수 있을 뿐만 아니라 rsync 및 sshfs와 같은 추가 도구 없이 ssh/sftp로 작업할 수 있는 것도 매우 바람직합니다.

백업 생성 시 동작:

1. 저장소의 크기는 변경 사항의 크기와 같거나 그 이하입니다.
2. 압축 및/또는 암호화를 사용하는 경우 CPU 부하가 많이 발생할 것으로 예상되며, 보관 및/또는 암호화 프로세스가 백업 스토리지 서버에서 실행되는 경우 네트워크 및 디스크 부하가 상당히 높아질 수 있습니다.
3. 리포지토리가 손상된 경우 새 백업을 생성할 때와 복원을 시도할 때 모두 지연된 오류가 발생할 수 있습니다. 저장소의 무결성을 보장하기 위한 추가 조치를 계획하거나 무결성을 확인하기 위해 내장된 도구를 사용하는 것이 필요합니다.

이전 기사 중 하나에 표시된 것처럼 tar 작업은 참조 값으로 사용됩니다.

zbackup 테스트

zbackup의 일반적인 메커니즘은 프로그램이 입력 데이터 스트림에서 동일한 데이터가 포함된 영역을 찾은 다음 선택적으로 이를 압축하고 암호화하여 각 영역을 한 번만 저장하는 것입니다.

중복 제거는 슬라이딩 윈도우가 있는 64비트 링 해시 기능을 사용하여 기존 데이터 블록과 바이트 단위로 일치하는지 확인합니다(rsync가 구현하는 방식과 유사).

멀티 스레드 lzma 및 lzo는 압축에 사용되고 aes는 암호화에 사용됩니다. 최신 버전에는 나중에 저장소에서 오래된 데이터를 삭제할 수 있는 기능이 있습니다.
이 프로그램은 최소한의 종속성을 가지고 C++로 작성되었습니다. 저자는 유닉스 방식에서 영감을 받은 것으로 보입니다. 따라서 프로그램은 백업을 생성할 때 stdin의 데이터를 받아들이고, 복원할 때 stdout에서 유사한 데이터 스트림을 생성합니다. 따라서 zbackup은 자신만의 백업 솔루션을 작성할 때 매우 훌륭한 "빌딩 블록"으로 사용될 수 있습니다. 예를 들어, 기사 작성자는 대략 2014년부터 이 프로그램을 가정용 컴퓨터의 주요 백업 도구로 사용해 왔습니다.

달리 명시하지 않는 한 데이터 스트림은 일반 tar가 됩니다.

결과가 무엇인지 봅시다:

작업은 두 가지 옵션으로 확인되었습니다.

1. 저장소가 생성되고 소스 데이터와 함께 서버에서 zbackup이 시작된 다음 저장소의 내용이 백업 스토리지 서버로 전송됩니다.
2. 백업 스토리지 서버에 리포지토리가 생성되고, 백업 스토리지 서버에서 SSH를 통해 zbackup이 시작되며, 데이터가 파이프를 통해 전송됩니다.

첫 번째 옵션의 결과는 다음과 같습니다. 43m11s - 암호화되지 않은 저장소와 lzma 압축기를 사용할 때, 19m13s - 압축기를 lzo로 교체할 때.

원본 데이터가 있는 서버의 로드는 다음과 같습니다(lzma의 예가 표시됩니다. lzo의 경우 거의 동일한 그림이 있었지만 rsync의 점유율은 약 XNUMX분의 XNUMX이었습니다).

이러한 백업 프로세스는 상대적으로 드물고 작은 변경에만 적합하다는 것이 분명합니다. 또한 zbackup을 1개의 스레드로 제한하는 것이 좋습니다. 그렇지 않으면 CPU 로드가 매우 높아집니다. 이 프로그램은 다중 스레드에서 작업하는 데 매우 능숙합니다. 디스크의 로드는 작았으며 일반적으로 최신 SSD 기반 디스크 하위 시스템에서는 눈에 띄지 않습니다. 또한 리포지토리 데이터를 원격 서버에 동기화하는 프로세스의 시작을 명확하게 확인할 수 있습니다. 작업 속도는 일반 rsync와 비슷하며 백업 스토리지 서버의 디스크 하위 시스템 성능에 따라 달라집니다. 이 접근 방식의 단점은 로컬 저장소를 저장하고 결과적으로 데이터가 중복된다는 것입니다.

실제로 더 흥미롭고 적용 가능한 두 번째 옵션은 백업 스토리지 서버에서 직접 zbackup을 실행하는 것입니다.

먼저 lzma 압축기를 사용하여 암호화를 사용하지 않고 작업을 테스트합니다.

각 테스트 실행 시간:

발사 1
발사 2
발사 3

39m45s
40m20s
40m3s

7m36s
8m3s
7m48s

15m35s
15m48s
15m38s

aes를 사용하여 암호화를 활성화하면 결과는 매우 유사합니다.

암호화를 사용한 동일한 데이터의 작동 시간:

발사 1
발사 2
발사 3

43m40s
44m12s
44m3s

8m3s
8m15s
8m12s

15m0s
15m40s
15m25s

lzo를 사용하여 암호화와 압축을 결합하면 다음과 같습니다.

영업 시간 :

발사 1
발사 2
발사 3

18m2s
18m15s
18m12s

5m13s
5m24s
5m20s

8m48s
9m3s
8m51s

결과 저장소의 크기는 13GB로 비교적 동일했습니다. 이는 중복 제거가 올바르게 작동하고 있음을 의미합니다. 또한 이미 압축된 데이터에 대해서는 lzo를 사용하면 눈에 띄는 효과가 있으며 총 작업 시간 측면에서 zbackup은 이중성/이중화에 가깝지만 librsync 기반보다 2~5배 정도 뒤처집니다.

장점은 분명합니다. 즉, 백업 스토리지 서버의 디스크 공간이 절약됩니다. 리포지토리 검사 도구는 zbackup 작성자가 제공하지 않으므로 내결함성 디스크 어레이 또는 클라우드 공급자를 사용하는 것이 좋습니다.

프로젝트가 약 3년 동안 중단되었다는 사실에도 불구하고 전반적으로 매우 좋은 인상을 받았습니다(마지막 기능 요청은 약 XNUMX년 전이었지만 응답이 없었습니다).

borgbackup 테스트

Borgbackup은 zbackup과 유사한 또 다른 시스템인 다락방의 포크입니다. Python으로 작성되었으며 zbackup과 유사한 기능 목록이 있지만 추가로 다음을 수행할 수 있습니다.

• 퓨즈를 통해 백업 마운트
• 저장소 내용 확인
• 클라이언트-서버 모드에서 작업
• 데이터에 대한 다양한 압축기를 사용하고 압축 시 파일 형식을 경험적으로 결정합니다.
• 2가지 암호화 옵션, aes 및 blake
• 내장 도구

성능 점검

borgbackup 벤치마크 crud ssh://backup_server/repo/path local_dir

결과는 다음과 같습니다.

CZ-BIG 96.51MB/초(10 100.00MB 올제로 파일: 10.36초)
RZ-BIG 57.22MB/초(10 100.00MB 올제로 파일: 17.48초)
UZ-BIG 253.63MB/초(10 100.00MB 올제로 파일: 3.94초)
DZ-BIG 351.06MB/초(10 100.00MB 올제로 파일: 2.85초)
CR-빅 34.30MB/초(10 100.00MB 임의 파일: 29.15초)
RR-빅 60.69MB/초(10 100.00MB 임의 파일: 16.48초)
UR-빅 311.06MB/초(10 100.00MB 임의 파일: 3.21초)
DR-BIG 72.63MB/초(10 100.00MB 임의 파일: 13.77초)
CZ-MEDIUM 108.59MB/초(1000 1.00MB 올제로 파일: 9.21초)
RZ-중간 76.16MB/초(1000 1.00MB 올제로 파일: 13.13초)
UZ-중간 331.27MB/초(1000 1.00MB 올제로 파일: 3.02초)
DZ-중간 387.36MB/초(1000 1.00MB 올제로 파일: 2.58초)
CR-MEDIUM 37.80MB/초(1000 1.00MB 임의 파일: 26.45초)
RR-MEDIUM 68.90MB/초(1000 1.00MB 임의 파일: 14.51초)
UR-MEDIUM 347.24MB/s(1000 1.00MB 임의 파일: 2.88초)
DR-MEDIUM 48.80MB/초(1000 1.00MB 임의 파일: 20.49초)
CZ-SMALL 11.72MB/초(10000 10.00kB 올제로 파일: 8.53초)
RZ-SMALL 32.57MB/초(10000 10.00kB 올제로 파일: 3.07초)
UZ-SMALL 19.37MB/초(10000 10.00kB 올제로 파일: 5.16초)
DZ-SMALL 33.71MB/초(10000 10.00kB 올제로 파일: 2.97초)
CR-SMALL 6.85MB/초(10000 10.00kB 무작위 파일: 14.60초)
RR-SMALL 31.27MB/초(10000 10.00kB 무작위 파일: 3.20초)
UR-SMALL 12.28MB/초(10000 10.00kB 무작위 파일: 8.14초)
DR-SMALL 18.78MB/초(10000 10.00kB 무작위 파일: 5.32초)

테스트 시 압축 휴리스틱을 사용하여 파일 유형(압축 자동)을 결정하며 결과는 다음과 같습니다.

먼저 암호화 없이 어떻게 작동하는지 확인해 보겠습니다.

영업 시간 :

발사 1
발사 2
발사 3

4m6s
4m10s
4m5s

56s
58s
54s

1m26s
1m34s
1m30s

저장소 인증(인증 모드)을 활성화하면 결과는 종료됩니다.

영업 시간 :

발사 1
발사 2
발사 3

4m11s
4m20s
4m12s

1m0s
1m3s
1m2s

1m30s
1m34s
1m31s

aes 암호화가 활성화되면 결과가 크게 저하되지 않았습니다.

발사 1
발사 2
발사 3

4m55s
5m2s
4m58s

1m0s
1m2s
1m0s

1m49s
1m50s
1m50s

그리고 aes를 blake로 변경하면 상황이 완전히 개선됩니다.

영업 시간 :

발사 1
발사 2
발사 3

4m33s
4m43s
4m40s

59s
1m0s
1m0s

1m38s
1m43s
1m40s

zbackup의 경우와 마찬가지로 저장소 크기는 13GB였으며 일반적으로 예상되는 크기보다 조금 더 작았습니다. 실행 시간이 매우 만족스러웠습니다. librsync 기반 솔루션과 비슷하며 훨씬 더 광범위한 기능을 제공합니다. 또한 환경 변수를 통해 다양한 매개변수를 설정할 수 있는 기능도 만족스러웠습니다. 이는 자동 모드에서 borgbackup을 사용할 때 매우 큰 이점을 제공합니다. 백업 중 로드도 만족스러웠습니다. 프로세서 로드로 판단하면 borgbackup은 1개의 스레드에서 작동합니다.

사용시 특별한 단점은 없었습니다.

잔여 테스트

Restic이 상당히 새로운 솔루션이라는 사실에도 불구하고(처음 2개의 후보는 2013년 이전에 알려졌습니다) 꽤 좋은 특성을 가지고 있습니다. Go로 작성되었습니다.

zbackup과 비교하면 다음이 추가로 제공됩니다.

• 저장소의 무결성을 확인합니다(부분 체크인 포함).
• 백업 저장을 위한 지원되는 프로토콜 및 공급자의 방대한 목록은 물론 클라우드 솔루션용 rclone - rsync 지원도 제공합니다.
• 2개의 백업을 서로 비교합니다.
• 퓨즈를 통해 저장소를 마운트합니다.

일반적으로 기능 목록은 borgbackup과 매우 유사하며 어떤 곳에서는 더 많고 다른 곳에서는 더 적습니다. 기능 중 하나는 암호화를 비활성화할 수 있는 방법이 없으므로 백업 복사본이 항상 암호화된다는 것입니다. 실제로 이 소프트웨어에서 무엇을 짜낼 수 있는지 살펴보겠습니다.

결과는 다음과 같습니다.

영업 시간 :

발사 1
발사 2
발사 3

5m25s
5m50s
5m38s

35s
38s
36s

1m54s
2m2s
1m58s

성능 결과도 rsync 기반 솔루션과 비슷하며 일반적으로 borgbackup과 매우 비슷하지만 CPU 로드가 더 높고(다중 스레드 실행) 톱니 모양입니다.

rsync의 경우와 마찬가지로 프로그램은 데이터 스토리지 서버의 디스크 하위 시스템 성능에 의해 제한될 가능성이 높습니다. 저장소 크기는 zbackup이나 borgbackup과 마찬가지로 13GB였으며 이 솔루션을 사용할 때 뚜렷한 단점은 없었습니다.

조사 결과

실제로 모든 후보자는 비슷한 결과를 얻었지만 가격은 달랐습니다. Borgbackup이 가장 성능이 좋았고, Restic은 약간 느렸으며, zbackup은 아마도 사용을 시작할 가치가 없을 것입니다.
이미 사용 중이라면 borgbackup이나 Restic으로 변경해보세요.

조사 결과

가장 유망한 해결책은 Restic인 것 같습니다. 왜냐하면... 작동 속도 대비 성능 비율이 가장 좋은 사람은 바로 그 사람이지만 지금은 일반적인 결론을 서두르지 말자.

Borgbackup은 기본적으로 나쁘지 않지만 zbackup을 대체하는 것이 더 나을 것입니다. 사실, zbackup을 사용하여 3-2-1 규칙이 작동하는지 확인할 수 있습니다. 예를 들어 (lib)rsync 기반 백업 기능이 추가됩니다.

발표

백업, 파트 1: 백업이 필요한 이유, 방법 및 기술 개요
백업 2부: rsync 기반 백업 도구 검토 및 테스트
백업 파트 3: 이중성 검토 및 테스트
백업 파트 4: zbackup, restic, borgbackup 검토 및 테스트
백업 파트 5: Linux용 bacula 및 veeam 백업 테스트
백업 파트 6: 백업 도구 비교
백업 파트 7: 결론

게시자: 파벨 뎀코비치

출처 : habr.com