Cuando una base de datos PostgreSQL no inicia correctamente, muchos administradores sienten una gran preocupación. ¿Está todo perdido? ¿Se rompió la base? En esta nota te vamos a contar qué significa que PostgreSQL entre en modo de recuperación, por qué ocurre, cómo solucionarlo paso a paso y cómo podés evitar que vuelva a pasar. ¡Tomá nota!

¿Qué es el modo de recuperación en PostgreSQL?

A diferencia de SQL Server, PostgreSQL no muestra un estado literal llamado ‘Recovery Pending’. Sin embargo, puede encontrarse en un estado muy similar cuando el sistema intenta arrancar pero no puede completar la recuperación. Esto sucede generalmente cuando hay archivos WAL (Write Ahead Log) faltantes, archivos corruptos o configuraciones incorrectas.

En estos casos, el motor entra en lo que se conoce como ‘modo de recuperación’. Esto puede verse en los logs o en la consola como: ‘recovery is in progress’, ‘FATAL: could not locate WAL file’, o mensajes sobre timeline. La base de datos queda inaccesible hasta que termine la recuperación o hasta que se resuelva el problema subyacente.

Es importante entender que esto no significa que tu base esté destruida. De hecho, este comportamiento busca proteger los datos y garantizar que el sistema vuelva a un estado consistente.

Causas comunes del modo de recuperación:

Estas son las razones más frecuentes por las que PostgreSQL entra en modo de recuperación:

1. 🔌 Corte de energía o apagado forzado del servidor, especialmente si ocurre durante una operación crítica.
2. 🧱 Archivos WAL faltantes, por eliminación manual, corrupción o problemas en el sistema de archivos.
3. 💾 Falta de espacio libre en disco, lo que impide que PostgreSQL escriba archivos de recuperación.
4. 🔐 Permisos incorrectos en carpetas como `pg_wal`, `base`, o el directorio principal del clúster.
5. 🛑 Corrupción de archivos de control (`pg_control`) o archivos internos por fallos de hardware.
6. 🔁 Conflictos de timeline durante una restauración o recuperación PITR (point-in-time recovery) mal configurada.

Conocer la causa es clave para aplicar la solución correcta y evitar intervenciones innecesarias.

Cómo resolver el modo de recuperación en PostgreSQL

Si te encontrás con PostgreSQL en modo de recuperación, seguí estos pasos para resolverlo de forma segura:

🔍 Paso 1: Revisá los logs.
Buscá en los archivos de log ubicados normalmente en `/var/log/postgresql/` o en la carpeta de datos. Allí vas a encontrar mensajes que te indiquen si falta un WAL, si hay corrupción o si está haciendo una recuperación automática.

💽 Paso 2: Verificá espacio y permisos.
Chequeá con `df -h` que haya espacio en las particiones. Usá `ls -l` para asegurarte de que el usuario `postgres` tenga los permisos necesarios.

♻️ Paso 3: Dejá que el sistema recupere solo.
Si los logs indican ‘recovery is in progress’, esperá unos minutos. Es el comportamiento esperado después de un corte brusco. No apagues el servidor nuevamente.

🪄 Paso 4: Restaurar archivos WAL faltantes.
Si usás herramientas como pgBackRest, Barman o tenés una réplica, podés traer los WAL faltantes al directorio correspondiente (`pg_wal`).

🧪 Paso 5: Usá el modo single user si necesitás intervenir.
Con el servidor apagado, ejecutá:
`sudo -u postgres postgres –single -D /var/lib/postgresql/XX/main postgres`
Desde ahí podés ejecutar comandos para reparar o inspeccionar manualmente.

♻️ Paso 6: Recuperación total desde backup (si es necesario).
En situaciones críticas, restaurá el último backup completo y aplicá los WAL guardados para llegar al punto deseado.

¿Cómo prevenir este escenario en el futuro?

Una de las mejores estrategias es prevenir que PostgreSQL entre en modo de recuperación forzada. Te compartimos buenas prácticas clave:

✅ Monitoreo activo: Usá herramientas como Prometheus con PostgreSQL Exporter, pgAdmin o Zabbix para estar al tanto del estado del sistema.
✅ Backups automatizados y verificados:** pgBackRest, Barman o WAL-G permiten configurar copias de seguridad diferenciales y completas, junto con archivado de WAL.
✅ Configuración óptima de checkpoints: Asegurate de que `checkpoint_timeout`, `max_wal_size` y `wal_keep_segments` estén correctamente definidos.
✅ Uso de UPS y discos confiables: Evitá apagados bruscos con sistemas de energía de respaldo y discos con journaling como ext4 o xfs.
✅ Revisión periódica de permisos y espacio: Automatizá scripts que revisen el estado del sistema de archivos y de permisos en carpetas críticas.

Implementar estas medidas puede marcar la diferencia entre una recuperación rápida y una pérdida significativa de datos.

Conclusión

El modo de recuperación en PostgreSQL puede asustar, especialmente si te toma por sorpresa. Sin embargo, la mayoría de las veces tiene solución y no implica pérdida de datos si actuás a tiempo y con criterio. Los mecanismos de recuperación están diseñados para proteger la integridad de la base, no para complicarte.

Desde DBA24 te recomendamos estar siempre un paso adelante: monitoreo constante, buenos backups, y una estrategia clara de contingencia. Y si en algún momento te encontrás con este problema y no sabés cómo seguir, podés contar con nosotros.

📧 Escribinos a info@dba24.com y con gusto te damos una mano.