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

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

매우 일반적으로 GSAN 용량을 클라이언트 백업의 공간 및 활용도로 고려할 수 있습니다.

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

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

  • 클라이언트 백업 작업이 실패하고 다음과 유사한 메시지가 표시될 수 있습니다.  "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: 용량 문제를 해결하기 위해 정보를 수집하는 방법

최소한 Avamar 관리 UI 내의 status.dpn 명령이나 값이 GSAN 용량을 표시합니다.

3단계 OS 용량이 가득 찼는지 확인:

다음 명령을 실행하면 각 디스크 파티션에 대한 OS 용량의 현재 값을 보여 줍니다. 두 번째 샘플 출력에서와 같이 값이 85%에 도달하거나 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 관리 UI에서도 확인할 수 있습니다.

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

만일 GSAN 용량이 높고 다른 용량도 높은 경우 문제 해결은 OS 용량을 항상 먼저 처리해야 한다는 점을 제외하면 순서에 상관없이 진행할 수 있습니다.

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

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

스트라이프는 그리드 내의 서로 다른 디스크와 노드에 걸쳐 "균형" 있게 또는 균등하게 분산될 것으로 예상되지만 때로는 균형이 맞지 않을 수 있습니다.

Avamar의 설계상 최대 노드 또는 디스크 파티션은 Avamar 용량의 제한 요소입니다.

이는 어떤 디스크나 노드도 처리할 수 있거나 허용된 수준을 초과해 스트라이프를 생성하지 않도록 하기 위한 의도적인 설계입니다. 따라서 스트라이프가 균형 있게 분산되는 것은 용량 관리에 매우 중요합니다.

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

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

동일한 데이터 노드에서 한 파티션이 동일한 노드의 다른 파티션보다 훨씬 크거나 작은 경우 "freespaceunbalance"로 불리는 제한을 초과할 수 있습니다. 이 문제는 일반적으로 GSAN 용량이 아니라 OS와 관련되어 있지만, 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 값을 기록합니다. 이 예에서 값은 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이 아니라고 가정하고 maxtime의 2/3를 계산한 후 경과 시간과 비교합니다.
(위의 예에서 14400의 2/3은 9600이며, 모든 경과 시간 출력은 이 수치보다 훨씬 낮음)

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

만일 maxtime또는 패스 개수에 대한 우려 사항이 있는 경우, Dell Technologies Avamar 지원 팀과 함께 서비스 요청을 생성하여 추가 조사를 수행합니다.

8단계 GC가 충분한 데이터를 제거하지 않았거나 예상했던 데이터를 제거하지 않았다고 의심할 경우

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

a. 백업이 최종적으로 또는 정기적으로 만료되도록 구성되어 있는지 확인합니다. 만료되는 백업이 자주 발생하지 않는 경우, GC가 수행할 작업은 많지 않습니다.

b. 이 문서를 사용하여 "상위 변경률" 클라이언트를 찾습니다. Avamar: capacity.sh 스크립트를 사용하여 용량을 관리하는 방법 ("% OF TOTAL" 및 "CHGRATE" 모두 검토)

c. 다음과 같은 건너뛴 해시를 확인합니다. Avamar: Avamar 가비지 컬렉션에서 정리할 수 없는 "skipped-hashes"를 보고합니다. 이러한 현상이 발생하더라도 빈도가 낮다면 정상적인 것으로 간주할 수 있으며, 해당 단계는 건너뛸 수 있습니다.

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

e. 최근 백업이 GSAN 에서 DD 백엔드로 전환되었거나 실수로 GSAN 백업이 수행되었음에도 불구하고 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 그리드에 영구적인 손상을 초래할 수 있으며, 이를 해결하기 위해서는 스토리지 노드를 추가하거나 재배포해야 하는 경우가 많습니다.

지원 팀이 가장 유리한 방법으로 용량 문제를 해결하기를 원하기 때문에 위에 나열된 작업 중 어느 것도 수행되지 않는다는 점을 이해하십시오.