Qué hacer si tu copia de seguridad está dañada

Sheet happens. En la lección anterior también vimos el proceso paso a paso para restaurar completamente una base de datos después de un fallo. Pero la realidad siempre trae sorpresas. ¿Qué hacer si tu copia de seguridad resulta estar dañada? Pues ha llegado el momento de enfrentarse a esto.

¿Dónde es mejor poner el currículum?

Es broma. Ahora vamos a ver temas técnicos. Pero no olvides que en cada broma hay algo de verdad :)

Análisis del daño en la copia de seguridad

Una copia de seguridad dañada es como el archivo de tu trabajo de fin de grado que no se abre justo antes de entregarlo. Los síntomas son parecidos:

• Errores al intentar restaurar: al ejecutar pg_restore puedes ver errores como:

  pg_restore: [archiver] input file does not appear to be a valid archive

• Faltan datos o el archivo tiene un tamaño incorrecto (por ejemplo, de repente es muy pequeño o igual a cero).
• El archivo SQL descomprimido tiene datos cortados, símbolos raros o secciones vacías.

Los daños en los backups pueden pasar por muchas razones:

• Interrupción del proceso de backup (por ejemplo, corte de luz o apagado del sistema).
• Transferencia incorrecta del archivo (errores al copiarlo a un USB o por red).
• Fallo de hardware (discos, RAM, fallo en el RAID).
• Errores en la configuración del sistema o de la utilidad de backup.
• Virus, malware y, por supuesto, el clásico "clic donde no era".

Recuperar datos de una copia dañada

Si el archivo está dañado, no todo está perdido. A veces se puede recuperar algo. Vamos a ver algunos enfoques.

Intentar restaurar con pg_restore

Si el archivo se creó con pg_dump en formato custom o directory, prueba a restaurar usando pg_restore con la opción --ignore-errors. Ejemplo:

pg_restore --dbname=your_database --ignore-errors backup_file.dump

Esta opción le dice a la utilidad que ignore los errores y siga adelante. Obviamente, los datos en las zonas dañadas se perderán, pero al menos una parte puede recuperarse.

Si esto funciona, revisa bien los datos restaurados al terminar y apunta qué falta exactamente.

Usar datos parciales

Supón que tienes una copia de seguridad en formato SQL de texto. Ábrela con un editor de texto (mejor si es avanzado, como Visual Studio Code o Notepad++) para ver dónde se corta. Si el archivo se puede leer y la mayoría de las consultas SQL están bien:

1. Borra la parte dañada del archivo.
2. Ejecuta las consultas SQL que quedan a mano o usando psql:

psql -U username -d database_name -f partial_backup.sql

Leer un archivo en formato custom

Si tu backup está en formato custom, puedes intentar extraer su contenido por partes:

pg_restore --list backup_file.dump > file_list.txt

Este comando crea una lista de todos los objetos en el backup. Luego puedes intentar restaurar elementos concretos (por ejemplo, tablas o esquemas) con este comando:

pg_restore --dbname=your_database --use-list=file_list.txt backup_file.dump

Editando file_list.txt, puedes excluir los elementos dañados de la restauración.

Intentar restaurar usando los logs de archivo (WAL)

Si usas backups incrementales o diferenciales (por ejemplo, con pg_basebackup), seguramente tienes logs de archivo (archivos WAL). Guardan todos los cambios desde el último backup. Para recuperar datos, puedes:

1. Buscar la última copia de seguridad completa (por ejemplo, un backup full).
2. Indicarle a PostgreSQL dónde están los archivos WAL:

   restore_command = 'cp /path/to/wal_directory/%f %p'

3. Hacer la restauración.

Usar herramientas de terceros

A veces los daños en los backups se pueden minimizar con utilidades para recuperar archivos. Una herramienta popular es ddrescue. Ejemplo:

ddrescue --force backup_file.dump recovered_dump.file

Esta herramienta intentará recuperar la mayor cantidad de datos posible y crear una copia nueva del archivo.

Cómo evitar daños en las copias de seguridad

Sí, trabajar con archivos dañados es un estrés. Vamos a pensar cómo evitar estas situaciones.

Guardar copias en varios sitios

Como en cualquier proyecto, la regla de oro del backup es "no pongas todos los huevos en la misma cesta". Duplica tus backups:

• En el servidor local.
• En la nube (Amazon S3, Google Cloud Storage o incluso un servicio sencillo como Dropbox).
• En soportes externos (si quieres estar súper protegido).

Comprobar la integridad de los backups regularmente

Hay un dicho en el mundo IT: "Un backup que no se ha probado, no es un backup". Comprueba tus copias de seguridad haciendo restauraciones de prueba. Para eso:

1. Sube el backup a un servidor de pruebas.
2. Restaura los datos desde ahí.
3. Comprueba que todo esté correcto.

Usar checksums

Cuando crees backups, genera checksums de los archivos (por ejemplo, usando MD5 o SHA256):

md5sum backup_file.dump > backup_file.md5

Al restaurar, compara el checksum actual con el original:

md5sum -c backup_file.md5

Así sabrás de antemano si el archivo está dañado.

Ejemplos de recuperación de copias dañadas

Vamos a ver un par de casos reales.

Caso 1. Error al transferir el archivo

Estás transfiriendo una copia de seguridad por FTP y de repente ves que el archivo es más pequeño de lo esperado. Usaste pg_dump en formato texto, así que:

1. Abriste el archivo en un editor.
2. Borraste la parte dañada de los datos.
3. Restauraste la parte útil del archivo con psql.

Caso 2. Pérdida parcial de datos en WAL

Tu servidor usaba backups incrementales y archivos WAL archivados. De repente, desaparecieron algunos archivos. Pero pudiste recuperar los datos usando pg_basebackup y los archivos WAL que quedaban, indicando su ruta en la configuración de restauración.

Recuerda que hacer backups no es solo crearlos, sino también comprobarlos. No esperes al apocalipsis para descubrir que tus copias no sirven. Y si la copia se daña, no entres en pánico: PostgreSQL tiene un montón de formas de recuperar tus datos. Lo importante es actuar rápido y con cabeza.

Y si nada funcionó — vuelve a leer el primer punto de esta lección.