백업 파트 6: 백업 도구 비교

이 기사에서는 백업 도구를 비교하지만 먼저 백업에서 데이터를 복원하는 데 얼마나 빠르고 잘 대처하는지 알아야 합니다.
비교의 용이성을 위해 특히 모든 후보가 이 작업 모드를 지원하므로 전체 백업에서 복원하는 것을 고려할 것입니다. 단순화를 위해 숫자는 이미 평균화되었습니다(여러 실행의 산술 평균). 결과는 웹 인터페이스의 존재, 설정 및 운영의 용이성, 자동화 기능, 다양한 추가 기능의 존재(예: 데이터 무결성 확인) 등 기능에 대한 정보도 포함하는 표로 요약됩니다. , 등. 그래프는 데이터가 사용될 서버(백업 복사본을 저장하는 서버 아님)의 부하를 표시합니다.

자료 복구

rsync 및 tar는 이후 참조 지점으로 사용됩니다. 그들은 대개 그것들을 기반으로 합니다. 백업 복사본을 만들기 위한 간단한 스크립트입니다.

Rsync 4분 28초 만에 설정된 테스트 데이터를 처리하여

그런 짐

복구 프로세스가 백업 스토리지 서버의 디스크 하위 시스템(톱니 그래프)의 제한에 도달했습니다. 또한 문제 없이 하나의 커널이 로드되는 것을 명확하게 볼 수 있습니다(낮은 iowait 및 Softirq - 각각 디스크 및 네트워크에 문제 없음). 다른 두 프로그램, 즉 rdiff-backup 및 rsnapshot은 rsync를 기반으로 하며 복구 도구로 일반 rsync도 제공하므로 로드 프로필과 백업 복구 시간이 거의 동일합니다.

타르 좀 더 빨리 끝났어

2분 43초:

Softirq 증가로 인해 전체 시스템 로드가 평균 20% 더 높아졌습니다. 즉, 네트워크 하위 시스템 운영 중 오버헤드 비용이 증가했습니다.

아카이브를 더 압축하면 복구 시간이 3분 19초로 늘어납니다.
메인 서버에 이러한 부하가 있는 경우(메인 서버 측면에서 포장 풀기):

두 개의 프로세스가 실행 중이므로 압축 해제 프로세스는 두 프로세서 코어를 모두 사용합니다. 일반적으로 이는 예상되는 결과입니다. 또한 백업이 포함된 서버 측에서 gzip을 실행할 때 비슷한 결과(3분 20초)를 얻었습니다. 기본 서버의 로드 프로필은 gzip 압축기 없이 tar를 실행하는 것과 매우 유사했습니다(이전 그래프 참조).

В rdiff 백업 일반 rsync를 사용하여 마지막 백업을 동기화할 수 있지만(결과는 유사함), 이전 백업은 여전히 ​​rdiff-backup 프로그램을 사용하여 복원해야 합니다. 이 프로그램은 17분 17초 만에 복원을 완료하여 다음을 보여줍니다.

이 부하:

아마도 이것은 적어도 작성자의 속도를 제한하려는 의도였을 것입니다. 그런 해결책을 제시하다. 백업 복사본 자체를 복원하는 프로세스는 코어 하나의 절반도 안되는 시간을 차지하며 rsync를 사용하는 디스크 및 네트워크에 비해 성능이 비례적으로 비슷합니다(예: 2~5배 느림).

스냅샷 복구를 위해서는 일반 rsync를 사용할 것을 제안하므로 결과는 비슷합니다. 일반적으로 결과는 다음과 같습니다.

트림 으로 7분 2초 만에 백업 복원 작업을 완료했습니다.
이 부하로:

매우 빠르게 작동했으며 최소한 순수 rsync보다 훨씬 더 편리합니다. 플래그, 간단하고 직관적인 cli 인터페이스, 내장된 다중 복사본 지원을 기억할 필요가 없습니다. 비록 두 배 느리기는 하지만요. 마지막 백업에서 데이터를 복원해야 하는 경우 몇 가지 주의 사항과 함께 rsync를 사용할 수 있습니다.

프로그램은 거의 동일한 속도와 부하를 보여주었습니다. 백업PC rsync 전송 모드를 활성화할 때 다음에 대한 백업을 배포합니다.

7분 42초:

그러나 데이터 전송 모드에서 BackupPC는 tar에 더 느리게 대처했습니다. 12분 15초 만에 프로세서 부하가 일반적으로 낮아졌습니다.

한 번 반:

이중성 암호화 없이는 약간 더 나은 결과를 보여 10분 58초 만에 백업을 복원했습니다. gpg를 사용하여 암호화를 활성화하면 복구 시간이 15분 3초로 늘어납니다. 또한 복사본을 저장하기 위한 리포지토리를 생성할 때 수신 데이터 스트림을 분할할 때 사용할 아카이브 크기를 지정할 수 있습니다. 일반적으로 기존 하드 드라이브에서는 단일 스레드 작동 모드로 인해 큰 차이가 없습니다. 하이브리드 스토리지를 사용하는 경우 다양한 블록 크기로 나타날 수 있습니다. 복구 중 메인 서버의 부하는 다음과 같았습니다.

암호화 없음

암호화

듀플리 카티 13분 45초 만에 완료하는 등 비슷한 회복률을 보였습니다. 복구된 데이터의 정확성을 확인하는 데 약 5분 정도가 더 소요됐다(총 약 19분). 부하는

꽤 높은:

aes 암호화가 내부적으로 활성화된 경우 복구 시간은 21분 40초였으며 복구 중 CPU 사용률은 최대(두 코어 모두!)였습니다. 데이터를 확인할 때 하나의 스레드만 활성화되어 하나의 프로세서 코어를 차지했습니다. 복구 후 데이터 확인에도 똑같이 5분(총 27분 정도)이 걸렸다.

결과

duplicati는 암호화를 위해 외부 gpg 프로그램을 사용할 때 복구 속도가 조금 더 빨랐지만 일반적으로 이전 모드와의 차이는 미미합니다. 작동시간은 16분30초, 데이터 검증은 6분 만에 이뤄졌다. 부하는

그런:

AMANDA, tar를 사용하여 2분 49초 만에 완료했는데, 이는 원칙적으로 일반 tar에 매우 가깝습니다. 원칙적으로 시스템에 부하

똑같다:

다음을 사용하여 백업을 복원하는 경우 zbackup 다음과 같은 결과가 얻어졌습니다:

암호화, lzma 압축

러닝타임 11분 8초

AES 암호화, lzma 압축

운행시간 14분

AES 암호화, lzo 압축

러닝타임 6분 19초

전반적으로 나쁘지 않습니다. 이는 모두 백업 서버의 프로세서 속도에 따라 달라지며, 이는 다양한 압축기를 사용하는 프로그램의 실행 시간에서 명확하게 볼 수 있습니다. 백업서버 측에서는 일반 tar가 실행되었기 때문에 그것과 비교해 보면 복구 속도가 3배 정도 느립니다. XNUMX개 이상의 스레드가 있는 다중 스레드 모드에서 작업을 확인하는 것이 좋습니다.

보그백업 비암호화 모드에서는 2분 45초로 tar보다 조금 느리지만 tar와 달리 저장소 중복 제거가 가능해졌습니다. 부하는 다음과 같이 드러났다.

다음 :

블레이크 기반 암호화를 활성화하면 백업 복구 속도가 약간 느려집니다. 이 모드의 복구 시간은 3분 19초이며 부하가 사라졌습니다.

이와 같이:

AES 암호화는 약간 느리고, 복구 시간은 3분 23초이며, 특히 로드가

변경되지 않았습니다:

Borg는 멀티스레드 모드에서 작업할 수 있으므로 프로세서 부하가 최대이며, 추가 기능이 활성화되면 작동 시간이 늘어납니다. 분명히 zbackup과 비슷한 방식으로 멀티스레딩을 살펴볼 가치가 있습니다.

레스스틱 조금 더 천천히 회복에 대처했는데, 수술시간은 4분 28초였다. 짐은 다음과 같았어요

다음과 같습니다 :

분명히 복구 프로세스는 여러 스레드에서 작동하지만 효율성은 BorgBackup만큼 높지는 않지만 시간 측면에서 일반 rsync와 비슷합니다.

과 유어백업 8분 19초 만에 데이터 복원이 가능했고, 부하도 컸다.

그런:

부하는 여전히 그다지 높지 않으며 심지어 tar보다 낮습니다. 어떤 곳에서는 버스트가 발생하지만 코어 하나의 부하를 넘지 않습니다.

비교 기준의 선택 및 정당화

이전 기사 중 하나에서 설명한 대로 백업 시스템은 다음 기준을 충족해야 합니다.

• 사용의 용이성
• Universalism
• 안정성
• 쉬움

각 항목을 개별적으로 더 자세히 고려해 볼 가치가 있습니다.

작동 용이성

"모든 것을 잘하세요"라는 버튼이 하나 있을 때 가장 좋지만, 실제 프로그램으로 돌아가면 가장 편리한 것은 익숙하고 표준적인 작동 원리일 것입니다.
대부분의 사용자는 cli에 대한 여러 키를 기억할 필요가 없고, 웹이나 tui를 통해 다양하고 종종 모호한 옵션을 구성하거나, 실패한 작업에 대한 알림을 설정할 필요가 없다면 더 나을 것입니다. 여기에는 백업 솔루션을 기존 인프라에 쉽게 "적합"하는 기능과 백업 프로세스 자동화도 포함됩니다. 패키지 관리자를 사용하거나 "다운로드 및 압축 풀기"와 같은 하나 또는 두 개의 명령을 사용하여 설치할 수도 있습니다. curl ссылка | sudo bash - 링크를 통해 무엇이 도착하는지 확인해야 하기 때문에 복잡한 방법입니다.

예를 들어, 고려된 후보 중에서 간단한 솔루션은 다양한 작동 모드에 대한 니모닉 키가 있는 burp, rdiff-backup 및 Restic입니다. 약간 더 복잡한 것은 보그(borg)와 이중성(duplicity)입니다. 가장 어려웠던 건 아만다였어요. 나머지는 사용 편의성 측면에서 중간 정도입니다. 어쨌든 사용 설명서를 읽는 데 30초 이상이 필요하거나 Google이나 다른 검색 엔진으로 이동해야 하고 긴 도움말 시트를 스크롤해야 한다면 어떤 식으로든 결정이 어렵습니다.

고려되는 후보자 중 일부는 e-mailjabber를 통해 자동으로 메시지를 보낼 수 있는 반면 다른 후보자는 시스템에 구성된 경고에 의존합니다. 게다가 대부분의 복잡한 솔루션에는 완전히 명확한 경고 설정이 없습니다. 어떤 경우든, 백업 프로그램이 XNUMX이 아닌 반환 코드를 생성하는 경우 정기적인 작업을 위해 시스템 서비스에서 이를 올바르게 이해할 수 있습니다(메시지가 시스템 관리자에게 전송되거나 모니터링에 직접 전송됨). 상황은 간단합니다. 그러나 백업 서버에서 실행되지 않는 백업 시스템을 구성할 수 없는 경우 문제에 대한 분명한 표현은 복잡성이 이미 과도하다는 것입니다. 어떤 경우든 웹 인터페이스나 로그에만 경고 및 기타 메시지를 보내는 것은 대부분 무시되기 때문에 나쁜 습관입니다.

자동화의 경우, 간단한 프로그램이 작동 모드를 설정하는 환경 변수를 읽을 수 있거나, 예를 들어 웹 인터페이스를 통해 작업할 때 동작을 완전히 복제할 수 있는 개발된 CLI가 있습니다. 여기에는 지속적인 운영 가능성, 확장 기회 가용성 등도 포함됩니다.

Universalism

자동화에 관한 이전 하위 섹션을 부분적으로 반영하면 백업 프로세스를 기존 인프라에 "적합"하는 것은 특별한 문제가 되어서는 안 됩니다.
작업에 비표준 포트(웹 인터페이스 제외)를 사용하고, 비표준 방식으로 암호화를 구현하고, 비표준 프로토콜을 사용하여 데이터를 교환하는 것은 비표준 포트의 징후라는 점은 주목할 가치가 있습니다. -범용 솔루션. 대부분의 경우 모든 후보자는 분명한 이유 때문에 어떤 방식으로든 이러한 기능을 가지고 있습니다. 단순성과 다양성은 일반적으로 함께 어울리지 않습니다. 예외적으로 트림, 다른 것들도 있습니다.

표시로-일반 SSH를 사용하여 작업하는 능력.

작업 속도

가장 논란이되고 논란이되는 점. 한편으로 우리는 프로세스를 시작했고 가능한 한 빨리 작동했으며 주요 작업을 방해하지 않았습니다. 반면, 백업 기간에는 트래픽과 프로세서 부하가 급증합니다. 복사를 위한 가장 빠른 프로그램은 일반적으로 사용자에게 중요한 기능 측면에서 가장 열악하다는 점도 주목할 가치가 있습니다. 다시 말하지만, 암호를 사용하여 수십 바이트 크기의 불행한 텍스트 파일 하나를 얻으려고 하고 이로 인해 전체 서비스 비용이 발생하는 경우(예, 예, 여기에서는 백업 프로세스가 대부분 책임이 없다는 것을 이해합니다), 그리고 저장소의 모든 파일을 순차적으로 다시 읽거나 전체 아카이브를 확장해야 합니다. 백업 시스템은 결코 빠르지 않습니다. 종종 걸림돌이 되는 또 다른 점은 아카이브에서 백업을 배포하는 속도입니다. 많은 조작(예: rsync) 없이 단순히 파일을 원하는 위치로 복사하거나 이동할 수 있는 사용자에게는 여기에 분명한 이점이 있지만 대부분의 경우 문제는 조직적인 방식으로 경험적으로 해결되어야 합니다. 즉, 백업 복구 시간을 측정합니다. 이에 대해 사용자에게 공개적으로 알립니다.

안정성

다음과 같이 이해해야 합니다. 한편으로는 어떤 방식으로든 백업 복사본을 다시 배포할 수 있어야 하며, 다른 한편으로는 네트워크 중단, 디스크 오류, 일부 삭제 등 다양한 문제에 저항할 수 있어야 합니다. 저장소.

백업 도구 비교

사본 생성 시간
복사 복구 시간
쉬운 설치
쉬운 설정
간단한 사용
간단한 자동화
클라이언트 서버가 필요합니까?
저장소의 무결성 확인
차등 복사본
파이프를 통한 작업
Universalism
독립
저장소 투명성
암호화
압축
중복 제거
웹 인터페이스
클라우드에 채우기
윈도우 지원
점수

Rsync
4m15s
4m28s
예
아니
아니
아니
예
아니
아니
예
아니
예
예
아니
아니
아니
아니
아니
예
6

타르
순수한
3m12s
2m43s
예
아니
아니
아니
아니
아니
예
예
아니
예
아니
아니
아니
아니
아니
아니
예
8,5

gzip을
9m37s
3m19s
예

Rdiff 백업
16m26s
17m17s
예
예
예
예
예
아니
예
아니
예
아니
예
아니
예
예
예
아니
예
11

스냅샷
4m19s
4m28s
예
예
예
예
아니
아니
예
아니
예
아니
예
아니
아니
예
예
아니
예
12,5

트림
11m9s
7m2s
예
아니
예
예
예
예
예
아니
예
예
아니
아니
예
아니
예
아니
예
10,5

이중성
암호화 없음
16m48s
10m58s
예
예
아니
예
아니
예
예
아니
아니
예
아니
예
예
아니
예
아니
예
11

gpg
17m27s
15m3s

듀플리 카티
암호화 없음
20m28s
13m45s
아니
예
아니
아니
아니
예
예
아니
아니
예
아니
예
예
예
예
예
예
11

에이스
29m41s
21m40s

gpg
26m19s
16m30s

지백업
암호화 없음
40m3s
11m8s
예
예
아니
아니
아니
예
예
예
아니
예
아니
예
예
예
아니
아니
아니
10

에이스
42m0s
14m1s

aes+lzo
18m9s
6m19s

보그백업
암호화 없음
4m7s
2m45s
예
예
예
예
예
예
예
예
예
예
아니
예
예
예
예
아니
예
16

에이스
4m58s
3m23s

blake2
4m39s
3m19s

레스스틱
5m38s
4m28s
예
예
예
예
아니
예
예
예
예
예
아니
예
아니
예
아니
예
예
15,5

유어백업
8m21s
8m19s
예
예
예
아니
예
아니
예
아니
예
예
아니
예
예
예
예
아니
예
12

아만다
9m3s
2m49s
예
아니
아니
예
예
예
예
아니
예
예
예
예
예
아니
예
예
예
13

백업PC
rsync
12m22s
7m42s
예
아니
예
예
예
예
예
아니
예
아니
아니
예
예
아니
예
아니
예
10,5

타르
12m34s
12m15s

테이블 범례:

• 녹색, 작동 시간 1분 미만 또는 “예”라고 대답(“클라이언트 서버가 필요합니까?” 열 제외), XNUMX점
• 노란색, 작동시간 0.5~XNUMX분, XNUMX점
• 빨간색, 작업 시간이 0분 이상이거나 답변이 "아니요"입니다("클라이언트 서버가 필요합니까?" 열 제외), XNUMX점

위의 표에 따르면 가장 간단하고 빠르며 동시에 편리하고 강력한 백업 도구는 BorgBackup입니다. Restic이 XNUMX위를 차지했고, 고려된 나머지 후보들은 마지막에 XNUMX~XNUMX점 차이로 거의 균등하게 배치되었습니다.

시리즈를 끝까지 읽어주신 모든 분들께 감사드리며, 옵션에 대해 논의하고 원하는 옵션이 있으면 제안해 주시기 바랍니다. 논의가 진행됨에 따라 표가 확장될 수 있습니다.

이 시리즈의 결과는 가능한 가장 짧은 시간에 복사본을 다시 배포하는 동시에 편리하고 쉽게 만들 수 있는 이상적이고 빠르며 관리하기 쉬운 백업 도구를 개발하려는 시도가 있는 마지막 기사가 될 것입니다. 구성하고 유지 관리합니다.

발표

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

출처 : habr.com