Was ist Retention Lock?
Retention Lock ist eine Funktion, die auf Data Domain Restorers (DDRs) verwendet wird, um das Ändern oder Löschen bestimmter Dateisätze für einen vorab festgelegten Zeitraum zu verhindern. Das heißt, Dateien mit Retention Lock sind schreibgeschützt, bis ihre Aufbewahrungsfrist abläuft.
Was sind die verschiedenen Versionen von Retention Lock?
Retention Lock bietet zwei verschiedene Funktionen:
Welche Datenzugriffsprotokolle werden mit Retention Lock unterstützt?
Der Compliance-Modus von Retention Lock erfüllt gesetzliche Vorschriften:
Die Liste der gesetzlichen Vorschriften, die der Compliance-Modus von Retention Lock erfüllt, umfasst:
Weitere Informationen zu Zertifizierungen erhalten Sie von Ihrem Supportanbieter.
Wie wird Retention Lock Governance aktiviert?
# mtree retention-lock enable mode governance mtree [mtree]
Wie wird Retention Lock Compliance aktiviert?
(ADMIN USER) # user add [username] role security
(SECURITY USER): # authorization policy set security-officer enabled
(ADMIN USER) # system retention-lock compliance configure
(ADMIN USER) # system retention-lock compliance enable
(ADMIN USER) # mtree retention-lock enable mode compliance mtree [mtree]
Wie lässt sich feststellen, für welche MTrees Retention Lock aktiviert ist?
MTrees mit aktiviertem Retention Lock werden in der Ausgabe von mtree listZum 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:
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?
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.
In den entsprechenden Versionen gibt es zusätzliche Optionen in der mtree retention-lock CLI, 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?
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 passiert, wenn versucht wird, eine Datei mit Aufbewahrungssperre zu ändern oder zu entfernen?
Jeder Versuch, eine Datei mit Aufbewahrungssperre zu ändern oder zu löschen, führt zu einer entsprechenden permission denied Fehler:
# 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 aufzulisten, die mit einer Aufbewahrungssperre versehen sind?
Ja, dies kann mithilfe der mtree retention-lock report generate retention-details Befehls:
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.
Zum Beispiel, um Details zu allen gesperrten Dateien im /data/col1/rl_test MTree Folgendes würde 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 es aktiviert wurde)?
Ja, für MTrees, die den Governance-Modus verwenden, erfolgt dies über die mtree retention-lock disable Befehls:
# 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 listindicates that retention lock was used against the MTree but has since been disabled, that is: sysadmin@ddxxxx#mtree listName 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.
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
# 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] Solche Systeme können nicht im Einzelnutzermodus gestartet werden, um eine Wiederherstellung durch den technischen Support ohne Verwendung eines USB-Laufwerks oder physischen Zugriffs auf das System durchzuführen.
# 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 revertIn DDOS 7.3 und späteren Versionen wurden jedoch Vorkehrungen getroffen, damit KundInnen MTrees mit aktiviertem Retention Lock im Compliance-Modus unter folgenden Bedingungen löschen können:
# cloud unit del <cloud unit name>
# filesys enable