12 errores comunes al hacer copias de seguridad de bases de datos
por Alexey Kovyazin, 11 de noviembre de 2015
Descargar PDF (inglés) Este artículo fue inicialmente pensado para desarrolladores y administradores de DBMS Firebird, pero los contactos con administradores de otras bases de datos dejaron claro que la mayoría de los errores son comunes entre ellos también y literalmente todos tropiezan con casi las mismas piedras. Si puedes añadir algo a esta lista (incluso algo específico de un DBMS en particular), contáctanos a través de nuestro correo electrónico [email protected].
1. Eliminar la copia de seguridad anterior antes de que se cree una nueva copia de seguridad
Este error es el más común entre los novatos que no se dan cuenta de que el propósito principal de una copia de seguridad de base de datos no es solo crear una copia de la base de datos, sino hacer que el tiempo de inactividad de un sistema de información (del cual la base de datos es una parte importante) sea lo más corto posible.
Como resultado, el sistema queda desprotegido desde el momento en que se elimina la última copia de seguridad hasta el momento en que se crea la nueva, porque la base de datos no tiene una sola copia de seguridad durante este período. Dado que crear una copia de seguridad puede llevar bastante tiempo, es el momento perfecto para que la ley de Murphy surta efecto. Este enfoque funciona especialmente bien cuando se combina con el Problema 7 (ver más abajo).
Recomendaciones: ¡no elimines la copia de seguridad anterior antes de que se cree la nueva! (y no hagas una nueva copia de seguridad en un archivo existente).
Recomendación para Firebird: existe una herramienta FBDataGuard incluida en HQbird (un paquete de distribución avanzado de Firebird) que elimina la copia de seguridad más antigua del historial solo después de que se cree una nueva.
2. Sobrescribir una base de datos existente al restaurarla desde una copia de seguridad
Este error es menos común aunque los resultados pueden ser mucho peores. Si la copia de seguridad no ha sido verificada y resulta estar corrupta (ver Problema 6), no tendrás ni la copia anterior de la base de datos ni una copia de seguridad válida.
Un desastre así suele ocurrir un viernes por la tarde cuando las cosas se ponen frenéticas y cuando las instrucciones de la dirección se vuelven algo contradictorias. Un poco de mala suerte y un fin de semana lánguido en la sala de servidores es lo que te espera.
Firebird tiene una especie de protección contra este error: no será posible restaurar una base de datos desde una copia de seguridad con la ayuda de la utilidad gbak si su interruptor predeterminado -create está activado y si el nombre de archivo especificado apunta a una base de datos existente. Desafortunadamente, hay una manera de sortear esta protección: el interruptor -rep aún permite sobrescribir el archivo existente.
Recomendación: nunca sobrescribas el archivo de una base de datos en funcionamiento sin una directiva escrita de tu dirección.
Recomendación para Firebird: usa FBDataGuard porque nunca sobrescribe el archivo de la base de datos.
3. Usar copia de seguridad/restauración en un solo paso sin usar un archivo de copia de seguridad intermedio
Los flujos estándar de entrada/salida hacen posible hacer un truco divertido con muchos DBMS (incluido Firebird): implementar una copia de seguridad en streaming con restauración de la base de datos desde ella al instante. No se crea ningún archivo de copia de seguridad intermedio como resultado. Es conveniente para el mantenimiento rutinario y para ejecutar una operación de restauración de prueba (siempre que haya otra copia de seguridad disponible), pero ¡no debes usarlo para copias de seguridad automáticas!
Por ejemplo, si ocurre una falla grave del disco durante este proceso de copia de seguridad/restauración, la base de datos inicial puede dañarse mientras aún no se ha creado una nueva base de datos. Por supuesto, si tienes en cuenta el Problema 1 y hay una copia de la base de datos del intento anterior, solo se perderán los datos creados o actualizados en la base de datos después de que se creó esa copia.
Recomendaciones: no uses copia de seguridad/restauración en un solo paso en modo automático y verifica siempre la disponibilidad de una copia lo suficientemente actualizada en modo manual.
4. Almacenar las copias de seguridad y la base de datos en un mismo dispositivo físico
Muchos de ustedes pueden encontrar divertido que el consejo que damos sea algo infantil: el ABC de las copias de seguridad. Cierto, eso es verdad, pero la base de datos y el disco pueden terminar almacenados en un mismo sistema de almacenamiento de datos debido a la popularidad de los entornos virtuales. Y ciertamente fallará en el momento más inoportuno. Además, todavía hay personas que creen que nada puede pasar con sus datos si usan matrices RAID (versión 1 o superior :)). Además, hay personas que creen que algunos servidores de “marca” son a prueba de fallos, pero eso es un caso especial.
Recomendaciones: no almacenes las copias de seguridad y la base de datos en un mismo dispositivo por muy confiable que parezca.
5. Sin control sobre la finalización exitosa del proceso de copia de seguridad
Es un error bastante común tanto entre administradores como entre los jefes de departamentos de TI. Si no verificas los resultados del proceso de copia de seguridad, más te vale no realizarlo en absoluto. Debes recibir notificaciones sobre el proceso de copia de seguridad completado con éxito por correo electrónico o, mejor aún, también mediante mensajes de texto. ¡Y la ausencia de tales notificaciones es una señal de un problema!
Un lector atento que haya llegado a este punto de nuestro artículo (aunque es demasiado pronto para dar un premio por eso hasta ahora) podría preguntar: ‘¿Pero qué tiene que ver con la dirección?’ Aquí está la respuesta: el administrador generalmente configura el proceso de copia de seguridad, pero le resulta demasiado aburrido verificar las notificaciones, especialmente cuando se almacenan en una carpeta separada, por lo que nunca está de más solicitar informes adicionales sobre el estado del proceso. Se trata de la cuestión de quién tiene la culpa cuando parece que las copias de seguridad estaban allí, pero en realidad no están allí en el momento en que las necesitas :)
! una vez combinado con el Problema 2, no tenemos ni la base de datos ni su copia de seguridad.
Recomendaciones: usa herramientas de automatización de copias de seguridad que puedan monitorear procesos de copia de seguridad exitosos y fallidos, notificar a los usuarios sobre problemas y ofrecer herramientas de control resumido (es especialmente relevante cuando necesitas controlar docenas y cientos de procesos de copia de seguridad en diferentes servidores).
Recomendación para Firebird: FBDataGuard verifica si el proceso de copia de seguridad se ha completado y envía la notificación correspondiente. Para sistemas con muchas bases de datos, hay monitoreo resumido de segundo nivel con la ayuda de la herramienta Control Center que te permite ver los estados de todos los servidores y bases de datos monitoreados en una sola página.
6. Sin validación de la copia de seguridad
El hecho de que las copias de seguridad estén almacenadas en algún lugar no significa que puedan leerse desde allí.
Por eso debes verificar regularmente las copias de seguridad que creas para asegurarte de que no estén corruptas ni copiadas a /dev/null.
Recomendación para Firebird: puedes automatizar la validación de copias de seguridad con la ayuda de FBDataGuard.
7. Sin verificaciones de salud de la base de datos al usar copias de seguridad no verificadas
Generalmente, las bases de datos usan varios tipos de copia de seguridad: volcados, copias de seguridad regulares, etc. Sin entrar en detalles, podemos distinguir dos categorías: verificadas y no verificadas. En el caso de Firebird, son gbak y nbackup.
Gbak lee toda la base de datos a nivel de registros para crear un archivo de copia de seguridad y crea una base de datos insertando registros en una nueva base de datos, verificando así la copia de seguridad (hay formas de que los errores se cuelen en la copia restaurada, pero esa es otra forma en que el administrador de la base de datos puede estropear las cosas relacionada con una migración mal organizada) y la propia base de datos (si se puede leer de principio a fin, lo más probable es que no esté corrupta).
Nbackup (también conocido como copia de seguridad incremental) bloquea temporalmente el archivo principal de la base de datos para actualizaciones (en el estado consistente) y permite copiar rápidamente el archivo de la base de datos (completa o parcialmente/incrementalmente).
En el caso de bases de datos Firebird grandes (más de 500 GB), es recomendable usar nbackup para no ralentizar las operaciones de los usuarios, pero al mismo tiempo es necesario validar la base de datos porque las copias de seguridad no verificadas que crea son copias de páginas de la base de datos y si un error reside a nivel de registros (debido a una falla de RAM) o a nivel lógico, una copia de seguridad no verificada lo contendrá tanto como la base de datos original.
Para evitarlo, debes usar validación en línea para la base de datos original (la validación en línea con la ayuda de gfix está disponible a partir de la versión 2.5.4 de Firebird, mientras que nuestra herramienta FBDataGuard admite validación en línea de bases de datos para las versiones 1.5-2.5).
Además, es recomendable realizar una copia de seguridad verificada de vez en cuando (una vez a la semana, por ejemplo) además de la copia de seguridad no verificada.
Recomendación para Firebird: además de la verificación de salud en línea, FBDataGuard te permite probar el proceso de restauración de copias de seguridad en modo automático.
8. Sin control del espacio libre para las copias de seguridad
En realidad, es un error clásico: si no hay suficiente espacio, las copias de seguridad ocupan todo el espacio libre y el proceso termina con un error. Almacenar las copias de seguridad en el mismo disco que la base de datos puede llevar a una interrupción en la operación de la base de datos, y almacenarlas en el disco del sistema puede resultar en una falla del sistema.
En combinación con el Problema 4, el mejor resultado posible será aquel en el que el sistema deja de funcionar porque la base de datos también necesita espacio libre, pero está ocupado por las copias de seguridad. En cuanto a la combinación con los Problemas 5 y 2, nos deja nuevamente sin la base de datos ni su copia de seguridad.
Recomendaciones: usa herramientas de copia de seguridad que predigan el tamaño de la copia y te adviertan sobre la posible falta de espacio libre.
Recomendación para Firebird: FBDataGuard controla el tamaño del espacio libre para fines de copia de seguridad y también el tamaño del espacio libre en el disco con las bases de datos, así como en el disco del sistema.
9. Sin control del tiempo que lleva crear una copia de seguridad
El proceso de copia de seguridad tomaba 40 minutos literalmente hace medio año y de repente ya toma tres horas: ¿por qué? El tamaño de la base de datos puede haber aumentado o un disco puede haberse caído de tu matriz RAID, lo que resulta en un rendimiento de escritura considerablemente más lento, y todas tus copias de seguridad pueden estar a punto de despedirse de este mundo. O un buen colega tuyo puede haber ejecutado otro sistema de copia de seguridad al mismo tiempo (por cierto, Firebird te permite ejecutar varios procesos de copia de seguridad a la vez, aunque no está del todo claro para qué se necesita). Si no controlas el tiempo que lleva hacer una copia de seguridad, puedes pasar por alto un problema recién surgido y perder la oportunidad de solucionarlo antes de que se vuelva masivo.
Además, si el sistema de copia de seguridad no monitorea los estados de las tareas de copia de seguridad y las ejecuta simplemente según el horario, puedes fácilmente “adelantarte”, lo que significa la situación en la que el sistema inicia un nuevo proceso de copia de seguridad mientras el anterior aún no ha terminado.
Recomendaciones: ¡usa herramientas que controlen el tiempo que tarda el proceso de copia de seguridad!
Recomendación para Firebird: FBDataGuard controla el tiempo que tarda el proceso de copia de seguridad.
10. Hacer una copia de seguridad de la base de datos mientras se aplican actualizaciones del sistema operativo
Es un problema muy común, especialmente en combinación con el Problema 9 y las actualizaciones automáticas de Windows habilitadas (por defecto, las actualizaciones se aplican a las 3 a.m.). Conduce a una ralentización en el mejor de los casos, pero si el sistema operativo se reinicia para aplicar las actualizaciones, la copia de seguridad resultará dañada. Al menos, la buena noticia es que el sistema operativo no se actualiza todos los días.
Recomendaciones: programa las actualizaciones del sistema operativo para que no interfieran con el proceso de copia de seguridad.
11. Hacer una copia de seguridad de la base de datos con herramientas de copia de seguridad de archivos o herramientas de copia de seguridad de máquinas virtuales mientras el servidor de la base de datos está en ejecución
Muchos administradores olvidan que cualquier DBMS tiene una caché activa y compleja que contiene datos que se leen y escriben mientras los archivos de la base de datos están abiertos en modo de acceso aleatorio. Por eso es necesario usar tipos especiales de copia de seguridad en lugar de la mera copia de seguridad de archivos (incluida la simple copia de archivos de la base de datos) o la copia de seguridad de máquinas virtuales. Las herramientas de copia de seguridad de archivos leen la base de datos secuencialmente y puede llevar bastante tiempo, especialmente en el caso de bases de datos grandes, por lo que es imposible garantizar la integridad de la copia de seguridad creada.
Las máquinas virtuales pueden utilizar los mecanismos de instantáneas y Changed Block Tracking, pero es necesario sincronizar las copias de seguridad creadas para obtener una copia de seguridad coherente de la base de datos, porque la copia de seguridad será incoherente en caso de que haya operaciones de escritura activas con la base de datos en el momento de recopilar el conjunto de bloques modificados.
Para aquellos que deseen respaldar sus bases de datos con la ayuda de herramientas de copia de seguridad de archivos o máquinas virtuales, podemos ofrecer dos métodos:
- apagar por completo los servicios y procesos del DBMS para que no haya nada en la caché,
- utilizar agentes y/o scripts que cambien la base de datos a un modo especial que haga seguro copiar el archivo de la base de datos de forma secuencial. Por ejemplo, existe un mecanismo llamado VSS writer para bases de datos MSSQL. Bajo petición, cambia la base de datos al modo compatible con instantáneas en el momento en que se realiza una instantánea. Si utiliza mecanismos basados en Changed Block Tracking, usted mismo debe asegurarse de que la base de datos sea coherente en el momento de la sincronización.
Si no cambia la base de datos al modo compatible con copias de seguridad, la copia de la base de datos resultante parecerá como si se hubiera producido un reinicio forzado (por ejemplo, un corte de energía) en el equipo host. Este nivel de fiabilidad es absolutamente insuficiente para la mayoría de las empresas. Puede obtener más información al respecto en el artículo “Peculiaridades del trabajo con bases de datos en máquinas virtuales”.
Para Firebird, es necesario bloquear el archivo principal de la base de datos con la ayuda de nbackup antes de que comience el proceso de copia de seguridad y desbloquearlo después de que el proceso haya terminado. Para otros DBMS existen herramientas similares para activar/desactivar los modos correspondientes.
Algunos administradores de bases de datos están seguros de que pueden respaldar sus bases de datos de forma segura con la ayuda de herramientas estándar de copia de seguridad de archivos si el DBMS tiene un registro de transacciones, porque como máximo solo se corromperá ese registro. Es una peligrosa idea errónea que los desarrolladores de DBMS no respaldan.
Las raíces de esta idea errónea son claras: la publicidad agresiva de los desarrolladores de máquinas virtuales y herramientas de copia de seguridad suele omitir mencionar que las bases de datos, así como otros archivos actualizados intensivamente, requieren una configuración avanzada. No crea en el bombo publicitario: no todos los yogures tienen los mismos beneficios.
Recomendaciones: no utilice herramientas de copia de seguridad de archivos y máquinas virtuales sin las herramientas de automatización correspondientes para bases de datos.
Recomendación para Firebird: utilice FBDataGuard (del paquete de distribución HQbird), que proporciona integración con herramientas de copia de seguridad compatibles con VSS.
12. Reemplazar la copia de seguridad con la replicación
La copia de seguridad de datos y la replicación de datos se utilizan para aumentar la fiabilidad y prevenir la pérdida de datos, pero siguen siendo bastante diferentes.
A todos les encanta la replicación por la capacidad de sincronizar datos en otro servidor con un retraso mínimo, pero la copia de seguridad también tiene ventajas indiscutibles. Por ejemplo, en caso de eliminación accidental (o intencional) de datos, la replicación enviará rápida e imperturbablemente los cambios a la réplica, mientras que la copia de seguridad (especialmente con copias en medios de solo lectura) es inmune a tales operaciones. Se necesita cierto esfuerzo para configurar tanto la replicación como la copia de seguridad correctamente, y aún así existe la posibilidad de errores.
Recomendaciones: Si tiene la replicación configurada, no descuide las copias de seguridad, utilice ambas.
Recomendación para Firebird: utilice el paquete de distribución HQbird Enterprise, que incluye tanto herramientas de copia de seguridad como de replicación.
Resumen
No es tan fácil configurar la copia de seguridad para su DBMS favorito, por lo que generalmente los administradores de bases de datos de organizaciones que valoran sus datos suelen utilizar herramientas profesionales de copia de seguridad que les permiten tener en cuenta los problemas mencionados anteriormente y prevenir los problemas.
Para Firebird (perdón por la publicidad) existe un paquete llamado HQbird que incluye FBDataGuard.
Además, nuestra empresa proporciona soporte completo de copia de seguridad y mantenimiento para Firebird y otras bases de datos, esta es una buena opción para aquellos que no conocen todos los detalles técnicos de las copias de seguridad.
Y, por supuesto, siga cultivando su paranoia de administrador, por ejemplo, levántese y verifique sus copias de seguridad ahora mismo :)
Contactos
No dude en hacer cualquier pregunta: [email protected]
¿Quiere recibir noticias y artículos sobre Firebird? Únase a nosotros en Telegram https://t.me/firebirdsql