Symptoms
백업 클라이언트에서 다음과 같은 메시지가 표시되면서 일부 백업 작업이 실패합니다.
8212 6df7 12/05 15:47:15 871396 [MEDIAFS ] 3637866-3138214 Cannot set the access time of [/data/col1/Commvault/SUBDIR/CV_MAGNETIC/V_305788/CHUNK_18517307], error=0xECCC000D:{CQiFile::SetTimes(825)/ErrNo.13.(Permission denied)}
8212 6df7 12/05 15:47:15 871396 [MEDIAFS ] 3637866-3138214 Cannot mark the file [/data/col1/Commvault/SUBDIR/CV_MAGNETIC/V_305788/CHUNK_18517307] as read only.
백업 및 이미지에 대한 "읽기 전용" 모드는 이 특정 백업 소프트웨어가 DD 백엔드 기능을 호출하여 관리자가 우발적이거나 악의적인 데이터 삭제에 대한 보호를 위해 백엔드의 파일을 수정하거나 삭제할 수 없는 기간을 설정할 수 있는 방법입니다. 이 기능을 Data Domain Retention Lock(짧은 RL)이라고 합니다.
DD 측에서 로그에 동일한 스토리지 유닛, 하위 디렉토리 및 백업 파일에 대한 다음이 표시됩니다.
12/05 07:47:47.820284 [7f1bc842a000] Attempt to set atime of 16adcf:0:16addb:0:7d70db86:6256fe81:0 to larger than maximum retention period of mtree.
12/05 07:47:47.820289 [7f1bc842a000] ERROR: FM fm_dm1_setattr:1408 - fm_dm1_setattr_intern failed
12/05 07:47:47.820533 [7f1bcdf19d90] ddboost-: ddboost_api ERROR: ddp_utime() failed, su_name=Commvault, path_name=/SUBDIR/CV_MAGNETIC/V_305788/CHUNK_18517307, Err: 5034-nfs setattr failed (nfs: Permission denied)
Cause
기능이 활성화된 각 개별 MTree에 대한 DD RL 구성에는 MTree의 파일에 대해 설정할 수 있는 최소(Retention-lock min-retention-period) 및 최대(Retention-lock max-retention-period) 잠금 기간을 설정하는 것이 포함됩니다. DD RL을 사용하면 DD ARL(Automatic Retention Lock) 기능이 활성화되지 않는 한 백업 애플리케이션이 파일에 대한 잠금을 개별적으로 설정해야 합니다. 이 예의 MTree 옵션은 다음과 같습니다.
Mtree: /data/col1/Commvault
Option Value
----------------------------------------- -----------
Retention-lock enabled
Retention-lock mode governance
Retention-lock uuid UUID1:UUID2
Retention-lock min-retention-period 720minutes
Retention-lock max-retention-period 35days
Retention-lock automatic-retention-period not set
Retention-lock automatic-lock-delay 120minutes
Retention-lock indefinite-retention-hold disabled
----------------------------------------- -----------
즉, MTree의 모든 파일에 대해 RL은 현재 시간(또는 그 이상)에서 720분, 현재 시간(또는 더 짧은 시간)에서 35일만 설정할 수 있습니다. 즉, 위의 구성을 사용하면 파일이 12시간 이상이지만 35일 미만의 기간 동안만 수정 또는 제거되지 않도록 보호할 수 있습니다. 백업 애플리케이션이 잠금을 설정하려고 하면(BOOST를 사용할 때 파일의 atime을 업데이트하고 "ddp_utime" 호출을 통해 수행)을 더 짧거나 긴 기간 동안 설정하려고 하면 위에 오류가 표시됩니다.
12/05 07:47:47.820284 [7f1bc842a000] Attempt to set atime of 16adcf:0:16addb:0:7d70db86:6256fe81:0 to larger than maximum retention period of mtree.
백업 애플리케이션이 DD RL 기능을 사용하는 방법을 알고 있는 경우 백업이 백엔드의 이미지에 쓰기를 완료할 때까지 기다린 다음 결국 백업 이미지에 잠금을 설정합니다(또는 일부 소프트웨어는 단일 백업 작업을 저장하기 위해 두 개 이상의 파일을 사용할 수 있음). BOOST 라이브러리는 "ddp_utime"를 호출하여 백업 애플리케이션 레벨에서 의도한 백업 보존 기간과 동일한 기간 동안 잠금을 설정하는 데 사용됩니다. 여기에는 두 가지 영향이 있습니다.
- 백업 애플리케이션과 DD 간에 시간이 동기화되지 않은 경우 백업 애플리케이션은 "X days from now"를 계산하고 DD의 날짜와 정확히 동일하지 않은 시간을 얻을 수 있으며, 이로 인해 시간 차이의 표시에 따라 백업 이미지가 더 짧거나 더 긴 기간 동안 잠깁니다.
- 의도된 백업 보존이 DD MTree의 RL 제한과 일치하지 않으면 백업 애플리케이션이 나중에 너무 멀리("Retention-lock max-retention-period"보다 긴 기간 동안) 잠금을 설정하려고 시도할 수 있으므로 잠금 설정이 거부될 수 있습니다. 예를 들어 백업 애플리케이션 보존 기간이 60일이고 DD에서 "Retention-lock max-retention-period"가 30일로 설정된 경우 잠금 설정이 실패합니다.
백업 소프트웨어 보존이 DD의 "Retention-lock max-retention-period"에 해당하는 경우 두 호스트 간의 시간 차이로 인해 약간의 시간 차이로 인해 잠금 설정이 거부될 수 있습니다.
Resolution
백업 인프라스트럭처의 모든 호스트가 올바른 시간을 가지므로 NTP 또는(해당하는 경우) Windows AD를 통해 동기화해야 합니다.
설명한 것과 같은 모서리 케이스를 방지하기 위해 RL 지원 MTree의 "Retention-lock max-retention-period"가 해당 MTree에 저장된 가장 긴 보존 백업 정책보다 약간 더 길도록 설정하는 것이 좋습니다. 예를 들어 백업 애플리케이션에서 데이터 보존이 35일로 설정된 경우 이러한 정책을 저장하는 데 사용되는 DD MTree에서 "Retention-lock max-retention-period"를 36일 또는 40일로 설정하는 것이 실수로 RL을 설정하지 못하는 것을 방지하는 것이 옳은 일입니다.
백업 이미지 보존 기간보다 "Retention-lock max-retention-period"가 더 높은 것은 문제가 되지 않습니다. 35일 보존 백업 정책에 대해 100일 "Retention-lock max-retention-period"가 있는 경우 35일 후에 애플리케이션에서 이미지를 삭제하고 다음에 실행될 때 사용된 공간을 정리합니다. RL 규정 준수를 통해 실수로 더 긴 잠금 상태로 이미지를 설정하는 경우 예상보다 오래 파일을 삭제할 수 없다는 단점만 있습니다. 따라서 "Retention-lock max-retention-period"를 조금 더 길게 설정하는 것이 좋습니다.
Affected Products
Data Domain