Hasta el momento, este documento se enfocó en la gestión de soluciones de Oracle Hierarchical Storage Manager and StorageTek QFS Software como sistemas de archivos UNIX comunes, donde los usuarios y las aplicaciones crean, modifican y suprimen archivos periódicamente. El punto central era la caché de disco y el archivo funcionaba principalmente como un servicio de copia de seguridad altamente integrado. En este capítulo, nos volvemos a enfocar en el archivo como una solución de repositorio y gestión para la conservación de datos a largo plazo. Las técnicas y los principios de gestión descritos anteriormente siguen siendo pertinentes. Sin embargo, la caché de disco ahora funciona principalmente como una manera de introducir archivos en un archivo de almacenamiento que no permite supresión ni modificación tras esa introducción.
Los requisitos exactos varían. Un repositorio que almacena registros médicos o comerciales durante un período obligatorio posiblemente deba desechar registros periódicamente. Sin embargo, un archivo que almacena datos científicos, registros históricos o genealógicos, o música digital, películas y programas de televisión posiblemente deba almacenar el contenido para siempre. Por este motivo, Oracle HSM admite la conservación digital de varias maneras:
Los resúmenes de mensajes (totales de control) permiten detectar daños, datos dañados y modificaciones no autorizadas en los archivos, de modo que pueda corregir problemas de hardware y reemplazar los archivos defectuosos con copias no defectuosas almacenadas en otra parte del archivo.
Los atributos de corrección de archivos funcionan junto con los resúmenes de mensajes para garantizar que solo el superusuario pueda modificar los archivos ya corregidos. Cuando Oracle HSM almacena provisional o permanentemente un archivo corregido, vuelve a validar el total de control con el atributo de corrección para probar que el archivo no se haya modificado.
Los sistemas de archivos de escritura única lectura múltiple (WORM) de Oracle HSM permiten convertir los archivos a solo lectura y exigir la retención durante un período específico. Estos sistemas de archivos se pueden configurar para que el superusuario no pueda modificar archivos o atributos de archivos, como el atributo de corrección antes mencionado.
El capítulo comienza con una breve revisión de las medidas básicas de protección de datos de Oracle HSM que constituyen la base de cualquier solución de almacenamiento a largo plazo: Configuración de sistemas de archivos para conservación. A continuación, explica las tareas que se enfocan específicamente en la conservación de datos:
Toda solución de conservación comienza con sistemas de archivos correctos altamente redundantes. Por lo tanto, si aún no lo ha hecho, revise los capítulos sobre implementación de Guía de configuración e instalación de Oracle Hierarchical Storage Manager and StorageTek QFS. Proteja el acceso al archivo mediante servidores redundantes, conexiones de red y dispositivos de almacenamiento. Proteja los datos de archivos configurando al menos dos copias adicionales de cada archivo, cada una almacenada en medios independientes. En la mayoría de los casos, es recomendable archivar una copia en disco o dispositivos de almacenamiento de estado sólido y dos copias en medios de cinta. Si es posible, implemente la función de verificación de integridad de datos de Oracle HSM para asegurarse de que los bloques de cintas puedan escribirse y leerse correctamente. Para proteger los metadatos de sistemas de archivos, periódicamente genere archivos de volcado y realice copias de seguridad de los logs de archivado.
Los resúmenes de mensajes (totales de control) permiten que los encargados de conservación evalúen los archivos almacenados para detectar cambios que puedan indicar deterioro gradual, error de hardware u operador, o modificaciones no autorizadas e intencionales del contenido. Un resumen de mensaje es simplemente un resumen matemático del contenido de un archivo generado mediante una función hash criptográfica unidireccional. Las funciones hash criptográficas son extremadamente sensibles a los cambios en los datos de entrada. Aun los pequeños cambios en la entrada originan grandes cambios en la salida. Por lo tanto, los resúmenes de mensajes son ideales para detectar daños en los archivos y modificaciones no autorizadas. Al volver a calcular el resumen de un archivo y comparar el valor resultante con un valor de resultado almacenado se puede ver si cambió el archivo.
Los sistemas de archivos de Oracle Hierarchical Storage Manager pueden introducir, crear, almacenar y validar resúmenes de mensajes mediante cualquiera de las siguientes funciones hash criptográficas:
SHA1, el miembro de 160 bits de la familia de funciones criptográficas del algoritmo hash seguro.
Los algoritmos hash seguros se definen en la Publicación 180-4 del Estándar Federal de Procesamiento de la Información (FIPS), Instituto Nacional de Normas y Tecnología (2012). Oracle HSM usa SHA1 por defecto.
SHA256, el miembro de 256 bits de la familia del algoritmo hash seguro.
SHA384, el miembro de 384 bits de la familia del algoritmo hash seguro.
SHA512, el miembro de 512 bits de la familia del algoritmo hash seguro.
MD5, la función de resumen de mensaje de 128 bits definida por el Grupo de Trabajo de Ingeniería de Internet (IETF) en la solicitud de comentarios (RFC) 1321.
Una función exclusiva de Oracle HSM de 128 bits que ahora es principalmente útil para la compatibilidad con implementaciones anteriores de Storage Archive Manager.
Los usuarios pueden proporcionar un valor de resumen existente cuando un archivo se introduce en el repositorio o el sistema de archivos puede calcular uno, ya sea inmediatamente o cuando el archivo se almacena por primera vez. Los sistemas de archivos de Oracle HSM almacenan valores de resumen con los metadatos del sistema de archivos mediante un atributo de archivo especial. Una vez que se configura el atributo, el sistema de archivos vuelve a calcular un resumen y lo valida con el valor almacenado cada vez que se vuelve a almacenar el archivo correspondiente y, de manera opcional, cada vez que el archivo se almacena provisionalmente desde el medio de archivo hasta la caché de disco.
Sin embargo, tenga en cuenta que la función de migración de medios de Oracle HSM copia archivos a medios nuevos sin volver a calcular los totales de control (para obtener información sobre la migración de medios, consulte el Capítulo 8, Migración a medios de almacenamiento nuevos). Si un archivo no se copia correctamente, existe un pequeño riesgo de que el daño no sea detectado hasta que el archivo vuelva a almacenarse provisionalmente y a validarse. El uso de validación de integridad de datos (DIV) minimiza este riesgo (consulte la Guía de configuración e instalación de Oracle Hierarchical Storage Manager and StorageTek QFS para obtener detalles).
Antes de comenzar a utilizar resúmenes de mensajes, debe comprender Cómo asegurarse de que el rendimiento de host del sistema de archivos sea adecuado. Puede consultar las siguientes secciones para obtener instrucciones sobre cómo proporcionar, generar y validar resúmenes:
Cómo proporcionar un resumen de mensaje y activar la validación para un archivo
Generación de un resumen de mensaje y activación de la validación para un archivo
Validación del resumen de mensaje de un archivo durante el almacenamiento provisional
Cambio de los atributos de validación y resumen de mensajes antes de almacenar un archivo
Si tiene previsto utilizar en gran medida los resúmenes de mensajes, asegúrese de que el host del sistema de archivos tenga suficientes recursos informáticos para un rendimiento adecuado. La mayoría de las plataformas modernas incorporan hardware criptográfico dedicado que puede llevar a cabo eficazmente cálculos especializados sin consumir ciclos del procesador central. Asegúrese de aprovechar estas capacidades si están disponibles.
Para comprobar las capacidades de un posible host de sistema de archivos, realice lo siguiente:
Inicie sesión en el host del sistema de archivos como root:
root@solaris:~#
Asegúrese de que el sistema operativo del host sea Solaris 11.1 o posterior. Utilice el comando uname -v.
Las versiones anteriores del sistema operativo no admiten la aceleración de hardware de funciones hash. En el ejemplo, el sistema operativo del host es Solaris 11.2:
root@solaris:~# uname -v 11.2 root@solaris:~#
Visualice la arquitectura del juego de instrucciones. En el símbolo del sistema, introduzca el comando isainfo -v:
root@solaris:~# isainfo -v
Si el host de Solaris 11 es un sistema Oracle Sun SPARC T3 o posterior, la salida del comando isainfo -v debe mostrar juegos de instrucciones que admitan los algoritmos criptográficos sha512, sha256, sha1 y md5.
En el ejemplo, el host Sun SPARC T4-2 proporciona aceleración de hardware para las familias de algoritmos SHA1, SHA2 y MD5:
[Sun_SPARC_T4-2]root@solaris:~# isainfo -v
64-bit sparcv9 applications
crc32c cbcond pause mont mpmul sha512 sha256 sha1 md5 camellia kasumi
des aes ima hpc vis3 fmaf asi_blk_init vis2 vis popc
root@solaris:~#
Si el host de Solaris es un sistema x86/64, admitirá la aceleración de hardware SHA-1 si la salida del comando isainfo -v incluye el juego de instrucciones ssse3 (Supplemental Streaming SIMD Extensions 3).
En el ejemplo, el host Sun X3-2 admite la aceleración de hardware de resúmenes SHA-1:
[Sun_X3-2]root@solaris:~# isainfo -v
64-bit amd64 applications
avx xsave pclmulqdq aes sse4.2 sse4.1 ssse3 popcnt tscp ahf cx16 sse3
sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu
root@solaris:~#
Al almacenar archivos que ya están asociados con resúmenes de mensajes, realice lo siguiente.
Inicie sesión en el host del sistema de archivos como root:
root@solaris:~#
En el símbolo del sistema, introduzca el comando ssum -a algorithm -h digest -G [-u]filename, donde:
-a algorithm identifica la función hash criptográfica que debe utilizar el sistema de archivos al validar el archivo con el resumen de mensaje proporcionado.
-h digest identifica el resumen de mensaje que debe utilizar el sistema de archivos al validar el archivo.
-G especifica una validación inmediata. El sistema de archivos configura el atributo de archivo hash en el valor del resumen de mensaje proporcionado, calcula de forma independiente un resumen de mensaje para el archivo y compara el resultado con el valor almacenado. Si los resúmenes proporcionados y calculados coinciden, el sistema de archivos configura el atributo validated para el archivo. A continuación, configura el atributo generate de modo que la validez se compruebe nuevamente cuando vuelve a almacenarse el archivo.
-u configura el atributo de archivo use (opcional). Cuando se almacena provisionalmente este archivo, el sistema de archivos vuelve a calcular el resumen y valida el resultado con el valor almacenado en el atributo hash.
filename es la ruta y el nombre del archivo.
En el ejemplo, se proporciona un resumen SHA256 y se solicita al sistema de archivos que vuelva a calcular inmediatamente el resumen y valide el valor de resumen para el archivo data10 con el valor proporcionado. Cuando se comprueban los atributos de archivo con el comando sls -D -h data10, se observa que se configuraron los atributos de archivo generate y validated, que el atributo algorithm se configuró en SHA-256 y que el valor de resumen se calculó y se almacenó en el atributo hash.
root@solaris:~# ssum -h f03ce01b3828...f7459503007e -a sha256 -g data10 root@solaris:~# sls -D -h data10 data10: mode: -rw-r--r-- links: 1 owner: root group: root length: 14975 admin id: 0 inode: 90217.1 project: user.root(1) access: Jul 16 16:14 modification: Jul 16 16:14 changed: Jul 16 16:15 attributes: Jul 16 16:14 creation: Jul 16 16:14 residence: Jul 16 16:14 checksum: generate validated algorithm: SHA-256 hash: f03ce01b3828...f7459503007e root@solaris:~#
Cuando sea necesario, edite el archivo como lo haría normalmente.
En el ejemplo, se modifica un archivo denominado data10m desde que se almacenó por última vez. El comando sls -D -h muestra que el indicador S (desactualizado) fue configurado en ambas copias, ya que ninguna refleja los cambios más recientes. Cuando se comprueba el valor de resumen SHA-256 para el archivo modificado con el comando de Solaris digest, se observa que el atributo hash del archivo también almacena un valor de resumen desactualizado:
root@solaris:~# sls -D -h data10m data10m: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) copy 1: S----- Jul 17 16:47 dd.1 dk diskarchive f221 copy 2: S----- Jul 20 11:31 a8d.1 li VOL002 access: Jul 20 11:32 modification: Jul 20 11:31 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 17 16:36 checksum: generate algorithm: SHA-256 hash: f03ce01b3828...f7459503007e root@solaris:~# digest -a sha256 data10m 56c55bb421cc...71ac2ac0b7b0 root@solaris:~#
Si es necesario, puede cambiar los atributos de resumen de un archivo modificado antes de volver a almacenarlo.
En el ejemplo, se cambia el algoritmo de resumen de SHA256 a SHA1, con efecto inmediato:
root@solaris:~# ssum -a sha1 -G data10m root@solaris:~# sls -D -h data10m data10m: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) release -a; copy 1: S----- Jul 20 13:00 e0.1 dk diskarchive f224 copy 2: S----- Jul 20 13:05 a93.1 li VOL002 access: Jul 20 16:39 modification: Jul 20 16:39 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 20 16:29 checksum: generate validated algorithm: SHA-1 hash: 92003525f0f8...53e29d0718c8 root@solaris:~#
De lo contrario, espere a que el sistema de archivos almacene el archivo modificado y actualice automáticamente los atributos relacionados con el resumen.
Cuando se almacena un archivo modificado, el sistema de archivos vuelve a calcular el valor de resumen, almacena el nuevo valor en el atributo hash y configura el indicador S (desactualizado) en las copias almacenadas de versiones anteriores del archivo. En el ejemplo, se edita el archivo data10m sin modificar los atributos de resumen. El archivador creó una nueva copy 1 en el disco, según lo programado, y actualizó el atributo hash. Una copia del archivo no modificado permanece en la cinta, con el indicador S (desactualizado), hasta el momento en que el archivador crea copy 2:
root@solaris:~# sls -D -h data10m data10m: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) copy 1: ------ Jul 17 16:47 dd.1 dk diskarchive f221 copy 2: S----- Jul 20 11:31 a8d.1 li VOL002 access: Jul 20 11:32 modification: Jul 20 11:31 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 17 16:36 checksum: generate algorithm: SHA-256 hash: 56c55bb421cc...71ac2ac0b7b0
Para generar un resumen para un archivo y activar la validación de archivos, realice lo siguiente:
Inicie sesión en el host del sistema de archivos como root:
root@solaris:~#
En el símbolo del sistema, introduzca el comando ssum -a algorithm -g|G [-u] filename, donde:
-a algorithm especifica la función hash criptográfica que utilizará el sistema de archivos al generar un resumen de mensaje para el archivo.
-g configura el atributo de archivo generate para el archivo. La primera vez que se almacena el archivo, el sistema de archivos calcula un resumen de mensaje. Cuando se vuelve a almacenar el archivo, el sistema de archivos vuelve a calcular el resumen y valida el resultado con el valor almacenado.
-G configura los atributos de archivo generate y validate para el archivo. El sistema de archivos calcula inmediatamente un resumen de mensaje y almacena el resultado en el atributo hash. Cuando se almacena el archivo, el sistema de archivos vuelve a calcular el resumen y valida el resultado con el valor almacenado.
-u configura el atributo de archivo use (opcional). Cuando se almacena provisionalmente este archivo, el sistema de archivos vuelve a calcular el resumen y valida el resultado con el valor almacenado en el atributo hash.
filename es la ruta y el nombre del archivo.
En el ejemplo, se solicita al sistema de archivos que use el algoritmo SHA256 para calcular el resumen para el archivo data11 antes de almacenarlo. Cuando se comprueban los atributos de archivo con el comando sls -D -h data10, se observa que, para cada archivo, se configuró el atributo de archivo generate y el atributo algorithm se configuró en SHA-256. Dado que el archivo aún no se almacenó, todavía no se calculó el valor de resumen ni se lo almacenó en el atributo hash:
root@solaris:~# ssum -a sha256 -g data11 root@solaris:~# sls -D -h data11 data11: mode: -rw-r--r-- links: 1 owner: root group: root length: 14975 admin id: 0 inode: 90218.1 project: user.root(1) access: Jul 16 16:14 modification: Jul 16 16:14 changed: Jul 16 16:22 attributes: Jul 16 16:14 creation: Jul 16 16:14 residence: Jul 16 16:14 checksum: generate algorithm: SHA-256 hash: root@solaris:~#
Cuando sea necesario, edite el archivo como lo haría normalmente.
En el ejemplo, se modifica un archivo denominado data11m desde que se almacenó por última vez. El comando sls -D -h muestra que el indicador S (desactualizado) fue configurado en ambas copias, ya que ninguna refleja los cambios más recientes. Cuando se comprueba el valor de resumen SHA-256 para el archivo modificado con el comando de Solaris digest, se observa que el atributo hash del archivo también almacena un valor de resumen desactualizado:
root@solaris:~# sls -D -h data11m data11m: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) copy 1: S----- Jul 17 16:47 dd.1 dk diskarchive f221 copy 2: S----- Jul 20 11:31 a8d.1 li VOL002 access: Jul 20 11:32 modification: Jul 20 11:31 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 17 16:36 checksum: generate algorithm: SHA-256 hash: f03ce01b3828...f7459503007e root@solaris:~# digest -a sha256 data11m 56c55bb421cc...71ac2ac0b7b0 root@solaris:~#
Si es necesario, puede cambiar los atributos de resumen de un archivo modificado antes de volver a almacenarlo.
En el ejemplo, se cambia el algoritmo de resumen de SHA256 a SHA1, con efecto inmediato:
root@solaris:~# ssum -a sha1 -G data11m root@solaris:~# sls -D -h data11m data11m: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) release -a; copy 1: S----- Jul 20 13:00 e0.1 dk diskarchive f224 copy 2: S----- Jul 20 13:05 a93.1 li VOL002 access: Jul 20 16:39 modification: Jul 20 16:39 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 20 16:29 checksum: generate validated algorithm: SHA-1 hash: 92003525f0f8...53e29d0718c8 root@solaris:~#
De lo contrario, espere a que el sistema de archivos almacene el archivo modificado y actualice automáticamente los atributos relacionados con el resumen.
Cuando se almacena un archivo modificado, el sistema de archivos vuelve a calcular el valor de resumen, almacena el nuevo valor en el atributo hash y configura el indicador S (desactualizado) en las copias almacenadas de versiones anteriores del archivo.
En el ejemplo, se edita el archivo data11m sin modificar los atributos de resumen. El archivador creó una nueva copy 1 en el disco, según lo programado, y actualizó el atributo hash. Una copia del archivo no modificado permanece en la cinta, con el indicador S (desactualizado), hasta el momento en que el archivador crea copy 2:
root@solaris:~# sls -D -h data11m mdata11: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90307.1 project: user.root(1) copy 1: ------ Jul 17 16:47 dd.1 dk diskarchive f221 copy 2: S----- Jul 20 11:31 a8d.1 li VOL002 access: Jul 20 11:32 modification: Jul 20 11:31 changed: Jul 17 16:37 attributes: Jul 17 16:36 creation: Jul 17 16:36 residence: Jul 17 16:36 checksum: generate algorithm: SHA-256 hash: 56c55bb421cc...71ac2ac0b7b0
Para generar un resumen de forma recursiva y configurar los atributos de validación para todos los archivos de un directorio, realice lo siguiente:
Inicie sesión en el host del sistema de archivos como root:
root@solaris:~#
En el símbolo del sistema, introduzca el comando ssum -a algorithm -g|G [-u] -r directoryname, donde:
-a algorithm especifica la función hash criptográfica que utilizará el sistema de archivos al generar resúmenes de mensajes.
-g configura el atributo de archivo generate para cada archivo. La primera vez que se almacena un archivo, el sistema de archivos calcula un resumen de mensaje para el archivo. Cuando se vuelve a almacenar el archivo, el sistema de archivos vuelve a calcular el resumen y valida el resultado con el valor almacenado.
-G configura los atributos de archivo generate y validate para cada archivo. El sistema de archivos calcula inmediatamente un resumen de mensaje y almacena el resultado en el atributo hash. Cuando se almacena el archivo, el sistema de archivos vuelve a calcular el resumen y valida el resultado con el valor almacenado.
-u configura el atributo de archivo use (opcional). Cuando el archivo se almacena provisionalmente, el sistema de archivos vuelve a calcular el resumen y valida el resultado con el valor almacenado.
-r aplica de forma recursiva el comando a todos los archivos en el directorio especificado.
directoryname es la ruta y el nombre del directorio.
En el primer ejemplo, se indica al sistema de archivos que use el algoritmo SHA256 para calcular el resumen para los archivos del directorio datasetA antes de almacenarlos. Cuando se comprueban los atributos de archivo con el comando sls -D -h datasetA, se observa que, para cada archivo, se configuró el atributo de archivo generate y el atributo algorithm se configuró en SHA-256. Dado que los archivos aún no se almacenaron, todavía no se calcularon los valores de resumen ni se los almacenó en el atributo hash:
root@solaris:~# ssum -a sha256 -g -r datasetA root@solaris:~# sls -D -h datasetA datasetA/pdata0: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90232.1 project: user.root(1) access: Jul 16 16:47 modification: Jul 16 16:47 changed: Jul 16 16:47 attributes: Jul 16 16:47 creation: Jul 16 16:47 residence: Jul 16 16:47 checksum: generate algorithm: SHA-256 hash: ... datasetA/pdata20: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90234.1 project: user.root(1) access: Jul 16 16:47 modification: Jul 16 16:47 changed: Jul 16 16:47 attributes: Jul 16 16:47 creation: Jul 16 16:47 residence: Jul 16 16:47 checksum: generate algorithm: SHA-256 hash: ... root@solaris:~#
En el segundo ejemplo, se indica al sistema de archivos que use el algoritmo SHA256 para calcular inmediatamente el resumen para todos los archivos del directorio datasetB antes de almacenarlos. Cuando se comprueban los atributos de archivo con el comando sls -D -h datasetB, se observa que, para cada archivo, se configuraron los atributos de archivo generate y validated, que el atributo algorithm se configuró en SHA-256 y que el valor de resumen se calculó y se almacenó en el atributo hash.
root@solaris:~# ssum -a sha256 -G -r datasetB root@solaris:~# sls -D -h datasetB datasetB/qdata0: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90232.1 project: user.root(1) access: Jul 16 16:47 modification: Jul 16 16:47 changed: Jul 16 16:47 attributes: Jul 16 16:47 creation: Jul 16 16:47 residence: Jul 16 16:47 checksum: generate validated algorithm: SHA-256 hash: 4d2800eb82b3...520341edde95 ... datasetB/qdata12: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90234.1 project: user.root(1) access: Jul 16 16:47 modification: Jul 16 16:47 changed: Jul 16 16:47 attributes: Jul 16 16:47 creation: Jul 16 16:47 residence: Jul 16 16:47 checksum: generate validated algorithm: SHA-256 hash: 5b057f1b7b48...88c590d47dec ... root@solaris:~#
Si es necesario, puede validar un archivo antes de almacenarlo provisionalmente en la caché de disco para su uso. Siga estos pasos:
Inicie sesión en el host del sistema de archivos como root:
root@solaris:~#
En el símbolo del sistema, introduzca el comando ssum -u [-a algorithm [-h digest] -g|G] filename, donde:
-u especifica la validación anterior al almacenamiento provisional mediante la configuración del atributo de archivo use. Cuando se configura el atributo use para un archivo, el sistema de archivos no volverá a copiar el archivo desde el medio de archivo a la caché de disco hasta que haya generado un resumen de mensaje y validado correctamente el resultado con el valor almacenado en el atributo hash del archivo.
-a algorithm, -h digest y -g|G son parámetros opcionales que configuran los algoritmos algorithm, hash y generate requeridos en el archivo si los atributos no se configuraron anteriormente.
filename es la ruta y el nombre del archivo.
En el ejemplo, ya se activó la validación para el archivo data102. Como muestra el comando sls -D -h data102, se configuraron los atributos de archivo generate y validated, el atributo algorithm se configuró en SHA-256 y el valor de resumen se calculó y se almacenó en el atributo hash:
root@solaris:~# ssum -a sha256 -F data102 root@solaris:~# sls -D -h data102 data102: mode: -rw-r--r-- links: 1 owner: root group: root length: 14979 admin id: 0 inode: 90264.1 project: user.root(1) access: Jul 16 17:34 modification: Jul 16 17:34 changed: Jul 16 17:34 attributes: Jul 16 17:34 creation: Jul 16 17:34 residence: Jul 16 17:34 checksum: generate validated algorithm: SHA-256 hash: baae932ce1cf...93166a2e36b5 root@solaris:~#
Por lo tanto, se puede configurar el atributo use para asegurarse de que el sistema de archivos valide el archivo antes del almacenamiento provisional. El comando sls -D -h data102 muestra que el atributo use está ahora configurado:
root@solaris:~# ssum -u data102 root@solaris:~# sls -D -h data102 data102: mode: -rw-r--r-- links: 1 owner: root group: root length: 14979 admin id: 0 inode: 90264.1 project: user.root(1) access: Jul 16 17:34 modification: Jul 16 17:34 changed: Jul 16 17:34 attributes: Jul 16 17:34 creation: Jul 16 17:34 residence: Jul 16 17:34 checksum: generate use validated algorithm: SHA-256 hash: baae932ce1cf...93166a2e36b5 root@solaris:~#
Si un archivo no se convirtió en inmutable y aún no se almacenó, puede cambiar los atributos de validación y resumen de mensajes mediante el procedimiento que se describe a continuación.
Inicie sesión en el host del sistema de archivos como root:
root@solaris:~#
Si es necesario, cambie el algoritmo de resumen. En el símbolo del sistema, introduzca el comando ssum -a newalgorithm filename, donde:
-a newalgorithm especifica la función hash criptográfica que reemplaza al algoritmo de resumen antes especificado.
filename es la ruta y el nombre del archivo.
En el ejemplo, nuestras políticas de conservación requieren la función SHA256 altamente resistente a colisiones. Sin embargo, como muestra el comando sls -D -h, se especificó involuntariamente el algoritmo SHA1 al configurar los atributos de resumen del archivo data319. Dado que el archivo aún no se almacenó, se puede cambiar correctamente el algoritmo a SHA256:
root@solaris:~# sls -D -h data319 data319: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90301.1 project: user.root(1) access: Jul 17 15:27 modification: Jul 17 15:27 changed: Jul 17 15:28 attributes: Jul 17 15:27 creation: Jul 17 15:27 residence: Jul 17 15:27 checksum: generate algorithm: SHA-1 hash: root@solaris:~# ssum -a sha256 data319 root@solaris:~# sls -D -h data319 data319: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90301.1 project: user.root(1) access: Jul 17 15:27 modification: Jul 17 15:27 changed: Jul 17 15:28 attributes: Jul 17 15:27 creation: Jul 17 15:27 residence: Jul 17 15:27 checksum: generate algorithm: SHA-256 hash: root@solaris:~#
Si es necesario, borre los atributos de resumen y restaure la configuración por defecto del archivo. En el símbolo del sistema, introduzca el comando ssum -d filename, donde:
-d restablece los atributos de resumen de archivo a los valores por defecto.
filename es la ruta y el nombre del archivo.
En el ejemplo, no se tenía la intención de configurar el resumen de mensajes y la validación para el archivo data44. Sin embargo, como muestra el comando sls -D -h, se lo hizo involuntariamente. Dado que el archivo aún no se almacenó, se pueden borrar correctamente generate y use, los atributos que controlan la validación de resumen durante el archivado y el almacenamiento provisional. Los datos en los atributos validated, algorithm y hash permanecen, pero no afectan el comportamiento del sistema de archivos:
root@solaris:~# sls -D -h data44 data44: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90292.1 project: user.root(1) access: Jul 17 14:58 modification: Jul 17 14:57 changed: Jul 17 14:58 attributes: Jul 17 14:57 creation: Jul 17 14:57 residence: Jul 17 14:57 checksum: generate use validated algorithm: SHA-256 hash: 3b4b15f8f69c...bae62c7e7568 root@solaris:~# ssum -d data44 root@solaris:~# sls -D -h data44 data44: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90292.1 project: user.root(1) access: Jul 17 14:58 modification: Jul 17 14:57 changed: Jul 17 14:58 attributes: Jul 17 14:57 creation: Jul 17 14:57 residence: Jul 17 14:57 checksum: validated algorithm: SHA-256 hash: 3b4b15f8f69c...bae62c7e7568 root@solaris:~#
Si es necesario, restablezca los atributos de validación y resumen de mensajes requeridos antes de almacenar el archivo. En el símbolo del sistema, introduzca el comando ssum con las opciones y el nombre de archivo adecuados.
En el ejemplo, se decide volver a activar el resumen de mensajes en el archivo qndat44 y validar los resúmenes antes del archivado. Sin embargo, no es necesaria la validación antes del almacenamiento provisional. Por lo tanto, se restaura el atributo generate, pero no el atributo use:
root@solaris:~# ssum -g data44 root@solaris:~# sls -D -h data44 data44: mode: -rw-r--r-- links: 1 owner: root group: root length: 14983 admin id: 0 inode: 90292.1 project: user.root(1) access: Jul 17 14:58 modification: Jul 17 14:57 changed: Jul 17 14:58 attributes: Jul 17 14:57 creation: Jul 17 14:57 residence: Jul 17 14:57 checksum: generate validated algorithm: SHA-256 hash: 3b4b15f8f69c...bae62c7e7568 root@solaris:~#
Los requisitos de conservación frecuentemente requieren mecanismos que garantizan la corrección de archivos. El archivo debe impedir que se produzcan cambios y probar que esos cambios no ocurrieron. Para la corrección, los sistemas de archivos de almacenamiento de Oracle HSM combinan los resúmenes de mensajes y los atributos de archivo relacionados con el resumen antes descritos con atributos adicionales que hacen que el archivo sea inmutable. Una vez que un archivo se convirtió en inmutable, únicamente quienes tienen autoridad de superusuario pueden cambiar su estado. Si combina inmutabilidad con un sistema de archivos estricto de escritura única lectura múltiple (WORM), aun los superusuarios no podrán realizar cambios (para obtener detalles, consulte Descripción de los sistemas de archivos WORM).
Puede convertir un archivo en inmutable de una de las siguientes maneras:
Cómo proporcionar un resumen de mensaje y convertir un archivo en inmutable
Generación de un resumen de mensaje y conversión de un archivo en inmutable
Cuando deba asegurarse de que un archivo no se modifique tras la introducción en el archivo de almacenamiento, realice lo siguiente.
Inicie sesión en el host del sistema de archivos como root:
root@solaris:~#
En el símbolo del sistema, introduzca el comando ssum -a algorithm [-h digest] -F filename, donde:
-a algorithm identifica la función hash criptográfica que debe utilizar el sistema de archivos al validar el archivo con el resumen de mensaje proporcionado.
-h digest identifica el resumen de mensaje que debe utilizar el sistema de archivos al validar el archivo.
-F especifica una validación e inmutabilidad inmediatas, y configura los atributos de archivo fixity, generate, validated y use. El sistema de archivos calcula y valida inmediatamente un resumen de mensaje. Cuando el archivo se almacena provisional o permanentemente, el sistema de archivos vuelve a calcular y validar un resumen de mensaje.
filename es la ruta y el nombre del archivo.
En el ejemplo, se proporciona un resumen SHA256 y se indica al sistema de archivos que vuelva a calcular el resumen, valide el valor para el archivo data20 y convierta el archivo en inmutable. Cuando se comprueban los atributos de archivo con el comando sls -D -h data10, se observa que, para cada archivo, se configuraron los atributos de archivo de corrección, generate, use y validated, que el atributo algorithm se configuró en SHA-256 y que el valor de resumen se calculó y se almacenó en el atributo hash:
root@solaris:~# ssum -h bfaefde932cf...d450892eda63 -a sha256 -F data20 root@solaris:~# sls -D -h data20 data20: mode: -rw-r--r-- links: 1 owner: root group: root length: 14979 admin id: 0 inode: 90264.1 project: user.root(1) access: Jul 16 17:34 modification: Jul 16 17:34 changed: Jul 16 17:34 attributes: Jul 16 17:34 creation: Jul 16 17:34 residence: Jul 16 17:34 checksum: fixity generate use validated algorithm: SHA-256 hash: bfaefde932cf...d450892eda63 root@solaris:~#
Cuando almacene archivos que ya tienen resúmenes de mensajes asociados y deba asegurarse de que el archivo no se modifique tras la introducción en el archivo de almacenamiento, realice lo siguiente.
Inicie sesión en el host del sistema de archivos como root:
root@solaris:~#
En el símbolo del sistema, introduzca el comando ssum -a algorithm [-h digest] -F filename, donde:
-a algorithm identifica la función hash criptográfica que se utilizó para generar el resumen especificado en el parámetro -h digest.
-F configura los atributos de archivo fixity, generate, validated y use. El sistema de archivos calcula y valida inmediatamente un resumen de mensaje. Cuando el archivo se almacena provisional o permanentemente, el sistema de archivos vuelve a calcular y validar un resumen de mensaje.
filename es la ruta y el nombre del archivo.
En el ejemplo, se indica al sistema de archivos que calcule un resumen SHA256, valide el valor para el archivo data200 y convierta el archivo en inmutable. Cuando se comprueban los atributos de archivo con el comando sls -D -h data10, se observa que, para cada archivo, se configuraron los atributos de archivo fixity, generate, validated y use, que el atributo algorithm se configuró en SHA-256 y que el valor de resumen se calculó y se almacenó en el atributo hash:
root@solaris:~# ssum -a sha256 -F data200 root@solaris:~# sls -D -h data200 data200: mode: -rw-r--r-- links: 1 owner: root group: root length: 14979 admin id: 0 inode: 90264.1 project: user.root(1) access: Jul 16 17:34 modification: Jul 16 17:34 changed: Jul 16 17:34 attributes: Jul 16 17:34 creation: Jul 16 17:34 residence: Jul 16 17:34 checksum: fixity generate use validated algorithm: SHA-256 hash: efde93cc12cf...d496602e36dd root@solaris:~#
Para ver los atributos de corrección y resumen de mensaje de uno o varios archivos, utilice el comando de listado de directorios de Oracle HSM: sls. Realice lo siguiente.
Inicie sesión en el host del sistema de archivos como root:
root@solaris:~#
En el símbolo del sistema, introduzca el comando sls -D -h filename, donde:
-D especifica una visualización detallada de los atributos de archivo.
-h incluye el valor hash (resumen) en la visualización.
filename identifica uno o varios archivos por ruta y nombre.
En el ejemplo, se observan los atributos de resumen para el archivo data02 en los campos checksum y hash de la pantalla:
root@solaris:~# sls -D -h data02 data02: mode: -rw-r--r-- links: 1 owner: root group: root length: 14975 admin id: 0 inode: 90217.1 project: user.root(1) access: Jul 16 16:14 modification: Jul 16 16:14 changed: Jul 16 16:15 attributes: Jul 16 16:14 creation: Jul 16 16:14 residence: Jul 16 16:14 checksum: generate use validated algorithm: SHA-256 hash: f03ce01b3828...f7459503007e root@solaris:~#
El atributo hash almacena el resumen de mensaje para el archivo, f03ce01b3828...f7459503007e.
El atributo algorithm muestra que la función hash criptográfica SHA-256 generó el resumen de mensaje almacenado.
El atributo generate muestra que el sistema de archivos vuelve a calcular de forma independiente el resumen de mensaje y lo valida con el valor almacenado cada vez que se almacena el archivo.
El atributo use muestra que el sistema de archivos vuelve a calcular de forma independiente el resumen de mensaje y lo valida con el valor almacenado cada vez que el archivo se almacena provisionalmente.
El atributo validated muestra que el resumen de mensaje calculado de forma independiente coincidía con el valor almacenado en el atributo hash cuando se comprobó por última vez.
El atributo fixity aparece si el archivo se convirtió en inmutable.
Si es necesario por cuestiones legales o de archivado, puede crear archivos y directorios de escritura única lectura múltiple (WORM) en cualquier sistema de archivos de Oracle HSM configurado para admitirlos. Esta sección se centra en la descripción de los sistemas de archivos WORM y en las tareas específicas que deben realizarse al trabajar con archivos y directorios WORM, como:
Para obtener información sobre cómo activar la compatibilidad con WORM para un sistema de archivos, consulte la Guía de configuración e instalación de Oracle Hierarchical Storage Manager and StorageTek QFS.
Los sistemas de archivos de escritura única lectura múltiple (WORM) protegen datos al permitir que los usuarios conviertan los archivos a solo lectura durante todo un período de retención específico. Los sistemas de archivos de Oracle HSM activados para WORM admiten períodos de retención de archivos predeterminados y personalizados, inmutabilidad de rutas y datos y herencia de subdirectorio de la configuración WORM.
Según la configuración de los sistemas de archivos, puede utilizar uno o dos modos WORM de Oracle HSM:
modo de cumplimiento estándar (predeterminado)
modo de emulación
En un sistema de archivos montado según el modo WORM estándar, un usuario activa para WORM los directorios e inicia el período de retención de solo lectura para los archivos ejecutando el comando chmod 4000 path_name, donde path_name es la ruta y el nombre del archivo o el directorio. Esto configura el permiso setuid (configurar ID de usuario al momento de la ejecución) de UNIX. La configuración del permiso setuid en un archivo que también tiene el permiso execute es un riesgo de seguridad; por lo tanto, en modo WORM estándar, únicamente los archivos no ejecutables pueden convertirse a solo lectura.
En un sistema de archivos montado según el modo de emulación WORM, un usuario activa para WORM los directorios e inicia el período de retención de solo lectura para los archivos ejecutando el comando chmod 555 path_name, donde path_name es la ruta y el nombre de un archivo o directorio con permiso de escritura. Dado que el modo de emulación no requiere el permiso setuid, los archivos ejecutables pueden convertirse a solo lectura y se les puede asignar períodos de retención.
Los modos de emulación y estándar tienen una implementación WORM estricta y una implementación flexible menos restrictiva. Las implementaciones estrictas y flexibles no permiten cambios a los datos o las rutas después del inicio de la retención en un archivo o directorio. Ambas configuran el período de retención por defecto en 43.200 minutos (30 días). Sin embargo, la implementación flexible permite reducir algunas restricciones para los usuarios root.
Las implementaciones estrictas no permiten que nadie acorte el período de retención especificado ni suprima archivos o directorios antes del final del período de retención. Asimismo, tampoco permiten a nadie utilizar sammkfs para eliminar volúmenes que en la actualidad contienen archivos y directorios conservados. Por lo tanto, las implementaciones estrictas son ideales para cumplir con los requisitos legales, de conformidad reglamentaria y de conservación más exigentes.
Las implementaciones flexibles permiten a los usuarios root acortar períodos de retención, suprimir archivos y directorios y suprimir volúmenes mediante el comando sammkfs. Esto ofrece un alto nivel de protección contra la pérdida casual de datos y ofrece más flexibilidad al administrar sistemas de archivos y recursos de almacenamiento. Sin embargo, los sistemas de archivos que permiten que los superusuarios tengan este nivel de control posiblemente no cumplan estos requisitos de conformidad.
Puede crear enlaces fijos y flexibles para los archivos WORM. Solo puede crear enlaces fijos y flexibles que residen en un directorio que admite WORM. Después de crear un enlace fijo, tiene las mismas características de WORM que el archivo original. También se pueden establecer enlaces flexibles, pero un enlace flexible no puede utilizar las funciones de WORM. Se pueden crear enlaces flexibles para los archivos WORM en cualquier directorio en un sistema de archivos Oracle HSM.
Para obtener información completa sobre la creación y configuración de sistemas de archivos WORM, consulte la Guía de configuración e instalación de Oracle Hierarchical Storage Manager and StorageTek QFS en la Biblioteca de documentación del cliente.
Cuando activa para WORM un directorio, agrega compatibilidad para archivos WORM, pero no modifica de otra manera las características del directorio. Los usuarios pueden seguir creando y editando archivos dentro de un directorio activado para WORM y los directorios activados para WORM que no contienen archivos WORM pueden suprimirse. Para activar para WORM un directorio, realice lo siguiente:
Inicie sesión en el servidor del sistema de archivos.
user@solaris:~#
Observe si el directorio ya fue activado para WORM. Utilice el comando sls -Dd directory, donde directory es la ruta y el nombre del directorio. Busque el atributo worm-capable en la salida del comando.
Generalmente, los directorios estarán activados para WORM, ya que cuando un usuario activa para WORM un directorio, todos los directorios secundarios actuales y futuros heredan la capacidad WORM (para obtener información completa sobre el comando, consulte la página del comando man sls). En el primer ejemplo, se determina que el directorio de destino, /hsm/hsmfs1/records, ya está activado para WORM:
user@solaris:~# sls -Dd /hsm/hsmfs1/records/2013/ /hsm/hsmfs1/records/2013: mode: drwxr-xr-x links: 2 owner: root group: root length: 4096 admin id: 0 inode: 1048.1 project: user.root(1) access: Mar 3 12:15 modification: Mar 3 12:15 changed: Mar 3 12:15 attributes: Mar 3 12:15 creation: Mar 3 12:15 residence: Mar 3 12:15 worm-capable retention-period: 0y, 30d, 0h, 0m
Sin embargo, en el segundo ejemplo, se determina que el directorio de destino, /hsm/hsmfs1/documents, no está activado para WORM:
user@solaris:~# sls -Dd /hsm/hsmfs1/documents /hsm/hsmfs1/documents mode: drwxr-xr-x links: 2 owner: root group: root length: 4096 admin id: 0 inode: 1049.1 project: user.root(1) access: Mar 3 12:28 modification: Mar 3 12:28 changed: Mar 3 12:28 attributes: Mar 3 12:28 creation: Mar 3 12:28 residence: Mar 3 12:28
Si el directorio no está activado para WORM y si el sistema de archivos se montó con la opción de montaje worm_capable o worm_lite, active la compatibilidad con WORM con el comando de Solaris chmod 4000 directory-name, donde directory-name es la ruta y el nombre del directorio que alojará los archivos WORM.
El comando chmod 4000 configura el atributo setuid (configurar ID de usuario al momento de la ejecución) en el directorio y activa la compatibilidad con WORM estándar. En el ejemplo, se activa para WORM el directorio /hsm/hsmfs1/documents y se comprueba el resultado con sls -Dd. La operación se realiza correctamente y el directorio se activa para WORM:
user@solaris:~# chmod 4000 /hsm/hsmfs1/documents user@solaris:~# sls -Dd /hsm/hsmfs1/documents /hsm/hsmfs1/documents mode: drwxr-xr-x links: 2 owner: root group: root length: 4096 admin id: 0 inode: 1049.1 project: user.root(1) access: Mar 3 12:28 modification: Mar 3 12:28 changed: Mar 3 12:28 attributes: Mar 3 12:28 creation: Mar 3 12:28 residence: Mar 3 12:28 worm-capable retention-period: 0y, 30d, 0h, 0m
Si el directorio no está activado para WORM y si el sistema de archivos se montó con la opción de montaje worm_emul o emul_lite, active la compatibilidad con WORM con el comando de Solaris chmod 555 directory-name, donde directory-name es la ruta y el nombre del directorio que alojará los archivos WORM.
El comando chmod 555 elimina los permisos de escritura del directorio y activa la compatibilidad con la emulación WORM. En el ejemplo, se activa para WORM el directorio /hsm/hsmfs1/documents y se comprueba el resultado con el comando sls -Dd. La operación se realiza correctamente y el directorio se activa para WORM:
user@solaris:~# chmod 555 /hsm/hsmfs1/documents user@solaris:~# sls -Dd /hsm/hsmfs1/documents /hsm/hsmfs1/documents mode: drwxr-xr-x links: 2 owner: root group: root length: 4096 admin id: 0 inode: 1049.1 project: user.root(1) access: Mar 3 12:28 modification: Mar 3 12:28 changed: Mar 3 12:28 attributes: Mar 3 12:28 creation: Mar 3 12:28 residence: Mar 3 12:28 worm-capable retention-period: 0y, 30d, 0h, 0m
Cuando activa la protección WORM en un archivo dentro de un directorio activado para WORM, el sistema de archivos ya no permite modificaciones de los datos de archivos o la ruta hacia los datos hasta que caduca el período de retención. Por lo tanto, debe tener cuidado. Para activar la protección WORM, realice lo siguiente:
Inicie sesión en el servidor del sistema de archivos.
user@solaris:~#
Si necesita conservar el archivo durante un período diferente al predeterminado para el sistema de archivos, especifique el tiempo de retención necesario y cambie el horario de acceso del archivo. Utilice el comando de Solaris touch -a -texpiration-date path-name, donde:
expiration-date es una cadena de numerales compuesta de un año de cuatro dígitos, un mes de dos dígitos, un día del mes de dos dígitos, una hora del día de dos dígitos, un minuto dentro de la hora de dos dígitos y, opcionalmente, un segundo dentro del minuto de dos dígitos.
path-name es la ruta y el nombre del archivo.
Recuerde que las utilidades UNIX de Oracle Solaris como touch no pueden extender el período de retención más allá de las 10:14 PM del 18/01/2038. Estas utilidades usan números de 32 bits firmados que representan la hora en segundos a partir del 01/01/1970. Por lo tanto, utilice un período de retención predeterminado si necesita conservar archivos más allá de esta fecha de corte.
En el ejemplo, se configura el período de retención para el archivo para que caduque en cuatro años, el 4 de octubre de 2019 a las 11:59 a. m:
user@solaris:~# touch -a -t201910141159 /hsm/hsmfs1/plans/master.odt
Si el sistema de archivos se montó con la opción de montaje worm_capable o worm_lite, active la protección WORM con el comando de Solaris chmod 4000 path-name, donde path-name es la ruta y el nombre del archivo.
El comando chmod 4000 configura el atributo setuid (configurar ID de usuario al momento de la ejecución) en el archivo especificado. La configuración de este atributo en un archivo ejecutable no es segura. Por lo tanto, si el sistema de archivos se montó con la opción de montaje worm_capable oworm_lite, no puede configurar protecciones WORM en los archivos que tienen el permiso execute de UNIX.
En el ejemplo, se activa la protección WORM para el archivo master.odt. Se comprueba el resultado con sls -D. Observe que el atributo retention ahora está configurado en active y que retention-period está configurado en cuatro años:
user@solaris:~# chmod 4000 /hsm/hsmfs1/plans/master.odt user@solaris:~# sls -Dd /hsm/hsmfs1/plans/master.odt /hsm/hsmfs1/plans/master.odt: mode: -r-xr-xr-x links: 1 owner: root group: root length: 104 admin id: 0 inode: 1051.1 project: user.root(1) access: Mar 4 2018 modification: Mar 3 13:14 changed: Mar 3 13:16 retention-end: Apr 2 14:16 2014 creation: Mar 3 13:16 residence: Mar 3 13:16 retention: active retention-period: 4y, 0d, 0h, 0m
Si el sistema de archivos se montó con la opción de montaje worm_emul o emul_lite, active la protección WORM con el comando de Solaris chmod 555 path-name, donde path-name es la ruta y el nombre del archivo.
El comando chmod 555 elimina los permisos de escritura del directorio. Por lo tanto, si es necesario, puede proteger con WORM los archivos ejecutables. En el ejemplo, activamos la retención de WORM para el archivo master-plan.odt. Se comprueba el resultado con sls -D. Observe que el atributo retention ahora está configurado en active y que retention-period está configurado en cuatro años:
user@solaris:~# chmod 555 /hsm/hsmfs1/plans/master.odt user@solaris:~# sls -Dd /hsm/hsmfs1/plans/master.odt /hsm/hsmfs1/plans/master.odt: mode: -r-xr-xr-x links: 1 owner: root group: root length: 104 admin id: 0 inode: 1051.1 project: user.root(1) access: Mar 4 2018 modification: Mar 3 13:14 changed: Mar 3 13:16 retention-end: Apr 2 14:16 2014 creation: Mar 3 13:16 residence: Mar 3 13:16 retention: active retention-period: 4y, 0d, 0h, 0m
Para buscar y enumerar los archivos WORM que cumplen con los criterios de búsqueda especificados, utilice el comando sfind. Siga estos pasos:
Inicie sesión en el servidor del sistema de archivos.
user@solaris:~#
Para enumerar los archivos protegidos por WORM y retenidos activamente, utilice el comando sfind starting-directory -ractive, donde starting-directory es la ruta y el nombre del directorio donde desea que comience el proceso de enumeración.
user@solaris:~# sfind /hsm/hsmfs1/ -ractive /hsm/hsmfs1/documents/2013/master-plan.odt /hsm/hsmfs1/documents/2013/schedule.ods /samma1/records/2013/progress/report01.odt /samma1/records/2013/progress/report02.odt /samma1/records/2013/progress/report03.odt ... user@solaris:~#
Para enumerar los archivos protegidos por WORM para los cuales ha caducado el período de retención, utilice el comando sfind starting-directory -rover, donde starting-directory es la ruta y el nombre del directorio donde desea que comience el proceso de enumeración.
user@solaris:~# sfind /hsm/hsmfs1/ -rover /samma1/documents/2007/master-plan.odt /samma1/documents/2007/schedule.ods user@solaris:~#
Para enumerar los archivos protegidos por WORM para los cuales el período de retención caducará tras una fecha y hora especificadas, utilice el comando sfind starting-directory -rafter expiration-date, donde:
starting-directory es la ruta y el nombre del directorio donde desea que comience el proceso de enumeración.
expiration-date es una cadena de numerales compuesta de un año de cuatro dígitos, un mes de dos dígitos, un día del mes de dos dígitos, una hora del día de dos dígitos, un minuto dentro de la hora de dos dígitos y, opcionalmente, un segundo dentro del minuto de dos dígitos.
En el ejemplo, enumeramos los archivos para los cuales el período de retención caduca después del 1° de enero de 2015, un minuto después de la medianoche:
user@solaris:~# sfind /hsm/hsmfs1/ -rafter 201501010001 /hsm/hsmfs1/documents/2013/master-plan.odt user@solaris:~#
Para enumerar los archivos protegidos por WORM que deben permanecer en el sistema de archivos durante al menos una cantidad de tiempo especificada, utilice el comando sfind starting-directory -rremain time-remaining, donde:
starting-directory es la ubicación en el árbol de directorios en los que la búsqueda se inicia.
time-remaining es una cadena de números enteros no negativos asociados con las siguientes unidades de tiempo: y para años, d para días, h para horas y m para minutos.
En el ejemplo, se encuentran todos los archivos en el directorio /hsm/hsmfs1/ que se conservarán durante al menos tres años más:
user@solaris:~# sfind /hsm/hsmfs1/ -rremain 3y /hsm/hsmfs1/documents/2013/master-plan.odt user@solaris:~#
Para enumerar los archivos protegidos por WORM que deben permanecer en el sistema de archivos durante más de una cantidad de tiempo especificada, utilice el comando sfind starting-directory -rlonger time, donde:
starting-directory es la ubicación en el árbol de directorios en los que la búsqueda se inicia.
time-remaining es una cadena de números enteros no negativos asociados con las siguientes unidades de tiempo: y para años, d para días, h para horas y m para minutos.
En el ejemplo, se encuentran todos los archivos en el directorio /hsm/hsmfs1/ que se conservarán durante más de tres años y noventa días:
user@solaris:~# sfind /hsm/hsmfs1/ -rremain 3y90d /hsm/hsmfs1/documents/2013/master-plan.odt user@solaris:~#
Para enumerar los archivos protegidos por WORM que deben permanecer en el sistema de archivos de forma permanente, utilice el comando sfind starting-directory -rpermanent.
En el ejemplo, se observa que ninguno de los archivos en el directorio /samqfs1/ se conservará de forma permanente:
user@solaris:~# sfind /hsm/hsmfs1/ -rpermanent user@solaris:~#