Avamar: 백업 성능 저하 문제 해결
Summary: 이 문서에서는 Avamar 백업 성능을 구성 요소로 분류하여 설명합니다. 이 문서에서는 느린 Avamar 백업을 조사하고, 병목 현상을 식별하고, 그 영향을 완화하는 방법에 대한 실용적인 지침을 제공합니다.
Symptoms
- 파일 시스템 또는 데이터베이스를 Avamar Server 또는 Data Domain 백엔드로 백업하는 Avamar Client
- 초기 백업이 완료되고 전체 백업이 Avamar Server에 있는 L1 백업
클라이언트 백업 성능을 최적화하는 이유
- 백업 기간 내에 개별 백업을 안정적으로 완료할 수 있도록 합니다.
- Avamar Client의 하드웨어 리소스에 대한 불필요한 로드를 최소화합니다.
- 백업 세션을 효율적으로 사용하고 백업 대기 시간을 줄입니다.
- 백업이 유지 보수 작업과 겹치면 모든 작업이 느리게 실행됩니다.
- 해시 참조 비트맵이 재설정될 수 있도록 부하가 적은 시간을 제공합니다(
백업 성능 저하의 일반적인 증상:
- 예약된 기간 내에 백업이 완료되지 않습니다. 활동 모니터에 "Client time out - end" 보고
- 예약된 기간이 끝나기 전에는 백업을 시작할 수 없습니다. 활동 모니터에 "Client time out - start" 보고
- 가비지 컬렉션이 정기적으로 실패하고 MSG_ERR_BACKUPSINPROGRESS 또는 MSG_ERR_TRYAGAINLATER가 표시됨
성능 관점에서 Avamar 백업 중에 발생하는 결과에 대한 이해
백그라운드에서 Avamar Client 백업 성능 및 동작에 영향을 미치는 결과에 대한 자세한 설명은 다음 문서에서 확인할 수 있습니다.
Cause
Resolution
정보 수집:
문제에 대한 자세한 정보를 수집합니다.
백업 체인의 어느 부분에서 병목 현상이 가장 심한지 확인:
다음은 백업 시스템의 주요 구성 요소를 보여주는 개요입니다. 
병목 현상은 항상 존재하지만 병목 현상이 어디에 발생하는지 이해하기 위해 노력해야 합니다.
이를 통해 병목 현상을 완화할 수 있다면 성능을 향상할 수 있을 것입니다.
병목 현상이 완화되면 또 다른 병목 현상이 나타날 수 있습니다. 최종 목표는 백업 기간이 허용되는 상황에 도달하는 것입니다.
Avamar Server 측 병목 현상:
Avamar Server에 대한 모든 백업이 느린 경우 서버 측 문제의 가능성을 고려합니다.
특정 시간 동안 Avamar Server에 대한 모든 백업이 느린 경우 서버 측 경합 또는 네트워크 병목 현상이 원인일 수 있습니다.
하나 또는 몇 개의 백업 클라이언트에 성능 문제가 있는 경우 각 클라이언트에만 집중하십시오.
서버 상태:
정상 상태의 Avamar 시스템에서는 백업 시 병목 현상이 발생할 가능성이 낮습니다.
백업 서버의 상태를 확인합니다.
- Avamar: Avamar Server에서 proactive_check.pl 상태 점검 스크립트를 실행하는 방법
- 백업이 Data Domain으로 전송되는 경우 DD 자동 지원 정보를 확인하거나 Data Domain 지원과 협력하여 백업이 정상 상태인지 확인합니다.
Avamar는 허용되는 성능 수준을 유지하기 위해 클라이언트 연결을 제한합니다.
서버 경합:
백업 성능이 저하되는 시간이 있는 경우 경합이 발생했을 수 있습니다.
- sched.sh 스크립트는 느린 백업과 동시에 실행 중인 작업을 시각적으로 표시합니다.
- 다음을 참조하십시오. Avamar: sched.sh 스크립트를 사용하여 Avamar Server에서 기간별 백업, 복제 및 유지 보수 작업을 확인하는 방법
- status.dpn을 실행하여 진행 중인 유지 보수 작업 확인
- 활성 상태인 클라이언트 세션 수 확인
-
admin@utilitynode:~/>: avmaint session | grep path | wc -l
-
- 유지 보수 및 백업 스케줄이 겹치지 않도록 준비합니다.
- status.dpn 및 top 명령의 출력을 검토하여 데이터 노드의 로드를 확인합니다.
- 데이터 노드에서 mapall 'iostat -x'를 실행합니다. %iowait, %idle 및 % util을 확인하여 디스크의 I/O 대역폭이 포화 상태인지 확인합니다.
- 특정 클라이언트의 성능을 파악하려면 Avamar Server가 유지 보수 작업이나 다른 백업 또는 복제를 수행하지 않을 때 백업을 테스트합니다.
Data Domain 백업 수집 성능:
Dell 지원 포털에 로그인하여 다음을 검토합니다.
네트워크 측 병목 현상:
클라이언트가 WAN을 통해 백업되는 경우 네트워크에 병목 현상이 발생할 수 있습니다.
네트워크 레이턴시:
클라이언트가 Avamar Server에 해시가 있는지 확인할 수 있는 속도에 영향을 줍니다.
- 클라이언트에서 Avamar Server로 ping을 실행하여 네트워크의 패킷 손실과 레이턴시를 확인합니다.
네트워크 대역폭:
백업 중에는 새 데이터를 네트워크를 통해 Avamar Server로 전송해야 합니다. 완료된 백업에 대한 로그를 확인하고 전송되는 용량을 확인합니다.
2014-11-20 04:45:30 avtar Info <5156>: Backup #1180 timestamp 2014-11-20 04:45:28, 23 files, 5 folders, 291.7 GB (23 files, 4.316 GB, 1.48% new)
클라이언트와 서버가 WAN으로 구분되어 있는 경우 링크에서 백업 기간 내에 필요한 데이터를 전송할 수 있습니까?
이 경우 전송해야 하는 데이터는 4.316GB입니다.
이러한 값은 모두 상호 연관되어 있습니다.
- 새 백업 데이터의 양
- 백업 가능한 시간
- 효과적인 네트워크 대역폭

새 데이터의 양이 많을수록 네트워크 대역폭이 더 많이 필요하거나 백업 시간이 더 오래 걸립니다.
이러한 요소에는 실질적인 제한이 있지만 사용자가 어느 정도 제어할 수 있습니다.
시기 적절한 백업을 수용하도록 해당 제한을 조작할 수 있는지 고려해야 합니다.
네트워크 병목 현상 또는 서버 통신 문제가 의심되는 경우:
클라이언트와 백업 디바이스 간의 네트워크 처리량을 확인합니다.
avtar comstats 로깅을 활성화하여 문제를 쉽게 해결할 수 있습니다.
클라이언트 측 병목 현상:
서버에 대한 클라이언트의 초기 백업이 아닌지 확인:
최초 백업은 느릴 것으로 예상됩니다.
성숙한 클라이언트인 경우 백업 구성이 최근에 변경되었는지 확인합니다.
백업이 조기에 취소되지 않았는지 확인:
백업 로그에서 'canceled'를 검색합니다. 다음은 조급한 사용자가 L1 백업을 취소한 경우의 예시입니다.
2013-11-05 12:15:29 avtar Info <5157>: PARTIAL Backup #14 timestamp 2011-11-05 12:13:36, 2,030 files, 562 folders, 397.3 MB (691 files, 17.44 MB, 4.39% new)
2013-11-05 12:15:29 avtar Info <7539>: Label "MOD-xxxxxxxxxx", scheduled to expire 11/12/11, none backup
2013-11-05 12:15:29 avtar Info <6083>: Backed-up 397.3 MB in 1.36 minutes: 17 GB/hour (89,593 files/hour)
2013-11-05 12:15:29 avtar Info <7883>: Finished at 2011-11-05 12:15:29 GMT Standard Time, Elapsed time: 0000h:01m:21s
2013-11-05 12:15:29 avtar Info <8468>: Sending wrapup message to parent
2013-11-05 12:15:29 avtar Info <5314>: Command failed (exit code 10013: Externally canceled)
이러한 경우 백업이 정상적으로 종료되면 데이터가 '부분' 백업으로 유지됩니다.
부분 백업 로그가 백업 성능을 나타낼 수 있지만 적절한 분석을 수행하려면 전체 백업의 로그가 필요합니다.
로그에서 파일 캐시 또는 해시 캐시 사이징 문제 확인:
스로틀링 플래그가 avtar에 전달되는지 확인:
Avtar CPU 또는 네트워크 스로틀링은 백업 성능을 크게 저하시킵니다.
Avamar: Avamar Client의 시스템 리소스(CPU, 네트워크, I/O 및 메모리) 사용을 제한하는 방법을 참조하십시오.
이는 백업 로그에서 탐지될 수 있습니다.
2013-09-06 14:22:13 avtar Info <6557>: Network bandwidth throttling is enabled, limiting to approx. 0.512 Mbps (62.50 KB/sec) 2013-09-06 14:22:13 avtar Info <6558>: CPU throttling is enabled, limiting CPU usage to approx. 70%
Avamar Client CPU 또는 메모리 병목 현상이 있습니까?
Avamar 백업은 하드웨어에서 허용하는 만큼 빠르게 실행되며 리소스에 대한 다른 서비스와 경합합니다. 고객의 "일상 작업"과 바쁜 시간을 염두에 두십시오.
작업 관리자 또는 프로세스 탐색기(Windows) 또는 'top' 명령(UNIX 또는 Linux)을 사용하여 클라이언트를 모니터링합니다. 이를 통해 백업 중에 CPU 포화가 발생하는지 알 수 있습니다.
Dell은 시간 경과에 따른 리소스 사용량과 성능을 차트로 보여주는 내부 "LogAnalyzer" 툴을 보유하고 있습니다. 이를 사용하려면 지원 부서와 협력하십시오.
캐시 파일은 백업 중에 메모리에 로드됩니다. 클라이언트의 메모리 사용량을 확인하여 페이지 오류 또는 클라이언트에 RAM이 부족하다는 단서를 확인합니다.
Data Domain에 대한 Avamar v7.x 클라이언트가 '페이징 캐시'(f_cache2.dat)를 활용하는 경우에는 크게 문제가 되지 않습니다.
페이징 캐시는 기존 '모놀로식' avtar 캐시에 비해 클라이언트의 메모리 공간을 줄일 수 있습니다.
클라이언트 측 I/O 병목 현상 확인:
클라이언트 캐시 사이징 후 백업 성능을 결정하는 데 있어 다음으로 중요한 요소는 백업 데이터를 호스팅하고 avtar에 제공하는 스토리지 시스템입니다.
타겟 스토리지의 상태가 양호한지 확인:
타겟 스토리지 디바이스에 최적의 성능을 방해하는 문제가 없는지 확인합니다.
타사 소프트웨어가 avtar와 I/O를 두고 경합하지 않는지 확인:
클라이언트의 애플리케이션이 스토리지 I/O를 두고 Avamar Client와 경합하고 있습니까?
안티바이러스 소프트웨어 실시간/액세스 시 검사는 Avamar Client 성능에 큰 영향을 미칩니다.
파일 검사를 병렬로 실행하도록 구성할 수 있습니까?
백업 데이터가 별도의 읽기 헤드로 서비스되는 여러 볼륨에서 호스팅되는 경우가 있습니다. 이러한 시나리오에서는 Avamar가 여러 볼륨을 동시에 검사하도록 볼륨 병렬 처리를 구성할 수 있습니다.
클라이언트가 CIFS 또는 NFS를 사용하여 데이터를 백업하지 않는지 확인:
CIFS 또는 NFS 데이터의 백업은 NDMP 가속기를 통해서만 지원됩니다.
스토리지 압축 또는 암호화가 사용 중인지 확인:
타겟 데이터가 파일 시스템 수준에서 압축 또는 암호화된 타겟 스토리지에 있는 경우 백업 성능이 예상보다 낮을 수 있습니다.
Perfmon을 사용하여 Windows 클라이언트 리소스 병목 현상 분석:
다음 문서에서는 특정 시점에 클라이언트가 특정 리소스를 대기하고 있는지 파악하는 성능 그래프를 생성하는 데 도움이 됩니다. LogAnalyzer 툴에서 생성한 그래프와 함께 사용해 보십시오.
Outlook 아카이브 .pst 파일 백업
.pst 파일이 많거나 큰 경우 백업이 느리게 수행될 수 있습니다.
스토리지 성능 벤치마킹
타겟 데이터가 호스팅되는 스토리지 디바이스의 성능을 확인합니다.
백업 중인 데이터로 인한 백업 성능 저하:
백업 속도가 느린 일반적인 원인은 백업 중인 데이터의 특성 때문입니다.
새 데이터나 변경된 데이터가 많은지 확인:
대용량의 몇 가지 신규 또는 수정된 파일을 사용하면 백업 기간을 초과하여 백업이 빠르게 실행될 수 있습니다. 이러한 파일을 식별하려면 다음을 참조하십시오.
Windows 클라이언트
Linux 및 UNIX 클라이언트 - 클라이언트의 데이터 세트에 대용량 스파스(sparse) 파일이 포함되어 있는지 확인합니다.
- Avamar 및 스파스 파일
- Avamar Linux 클라이언트의 백업 크기는 '/var/log/lastlog' 및 Avamar 스파스(sparse) 파일 처리 동작으로 인해 오해의 소지가 있을 수 있음
백업 요약 줄을 확인하여 백업 범위를 파악하고 이상값 식별:
백업 로그에서 "Backup#" 또는 "Backed-up" 문자열을 검색합니다.
2017-06-07 20:21:38 avtar Info <5156>: Backup #441 timestamp 2017-06-07 20:21:38, 2,653,523 files, 255,181 folders, 1,566 GB (10,777 files, 668.4 MB, 0.04% new) 2017-06-07 20:21:38 avtar Info <6083>: Backed-up 1,566 GB in 1281.60 minutes: 73 GB/hour (124,228 files/hour)
이렇게 하면 백업 성능을 조사할 때 많은 시간을 절약할 수 있습니다.
위의 출력에 대해 다음을 고려합니다.
- 초기 백업인지 레벨 1 백업인지 여부 (백업 레이블이 #441이기 때문에 가능성이 낮음)
- 백업의 파일 수가 적당한지 여부 (260만 개의 파일이 합리적임)
- 파일 대 폴더 비율 (일반적으로 10:1)
- 데이터 세트의 총 데이터 양 (최대 1.5TB)
- 처리할 파일 수와 총 파일 수의 비율 (250만 개의 파일 중 최대 11,000개가 합리적임)
- 처리할 모든 파일의 총 크기 (단지 예상치일 수 있음)
- Avamar Server로 전송할 변경된 데이터의 양 (668MB)
- 변경 비율이 합리적인지 여부 데이터 세트가 작을수록 허용되는 변경 비율이 더 높아질 수 있음(0.04%가 합리적임)
- 백업의 전체 크기와 범위를 고려할 때 시간당 성능 측면에서 합리적인 수준인지 여부 (시간당 124,000개의 파일은 다른 수치에서 볼 때 성능이 느린 것으로 간주됨)
이러한 세부 정보는 백업 성능 저하의 원인을 파악할 수 있는 충분한 데이터를 제공합니다.
필요한 경우 백업이 실행되는 동안 생성되는 상태 줄 메시지를 검토하십시오.
이 두 로그 줄의 값 중 이상값이 있는지 확인합니다. 다시 말해, 평소와 달리 비정상적으로 크거나 작습니까?
백업 동작에 익숙하다면 이상 징후를 탐지하는 것이 더 쉽습니다.
파일 대 폴더 비율
대부분의 고객 데이터 세트는 파일 대 폴더 비율이 약 10:1이고 avtar는 이를 반영하도록 조정되었습니다.
아래 예와 같이 데이터 세트의 파일 대 폴더 비율이 낮으면 소규모 튜닝 없이는 백업이 효율적으로 실행되지 않을 수 있습니다.
2015-11-18 00:34:32 avtar Info <5156>: Backup #75 timestamp 2015-11-18 00:24:43, 4,007,032 files, 1,974,043 folders, 1,589 GB (2,680 files, 419.4 MB, 0.03% new)
파일 대 폴더 비율이 낮은 데이터 세트에 대한 Avamar Client 백업 성능 튜닝을 참조하십시오.
avtar 로그 상태 정보 메시지를 사용한 성능 분석:
Notepad++ 등을 사용하여 로그를 필터링하여 Status 메시지가 포함된 모든 avtar Info 줄을 찾습니다. Avamar Client 버전에 따라 <5100> 또는 <8688>이 포함된 코드 항목을 사용하여 필터링할 수 있습니다. 이러한 줄은 avtar에서 보고하는 주기적 상태 메시지입니다.
타사 애플리케이션이 파일 메타데이터를 예기치 않게 업데이트하는지 확인:
일부 애플리케이션에서는 파일 메타데이터를 변경할 수 있습니다. 이 경우 Avamar가 전체 파일을 백업합니다.
포함 및 제외 플래그의 사용을 검토합니다. 'include' 문 사용 금지:
운영 모범 사례 가이드에서는 포함 및 제외 목록에 대해 설명합니다.
Avamar는 백업 데이터 세트의 모든 파일을 두 목록 모두와 비교하여 파일 백업 여부를 결정해야 합니다. 이 비교 프로세스는 추가적인 오버헤드를 발생시키고 백업 런타임을 늘릴 수 있습니다.
클라이언트의 avsar 디렉토리에 avtar.cmd 파일이 있는지 확인합니다.입니다.
해당 파일에 활성 --exclude 또는 --exclude-from-file 문이 있는지 확인합니다.
디렉토리 또는 파일 시스템이 제외되었지만 include 플래그를 사용하는 경우 avtar는 'include'라고 표시된 항목이 있는지 검사합니다.
데이터 세트에 재분석 지점 또는 스텁 파일이 포함되어 있는지 확인:
데이터 세트에 스텁 파일 또는 다른 디바이스에 저장된 데이터에 대한 포인터가 포함되어 있는 경우 주의하십시오.
avtar가 원격 파일을 리콜할 때까지 기다려야 한다면 백업 성능이 저하될 수 있습니다.
이러한 소프트웨어의 예는 다음과 같습니다. Enterprise Vault Archiver, Moonwalk 및 DiskXtender
Avamar 게스트 설치를 사용하여 가상 클라이언트 백업
- 하드웨어 리소스 병목 현상으로 인해 가상 머신의 Avamar 게스트 백업이 느리게 실행되고 시간이 초과됨
- VMware vShield Endpoint Trend Micro Deep Security로 인해 Avamar VM 클라이언트 게스트 백업 성능이 저하됨
파일 검사 동작 변경으로 인한 v7.2의 알려진 백업 성능 관련 문제
Additional Information
기타 참고 사항
- 가상 머신 클라이언트의 리소스가 제한되어 있지 않거나, 가상 머신 클라이언트가 Avamar 백업을 신속히 완료하는 기능에 영향을 미치는 엄격한 하드웨어 제한 사항을 준수하는지 확인합니다. 사용량이 많은 시스템에서 운영 체제에 과부하가 발생하거나 너무 많은 스레드를 조작하여 심각한 컨텍스트 전환이 발생할 수 있습니다.
- Avamar 운영 모범 사례 가이드를 활용하여 Avamar 시스템을 최적화하고, 백업을 예약하고, 클라이언트 캐시를 튜닝하는 데 도움을 받으십시오.
기타 참고 자료