>>Você não tinha nenhum backup? Nenhum backup? Nada como algo de dois ou três dias atrás? *Tinha backup de algumas bases de dados, faltam duas importantes, uma não estava na rotina de backup (dump) e a outra estava mas não foi realizada por algum motivo.*
>>Qual o sistema de arquivos que você utiliza? *RAID 1, LVM, não tenho certeza se era ext3 ou ext4, tem como conferir? com o comando fdisk aparece 8e (lvm).* >>Você pode tentar fazer uma nova máquina com a mesma versão do SO e do PG, e ver o que consegue restaurar lá. Você já fez isso? *Utilizei o mesmo instalador binário do postgres em outro servidor debian 7, mas no log acusa os erros relatados:* *-pg_filenode.map invalid data* *-global/32777 not a directory* Atenciosamente, Alessandro Lima email [email protected] msn [email protected] skype grandegoiania Em 2 de junho de 2014 15:10, Alessandro Lima <[email protected]> escreveu: > Sei que este não é o forum apropriado para tirar dúvida sobre extundelete, > mas se alguém puder ajudar, > > >>Para ext3, por exemplo, extundelete, fsck, extdump, entre outras. > > Apenas confirmando, devo então montar meu hd com problemas como somente > leitura: > mount /dev/VolGroup00/LogVol00 /mnt -o ro,user (pelo que vi, por ser lvm > não devo usar /dev/sdb1) > e executar o extundelete especificando o caminho dos arquivos recuperados. > > Para preservar o hd original, não será necessário cloná-lo com o comando > dd, a montágem somente leitura já é suficiente? > > > Alessandro Lima > > email [email protected] > > > Em 2 de junho de 2014 09:09, Flavio Henrique Araque Gurgel < > [email protected]> escreveu: > > >>Não sei o que esse último .1 significa (é do pacote?)... >>> *Também não sei, está no nome do instalador que foi utilizado: >>> postgresql-9.2.4.1-linux-x64.run* >>> >> >> Você usou o instalador binário da EnterpriseDB. >> Use sempre o mesmo até ter um banco de dados funcional novamente. >> >> >>Você quer dizer, o sistema de arquivos nem monta? Ou é o postgres que >>> não sobe? Qual o erro exato que vês? >>> *Após montar o RAID, apresentava a mensagem antes do fsck: ext3-fs group >>> descriptors corrupted!* >>> *agora depois do fsck: kernel panic - not syncing: Attemped to kill >>> init!* >>> >> >> Parece que você perdeu um dos discos do seu grupo. Que tipo de RAID >> utilizava? Talvez refazer o disco perdido resolva seu problema, se você >> usava alguma redundância (raid 5, 6 ou 10), ou seja, resolver o problema no >> nível mais baixo primeiro. >> >> >>Me parece que as permissões estão erradas. Execute um chmod 700 nesse >>> diretório e tente novamente. >>> *Alterando as permissões não resolve, continua sem exibir a letra d, >>> indicando que o arquivo é um diretório.* >>> >> >> O sistema de arquivos está realmente confuso. Identifique a causa da >> perda de dados antes de continuar, pode ser um caminho mais fácil. >> Principalmente, não monte esse sistema de arquivos em modo r/w e copie >> para outro disco limpo para seus testes. >> >> []s >> Flavio Gurgel >> >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> > >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
