¿Qué es el bloqueo de retención?
El bloqueo de retención es una función utilizada en los restauradores de Data Domain (DDR) para evitar la modificación o eliminación de ciertos conjuntos de archivos durante un período predeterminado. Es decir, los archivos con bloqueo de retención son de solo lectura hasta que vence su período de retención.
¿Cuáles son las diferentes versiones del bloqueo de retención?
El bloqueo de retención está disponible para dos funciones diferentes:
¿Qué protocolos de acceso a datos se soportan con el bloqueo de retención?
El modo de cumplimiento del bloqueo de retención cumple con los estándares normativos:
La lista de estándares normativos que cumple el modo de cumplimiento del bloqueo de retención incluye lo siguiente:
Para obtener todos los detalles de la información de certificación, comuníquese con su proveedor de soporte contratado.
¿Cómo se habilita el bloqueo de retención de administración?
# mtree retention-lock enable mode governance mtree [mtree]
¿Cómo se habilita el bloqueo de retención de cumplimiento?
(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]
¿Cómo es posible determinar qué MTrees tienen habilitado el bloqueo de retención?
Los MTrees con bloqueo de retención habilitado se indican en la salida de mtree listpor ejemplo:
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
¿Se puede convertir un MTree con bloqueo de retención de administración habilitado en bloqueo de retención de cumplimiento?
Como se indica en la Guía de administración de DDOS, esto no es posible.
¿Se puede convertir un MTree con bloqueo de retención de cumplimiento habilitado en bloqueo de retención de administración?
Como se indica en la Guía de administración de DDOS, esto no es posible.
¿Cómo se establecen los períodos de retención o bloqueo de archivos?
Una vez que se habilita el bloqueo de retención en un MTree, se debe fijar un período de retención mínimo y máximo. Estos períodos determinan el tiempo mínimo y máximo durante el cual se puede bloquear un archivo dentro del MTree. Por ejemplo:
# mtree retention-lock set min-retention-period [period] mtree [mtree]
# mtree retention-lock set max-retention-period [period] mtree [mtree]
Los períodos se pueden dar en varias unidades de la siguiente manera:
¿Cómo se pueden mostrar los períodos de retención existentes?
Esto se puede realizar mediante los siguientes dos comandos:
# mtree retention-lock show min-retention-period mtree [mtree] # mtree retention-lock show max-retention-period mtree [mtree]
Por ejemplo:
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.
¿Cómo se bloquean los archivos dentro de un MTree con bloqueo de retención activado?
El atime de un archivo se puede cambiar desde un cliente NFS o CIFS mediante el comando “touch”:
# touch -a -t [expiry time] [file to be locked]
Por ejemplo, para configurar atime de /data/col1/rl_test/testfile a las 07:05 del 8 de junio:
# touch -a -t 06080705 /data/col1/rl_test/testfile
El período del tiempo actual al tiempo futuro debe estar dentro de los períodos de retención mínimos y máximos para el MTree. De lo contrario, se genera un error al modificar el atime de los archivos:
# touch -a -t 08080705 /data/col1/rl_test/testfile
touch: setting times of `/data/col1/rl_test/testfile': Permission denied
También se muestra un mensaje correspondiente en los archivos de registro del sistema de archivos de Data Domain (DDFS):
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.
De manera predeterminada, los clientes CIFS (Windows) no incluyen un comando “touch” o una utilidad; sin embargo, varias de estas utilidades están disponibles de forma libre para su descarga desde diversos sitios web de otros fabricantes.
s¿Qué aplicaciones de respaldo soportan de forma automática el bloqueo de retención de archivos después de escribirlos en un DDR?
Data Domain Retention Lock es compatible con los protocolos de una sola escritura y múltiples lecturas (WORM) basados en NAS y estándares del sector. La integración cumple con los requisitos por sus aplicaciones de archivos, como Symantec Enterprise Vault, SourceOne, Cloud Tiering Appliance o DiskXtender.
Para Dell NetWorker, se soportan los modos de administración y cumplimiento.
A partir de junio de 2024, las versiones recientes de Avamar soportan tanto el cumplimiento de Data Domain Retention Lock como la administración) como parte de la característica "Immutable Backups" de Avamar. Consulte el siguiente artículo y la documentación de Avamar para obtener más información:
Avamar y Data Domain: Habilitación de respaldos inmutables de Avamar y bloqueo de retención del modo de cumplimiento de normas de Data Domain
Es fundamental que se sigan estrictamente los pasos para habilitar la función "Respaldos inmutables" de Avamar. Si no lo hace, puede terminar con un MTree de Avamar en DD en el que no se puede escribir más o que tiene problemas operativos que obligan a una recuperación prolongada. Avamar no funciona con el bloqueo de retención automático (ARL, por sus siglas en inglés) de DD, y ARL no debe estar habilitado para ningún MTree de Avamar en un DD.
Los clientes que utilicen otras aplicaciones de respaldo que no soporten de forma nativa el Data Domain Retention Lock también pueden desarrollar scripts personalizados para utilizar Data Domain Retention Lock con el fin de establecer manualmente los periodos de retención de los archivos. En este caso, asegúrese de que los scripts personalizados establezcan el atime del archivo de modo que se desbloquee antes de que la aplicación de respaldo intente eliminar el archivo. Si no se hace esto, la aplicación de respaldo puede intentar eliminar los archivos bloqueados (lo cual falla); el archivo permanece en el DDR de forma indefinida, ocupando espacio en disco. Consulte la guía de administración de Data Domain.
Bloqueo de retención automático
En el caso de las aplicaciones de respaldo que no soportan de forma nativa la función de bloqueo de retención de Data Domain, aprovechar la función siempre ha sido un problema para los clientes. El administrador de respaldo debe configurar scripts para establecer el bloqueo de retención en los archivos recién ingeridos para un MTree. El bloqueo debe ser configurado para que expire poco antes de que el respaldo expire (y lo borre) el administrador del respaldo.
ARL establece un bloqueo en todos y cada uno de los archivos escritos en el MTree después de que se ha habilitado la función, impidiendo que el archivo se pueda cambiar o eliminar durante un período determinado de tiempo después de que haya pasado el período de enfriamiento configurado. Esto significa que ARL no se debe habilitar para cargas de trabajo o aplicaciones de respaldo que necesitan actualizar algunos archivos repetidamente a lo largo del tiempo. Por ejemplo, en pools de VTL (los archivos de cinta de VTL se escriben repetidamente) o para aplicaciones de respaldo que conservan información de metadatos junto con los propios archivos de respaldo del cliente (como NetWorker o Avamar). Habilitar ARL en estos casos para tener archivos importantes bloqueados durante algún tiempo, y cuando estos archivos deben ser escritos más tarde para otros respaldos, la escritura falla, y también lo harán los respaldos posteriores. Para ayudar a los administradores de respaldos a reducir la carga de mantener el bloqueo de retención de archivos de respaldo y poner al DDOS en paridad de características con otros proveedores, desde DDOS 6.2.0.20 hay una característica que se puede habilitar desde el CLI para cada MTree con Bloqueo de Retención configurado, para establecer un bloqueo en cada archivo recopilado (por un período determinado), después de que haya pasado una cantidad predeterminada de tiempo desde que se completó la escritura del archivo en el disco. De esta manera, los administradores ya no tienen que preocuparse por el ajuste manual (o con script) del bloqueo de retención, y esto puede ocurrir de forma automática sin la cooperación de la aplicación de respaldo.
Antes de DDOS 7.8, el bloqueo de retención automático no se podía utilizar en unidades de almacenamiento lógicas (LSU) de DD Boost y, cuando se intentaba habilitarlo, aparecía un mensaje de error en el que se indicaba que no se soportaba.
Desde la versión 7.8 en adelante, ARL se soporta en las LSU de DD Boost.
(La versión de ARL que se utiliza en los DD objetivo para la replicación de archivos administrados [MFR], como el clon de NW, debe tener un “automatic-lock-delay” de duración suficiente a fin de asegurarse de que las operaciones de clonación estén completas para el conjunto de respaldo antes de establecer el bloqueo en los archivos. Ejemplo: Un archivo pequeño que forma parte de un conjunto de respaldo termina de replicarse rápidamente, mientras que un archivo más grande tarda más. Luego, el primer archivo se bloquea con retención para cuando el archivo más grande termina de replicarse y encuentra un error cuando NW intenta mover todos los archivos del conjunto de respaldo al directorio de archiving final).
El bloqueo de retención automático no es compatible con la VTL de Data Domain.
En las versiones correspondientes, hay opciones adicionales en la mtree retention-lock CLI, como se muestra a continuación. Esta función también se puede configurar en la interfaz del usuario mediante la selección de “Automatic” en lugar de “Manual” en la opción “Use”:
# mtree retention-lock set
{min-retention-period | max-retention-period |
automatic-retention-period | automatic-lock-delay} <period>
mtree <mtree-path>
La función de bloqueo de retención automático bloquea un archivo de forma inmediata después de que vence un período de enfriamiento preconfigurado (automatic-lock-delay). Una vez que el archivo se escribe en un MTree con el bloqueo de retención habilitado, y el bloqueo es válido para “automatic-retention-period” desde el momento en que se configuró, si el valor se encuentra dentro de los valores “min-retention-period” y “max-retention-period” configurados en el MTree, se produce el bloqueo.
Para obtener más información sobre el uso y los detalles generales sobre la función, consulte la Guía de administración de DDOS correspondiente. Esta función no es adecuada en situaciones en las que se utiliza el mismo MTree como destino de los respaldos que deben tener conjuntos de bloqueos en diferentes períodos, o respaldos que deberían y respaldos que no deberían tener un bloqueo configurado para comenzar.
¿Qué se puede o qué no se puede hacer con un archivo bloqueado?
¿Es posible eliminar por completo el bloqueo de retención de un archivo o un conjunto de archivos?
Es posible “revertir” (eliminar) el bloqueo de retención de archivos en MTrees mediante el modo de administración. Esto se realiza con el siguiente comando:
# mtree retention-lock revert [path]
Una vez que se elimina el bloqueo de retención de un archivo, se lo puede modificar o eliminar de manera normal. Si este comando se ejecuta en un directorio, el bloqueo de retención se elimina de todos los archivos dentro de ese directorio y todos los subdirectorios.
No es posible revertir un bloqueo de retención de archivos en MTrees mediante el modo de cumplimiento. Si se intenta, se muestra el error correspondiente:
# mtree retention-lock revert /data/col1/rl_test_comp/testfile
This operation is not allowed. Mtree is in retention-lock compliance mode.
¿Qué sucede si se intenta modificar o eliminar un archivo con bloqueo de retención?
Cualquier intento de modificar o eliminar un archivo con bloqueo de retención provoca un permission denied error:
# 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
Los registros de DDFS indican que la operación falló debido al bloqueo de retención del archivo:
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.
¿Es posible enumerar todos los archivos que tienen bloqueo de retención?
Sí, esto se puede realizar mediante el comando mtree retention-lock report generate retention-details el comando:
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.
Por ejemplo, para enumerar los detalles de todos los archivos bloqueados en el archivo /data/col1/rl_test MTree Se realizaría lo siguiente:
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
¿Es posible deshabilitar completamente el bloqueo de retención para un MTree (después de habilitarlo)?
Sí, en el caso de los MTrees que utilizan el modo de gobierno, esto se realiza mediante el mtree retention-lock disable el comando:
# 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] Estos sistemas no se pueden iniciar en modo de usuario único en la recuperación por parte del soporte técnico sin el uso de una unidad USB y el acceso físico al sistema.
# 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 revertSin embargo, en DDOS 7.3 y versiones posteriores, se ha hecho una provisión para que los clientes puedan eliminar MTrees habilitados en el cumplimiento del bloqueo de retención, si se cumple lo siguiente:
# cloud unit del <cloud unit name>
# filesys enable