Ahora que el incendio esta apagado, tu pega es hacer un script que se ejecute cada día y que saque un respaldo. mucho mejor si puedes configurar un hot-standby.
> On 27/03/2019, at 1:15 PM, Jairo Graterón <jgrate...@gmail.com> wrote: > > ¡Gracias! Horacio > > Este thread es bueno, dedos cruzados que solo es un indices. > https://grokbase.com/t/postgresql/pgsql-general/12a3rb6p15/postgres-will-not-start-due-to-corrupt-index > > <https://grokbase.com/t/postgresql/pgsql-general/12a3rb6p15/postgres-will-not-start-due-to-corrupt-index> > > Puedes subir la base de datos con la opción -P ( hagas lo que hagas no > toques el respaldo que tienes ). > > Logré acceder a la BD con las instrucciones, hice reindex y puedo ver toda > la información. > > Compartiré los pasos > > 1. Paré el servicio de postgres > 2. desde la consola inicié el programa postgres.exe > postgres --single -D "C:\Program Files\PostgreSQL\9.2\data" -P mydb > 4. reindex database mydb; > 5. cerré la consola > 6. inicié el servicio y listo ya se puede acceder desde pgadmin. >> >> select * from pg_class where relfilenode = 11760; > > Ésta relación ya no existe, seguramente era un índice. > > Saludos. > > > > > > El lun., 25 mar. 2019 a las 18:41, Horacio Miranda (<hmira...@gmail.com > <mailto:hmira...@gmail.com>>) escribió: > > >> On 26/03/2019, at 11:10 AM, Jairo Graterón <jgrate...@gmail.com >> <mailto:jgrate...@gmail.com>> wrote: >> >> Saludos >> >> select * from pg_class where relfilenode = 11760; >> No funciona porque no se puede acceder a la BD > > Este thread es bueno, dedos cruzados que solo es un indices. > https://grokbase.com/t/postgresql/pgsql-general/12a3rb6p15/postgres-will-not-start-due-to-corrupt-index > > <https://grokbase.com/t/postgresql/pgsql-general/12a3rb6p15/postgres-will-not-start-due-to-corrupt-index> > > Puedes subir la base de datos con la opción -P ( hagas lo que hagas no > toques el respaldo que tienes ). > >> Hice el checkdisk y hay fallas en el disco duro, es más la máquina ya no >> arranca. >> >> Logré respaldar la carpeta DATA de postgres y lo copie en otra máquina con >> su misma versión de postgres pero igualmente no se puede acceder a la BD. >> >> usé el programa reindex y da el mismo error, cree un archivo con el mismo >> nombre sin bytes y aparece "Fatal: índice pg_attribute_relid_attnum_index >> contiene páginas vacías no esperadas en el bloque 0" >> >> >> Así que restauraremos la copia que tengo del año pasado y ellos revisaran >> los reportes diarios para recuperar las ventas y cobranzas. >> >> >> Ojo no soy el administrador de sistemas de la empresa, sólo instalé el >> sistema hace varios años, en su momento les indiqué que hicieran respaldos >> diarios, comprar discos redundantes y un UPS para ese equipo. >> >> Gracias por sus respuestas. >> >> >> >> >> >> El sáb., 23 mar. 2019 a las 18:24, Horacio Miranda (<hmira...@gmail.com >> <mailto:hmira...@gmail.com>>) escribió: >> Algunas cosas que hago cuando hay problemas Comentarios entre lineas. >> >> On 24/03/2019 5:29 AM, Jairo Graterón wrote: >>> Hola Lucas >>> >>> Si el servidor Postgres arranca correctamente, no se puede hacer backup ya >>> que da error al acceder a la BD de la empresa >> Hay varios tipos de respaldos, si no puedes hacer un respaldo lógico, hace >> un respaldo físico ( copia todo a otra maquina no otro directorio o disco en >> ese servidor ). ( usa discos remotos montados de forma local ), que tamaño >> estamos hablando ? Tienes otra maquina similar supongo ? >>> >>> Al igual que pg_admin desde la línea de comandos puedo iniciar sesión desde >>> la BD por default de postgres, pero luego cuando cambio a BD de producción >>> aparece el error. >>> >> Antes de ver la base de datos asegurate que la maquina este bien ( que >> maquina es ? sí es una HP/DELL/Cisco, etc ) revisa que el cache de la >> controladora este online y los discos no esten esperando una acción, sí >> tienes mala suerte el archivo estaba en el cache a la hora de la falla, sí >> esto llegara a ser correcto, es un proceso temporal que crea y borra tablas >> y puede que tengas suerte ). >> >> Sí es S.O. Lo que puedes tratar ( sí no has escrito nada en la maquina ) >> recuperar ese archivo con testdisk ( pero debes saber lo que estas haciendo >> y despues de sacar un respaldo ) la regla es no usar el disco con problemas >> para asegurarte que no se escriban los bloques ( lo ideal es tener el >> postgresql en otra particion ). >> https://www.cgsecurity.org/wiki/TestDisk_Download >> <https://www.cgsecurity.org/wiki/TestDisk_Download>Paré el servicio postgres >> e hice un respaldo del directorio BASE, >>> >>> Voy a revisar el visor de logs de postgres a ver si encuentro el porque se >>> borró ese archivo. >>> >> No creo que pilles el por que... revisa el disco con checkdisk, y carga el >> respaldo en otra maquina ( se que tienes un respaldo, pero esta probado ? ). >> >> >> >> PS: Moraleja, los respaldos se deben sacar de forma automática, no confíes >> en humanos para hacer tareas de maquinas y debes tener un DR plan ( >> respaldos fuera de la maquina y/o respaldados en dos lugares. En lo personal >> saco respaldo semanales, mensuales y anuales con retención 4 en cada ítem >> para bases importantes en un Storage remoto en otro datacenter. ( paranoico >> pero eso me salvo la vida una vez una carga de datos errónea que necesite un >> respaldo de 2 años atrás ). >> >>> El sáb., 23 mar. 2019 a las 11:49, Lucas Luengas (<lucasluen...@gmail.com >>> <mailto:lucasluen...@gmail.com>>) escribió: >>> Hola. >>> >>> Lo primero que yo haría sería comprobar si la base de datos arranca y para >>> correctamente. Aunque quizás no se acceda a todos sus objetos. >>> Si la base de datos arranca y para correctamente, lo primero que yo haría >>> sería hacer un backup del estado actual antes de proceder con ninguna >>> acción (suponiendo que se pueda hacer backup, espero que sí). >>> >>> Lo segundo que haría sería revisar los logs postgres y el visor de sucesos >>> de Windows porque algunos mensajes iniciales de Postgres en entorno Windows >>> se muestran en el visor de sucesos y quizás puedan ser de interés. A partir >>> de los logs puedes investigar más a fondo. >>> >>> Lo tercero: por la captura de pantalla, el error lo ofrece Pgadmin. ¿Lo >>> ofrece al acceder a alguna tabla en concreto, a todas las tablas, al >>> conectar a la base de datos? >>> >>> Lo cuarto: comprueba si se puede entrar a la base de datos por línea de >>> comandos vía psql, y en caso afirmativo si puedes hacer select de las >>> tablas de la base de datos. >>> >>> Lo que he comentado no soluciona el problema, pero ayuda a averiguar el/los >>> problemas concretos de fondo. >>> >>> Saludos. >>> >>> >>> >>> >>> >>> On Sat, Mar 23, 2019 at 3:23 PM Jairo Graterón <jgrate...@gmail.com >>> <mailto:jgrate...@gmail.com>> wrote: >>> Buen día lista, >>> >>> Tengo el siguiente problema >>> >>> <image.png> >>> >>> Ocurrió al apagarse repentinamente el servidor porque falló el sistema >>> eléctrico y su sistema de respaldo. >>> >>> El administrador de sistema no hizo los respaldos respectivos y no hay >>> backup de éste año. >>> >>> Es una empresa pequeña y tiene un servidor con postgres 9.2. corriendo >>> sobre Windows 7. >>> >>> Ese sistema lo instalé hace como 10 años y la BD nunca había dado problemas. >>> >>> Alguna sugerencia de cómo recuperar la BD? >>> >>> PD. >>> >>> Tengo un respaldo del año pasado, no se si sirva para algo. >>> >>> Gracias >>> >>> >>> >>> >>> >>> >>> >
