Entonces, estoy (bueno... estaba) ejecutando PostgreSQL dentro de un contenedor (Ubuntu 14.04LTS con todas las actualizaciones recientes, el almacenamiento de back-end es "dir" debido a la convicción).
Para resumir, la carpeta del contenedor se eliminó. Siguiendo el uso de extundelete y ext4magic, logré extraer algunos de los archivos físicos de la base de datos (parece que la mayoría de los archivos están allí... pero no estoy 100% seguro de si falta y qué falta).
Tengo dos copias de los archivos de la base de datos. Uno de 9.5.3 (que parece ser más completo) y otro de 9.6 (actualicé el contenedor recientemente a 9.6, sin embargo, parece que faltan archivos de datos).
Todo lo que busco es intentar extraer el código SQL relacionado con las funciones definidas por el usuario. ¿Alguien sabe de un enfoque que podría probar?
PD: La última copia de seguridad está un poco anticuada (realmente debido a malas prácticas), por lo que sería el último recurso si la tarea de extraer la información necesaria es "razonable" y "exitosa".
Saludos, G.
Actualización - 20/4/2017 Esperaba una "solución rápida" extrayendo de alguna manera el texto del cuerpo de la función de los archivos de datos recuperados... sin embargo, nada es gratis en esta vida :)
A partir de la copia de seguridad antigua junto con los registros recuperados, logramos cubrir mucho terreno para devolverle la vida a la base de datos.
Lecciones aprendidas :
1. Implemente una buena estrategia de copia de seguridad/restauración
2. No almacene copias de seguridad en la misma máquina física
3. La falla del hardware puede ser perjudicial ... ¡El error humano puede ser desastroso!
Si puede reconstruir una cantidad suficiente de un directorio de datos para iniciar Postgres en modo de usuario único, es posible que pueda volcar pg_proc. Pero esto parece poco probable.
De lo contrario, si tiene mucha suerte, podrá encontrar la relación para pg_proc y su correspondiente relación pg_toast . Este último a menudo contendrá texto comprimido, por lo que las búsquedas de partes de variables que sabe que aparecen en los cuerpos de las funciones pueden no serle de ayuda.
Cualquier cosa almacenada en línea en pg_proc serán funciones cortas, significativamente menos de 8k de largo. Todo lo demás estará en la relación de brindis.
Para decodificar eso, debe descomprimir las páginas para obtener los trozos de pan tostado, luego volver a ensamblarlos y descomprimirlos (si están comprimidos).
Si tuviera que hacer esto, probablemente crearía una tabla con exactamente el mismo esquema que pg_proc en una nueva instancia de postgres de la misma versión. Luego encontraría los relfilenode(s) para pg_catalog.pg_proc y su tabla de brindis usando el archivo de mapa de relfilenode (si sobrevivió) o mediante coincidencia de patrones y conjeturas. Reemplazaría los archivos de relación vacíos para la nueva tabla que creé con los recuperados, reiniciaría Postgres y, si tenía razón, podría select entre las tablas.
No es fácil.
Sugiero leer sobre el formato de almacenamiento de Postgres, ya que deberá comprenderlo.
Puede considerar https://www.postgresql.org/support/professional_support/ . (Descargo de responsabilidad, trabajo para una de las empresas que figuran en la lista).
PD: La última copia de seguridad está un poco anticuada (realmente debido a malas prácticas), por lo que sería el último recurso si la tarea de extraer la información necesaria es "razonable" y "exitosa".
Las copias de seguridad son su primer recurso aquí.
Si los archivos 9.5 están completos y sin daños (o lo suficiente como para volcar el esquema), simplemente copiándolos en su lugar, verificando los permisos e iniciando el servidor lo pondrá en marcha. Sin embargo, no confíes en los datos, tendrás que verificarlos todos.
Aunque es posible recuperar parcialmente archivos dañados, es un proceso largo y complicado y el hecho de que esté preguntando sobre Stack Overflow probablemente significa que no es para usted.