Recuperación de PostgreSQL sin copia de seguridad de 2.5 TB

Recuperación de PostgreSQL sin Backups: Estudio de Caso de un Clúster de 2.5 TB

Un clúster de PostgreSQL de 2.5 TB de Postgres Professional funcionó durante tres años en una máquina virtual sin copias de seguridad. El disco, configurado sin reserva de espacio, superó el tamaño físico del host, expandiéndose mediante copia en escritura. Diez bases de datos activas, incluyendo 1C, colapsaron tras cargar una nueva base de información: los registros WAL llenaron el disco del hipervisor y los puntos de control no lograron completarse.

Los administradores eliminaron manualmente archivos WAL e intentaron detener el postmaster en modo rápido, pero sin éxito. Una detención forzada con SIGKILL provocó corrupción de datos debido a los masivos shared_buffers. El inicio mediante pg_resetwal desactivó la recuperación WAL; las consultas simples funcionaban, pero las complejas no.

Diagnóstico y Parches Iniciales

Utilizando la utilidad crash_info (disponible en la versión gratuita de Postgres Professional) mediante la señal SIGRTMIN+6, identificamos una bloqueo en _bt_moveright en un índice btree del catálogo del sistema. Habilitamos el parámetro ignore_system_indexes o aplicamos un parche para omitir los índices del sistema. REINDEX SYSTEM no se completó durante la noche.

pg_dump se colgó al recuperar la lista de tablas debido a la falta de índices. El parámetro --data-only no ayudó: la utilidad solicitaba estadísticas extendidas. Un parche para pg_dump excluyó consultas innecesarias al catálogo del sistema.

Exportación de Datos y Consecuencias

Tras 24 horas, los datos de la base de datos clave se exportaron a un nuevo clúster. Un informe de error enviado a la comunidad de PostgreSQL con un parche (para versiones 13–17) destacó problemas de pg_dump con índices corruptos. La comunidad se negó a clasificar esto como un bug: la recuperación sin backups no es una prioridad.

El cliente compró soporte enterprise de Postgres Professional. Una alternativa a pg_dump fue COPY mediante una lista de tablas desde 1C (50,000 tablas en la base de datos), generada por un script sin acceder al catálogo del sistema.

Errores Clave del Administrador

• Falta de backups y réplicas.
• Eliminación manual de registros WAL.
• Detención del postmaster con SIGKILL en lugar de SIGQUIT.
• Ignorar las recomendaciones de reserva de disco.
• Confiar en 'guías' sin verificar las copias de seguridad.
• Elección incorrecta de pg_dump sin considerar el daño del catálogo.

Qué Importa

• Sin backups (volcados, réplicas), la recuperación completa de un clúster de 2.5 TB es imposible.
• ignore_system_indexes permite omitir índices del sistema corruptos.
• crash_info es útil para volcados de estado sin acceso a la consola.
• pg_dump es vulnerable al daño del catálogo: use --data-only con parches o COPY.
• Matar el postmaster con SIGKILL destruye datos cuando shared_buffers es grande.

Lecciones para DBAs

Un clúster 1C requiere limpieza de WAL, monitoreo de espacio en disco y replicación. Los shared_buffers enormes enmascaran problemas hasta que ocurre la catástrofe. Para 50,000 tablas, genere scripts COPY desde los metadatos de 1C.

— Editorial Team