Symptoms
Einige Backupjobs schlagen auf dem Backupclient mit Meldungen wie den folgenden fehl:
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.
Im "schreibgeschützten" Modus für Backups und Images ruft diese bestimmte Backupsoftware die DD-Back-end-Funktion auf, die es einem Administrator ermöglicht, einen Zeitraum festzulegen, in dem die Datei im Back-end zum Schutz vor versehentlicher oder böswilliger Datenlöschung nicht geändert oder gelöscht werden darf. Diese Funktion wird als Data Domain Retention Lock (kurz RL) bezeichnet.
Auf der DD-Seite zeigen Protokolle Folgendes für dieselbe Speichereinheit, dasselbe Unterverzeichnis und die gleiche Backupdatei an:
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-<backupsoftware.example.com-56892>: 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
Die DD-RL-Konfiguration für jeden einzelnen MTree, für den die Funktion aktiviert ist, umfasst die Festlegung der minimalen Dauer (Retention-Lock Min-Retention-Period) und der maximalen Dauer (Retention-lock max-retention-period) von Sperren, die für eine der Dateien im MTree festgelegt werden dürfen. Bei DD RL muss die Backupanwendung die Sperre für Dateien einzeln festlegen, es sei denn, die Funktion DD Automatic Retention Lock (ARL) ist aktiviert. Die Optionen für den MTree im Beispiel waren wie folgt:
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
----------------------------------------- -----------
Das bedeutet, dass für jede Datei im MTree die RL nur 720 Minuten ab der aktuellen Zeit (oder länger) und 35 Tage ab der aktuellen Zeit (oder kürzer) festgelegt werden kann. Mit anderen Worten: Mit der obigen Konfiguration kann eine Datei nur für einen Zeitraum von mehr als 12 Stunden, aber weniger als 35 Tagen vor Änderungen oder Entfernung geschützt werden. Jeder Versuch der Backupanwendung, eine Sperre für eine kürzere oder längere Dauer festzulegen (durch Aktualisieren der Datei bei Verwendung von BOOST; über den "ddp_utime"-Aufruf), führt zu dem oben dargestellten Fehler:
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.
Wenn die Backupanwendung weiß, wie die DD-RL-Funktion verwendet wird, wartet sie, bis das Backup das Schreiben auf das Image im Back-end abgeschlossen hat, und legt schließlich die Sperre für das Backup-Image fest (oder die Images, da einige Software möglicherweise mehr als eine Datei verwendet, um einen einzigen Backupjob zu speichern). Die BOOST-Bibliotheken werden verwendet, um den "ddp_utime" aufzurufen, um die Sperre für eine Dauer festzulegen, die der beabsichtigten Backupaufbewahrung auf Backupanwendungsebene entspricht. Dies hat zwei Auswirkungen:
- Wenn die Zeit zwischen der Backupanwendung und der DD nicht synchronisiert ist, kann die Backupanwendung "X Tage ab jetzt" berechnen und ein Datum und eine Uhrzeit erhalten, die nicht genau mit dem für DD identisch sind. Dies würde dazu führen, dass das Backup-Image je nach Zeichen des Zeitunterschieds für einen kürzeren oder längeren Zeitraum gesperrt wird.
- Wenn die vorgesehene Backupaufbewahrung nicht an den RL-Limits auf dem DD-MTree ausgerichtet ist, versucht die Backupanwendung möglicherweise, eine Sperre in Zukunft zu weit festzulegen (für einen Längeren Zeitraum als "Retention-lock max-retention-period"). Daher wird die Einstellung der Sperre verweigert. Wenn z. B. die Aufbewahrung der Backupanwendung 60 Tage beträgt und in DD die Option "Retention-lock max-retention-period" auf 30 Tage festgelegt ist, schlägt die Einstellung der Sperre offensichtlich fehl.
In Situationen, in denen die Aufbewahrung der Backupsoftware der "Retention-lock max-retention-period" auf der DD entspricht, können geringfügige Zeitunterschiede dazu führen, dass die Sperreinstellung aufgrund der Zeitdifferenz zwischen den beiden Hosts verweigert wird.
Resolution
Es ist wichtig, dass alle Hosts in der Backupinfrastruktur die richtige Zeit haben und daher über NTP oder (falls zutreffend) Windows AD synchronisiert werden.
Um Eckfälle wie den beschriebenen zu vermeiden, ist es eine gute Vorgehensweise, dass die "Retention-lock max-retention-period" im RL-fähigen MTree etwas länger als die am längsten aufbewahrte Backup-Policy in diesem MTree eingestellt ist. Wenn beispielsweise die Datenaufbewahrung in der Backupanwendung auf 35 Tage festgelegt ist, ist die Einstellung "Retention-lock max-retention-period" auf dem DD-MTree, der zum Speichern dieser Policies verwendet wird, auf 36 oder sogar 40 Tage die richtige Vorgehensweise, um versehentliche Fehler beim Festlegen von RL zu vermeiden.
Beachten Sie, dass eine "Aufbewahrungssperre max-retention-period" höher als die Aufbewahrungsfrist für Backup-Images ist kein Problem. Wenn wir 100 Tage "Retention-lock max-retention-period" für eine 35-Tage-Aufbewahrungsbackup-Policy hatten, werden die Images nach 35 Tagen von der Anwendung gelöscht und bei der nächsten Ausführung wird der verwendete Speicherplatz gelöscht. Der einzige Nachteil besteht darin, dass Sie Bilder versehentlich mit einer längeren Sperre festlegen und die RL-Compliance die Dateien nicht länger als erwartet löschen kann. Daher wird empfohlen, "Retention-lock max-retention-period" etwas länger, aber nicht zu viel festzulegen.
Affected Products
Data Domain