[pgbr-geral] Diferença de tamanho backup pg_dump
Bom dia a todos. Sou novo em uma empresa e o pessoal esta utilizando o pg_dump para realizar backup da base de dados, a pasta data tem o tamanho de 30 GB e depois que o backup é realizado o arquivo de saída tem 1,2 GB é isto mesmo? Quando eu restauro em outro servidor de testes a pasta Data fica com uns 9 GB. Resaltando que nunca foi executado o Vacuum nesta base. O arquivo de backup esta com estes comando SET PGUSER=postgresSET PGPASSWORD=blablabla C:\Arquivos de programas\PostgreSQL\9.0\bin\pg_dump -h localhost -p 5432 -U postgres -C -F c -b -v -f D:\Backup.backup Base_de_Dadospause Obrigado. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Diferença de tamanho backup pg_dump
Bom dia a todos. Sou novo em uma empresa e o pessoal esta utilizando o pg_dump para realizar backup da base de dados, a pasta data tem o tamanho de 30 GB e depois que o backup é realizado o arquivo de saída tem 1,2 GB é isto Isso é normal. Uma base em disco tem bastante espaço inutilizado, nós chamamos isso de inchaço, basicamente são os deletes, updates e rollbacks que causam isso e é absolutamente normal. Tem também a questão dos índices, os índices ocupam um enorme espaço em disco e, no dump, eles são simplesmente uma linha cada, que indica como recriá-los. mesmo? Quando eu restauro em outro servidor de testes a pasta Data fica com uns 9 GB. Uma restauração recente não conta com o inchaço de uma instalação já utilizada, por isso você vê essa diferença. Resaltando que nunca foi executado o Vacuum nesta base. Mantenha o autovacuum ligado para controlar o espaço do inchaço. O autovacuum permite reaproveitar esse espaço, mas não o elimina. O comando que faz a limpeza completa do espaço do inchaço se chama VACUUM FULL, mas normalmente não é necessário utilizá-lo. O arquivo de backup esta com estes comando SET PGUSER=postgres SET PGPASSWORD=blablabla C:\Arquivos de programas\PostgreSQL\9.0\bin\pg_dump -h localhost -p 5432 -U postgres -C -F c -b -v -f D:\Backup.backup Base_de_Dados pause Você está usando a opção -Fc, o que significa que seu arquivo de dump é ainda menor por ser comprimido. Parece tudo ok. O mais legal é que você tem um backup e sabe restaurá-lo. Deve estar com a cabeça fresca. Estudo um pouco mais e aprenda sobre a metodologia PITR pra tirar nota 10. Se tiver um tempinho, pesquise sobre o excelente pg_dump não é backup do colega Fabio Teles (que anda meio sumido ultimamente). []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Diferença de tamanho backup pg_dump
Estudo um pouco mais e aprenda sobre a metodologia PITR pra tirar nota 10. Estou estudando, porem me perco no restore...Sempre utilizo no arquivo recovery.conf o comando restore_command = 'copy C:\\Logs\\%f %p' Porem não consegui entender como eu recupero ele com delimitação de tempo(timelines, se não me engano), tipo, voltar os arquivos até as 10:00 deste dia ou as 09:00, caso ocorra um desastre as 11:00 da manha... Se tiver um tempinho, pesquise sobre o excelente pg_dump não é backup Já li sobre o mesmo, muito interessante este Fabio Teles é nota 10 no postgres. do colega Fabio Teles (que anda meio sumido ultimamente). Date: Mon, 21 Jul 2014 14:58:54 +0200 From: fha...@gmail.com To: pgbr-geral@listas.postgresql.org.br Subject: Re: [pgbr-geral] Diferença de tamanho backup pg_dump Bom dia a todos. Sou novo em uma empresa e o pessoal esta utilizando o pg_dump para realizar backup da base de dados, a pasta data tem o tamanho de 30 GB e depois que o backup é realizado o arquivo de saída tem 1,2 GB é isto Isso é normal. Uma base em disco tem bastante espaço inutilizado, nós chamamos isso de inchaço, basicamente são os deletes, updates e rollbacks que causam isso e é absolutamente normal. Tem também a questão dos índices, os índices ocupam um enorme espaço em disco e, no dump, eles são simplesmente uma linha cada, que indica como recriá-los. mesmo? Quando eu restauro em outro servidor de testes a pasta Data fica com uns 9 GB. Uma restauração recente não conta com o inchaço de uma instalação já utilizada, por isso você vê essa diferença. Resaltando que nunca foi executado o Vacuum nesta base. Mantenha o autovacuum ligado para controlar o espaço do inchaço. O autovacuum permite reaproveitar esse espaço, mas não o elimina. O comando que faz a limpeza completa do espaço do inchaço se chama VACUUM FULL, mas normalmente não é necessário utilizá-lo. O arquivo de backup esta com estes comando SET PGUSER=postgres SET PGPASSWORD=blablabla C:\Arquivos de programas\PostgreSQL\9.0\bin\pg_dump -h localhost -p 5432 -U postgres -C -F c -b -v -f D:\Backup.backup Base_de_Dados pause Você está usando a opção -Fc, o que significa que seu arquivo de dump é ainda menor por ser comprimido. Parece tudo ok. O mais legal é que você tem um backup e sabe restaurá-lo. Deve estar com a cabeça fresca. Estudo um pouco mais e aprenda sobre a metodologia PITR pra tirar nota 10. Se tiver um tempinho, pesquise sobre o excelente pg_dump não é backup do colega Fabio Teles (que anda meio sumido ultimamente). []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Diferença de tamanho backup pg_dump
Estudo um pouco mais e aprenda sobre a metodologia PITR pra tirar nota 10. Estou estudando, porem me perco no restore... Sempre utilizo no arquivo recovery.conf o comando restore_command = 'copy C:\\Logs\\%f %p' Porem não consegui entender como eu recupero ele com delimitação de tempo(timelines, se não me engano), tipo, voltar os arquivos até as 10:00 deste dia ou as 09:00, caso ocorra um desastre as 11:00 da manha... Procure mudar o assunto do e-mail quando fizer outra pergunta, isso ajuda a organizar a lista, por favor. Respondendo, pesquise as configurações recovery_target_*, no seu caso seria recovery_target_time. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
