Avamar GSAN 또는 사용자 용량 해결 경로

OS(Operating System) 용량에 대한 초기 개념 및 이해는 다음을 참조하십시오. Avamar: 용량 일반 교육 - 해결 경로

일반적으로 고려하는 것이 가장 쉽습니다 GSAN 클라이언트 백업의 공간 및 활용도로서의 용량입니다.

• 중복 제거에 대한 기본적인 이해
• 체크포인트에 대한 기본적인 이해, 체크포인트 검증(hfscheck), 가비지 컬렉션 및 각각의 중요성.
• 차이점: GSAN (또는 사용자) 용량 및 OS 용량
• 변경률
• 상시 상태

• 그리드 액세스 상태가 "관리자 모드"로 변경된 경우 백업 또는 복제 실패

  • 다음과 유사한 메시지와 함께 클라이언트 백업 작업이 실패할 수 있습니다.  "avtar Info <5314>: Command failed (1 error, exit code 10028: Operation failed because target server is full)"
• 백업 스케줄러의 자동 비활성화(다른 사용자가 확인하고 지울 때까지)

• 80% - 용량 경고
• 95% - 상태 점검 제한에 도달했습니다(적어도 수동으로 확인하기 전까지는 백업 스케줄러가 비활성화될 수 있음).
• 100% - 서버 읽기 전용 제한에 도달함(그리드가 관리자 모드로 전환됨)

1. Avamar는 중복 제거로 인해 각 클라이언트 백업 작업 간의 사소한 변경 사항과 차이점만 저장하고 저장하면 됩니다. 새 백업(또는 수신 복제)이 실행되면 새 데이터가 추가되고 Avamar 용량 또는 활용도 값이 증가할 수 있습니다. 
2. 일정 시간이 지나면 구성된 보존 및 만료 기간에 따라 백업이 만료되고 복원할 수 있는 Avamar 그리드에서 찾을 수 없습니다. 
3. GC(Garbage Collection)라는 Avamar 유지 보수 작업이 실행되면 만료된 백업으로 인해 더 이상 필요하지 않은 데이터의 고유한 부분 또는 청크를 모두 찾습니다. GC는 중복 제거를 통해 현재 백업에서 동일한 데이터를 공유하는 것이 없는지 확인한 다음 더 이상 필요하지 않은 데이터 청크를 제거하거나 해제하여 Avamar Server 용량 또는 활용도를 낮춥니다.

매일 추가되는 수신 데이터의 양이 정리되는 일일 데이터의 양과 거의 같은 경우 이를 "안정 상태"라고 합니다. 이는 설치된 모든 Avamar 그리드의 목표입니다.

새 Avamar 그리드를 설정하고 구성하기 전에 백업 데이터를 저장하는 데 필요한 용량을 결정하기 위해 일반적인 설치 전 사이징 계산이 수행됩니다. 이러한 계산은 고객 보존 요구 사항과 백업할 데이터의 양을 기반으로 합니다. 또한 평균적으로 중복 제거할 수 있는 데이터의 양을 추정합니다.

1. 가비지 컬렉션이 일관되게 실행되지 않음
2. 가비지 컬렉션 성능이 느리거나 충분히 오래 실행되지 않습니다.
3. Avamar 그리드 설치 전에 예상되는 중복 제거가 정확하지 않음
4. Avamar 그리드 설치 전에 계산된 데이터 이외의 데이터가 이 Avamar Server에 백업됩니다.
5. 다른 이유들

아래의 각 문제 해결 단계가 환경에 해당하는지 확인합니다.

1단계. 데이터 수집:

Avamar 그리드에 다른 용량 외 문제가 없는지 확인합니다. 있는 경우 용량 문제를 해결하기 전에 주의가 필요할 수 있습니다.

여기에는 하드웨어 오류, 데이터 무결성 문제(오프라인 노드 포함), 오프라인 스트라이프, 체크포인트 검증 실패 또는 유지 보수 작업 실패가 포함됩니다. 이 중 하나라도 문제이면 용량 문제 해결을 중지하고 다른 문제를 해결해야 합니다. 다른 문제가 해결되면 용량을 다시 검토할 수 있습니다.

상태 점검을 실행해야 합니다(Avamar: Avamar Server에서 proactive_check.pl 상태 점검 스크립트를 실행하는 방법, 최소한 status.dpn 명령은 대부분의 동일한 문제에 대한 빠른 개요 및 확인을 제공할 수 있습니다. 다음을 참조하십시오. Avamar: status.dpn 명령으로 생성된 출력을 이해하는 방법

자세한 내용은 다음 문서를 참조하십시오. Avamar: "Avamar 문제 해결 계층 구조" 접근 방식을 올바르게 적용하는 방법

용량 외 문제를 해결하기 위해 지원이 필요한 경우 Dell Technologies Avamar 지원 팀에 서비스 요청을 생성 하십시오.

2 단계. 용량 정보 수집: 

Avamar 용량 문제를 해결하는 데 필요한 모든 정보는 다음을 참조하십시오. Avamar: 용량 문제를 해결하기 위한 정보를 수집하는 방법

적어도, status.dpn 명령을 실행하거나 Avamar Administration UI 내의 값을 실행하면 GSAN 용량.

3 단계. OS 용량이 가득 찼는지 확인합니다.

다음 명령을 실행하면 각 디스크 파티션에 대한 OS 용량의 현재 값을 확인할 수 있습니다. 두 번째 샘플 출력에서와 같이 값이 85%에 도달하거나 초과하면 높은 OS 용량으로 간주됩니다.

avmaint nodelist | egrep 'nodetag|fs-percent-full'

샘플 출력:

nodetag="0.2"
        fs-percent-full="56.6"
        fs-percent-full="54.7"
        fs-percent-full="54.4"
        fs-percent-full="54.6"
        fs-percent-full="54.7"
        fs-percent-full="54.7"
      nodetag="0.1"
        fs-percent-full="56.2"
        fs-percent-full="54.6"
        fs-percent-full="54.6"
        fs-percent-full="54.8"
        fs-percent-full="54.8"
        fs-percent-full="54.5"
      nodetag="0.0"
        fs-percent-full="56.2"
        fs-percent-full="54.7"
        fs-percent-full="54.8"
        fs-percent-full="54.7"
        fs-percent-full="54.6"
        fs-percent-full="54.6"

nodetag="0.2"
        fs-percent-full="94.5"
        fs-percent-full="94.4"
        fs-percent-full="94.2"
        fs-percent-full="94.1"
        fs-percent-full="94.0"
        fs-percent-full="94.0"
      nodetag="0.1"
        fs-percent-full="94.5"
        fs-percent-full="94.3"
        fs-percent-full="94.1"
        fs-percent-full="93.6"
        fs-percent-full="94.0"
        fs-percent-full="93.9"
      nodetag="0.0"
        fs-percent-full="94.4"
        fs-percent-full="94.4"
        fs-percent-full="94.0"
        fs-percent-full="94.1"
        fs-percent-full="92.7"
        fs-percent-full="92.5"

OS 용량이 85% 미만인 경우에만 GSAN 용량 문제 해결이 계속됩니다. 

4 단계. 때때로 용량으로 오해될 수 있는 비용량 문제:

클라이언트 백업은 "용량" 때문이 아니라 "할당량" 때문에 실패할 수 있습니다. 이를 용량으로 오해하는 경우가 있습니다.

이 상황은 다음을 통해 확인할 수 있습니다. status.dpn 명령 또는 더 낮은 용량을 보여주는 다른 수집된 출력 중 일부입니다.

또한 클라이언트 백업이 실패했거나 다른 이유로 실행되지 않았을 수도 있습니다. Non-GSAN 용량 이유 수집된 정보에서 이를 확인하거나 Avamar Administration UI에서도 확인할 수 있습니다.

• Avamar: 메타데이터 용량 확인 경로
• Data Domain: Avamar 통합 해결 경로의 대용량

만일 GSAN 용량이 많고 이러한 다른 용량도 높은 경우 어떤 순서로든 문제 해결을 수행할 수 있습니다(항상 첫 번째여야 하는 OS 용량 제외).

5 단계. 스트라이프 밸런스 및 OS 디스크 밸런스:

Avamar의 "스트라이프"는 데이터 노드(단일 노드 Avamar 그리드 제외)에 백업 데이터가 저장되는 컨테이너 파일입니다.

스트라이프는 그리드 내의 서로 다른 디스크와 노드에 걸쳐 "균형"이 잡히거나 균등하게 분포되어 있을 것으로 기대되지만, 때때로 불균형이 될 수 있습니다.

Avamar에서는 가장 큰 노드 또는 디스크 파티션이 Avamar 용량을 제한하는 요인으로 설계되어 있습니다.

이는 디스크 또는 노드가 처리할 수 있는(또는 허용된) 것보다 더 많은 스트라이프를 생성하지 않도록 의도적으로 수행된 것이므로 균형 잡힌 스트라이프를 갖는 것이 용량에 중요합니다.

예를 들어, Avamar 그리드 확장을 위해 데이터 노드를 추가할 때 스트라이프를 새 노드에 균등하게 분산하여 전체 Avamar 용량 비율을 줄이려면 밸런싱을 실행해야 합니다.

이해가 필요한 또 다른 유형의 균형은 OS 디스크 균형입니다. 이는 여러 노드의 파티션이 아닌 동일한 노드의 데이터 파티션으로만 제한됩니다. 

동일한 데이터 노드에서 한 파티션이 SAME 노드의 다른 파티션보다 훨씬 크거나 작은 경우 "freespaceunbalance"로 이동되었습니다. 이것은 일반적으로 OS에 있지만 GSAN 용량, 다음과 같이 보고할 수 있습니다. GSAN 용량 문제입니다.

6 단계. 가비지 수집이 완료되었는지 확인합니다. 

다음 명령을 실행하여 가비지 컬렉션에 대한 정보를 가져옵니다.

dumpmaintlogs --types=gc --days=30 | grep "4201\|2402"

이상적으로는 출력에 GC가 지난 30일 동안 완료되었다고 표시됩니다.

2025/10/07-12:00:35.24911 {0.1} <4201> completed garbage collection
2025/10/08-12:00:34.61185 {0.1} <4201> completed garbage collection
2025/10/09-12:00:35.14874 {0.1} <4201> completed garbage collection
2025/10/10-12:00:34.67986 {0.1} <4201> completed garbage collection
2025/10/11-12:00:34.73284 {0.1} <4201> completed garbage collection
2025/10/12-12:00:33.23205 {0.1} <4201> completed garbage collection
2025/10/13-12:00:33.41448 {0.1} <4201> completed garbage collection
2025/10/14-12:00:35.70726 {0.1} <4201> completed garbage collection
2025/10/15-12:00:35.08316 {0.1} <4201> completed garbage collection
2025/10/16-12:00:34.82681 {0.1} <4201> completed garbage collection
2025/10/17-12:00:35.29262 {0.1} <4201> completed garbage collection
2025/10/18-12:00:35.24618 {0.1} <4201> completed garbage collection
2025/10/19-12:00:34.56531 {0.1} <4201> completed garbage collection
2025/10/20-19:06:45.15574 {0.1} <4201> completed garbage collection
2025/10/21-12:00:34.21062 {0.1} <4201> completed garbage collection
2025/10/22-12:00:35.29770 {0.1} <4201> completed garbage collection
2025/10/23-12:00:36.13041 {0.1} <4201> completed garbage collection
2025/10/24-12:00:35.52502 {0.1} <4201> completed garbage collection
2025/10/25-12:00:35.93730 {0.1} <4201> completed garbage collection
2025/10/26-12:00:35.55037 {0.1} <4201> completed garbage collection
2025/10/27-12:00:36.12049 {0.1} <4201> completed garbage collection
2025/10/28-12:00:35.75633 {0.1} <4201> completed garbage collection
2025/10/29-12:00:34.85499 {0.1} <4201> completed garbage collection
2025/10/30-12:00:34.96325 {0.2} <4201> completed garbage collection
2025/10/31-12:00:35.39840 {0.0} <4201> completed garbage collection
2025/11/01-12:00:35.11248 {0.0} <4201> completed garbage collection
2025/11/02-13:00:34.39202 {0.0} <4201> completed garbage collection
2025/11/03-13:00:34.70587 {0.0} <4201> completed garbage collection
2025/11/04-13:00:34.18799 {0.0} <4201> completed garbage collection
2025/11/05-13:00:34.44950 {0.0} <4201> completed garbage collection

GC 실패 메시지에는 다음이 포함될 수 있지만 이에 국한되지는 않습니다.

2025/11/04-13:00:01.62234 {0.1} <4202> failed garbage collection with error MSG_ERR_DDR_ERROR

2025/11/01-12:35:06.62868 {0.2} <4202> failed garbage collection with error MSG_ERR_BACKUPSINPROGRESS

2025/10/13-12:20:07.35498 {0.7} <4202> failed garbage collection with error MSG_ERR_TRYAGAINLATER

2025/10/27-12:07:44.35485 {0.0} <4202> failed garbage collection with error MSG_ERR_DISKFULL

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_MISC

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_TIMEOUT

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_GARBAGECOLLECT

GC가 실패한 경우 먼저 다음 문서를 참조로 사용하여 이 문제를 해결하십시오. Avamar: GC(Garbage Collection) 오류 문제 해결(해결 경로)
(이미 해결된 문제가 있는 경우 다음 단계로 이동합니다.)

7 단계. GC가 충분히 오래 실행되고 있습니까?

a. 다음 명령을 실행하여 GC에 허용되는 최대 시간을 확인합니다.

dumpmaintlogs --types=gc --days=30 | grep gcflags 

샘플 출력:

2025/10/07-12:00:20.05509 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/08-12:00:20.09141 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/09-12:00:20.42307 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/10-12:00:20.47775 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
...
2025/11/02-13:00:19.76100 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/03-13:00:19.92093 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/04-13:00:19.42781 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/05-13:00:19.74984 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>

다음 사항에 유의하십시오. maxtime value이며, 이 예에서는 14400(초)입니다.
(값이 0이면 무제한임)

b. 다음 명령을 실행하여 GC가 실행되는 시간과 완료
되는 "패스" 수를 확인합니다. 생각해 보십시오. GSAN 양파 층과 같은 용량. 내부 층이 보이기 전에 외부 층을 벗겨내거나 제거해야 합니다. 각 패스는 GSAN 저장된 데이터.)

dumpmaintlogs --types=gc --days=30 | grep passes | cut -d ' ' -f1,14-20

샘플 출력:

2025/10/07-12:00:35.24463 passes="24" start-time="1758283220" elapsed-time="250" end-time="1758283235"/>
2025/10/08-12:00:34.60779 passes="3" start-time="1758369620" elapsed-time="70" end-time="1758369627"/>
2025/10/09-12:00:35.14232 megabytes-recovered="1" passes="4" start-time="1758456020" elapsed-time="85" end-time="1758456028"/>
2025/10/10-12:00:34.67590 passes="3" start-time="1758542420" elapsed-time="72" end-time="1758542427"/>
...
2025/11/02-13:00:34.38348 megabytes-recovered="2" passes="18" start-time="1762088419" elapsed-time="89" end-time="1762088427"/>
2025/11/03-13:00:34.69743 passes="18" start-time="1762174819" elapsed-time="9" end-time="1762174828"/>
2025/11/04-13:00:34.17943 megabytes-recovered="8" passes="22" start-time="1762261219" elapsed-time="134" end-time="1762261228"/>
2025/11/05-13:00:34.44187 megabytes-recovered="2" passes="16" start-time="1762347619" elapsed-time="119" end-time="1762347628"/>

패스 수를 기록하고 elapsed-time (초).

c. 가정 maxtime 가 0이 아닌 경우 의 2/3를 계산합니다. maxtime를 클릭하고 경과 시간과 비교합니다.
(위의 예에서 14400의 2/3는 9600이고 모든 경과 시간 출력은 이 그림보다 훨씬 낮습니다.)

다양한 문제로 인해 GC가 느리게 실행되거나 모든 항목을 스캔하지 못할 수 있습니다. 여기에는 과거에 상당한 시간 또는 며칠 동안 실행할 시간이 충분하지 않았거나 잘못된 구성, 오류 등이 포함될 수 있습니다.

에 대한 우려가 있는 경우 maxtime또는 통과 횟수인 경우 Dell Technologies Avamar 지원 팀에 서비스 요청을 생성 하여 자세히 조사하십시오.

8 단계. GC가 충분하거나 예상 데이터를 제거하지 않은 것으로 의심되는 경우:

GC가 충분히 오래 실행되는 것으로 확인되면 가비지 컬렉션 제어 이외의 이유로 데이터가 수집되지 않을 수 있습니다. 다음은 일반적으로 확인해야 하는 문서화된 이유 목록입니다.

a. 백업이 최소한 최종적으로 또는 정기적으로 만료되도록 구성되어 있는지 확인합니다. 만료되는 백업이 자주 없는 경우 GC에서 수행할 작업이 많지 않습니다.

b. 이 문서를 사용하여 "Top Change Rate" 클라이언트를 찾습니다. Avamar: capacity.sh 스크립트를 사용하여 용량을 관리하는 방법 (% OF TOTAL" 및 "CHGRATE".)

c. Avamar당 건너뛴 해시 확인: Avamar Garbage Collection은 정리할 수 없는 "skipped-hashes"를 보고합니다. 이러한 일이 드물지만 발생하는 경우 이는 정상이며 건너뛸 수 있습니다.

d. Avamar Server가 모든 클라이언트의 최신 백업을 유지하도록 강제하는 플래그 또는 옵션이 있습니다. 이 백업은 클라이언트의 모든 백업이 실수로 만료되지 않도록 하기 위한 안전용으로 사용됩니다. 그러나 이로 인해 데이터 정리 및 가비지 수집과 관련하여 다른 문제가 발생할 수 있습니다. Dell Technologies Avamar 지원 팀에서 이 기능의 활성화 여부를 확인할 수 있습니다.

e. 최근 백업이 다음에서 전환된 경우 GSAN DD 백엔드에 연결하거나 실수로 GSAN backup이지만 GSAN 용량이 감소하지 않을 경우 Dell Technologies Avamar 지원 팀에 서비스 요청을 생성 하여 자세히 알아보십시오.

9 단계. Avamar 그리드는 현재 또는 추가할 예상 데이터의 양에 비해 크기가 작습니다.

다른 모든 솔루션과 가능한 원인을 대용량으로 검토한 후 구성 문제나 우발적인 데이터 문제가 아닌 경우:

즉, 데이터를 삭제하거나 특정 클라이언트를 다른 Avamar 그리드로 마이그레이션하거나 새 데이터 노드를 추가하는 등의 옵션을 탐색해야 할 수 있습니다.

10 단계. 용량 이벤트를 확인하고 필요한 경우 백업 스케줄러를 재개합니다.

a. 용량 문제가 해결되면 Avamar Admin UI에서 모든 용량 관련 이벤트를 확인합니다.

b. 백업 스케줄러를 재개합니다.

dpnctl start sched

기타 Avamar 용량 관련 질문, 교육, 문제 해결 등은 다음을 참조하십시오. Avamar: 용량 문제 해결, 문제 및 질문 - 모든 용량(해결 경로)

• 이 작업은 그 자체로 실제 문제를 "은폐"하고 숨길 수 있으며, 며칠 또는 몇 주 후에 다시 나타나게 하여 이 수동 작업의 시간을 낭비하게 만듭니다.
• 또한 수동 GC는 일정이 부족하여 효율적으로 실행되지 않을 수 있습니다.
  • 때로는 다른 문제를 악화시킬 수 있습니다. 자세한 내용은 다음을 참조하십시오. Avamar: 수동 가비지 컬렉션의 사용에 대해

• 이 변경 또는 작업은 일반적으로 수행되지 않으며 기본적으로 고려해서는 안 됩니다. 이 변경은 Avamar L2 엔지니어 또는 SME(Subject Matter Expert)가 승인해야 합니다.
• 안타깝게도 이러한 작업은 다양한 방법으로 Avamar 그리드에 영구적인 손상을 일으킬 수 있습니다. 이러한 경우 스토리지 노드를 추가하거나 재구축해야만 해결할 수 있습니다.

지원 팀은 용량 문제를 해결하는 데 도움을 주고 싶기 때문에 위에 나열된 작업은 수행되지 않습니다.