[firebase-br] Ajuda(Perca de Registros)

[Carlos H. Cantu]

DTT> Obrigado pelo retorno Carlos.
DTT>  Resumindo não ha como recuperar esses dados de forma alguma ...certo?

Creio que não, a não ser que vc encontre algum utilitário que consiga
"ressucitar o antigo arquivo", tipo um undelete ou coisa assim, mas as
chances do arquivo não estar corrompido seriam baixas.

[]s
Carlos H. Cantu
eBook Guia de Migração para o FB 3 - www.firebase.com.br/guiafb3.php
www.FireBase.com.br - www.firebirdnews.org - blog.firebase.com.br



DTT>  

DTT> ---

DTT> Diego Fernandes Souza

DTT>  

DTT>  

DTT>  
DTT>  

DTT> Em 08/11/2018 12:13, Carlos H. Cantu escreveu:

DTT> Me parece sintoma tipico do sistema de arquivos do Linux. Tentando
DTT>  explicar de forma simplificada:
DTT>  
DTT>  Provavelmente vc restaurou o backup em cima da base que já existia, e
DTT>  o arquivo da base estava aberto (em uso, pelo Firebird), então você
DTT>  ficou com duas "versões" do mesmo arquivo. As conexões continuaram
DTT>  ocorrendo na base que já existia, pois o Firebird estava conectado a
DTT>  ela. Quando você reiniciou o servidor, o arquivo da base foi liberado
DTT>  e finalmente "substituído" pela versão que tinha sido restaurada dia
DTT>  20, ou seja, perdeu tudo que tinha sido feito depois, pois essas
DTT>  alterações foram realizadas no arquivo "antigo".
DTT>  
DTT>  Veja artigo publicado pela IBSurgeon que descreve o problema:
DTT>  
DTT>  It is well-known fact that Linux uses the inode mechanism to support
DTT>  different file systems. One of the key features of this mechanism is
DTT>  the use of cache to handle file descriptors – it means that file
DTT>  descriptors are stored both in memory and on disk.
DTT>  
DTT>  To InterBase and Firebird it brings an onerous side-effect. If you
DTT>  replace a database when users are still connected, the server will
DTT>  continue to work with the old file, which is wrongly assumed to be
DTT>  deleted. The danger here is that, when the last user detaches, the
DTT>  server will drop the file forever and the "new" file steps in to
DTT>  replace it at that point. You never know it has happened until it is
DTT>  too late and then, it is most likely to be discovered by furious
DTT>  users: "Where is my work from last week?!"
DTT>  
DTT>  The longest period of lost data due to such «disappearing» that I have
DTT>  observed was 1.5 years. It was a multi-volume database on Linux and
DTT>  one of the 4Gb volumes was completely lost.
DTT>  
DTT>  You may say it is a very rare circumstance but I can stake a case of
DTT>  beer on the fact that, right now, at least one hundred server
DTT>  installations have this problem. We receive at least one repair
DTT>  request due to this problem every two months!
DTT>  
DTT>  []s
DTT>  Carlos H. Cantu
DTT>  eBook Guia de Migração para o FB 3 - www.firebase.com.br/guiafb3.php
DTT>  www.FireBase.com.br - www.firebirdnews.org - blog.firebase.com.br
DTT>  
 DTT>>  
DTT>  
 DTT>> Bom dia. 

 DTT>>  Fiz um bkp_restore do meu banco no dia 20/10/18 aparentemente tudo ok
 DTT>> apos o termino.
 DTT>> Porem hoje apos reiniciar o servidor Linux onde o banco e o serviço do
 DTT>> firebird esta os dados do 
 DTT>> dia 20 ate a presente data sumiram. Alguem ja passou por esse tipo de
 DTT>> situação ? 

 DTT>> []s.