330 likes | 582 Views
Administración Documentum 6.5. Backup y Restore. Objetivos del Módulo. Efectuar un backup frío del repositorio Restaurar el repositorio de un backup frío Configurar un backup de High Availability y estrategia de recuperación.
E N D
Administración Documentum 6.5 Backup y Restore
Objetivos del Módulo • Efectuar un backup frío del repositorio • Restaurar el repositorio de un backup frío • Configurar un backup de High Availability y estrategia de recuperación. • Saber cuándo una solución de High Availability es necesaria en vez de una solución Hot Standby
Los procedimientos de Backup y Restore/ recuperación de desastres varían en función de las necesidades del cliente. Este tema abarca Consideraciones generales de backup y recuperación Varios enfoques sobre backup y recuperación Backup frío y recuperación Backup caliente y recuperación Soluciones High Availability Soluciones Hot Standby (a veces llamadas soluciones “warm server”) Visión General Visión General Backup Frío Backup Caliente High Availability Hot Standby Full-Text Index Backup
¿Qué debería ser guardado? (1 de 3) • Archivos de datos RDBMS • La base de datos almacena información sobre todos los objetos del repositorio • Los objetos del repositorio contienen metadatos que apuntan a los archivos de contenido en el file system • Almacenamiento de contenido • Back up los directorios de almacenamiento de contenido y/o mirror los directorios de almacenamiento de contenido en un filesystem separado Cada uno de estos directorios representa un área de almacenamiento de contenidos – en otras palabras, una instancia del sub-tipo dm_store
¿Qué debería ser guardado? (2 de 3) • Archivos de configuración del repositorio • Por ejemplo: server.ini, webcache.ini • Archivos de índice Full-text • En lugar de salvar los archivos de índice full-text, se pueden reconstruir tras restaurar el repositorio • Cambiar el agente de indexación para ejecutar en modo de migración para re-indexar el contenido del repositorio • Dependiendo del tamaño de la indexación, reconstruir los archivos de índice full-text puede llevar horas (o más) • Los archivos de índice full-text residen en el index server • Los archivos de Documentum (mensualmente para ahorrar tiempo de re-instalación, en el caso de malfuncionamiento del sistema)
Es una buena idea hacer un back up periódico de los servidores de aplicaciones web que acceden al Content Server, especialmente antes y después de un cambio de versión en las aplicaciones Content Server ¿Qué debería ser guardado? (3 de 3) Otras Aplicaciones WDK Webtop DA WDK Servidor de Aplicaciones Web
Previniendo Repositorios Corruptos • Para prevenir corrupción de los repositorios, hacer siempre back up de la bbdd ANTES de hacer back up de las áreas de almacenamiento de archivos • Caso 1: La entrada de objetos en la bbdd hace referencias a un archivo en el file system que no existe • El repositorio está corrupto • Caso 2: Un archivo en el file system no está referenciado por ningún objeto en la bbdd • El repositorio no está corrupto • El archivo se puede eliminar después de usar dmFilescan o dmClean
Backup frío • Visión General • Backup Frío • Backup Caliente • High Availability • Hot Standby • Full-Text Index Backup • Se refiere a salvar archivos y datos a guardar mientras el repositorio está parado • Ventajas • Coste. Típicamente el coste es sólo el precio del software de backup y los medios de backup (y el hardware asociado al backup, como las cintas) • No requiere mantener una plataforma duplicada en reserva, como para hot standby y soluciones high availability • Normalmente es la solución más fácil • Desventajas • Puede ser el tiempo de ejecución, ya que el backup medio se hace típicamente en una unidad de cinta lenta • Mientras se hace el backup, el repositorio debe estar off-line • El tiempo de recuperación puede ir desde horas hasta días – probablemente inaceptable para un repositorio de tareas críticas
Procedimientos Generales de Backup Frío • Parar todo el software que trabaja con el Content Server • Parar el repositorio y la base de datos • Hacer que el Content Server no esté disponible para usuarios de red • Back up de la BBDD, usando utilidades de bases de datos • Back up cada área de almacenamiento de contenidos, usando utilidades estándar de backup de file system • Arrancar la BBDD • Arrancar el repositorio • Arrancar el software y los servicios que trabajan con el Content Server • Hacer que el Content Server esté disponible en la red
Procedimientos Generales de Restauración (Backup Frío) • Parar el software que trabaja con el Content Server • Parar el repositorio y la base de datos • Hacer que el Content Server no esté disponible para usuarios de red • Restaurar la bbdd, usando utilidades de bbdd • Restaurar cada área de almacenamiento de contenidos, usando utilidades de restauración estándar de filesystem • Iniciar el repositorio • Ejecutar el Consistency Checker para asegurar la integridad de los objetos del repositorio, y arreglar las posibles incidencias • Iniciar el software que trabaja con el Content Server • Hacer que el Content Server esté disponible en la red
Backup Caliente • Visión General • Backup Frío • Backup Caliente • High Availability • Hot Standby • Full-Text Index Backup • Salvar archivos y datos mientras el repositorio está funcionando • Ventajas • El repositorio no tiene que pararse durante el backup • Coste. Típicamente el coste es sólo el precio del software y los medios del backup (y el hardware asociado, como las cintas) • No requiere mantener una plataforma duplicada en reserva, como hot standby y soluciones de alta diponibilidad • Desventajas • Ejecución más lenta del Content Server durante el backup y la restauración • Puede ser el tiempo de ejecución, ya que el backup medio se hace típicamente en una unidad de cinta lenta • El tiempo de recuperación puede ir desde horas hasta días
Backups Calientes y Modos de BBDD • La base de Datos debe estar configurada para ejecutar backups calientes • Generalmente, esto significa configurar la BBDD para guardar (no re-usar/sobreescribir) los logs que contienen información de las transacciones realizadas • Estos logs pueden ser usados, si es necesario, para re-hacer las transacciones y restaurar la BBDD
Recomendaciones para los file systems • Usar Disk Mirroring o RAID (Redundant Array of Independent/Inexpensive Disks) para el file system: • No hay pérdidas si el contenido del disco del área de almacenamiento de contenidos falla • El backup utiliza discos en mirror, por lo que el rendimiento del acceso a los datos no se ve afectado durante el Backup. • Sin mirroring o RAID, será necesario hacer backups incrementales de file system tan frecuentemente como sea posible • SAN (storage area network) y NAS (network attached storage) • Pueden ser accedidos como un file system convencional (sin, por ejemplo, solicitar password para acceder) • Son transparente al sistema operativo y al entorno del Content Server
Procedimientos Generales de Backup Caliente • En el repositorio, poner todas las áreas de almacenamiento de contenido en modo de sólo lectura • Para cada área de almacenamiento, poner el atributo r_status a 2 (sólo lectura) • Hacer backup de la BBDD, usando utilidades de BBDD • Hacer backup de cada área de almacenamiento de contenidos, usando utilidades de backup de file system • Resetear todas las áreas de almacenamiento de contenido a sus opciones previas
Procedimientos Generales de Restauración (Backup Caliente) • Parar el software que trabaja con el Content Server • Parar el repositorio • Hacer que el Content Server no esté disponible para usuarios de red • Restaurar la BBDD, usando utilidades de BBDD • Restaurar cada área de almacenamiento de contenidos, usando utilidades de restauración estándar de file system • Iniciar el repositorio • Ejecutar el Consistency Checker para asegurar la integridad de los objetos del repositorio, y arreglar las posibles incidencias • Iniciar el software que trabaja con el Content Server • Hacer que el Content Server esté disponible en la red
Alta Disponibilidad • Visión General • Backup Frío • Backup Caliente • High Availability • Hot Standby • Full-Text Index Backup • Existe un repositorio de respaldo constantemente actualizado y listo para dar servicio si fuera necesario • Si el repositorio de producción se cae, el repositorio de respaldo puede ponerse en línea rápidamente sin pérdida de datos • Ventajas • La pérdida de datos puede ser eliminada • La transición desde el repositorio de producción erróneo al repositorio de respaldo es casi transparente a los usuarios finales • Desventajas • Coste. A través del repositorio duplicado, los sistemas en alta disponibilidad típicamente requieren hardware especializado • Típicamente requiere • Estrictos hardware y configuraciones software • El repositorio de respaldo está localizado adyacente al repositorio de producción
Monitorización de Procesos (1 de 3) • En un entorno de alta disponibilidad, frecuentemente se monitoriza el software para asegurarse de que todos los procesos están ejecutándose. • Desde la versión 5.3 SP1 del Content Server, se proporcionan un conjunto de scripts que monitorizan procesos para determinar si todo se está ejecutando adecuadamente • Los scripts son instalados cuando se crea una instalación del Content Server • Son lanzados por terceras aplicaciones
Monitorización de Procesos (2 de 3) • Existen scripts que monitorizan: • Content Server • Connection broker • Java method server • Index Agent • Deben ser ejecutados usando la cuenta del propietario de la instalación • Cada script devuelve: • Éxito (el proceso monitorizado está corriendo) como 0 ó • Fallo (el proceso monitorizado está parado) como un valor distinto de cero • Para información sobre cómo ejecutar los scripts, consulte Content Server Administration Guide, Appendix D
Monitorización de Procesos (3 de 3) • Los siguientes procesos no requieren un script separado: • dmbasic method server • ACS server • Workflow agent • agent_exec • El Content Server monitoriza estos procesos • Si alguno de estos procesos se para, el Content Server los reinicia automáticamente
Alta DisponibilidadProcedimientos de Backup y Restore • Los procedimientos de backup y restauración varían en función del proveedor • Consulte la documentación del proveedor para más detalles
Hot Standby • Visión General • Backup Frío • Backup Caliente • High Availability • Hot Standby • Full-Text Index Backup • Mantiene un repositorio de respaldo actualizado periódicamente y siempre listo, por si es necesario • Si el repositorio de producción se cae, el repositorio de respaldo se puede poner en línea rápidamente • La cantidad de datos perdidos depende de la frecuencia en la que el repositorio de respaldo se mantenga actualizado • Ventajas • La pérdida de datos se puede minimizar • Relativo a soluciones high availability • El coste es mucho menor • Es más fácil de configurar, mantener, y probar • El repositorio de respaldo no necesita estar cercano al de producción • Es más fácil de administrar que las soluciones de alta disponibilidad • Desventajas • La pérdida de datos nunca se elimina, aunque se minimiza
Construyendo una SoluciónHot Standby (1 de 2) • El administrador de la base de datos debe: • Copiar los logs de transacciones desde la BBDD del repositorio de producción a la BBDD del repositorio de respaldo • Sincronizar la BBDD del repositorio de respaldo con la BBDD del repositorio de producción • La frecuencia de dicha sincronización puede variar basándose en el rendimiento global del sistema • El rendimiento global del sistema es muy variable, dependiendo de los recursos globales y del uso BBDD (Repositorio de Respaldo) BBDD (Repositorio de Producción)
Filesystem BBDD 1 2 Construyendo una Solución Hot Standby (2 de 2) • IMPORTANTE: En una solución hot standby, la BBDD se debe re-crear primero; los archivos de contenido pueden ser traídos o modificados después • Para prevenir la corrupción del repositorio, la base de datos NUNCA debería ir por delante del filesystem • Copiar los archivos de contenido desde el repositorio de producción siempre después de que se copien y apliquen los logs de transacción de la base de datos
Procedimiento General de Backup (Hot Standby) • Copiar los logs de transacciones desde la BBDD del repositorio de producción a la BBDD del repositorio de respaldo. • Sincronizar la BBDD del repositorio de respaldo con la BBDD del repositorio de producción usando los logs de transacciones. • Copiar los archivos de contenido afectados desde el repositorio de producción al repositorio de respaldo.
Procedimiento General de Restauración (Hot Standby) • Asegurese de que los archivos de configuración (como server.ini, webcache.ini) han sido cambiados para reflejar los diferentes hostname/direcciones. • Reiniciar la bbdd del repositorio de respaldo. • Reiniciar el repositorio de respaldo. • Hacer que el Content Server esté disponible en la red.
Backup y Restauración: Puntos a Considerar (1 de 2) • Tamaño del Repositorio – afecta a la velocidad del backup y de la restauración • Variación de los datos – afectan a la frecuencia en la que los backups deben hacerse • El tamaño de la ventana para ejecutar los procedimientos de backup y restauración • La noche puede ser una hora adecuada para programar un backup • Tener en cuenta la ubicación física de las máquinas y de los usuarios - la noche en Norteamérica coincide con el día en Asia
Backup y Restauración: Puntos a Considerar (2 de 2) • La situación y las necesidades, por ejemplo: • El fail-over es esencial para el sistema y el dinero no es un problema • Considere una solución high availability • El dinero es limitado y los usuarios pueden tolerar unos cuántos minutos de pérdida de datos • Considere uns solución hot standby
Backup del Full-Text(1 de 2) • Visión General • Backup Frío • Backup Caliente • High Availability • Hot Standby • Full-Text Index Backup • Realizar un backup incremental del repositorio y sus metadatos a la vez que hacer el backup completo • Backup incremental del Index Server • Los datos de texto completo son dominados por unos pocos archivos de índices • Si el software de backup recoge los archivos cambiados completos (y no los bloques individuales que han cambiado) incluso si los cambios en el archivo fueron pequeños, se perderá tiempo tanto en backup como en restauración • Por lo tanto, los backups incrementales están mejor dotados con un software de backup que soporte cambios a nivel de bloque, como Legato NetWorker de EMC o NetBackup de Symantec
Backup del Full-Text(2 de 2) • Backup frío de instalación inicial • DOCUMENTUM/fulltext • Posteriores backups de datos • Fixml: DOCUMENTUM/data/fulltext/fixml • Index: DOCUMENTUM/data/fulltext/index • Archivos de Configuración: DOCUMENTUM/fulltext/IndexServer/etc • Otros datos: DOCUMENTUM/fulltext/IndexServer/data • El Index Server no soporta backup en caliente
Parar el Index Agent Parar el Index Server Hacer el backup Reiniciar el Index Server Reiniciar el Index Agent Procedimiento General de Backup Full Text Server • Visión General • Backup Frío • Backup Caliente • High Availability • Hot Standby • Full-Text Index Backup
Para soluciones de backup caliente, cuáles de las siguientes afirmaciones son ciertas El repositorio debe estar configurado para salvar logs que soporten información de las transacciones La base de datos debe estar configurada para salvar logs que soporten información de las transacciones Tanto el repositorio como la base de datos deben estar configuradas para salvar logs que soporten información de las transacciones Que debería guardarse primero: el file system o la base de datos? Verdadero/Falso: Un script de monitorización de procesos está disponible para el dmbasic Method Server. Comprueba tu Conocimiento