iseries Planificación de una estrategia de copia de seguridad y recuperación

Transcripción

1 iseries Planificación de una estrategia de copia de seguridad y recuperación

2

3 iseries Planificación de una estrategia de copia de seguridad y recuperación

4 Copyright International Business Machines Corporation 1998, Reserados todos los derechos.

5 Contenido Parte 1. Planificación de una estrategia de copia de seguridad y recuperación.. 1 Capítulo 1. Secuencia temporal para la copia de seguridad y la recuperación Capítulo 2. Tipos de anomalías comunes Anomalía de disco Anomalía del sistema Anomalía de alimentación Anomalía de programa o error humano Pérdida total del sistema Capítulo 3. Saber qué salar y con qué frecuencia Capítulo 4. Determinar el período para salar Estrategia de salar sencilla Estrategia de salar intermedia Salar objetos modificados Registrar por diario los objetos y salar los receptores de diario Estrategia de salar compleja Capítulo 5. Elección de las opciones de disponibilidad Conceptos de disponibilidad Gestión de diarios para la copia de seguridad y recuperación Gestión de diario entajas Gestión de diario costes y limitaciones Protección de ías de acceso Protección de ías de acceso gestionada por el sistema Registro por diario explícito de las ías de acceso Protección de ías de acceso entajas Protección de ías de acceso costes y limitaciones Sistemas duales Sistemas duales entajas Sistemas duales costes y limitaciones Comparación de las opciones de disponibilidad Registro por diario, protección por duplicación de disco y protección por paridad de dispositios 17 Opciones de disponibilidad por tipo de anomalía tiempo de recuperación Opciones de disponibilidad por tipo de anomalía frecuencia Capítulo 6. Prueba de la estrategia Capítulo 7. Plan para la recuperación ante siniestros plantilla Plan para la recuperación ante siniestros Copyright IBM Corp. 1998, 2001 iii

6 i iseries: Planificación de una estrategia de copia de seguridad y recuperación

7 Parte 1. Planificación de una estrategia de copia de seguridad y recuperación Los sistemas informáticos por lo general, y los seridores iseries 400 y AS/400 en concreto, son muy fiables. Podría utilizar su sistema durante meses o incluso años sin experimentar problemas que ocasionaran pérdidas de información del sistema. Sin embargo, al disminuir la frecuencia de los problemas en los sistemas, ha aumentado la repercusión potencial de los problemas. Las empresas dependen cada ez más de los sistemas informáticos y de la información almacenada en los mismos. Es posible que la información que hay su sistema no esté disponible en ninguna otra parte. Salar la información del sistema requiere tiempo y disciplina. Por qué hacerlo? Por qué emplear tiempo en planificar y ealuar? Porque podría tener un problema. Será necesario utilizar las copias de seguridad de la información. Todo sistema necesita restaurar toda la información o parte de ella en algún momento. Los temas siguientes le ayudarán a comprender cuándo será necesario hacer copias de seguridad de la información y por qué: Secuencia temporal para la copia de seguridad y la recuperación Tipos de anomalías comunes Una ez comprenda por qué necesita una estrategia para la copia de seguridad y la recuperación, estará preparado para empezar a planificar la estrategia. Siga estos pasos: 1. Saber qué salar y con qué frecuencia 2. Determinar el período para salar 3. Elegir las opciones de disponibilidad 4. Probar la estrategia La Plantilla de plan de recuperación frente a desastres también puede serle útil como recurso de planificación. Este tema contiene información sobre cómo planificar la estrategia y efectuar las elecciones que necesite al preparar el sistema para la copia de seguridad, la recuperación y la disponibilidad. Para obtener información sobre cómo llear a cabo las tareas relacionadas con estos temas, consulte la publicación Copia de seguridad y recuperación. Copyright IBM Corp. 1998,

8 2 iseries: Planificación de una estrategia de copia de seguridad y recuperación

9 Capítulo 1. Secuencia temporal para la copia de seguridad y la recuperación La secuencia temporal para la copia de seguridad y la recuperación empieza cuando sala información y finaliza cuando se recupera el sistema por completo tras una anomalía. Consulte esta secuencia temporal mientras lee esta información y toma decisiones. Las estrategias para salar y para la disponibilidad determinan estos elementos: Si puede completar satisfactoriamente cada paso del diagrama Cuánto tiempo tardará en completar cada paso A medida que lea, utilice el diagrama para desarrollar ejemplos específicos. Por ejemplo, el punto conocido (1) podría ser el domingo por la noche y el punto de la anomalía (2) el juees por la tarde. Cuánto tiempo se tardaría en oler al punto conocido? Cuánto tiempo tardará en llegar al punto actual (6)? Es posible conseguirlo con la estrategia de salar que ha planificado? Punto 1 Punto conocido (última operación de salar) Punto 2 Sucede un fallo Punto 3 Hardware disponible Punto 4 El sistema se ha recuperado tal y como estaba en el punto 1 Punto 5 El sistema se ha recuperado hasta el fallo del punto 2 Punto 6 El sistema está actualizado Actiidad en el sistema Reparacion de hardware o IPL La información se recupera desde la copia de seguridad Las transacciones desde punto 1 al punto 2 son recuperadas La actiidad de negocios desde el fallo en el punto 2 hasta la recuperación en el punto 5 se ha recuperado RZAJ Copyright IBM Corp. 1998,

10 4 iseries: Planificación de una estrategia de copia de seguridad y recuperación

11 Capítulo 2. Tipos de anomalías comunes En un sistema pueden producirse los siguientes tipos de anomalías: Anomalía de disco Anomalía del sistema Anomalía de alimentación Anomalía de programa o error humano Pérdida total del sistema Algunas de estas anomalías tienen más probabilidades de producirse que otras. Deberá tener una estrategia de salar que le prepare para recuperarse de todas ellas. Anomalía de disco Si falla una unidad de discos del sistema, en la mayoría de los casos se destruirán los datos de dicha unidad de discos. Ello requiere la recuperación de todos los datos de la agrupación de almacenamiento auxiliar (ASP) que contiene la unidad anómala. La arquitectura de almacenamiento a un solo niel hace del seridor iseries y AS/400 un sistema muy productio en lo referente a la programación y la gestión. Sin embargo, la arquitectura hace que la recuperación de una anomalía de disco sea más difícil. El sistema reparte información por todas las unidades de discos de la ASP para proporcionar un rendimiento y una gestión del almacenamiento buenos. Si se pierde una unidad de una ASP, no podrá determinar qué datos se encontraban en esa unidad ya que los objetos están repartidos por la ASP. Debe recuperar todos los datos de la ASP. Las herramientas de protección de disco protección por duplicación de disco y protección por paridad de dispositios están diseñadas para reducir el tiempo de recuperación si falla una unidad de discos o, en algunos casos, para eliminar la necesidad de recuperar los datos. Anomalía del sistema Una anomalía del sistema significa que ha fallado alguna parte del hardware del sistema, aparte de los subsistemas de unidades de discos. Algunas anomalías del sistema, como los problemas de procesador, proocan que el sistema se detenga sin aiso. A esto se le denomina una finalización anormal. Cuando el sistema finaliza anormalmente, pueden producirse los siguientes problemas: Los archios se habrán actualizado parcialmente. Las ías de acceso para los archios pueden estar incompletas. Los objetos en uso pueden resultar dañados. Las relaciones entre los archios se habrán alidado parcialmente. Al reiniciar el sistema (hacer IPL) tras reparar el componente anómalo, el sistema analiza los posibles daños, reconstruye o recupera ías de acceso, intenta erificar las relaciones entre archios e intenta sincronizar los archios con los límites de transacciones. La primera IPL tras una finalización anormal del sistema puede tardar mucho tiempo. Anomalía de alimentación La pérdida de la alimentación también prooca que el sistema finalice anormalmente. Puede experimentar los mismos tipos de problemas que se producen por una anomalía del sistema. Muchos sistemas están equipados con una característica denominada Red de control de alimentación del sistema. Esta característica proporciona una función denominada Almacenamiento principal alimentado de forma continua. Si el sistema tiene esta característica, una batería proporciona suficiente alimentación para cerrar el sistema y conserar el contenido de la memoria hasta 2 días tras una pérdida de alimentación. Copyright IBM Corp. 1998,

12 En muchos casos, esto puede reducir de forma significatia el período de tiempo que el sistema necesita para realizar una carga del programa inicial (IPL) tras una pérdida de alimentación. Anomalía de programa o error humano A eces no se prueban los programas de la forma apropiada antes de ponerlos en producción, o bien se produce una condición no preista por los desarrolladores del software. Un error de programa puede proocar que haya información incorrecta en algunos archios de datos. El personal que utiliza el sistema también puede cometer errores. Un operador podría ejecutar dos eces un programa de fin de mes. Una persona encargada de la entrada de datos podría entrar el mismo lote de pedidos dos eces. Un gestor del sistema podría suprimir un archio por error. Cuando se producen estos tipos de errores, es necesario corregir o restaurar los datos dañados. Pérdida total del sistema Un incendio, una inundación u otro desastre natural podría destruir todo el sistema. Para reconstruir el sistema por completo, deberá tener un juego completo de cintas de salar y la documentación almacenados fuera del local, en una ubicación segura y accesible. 6 iseries: Planificación de una estrategia de copia de seguridad y recuperación

13 Capítulo 3. Saber qué salar y con qué frecuencia Es coneniente salar todo el contenido del sistema con la mayor frecuencia posible. En caso contrario, podría no estar en condiciones de realizar la recuperación ante la pérdida de un local o determinadas anomalías de disco. Si sala las partes adecuadas de su sistema iseries, podrá realizar la recuperación hasta el punto 4 (la última operación de salar) que se muestra en la secuencia temporal de copia de seguridad y recuperación. Las partes del sistema que cambian a menudo deben salarse diariamente. Las partes del sistema que no cambian con tanta frecuencia deben salarse semanalmente. Partes del sistema que cambian a menudo Esta tabla muestra las partes del sistema que cambian a menudo y que, por consiguiente, deberían salarse diariamente: Tabla 1. Qué salar diariamente: partes del sistema que cambian a menudo Suministrado por Descripción del elemento IBM? Cuándo se producen cambios Información de seguridad (perfiles de usuario, autorizaciones priadas, listas de autorizaciones) Algunos Regularmente, al añadirse nueos usuarios y objetos o cambiarse autorizaciones 1 Objetos de configuración en QSYS No Regularmente, cuando se añaden o modifican descripciones de dispositios o al utilizar la función Gestor de sericios de hardware para actualizar la información de configuración 1 Bibliotecas suministradas por IBM que Sí Regularmente contienen datos de usuario (QGPL, QUSRSYS) Bibliotecas de usuario que contienen No Regularmente datos de usuario y programas Carpetas y documentos Algunos Regularmente, si utiliza estos objetos Distribuciones No Regularmente, si utiliza la función de distribución Directorios Algunos Regularmente, si utiliza estos objetos 1 Estos objetos también pueden cambiar al actualizar programas bajo licencia. Partes del sistema que no cambian con frecuencia Esta tabla muestra las partes del sistema que no cambian a menudo; puede salarlas semanalmente. Tabla 2. Qué salar semanalmente: partes del sistema que no cambian a menudo Suministrado por Descripción del elemento IBM? Cuándo se producen cambios C¾digo Interno bajo Licencia Sí Con los PTF o nueo release del sistema operatio Objetos del sistema operatio en la Sí Con los PTF o nueo release del sistema operatio biblioteca QSYS Biblioteca opcionales del Operating Sí Con los PTF o nueo release del sistema operatio System/400 (QHLPSYS, QUSRTOOL) Bibliotecas de programas bajo licencia Sí Actualizaciones de los programas bajo licencia (QRPG, QCBL, Qxxxx) Carpetas de programas bajo licencia Sí Actualizaciones de los programas bajo licencia (Qxxxxxxx) Directorios de programas bajo licencia (/QIBM, /QOpenSys/QIBM) Sí Actualizaciones de los programas bajo licencia Copyright IBM Corp. 1998,

14 8 iseries: Planificación de una estrategia de copia de seguridad y recuperación

15 Capítulo 4. Determinar el período para salar Pensando de forma realista, el momento de ejecutar los procedimientos de salar, la forma de ejecutarlos y lo que sale está supeditado al tiempo de que disponga para el período de salar. El período para salar es la cantidad de tiempo que el sistema puede no estar disponible para los usuarios mientras realiza las operaciones de salar. Para simplificar la recuperación, es necesario salar cuando el sistema está en un punto conocido y los datos no están modificándose. Al seleccionar una estrategia para salar, deberá sopesar lo que los usuarios consideran un período para salar aceptable con el alor de los datos que podría perder y la cantidad de tiempo que puede tardar la recuperación. Si el sistema es de tal importancia para la empresa que no puede disponer de un período para salar manejable, probablemente tampoco podrá permitirse un paro no planificado. Deberá ealuar seriamente todas las opciones de disponibilidad del seridor iseries, incluidos los sistemas duales. Elija una de las siguientes estrategias de salar, basándose en la duración del período para salar. Vuela a ealuar entonces su decisión basándose en la posición en que la estrategia de salar le deja para la recuperación. Estrategia de salar sencilla Tiene un período para salar amplio, lo que significa que tiene disponible diariamente un bloque de tiempo de 8 a 12 horas sin actiidad del sistema (incluido el trabajo de proceso por lotes). Estrategia de salar intermedia Tiene un período para salar intermedio, lo que significa que tiene disponible diariamente un bloque de tiempo más reducido (de 4 a 6 horas) sin actiidad del sistema. Estrategia de salar compleja Tiene un período para salar reducido, lo que significa que no hay tiempo o hay muy poco tiempo durante el cual el sistema no se está utilizando para trabajos interactios o de proceso por lotes. Estrategia de salar sencilla La estrategia de salar más sencilla es salarlo todo cada noche (o en horas fuera del horario de trabajo). Puede utilizar la opción 21 (Todo el sistema) del menú Salar para hacerlo. Puede planificar que se ejecute la opción 21 sin operador (desatendida), iniciándose a una hora determinada. También puede utilizar este método para salar todo el sistema tras actualizar a un nueo release o aplicar arreglos temporales del programa (PTF). Podría suceder que no tenga suficiente tiempo o suficiente capacidad en las unidades de cintas para ejecutar la opción 21 sin un operador. Puede utilizar una estrategia sencilla igualmente: Diariamente Semanalmente Salar todo lo que cambia a menudo. Salar lo que no cambia a menudo. La opción 23 (Todos los datos de usuario) del menú Salar sala la información que cambia con regularidad. La opción 23 puede planificarse para que se ejecute de forma desatendida. Para ejecutarla de forma desatendida, debe tener suficiente capacidad de medio de copia de seguridad en línea. Si el sistema tiene un largo período de inactiidad durante el fin de semana, la estrategia para salar podría ser como la siguiente: Viernes noche Lunes noche Opción 21 del menú Salar Opción 23 del menú Salar Copyright IBM Corp. 1998,

16 Martes noche Miércoles noche Juees noche Viernes noche Opción 23 del menú Salar Opción 23 del menú Salar Opción 23 del menú Salar Opción 21 del menú Salar Estrategia de salar intermedia Puede suceder que no tenga un período para salar lo suficientemente amplio como para utilizar una estrategia de salar sencilla. Quizás por la noche se ejecutan grandes trabajos por lotes en su sistema, o bien tiene archios muy grandes que cuesta mucho tiempo salar. Si este es el caso, podría ser necesario desarrollar una estrategia de salar intermedia, lo que significa que la complejidad a la hora de salar y recuperar es media. Al desarrollar una estrategia de salar intermedia, aplique este principio: cuánto más a menudo cambien los datos, más a menudo deberá salarlos. Simplemente necesita ealuar con más detalle la frecuencia con que cambia la información que cuando se utiliza una estrategia sencilla. Hay diersas técnicas disponibles a utilizar en una estrategia de salar intermedia. Puede utilizar una de ellas o una combinación. Salar objetos modificados Registrar por diario los objetos y salar los receptores de diario Salar objetos modificados Puede utilizar arios mandatos para salar únicamente la información que ha cambiado desde la última operación de salar o desde una fecha y hora concretas. Puede utilizar el mandato Salar Objetos Cambiados (SAVCHGOBJ) para salar solamente los objetos que han cambiado desde la última ez que se saló una biblioteca o un grupo de bibliotecas. Esto puede resultar especialmente útil en una situación en la que los programas y los archios de datos se encuentren en la misma biblioteca. Normalmente, los archios de datos cambian con frecuencia y los programas no. Puede utilizar el mandato SAVCHGOBJ para salar solamente los archios que cambien. Puede utilizar el mandato Salar Objeto de Biblioteca de Documentos (SAVDLO) para salar solamente los documentos y carpetas que han cambiado. Puede utilizar el mandato SAVDLO para todas las agrupaciones de almacenamiento auxiliar de usuario o para una agrupación de almacenamiento auxiliar de usuario concreta. Puede utilizar el mandato Salar (SAV) para salar objetos de los directorios que hayan cambiado desde un punto concreto. También podría elegir salar los objetos cambiados si la carga de trabajo de proceso por lotes es más intensa algunas noches. Por ejemplo: Día Carga de trabajo por lotes Operación de salar Viernes noche Ligera Opción 21 del menú Salar Lunes noche Intensa Salar cambios solamente 1 Martes noche Ligera Opción 23 del menú Salar Miércoles noche Intensa Salar cambios solamente 1 Juees noche Intensa Salar cambios solamente 1 Viernes noche Ligera Opción 21 del menú Salar 1 Utilice una combinación de los mandatos SAVCHGOBJ, SAVDLO y SAV. 10 iseries: Planificación de una estrategia de copia de seguridad y recuperación

17 Registrar por diario los objetos y salar los receptores de diario Si las operaciones de salar archios de bases de datos duran demasiado debido a que los archios son grandes, salar los objetos cambiados no le ayudará. Si tiene un miembro de archio con registros y cambia 1 registro, el mandato SAVCHGOBJ sala el miembro de archio completo. En esta situación, registrar por diario los archios de base de datos y salar los receptores de diario regularmente puede ser una solución más efectia, aunque la recuperación es más compleja. Se aplica un principio similar a los objetos IFS y a las áreas de datos. Si las operaciones de salar objetos IFS y áreas de datos tardan demasiado, puede optar por registrar por diario los objetos y hacer más eficaces las operaciones de salar. Salar receptores de diario puede ser una opción mejor. Cuando se registran por diario objetos, el sistema graba en un receptor de diario una copia de cada cambio efectuado en el objeto. Cuando sala un receptor de diario, está salando solamente las partes modificadas del objeto, no el objeto entero. Si registra por diario los objetos y tiene una carga de trabajo de proceso por lotes ariable, la estrategia de salar podría ser como la siguiente: Día Carga de trabajo por lotes Operación de salar Viernes noche Ligera Opción 21 del menú Salar Lunes noche Intensa Salar receptores de diario Martes noche Ligera Opción 23 del menú Salar Miércoles noche Intensa Salar receptores de diario Juees noche Intensa Salar receptores de diario Viernes noche Ligera Opción 21 del menú Salar Notas: 1. Para beneficiarse de la protección que proporciona el registro por diario, deberá desconectar y salar los receptores de diario regularmente. La frecuencia con que los sale dependerá del número de cambios registrados por diario que se produzcan. Salar los receptores de diario arias eces a lo largo del día podría ser lo más apropiado. La forma en que sale los receptores de diario dependerá de si se encuentran en una biblioteca aparte. Podría utilizar el mandato Salar Biblioteca (SAVLIB) o el mandato Salar Objeto (SAVOBJ). 2. Debe salar los nueos objetos antes de poder aplicar las entradas del diario al objeto. Si sus aplicaciones añaden nueos objetos regularmente, deberá considerar utilizar la estrategia SAVCHGOBJ, ya sea sola o en combinación con el registro por diario. Estrategia de salar compleja Un período para salar muy reducido requiere una estrategia compleja para salar y para la recuperación. Se utilizan las mismas herramientas y técnicas que se describen para una estrategia de salar intermedia, pero con un niel de detalles superior. Por ejemplo, podría ser necesario salar archios críticos específicos en momentos concretos del día o de la semana. Considere también la posibilidad de utilizar una herramienta como Backup Recoery and Media Serices for iseries (BRMS). Salar el sistema mientras está actio suele ser necesario en una estrategia de salar compleja. El parámetro salar mientras está actio (SAVACT) está soportado en estos mandatos: Salar Biblioteca (SAVLIB) Salar Objeto (SAVOBJ) Salar Objetos Cambiados (SAVCHGOBJ) Salar Objeto de Biblioteca de Documentos (SAVDLO) Salar (SAV) Capítulo 4. Determinar el período para salar 11

18 Si utiliza el soporte de salar mientras está actio, puede reducir de forma significatia el período de tiempo que los archios no están disponibles. Cuando el sistema ha establecido un punto de control para todos los objetos que se están salando, los objetos pueden ponerse de nueo a disposición de los usuarios. El soporte de salar mientras está actio puede utilizarse en combinación con el registro por diario y el control de compromiso para simplificar el procedimiento de recuperación. Si elige utilizar el soporte de salar mientras está actio, asegúrese de que comprende el proceso y superise con qué precisión se establecen los puntos de control en el sistema. También puede reducir el tiempo que los archios no están disponibles realizando operaciones de salar en más de un dispositio a la ez o realizando operaciones de salar simultáneas. Por ejemplo, puede salar bibliotecas en un dispositio, carpetas en otro dispositio y directorios en un tercer dispositio; o bien, puede salar distintos conjuntos de bibliotecas u objetos en dispositios distintos. Si está utilizando V4R4 o un release posterior, también puede utilizar múltiples dispositios simultáneamente efectuando una operación de salar paralela. Para realizar una operación de salar paralela, necesita Backup Recoery and Media Serices o una aplicación que le permita crear objetos de definición de medios. Para obtener más información sobre el soporte de salar mientras está actio, las operaciones de salar simultáneas y las operaciones de salar paralelas, ea Copia de seguridad del sistema. 12 iseries: Planificación de una estrategia de copia de seguridad y recuperación

19 Capítulo 5. Elección de las opciones de disponibilidad Las opciones de disponibilidad son el complemento de una buena estrategia de salar, no el sustituto. Las opciones de disponibilidad pueden reducir de forma significatia el tiempo que se tarda en recuperarse tras una anomalía. En algunos casos, las opciones de disponibilidad pueden eitarle tener que realizar una recuperación. Para justificar el coste de utilizar las opciones de disponibilidad, es necesario que comprenda lo siguiente: El alor que el sistema proporciona. El coste de un paro planificado o no planificado. Las necesidades de disponibilidad que tiene. Si la idea de disponibilidad le resulta nuea, le interesa familiarizarse con algunos conceptos básicos de disponibilidad. Las siguientes son las opciones de disponibilidad que puede utilizar para complementar su estrategia de salar: La gestión de diario le permite recuperar los cambios efectuados en los objetos que se hayan producido desde la última operación de salar completa. La protección de ías de acceso le permite oler a crear el orden en que se procesan los registros de un archio de base de datos. Las agrupaciones de almacenamiento auxiliar limitan la cantidad de datos que tendrá que recuperar a los datos de la ASP de la unidad anómala. La Protección por paridad de dispositios le permite reconstruir datos perdidos; el sistema puede continuar ejecutándose mientras los datos se reconstruyen. La Protección por duplicación de disco le ayuda a mantener los datos disponibles ya que tiene dos copias de los datos en dos unidades de discos aparte. Los sistemas duales le permiten conserar todos los datos o parte de ellos en dos sistemas; el sistema secundario puede encargarse de los programas de aplicación críticos si el sistema principal falla. Una ez comprenda cuáles son las opciones, le resultará útil comparar estas opciones de disponibilidad para poder decidir cuáles se ajustan mejor a su empresa. Conceptos de disponibilidad Estos términos suelen utilizarse para tratar la disponibilidad del sistema: Paro Un período durante el cuál el sistema no está disponible para los usuarios. Durante un paro planificado, hace que el sistema no esté disponible para los usuarios a propósito. Puede utilizarse un paro planificado para ejecutar trabajos de proceso por lotes, salar el sistema o aplicar arreglos temporales del programa (PTF). Un paro no planificado suele producirse por algún tipo de anomalía. Disponibilidad alta El sistema no tiene ningún paro no planificado. Operaciones continuas El sistema no tiene ningún paro planificado. Disponibilidad continua El sistema no tiene ningún paro planificado o no planificado. Gestión de diarios para la copia de seguridad y recuperación Puede utilizar la gestión de diarios para recuperar los cambios efectuados en los objetos que se hayan producido desde la última operación de salar completa. Copyright IBM Corp. 1998,

20 El diario se utiliza para definir qué objetos desea proteger con la gestión de diario. A menudo se hace referencia a esta operación como registrar por diario un objeto. Un receptor de diario contiene las entradas (denominadas entradas de diario) que el sistema añade cuando se producen eentos que se registran por diario, como los cambios en los archios de base de datos, los cambios en otros objetos registrados por diario o eentos releantes para la seguridad. Para obtener una lista de objetos que pueden registrarse por diario, consulte el tema Copia de seguridad y recuperación. Puede utilizar la función de diario remoto para configurar diarios y receptores de diario en un seridor iseries remoto. Estos diarios y receptores de diario están asociados con diarios y receptores de diario del sistema origen. La función del diario remoto le permite duplicar entradas de diario del sistema origen en el sistema remoto. La finalidad principal de la gestión de diario es ayudar en la recuperación. También puede utilizar la información almacenada en los receptores de diario con otros fines como, por ejemplo, los siguientes: Un seguimiento de auditoría de la actiidad que se produce para los archios de base de datos u otros objetos en el sistema. Ayuda para probar los programas de aplicación. Puede utilizar entradas de diario para er los cambios realizados por un programa concreto. Para obtener más información sobre el registro por diario, consulte los siguientes apartados: Gestión de diario entajas Gestión de diario costes y limitaciones Para obtener información sobre cómo utilizar la gestión de diario para tipos de objeto determinados en su empresa, consulte el tema Copia de seguridad y recuperación. Gestión de diario entajas Estas son las entajas de la gestión de diario: Puede reducir la frecuencia y la cantidad de datos salados. Aumenta la capacidad y la elocidad de recuperación desde un punto conocido al punto de la anomalía. Proporciona sincronización de objetos registrados por diario si el sistema finaliza anormalmente. Gestión de diario costes y limitaciones Estas son las desentajas de la gestión de diario: Aumenta los requisitos de almacenamiento auxiliar. Puede repercutir sobre el rendimiento debido al aumento de la actiidad de los discos y de la unidad de proceso. Requiere conocimientos de los objetos y aplicaciones para la recuperación. Protección de ías de acceso Una ía de acceso describe el orden en que se procesan los registros de un archio de base de datos. Un archio puede tener múltiples ías de acceso, si distintos programas necesitan er los registros en secuencias distintas. Si el sistema finaliza anormalmente cuando se están utilizando ías de acceso, el sistema podría tener que reconstruir las ías de acceso para que pueda oler a utilizar los archios. Este es un proceso que requiere mucho tiempo. Realizar una IPL en un seridor iseries grande y muy actio que ha finalizado anormalmente puede requerir muchas horas. Puede utilizar la gestión de diario para mantener un registro de los cambios realizados en las ías de acceso. Esto reduce mucho el tiempo que tarda el sistema en realizar una IPL tras finalizar anormalmente. 14 iseries: Planificación de una estrategia de copia de seguridad y recuperación