– Oh, ningún refugio puede resistir el impacto de un meteorito. Pero tú, como todos, tienes una reserva, así que no tienes de qué preocuparte.
Stanislav Lem, “Diarios estelares de Ijon el Tranquilo”
La copia de seguridad se refiere a guardar una copia de los datos en algún lugar fuera de su ubicación de almacenamiento principal.
El objetivo principal de la copia de seguridad es restaurar los datos después de que se hayan perdido. En este sentido, a menudo se escucha que si tiene una réplica de la base de datos, siempre puede restaurar los datos desde ella y no es necesario realizar una copia de seguridad. De hecho, la copia de seguridad le permite resolver al menos tres problemas que no se pueden resolver utilizando 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 administrador de base de datos destruyó un espacio de tabla. Ambas operaciones son completamente legales desde el punto de vista de la base de datos y el proceso de replicación las reproducirá en la base de datos réplica.
En segundo lugar, los DBMS modernos son sistemas de software muy fiables, pero ocasionalmente se producen daños en las estructuras internas de las bases de datos, tras lo cual se pierde el acceso a los datos. Lo que es especialmente ofensivo es que dicha infracción suele ocurrir con una carga elevada o al instalar algún tipo de actualización. Pero tanto la carga elevada como las actualizaciones periódicas indican que la base de datos no es de ninguna manera 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 la clonación de bases de datos, por ejemplo, con fines de prueba.
La copia de seguridad de la base de datos se basa de una forma u otra en uno de dos principios:
- Muestreo de datos y posterior guardado en formato personalizado;
- Instantánea de archivos de bases 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 incluidas con cualquier DBMS debe incluir herramientas para cargar y cargar datos. Los datos se almacenan en formato de texto o en un formato binario específico de un DBMS en particular. La siguiente tabla proporciona una lista de dichas herramientas:
formato binario
Formato de texto
el
Exportación de DataPump/Importación de DataPump
Exportación / Importación
SQL*Plus/SQL*Cargador
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
mongoexportar/mongoimportar
Cassandra
instantánea de nodetool/sstableloader
cqlsh
Lo bueno del formato de texto es que puede ser editado o incluso creado por programas externos, y el formato binario, a su vez, es bueno porque permite cargar y descargar datos más rápido ahorrando 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 de datos 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 se complete la descarga, ya no será relevante;
- Es casi imposible realizar una descarga coordinada de toda la base de datos bajo una carga elevada, ya que el DBMS se ve obligado a almacenar una instantánea de su estado en el momento en que comienza la descarga. Cuantas más transacciones se hayan completado desde el inicio de la carga, mayor será el tamaño de la instantánea (copias irrelevantes de datos en PostgreSQL, espacio para deshacer en Oracle, tempdb en Microsoft SQL Server, etc.);
- la descarga preserva la estructura lógica de los datos, pero no preserva su estructura física: parámetros del almacenamiento físico de tablas, índices, etc.
Sin embargo, cargar también tiene sus ventajas:
- alta selectividad: puede descargar tablas individuales, campos individuales e incluso filas individuales;
- los datos descargados se pueden cargar en una base de datos de otra versión, y si la descarga se realiza en formato de texto, entonces en otra base de datos.
Por lo tanto, la carga 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 de copia de seguridad de una base de datos es copiar archivos de base de datos.
Almacenamiento en frío de archivos de bases de datos
La idea obvia es detener la base de datos y copiar todos sus archivos. Esta copia de seguridad se denomina copia de seguridad "en frío". El método es extremadamente fiable y sencillo, pero tiene dos inconvenientes evidentes:
- Desde una copia de seguridad “en frío”, solo se puede restaurar el estado de la base de datos que se encontraba 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 “fría”;
- No todas las bases de datos tienen una ventana tecnológica en la que se puede detener la base de datos.
Si la copia de seguridad "en frío" le conviene, debe recordar que
- La copia en frío a veces debe incluir registros. Los métodos para determinar los registros que deben incluirse en la copia "fría" son individuales para cada DBMS. Por ejemplo, en Oracle es necesario copiar el llamado rehacer en línea, es decir, un número fijo de archivos de registro en un directorio especial, incluso cuando la base de datos se detiene correctamente. En PostgreSQL, debe guardar todos los registros comenzando con el registro que contiene el último punto de control, cuya información está contenida en el archivo de control.
- El directorio de la base de datos puede contener archivos de espacios de tablas temporales que sean lo suficientemente grandes como para no necesitar incluirlos en la copia de seguridad. Por cierto, esta observación también es válida para las copias de seguridad en caliente.
Guardar archivos en caliente
La mayoría de las copias de seguridad de bases de datos modernas se realizan copiando archivos de bases de datos sin detener la base de datos. Hay varios problemas aquí:
- Cuando comienza 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 el 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 archivos nuevos y se eliminan los antiguos.
- Dado que la escritura de datos en la base de datos y la lectura de archivos de la base de datos no están sincronizados de ninguna manera, el programa de respaldo puede leer una página incorrecta, en la cual la mitad será de la versión anterior de la página y la otra mitad de la nueva.
Para que la copia de seguridad sea consistente, cada DBMS tiene un comando que notifica que el proceso de copia de seguridad ha comenzado. Sintácticamente, este comando puede verse diferente:
- en Oracle este es un comando separado ALTER DATABASE/TABLESPACE BEGIN BACKUP;
- en PostgreSQL – función pg_start_backup();
- En Microsoft SQL Server y DB2, la preparación para la copia de seguridad se realiza implícitamente durante la ejecución del comando BACKUP DATABASE;
- en MySQL Enterprise, Cassandra y MongoDB, la preparación la realiza implícitamente una utilidad externa: mysqlbackup, OpsCenter y Ops Manager, respectivamente.
A pesar de las diferencias de sintaxis, 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 mutables, es decir, en todos los sistemas relacionales de disco tradicionales:
- Se recuerda el momento en que se inició la copia de seguridad; la copia de seguridad deberá contener registros de la base de datos a partir de este momento.
- Se realiza un punto de control, es decir, todos los cambios que ocurrieron en las páginas de datos antes del momento recordado se descargan en el disco. Esto garantiza que no se necesiten registros antes de que comience la copia de seguridad durante la recuperación.
- Se habilita un modo de registro especial: si una página de datos ha cambiado por primera vez después de cargarla desde el disco, en lugar de escribir los cambios de página en el registro, la base de datos escribirá la página completa allí. Al realizar el procedimiento de preparación, todas las páginas se vacían en el disco, por lo que la primera vez que se realiza un cambio, el bloque completo siempre se escribirá en el registro. Pero si la página se expulsa al disco nuevamente durante el proceso de copia de seguridad, el siguiente cambio también dará como resultado que aparezca una copia completa de la página en el registro. Esto garantiza que si la página resulta incorrecta al copiar un archivo de datos, la aplicación de un registro hará que sea correcta nuevamente.
- Se bloquean los cambios en los encabezados del archivo de datos, es decir, aquella parte del mismo cuyos cambios no se reflejan en los registros. Esto garantiza que el encabezado se copie correctamente y luego los registros se apliquen correctamente al archivo de datos.
Una vez completados todos los procedimientos anteriores, puede copiar archivos de datos utilizando las herramientas del sistema operativo: cp, rsync y otras. Habilitar el modo de copia de seguridad reduce el rendimiento de la base de datos: en primer lugar, el volumen de registros aumenta y, en segundo lugar, si de repente ocurre una falla en el modo de copia de seguridad, la recuperación tardará más porque 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 romper el espejo (BCV) en la 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 sus propias utilidades de respaldo con sistemas de archivos o mecanismos de almacenamiento.
Una vez que se completa la copia de seguridad, debe devolver la base de datos 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 del proceso de respaldo:
- La preparación de una copia de seguridad lleva tiempo, a veces un tiempo considerable. Incluso si se utilizan volúmenes reflejados o sistemas de archivos con capacidad de instantáneas, el proceso de copia de seguridad no será instantáneo.
- Junto con los archivos de datos, es necesario guardar registros desde el momento en que comienza la preparación para la copia de seguridad hasta el momento en que la base de datos vuelve a su estado normal.
- Puedes restaurar desde esta copia de seguridad en el momento en que la base vuelve a su estado normal. No es posible restaurar a un punto anterior.
Con bases de datos que utilizan estructuras de datos inmutables (instantáneas de memoria, árboles LSM), la situación es más sencilla. La preparación para una 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 se complete el proceso de copia de seguridad, la base de datos tiene prohibido eliminar estos archivos, incluso si ya no son necesarios.
Tras la señal de que la copia de seguridad está completa, la base de datos con estructuras inmutables puede volver a eliminar archivos innecesarios.
Recuperación al punto
Una copia de seguridad le permite restaurar el estado de la base de datos al momento en que se completó el comando de retorno desde el modo de copia de seguridad. Sin embargo, un accidente que requiera recuperación puede ocurrir en cualquier momento. La tarea de restaurar el estado de una base de datos en un momento arbitrario se denomina "recuperación de un momento dado".
Para garantizar que esto sea posible, debe guardar los registros de la base de datos desde el final de la copia de seguridad y, durante el proceso de recuperación, continuar aplicando los registros a la copia restaurada. Después de restaurar la base de datos a partir de una copia de seguridad en el momento en que se completa la copia, se garantiza que el estado de la base de datos (archivos y páginas en caché) será correcto, por lo que no se necesita un modo de registro especial. Al aplicar registros en el momento adecuado, puede obtener el estado de la base de datos en cualquier momento.
Si bien la velocidad a la que se puede restaurar una copia de seguridad está limitada únicamente por el ancho de banda del disco, la velocidad a la que se pueden aplicar los registros suele estar limitada por el rendimiento del procesador. Si los cambios se producen en paralelo en la base de datos principal, durante la recuperación todos los cambios se realizan de forma secuencial, en el orden en que se leen del registro. Por lo tanto, el tiempo de recuperación depende linealmente de qué tan lejos esté el punto de recuperación del punto final de la copia de seguridad. Debido a esto, es necesario realizar copias de seguridad completas con bastante frecuencia: al menos una vez a la semana para bases de datos con una pequeña carga de transacciones y hasta copias diarias de bases de datos muy cargadas.
Respaldo incremental
Para acelerar la recuperación hasta cierto 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 cargar la base de datos con tareas de copia de seguridad.
La solución al problema es la copia de seguridad incremental, es decir, copiar sólo aquellas páginas de datos que han cambiado desde la copia de seguridad anterior.
Las copias de seguridad incrementales sólo tienen sentido para los DBMS que utilizan estructuras de datos mutables.
El incremento se puede contar desde una copia de seguridad completa (copia acumulativa) o desde cualquier copia anterior (copia diferencial).
Desafortunadamente, no existe una terminología uniforme y los diferentes fabricantes utilizan términos diferentes:
diferencial
Acumulativo
el
Diferencial
Acumulativo
PostgreSQL
Incremental
-
Microsoft SQL Server
-
Diferencial
IBM DB2
Delta
Incremental
Si hay copias incrementales, el proceso de restauración a un punto es el siguiente:
- la última copia de seguridad completa realizada antes de restaurar la restauración;
- las copias incrementales se restauran encima de la copia completa;
- Los registros se acumulan 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 de la base de datos a un punto entre T3 y T4, es necesario restaurar dos copias incrementales, y para restaurar a un punto posterior a T4, solo una.
Obviamente, el tamaño de una copia acumulativa es menor que el tamaño de varias copias diferenciales, porque algunas páginas han cambiado varias veces y cada copia incremental contiene una versión diferente 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;
- Consultar páginas modificadas 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, no tiene sentido convertirla en una incremental, ya que restaurar una copia completa es más rápido que restaurar la copia completa anterior y aumentarla. Con este enfoque, es mejor trasladar la tarea de ahorrar espacio en disco a componentes especiales con mecanismos de deduplicación integrados. Pueden ser sistemas de almacenamiento especiales (EMC DataDomain, HPE StorageWorks VLS, toda la línea NetApp) o productos de software (ZFS, Veritas NetBackup PureFile, Windows Server Data Deduplication).
El segundo y tercer método difieren en el mecanismo para determinar la lista de páginas modificadas. El análisis de registros requiere más recursos y, además, para implementarlo es necesario conocer la estructura de los archivos de registro. La forma más sencilla es preguntar a la propia base de datos qué páginas han cambiado, pero para ello el kernel del DBMS debe tener una función de seguimiento de cambios en bloque.
La funcionalidad de copia de seguridad incremental se introdujo por primera vez en el software Oracle Recovery Manager (RMAN), introducido en la versión Oracle 8i. Oracle implementó inmediatamente el seguimiento de los 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, determina las páginas modificadas analizando el registro. Sin embargo, la empresa también suministra el DBMS PostgresPro, que incluye la extensión ptrack que rastrea los cambios de página. Cuando se usa pg_probackup con PostgresPro DBMS, la utilidad solicita páginas cambiadas desde la propia base de datos, exactamente igual que RMAN.
Microsoft SQL Server, al igual que Oracle, rastrea las páginas modificadas, pero el comando BACKUP solo le permite realizar copias de seguridad completas y acumulativas.
DB2 tiene la capacidad de realizar un seguimiento de las páginas modificadas, pero está deshabilitada 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 copia de seguridad de archivos es que solicitan imágenes de páginas de la base de datos en lugar de leer datos del disco. La desventaja de este enfoque es una pequeña carga adicional sobre la base. Sin embargo, este inconveniente se compensa con creces por el hecho de que la página leída siempre es correcta, por lo que no es necesario habilitar un modo de registro especial durante la copia de seguridad.
Tenga en cuenta nuevamente que la presencia de copias incrementales no elimina el requisito de tener registros disponibles para su recuperación en un momento arbitrario. 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 actual de la idea de las copias de seguridad incrementales es Zero Data Loss Recovery Appliance, un sistema de hardware y software (en la terminología de Oracle, un sistema de ingeniería), una solución especializada de Oracle para realizar copias de seguridad de su propia base de datos. El sistema es un clúster. servidores ZDLRA cuenta con una gran capacidad de disco y ejecuta una versión modificada del software Recovery Manager. Es compatible con otros sistemas de hardware y software de Oracle (Database Appliance, Exadata, SPARC Supercluster), así como con bases de datos Oracle que se ejecutan en infraestructuras tradicionales. A diferencia del RMAN convencional, ZDLRA implementa el concepto de "incremental permanente". El sistema crea una copia completa de la base de datos una vez y, posteriormente, solo realiza copias incrementales. Los módulos adicionales de RMAN permiten fusionar copias, creando nuevas copias completas a partir de copias incrementales.
Para crédito de los desarrolladores rusos, cabe señalar que pg_probackup también puede fusionar copias incrementales.
A diferencia de muchas preguntas similares, la pregunta "qué método de copia de seguridad es mejor" tiene una respuesta clara: la mejor opción es una utilidad nativa del DBMS que se utiliza, que brinda la posibilidad de realizar copias de seguridad incrementales.
Para el administrador de la base de datos, mucho más importantes son las cuestiones de elegir una estrategia de respaldo e integrar las herramientas de respaldo de la base de datos en la infraestructura corporativa. Pero estas preguntas están más allá del alcance de este artículo.
Fuente: habr.com
