En este artículo, se proporciona una visión general concisa de la funcionalidad de bloqueo de retención (RL) de Data Domain y respuestas a preguntas frecuentes relacionadas.
En este artículo, se proporciona una visión general concisa de la funcionalidad de bloqueo de retención (RL) de Data Domain y respuestas a preguntas frecuentes relacionadas.
¿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:
- Administración: La menos estricta de las dos funciones de bloqueo de retención (es decir, los bloqueos contra archivos se pueden revertir si es necesario).
- Compliance: La más estricta de las dos funciones que cumplen con varios estándares normativos comunes. Es decir, los bloqueos contra archivos no se pueden revertir. El DDR se debe configurar con un usuario con la función de “jefe de seguridad” que debe autenticar ciertos comandos. Existen diversas restricciones en otras funcionalidades para evitar que los datos bloqueados se eliminen o que los bloqueos se reviertan antes.
Nota:
- El modo de cumplimiento está disponible en DDOS 5.3 (y versiones posteriores).
- Cada función de bloqueo de retención requiere una clave de licencia independiente.
- La funcionalidad de bloqueo de retención se habilita por MTree.
- Un solo sistema puede utilizar el modo de administración y de cumplimiento en MTrees independientes. Sin embargo, debe tener licencias de cumplimiento y de administración independientes instaladas.
- No habilite ningún tipo de bloqueo de retención de DD en los árboles MT utilizados para almacenar datos de Avamar a menos que se indique en la documentación de Avamar, como parte de la ejecución de esta función en Avamar. La habilitación de DD RL en cualquier MTree sin seguir el proceso correcto de Avamar puede hacer que el MTree quede inutilizable para los respaldos e incurrir en la necesidad de una recuperación prolongada. Esto es especialmente cierto si se habilita el bloqueo de retención automático (ARL) para un MTree de Avamar.
- Es posible que la funcionalidad de bloqueo de retención no soporte MTrees que se utilizan para almacenar datos mediante versiones anteriores de Avamar o del software de protección en un dispositivo de la serie Data Protection de PowerProtect o en un Integration Data Protection Appliance. Esto puede impedir que Avamar o el software de protección dentro de Integration Data Protection Appliance funcionen como se espera y pasen al estado READONLY.
¿Qué protocolos de acceso a datos se soportan con el bloqueo de retención?
- Los protocolos NFS, CIFS y DD Boost se soportan por completo con MTrees que usan el modo de cumplimiento o de administración del bloqueo de retención.
- El protocolo de biblioteca de cintas virtuales (VTL) solo se soporta con MTrees que utilizan el modo de administración del bloqueo de retención. El bloqueo de retención automático no se soporta en la VTL de Data Domain. Consulte la Guía de administración de Data Domain para determinar cómo desbloquear las cintas con bloqueo de retención, de modo que se puedan escribir en estas.
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:
- SEC 17a-4(f)
- Regla 1.31b de CFTC
- FDA 21 CFR, parte 11
- Ley Sarbanes-Oxley
- IRS 98025 y 97-22
- Estándar ISO 15489-1
- MoREQ2010
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?
- Se agrega una licencia de administración del bloqueo de retención al DDR.
- El modo de administración del bloqueo de retención está activado en cualquier MTree requerido:
# mtree retention-lock enable mode governance mtree [mtree]
¿Cómo se habilita el bloqueo de retención de cumplimiento?
- Hay instrucciones específicas para algunos modelos más recientes de Data Domain con iDRAC.
- Se agrega una licencia de cumplimiento del bloqueo de retención al DDR.
- Se debe crear un usuario con la función de “security” (suponiendo que dicho usuario no exista):
(ADMIN USER) # user add [username] role security
- El usuario con la función de “security” debe iniciar sesión en el DDR y habilitar las autorizaciones de usuario de seguridad:
(SECURITY USER): # authorization policy set security-officer enabled
- El sistema debería estar configurado para el modo de cumplimiento del bloqueo de retención. Una vez que se ejecuta el siguiente comando hasta su finalización, el sistema se reinicia de forma automática:
(ADMIN USER) # system retention-lock compliance configure
- Una vez que el sistema se haya reiniciado, el modo de cumplimiento del bloqueo de retención debería habilitarse en el sistema:
(ADMIN USER) # system retention-lock compliance enable
Nota: Para las versiones más recientes de DDOS, esta tarea se debe realizar con la interfaz de usuario de Data Domain. Administración > Cumplimiento
- El modo de cumplimiento del bloqueo de retención está activado en cualquier MTree requerido:
(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 activado se indican en la salida de “mtree list”, por 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:
- 1 min
- 1 h
- 1 día
- 1 mes
- 1 año
Nota:
- Un período de retención mínimo no puede ser inferior a 12 horas.
- Un período de retención máximo no puede ser mayor que 70 años.
- El período de retención mínimo debe ser menor que el período de retención máximo.
- Los períodos de retención para cada MTree se configuran de la misma manera, sin importar la variante de bloqueo de retención que se utilice.
¿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?
- Cuando se habilita el bloqueo de retención en un MTree, los archivos existentes dentro del MTree no se bloquean de forma automática (es decir, todos los archivos preexisteentes permanecen en modo de lectura o escritura).
- Cuando se escribe un nuevo archivo en un MTree con el bloqueo de retención habilitado, el archivo no se bloquea con retención de forma automática. Es decir, el nuevo archivo permanece en modo de lectura o escritura.
Nota: A partir de DDOS 6.2.0.20, hay una función en DDOS denominada “bloqueo de retención automático”, que puede establecer un bloqueo en todos los archivos escritos de forma automática. Consulte la sección “Bloqueo de retención automático” más adelante en este artículo de la base de conocimientos para obtener más información.
- Para el bloqueo de retención de un archivo específico, se debe modificar el atime del archivo a fin de que coincida con la fecha y la hora en que el archivo debe estar bloqueado por retención. Esa es la fecha y la hora hasta la cual el archivo debe permanecer en modo de solo lectura. Hasta que el time se modifique de esta manera, el archivo no se puede bloquear con retención (y se puede modificar o quitar).
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 cuando se modifica el atime del archivo:
# 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.
Nota: Los archivos no se pueden bloquear con retención hasta que se escriban en el DDR. No es posible crear un archivo vacío, bloquear la retención de ese archivo y, a continuación, escribir datos en el archivo.
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 uno más grande tarda más tiempo. El primer archivo está bloqueado por retención cuando se completa la replicación del más grande y se genera 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 se soporta en la VTL de Data Domain.
En las versiones aplicables, hay opciones adicionales en la CLI de “mtree retention-lock”, 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?
- Los archivos con bloqueo de retención son de solo lectura y no se pueden modificar ni eliminar.
- Una vez que vence el período de retención de un archivo, se “desbloquea”: cuando se encuentra en un estado desbloqueado, el archivo aún no se puede modificar; sin embargo, se puede eliminar. El DDR no elimina de forma automática un archivo cuando vence su período de retención (la eliminación posterior se debe realizar desde un sistema cliente o una aplicación de respaldo).
- Una vez configurado el período de retención para un archivo específico, no se puede reducir (es decir, el atime del archivo no se pueden adelantar).
- Sin embargo, los períodos de retención se pueden aumentar (atime se puede aumentar hasta el período de retención máximo para el MTree).
- Los ajustes de propiedad y permisos para un archivo se pueden seguir modificando mientras el archivo está bloqueado.
- Solo es posible cambiar el nombre o eliminar un directorio en un MTree con el bloqueo de retención habilitado si ese directorio no contiene archivos. Si el directorio contiene archivos (incluso si estos archivos no tienen bloqueo de retención), el cambio de nombre o la eliminación del directorio fallará.
- Incluso si no se cambia el contenido del archivo, no se permite cambiar el nombre (renombrar) de los archivos que tienen un bloqueo establecido, pero el cambio de nombre tampoco se permite una vez que el bloqueo del archivo caduque. En el caso de los archivos que ya no están bloqueados, solo se permite una operación: la eliminación. Esto cambia en DDOS 7.7.4, ya que se permite el cambio de nombre de los archivos que ya no estén bloqueados.
¿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 el error de “permission denied” correspondiente:
# 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 están bloqueados por retención?
Sí, esto se puede realizar mediante el comando “mtree retention-lock report generate retention-details”:
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 MTree /data/col1/rl_test, 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 por completo el bloqueo de retención para un MTree (después de habilitarlo)?
Sí, en MTrees que utilizan el modo de administración, esto se realiza mediante el comando “mtree retention-lock disable”:
# 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 -
...
Nota: Una vez que el bloqueo de retención se deshabilita en un MTree:
- Los nuevos archivos escritos en el MTree no se pueden bloquear con retención.
- Los archivos que ya están bloqueados permanecen bloqueados durante su período de retención definido antes (es decir, todos los bloqueos no se revierten de forma automática cuando el bloqueo de retención se deshabilita en un MTree).
- Los bloqueos existentes de archivos en un MTree donde el bloqueo de retención está deshabilitado no se pueden revertir. Todas las reversiones necesarias se deben realizar antes de que se deshabilite el bloqueo de retención:
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.
- El bloqueo de retención no se puede deshabilitar para un MTree con el modo de cumplimiento:
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
¿Se puede seguir utilizando la replicación en MTrees que tengan habilitado el bloqueo de retención?
Sí, los MTrees o archivos con bloqueo de retención se pueden replicar mediante diversas topologías de replicación:
- Replicación de directorio: solo soportado en archivos con el modo de administración; no replica los períodos de retención mínimos y máximos en el sistema de destino.
- Replicación de MTree: se puede utilizar para datos de modo de administración o cumplimiento, y replica los períodos de retención mínimos y máximos en el sistema de destino.
- Replicación de recopilaciones: se puede utilizar para datos de modo de administración o cumplimiento, y réplica los períodos de retención mínimos y máximos en el sistema de destino.
Nota: Para que los bloqueos de retención se conserven en los sistemas de destino:
- Los sistemas fuente y de destino deben tener instaladas las licencias de bloqueo de retención correspondientes.
- Los contextos de replicación de MTree deben tener “Replication propagate-retention-lock” establecido en Enabled.
- Para los archivos replicados por la replicación de directorios, los períodos de retención mínimo y máximo de MTrees correspondientes se deben configurar de forma manual en el sistema de destino.
¿Existen otras restricciones cuando se replican archivos con bloqueo de retención?
Sí. La resincronización de los contextos de replicación (que intenta restablecer un contexto configurado antes, pero dañado), en el que se utilizan datos con bloqueo de retención, puede fallar.
Nota:
- Si se utiliza la replicación de MTree y el MTree de destino contiene archivos bloqueados de retención que no existen en la fuente, se produce un error de resincronización.
- Si se utiliza la replicación de directorios y el destino tiene un bloqueo de retención habilitado, pero la fuente no lo tiene, se produce un error de resincronización.
Nota: Cuando se utiliza la replicación de MTree, una resincronización se realiza con éxito en los siguientes casos: si el MTree de destino no contiene archivos con bloqueo de retención, que no están presentes en el DDR fuente:
- El MTree fuente no tiene el bloqueo de retención habilitado, pero el destino sí lo tiene.
- El MTree de destino no tiene habilitado el bloqueo de retención, pero la fuente sí lo tiene.
Tampoco es posible habilitar el modo de cumplimiento del bloqueo de retención en un MTree que ya es miembro de un contexto de replicación de MTree. En este caso:
# 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]
¿Se pueden copiar rápidamente los archivos con bloqueo de retención?
Sí, se puede hacer una copia rápida de los archivos que tienen bloqueo de retención de manera normal. Si el MTree de destino que mantiene la copia rápida está habilitado para el bloqueo de retención, el bloqueo de retención del archivo se conserva en la copia rápida. Si el MTree de destino no está habilitado para el bloqueo de retención, la copia rápida no tendrá bloqueo de retención.
¿Existen otras restricciones en la funcionalidad del sistema cuando se utiliza el bloqueo de retención?
Los siguientes comandos no están permitidos en sistemas que utilizan el modo de cumplimiento del bloqueo de retención:
# 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.
Los siguientes comandos no se pueden aplicar a MTrees con el modo de cumplimiento del bloqueo de retención:
# 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
Sin 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:
- DD ejecuta DDOS 7.3 o versiones posteriores.
- El MTree de RLCE que se eliminará está vacío (no tiene archivos ni directorios).
- El administrador aprueba con éxito la autenticación de jefe de seguridad.
En los sistemas configurados con retención a largo plazo (nivel de nube), los comandos destructivos similares también pueden no estar permitidos, por ejemplo:
# cloud unit del <cloud unit name>
Nota: Los MTrees que utilizan el modo de administración del bloqueo de retención (o donde este modo estaba habilitado) solo se pueden eliminar una vez que el MTree no contenga archivos; si hay archivos restantes en el MTree, se muestra un error.
¿El reloj del sistema es importante en los sistemas habilitados para el bloqueo de retención?
Sí, los sistemas habilitados para el cumplimiento del bloqueo de retención habilitan un “reloj de seguridad” interno a fin de evitar la manipulación maliciosa del reloj del sistema (lo que puede permitir que los archivos con bloqueo de retención se eliminen con anticipación). Los tiempos de los relojes de seguridad y del sistema se comparan de forma regular y, si hay una desviación acumulada de dos semanas entre los dos en un solo año de calendario, el sistema de archivos de Data Domain (DDFS) se deshabilita de forma automática para evitar el acceso a los datos en el DDR. Esto también puede suceder si el reloj del sistema se modifica de forma repentina y la hora cambia en más de dos semanas.
En este caso, DDFS se puede volver a activar mediante las siguientes acciones:
- Iniciar sesión en la DDR
- Compruebe que el reloj del sistema esté configurado de forma correcta.
- Habilitar el sistema de archivos:
# filesys enable
- Cuando se le solicite, ingrese los detalles de un usuario con función de seguridad para permitir que se restablezca el reloj de seguridad y se habilite DDFS.
¿Se puede sincronizar el reloj del sistema con Active Directory en sistemas habilitados para el cumplimiento del bloqueo de retención?
No. Cuando el cumplimiento de normas de bloqueo de retención está habilitado, los servidores CIFS ya no sincronizan la hora del sistema con Active Directory. Si hay una diferencia horaria superior a cinco minutos entre el sistema y Active Directory, el servidor CIFS muestra un mensaje de error cuando un usuario de Active Directory intenta iniciar sesión o el sistema intenta unirse a un dominio de Active Directory. Configure la hora de Active Directory con NTP para evitar este error.
Esto contrasta con los sistemas en los que el cumplimiento de bloqueo de retención no está habilitado, pero Active Directory está en uso. En esta situación, no se recomienda habilitar NTP, ya que puede haber conflictos de ajustes de hora entre Active Directory y NTP.
¿Qué pasos se pueden realizar si un DDR con archivos con bloqueo de retención se llena al máximo?
Suponiendo que no hay espacio “limpiable” en el DDR (se ejecuta la limpieza, pero el sistema permanece lleno por completo), se debe revisar su contenido para determinar si:
Una vez hecho esto, la limpieza se debe volver a ejecutar para liberar espacio físico en el sistema. Como alternativa, si no se pueden eliminar datos físicos del sistema, se debe agregar almacenamiento físico adicional al DDR y expandir el sistema de archivos (suponiendo que la expansión es soportada por el DDR o la configuración actuales).
Si los únicos archivos del sistema están bloqueados con el modo de cumplimiento, no es posible revertir los bloqueos y eliminar estos archivos. Como resultado, el espacio no se puede liberar, a menos que:
-
Se alcance el período de retención para algunos o todos los archivos. Después de esto, se pueden eliminar y ejecutar de manera limpia (como se describió antes).
-
El sistema se reinstale desde la unidad USB (lo que provoca la pérdida de todos los datos en el DDR).
-
Se agregue más almacenamiento físico al sistema (como se describió antes).
Nota: Es completamente posible llenar por completo un DDR con archivos bloqueados mediante el modo de cumplimiento. En este caso, no hay nada que un administrador o soporte técnico pueda hacer para liberar espacio (es decir, no hay una funcionalidad de bajo nivel a fin de eliminar o revertir los bloqueos del modo de cumplimiento y eliminar los archivos correspondientes con anticipación).