Em 3 de junho de 2014 13:41, Alessandro Lima <[email protected]>
escreveu:

> >>​Não gostou do serviço de ambas ou considerou o custo elevado?
> *Estou praticamente fechando com a timbira para a restauração,*
> *mas o que estou pedindo agora é recomendação de cursos, para aprendizagem
> mesmo.*
>
> Atenciosamente,
>
> Alessandro Lima
>
> email [email protected]
>
>
> Em 3 de junho de 2014 12:03, JotaComm <[email protected]> escreveu:
>
>>  Olá,
>>
>>
>> Em 2 de junho de 2014 17:02, Alessandro Lima <[email protected]>
>> escreveu:
>>
>> Além da timbira, dextra e 4linux,
>>> alguém conhece ou pode indicar mais empresas que oferecem consultoria
>>> para recuperar base de dados?
>>>
>>
>> ​Não gostou do serviço de ambas ou considerou o custo elevado?
>>
>>>
>>> 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
>>>
>>>
>>
>> ​Abraços​
>>
>> --
>> JotaComm
>> http://jotacomm.wordpress.com
>>
>> _______________________________________________
>> 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
>
>
boa tarde
fiz o curso na Targettrust de porto alegre e na época foi muito bom..


-- 

Douglas Fabiano Specht
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a