Além da timbira, dextra e 4linux, alguém conhece ou pode indicar mais empresas que oferecem consultoria para recuperar base de dados?
Atenciosamente, Alessandro Lima email [email protected] Em 2 de junho de 2014 15:25, Alessandro Lima <[email protected]> escreveu: > >>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
