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 estaba inicialmente destinado a desarrolladores y administradores del 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 que 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 más común entre los novatos que no se dan cuenta de que el propósito principal de una copia de seguridad de la 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 (una parte importante del cual es la base de datos) sea lo más breve posible.
Como resultado, el sistema permanece 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 ni 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 entre en vigor. 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 crees 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 como este suele ocurrir un viernes por la tarde, cuando las cosas se ponen caóticas y cuando las instrucciones de la dirección son algo contradictorias. Un poco de mala suerte y tienes por delante un fin de semana lánguido en la sala de servidores.
Firebird tiene cierto tipo 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 conmutador predeterminado -create está activado y si el nombre de archivo especificado apunta a una base de datos existente. Desafortunadamente, hay una manera de eludir esta protección: el conmutador -rep todavía 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 permiten hacer un truco curioso con muchos DBMS (incluido Firebird): implementar una copia de seguridad en streaming con la restauración de la base de datos a partir de ella a la vez. Como resultado, no se crea ningún archivo de copia de seguridad intermedio. 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 un fallo grave de disco durante este proceso de copia de seguridad/restauración, la base de datos inicial puede dañarse mientras que aún no se ha creado ninguna base de datos nueva. 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 creara esa copia.
Recomendaciones: no uses la copia de seguridad/restauración en un solo paso en el modo automático y siempre verifica la disponibilidad de una copia suficientemente actualizada en el modo manual.
4. Almacenar las copias de seguridad y la base de datos en un mismo dispositivo físico
A muchos de ustedes les puede parecer gracioso que el consejo que damos sea algo infantil: el abecé de las copias de seguridad. Cierto, es verdad, pero la base de datos y el disco pueden acabar 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 pasarle a sus datos si usan matrices RAID (versión 1 o superior :)). Además, hay personas que creen que algunos servidores de “marca” son infalibles, pero ese es un caso especial.
Recomendaciones: no almacenes las copias de seguridad y la base de datos en un mismo dispositivo, por muy fiable que parezca.
5. Falta de 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, bien podrías 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 por mensaje de texto. ¡Y la ausencia de tales notificaciones es señal de un problema!
Un lector atento que haya llegado a este punto de nuestro artículo (aunque todavía es pronto para dar un premio por ello) puede preguntar: “Pero, ¿qué tiene que ver esto con la dirección?”. He aquí qué: el administrador normalmente configura el proceso de copia de seguridad, pero le parece demasiado aburrido verificar las notificaciones, especialmente cuando se almacenan en una carpeta separada, así que nunca está de más solicitar informes adicionales sobre el estado del proceso. Es en relación con la cuestión de quién tiene la culpa cuando parece como si las copias de seguridad estuvieran ahí, pero en realidad no están 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 los procesos de copia de seguridad exitosos y fallidos, notificar a los usuarios sobre los problemas y ofrecer herramientas de control resumido (es especialmente relevante cuando necesitas controlar decenas 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 existe un 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. Falta de validación de las copias de seguridad
El hecho de que las copias de seguridad estén almacenadas en algún lugar no significa que se puedan leer 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 las copias de seguridad con la ayuda de FBDataGuard.
7. Falta de comprobaciones de estado de la base de datos al usar copias de seguridad no verificadas
Normalmente, 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 hace posible copiar rápidamente el archivo de la base de datos (de forma completa o parcial/incremental).
En el caso de bases de datos Firebird grandes (más de 500 GB), es aconsejable 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 un fallo de la RAM) o a nivel lógico, una copia de seguridad no verificada lo contendrá también, al igual que la base de datos original.
Para evitarlo, debes usar la 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 la validación en línea de bases de datos para las versiones 1.5-2.5).
Además, es aconsejable 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 comprobación de estado en línea, FBDataGuard te permite probar el proceso de restauración de la copia de seguridad en el modo automático.
8. Falta de control sobre el 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 un disco junto con la base de datos puede provocar una interrupción en el funcionamiento de la base de datos, y almacenarlas en el disco del sistema puede provocar un fallo del sistema.
En combinación con el Problema 4, el mejor resultado posible será aquel en el que el sistema deje 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 de seguridad 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. Falta de control sobre el tiempo que lleva crear una copia de seguridad
El proceso de copia de seguridad tardaba 40 minutos literalmente hace medio año y de repente ya tarda 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 abandonar 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 por qué alguien podría necesitarlo). 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 copias 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 con las actualizaciones automáticas de Windows habilitadas (por defecto, las actualizaciones se aplican a las 3 a. m.). En el mejor de los casos provoca una ralentización, pero si el sistema operativo se reinicia para aplicar las actualizaciones, la copia de seguridad se dañará. Al menos, la buena noticia es que el sistema operativo no se actualiza todos los días.
Recomendaciones: programa las actualizaciones del sistema operativo cuando no interfieran con el proceso de copia de seguridad.
11. Hacer copias de seguridad de la base de datos con la ayuda de herramientas de copia de seguridad de archivos o de máquinas virtuales mientras el servidor de base de datos está en funcionamiento
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 se abren 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 los archivos de la base de datos) o la copia de seguridad de la máquina virtual. Las herramientas de copia de seguridad de archivos leen la base de datos de forma secuencial y esto 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 de la base de datos consistente, ya que la copia de seguridad será inconsistente en caso de que existan operaciones de escritura activas con la base de datos en el momento de recopilar el conjunto de bloques modificados.
Para aquellos que deseen hacer copias de seguridad de sus bases de datos con la ayuda de herramientas de copia de seguridad de archivos o de máquinas virtuales, podemos ofrecer dos métodos:
- apagar completamente 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 consistente en el momento de la sincronización.
Si no cambia la base de datos al modo compatible con copias de seguridad, la copia resultante de la base de datos se verá 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 sobre esto 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 hacer copias de seguridad de 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, ya que como mucho solo se corromperá este registro. Es una idea errónea peligrosa que los desarrolladores de DBMS no respaldan.
Las raíces de esta idea errónea están claras: la publicidad agresiva de los desarrolladores de máquinas virtuales y herramientas de copia de seguridad normalmente no menciona 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 de máquinas virtuales sin las correspondientes herramientas de automatización 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. Sustituir la copia de seguridad por 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 aun así son bastante diferentes.
Todo el mundo adora la replicación por la capacidad de sincronizar datos en otro servidor con el mínimo retraso, pero la copia de seguridad también tiene algunas ventajas indiscutibles. Por ejemplo, en caso de eliminación accidental (o intencionada) de datos, la replicación enviará rápidamente 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 requiere cierto esfuerzo para configurar correctamente tanto la replicación como la copia de seguridad y, aun así, la posibilidad de errores existe de todos modos.
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 normalmente los administradores de bases de datos de organizaciones donde valoran sus datos suelen utilizar herramientas profesionales de copia de seguridad que les permiten tener en cuenta los problemas mencionados anteriormente y prevenirlos.
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 compruebe sus copias de seguridad ahora mismo :)
Contactos
No dude en hacernos cualquier pregunta: [email protected]
¿Quiere recibir noticias y artículos sobre Firebird? Únase a nosotros en Telegram https://t.me/firebirdsql