Con demasiada frecuencia, veo personas que hacen preguntas sobre las estrategias de copia de seguridad que deberían emplear para sus bases de datos. Parece que nunca falla, cada pregunta de este tipo que he encontrado en una variedad de foros nunca incluye sus requisitos de recuperación. A menudo me he quedado perplejo al considerar sus requisitos de recuperación antes de diseñar su estrategia de copia de seguridad. Cuando me presionan por los requisitos, a menudo obtengo requisitos de copia de seguridad, por ejemplo:
- Las copias de seguridad no deben generar ningún tiempo de inactividad
- Debe poder realizar una copia de seguridad de los registros de rehacer archivados
- Las copias de seguridad deben grabarse en cinta
Estos requisitos están muy bien, pero en mi opinión, nunca debe diseñar su estrategia de respaldo sin primero documentar sus requisitos de recuperación y obtener la ocurrencia de administración.
Aquí hay algunas preguntas que me hago al diseñar una estrategia de respaldo. Tenga en cuenta que todas estas preguntas se centran en el lado de la recuperación.
- ¿Cuánta pérdida de datos puedo permitirme al restaurar la base de datos? ¿Cero pérdida de datos? ¿Es aceptable una hora de pérdida de datos después de la recuperación de la base de datos?
- ¿Necesito revertir alguna transacción, es decir, realizar una restauración de un punto en el tiempo?
- ¿Tendré que restaurar el contenido de un esquema y dejar intactos los otros esquemas?
- ¿Cuánto tiempo tengo para poner en funcionamiento la base de datos después de una falla?
- ¿De qué tipo de fallas debo recuperarme? Obviamente, necesito poder restaurar desde una falla completa del servidor o la pérdida de un disco. Pero, ¿necesito poder recuperarme de fallas humanas como alguien que eliminó accidentalmente una tabla?
- ¿Tendré que restaurar la copia de seguridad en otros servidores como parte de la actualización de las bases de datos de desarrollo o prueba a partir de una copia de producción?
Si le pregunta a la mayoría de las personas en la comunidad de Oracle en estos días, le dirán que use RMAN para hacer una copia de seguridad de su base de datos. RMAN es un gran producto y, por muchas cosas, es mejor que las copias de seguridad frías o calientes administradas por el usuario al estilo antiguo. Algunos DBA de Oracle le dirán que use RMAN para realizar copias de seguridad en caliente y ejecutar su base de datos de producción en modo de registro de archivo. Al hacerlo, cubrirá muchos de los escenarios de recuperación que es probable que enfrente. Pero, ¿qué sucede si su respuesta a la pregunta 4 es que tiene 1 hora para volver a funcionar y su base de datos tiene un tamaño de 10 TB? Buena suerte al intentar realizar una restauración completa de una base de datos de 10 TB en 1 hora con RMAN. Y RMAN no podrá ayudar con la pregunta 3 ya que RMAN no realiza copias de seguridad en el nivel de esquema.
Hay muchas herramientas a disposición del DBA para realizar copias de seguridad y recuperar datos en la base de datos. Esas herramientas incluyen, pero no se limitan también:
- Administrador de recuperación de Oracle (RMAN)
- Copias de seguridad administradas por el usuario de Oracle
- Exportación/importación de Oracle o bomba de datos
- Instantáneas basadas en disco
- Replicación basada en disco
- Guarda de datos de Oracle
Entonces, ¿cuál usas? Pues cada uno tiene sus pros y sus contras. Una vez que conoce sus requisitos de recuperación, las herramientas para respaldar su base de datos comienzan a ser más claras. Y es posible que deba emplear más de una herramienta de respaldo para cumplir con todos sus requisitos de recuperación. Si usa, como sugerencia, RMAN con el modo Archive Log y nada más, y su gerente se le acerca y le dice “¡necesita volver a poner en funcionamiento esta base de datos de 10 TB en 1 hora!” tu trabajo bien puede estar en juego.
Lo que lleva al siguiente punto, documente sus requisitos de recuperación e inclúyalos en su Acuerdo de nivel de servicio (SLA). Al escribir y examinar el SLA, su gerencia puede decir que quiere cero pérdida de datos. Es en este momento que puede mencionar los pros y los contras de implementar una solución de pérdida de datos cero... ¡y también mencionar los costos! Muchas empresas se resisten al alto costo de una solución de pérdida de datos cero, pero para otras empresas, el costo es pequeño en comparación con la carga financiera de perder cualquier transacción. Aquí es donde entran en juego el regateo y el trueque. Si la gerencia insiste en una solución de pérdida de datos cero, entonces tienen que aportar los fondos para respaldarla porque RMAN (gratuito) no la proporcionará. Una vez que tenga sus requisitos de recuperación documentados en el SLA, será difícil para la administración pedirle que recupere algo que su estrategia de copia de seguridad no está diseñada para soportar. Si el SLA está vigente y le piden que recupere cada transacción y su estrategia de respaldo no lo permite, entonces tiene un documento que dice que nunca se requirió pérdida de datos cero y esto puede ayudarlo a salvar su trabajo.
Dicho esto, una vez que tenga sus requisitos de recuperación documentados en el SLA, asegúrese de que su estrategia de copia de seguridad le permita realizar todos los escenarios de recuperación documentados en el SLA. Su trabajo puede depender de ello. Si el SLA establece cero pérdida de datos y usted no implementa Data Guard a pesar de que la gerencia estaba dispuesta a financiarlo, es posible que lo despidan porque no cumplió con su trabajo.
Finalmente, ninguna estrategia de copia de seguridad/recuperación está completa a menos que se pruebe exhaustivamente. Debe probar cada estrategia de recuperación requerida para asegurarse de que puede cumplir con todos los requisitos establecidos en el SLA. Las pruebas se deben realizar al menos una vez al año por dos razones... una, asegura que los cambios en el sistema no afecten negativamente su capacidad para realizar una recuperación requerida y dos, lo mantiene actualizado sobre cómo realizar la recuperación para que si tiene que hacerlo de verdad, no está buscando a tientas el procedimiento. En las pruebas, es posible que descubra que su metodología de respaldo admitirá los escenarios de recuperación que se requieren, pero que es bueno tener si los necesita.
Y no puedo decirlo lo suficiente... ¡Prueba, prueba y prueba!
