백업 파트 3: 이중성 검토 및 테스트

이 노트에서는 백업 서버에 아카이브를 생성하여 백업을 수행하는 백업 도구에 대해 설명합니다.

요구 사항을 충족하는 것 중에는 이중성(deja dup 형태의 멋진 인터페이스가 있음)과 이중성이 있습니다.

매우 주목할만한 또 다른 백업 도구는 dar입니다. 그러나 이 도구에는 매우 광범위한 옵션 목록이 있으므로(테스트 방법론은 해당 기능의 거의 10%만 다루므로) 현재 주기의 일부로 테스트하지 않습니다.

예상 결과

두 후보 모두 어떤 방식으로든 아카이브를 생성하므로 일반 tar를 가이드로 사용할 수 있습니다.

또한 전체 복사본과 파일의 현재 상태 또는 이전 아카이브와 현재 아카이브(증분, 감소 등) 간의 차이만 포함하는 백업 복사본을 생성하여 스토리지 서버의 데이터 스토리지가 얼마나 잘 최적화되는지 평가합니다. .

백업 생성 시 동작:

1. 백업 저장소 서버에 있는 파일 수는 상대적으로 적지만(백업 복사본 수 또는 데이터 크기(GB)와 비슷함) 크기가 상당히 큽니다(수십~수백 메가바이트).
2. 저장소 크기에는 변경 사항만 포함됩니다. 중복 항목은 저장되지 않으므로 저장소 크기는 rsync 기반 소프트웨어보다 작습니다.
3. 압축 및/또는 암호화를 사용할 경우 CPU 부하가 높을 수 있으며, 보관 및/또는 암호화 프로세스가 백업 스토리지 서버에서 실행 중인 경우 네트워크 및 디스크 부하가 상당히 높아질 수 있습니다.

참조 값으로 다음 명령을 실행해 보겠습니다.

cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"

실행 결과는 다음과 같았습니다.

실행 시간은 3분 12초입니다. 다음 예에서와 같이 백업 스토리지 서버의 디스크 하위 시스템에 의해 속도가 제한되는 것을 볼 수 있습니다. rsync. 조금 더 빠르니까... 녹음은 하나의 파일로 진행됩니다.

또한 압축을 평가하기 위해 동일한 옵션을 실행하되 백업 서버 측에서 압축을 활성화해 보겠습니다.

cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"

결과는 다음과 같습니다.

실행 시간 10분 11초. 병목 현상은 수신 측의 단일 흐름 압축기일 가능성이 높습니다.

동일한 명령이지만 병목 현상이 단일 스레드 압축기라는 가설을 테스트하기 위해 원래 데이터와 함께 압축이 서버로 전송되었습니다.

cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"

결과는 다음과 같습니다.

실행 시간은 9분 37초였습니다. 압축기에 의해 하나의 코어에 가해지는 부하가 명확하게 표시됩니다. 네트워크 전송 속도와 원본 디스크 하위 시스템의 로드는 비슷합니다.

암호화를 평가하려면 추가 명령을 연결하여 openssl 또는 gpg를 사용할 수 있습니다. openssl 또는 gpg 파이프에. 참고로 다음과 같은 명령이 있습니다.

cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"

결과는 다음과 같이 나왔습니다.

수신 측에서 10개의 프로세스가 실행 중이었기 때문에 실행 시간은 30분 2초로 나타났습니다. 병목 현상은 다시 단일 스레드 압축기와 작은 암호화 오버헤드로 인해 발생합니다.

UPD : bliznezz의 요청에 따라 pigz에 테스트를 추가하고 있습니다. 압축기만 사용하면 6분 30초 정도 걸리고, 암호화도 추가하면 7분 정도 걸립니다. 아래쪽 그래프의 하락은 플러시되지 않은 디스크 캐시입니다.

중복 테스트

Duplicity는 tar 형식의 암호화된 아카이브를 생성하여 백업하는 Python 소프트웨어입니다.

증분 아카이브의 경우 librsync가 사용되므로 다음에 설명된 동작을 기대할 수 있습니다. 시리즈의 이전 게시물.

백업은 gnupg를 사용하여 암호화하고 서명할 수 있습니다. 이는 백업 저장을 위해 다른 공급자(s3, backblaze, gdrive 등)를 사용할 때 중요합니다.

결과가 무엇인지 봅시다:

암호화 없이 실행할 때 얻은 결과는 다음과 같습니다.

스포일러

각 테스트 실행 시간:

발사 1
발사 2
발사 3

16m33s
17m20s
16m30s

8m29s
9m3s
8m45s

5m21s
6m04s
5m53s

다음은 키 크기가 2048비트인 gnupg 암호화를 활성화한 경우의 결과입니다.

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

발사 1
발사 2
발사 3

17m22s
17m32s
17m28s

8m52s
9m13s
9m3s

5m48s
5m40s
5m30s

블록 크기는 512MB로 그래프에서 명확하게 표시됩니다. 프로세서 로드는 실제로 50%로 유지되었습니다. 이는 프로그램이 하나의 프로세서 코어만 사용한다는 것을 의미합니다.

프로그램 작동 원리도 매우 명확하게 보입니다. 데이터 조각을 가져와 압축한 다음 백업 스토리지 서버로 보냈는데 속도가 상당히 느릴 수 있습니다.
또 다른 특징은 변경된 데이터의 크기에만 의존하는 예측 가능한 프로그램 실행 시간입니다.

암호화를 활성화해도 프로그램 실행 시간이 크게 늘어나지는 않았지만 프로세서 로드가 약 10% 증가했는데 이는 꽤 좋은 보너스가 될 수 있습니다.

불행하게도 이 프로그램은 디렉토리 이름 변경으로 인한 상황을 정확하게 감지하지 못했고 결과 저장소 크기는 변경된 크기(즉, 모두 18GB)와 동일한 것으로 밝혀졌지만 신뢰할 수 없는 서버를 사용하여 백업하는 기능이 명확하게 나타납니다. 이 동작을 다룹니다.

중복 테스트

이 소프트웨어는 C#으로 작성되었으며 Mono의 라이브러리 세트를 사용하여 실행됩니다. GUI 버전과 CLI 버전이 있습니다.

주요 기능의 대략적인 목록은 다양한 백업 저장소 공급자를 포함하여 이중성과 유사하지만 이중성과 달리 대부분의 기능은 타사 도구 없이 사용할 수 있습니다. 이것이 플러스인지 마이너스인지는 구체적인 사례에 따라 다르지만 초보자의 경우 Python용 패키지를 추가로 설치하는 것보다 한 번에 모든 기능 목록을 앞에 두는 것이 더 쉬울 가능성이 높습니다. 이중성이 있는 사건.

또 다른 작은 뉘앙스 - 프로그램은 백업을 시작하는 사용자를 대신하여 로컬 sqlite 데이터베이스를 적극적으로 작성하므로 cli를 사용하여 프로세스가 시작될 때마다 필요한 데이터베이스가 올바르게 지정되었는지 추가로 확인해야 합니다. GUI 또는 WEBGUI를 통해 작업할 때 세부 정보가 사용자에게 숨겨집니다.

이 솔루션이 어떤 지표를 생성할 수 있는지 살펴보겠습니다.

암호화를 끄면(WEBGUI에서는 이를 권장하지 않음) 결과는 다음과 같습니다.

영업 시간 :

발사 1
발사 2
발사 3

20m43s
20m13s
20m28s

5m21s
5m40s
5m35s

7m36s
7m54s
7m49s

암호화가 활성화된 상태에서 aes를 사용하면 다음과 같습니다.

영업 시간 :

발사 1
발사 2
발사 3

29m9s
30m1s
29m54s

5m29s
6m2s
5m54s

8m44s
9m12s
9m1s

그리고 외부 프로그램 gnupg를 사용하면 다음과 같은 결과가 나온다.

발사 1
발사 2
발사 3

26m6s
26m35s
26m17s

5m20s
5m48s
5m40s

8m12s
8m42s
8m15s

보시다시피 프로그램은 여러 스레드에서 작동할 수 있지만 이로 인해 더 생산적인 솔루션이 되지는 않으며 암호화 작업을 비교하면 외부 프로그램을 시작합니다.
Mono 세트의 라이브러리를 사용하는 것보다 더 빠른 것으로 나타났습니다. 이는 외부 프로그램이 더 최적화되었기 때문일 수 있습니다.

또 다른 좋은 점은 저장소의 크기가 실제 변경된 데이터와 정확히 일치한다는 사실입니다. duplicati는 디렉터리 이름 변경을 감지하고 이 상황을 올바르게 처리했습니다. 이는 두 번째 테스트를 실행할 때 볼 수 있습니다.

전반적으로, 초보자에게 상당히 친근하다는 점을 포함하여 프로그램에 대한 상당히 긍정적인 인상을 받았습니다.

조사 결과

두 후보 모두 다소 느리게 작업했지만 일반적으로 일반 tar에 비해 적어도 duplicati에서는 진전이 있습니다. 그러한 발전의 대가도 분명합니다. 눈에 띄는 부담입니다.
프로세서. 일반적으로 결과 예측에는 특별한 편차가 없습니다.

조사 결과

어디든 서두를 필요가 없고 여분의 프로세서도 있다면 고려된 솔루션 중 어느 것이든 가능합니다. 어쨌든 tar 위에 래퍼 스크립트를 작성하여 반복해서는 안 되는 꽤 많은 작업이 수행되었습니다. . 백업 복사본을 저장하는 서버를 완전히 신뢰할 수 없는 경우 암호화 기능은 매우 필요한 속성입니다.

솔루션 기반에 비해 rsync - 순수한 형태의 tar는 rsync보다 20-30% 더 빠르게 작동한다는 사실에도 불구하고 성능이 몇 배 더 나쁠 수 있습니다.
저장소 크기가 절약되지만 중복된 경우에만 가능합니다.

발표

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

게시자: 파벨 뎀코비치

출처 : habr.com