Copias dentro del gestor

Las copias de una base de datos se clasifican por dos ejes independientes, y se pueden combinar. El primero es si la base está parada o en servicio mientras se copia.

• Copia en frío: se para el servicio y se copia con la base cerrada. Es la más simple y la más segura de interpretar, porque nada cambia mientras se copia. Su precio es la interrupción, que en un servicio disponible todo el día no suele ser aceptable.
• Copia en caliente: se hace con la base abierta y trabajando. Exige que el gestor colabore, marcando el punto de partida y guardando los cambios que ocurren durante la copia para que el resultado sea coherente. Es lo normal hoy, y es lo que hacen Data Pump, mysqldump o pg_dump.

El segundo eje es qué se copia exactamente.

• Copia lógica: se extrae el contenido en forma de sentencias o de un fichero de exportación. Es portable entre versiones y hasta entre máquinas de distinta arquitectura, permite recuperar una sola tabla y sirve para migrar. A cambio es lenta de restaurar en bases grandes, porque hay que volver a insertar y a reconstruir los índices.
• Copia física: se lleva los ficheros del gestor tal cual, bloque a bloque. Es mucho más rápida en volúmenes grandes y es la base de la recuperación de una instalación entera. A cambio está atada a la versión y a la plataforma, y no permite sacar una tabla suelta con facilidad.

El puente entre las copias y la recuperación fina es el registro de transacciones, que ya apareció en «El oficio del DBA» con nombres distintos según el producto: ficheros de rehacer y de archivo en Oracle, registro de escritura anticipada en PostgreSQL, y fichero .ldf en SQL Server. Si se conserva ese registro además de la copia, se puede restaurar la copia y después reproducir los cambios hasta un instante elegido, justo antes del error. Es lo que se llama recuperación a un punto en el tiempo, y es lo que salva de un borrado accidental a las once y cuarto cuando la última copia es de las tres de la madrugada.

La copia da el punto de partida y el registro de transacciones da el trayecto. Sin conservar el registro, lo mejor a lo que se puede volver es al momento de la última copia.

Oracle separa las dos familias del punto anterior en dos herramientas distintas, y esa es la comparación que se pregunta.

RMAN se maneja desde su propia línea de mandatos y admite copiar la base entera o solo un tablespace, ponerle una etiqueta para localizarla después, indicar dónde se deja el fichero y acotar un intervalo de tiempo para las operaciones de recuperación.

RMAN> BACKUP TABLESPACE ts_intentos
        FORMAT '/respaldo/oracle/%U'
        TAG 'intentos_semanal';

Data Pump son dos programas del sistema operativo: uno exporta y otro importa. Trabaja en caliente, es decir con la base en servicio, y sustituyó a las utilidades clásicas de exportación e importación.

RMAN es copia física y es la herramienta de respaldo y recuperación. Data Pump es copia lógica y es la herramienta de movimiento de datos. No compiten: se usan para cosas distintas.

Antes del primer volcado hay un paso que suele olvidarse y que explica la mitad de los errores con esta herramienta: Data Pump no escribe en una ruta cualquiera, escribe en un objeto de la base de datos llamado directorio, que apunta a una carpeta de la máquina del SERVIDOR, no de la máquina desde la que se lanza el mandato. Hay que crear la carpeta en el sistema operativo, registrarla como objeto y dar permiso de lectura y escritura sobre ella al usuario que va a hacer la copia. Existe además uno predefinido, DATA_PUMP_DIR, que es el que se usa si no se indica otro.

CREATE DIRECTORY respaldo AS '/respaldo/oracle';
GRANT READ, WRITE ON DIRECTORY respaldo TO intentos_owner;

Con eso resuelto, la forma general de la exportación pide credenciales, el fichero de volcado, el fichero de registro y las opciones que acotan el alcance: la base completa, un esquema concreto o una lista de tablas.

expdp usuario/clave dumpfile=fichero.dmp logfile=fichero.log opciones

expdp system/clave directory=respaldo \
      dumpfile=esquema_intentos.dmp \
      logfile=esquema_intentos.log \
      schemas=INTENTOS_OWNER

La importación es simétrica y usa el mismo directorio y el mismo fichero de volcado.

impdp system/clave directory=respaldo \
      dumpfile=esquema_intentos.dmp

En los dos gestores libres la copia de referencia es lógica y el resultado es un fichero de texto con sentencias SQL: las de creación de los objetos y las de inserción de las filas. Tiene la virtud de que se puede abrir, leer y editar, y el inconveniente de que restaurar una base grande significa ejecutar millones de sentencias.

# MySQL y MariaDB: copiar y restaurar
mysqldump -u root -p --databases llegando --add-drop-database > llegando.sql
mysql -u root -p llegando < llegando.sql

# PostgreSQL: copiar y restaurar
pg_dump llegando > llegando.sql
psql llegando < llegando.sql

Con la restauración de MySQL hay un detalle que se pregunta: el guion restaura el contenido, pero la base de destino tiene que existir. O bien se crea a mano antes, o bien la copia se hizo de manera que el propio fichero incluya la creación de la base y su selección. Es lo que consigue la opción que añade el borrado previo de la base junto con su creación.

PostgreSQL añade dos matices propios. Uno es la copia de todo el servidor, que incluye los objetos globales como los roles y que por eso es la única forma de reconstruir una instalación entera desde una copia lógica. El otro es el formato propio, que no es texto sino un contenedor comprimido, permite restaurar objetos sueltos y hacerlo en paralelo, y exige el restaurador específico.

pg_dump copia una base; pg_dumpall copia el servidor entero incluidos los roles. En MySQL, la base de destino tiene que existir antes de restaurar, salvo que el propio guion la cree.