Data Domain: DDR(Data Domain Restorer)의 높은 공간 활용도 또는 가용 용량 부족과 관련된 문제를 해결하는 방법

 

• 이 영역은 새로 수집한 파일/데이터가 상주하는 디스크 영역이며, 대부분의 DDR에서는 파일이 클라이언트 백업 애플리케이션에 의해 만료/삭제될 때까지 여기에 남아 있습니다.
• ER(Extended Retention) 또는 LTR(Long Term Retention)로 구성된 DDR에서는 오래된 파일을 활성 계층에서 아카이브 또는 클라우드 계층으로 마이그레이션하기 위해 데이터 이동 프로세스가 주기적으로 실행될 수 있습니다.
• 삭제/마이그레이션된 파일에서 사용한 활성 계층에서 공간을 재확보할 수 있는 유일한 방법은 GC(Garbage Collection)/정리 프로세스를 실행하는 것입니다.

• 활성 계층에 사용 가능한 공간이 부족해지기 시작하면 다음과 같은 알림/메시지가 표시될 수 있습니다.

• 활성 계층이 100% 찬 경우, DDR에 새 데이터를 쓸 수 없게 되어 백업/복제가 실패할 수 있습니다. 이 시나리오에서는 다음과 같은 알림/메시지가 표시될 수 있습니다.

• 경우에 따라 활성 계층이 가득 차면 DDFS(Data Domain File System)가 읽기 전용이 되고, 이때는 기존 파일을 삭제할 수 없습니다.

• 활성 계층이 가득 찰 수 있는 이유 설명
• 수행할 수 있는 간단한 점검 세트를 설명하여 활성 계층의 높은 활용도 원인 및 해당 개선 단계 파악

• 이 문서는 완벽하지는 않지만(즉, 이 문서에서 다루지 않은 이유로 인해 DDR의 활성 계층이 많이 활용된/꽉 찬 경우가 적을 수 있음) 가장 일반적인 원인/문제를 다루기 위한 것입니다.
• 이 문서에서는 아카이브 또는 클라우드 계층의 높은 활용도에 대해서는 다루지 않습니다.

  DDR의 활성 계층은 다음과 같은 여러 가지 이유로 인해 예상 활용도보다 높은 성능을 경험할 수 있습니다.

• 백업 파일/save set가 잘못된 보존 정책 또는 백업 애플리케이션 구성으로 인해 클라이언트 백업 애플리케이션에 의해 올바르게 만료/삭제되지 않음
• 복제 지연으로 인해 많은 양의 오래된 데이터가 복제본에 대한 복제를 보류 중인 활성 계층에 보관됨
• 활성 계층에 기록되는 데이터의 양이 예상되는 전체 압축률보다 적음
• 시스템의 크기가 올바르게 조정되지 않았음, 즉 저장하려고 하는 데이터 양에 비해 크기가 너무 작음
• 백업은 크기가 매우 작은 많은 파일로 구성됨 - 이러한 파일은 처음 쓸 때 예상보다 많은 공간을 사용하지만 정리/가비지 컬렉션 중에는 이 공간을 재확보해야 함
• ER/LTR로 구성된 시스템에서 데이터 이동이 정기적으로 실행되지 않으면 아카이브/클라우드 계층으로 마이그레이션해야 하는 오래된 파일이 활성 계층에 남아 있게 됨
• 정리/가비지 컬렉션이 정기적으로 실행되지 않음
• DDR에 너무 많거나 오래된 mtree 스냅샷이 있어 정리를 통해 삭제된 파일/데이터에서 공간을 재확보할 수 없음

1단계 - 활성 계층 정리를 실행해야 하는지 결정

DDOS(Data Domain Operating System)에서 활성 계층에 대해 'Cleanable GiB'라는 카운터를 유지하려고 합니다. 이는 정리/가비지 컬렉션을 실행하여 활성 계층에서 재확보할 수 있는 물리적 공간(post-comp)에 대한 추정입니다. 이 카운터는 'filesys show space'/'df' 명령으로 표시됩니다.
 
다음 중 한 가지 경우:

• 'Cleanable GiB’ 값이 큼
• DDFS가 100% 꽉 참(따라서 읽기 전용임)

이 문서의 추가 단계를 계속하기 전에 정리를 수행하고 완료를 실행할 수 있어야 합니다. 정리를 시작하려면 다음과 같이 'filesys clean start' 명령을 사용해야 합니다.
 
정리가 예상대로 시작되었는지 확인하려면 다음과 같이 'filesys status' 명령을 사용할 수 있습니다.
 
참고:

• 정리를 시작할 수 없는 경우, 계약한 지원 제공업체에 추가 지원을 요청하십시오. 이는 시스템에서 정리가 비활성화되는 'missing segment error'가 발생했음을 나타낼 수 있습니다.
• 정리가 이미 실행 중인 경우, 시작하려고 하면 다음 메시지가 표시됩니다.

• 활성 계층의 공간은 정리가 복사 단계에 도달할 때까지 확보/재확보되지 않습니다(기본적으로 DDOS 5.4.x 이하에서는 9단계, DDOS 5.5.x 이상에서는 11단계). 정리에서 사용하는 단계에 대한 자세한 내용은 다음을 참조하십시오. https://support.emc.com/kb/446734
• 이 값은 기본적으로 추정치이므로 정리는 'Cleanable GiB'로 표시된 공간을 재확보하지 못할 수 있습니다. 이에 대한 자세한 내용은 다음을 참조하십시오. https://support.emc.com/kb/485637
• 정리는 한 번의 실행으로 모든 잠재적 공간을 재확보하지 못할 수 있습니다. 이는 매우 큰 데이터 세트를 포함하는 DDR에서 가장 불필요한 데이터를 포함하는 파일 시스템 부분에 대해 정리가 실행되기 때문입니다(즉, 정리가 실행되는 데 걸리는 시간 동안 여유 공간에서 최상의 결과를 얻기 위해). 일부 시나리오에서는 모든 잠재적 공간이 재확보되기 전에 정리를 여러 번 실행해야 할 수 있습니다.
• 'Cleanable GiB' 값이 매우 큰 경우, 정리가 정기적으로 실행되지 않았음을 나타낼 수 있습니다. 정리 예약이 설정되어 있는지 확인합니다.

정리가 완료되면 'filesys show space'/'df' 명령을 사용하여 활용도 문제가 해결되었는지 확인합니다. 활용도가 여전히 높은 경우, 이 문서의 나머지 단계를 계속 진행합니다.

2단계 - 소스 복제 컨텍스트에 대해 많은 양의 복제 지연 확인

기본 Data Domain 복제는 '복제 컨텍스트'의 개념을 중심으로 설계되었습니다. 예를 들어, 시스템 간에 데이터를 복제해야 하는 경우

• 복제 컨텍스트가 소스 및 대상 DDR에서 생성됩니다.
• 컨텍스트가 초기화됩니다.
• 초기화가 완료되면 복제는 주기적으로 소스에서 대상으로 업데이트/DELTA를 보내 시스템의 데이터를 동기화된 상태로 유지합니다.

소스 복제 컨텍스트가 지연되는 경우, 오래된 데이터가 소스 시스템의 디스크에 보관될 수 있습니다(복제 컨텍스트가 지연되면 대상 시스템의 활용도가 과도해질 수 없음).

• 디렉토리 복제 컨텍스트(시스템 간 /data/col1/backup 아래의 단일 디렉토리 트리를 복제할 때 사용):

•  mtree 복제 컨텍스트(시스템 간 /data/col1/backup 이외의 mtree를 복제할 때 사용):

• 컬렉션 복제 컨텍스트(한 DDR의 전체 컨텐츠를 다른 시스템으로 복제할 때 사용):

 복제 컨텍스트가 지연되는지 확인하려면 다음 단계를 수행해야 합니다.

• 현재 시스템의 호스트 이름을 확인합니다.

• 현재 시스템의 날짜/시간을 확인합니다.

• 시스템에 구성된 복제 컨텍스트가 'synced as of time'과 함께 나열됩니다. 관심 컨텍스트는 'destination'에 현재 시스템의 호스트 이름이 포함되지 않고(현재 시스템이 소스임을 나타냄) 'synced as of time'이 상당히 오래된 컨텍스트입니다.

현재 시스템이 소스이고 더 이상 필요하지 않은 심각한 지연 또는 컨텍스트를 표시하는 컨텍스트는 제거해야 합니다. 이 작업은 소스 및 대상 시스템에서 다음 명령을 실행하여 수행할 수 있습니다.
 
예를 들어, 위에 표시된 '관심' 컨텍스트를 제거하려면 소스와 대상에서 다음 명령을 실행합니다.
 
참고:

• 컨텍스트를 제거한 후 성 계층 정리를 수행하여 활성 계층에서 잠재적 공간을 재확보해야 합니다.
• mtree 복제를 사용하는 경우, 컨텍스트가 제거되면 mtree 복제 스냅샷이 디스크에 남아 있을 수 있습니다. 정리를 실행하기 전에 5단계를 수행하여 불필요한 스냅샷이 만료되는지 확인합니다.
• 소스/대상 mtree가 아카이브 또는 클라우드 계층으로 데이터를 마이그레이션하도록 구성된 경우, 나중에 이러한 컨텍스트를 다시 생성/초기화할 수 없기 때문에 해당 mtree 복제 컨텍스트를 제거할 때 주의해야 합니다. 그 이유는 mtree 복제 컨텍스트가 초기화될 때 소스 시스템에서 mtree 스냅샷이 생성되고 계층에 관계없이 mtree의 모든 파일에 대한 세부 정보가 포함되기 때문입니다. 그런 다음 이 스냅샷이 대상의 활성 계층에 완전히 복제됩니다. 따라서 대상의 활성 계층에서 소스의 모든 mtree 데이터를 수집할 수 있는 충분한 여유 공간이 없는 경우, 초기화가 완료되지 않습니다. 이 문제에 대한 자세한 내용은 계약한 지원 공급업체에 문의하십시오.
• 컬렉션 복제 컨텍스트가 제거된 경우, 먼저 대상 DDR의 DDFS 인스턴스를 파괴(및 시스템의 모든 데이터를 손상)하지 않으면 컨텍스트를 다시 생성/초기화할 수 없습니다. 따라서 소스의 모든 데이터가 물리적으로 대상에 다시 복제되어야 하므로 후속 초기화에 상당한 시간/네트워크 대역폭이 필요할 수 있습니다.

3단계 - 더 이상 필요하지 않은 mtree 확인

DDFS의 내용이 논리적으로 mtree로 나뉩니다. 개별 백업 애플리케이션/클라이언트가 개별 mtree에 기록되는 것이 일반적입니다. 백업 애플리케이션의 압축을 풀면 DDR에 데이터 쓰기/DDR에서 데이터 삭제가 더 이상 가능하지 않아 시스템에 오래된/불필요한 mtree가 남아 있을 수 있습니다. 이러한 mtree의 데이터는 DDR의 디스크 공간을 사용하여 무기한으로 존재하게 됩니다. 따라서 이러한 불필요한 mtree는 삭제해야 합니다. 예:

• 시스템의 mtree 목록을 가져옵니다.

• 더 이상 필요하지 않은 mtree는 다음과 같이 'tree delete' 명령으로 삭제해야 합니다.

• 삭제된 mtree가 디스크에서 사용하는 공간은 다음에 활성 계층 정리/가비지 컬렉션이 실행될 때 재확보됩니다.

참고:

• mtree 복제 대상(예: mtree 목록 출력에서 RO/RD 상태)인 mtree에서는 mtree를 삭제하기 전에 해당 복제 컨텍스트를 제거해야 합니다.
• DDBoost LSU(Logical Storage Unit) VTL(Virtual Tape Library) 풀로 사용되는 mtree는 'mtree delete' 명령을 통해 삭제하지 못할 수 있습니다. 이러한 mtree 삭제에 대한 자세한 내용은 Data Domain 관리 가이드를 참조하십시오.
• 고정 잠금장치용으로 구성된(예: RLCE 또는 RLGE 상태) mtree는 삭제할 수 없습니다. 대신 mtree 내의 개별 파일은 고정 잠금장치를 되돌린 후 개별적으로 삭제해야 합니다. 자세한 내용은 Data Domain 관리 가이드를 참조하십시오.

4단계 - 오래된/불필요한 mtree 스냅샷 확인

Data Domain 스냅샷은 해당 mtree의 시점 스냅샷을 나타냅니다. 결과는 다음과 같습니다.

• 스냅샷 생성 시 mtree 내에 있는 모든 파일을 스냅샷에서 참조합니다.
• 스냅샷이 계속 존재하지만 이러한 파일이 제거/삭제되는 경우, 정리 작업을 수행하면 디스크에서 사용하는 물리적 공간을 재확보할 수 없습니다. 이는 나중에 스냅샷의 파일 사본에 액세스하는 경우 데이터가 시스템에 있어야 하기 때문입니다.

모든 mtree에 오래된/불필요한 스냅샷이 있는지 확인하려면 다음 단계를 수행해야 합니다.

• 3단계에 나와 있는 'mtree list' 명령을 사용하여 시스템의 mtree 목록을 가져옵니다.
• 'snapshot list' 명령을 사용하여 각 mtree에 존재하는 스냅샷을 나열합니다.

• 스냅샷이 있는 경우 'snapshot list mtree [mtree name]'에서 출력을 사용하여 다음 스냅샷을 확인합니다.

• snapshot list 명령을 다시 실행하는 경우, 이제 이러한 스냅샷이 expired로 표시됩니다.

참고:

• 디스크에 저장된 개별 스냅샷 또는 스냅샷 세트의 물리적 데이터 양을 확인할 수 없습니다. 스냅샷에 연결된 'space'에 대한 유일한 값은 스냅샷이 생성될 때 mtree의 사전 압축된(논리적) 크기를 나타냅니다(위 출력 참조).
• 이름이 'REPL-MTREE-AUTO-YYYY-MM-DD-HH-MM-SS'인 스냅샷은 mtree 복제에서 관리되므로 정상적인 상황에서는 수동으로 만료할 필요가 없습니다(이러한 스냅샷이 더 이상 필요하지 않을 경우 복제가 자동으로 이러한 스냅샷을 만료함). 이러한 스냅샷이 너무 오래된 경우, 해당 복제 컨텍스트는 상당한 지연을 보일 수 있습니다(2단계에서 설명됨).
• 이름이 'REPL-MTREE-RESYNC-RESERVE-YYYY-MM-DD-HH-MM-SS'인 스냅샷은 mtree 복제 컨텍스트가 제거될 때 mtree 복제에 의해 생성됩니다. 제거된 컨텍스트가 나중에 다시 생성될 경우(예: 컨텍스트가 오류로 인해 제거된 경우), 복제 데이터의 전체 재동기화를 방지하는 데 사용할 수 있습니다. 복제가 다시 설정되지 않을 경우, 위에서 설명한 대로 이러한 컨텍스트를 수동으로 만료할 수 있습니다.
• 만료된 스냅샷은 다음 정리/가비지 컬렉션이 실행될 때까지 시스템에 계속 존재합니다. 만료된 스냅샷은 이 시점에서 물리적으로 삭제되며 'snapshot list mtree [mtree name]'의 출력에서 제거됩니다. 그런 다음 정리 작업을 통해 디스크에서 이러한 스냅샷이 사용 중인 공간을 재확보할 수 있습니다.

5단계 - 시스템에 있는 예상치 못한 오래된 파일 수 확인

DDR의 자동 지원에는 오래된 DDR의 파일 분해를 보여 주는 히스토그램이 포함되어 있습니다. 예:
 
이 기능은 클라이언트 백업 애플리케이션에서 예상대로 만료/삭제되지 않은 파일이 시스템에 있는지 확인하는 데 유용합니다. 예를 들어, 한 파일의 최대 보존 기간이 6개월인 백업 애플리케이션에서 위의 시스템을 쓴 경우, 6개월 이상 된 파일이 DDR에 약 80,000개 있으므로 백업 애플리케이션이 예상대로 파일을 만료/삭제하지 않는 것이 바로 명백해집니다

참고:

• 모든 파일의 만료/삭제는 백업 애플리케이션에서 수행합니다.
• DDR은 자동으로 파일을 만료/삭제하지 않습니다. 백업 애플리케이션에서 명시적으로 파일을 삭제하라는 별도의 지시가 없는 한 공간을 무기한으로 사용하는 파일이 DDR에 계속 존재합니다.

따라서 이와 같은 문제는 먼저 백업 애플리케이션 공급업체 지원 팀에서 조사해야 합니다.

필요한 경우 Data Domain 지원에 다음과 같은 추가 보고서를 제공할 수 있습니다.

• DDR에 있는 모든 파일의 이름/수정 시간을 사용 기간에 따라 정렬하여 제공(따라서 오래된 데이터의 이름/위치 확인 가능)
• 파일 사용 기간에 대한 히스토그램을 활성/아카이브/클라우드 계층에 대한 별도의 보고서로 분할(ER/LTR 기능이 활성화된 경우)

이 작업을 수행하려면

• 이 문서의 참고 섹션에서 'Collecting sfs_dump' 단락에 설명된 대로 증거를 수집합니다.
• 계약한 지원 공급업체를 통해 서비스 요청을 개설합니다.

오래된/불필요한 파일이 삭제되면 활성 계층 정리/가비지 컬렉션을 실행하여 활성 계층의 공간을 물리적으로 재확보해야 합니다.

6단계 - 많은 수의 작은 파일이 포함된 백업 확인

작은 DDFS 파일(기본적으로 약 10MB 미만의 파일)의 설계로 인해 DDR에 처음 쓸 때 과도한 공간을 소비할 수 있습니다. 이는 'SISL'(Stream Informed Segment Layout) 아키텍처로 인해 작은 파일이 디스크에서 개별 4.5MB 블록 공간을 여러 개 소비하기 때문입니다. 예를 들어, 4KB 파일은 처음에 쓸 때 실제로 최대 9MB의 물리적 디스크 공간을 소비할 수 있습니다.

이러한 과도한 공간은 추후에 정리/가비지 컬렉션이 실행될 때 재확보되지만(작은 파일의 데이터가 더 적은 수의 4.5MB 블록으로 집계되기 때문) 더 작은 DDR 모델의 경우 그러한 백업이 실행될 때 과도한 활용도와 채우기가 나타날 수 있습니다.

자동 지원에는 크기별로 나뉜 파일의 히스토그램이 포함됩니다. 예:
 
매우 많은 수의 작은 파일을 쓰는 백업의 증거가 있는 경우, 정리/가비지 컬렉션을 호출할 때마다 일시적으로 사용률이 크게 증가하여 시스템이 영향을 받을 수 있습니다. 이 시나리오에서는 모든 작은 파일을 DDR에 쓰기 전에 하나의 큰 아카이브(예: tar 파일)에 포함하도록 백업 방법을 변경하는 것이 좋습니다. 이러한 아카이브를 압축하거나 암호화하면 안 됩니다(이 경우 해당 데이터의 압축률/중복 제거 비율이 손상되기 때문).

7단계 - 예상보다 낮은 데이터 중복 제거 비율 확인

DDR의 주요 목적은 디바이스에서 수집한 데이터를 중복 제거 및 압축하는 것입니다. 중복 제거/압축 비율은 시스템의 사용 사례와 보유한 데이터 유형에 따라 매우 달라지기는 하지만, 대부분의 경우 개념 증명 테스트 등을 통해 얻은 결과를 바탕으로 전체적인 압축률이 '예상'합니다. 시스템의 현재 전체 압축률(및 그에 따라 예상치에 부합하는지 여부)을 결정하기 위해 'filesys show compression' 명령을 사용할 수 있습니다. 예:
 
위의 예에서 시스템은 활성 계층에 대해 65.3x의 전체 압축률에 도달하게 됩니다(매우 좋음). 그러나 이 값이 전체 압축률이 기대치를 충족하지 않는 것을 나타내는 경우, 추가 조사가 필요할 수 있습니다. 예상보다 낮은 압축률을 조사하는 것은 근본 원인이 여러 가지일 수 있는 복잡한 주제입니다. 추가 조사에 대한 자세한 내용은 다음 문서 https://support.emc.com/kb/487055를 참조하십시오.

8단계 - 시스템이 컬렉션 복제의 소스인지 확인

컬렉션 복제를 사용할 때 소스 시스템이 실제로 대상보다 큰 경우, 소스 시스템의 크기는 대상의 크기와 일치하도록 인위적으로 제한됩니다(즉, 소스에 사용할 수 없음으로 표시되는 디스크 영역이 있을 수 있음). 그 이유는 컬렉션 복제를 사용할 때 대상이 소스의 블록 레벨 사본이어야 하지만, 소스가 실제로 대상보다 큰 경우, 대상에 복제될 수 없는 소스에 과도한 데이터가 기록될 가능성이 있기 때문입니다(이미 꽉 찼기 때문). 대상과 일치하도록 소스 크기를 제한하면 이 시나리오를 피할 수 있습니다.

• 2단계의 명령을 사용하여 시스템이 컬렉션 복제의 소스인지 확인합니다. 이렇게 하려면 'replication status'를 실행하고, 대상에 로컬 시스템의 호스트 이름이 포함되지 않은 (이 시스템이 복제 컨텍스트의 소스가 분명함을 나타내는) 'col://'(컬렉션 복제를 나타냄)로 시작하는 복제 컨텍스트가 있는지 확인합니다.
• 시스템이 컬렉션 복제를 위한 소스인 경우, 둘 다에 로그인하고 'filesys show space' 명령을 실행하여 각 시스템 활성 계층의 크기를 확인하고 활성 계층 'post-comp' 크기를 각각 비교합니다.
• 소스가 대상보다 훨씬 큰 경우, 활성 계층 크기는 인위적으로 제한됩니다.
• 소스의 모든 공간을 데이터에 사용할 수 있도록 하려면 다음을 수행해야 합니다.

9단계 - 데이터 이동이 정기적으로 실행되는지 확인

DDR이 ER(Extended Retention) 또는 LTR(Long Term Retention)로 구성된 경우, DDR에 두 번째 스토리지 계층(ER의 경우 아카이브 계층, LTR의 경우 클라우드 계층)이 연결됩니다. 이 시나리오에서는 활성 계층에서 이러한 파일이 사용하는 공간을 정리/가비지 컬렉션을 통해 물리적으로 재확보할 수 있도록 mtree에 대해 데이터 이동 정책을 구성하여 활성 계층에서 대체 스토리지 계층으로 장기간 보존해야 하는 오래된/수정되지 않은 데이터를 마이그레이션할 수 있습니다. 데이터 이동 정책이 잘못 구성되었거나 데이터 이동 프로세스가 정기적으로 실행되지 않는 경우, 오래된 데이터는 예상보다 오래 활성 계층에 남아 디스크의 물리적 공간을 계속 사용하게 됩니다.

• 처음에 'filesys show space'를 실행하고 아카이브 또는 클라우드 계층이 있는지 확인하여 시스템이 ER 또는 LTR에 대해 구성되었는지 확인합니다. 이러한 대체 스토리지 계층을 사용할 수 있으려면 post-comp 크기가 0GB를 초과해야 합니다.

• 시스템이 ER/LTR로 구성된 경우, mtree에 대한 데이터 이동 정책을 확인하여 이러한 정책이 예상과 일치하는지 확인하고 오래된 데이터가 대체 스토리지 계층으로 푸시되도록 설정합니다.

• 시스템이 ER/LTR로 구성된 경우, 활성 계층에서 대체 스토리지로 파일/데이터를 물리적으로 마이그레이션하기 위해 정기적으로 데이터 이동이 실행되도록 예약되었는지 확인합니다.

• 시스템이 ER/LTR용으로 구성된 경우, 데이터 이동이 마지막으로 실행된 시간을 확인합니다.

• 데이터 이동이 완료되면 활성 계층 정리를 실행하여(데이터 이동 완료 시 자동으로 시작되도록 구성할 수 있음) 활성 계층에서 마이그레이션된 파일에 사용된 공간이 물리적으로 확보되었는지 확인합니다.

10단계 - 활성 계층에 스토리지 추가

이전 단계를 모두 수행한 경우, 활성 계층 정리가 실행되어 완료되지만 활성 계층에 여전히 사용 가능한 공간이 충분하지 않아 시스템 크기가 수신 중인 워크로드에 대해 올바르게 조정되지 않았을 수 있습니다. 이 경우 다음 중 하나를 수행해야 합니다.

• 시스템에 가해지는 워크로드를 줄입니다. 예:

• 시스템의 활성 계층에 스토리지를 추가하고 크기를 확장합니다.

Data Domain 지원은 다음과 같은 정보를 보여 주는 여러 보고서를 생성할 수 있습니다.

• 사용 기간에 따라 정렬되는 특정 계층(예: 액티브/아카이브/클라우드)에 있는 모든 파일의 목록
• mtree/major 디렉토리 트리별 예상 크기 및 압축률
• 사용 기간에 따라 정렬되는 특정 mtree에 있는 모든 파일의 목록
• 등

이를 허용하려면 다음 정보를 수집해야 합니다.

• DDR의 새로운 지원 번들 - 자세한 내용은 https://support.emc.com/kb/323283을 참조하십시오.
• 'sfs_dump' 또는 'sfs_dump -c'의 출력:

• 파일 위치 보고서(시스템이 ER 또는 LTR용으로 구성된 경우 필요):

위의 사항을 수집하거나 이 아카이브 정리 단계에 대한 지원이 필요 경우, 계약한 지원 공급업체에 문의하십시오.