Data Domain: Bei einer in Retention Lock integrierten Backupanwendung kann es aufgrund von Konfigurationsproblemen zu Backupfehlern kommen

Einige Backupjobs schlagen auf dem Backupclient mit Meldungen wie der 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 wird von dieser speziellen Backupsoftware die DD-Backend-Funktion bezeichnet, mit der ein Administrator zum Schutz vor versehentlichem oder böswilligem Löschen von Daten einen Zeitraum festlegen kann, in dem die Datei im Backend 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 dieselbe 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)

Die DD RL-Konfiguration für jeden einzelnen MTree, für den diese Funktion aktiviert ist, umfasst das Festlegen der minimalen (Retention-lock min-retention-period) und maximalen (Retention-lock max-retention-period) Dauer der Sperre, die für jede der Dateien im MTree festgelegt werden dürfen. Mit DD RL muss die Backupanwendung die Sperre für Dateien einzeln festlegen, es sei denn, die ARL-Funktion (Automatic Retention Lock, DD-Aufbewahrungssperre) ist aktiviert. Die Optionen für den MTree in diesem 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 Entfernungen geschützt werden. Jeder Versuch der Backup-Anwendung, eine Sperre für eine kürzere oder längere Dauer zu setzen (dies geschieht durch Aktualisieren der atime der Datei bei Verwendung von BOOST; durch den Aufruf "ddp_utime") 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 die DD RL-Funktion verwenden kann, wartet sie, bis das Backup das Schreiben in das Image im Backend abgeschlossen hat, und sperrt schließlich das Backup-Image (oder die Images, da einige Software möglicherweise mehr als eine Datei verwendet, um einen einzelnen Backupjob zu speichern). Die BOOST-Bibliotheken werden verwendet, um die "ddp_utime" aufzurufen, um die Sperre für eine Dauer festzulegen, die der beabsichtigten Backupaufbewahrung auf Backupanwendungsebene entspricht. Dies hat zwei Implikationen:

• Wenn die Zeit zwischen der Backupanwendung und der DD nicht synchronisiert ist, berechnet die Backupanwendung möglicherweise "X Tage von heute" und erhält ein Datum und eine Uhrzeit, die nicht genau mit denen für die DD identisch sind, was dazu führen würde, dass das Backup-Image je nach Vorzeichen des Zeitunterschieds für einen kürzeren oder längeren Zeitraum gesperrt wird
• Wenn die beabsichtigte Backupaufbewahrung nicht an den RL-Limits für den DD-MTree ausgerichtet ist, versucht die Backupanwendung möglicherweise, eine Sperre zu weit in der Zukunft festzulegen (für einen Zeitraum, der länger als "Retention-lock max-retention-period") ist, und daher wird die Festlegung der Sperre verweigert. Wenn beispielsweise die Aufbewahrung der Backupanwendung 60 Tage beträgt und in der DD die Option "Retention-lock max-retention-period" auf 30 Tage festgelegt ist, schlägt das Festlegen der Sperre offensichtlich fehl

In Situationen, in denen die Aufbewahrung der Backupsoftware der "Retention-lock max-retention-period" auf dem DD entspricht, können geringfügige Zeitunterschiede dazu führen, dass die Sperreinstellung aufgrund des Zeitunterschieds zwischen den beiden Hosts abgelehnt wird.

Es ist wichtig, dass alle Hosts in der Backupinfrastruktur über die richtige Zeit verfügen und daher über NTP oder (falls zutreffend) Windows AD synchronisiert werden.

Um Ausnahmefälle wie den beschriebenen zu vermeiden, empfiehlt es sich, für "Retention-lock max-retention-period" im RL-fähigen MTree einen etwas längeren Wert festzulegen als die Backup-Policy mit der längsten Aufbewahrungsfrist, die in diesem MTree gespeichert ist. Wenn beispielsweise die Datenaufbewahrung in der Backupanwendung auf 35 Tage festgelegt ist, ist es richtig, den Wert für "Retention-lock max-retention-period" im DD-MTree, in dem diese Policies gespeichert werden, auf 36 oder sogar 40 Tage festzulegen, um versehentliche Fehler beim Festlegen von RL zu vermeiden.

Beachten Sie, dass eine "Retention-lock max-retention-period" höher ist als die Aufbewahrungsfrist für Backup-Images, ist kein Problem. Wenn wir 100 Tage "Retention-lock max-retention-period" für eine 35-tägige Aufbewahrungsbackup-Policy hatten, werden die Images nach 35 Tagen von der Anwendung gelöscht und die Bereinigung wird ihren verwendeten Speicherplatz bei der nächsten Ausführung löschen. Der einzige Nachteil besteht darin, dass Sie versehentlich Bilder mit einer längeren Sperre festlegen, mit RL-Compliance können Sie die Dateien nicht länger als erwartet löschen. Daher wird empfohlen, "Retention-lock max-retention-period" etwas länger einzustellen, aber nicht zu viel.