Data Domain: Retention Lock – Häufig gestellte Fragen

• Governance: Die weniger strenge der beiden Retention-Lock-Funktionen (d. h., Dateisperren können bei Bedarf aufgehoben werden).
• Compliance: Die strengere der beiden Funktionen, die mehrere übliche gesetzliche Vorschriften erfüllt. Bei dieser Funktion können Dateisperren nicht aufgehoben werden. Der DDR muss mit einem „Security Officer“-Nutzer konfiguriert werden, der bestimmte Befehle authentifizieren muss. Es gibt verschiedene Einschränkungen bei anderen Funktionen, um zu verhindern, dass gesperrte Daten entfernt oder Sperren frühzeitig zurückgesetzt werden.

• Die Protokolle NFS, CIFS und DDBoost werden im Governance- oder Compliancemodus von Retention Lock vollständig für MTrees unterstützt.
• Das VTL-Protokoll (Virtual Tape Library) wird nur für MTrees mit dem Governance-Modus von Retention Lock unterstützt. Automatisches Retention Lock wird auf Data Domain VTL nicht unterstützt. Im Data Domain-Administrationshandbuch finden Sie Informationen zum Entsperren von Bändern des Retention Lock, damit auf diese wieder geschrieben werden kann.

• SEC 17a-4(f)
• CFTC Regel 1.31b
• FDA 21 CFR Teil 11
• Sarbanes-Oxley Act
• IRS 98025 und 97-22
• ISO Standard 15489-1
• MoREQ2010

• Eine Retention Lock Governance-Lizenz wird dem DDR hinzugefügt.
• Der Governance-Modus von Retention Lock ist für jeden erforderlichen MTree aktiviert:     

# mtree retention-lock enable mode governance mtree [mtree]

• Beachten Sie, dass es spezifische Weisungen für einige neuere Data Domain-Modelle mit iDRAC gibt.
• Eine Retention Lock Compliance-Lizenz wird dem DDR hinzugefügt.
• Ein Nutzerkonto mit der Rolle „Security“ muss erstellt werden (sofern ein solches Konto nicht vorhanden ist):     

(ADMIN USER) # user add [username] role security

•  Über das Nutzerkonto mit der Rolle „Security“ melden Sie sich beim DDR an und aktivieren die Sicherheitsnutzerautorisierungen:     

(SECURITY USER): # authorization policy set security-officer enabled

• Das System wird für den Compliance-Modus von Retention Lock konfiguriert werden. Sobald der folgende Befehl ausgeführt wird, wird das System automatisch neu gestartet:     

(ADMIN USER) # system retention-lock compliance configure

• Sobald das System neu gestartet wurde, wird der Compliance-Modus von Retention Lock auf dem System aktiviert:     

(ADMIN USER) # system retention-lock compliance enable

• Der Compliance-Modus von Retention Lock ist für jeden erforderlichen MTree aktiviert:

(ADMIN USER) # mtree retention-lock enable mode compliance mtree [mtree]

Wie kann festgestellt werden, für welche MTrees Retention Lock aktiviert ist?
MTrees mit aktiviertem Retention Lock werden in der Ausgabe von mtree list angezeigt. Beispiel:     

sysadmin@ddxxxx# mtree list
Name                                Pre-Comp (GiB)   Status    Tenant-Unit
---------------------------------   --------------   -------   -----------
...
/data/col1/rich-retention-lock                 0.0   RW/RLGE   -
/data/col1/rl_test                             0.0   RW/RLGD   -
/data/col1/rl_test_comp                        0.0   RW/RLCE   -
/data/col1/test                                3.1   RW/RLGE   -
...
---------------------------------   --------------   -------   -----------
...
 RLGE : Retention-Lock Governance Enabled
 RLGD : Retention-Lock Governance Disabled
 RLCE : Retention-Lock Compliance Enabled

Kann ein MTree mit aktivierter Retention Lock Governance in Retention Lock Compliance konvertiert werden?
Wie im DDOS-Administrationshandbuch angegeben, ist dies nicht möglich.

Kann ein MTree mit aktivierter Retention Lock Compliance in Retention Lock Governance konvertiert werden?
Wie im DDOS-Administrationshandbuch angegeben, ist dies nicht möglich.

Wie werden Dateiaufbewahrungs- oder Sperrfristen festgelegt?
Sobald Retention Lock für einen MTree aktiviert ist, muss eine minimale und maximale Aufbewahrungsfrist festgelegt werden. Diese Zeiträume geben die minimale und maximale Zeit vor, für die eine Datei im MTree gesperrt werden kann. Zum Beispiel:     

# mtree retention-lock set min-retention-period [period] mtree [mtree]
# mtree retention-lock set max-retention-period [period] mtree [mtree]

Zeiträume können in verschiedenen Einheiten wie folgt angegeben werden:     

• 1 Min.
• 1 Std.
• 1 Tag
• 1 Monat
• 1 Jahr

Wie können bestehende Aufbewahrungsfristen angezeigt werden?
Dies kann mithilfe der folgenden beiden Befehle erfolgen:     

# mtree retention-lock show min-retention-period mtree [mtree]
# mtree retention-lock show max-retention-period mtree [mtree]

Zum Beispiel:     

sysadmin@dd630# mtree retention-lock show min-retention-period mtree /data/col1/rl_test
Retention-lock min-retention-period of mtree /data/col1/rl_test is: 720 minutes.
sysadmin@dd630# mtree retention-lock show max-retention-period mtree /data/col1/rl_test
Retention-lock max-retention-period of mtree /data/col1/rl_test is: 30 days.

Wie werden Dateien in einem MTree mit aktiviertem Retention Lock gesperrt?

• Wenn Retention Lock für einen MTree aktiviert ist, werden vorhandene Dateien innerhalb des MTree nicht automatisch gesperrt (d. h., alle bereits vorhandenen Dateien behalten Lese- oder Schreibrechte).
• Wenn eine neue Datei in einen MTree mit aktivierter Aufbewahrungssperre geschrieben wird, wird die Datei nicht automatisch gesperrt. Das heißt, die neue Datei behält Lese- oder Schreibrechte.

• Um eine bestimmte Datei zu sperren, muss die atime der Datei so geändert werden, dass sie dem Datum und der Uhrzeit entspricht, bis zu der die Datei aufbewahrt werden soll. Das heißt, Datum und Uhrzeit, bis zu der die Datei schreibgeschützt bleiben soll. Bis die Zeit entsprechend geändert wurde, kann die Datei nicht mit Retention Lock gesperrt werden (sie kann weiterhin geändert oder entfernt werden).

Die atime einer Datei kann mithilfe des Befehls „touch“ von einem NFS- oder CIFS-Client geändert werden:

# touch -a -t [expiry time] [file to be locked]

Um beispielsweise die atime von /data/col1/rl_test/testfile auf 7:05 Uhr am 8. Juni festzulegen: 

# touch -a -t 06080705 /data/col1/rl_test/testfile

Der Zeitraum von der aktuellen bis zur zukünftigen atime muss innerhalb der minimalen und maximalen Aufbewahrungsfristen für den MTree liegen. Andernfalls wird ein Fehler erzeugt, wenn die atime der Dateien geändert wird: 

# touch -a -t 08080705 /data/col1/rl_test/testfile
touch: setting times of `/data/col1/rl_test/testfile': Permission denied

Eine entsprechende Meldung wird auch in den DDFS-Protokolldateien (Data Domain File System) angezeigt:     

06/07 13:44:57.197 (tid 0x2b28ee5258c0): Attempt to set atime of /data/col1/rl_test/testfile to larger than maximum retention period of mtree.

CIFS-Clients (Windows) enthalten standardmäßig nicht den Befehl „touch“ oder ein Dienstprogramm, jedoch stehen mehrere solcher Dienstprogramme kostenlos zum Herunterladen von verschiedenen Websites von Drittanbietern zur Verfügung.

Welche Backupanwendungen unterstützen das automatische Retention Lock von Dateien nach dem Schreiben auf einen DDR?
Data Domain Retention Lock ist mit NAS-basierten WORM-Protokollen (Write-Once-Read-Many) nach Branchenstandard kompatibel. Die Integration ist mit Archivanwendungen wie Symantec Enterprise Vault, SourceOne, Cloud Tiering Appliance oder DiskXtender möglich.

Für Dell NetWorker werden sowohl der Governance- als auch der Compliance-Modus unterstützt.

Die im Juni 2024 aktuellen Versionen von Avamar unterstützen Compliance mit Data Domain Retention Lock und Governance als Teil der Avamar-Funktion „Immutable Backups“. Weitere Informationen finden Sie im folgenden Artikel und in der Avamar-Dokumentation:
Avamar und Data Domain: Aktivieren von Avamar Immutable Backups und Data Domain Compliance Mode Retention Lock

Es ist wichtig, dass die Schritte zum Aktivieren der Avamar-Funktion „Immutable Backups“ strikt befolgt werden. Andernfalls kann es passieren, dass ein Avamar-MTree in der DD vorhanden ist, in den nicht weiter geschrieben werden kann oder der Betriebsprobleme aufweist, die eine langwierige Recovery erzwingen. Avamar funktioniert nicht mit DD Automatic Retention Lock (ARL) und ARL darf für keinen Avamar-MTree auf einer DD aktiviert werden.

KundInnen, die andere Backupanwendungen verwenden, die Data Domain Retention Lock nicht nativ unterstützen, können auch nutzerdefinierte Skripte entwickeln, um mit Data Domain Retention Lock die Aufbewahrungsfristen für Dateien manuell festzulegen. Stellen Sie in diesem Fall sicher, dass nutzerdefinierte Skripte die atime der Datei so festlegen, dass sie entsperrt wird, bevor die Backupanwendung versucht, die Datei zu löschen. Andernfalls kann die Backupanwendung versuchen, gesperrte Dateien zu löschen, was fehlschlägt. Die Datei verbleibt auf dem DDR auf unbestimmte Zeit und verbraucht Speicherplatz. Weitere Informationen finden Sie im Data Domain-Administrationshandbuch.

Automatisches Retention Lock
Bei Backupanwendungen, die Data Domain Retention Lock nicht nativ unterstützen, war es für KundInnen schon immer ein Problem, diese Funktion zu nutzen. Die Backupadministration muss Skripte konfigurieren, um Retention Lock für neu aufgenommene Dateien für einen MTree festzulegen. Die Sperre muss so festgelegt werden, dass sie kurz vor dem Ablaufen (und Löschen) des Backups durch die Backupadministration abläuft.

ARL legt eine Sperre für jede einzelne Datei fest, die nach der Aktivierung der Funktion in den MTree geschrieben wird, sodass die Datei für einen bestimmten Zeitraum nach Ablauf der konfigurierten Wartezeit nicht geändert oder entfernt werden kann. Das bedeutet, dass ARL nicht für Workloads oder Backupanwendungen aktiviert werden darf, die einige Dateien im Laufe der Zeit wiederholt aktualisieren müssen, z. B. in VTL-Pools (in VTL-Banddateien wird wiederholt geschrieben), oder für Backupanwendungen, die Metadateninformationen neben den Backupdateien von KundInnen selbst aufbewahren (z. B. NetWorker oder Avamar). Die Aktivierung von ARL führt in diesen Fällen dazu, dass wichtige Dateien für eine gewisse Zeit gesperrt werden, und wenn diese Dateien später für andere Backups beschrieben werden müssen, schlägt der Schreibvorgang fehl, und damit auch alle nachfolgenden Backups.

Um BackupadministratorInnen dabei zu unterstützen, Retention Lock für Backupdateien leichter zu konfigurieren und DDOS auf dieselbe Funktionsstufe mit anderen Anbietern zu heben, gibt es seit DDOS 6.2.0.20 eine Funktion, die über die CLI für jeden MTree mit konfiguriertem Retention Lock aktiviert werden kann, um ein Retention Lock für jede aufgenommene Datei festzulegen (für einen bestimmten Zeitraum), nachdem eine festgelegte Zeitdauer verstrichen ist, seit der Dateischreibvorgang auf die Festplatte abgeschlossen wurde. Auf diese Weise müssen sich AdministratorInnen keine Gedanken mehr über die manuelle (oder skriptbasierte) Festlegung des Retention Lock machen. Dies kann automatisch ohne Kooperation der Backupanwendung erfolgen. 
Vor DDOS 7.8 kann Automatic Retention Lock nicht auf DDBoost Logical Storage Units (LSU) verwendet werden. Der Versuch, dies zu aktivieren, gibt eine Fehlermeldung zurück, die besagt, dass sie nicht unterstützt wird.
Ab 7.8 wird ARL für DDBoost-LSUs unterstützt.

(Die auf Ziel-DDs für MFR (Managed File Replication) verwendete ARL wie NW-Clone sollte eine ausreichend lange „automatische Sperrverzögerung“ aufweisen, um sicherzustellen, dass Klonvorgänge für den Backupsatz abgeschlossen sind, bevor die Sperre für die Dateien aktiviert wird. Beispiel: Eine kleine Datei, die Teil eines Sicherungssatzes ist, wird schnell fertig repliziert, während eine größere Datei länger dauert. Die erste Datei ist mit einer Aufbewahrungssperre versehen, wenn die Replikation der größeren Datei abgeschlossen ist und ein Fehler auftritt, wenn NW versucht, alle Dateien des Sicherungssatzes in das endgültige Archivierungsverzeichnis zu verschieben.)

Die automatische Aufbewahrungssperre wird auf Data Domain VTL nicht unterstützt.

Für entsprechende Versionen gibt es zusätzliche Optionen in der CLI "mtree retention-lock", wie unten gezeigt. Diese Funktion kann auch über die Benutzeroberfläche konfiguriert werden, indem Sie für „Use“ die Option „Automatic“ anstelle von „Manual“ auswählen:     

# mtree retention-lock set
{min-retention-period | max-retention-period |
automatic-retention-period | automatic-lock-delay} <period>
mtree <mtree-path>

Die Funktion für das automatische Retention Lock sperrt eine Datei unmittelbar nach Ablauf eines vorkonfigurierten Zeitraums (automatische Sperrverzögerung). Nachdem die Datei in einen MTree mit aktiviertem Retention Lock geschrieben wurde, erfolgt die Sperre ab dem Zeitpunkt der Festlegung für „automatic-retention-period“, wenn sich der Wert innerhalb der Werte „min-retention-period“ und „max-retention-period“ für den MTree befindet.

Weitere Informationen zur Nutzung und allgemeine Details zur Funktion finden Sie im entsprechenden DDOS-Administrationshandbuch. Diese Funktion eignet sich nicht gut für Situationen, in denen derselbe MTree als Ziel für Backups verwendet wird, die entweder Retention Lock von unterschiedlicher Dauer haben sollten, oder für Backups, die nicht von Anfang an ein Retention Lock haben sollen.

Was kann mit gesperrten Dateien getan werden und was nicht?

• Dateien mit Retention Lock sind schreibgeschützt und können nicht geändert oder gelöscht werden.
• Sobald die Aufbewahrungsfrist einer Datei abgelaufen ist, ist sie „entsperrt“. Wenn sich die Datei im entsperrten Zustand befindet, kann sie immer noch nicht geändert werden, sie kann jedoch gelöscht werden. Der DDR löscht eine Datei nicht automatisch, wenn ihre Aufbewahrungsfrist abläuft (die Löschung muss von einem Clientsystem oder einer Backupanwendung durchgeführt werden).
• Sobald die Aufbewahrungsfrist für eine bestimmte Datei festgelegt wurde, kann sie nicht verkürzt werden (d. h., die atime der Dateien kann nicht reduziert werden).
• Aufbewahrungsfristen können jedoch verlängert werden (die atime kann bis zur maximalen Aufbewahrungsfrist für den MTree erhöht werden).
• Ownership- und Berechtigungseinstellungen für eine Datei können weiterhin geändert werden, während die Datei gesperrt ist.
• Es ist nur möglich, ein Verzeichnis in einem MTree mit aktiviertem Retention Lock umzubenennen oder zu löschen, wenn dieses Verzeichnis keine Dateien enthält. Wenn das Verzeichnis Dateien enthält (selbst wenn diese Dateien keinem Retention Lock unterliegen), schlägt die Umbenennung oder das Löschen des Verzeichnisses fehl.
• Auch wenn der Dateiinhalt selbst nicht geändert wird, ist es nicht zulässig, die Namensdateien (umbenennen), für die eine Sperrung festgelegt ist, zu ändern, aber die Umbenennung ist auch nicht zulässig, sobald die Dateisperre abgelaufen ist. Bei Dateien, die nicht mehr gesperrt sind, ist der einzige zulässige Vorgang das Löschen. Dies ändert sich in DDOS 7.7.4, wo bei nicht mehr gesperrten Dateien auch eine Umbenennung zulässig ist.

Ist es möglich, das Retention Lock für eine Datei oder eine Reihe von Dateien vollständig zu entfernen?
Es ist möglich, das Retention Lock für Dateien in MTrees im Governance-Modus zurückzusetzen (entfernen) – dies geschieht mit dem folgenden Befehl:     

# mtree retention-lock revert [path]

Sobald Retention Lock für eine Datei entfernt wurde, kann sie wie gewohnt geändert oder gelöscht werden. Wenn dieser Befehl für ein Verzeichnis ausgeführt wird, wird für alle Dateien in diesem Verzeichnis und allen Unterverzeichnissen das Retention Lock entfernt.

Es ist nicht möglich, Retention Lock für Dateien in MTrees im Compliance-Modus zurückzusetzen. Wenn dies versucht wird, wird ein entsprechender Fehler angezeigt:     

# mtree retention-lock revert /data/col1/rl_test_comp/testfile
This operation is not allowed. Mtree is in retention-lock compliance mode.

Was geschieht, wenn versucht wird, eine Datei mit Retention Lock zu ändern oder zu entfernen?
Jeder Versuch, eine Datei mit Retention Lock zu ändern oder zu löschen, führt zu einem entsprechenden Fehler „permission denied“:     

# echo " test2" >> /data/col1/rl_test/testfile
bash: testfile: Permission denied
# rm testfile
rm: remove write-protected regular file `testfile'? y
rm: cannot remove `testfile': Permission denied

In DDFS-Protokollen ist zu erkennen, dass der Vorgang fehlgeschlagen ist, weil die Datei ein Retention Lock hat:     

06/07 07:06:59.756 (tid 0x2b5a77605d50): Atime of retention-lock file /data/col1/rl_test/testfile is not expired.
06/07 07:07:42.504 (tid 0x2b5a79111390): Atime of retention-lock file /data/col1/rl_test/testfile is not expired.

Ist es möglich, alle Dateien mit Retention Lock aufzulisten?
Ja, dies kann mit dem Befehl „mtree retention-lock report generate retention-details“ erfolgen:     

mtree retention-lock report generate retention-details
mtrees {<mtree-list> | all}
[format {text | tsv | csv}]
[output-file <file-name>]
               Report detailed information of
               retention-lock files.

Um z. B. die Details aller gesperrten Dateien im MTree /data/col1/rl_test aufzulisten, würde Folgendes durchgeführt werden:     

sysadmin@ddxxxx# mtree retention-lock report generate retention-details mtrees /data/col1/jftest
Report generated on: Fri Jul  1 14:19:31 2016

Report for mtree: /data/col1/jftest
File Path        Mode        Size(Bytes)        Expiration Date
/data/col1/jftest/file1 governance 10521456 Sat Jul  2 22:35:48 2016
/data/col1/jftest/testdir/file2 governance 10521680 Sat Jul  2 22:35:42 2016
/data/col1/jftest/file3 governance 10521820 Sun Jul 10 22:36:09 2016
Total files: 3

Ist es möglich, Retention Lock für einen MTree vollständig zu deaktivieren (nachdem er aktiviert wurde)?
Ja für MTrees mit Governance-Modus. Dies wird mit dem Befehl „mtree retention-lock disable“ durchgeführt:    

# mtree retention-lock disable mtree [mtree]

For example:     
sysadmin@xxxx# mtree retention-lock disable mtree /data/col1/rl_test
Retention-lock feature is disabled (previously enabled) for mtree /data/col1/rl_test.

Once disabled, MTree list indicates that retention lock was used against the MTree but has since been disabled, that is: 
sysadmin@ddxxxx# mtree list
Name                                Pre-Comp (GiB)   Status    Tenant-Unit
---------------------------------   --------------   -------   -----------
...
/data/col1/rl_test                             0.0   RW/RLGD   -
...

sysadmin@ddxxxx# mtree retention-lock revert /data/col1/rl_test/testfile
**** Retention-lock feature is disabled (previously enabled) for mtree which contains the path /data/col1/rl_test/testfile.

• Retention Lock kann für einen MTree im Compliance-Modus nicht deaktiviert werden:     

sysadmin@ddxxxx# mtree retention-lock disable mtree /data/col1/rl_test_comp
**** Operation is not allowed because the system is a retention-lock compliance system

• Die Verzeichnisreplikation – nur unterstützt für Dateien, die den Governance-Modus verwenden – repliziert keine minimalen und maximalen Aufbewahrungsfristen auf dem Zielsystem.
• MTree-Replikation – kann sowohl für Daten im Governance- als auch im Compliance-Modus verwendet werden und repliziert minimale und maximale Aufbewahrungsfristen auf das Zielsystem.
• Erfassungsreplikation – kann sowohl für Daten im Governance- als auch im Compliance-Modus verwendet werden und repliziert minimale und maximale Aufbewahrungsfristen auf das Zielsystem.

# replication break mtree://[destination system]/data/col1/[mtree]

# replication add source mtree://[source system]/data/col1/[mtree] destination mtree://[destination system/data/col1/[mtree]

# mtree retention-lock enable mode compliance mtree [mtree]

# replication resync mtree://[destination system/data/col1/[mtree]

# user reset
# filesys destroy
# filesys archive unit del [archive unit name]

# mtree delete [mtree]
# mtree retention-lock reset [min-retention-period period | max-retention-period period] mtree [mtree]
# mtree retention-lock disable mtree [mtree]
# mtree retention-lock revert

# cloud unit del <cloud unit name>