Comprobación de la integridad de los datos después de la restauración

Restaurar una base de datos no siempre es fácil: parece que todo fue bien, pero luego aparecen errores en los logs, algunas tablas desaparecen o los datos se ven raros. Por eso es tan importante comprobar después de la restauración si realmente todo está bien.

A veces, parte de los datos simplemente no se restauran — por ejemplo, si la copia de seguridad estaba dañada. Puede pasar que la estructura de las tablas se desordene: desaparecen claves foráneas, se pierden índices o aparecen valores extraños. Incluso si a primera vista todo parece normal, los logs pueden insinuar que la base realmente no está del todo sana.

La comprobación de integridad es como una revisión técnica después de una reparación. Mejor dedicarle un poco de tiempo y asegurarte de que todo funciona, que luego encontrarte con un problema en producción de repente.

Análisis de los logs de restauración

Cuando restauras datos usando pg_restore, PostgreSQL siempre genera un log. El log contiene mucha información útil sobre el proceso de restauración, incluyendo avisos y errores. Aquí tienes un ejemplo de comando indicando el archivo de log:

pg_restore -U username -d database_name backup_file.dump > restore_log.txt 2>&1

Fíjate en > restore_log.txt 2>&1 — esto redirige tanto la salida estándar como los errores a un solo archivo.

¿Qué buscar en los logs?

1. Errores. Presta atención a palabras clave como "ERROR" o "FATAL". Ejemplo:

   ERROR:  relation "students" does not exist
   

2. Avisos. A veces puedes ver avisos "WARNING". Aunque no son críticos, deberías leerlos — pueden estar avisando de problemas:

   WARNING:  no privileges could be granted for table "grades"
   

3. Incongruencias de datos. Comprueba si se restauraron todos los objetos clave: tablas, índices, claves foráneas.

Comprobación rápida usando grep

Si el archivo de log es demasiado largo (y a veces son como "Guerra y Paz"), puedes usar grep para buscar palabras clave:

grep -i "error" restore_log.txt
grep -i "warning" restore_log.txt

Análisis de errores de los logs

Vamos a ver un ejemplo real de un log:

ERROR:  constraint "fk_student_course" for relation "enrollments" does not exist
DETAIL:  Key (course_id)=(2) is not present in table "courses".

¿Qué nos dice este error? Significa que PostgreSQL intenta restaurar una fila en la tabla enrollments, pero no existe el course_id correspondiente en la tabla courses.

¿Cómo solucionarlo? Puede que los datos en la tabla courses estén dañados o no se hayan restaurado. Tendrás que añadir manualmente las filas que faltan o repetir la restauración.

Uso de checksums para comprobar la integridad

Si quieres estar seguro de que el archivo de backup no está dañado antes o después de la restauración, puedes usar checksums.

Un checksum es un número pequeño que representa los datos de un archivo. Si el archivo cambia aunque sea un bit, su checksum también cambia. Esto ayuda a saber si el archivo se ha dañado.

Para crear un checksum puedes usar la utilidad md5sum. Ejemplo de comando:

md5sum backup_file.dump

El resultado se verá así:

4c9b5f5d31ae2b53e9e3d56dfedc3fe4  backup_file.dump

Comparación de checksums

Si guardaste el checksum del archivo de antemano, puedes compararlo con el actual:

md5sum -c checksum.md5

El archivo checksum.md5 debe contener una línea con el checksum y el nombre del archivo:

4c9b5f5d31ae2b53e9e3d56dfedc3fe4  backup_file.dump

Si el checksum coincide, verás el mensaje OK. Si no — el archivo está dañado.

Comprobación de datos a nivel de base

Los checksums y los logs están bien, pero ¿cómo comprobar que los datos en sí están bien? Aquí tienes una lista de acciones estándar:

1. Comparar el número de filas

Compara el número de filas en las tablas antes y después de la restauración. Por ejemplo:

-- Contar el número de filas en la tabla students
SELECT COUNT(*) FROM students;

Si el número de filas es diferente, la restauración no fue completa.

2. Comprobar la integridad de las claves

Comprueba las relaciones entre tablas para asegurarte de que todas las claves foráneas funcionan:

-- Comprobar estudiantes inscritos en cursos
SELECT *
FROM enrollments e
LEFT JOIN courses c
ON e.course_id = c.course_id
WHERE c.course_id IS NULL;

Si la consulta devuelve resultados, significa que en la tabla enrollments hay filas con cursos que faltan.

3. Comparar datos con el original

Si tienes una copia de los datos (por ejemplo, un dump de otra base), puedes comparar los resultados:

-- Comprobar datos de la tabla courses
SELECT * FROM courses WHERE course_id NOT IN (
  SELECT course_id FROM courses_backup
);

Casos reales de restauración

Un caso de la vida real: una vez el administrador de SGBD Bob decidió restaurar datos de una copia de seguridad después de un fallo del servidor. Ejecutó el comando:

pg_restore -U admin -d my_database my_backup.dump

Pero al analizar los logs, la restauración terminó con error:

ERROR:  could not create file "base/16385/pg_internal.init": No space left on device

Esto significaba que se había quedado sin espacio en disco. Después de liberar espacio y repetir la restauración, también descubrió que no todas las tablas se habían restaurado. Por suerte, gracias a los checksums generados previamente y la configuración de la archivación WAL, Bob pudo restaurar completamente la base de datos.

Resumen de la comprobación de integridad

Al terminar la comprobación de la integridad de los datos después de la restauración, haz lo siguiente:

1. Revisa los logs en busca de errores y avisos.
2. Usa checksums para asegurarte de que los archivos no están dañados.
3. Compara los datos de la base en cuanto a número de filas e integridad de relaciones.
4. Si algo salió mal, revisa los errores y repite el proceso de restauración.

Ahora ya estás listo para hacer una comprobación a fondo y asegurarte de que los datos se restauraron tal como esperabas. ¡Porque lo más importante en la administración de bases de datos es tener confianza en tu backup!