2008/11/11 ELIAS JUNIOR <[EMAIL PROTECTED]> > Digo copiar os arquivos do banco para depois tentar restaurar, tentei fazer > isso e não funcionou, seguindo uma dica aqui da lista, por isso eu digo > façam backup através do dump, que é garantia de recuperação de dados. > >
Caro gafanhoto. Recomendo enfáticamente que você teste novamente, documente o processo e se der um problema, apresente sua documentação e o problema gerado. De qualquer forma, se você consultar a documentação oficial em http://www.postgresql.org/docs/8.3/static/backup-file.html terá algumas dicas. Concordo que o procedimento não é trivial como usar o pg_dump. Mas é importante. O pg_dump tem um defeito grave: o restore é lento, muito lento. Se você tiver uma base com mais de 100GB ou mesmo uma única tabela com mais de 1GB vai sentir bem este impácto. Criar índices e verificar todas integridades demora muito. A diferença no tempo de restore pode ser algo assim numa base grande: Restore físico: 2 a 4 horas (é o tempo de cópia dos arquivos). Restore lógico: 48 horas ou mais... Se você precisar realmente que a aplicação volte ao ar em caso de desastre, você não vai querer demorar 2 dias para subir um dump vai? Sem contar que com dump lógico você não consegue utilizar o Point In Time Recovery. Se você tivar um backup físico e tiver o bom senso de fazer uma cópia do WAL, você vai poder rolar o seu backup físico para momentos antes do desastre enquanto no backup lógico seus dados vão ter a data do momento de backup. Perder dados não é algo muito agradável. Com uma boa política de backup você diminui drásticamente o tempo de recuperação de desastres e a perda de dados. Isto pode salvar muita gente, inclusive o seu emprego!!! []s Fábio Telles > -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: [EMAIL PROTECTED]
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
