나는 지난 며칠 동안 obnam을 사용해 왔으며 매우 유망해 보이고 기본적으로 백업 도구에서 원하는 모든 기능을 제공하는 것처럼 보이지만 그 성능에 매우 실망했습니다. 사실, 속도가 너무 느려 여기서는 obnam이 잘못된 것이 아니라고 의심하지만 내 환경의 무언가가 문제를 일으키고 있습니다.
그래서 나는 다른 사람이 obnam을 사용하고 있거나 문제를 식별하기 위해 내부에 대해 충분히 알고 있는지 궁금합니다.
지금까지 내가 알 수 있는 바에 따르면, obnam은 백업된 각 파일에 대해 별도의 gpg 프로세스를 생성하는 것 같습니다. htop, strace 및 iostat를 살펴보면 초기 백업 속도는 주로 지속적인 분기로 인해 제한되는 반면, CPU 및 드라이브(네트워크와 관련되지 않음)는 대부분 사용률이 20% 미만으로 유휴 상태입니다.
내 백업에는 약 500,000개의 파일이 있으며 총 데이터 용량은 170GiB입니다. 따라서 각 백업 실행마다 gpg는 500,000번 포크됩니다. 사실 첫 번째 실행에는 거의 하루가 걸렸고 두 번째 실행에는 대부분의 파일이 변경되지 않은 상태에서 3시간 이상이 걸렸다는 사실도 놀랍지 않습니다. 그러나 이것이 정말로 obnam 사용자가 기대하는 성능입니까? 비교를 위해 rsnapshot(동일 데이터, 동일한 시스템, 동일한 드라이브)의 증분 실행에는 약 4분이 소요됩니다. 물론 암호화는 필요하지 않지만 그렇게 해서는 안 됩니다.저것중요한.
솔직하게 말하자면, 다른 사람의 컴퓨터도 gpg(작은 데이터 덩어리 암호화)를 초당 50회 이상 실행할 수 없어서 궁극적으로 obnam을 거의 사용할 수 없는 느린 도구로 만드는 것일까요? 아니면 나만 그런 걸까?
(FWIW, 내 컴퓨터는 8G RAM과 SSD 드라이브를 갖춘 Core i5-2500이며 Gentoo를 실행합니다. 백업은 HDD에서 수행되지만 SSD에 대한 백업은 I/O가 아니기 때문에 차이를 볼 수 없습니다. -제한됨.)
답변1
다음은 obnam 속도를 높이는 방법에 대한 좋은 내용입니다(어쩌면 10배 더 빠르게 실행될 수도 있음).http://listmaster.pepperfish.net/pipermail/obnam-support-obnam.org/2014-June/003086.html
요약: 명령줄 또는 구성 파일에 "--lru-size=1024 --upload-queue-size=512"를 추가합니다. obnam의 메모리 사용량이 약간 증가한다는 점에 유의하십시오.
답변2
나는 이 문제에 대해 몇 가지 방법으로 접근할 것이라고 생각했습니다. 먼저 다음과 같은 방법으로 직접 진단해 보도록 하겠습니다.
1.obnam 로그
obnam우선, 다음과 같은 메시지를 기록할 수 있습니다.
$ obnam --log obnam.log
스위치를 사용하여 로깅 수준을 높여 --log-level자세한 내용을 얻을 수도 있습니다.
--log=FILE write log entries to FILE (default is to not write log
files at all); use "syslog" to log to system log, or
"none" to disable logging
--log-level=LEVEL log at LEVEL, one of debug, info, warning, error,
critical, fatal (default: info)
2. 분석
obnam다음 발췌문에서 수행 중인 작업에 대한 개요를 확인할 수도 있습니다.프로젝트 FAQ:
환경 변수에 파일 이름이 포함되어 있으면
OBNAM_PROFILE분석 데이터가 여기에 저장되며 나중에 다음을 사용하여 볼 수 있습니다obnam-viewprof.$ OBNAM_PROFILE=obnam.prof obnam ... obnam-viewprof obnam.prof | less특정 설정과 관련되지 않은 성능 문제도 사용할 수 있습니다
obnam-benchmark tool.
3. 인보이스 발행
자체 조사를 통해 성능을 여전히 판단할 수 없는 경우 다음을 수행합니다.프로젝트 웹사이트에서 티켓을 오픈하세요. 내가 아는 한, 개발자는 일정 수준의 대응력을 갖고 있으며 아마도 프로젝트 문제 해결에 있어 최고일 것입니다.
obnamSFTP만 사용하는 것 같으니 문제의 원인은 분명할 것입니다. 또한 obnam테스트 자체에서 이 정보를 얻으려고 시도하기 전에 시스템 + 네트워크 연결에 대한 이론적 최대값이 무엇인지 알 수 있도록 SFTP 성능에 대한 기본 분석을 별도로 수행하는 것도 고려할 것입니다 .
추가 데이터 포인트
#1 - obnam과 rsnapshot을 비교하는 블로그 게시물작성자가 이 카테고리의 여러 옵션을 비교하는 이 블로그 게시물을 찾았습니다. 기사 제목은 다음과 같습니다.rsnapshot 및 obnam의 예약된 대규모 백업 비교.
obnam이 기사에서는 IMO가 설명하는 내용과 일치하는 것으로 보이는 매우 낮은 성능을 강조합니다 .
오난 퍼포먼스
/home의 전체 백업을 수행한 후(며칠 소요됨) 며칠 후에 새로 실행하십시오(Linux time 명령으로 시간 측정).
3443706개 파일 백업, 127시간 48분 49초 만에 94.0GiB 업로드, 평균 속도 214.2KiB/s830 파일 1.24GiB(0B/s) 실제 7668m56.628s 사용자 4767m16.132s 시스템 162m48.739s
obname 로그 파일에서:
2012-11-17 12:41:34 INFO VFS: baseurl=/home read=0 written=0 2012-11-21 23:09:36 INFO VFS: baseurl=/backups/backup_home read=2727031576964 written=150015706142 2012-11-21 23:09:36 INFO Backup performance statistics: 2012-11-21 23:09:36 INFO * files found: 3443706 2012-11-21 23:09:36 INFO * uploaded data: 100915247663 bytes (93.9846482715 GiB) 2012-11-21 23:09:36 INFO * duration: 460128.627629s 2012-11-21 23:09:36 INFO * average speed: 214.179341663 KiB/s 2012-11-21 23:09:36 INFO Backup finished. 2012-11-21 23:09:36 INFO Obnam ends 2012-11-21 23:09:36 INFO obnam version 1.2 ends normally따라서 약 100GB의 변경된 데이터를 백업하는 데 약 5일이 걸립니다. CPU나 RAM 측면에서 머신의 로드는 높지 않습니다. /backups/backup_home의 디스크 사용량은 5.7T이고 /home은 6.6T이므로 일부 중복 제거가 있는 것 같습니다.
스냅샷 성능
*오남이 있는 로프트/home의 전체 백업(로그 파일에 따라):
[27/Nov/2012:12:55:31] /usr/bin/rsnapshot daily: started [27/Nov/2012:12:55:31] echo 17632 > /var/run/rsnapshot.pid [27/Nov/2012:12:55:31] mkdir -m 0700 -p /backups/backup_home_rsnapshot/ [27/Nov/2012:12:55:31] mkdir -m 0755 -p /backups/backup_home_rsnapshot/daily.0/ [27/Nov/2012:12:55:31] /usr/bin/rsync -a --delete --numeric-ids --relative --delete-excluded /home /backups/backup_home_rsnapshot/daily.0/localhost/ [28/Nov/2012:23:16:16] touch /backups/backup_home_rsnapshot/daily.0/ [28/Nov/2012:23:16:16] rm -f /var/run/rsnapshot.pid [28/Nov/2012:23:16:16] /usr/bin/rsnapshot daily: completed successfully따라서 6.3TB의 전체 백업에는 약 1.5일이 소요됩니다. 하루 후 증분 백업에는 다음이 필요합니다.
[29/Nov/2012:13:10:21] /usr/bin/rsnapshot daily: started [29/Nov/2012:13:10:21] echo 20359 > /var/run/rsnapshot.pid [29/Nov/2012:13:10:21] mv /backups/backup_home_rsnapshot/daily.0/ /backups/backup_home_rsnapshot/daily.1/ [29/Nov/2012:13:10:21] mkdir -m 0755 -p /backups/backup_home_rsnapshot/daily.0/ [29/Nov/2012:13:10:21] /usr/bin/rsync -a --delete --numeric-ids -- relative --delete-excluded --link-dest=/backups/backup_home_rsnapshot/daily.1/localhost/ /home/backups/backup_home_rsnapshot/daily.0/localhost/ [29/Nov/2012:13:25:09] touch /backups/backup_home_rsnapshot/daily.0/ [29/Nov/2012:13:25:09] rm -f /var/run/rsnapshot.pid [29/Nov/2012:13:25:09] /usr/bin/rsnapshot daily: completed successfully즉, 15분...21GB의 변경된 데이터입니다.
그다지 철저하지는 않지만 언급된 단점 중 하나 obnam는 attic.
Aubunan의 장점:
- 잘 기록 된
- 활성 메일링 리스트
- 사용 가능한 패키지
오브난 단점:
- 아주 느린
- 대규모 백업
로프트 장점:
- 백업 규모가 훨씬 작음(중복 제거 없이도)
- 더 나은 중복 제거
- 훨씬 더 빨리
로프트 단점:
- 저장소 형식이 문서화되지 않았습니다.
- 대규모 사용자 커뮤니티가 아님
표시된 테스트 데이터 중 일부는 속도가 obnam실제로 느리다는 것을 나타내는 것 같습니다.
일반 WiFi 연결을 통해 로컬 SSD에서 원격 HD로:
rsync: 0:24 0:01 Attic ssh: 0:28 0:05 Attic sshfs: 0:51 0:08 Obnam sftp: 8:45 0:21 Obnam sshfs: 25:22 0:22
인용하다
답변3
Obnam의 기본 구성(2015년 2월 8일 기준)은 다수의 작은 파일이 포함된 디렉터리를 백업하는 데 적합하지 않습니다. 위에서 언급한 것과 똑같은 문제가 발생했습니다.
내 해결책은 명령줄에 --lru-size=8192 --upload-queue-size=8192 를 추가하는 것이었습니다. 이를 통해 문제가 해결되었고 좌절했던 Obnam 사용자가 매우 행복한 사용자로 바뀌었습니다. (이제 표준 프로필에 이러한 설정이 있습니다.)
불행하게도 Obnam의 튜토리얼에서는 이러한 설정의 중요성을 미리 언급하지 않습니다. FAQ에 자세한 내용이 나와 있습니다. 작은 파일이 많은 시스템의 경우 성능 매개변수 설정은 실제로 필수입니다.