“Oh, ningún refugio puede resistir el impacto de un meteorito. Pero tú, como todos, tienes una reserva, así que no te preocupes.
Stanislav Lem, "Los diarios estelares de Iyon el Tikhiy"
Hacer una copia de seguridad se refiere a mantener una copia de sus datos en algún lugar fuera de la ubicación de almacenamiento principal.
El objetivo principal de la copia de seguridad es restaurar los datos después de su pérdida. En este sentido, a menudo escuchamos que si tiene una réplica de una base de datos, siempre puede restaurar los datos de ella y no necesita una copia de seguridad. De hecho, la copia de seguridad le permite resolver al menos tres tareas que no se pueden resolver con una réplica y una réplica no se puede inicializar sin una copia de seguridad.
Primero, una copia de seguridad le permite recuperar datos después de un error lógico. Por ejemplo, un contador eliminó un grupo de transacciones o un DBA destruyó un espacio de tabla. Ambas operaciones son absolutamente legítimas desde el punto de vista de la base de datos y el proceso de replicación las reproducirá en la base de datos de réplica.
En segundo lugar, los DBMS modernos son sistemas de software muy confiables, pero ocasionalmente se producen daños en las estructuras internas de la base de datos, después de lo cual se pierde el acceso a los datos. Lo que es especialmente ofensivo, tal violación generalmente ocurre con una carga alta o al instalar algún tipo de actualización. Pero tanto la alta carga como las actualizaciones periódicas indican que la base de datos no es una base de datos de prueba y que los datos almacenados en ella son valiosos.
Finalmente, la tercera tarea, cuya solución requiere una copia de seguridad, es clonar la base de datos, por ejemplo, con fines de prueba.
La copia de seguridad de la base de datos se basa de alguna manera en uno de dos principios:
- Obtener datos y guardarlos posteriormente en un formato arbitrario;
- Instantánea de archivos de base de datos y registros de guardado.
Echemos un vistazo más de cerca a estos principios y las herramientas que los implementan.
Subiendo datos
El conjunto de utilidades que vienen con cualquier DBMS debe tener herramientas para cargar y descargar datos. Los datos se almacenan en formato de texto o en un formato binario específico de un DBMS en particular. La siguiente tabla enumera dichas herramientas:
| Formato binario | Formato de texto
|
|
|---|---|---|
| Oráculo | Exportación de DataPump / Importación de DataPump
Exportación / Importación |
Cargador SQL * Plus / SQL * |
| PostgreSQL | pg_dump, pg_dumpall / pg_restore | pg_dump, pg_dumpall / psql |
| Microsoft SQL Server | bcp | bcp |
| DB2 | descargar / cargar | descargar / cargar |
| MySQL | mysqldump, mysqlpump / mysql, mysqlimport | |
| MongoDB | mongodump / mongorestore | mongoexport / mongoimport |
| Casandra | instantánea de nodetool / sstableloader | cqlsh |
El formato de texto es bueno porque puede ser editado o incluso creado por programas externos, y el formato binario, a su vez, es bueno porque le permite descargar y cargar datos rápidamente al paralelizar la descarga y guardar recursos en la conversión de formato.
A pesar de la simplicidad y obviedad de la idea de descargar datos, este método rara vez se utiliza para realizar copias de seguridad de bases industriales cargadas. Estas son las razones por las que la descarga no es adecuada para una copia de seguridad completa:
- el proceso de descarga crea una carga significativa en el sistema fuente;
- la descarga lleva mucho tiempo; cuando finalice la descarga, se volverá irrelevante;
- Es casi imposible realizar una descarga consistente de toda la base de datos bajo carga alta, ya que el DBMS se ve obligado a mantener una instantánea de su estado en el momento en que comienza la descarga. Cuantas más transacciones se hayan comprometido desde el inicio de la carga, mayor será el volumen de la instantánea (copias desactualizadas de datos en PostgreSQL, espacio de deshacer en Oracle, tempdb en Microsoft SQL Server, etc.);
- la descarga conserva la estructura lógica de los datos, pero no conserva su estructura física: parámetros de almacenamiento físico de tablas, índices, etc.; La reconstrucción de índices en el momento del arranque puede llevar mucho tiempo.
Sin embargo, la descarga tiene ventajas:
- alta selectividad: puede descargar tablas individuales, campos individuales e incluso filas individuales;
- los datos cargados se pueden cargar en una base de datos de otra versión, y si la carga se realiza en formato de texto, entonces en otra base de datos.
Por lo tanto, la descarga se utiliza principalmente para tareas como realizar copias de seguridad de tablas pequeñas (por ejemplo, directorios) o distribuir conjuntos de datos con la próxima versión de la aplicación.
El método más común para realizar copias de seguridad de bases de datos es copiar archivos de bases de datos.
Guardado "en frío" de archivos de base de datos
La idea obvia es detener la base de datos y copiar todos sus archivos. Esto se llama copia de seguridad en frío. El método es extremadamente confiable y simple, pero tiene dos inconvenientes obvios:
- a partir de una copia de seguridad en frío, puede restaurar solo el estado de la base de datos que estaba en el momento del cierre; las transacciones realizadas después del reinicio de la base de datos no se incluirán en la copia de seguridad "en frío";
- no todas las bases de datos tienen una ventana tecnológica cuando se puede detener la base de datos.
Si está satisfecho con las copias de seguridad en frío, recuerde que
- «» . , «» , . , Oracle online redo, , , . PostgreSQL , , .
- , . , «» .
«»
La mayoría de las copias de seguridad de bases de datos modernas se realizan copiando los archivos de la base de datos sin detener la base de datos. Aquí se ven varios problemas:
- Al inicio de la copia, es posible que el contenido de la base de datos no coincida con el contenido de los archivos, ya que parte de la información está en la caché y aún no se ha escrito en el disco.
- Durante la copia, el contenido de la base de datos puede cambiar. Si se utilizan estructuras de datos mutables, el contenido de los archivos cambia, y cuando se utilizan estructuras inmutables, el conjunto de archivos cambia: aparecen nuevos archivos y los antiguos se eliminan.
- Dado que la escritura de datos en la base de datos y la lectura de archivos de la base de datos no están sincronizadas de ninguna manera, el programa de respaldo puede leer una página incorrecta, en la que la mitad será de la versión anterior de la página y la otra mitad de la nueva.
Para que el respaldo sea consistente, cada DBMS tiene un comando que informa que el proceso de respaldo ha comenzado. Sintácticamente, este comando puede verse diferente:
- en Oracle es un comando independiente ALTER DATABASE / TABLESPACE BEGIN BACKUP;
- en PostgreSQL, la función pg_start_backup ();
- en Microsoft SQL Server y DB2, la preparación para una copia de seguridad está implícita durante el comando BACKUP DATABASE;
- en MySQL Enterprise, Percoba Server, Cassandra y MongoDB, la preparación la realiza implícitamente una utilidad externa: mysqlbackup, Percona XtraBackup, OpsCenter y Ops Manager, respectivamente.
A pesar de las diferencias sintácticas, el proceso de preparación para una copia de seguridad parece el mismo.
Así es como se ve la preparación para la copia de seguridad en un DBMS con estructuras de disco variables, es decir, en todos los sistemas relacionales de disco tradicionales:
- Se recuerda el momento del inicio de la copia de seguridad; la copia de seguridad deberá contener los registros de la base de datos a partir de ahora.
- Se realiza un punto de control, es decir, todos los cambios que ocurrieron en las páginas de datos hasta ese momento se vacían en el disco. Esto asegura que no se requieran registros antes del inicio de la copia de seguridad durante la recuperación.
- : , , , . , . , . , , .
- , , . , , .
Después de completar todos los procedimientos anteriores, puede copiar los archivos de datos utilizando las herramientas del sistema operativo: cp, rsync y otras. Habilitar el modo de respaldo reduce el rendimiento de la base de datos: en primer lugar, aumenta el volumen de registros y, en segundo lugar, si de repente ocurre una falla en el modo de respaldo, la recuperación tomará más tiempo, ya que los encabezados de los archivos de datos no se actualizan. Cuanto más rápido se complete la copia de seguridad, mejor para la base de datos, por lo que es apropiado utilizar herramientas como una instantánea del sistema de archivos o una ruptura de espejo (BCV) en una matriz de discos. Algunos DBMS (Oracle, PostgreSQL) dejan al administrador la oportunidad de elegir de forma independiente el método de copia,otros (Microsoft SQL Server) proporcionan una interfaz para integrar utilidades de respaldo nativas con sistemas de archivos o motores de almacenamiento.
Cuando se completa la copia de seguridad, es necesario que la base de datos vuelva a su estado normal. En Oracle, esto se hace con el comando ALTER DATABASE / TABLESPACE END BACKUP, en PostgreSQL, llamando a la función pg_stop_backup (), y en otras bases de datos, mediante rutinas internas de los comandos correspondientes o servicios externos.
Así es como se ve la línea de tiempo para el proceso de respaldo:
- La preparación para la copia de seguridad (comenzar la copia de seguridad) lleva tiempo, a veces considerable. Incluso si se utilizan volúmenes duplicados o sistemas de archivos de instantáneas, el proceso de copia de seguridad no será instantáneo.
- Junto con los archivos de datos, es necesario guardar los registros desde el momento en que comenzó la preparación para la copia de seguridad y terminando con el momento en que la base de datos volvió a su estado normal.
- Puede recuperarse de esta copia de seguridad en el momento en que la base de datos vuelva a su estado normal . La recuperación a un momento anterior no es posible.
Con bases de datos que utilizan estructuras de datos inmutables (instantáneas, árboles LSM), la situación es más fácil. La preparación para la copia de seguridad consta de los siguientes pasos:
- Los datos de la memoria se vacían en el disco.
- Se registra la lista de archivos incluidos en la copia de seguridad. Hasta que finalice el proceso de copia de seguridad, la base de datos tiene prohibido eliminar estos archivos, incluso si ya no son necesarios.
Tras una señal sobre el final de la copia de seguridad, una base de datos con estructuras inmutables puede volver a eliminar archivos innecesarios.
Recuperación de puntos
La copia de seguridad le permite restaurar el estado de la base de datos al momento en que se completó el comando para regresar del modo de copia de seguridad. Sin embargo, un desastre que requiera recuperación puede ocurrir en cualquier momento. La tarea de restaurar el estado de la base de datos a un momento arbitrario se denomina "recuperación en un momento determinado".
Para hacer esto, debe guardar los registros de la base de datos desde el momento en que finaliza la copia de seguridad y continuar aplicando los registros a la copia restaurada durante el proceso de restauración. Una vez que la base de datos se restaura a partir de una copia de seguridad al final de la copia, se garantiza que el estado de la base de datos (archivos y páginas en caché) es correcto, por lo que no se necesita un modo de registro especial. Aplicando los registros hasta el momento deseado, puede obtener el estado de la base de datos en cualquier momento.
Si la velocidad de restauración de una copia de seguridad está limitada solo por el ancho de banda del disco, entonces la velocidad de aplicación de los registros generalmente está limitada por el rendimiento del procesador. Si los cambios en la base de datos principal ocurren en paralelo, durante la recuperación, todos los cambios se realizan de forma secuencial, en el orden en que se leyeron del registro. Por lo tanto, el tiempo de recuperación depende linealmente de la distancia entre el punto de recuperación y el punto final de la copia de seguridad. Debido a esto, debe realizar copias de seguridad completas con bastante frecuencia, al menos una vez a la semana para bases de datos con una carga transaccional baja y antes de la copia diaria de bases de datos muy cargadas.
Copias de seguridad incrementales
Para acelerar la recuperación punto a punto, me gustaría poder realizar copias de seguridad con la mayor frecuencia posible, pero al mismo tiempo no ocupar espacio adicional en el disco y no sobrecargar la base de datos con tareas de copia de seguridad.
La solución al problema es una copia de seguridad incremental, es decir, copiar solo aquellas páginas de datos que han cambiado desde la copia de seguridad anterior.
Las copias de seguridad incrementales solo tienen sentido para los DBMS que utilizan estructuras de datos mutables.
El incremento se puede calcular tanto a partir de la copia de seguridad completa (copia acumulativa) como de cualquier copia anterior (copia diferencial).
Desafortunadamente, no existe una terminología uniforme y los diferentes fabricantes utilizan términos diferentes:
| Diferencial | Acumulativo
|
|
|---|---|---|
| Oráculo | Diferencial | Acumulativo |
| PostgresPro | Incremental | - |
| Microsoft SQL Server | - | Diferencial |
| IBM DB2 | Delta | Incremental |
| MySQL Enterprise | Incremental | Diferencial |
| Servidor Percona | Incremental | |
Con las copias de seguridad incrementales, el proceso de restauración punto a punto tiene este aspecto:
- la última copia de seguridad completa realizada antes de restaurar la restauración;
- las copias incrementales se restauran sobre la copia completa;
- rueda los registros desde el punto de inicio de la copia de seguridad hasta el punto de recuperación.
Tener una copia acumulativa acelera el proceso de recuperación. Entonces, por ejemplo, para restaurar el estado base a un punto entre T3 y T4, es necesario restaurar dos copias incrementales y restaurar a un punto después de T4, solo una.
Obviamente, el volumen de una copia acumulativa es menor que el volumen de varias copias diferenciales, porque algunas páginas han cambiado varias veces y cada copia incremental contiene su propia versión de la página.
Hay tres formas de crear una copia incremental:
- crear una copia completa y calcular la diferencia con la copia completa anterior;
- analizar registros, crear una lista de páginas modificadas y realizar copias de seguridad de las páginas incluidas en la lista;
- solicitud de páginas cambiadas en la base de datos.
El primer método ahorra espacio en disco, pero no resuelve el problema de reducir la carga en la base de datos. Además, si tenemos una copia de seguridad completa, convertirla en una copia de seguridad incremental no tiene sentido, ya que restaurar una copia de seguridad completa es más rápido que restaurar una copia completa anterior y un incremento. Con este enfoque, es mejor trasladar la tarea de ahorrar espacio en disco a componentes especiales con mecanismos de deduplicación integrados. Estos pueden ser sistemas de almacenamiento especiales (EMC DataDomain, HPE StorageWorks VLS, toda la línea de NetApp) o productos de software (ZFS, Veritas NetBackup PureFile, Deduplicación de datos de Windows Server).
El segundo y tercer método difieren en el mecanismo para determinar la lista de páginas cambiadas. El análisis de los registros requiere más recursos, y además necesita conocer la estructura de los archivos de registro para implementarlo. Es más fácil preguntar a la propia base de datos qué páginas han cambiado, pero para esto el kernel DBMS debe tener la funcionalidad de rastrear los bloques cambiados (rastreo de cambios de bloque).
La funcionalidad de copia de seguridad incremental se introdujo por primera vez con el software Oracle Recovery Manager (RMAN), que se introdujo con la versión Oracle 8i. Oracle implementó inmediatamente el seguimiento de bloques modificados, por lo que no es necesario analizar los registros.
PostgreSQL no rastrea los bloques modificados, por lo que la utilidad pg_probackup, desarrollada por la empresa rusa Postgres Professional, detecta las páginas modificadas analizando el registro. Sin embargo, la compañía también ofrece PostgresPro, que incluye una extensión ptrack que rastrea los cambios de página. Cuando se usa pg_probackup con PostgresPro, la utilidad consulta la base de datos en busca de páginas modificadas, tal como lo hace RMAN.
Microsoft SQL Server, como Oracle, rastrea las páginas modificadas, pero el comando BACKUP solo permite respaldos completos y acumulativos.
DB2 tiene la capacidad de realizar un seguimiento de las páginas cambiadas, pero está deshabilitado de forma predeterminada. Una vez habilitado, DB2 permitirá copias de seguridad completas, diferenciales y acumulativas.
Una diferencia importante entre las herramientas descritas en esta sección (excepto pg_probackup) y las herramientas de respaldo basadas en archivos es que consultan la base de datos en busca de imágenes de página en lugar de leer los datos del disco ellos mismos. La desventaja de este enfoque es la pequeña carga adicional en la base. Sin embargo, este inconveniente está más que compensado por el hecho de que la página leída siempre es correcta, por lo que no es necesario habilitar un modo de registro en diario especial durante la copia de seguridad.
Tenga en cuenta nuevamente que la presencia de copias de seguridad incrementales no reemplaza el requisito de que los registros se restauren en un punto arbitrario en el tiempo. Por lo tanto, en las bases de datos industriales, los registros se reescriben constantemente en medios externos y las copias de seguridad, completas y / o incrementales, se crean según una programación.
La mejor implementación de la idea de la copia de seguridad incremental en la actualidad es el dispositivo Zero Data Loss Recovery Appliance (sistema diseñado en terminología de Oracle), una solución especializada de Oracle para realizar copias de seguridad de su propia base de datos. El complejo es un grupo de servidores con un gran volumen de discos, en los que se instala una versión modificada del software Recovery Manager y puede funcionar tanto con otros complejos de software y hardware de Oracle (Database Appliance, Exadata, SPARC Supercluster) como con bases de datos de Oracle en la infraestructura tradicional. A diferencia de RMAN "regular", ZDLRA implementa el concepto de "incremental para siempre". El sistema crea una copia completa de la base de datos solo una vez y luego solo hace copias incrementales. Los módulos RMAN adicionales le permiten combinar copias,creando nuevas copias completas a partir de las incrementales.
Para crédito de los desarrolladores rusos, cabe señalar que pg_probackup también puede combinar copias incrementales.
A diferencia de muchas preguntas similares, la pregunta "qué método de copia de seguridad es mejor" tiene una respuesta inequívoca: la mejor es la utilidad nativa para el DBMS usado que brinda la capacidad de realizar copias de seguridad incrementales.
Para el DBA, los problemas de elegir una estrategia de respaldo y la integración de los respaldos de la base de datos en la infraestructura corporativa son mucho más importantes. Pero estas preguntas están más allá del alcance de este artículo.