Recuperación de datos después de un fallo

Los fallos pueden ser de todo tipo: fallos de hardware, cortes de luz, bugs en el código o, lo que pasa bastante a menudo, el borrado accidental de la base de datos por un admin despistado que decidió limpiar "algo viejo". En estas situaciones, los backups y un proceso de recuperación bien practicado se convierten en tu "varita mágica".

Vamos a desglosar el proceso de recuperación paso a paso, como si montáramos un mueble de IKEA: sin pánico y siguiendo la guía al pie de la letra.

Paso 1. Analizar la causa del fallo

Antes de lanzarte a toda velocidad a restaurar datos, es importante entender qué ha pasado exactamente.

1. ¿Error de la aplicación o de la base de datos?
   Revisa los logs de tu aplicación y de PostgreSQL (normalmente los puedes encontrar en /var/log/postgresql/ o en un directorio similar según tu SO). Busca indicadores de errores.

2. ¿Fallo de hardware?
   Si el servidor está físicamente dañado (por ejemplo, problemas con el disco duro), primero asegúrate de que el hardware está bien. Si tu disco está roto, conecta otro y restaura todo desde ahí.

3. ¿Problemas de red o de acceso?
   Si el fallo es por la red — probablemente tu servidor aún no necesita operaciones de recuperación.

4. Factor humano:
   Confiesa... ¿alguien hizo DROP DATABASE? Si es así, todavía tenemos una oportunidad de restaurar los datos desde un backup.

Recuerda que entender bien la causa del fallo ayuda a evitarlo en el futuro.

Paso 2. Comprobar la disponibilidad de los backups

Es hora de asegurarnos de que tenemos el backup correcto. Busca los backups más recientes de la base de datos que creaste usando pg_dump o pg_basebackup. Comprueba su integridad. Si aún no sabes cómo hacerlo, aquí va un recordatorio rápido:

• Usa el comando ls -l para comprobar el tamaño de tus archivos. Si el archivo es sospechosamente pequeño, puede ser señal de problemas.
• Comprueba el archivo con el comando file. Por ejemplo:

  file backup_file.sql
  

  Deberías ver información sobre el archivo indicando que es un volcado SQL.

Para un archivo tar comprueba que se puede extraer:

tar -tf backup.tar

¿Sin errores? ¡Perfecto! Podemos seguir.

Paso 3. Parar PostgreSQL

Antes de empezar la recuperación es importante parar el servidor de PostgreSQL para asegurar el proceso. Hazlo con el siguiente comando (como admin del servidor):

sudo systemctl stop postgresql

Parar la base de datos garantiza que ningún proceso moleste la restauración.

Paso 4. Preparar una nueva base de datos para la recuperación

Si tu base de datos fue borrada o dañada por completo, primero créala de nuevo. Ejemplo de comando:

createdb -U postgres new_database

Sustituye new_database por el nombre de tu base.

Paso 5. Restaurar el backup

Veamos dos escenarios principales de recuperación:

1. Si usas un backup SQL (pg_dump): Para restaurar usa el comando

   psql -U username -d new_database -f backup_file.sql
   

• username — tu usuario de PostgreSQL.
• new_database — la base de datos donde se importarán los datos.
• backup_file.sql — tu archivo de backup.

2. Si usas un backup binario (pg_basebackup o pg_dump con custom):
   Para restaurar usa:
   

   pg_restore -U username -d new_database backup_file.dump
   

   Ojo que estos backups no son en texto, sino que contienen datos "empaquetados".

Extra:

• Si el backup solo tiene datos, usa --data-only.
• Si solo necesitas restaurar la estructura, añade --schema-only.

Paso 6. Arrancar PostgreSQL y hacer pruebas

Después de ejecutar el comando de restauración, arranca el servidor:

sudo systemctl start postgresql

Ahora hay que hacer pruebas. Intenta conectarte a la base restaurada con psql o pgAdmin. Haz algunas consultas para comprobar que los datos están bien:

SELECT * FROM your_table_name LIMIT 10;

Si todo se ve bien, ¡enhorabuena: los datos están restaurados!

Paso 7. Comprobar la integridad de los datos

Después de restaurar es importante comprobar que los datos son íntegros. Por ejemplo:

1. Compara el número de filas en las tablas con los backups:

   SELECT COUNT(*) FROM your_table_name;
   

   Compara el resultado con los registros del backup (si los tienes).

2. Usa checksums: Si antes creaste checksums para las tablas, ahora es el momento de compararlos:

   md5sum backup_file.sql
   

3. Comprueba las relaciones entre tablas: Asegúrate de que las relaciones restauradas FOREIGN KEY funcionan bien.

Paso 8. Testear la aplicación

Ahora comprueba que tu aplicación que usa esta base de datos funciona bien. Prueba los escenarios principales. ¿Hay errores? ¿Todo se muestra bien?

Ejemplos reales de errores de recuperación

Ahora vamos a ver algunos casos para mostrar cómo evitar problemas:

1. Incompatibilidad de versiones de PostgreSQL.
   Imagina que el backup se hizo en la versión 12 y el servidor se actualizó a la versión 15. Al restaurar te saldrán errores.
   Solución: usa la misma versión de PostgreSQL que para crear el backup, o consulta la documentación sobre compatibilidad: PostgreSQL Documentation.

2. Backup dañado . Si tu backup estaba dañado, puedes perder parte de los datos.
   Solución: usa replicación de backups (por ejemplo, guarda varias versiones).

3. Error al restaurar una tabla concreta.
   Si restauras una tabla concreta pero faltan dependencias (por ejemplo, claves externas), el proceso puede fallar.
   Solución: siempre restaura las tablas en el orden correcto, empezando por las parentales.