PostgreSQL Amap

Pgina 1 de 10

PostgreSQL Amap
18/03/2009
Script e uma breve introduo sobre polticas de backup para o SGBD
PostgreSQL em um ambiente instvel
Filed under: PostgreSQL Tags:Backup, FTP, PostgreSQL, Shell Script dailsonaraujo @
12:05
Autor: Dailson Igo; Colaboradores: Marco Craveiro, Gustavo e Juciclia.
O link do script encontra-se aqui. Como esse meu primeiro post, acabei caindo no erro de fazer
primeiro o documento em OpenOffice e encontrei um monte de problemas. Caso queiram, podem
baixar aqui. No consegui formatar as tabelas, por isso optei por transformar em imagens.
Voc j questionou a eficincia do seu script de backup? J parou algumas horas para tentar
melhor-lo? Se deparou com alguma situao em que ele se mostrou ineficiente ou inapropriado?
Caso seu script de backup se resuma a apenas executar uma instruo do tipo pg_dump -h
127.0.0.1 -U postgres -v -o -b -i -Z9 -Fc -f NomeBackup NomeBanco, pode ser necessrio
considerar alguns pontos que podero tornar suas rotinas de backup mais completas e inteligentes.
Os pontos abaixo tratam de um script que realiza um backup full on-line para o SGBD
PostgreSQL com a finalidade suprir s necessidades do Tribunal de Justia do Estado do Amap
(TJAP) que, para atender seu principal sistema de nome Tucujuris (Sistema de Gesto Judiciria
de 1 e 2 Grau) possui um banco de dados em cada uma das 12 comarcas, um na capital (MacapAP) e os outros onze em municpios distintos.

http://postgresqlnoamapa.wordpress.com/

13/04/2011

PostgreSQL Amap

Pgina 2 de 10

Figura F1 Disposio geogrfica dos municpios do Amap que possuem em sua comarca o
banco de dados do Sistema Tucujuris.
Como a capital possui uma infraestrutura um pouco melhor, nela funciona o BD concentrador,
pois possui dados de todos os outros municpios. Os outros municpios possuem seus dados e
alguns outros que so comuns a todos os municpios/comarcas. A sincronizao de dados
realizada com uma replicao multi-master assncrona fornecida pela empresa dbExperts, alm de
algumas implementaes feitas pelo TJAP. Na verdade a replicao vai um pouco alm do multimaster, ela possui um esquema de rotas, mas vamos deixar isso para um momento mais
apropriado.
No foi possvel utilizar apenas um nico servidor com o PostgreSQL para atender a demanda de
todos os 12 municpios pela fato da precariedade dos links de comunicao dentro de nosso

http://postgresqlnoamapa.wordpress.com/

13/04/2011

PostgreSQL Amap

Pgina 3 de 10

Estado (para fora tambm igualmente precrio), onde a comunicao via satlite utilizado na
maior parte das situaes, e em uma menor quantidade, a comunicao via rdio.
Em ambas as formas de comunicao muito comum a instabilidade do link, o que poderia
ocasionar falta de comunicao por perodos de vrias semanas (como j aconteceu diversas
vezes), ou seja, vrias semanas sem comunicao, vrias semanas sem BD, vrias semanas de
trabalho sem sistema, se possvel fosse trabalhar. Como se no bastasse a concessionria de
energia eltrica tambm peca na qualidade dos servios prestados a todos os municpios, o que j
ocasionou a danificao de vrios discos e equipamentos.
Para minimizar as chances de perda e corrupo de dados, recentemente no ano de 2008 novos
servidores foram instalados com RAID 10 na capital e RAID 5 nos demais municpios. A pouco
tempo somente na capital e em Santana possuamos uma mquina que poderamos chamar de
servidor, nos outros municpios tnhamos desktops com uma modesta configurao de estao
de trabalho para atender a demanda.
O cenrio, que no veio de nenhum filme de terror (tenho minhas dvidas ;-), exige muita ateno
e cuidado na execuo dos backups, na transferncia dele e em todos os recursos possveis que
possam evitar a perda e corrupo de dados. Guardar os backups somente localmente nos
municpios arriscado porque os discos ou at mesmo o servidor pode ser danificado
permanentemente. Enviar os dados para a capital no to fcil, pois, os links so lentos e
instveis, como poderemos constatar em breve neste artigo.
Em resumo o script de backup faz o seguinte: a) realiza a cpia full on-line localmente nos
municpios; b) transferem para um servidor de backup remoto, que se encontra em Macap-AP,
via FTP; e c) geram um histrico de execuo do backup e da transferncia via FTP, registrando
os erros identificados.
Como uma rotina de backup deve estar de acordo com o ambiente, adversidade, recursos
disponveis e tipos de backups pretendidos, importante fazer alguns questionamentos e colocar
alguns pontos bastante relevantes, sendo que muitos j foram includos na poltica de backup do
TJAP. Todos os backups mencionados aqui so full e on-line, de forma que os backups e as
tranferncias so executado pela tarde e a noite em algumas situaes. O PITR utilizado mas no
ser detalhado aqui.
ORGANIZAO DOS TPICOS:
1. Orientaes Gerais
2. O Backup
3. A Transferncias Via FTP
4. O Armazenamento e Arquivamento Definitivo
1. ORIENTAES GERAIS
1.1. Voc deve possuir, seguir e verificar constantemente a execuo de sua poltica de backup.
1.2. Do que devo fazer backup?
a) Principalmente:
Das bases de produo.
Dos usurios, grupos e permisses. Algumas pessoas ignoram ou deixam muito defasados
este tipo de backup.
Dos arquivos de configurao do PostgreSQL. Outro backup ignorado.
Dos scripts de backup e monitoramento, scripts de inicializao personalizada.
Das bases de teste que esto sendo utilizadas.
E tudo mais que possa ter importncia e reduzir retrabalho para voc e para sua empresa.

http://postgresqlnoamapa.wordpress.com/

13/04/2011

PostgreSQL Amap

Pgina 4 de 10

1.3. No esquea que o backup faz parte de sua rotina para aumentar a disponibilidade do SGBD.
Em um grave problema de hardware, somado a ausncia de uma rotina eficiente de backup, podede ter a perda de trabalho de vrios dias ou at mesmo meses.
1.4. Se voc j passou por alguma situao de perda de dados, desorganizao, backups que
desapareceram ou no correspondem a data que apresentam, pare e reveja suas rotinas e sua
equipe em busca de melhorias. Seu emprego pode estar ameaado e no se esquea que sua
reputao profissional est constantemente sendo construda. Um erro, dependendo da gravidade,
pode ser perfeitamente contornado. Mas o mesmo erro cometido repetidas vezes pode demonstrar
falta de competncia, de compromisso e de profissionalismo. Diga no as demisses por justa
causa! Corrija e assuma seus erros;

Tabela T1 Exemplo de relatrio possvel de ser construdo com as informaes coletadas durante
o backup e sua transferncia.
Nota 1: Relatrio do backups do dia 12 de maro de 2009, quinta-feira, com nvel de compactao
Z9. Data de emisso do relatrio acima: 13/03/2009 16:41:54.
Nota 2: Algumas informaes foram omitidas ou trocadas de forma que no comprometam a
anlise.
Nota 3: As clulas em vermelho (espaos sem informao preenchida) representam a ausncia da
transferncia via FTP com xito para a capital at o dia e horrio da emisso do relatrio.
Nota 4: Vocs lembram que informamos que a comarca um que se encontra na capital, Macap,
o concentrados dos dados. Por outro lado, se voc somar o tamanho das bases de dados dos
municpio dois (Santana) at o municpio doze (Vitria do Jar), teremos o valor 19.437 MB,
acima do tamanho da capital. Isto se deve porque muitos dados, como a tabela de pessoas, so
comuns a todas as comarcas, ou seja, tem apenas uma cpia na capital que replicada para os
outros municpios. Os dados que so enviados para o concentrador so os dados que no esto na
capital.
1.5. Caso existam vrios servidores para administrar, tem alguma forma de checar se o mesmo
script se encontra em todos?
a) O mesmo script faz o backup e a tranferncia via FTP, devido a grande quantidade de variveis
e funes comuns s duas tarefas. O script tambm utilizado em todos os servidores, as
customizaes necessrias so realizadas em arquivos de configurao separados. Assim, basta
checar o MD5 do script para saber se existe alguma diferena. Uma nova alterao pode ser
realizada em um nico local e facilmente copiada via scp para todos os demais municpios, sem
a necessidade de alterar um a um para adaptar a cada servidor.
b) Como os links de comunicao esto muitas vezes indisponveis, uma alterao importante

http://postgresqlnoamapa.wordpress.com/

13/04/2011

PostgreSQL Amap

Pgina 5 de 10

pode ser realizada e aplicada a maioria dos servidores, e, aps o restabelecimento do link, que
pode levar vrios dias, o servidor correspondente pode ter seu script esquecido de ser atualizado.
1.6. Voc deve tentar automatizar o mximo possvel para minimizar a necessidade de interveno
humana, que deve ficar, sempre que possvel, mais dedicada ao monitoramento e busca contnua
de melhorias. Trabalhos repetitivos so para mquinas, na maioria das vezes.
1.7. Os nveis de backup que o SGBD fornece esto sendo considerados e aproveitados?
a) Conhecer os tipos de backup que seu SGBD oferece ir permitir uma maior consistncia na
elaborao de sua poltica. Voc deve ser capaz de planejar quantas vezes e quais horrios o
backup full dever ser executado. Se necessrio ou no ativar o PITR. Em quanto tempo os logs
de transao sero enviados para uma outra unidade.
b) Voc poder utilizar outras ferramentas, como as disponveis no SO para gerar um backup
incremental e diferencial a partir de vrios backups full para facilitar o armazenamento. Voc pode
utilizar algo como o diff e o patch. Tome cuidado porque esse tipo de backup mais frgil e
trabalhoso. Frgil porque s se?a possvel restaurar at o ponto anterior a um patch com problema,
pois, um patch problemtico cria um efeito domin, invalidando todos os arquivos de patch
criados posteriormente ao mesmo. Trabalhoso porque voc ter de fazer manualmente ou por um
script personalizado para esta finalidade, portanto, deve dominar e testar qualquer soluo
adotada.
c) Cuidado na hora de agendar as transferncias para que o servidor de arquivamento dos backups
no fique congestionado devido ao recebimento de dados de vrios servidores ao mesmo tempo.
1.8. Alguns pontos aqui apresentados podem ser supridos pelo pgAdmin, mas com um scripts
voc no necessita da instalao de nenhum outro mdulo, alm de ter muito mais flexibilidade.
1.9. Observe com cuidado o material que voc est consultado, pois, o script e as instrues aqui
apresentado, assim como qualquer outro material na internet, no est isento de erros. Contamos
com a sua colaborao e suas crticas para melhorar e corrigir qualuqer tipo de problema.
2. O BACKUP
2.1. Todos os backups realizados durante o ms de novembro de 2008 foram realizados com
sucesso?
a) Existem vrios fatores que podem impedir a execuo do backup, tais como hardware com
problema, falta de espao, falta de energia, interrupo via kill de uma rotina de backup em
horrio inapropriado que acabou comprometendo significativamente a carga do sistema, entre
outros. O mais importante possuir uma ou vrias formas de fazer essa verificao o mais fcil
possvel. Descobrir somente quando for necessrio restaurar um backup que o mesmo foi
interrompido, no o momento mais apropriado.
b) Adotou-se guardar os logs da execuo dos backups e das transferncias via FTP em arquivos
csv, alm de alimentar tabelas no banco de dados com as mesmas informaes. As tabelas so
replicadas para a capital, assim, no lugar de sair fazendo SSH em 12 municpios, consultamos
duas tabelas para verificar se tudo ocorreu perfeitamente. Isso facilitou imensamente a verificao
do backup.
2.2. Qual foi o crescimento mdio mensal da minha principal base de dados no ltimo ano? Qual o
banco de dados que mais cresceu? Algum possuiu alguma reduo anormal de tamanho?
a) Manter um histrico da execuo do backup importante por vrios motivos como:
Informaes para projeo de crescimento que sustentem o dimensionamento do hardware
de armazenamento atual;
Identificao de redues anormais do tamanho da base que podem ter sido ocasionadas por
excluso do histrico, alterao de estrutura e normalizao dos dados; Vacuum que
estavam por algum motivo desligados ou no sendo realizados durante vrios meses,
excluso acidental ou criminal de um grande volume de dados, entre outros.

http://postgresqlnoamapa.wordpress.com/

13/04/2011

PostgreSQL Amap

Pgina 6 de 10

Alteraes considerveis no volume de dados podem alterar o comportamento do banco em

relao aos ndices.
Voc pode optar por guardar informaes sobre o tamanho e a quantidade de registros das
tabela no prprio BD. Lembre-se que algumas estatsticas utilizadas na instruo SQL
abaixo, como C.reltuples s estaro atualizadas apos o vacuum, esto, cuidado ao
coletar e considerar fielmente estas informaes. Voc pode optar por fazer um count(*)
dentro de uma funo no PostgreSQL para ter um resultado mais coerente.
SELECT n.nspname AS schemaname, c.relname AS tablename, C.reltuples::int AS Registros
pg_size_pretty(pg_relation_size(n.nspname ||'.'||c.relname)) as Tamanho
FROM pg_class c
LEFT JOIN pg_namespace n ON n.oid = c.relnamespace
LEFT JOIN pg_tablespace t ON t.oid = c.reltablespace
WHERE c.relkind = 'r'::char
--AND n.nspname = 'acc'
AND nspname NOT IN
('dbateste','information_schema','pg_catalog','pg_temp_1','pg_toast','postgres','pub
ORDER BY n.nspname;

Quadro Q1 Consulta SQL com o tamanho e quantidade de registros das tabelas

Referncias:
http://keniamilene.wordpress.com/2007/09/25/volumetria-de-banco-postgresql/
http://amd.co.at/adminwiki/PostgreSQL
2.3. O tempo de execuo de backup de minhas bases aceitvel? Qual a relao
tamanho/tempo para meu hardware atual? Ser que as alteraes realizadas nos arquivos de
configurao do SGBD ou do SO ofereceram-me um melhor rendimento na execuo do backup?
a) O tempo de backup outra informao importante que est relacionada a vrios fatores, tais
como: tamanho da base, tipos de dados armazenados, nvel de compresso adotada para o backup,
horrio de execuo vs quantidade de usurios on-line, verso do SGBD, arquivos de
configurao do SGBD e do sistema operacional, local e mdia de destino do backup, entre outros.
2.4. A hierarquia de diretrios planejada est sendo seguida? A estrutura adotada para o nome do
arquivo de backup suficientemente simples e completo a ponto de fornecer informaes
importantes?
a) bem provvel que tenha sido adotada uma rotina de backups onde existam cpias dirias,
quinzenais, semanais, mensais, ou alguma organizao de perodos semelhantes. Para constatar se
o backup que foi planejado para sbado est sendo arquivado em uma pasta referente cpia da
semana conforme planejado, importante possuir essa informao em algum lugar, o que tambm
ajudar a identificar alteraes nos critrios de arquivamento.
b) Caso se possua o mesmo banco de dados sendo executado em vrios municpios distintos, pode
-se optar por utilizar a seguinte estrutura de diretrios nos servidores de backup e fita. Exemplo:
|- municipio ( Um dos doze: macapa, amapa, calcoene, oiapoque ...)
....|- 2009
........|- janeiro
............|- diario
................|- [ backups de domingo a segunda-feira ]
............ |- semanal
................|- semana1
....................|- [ backup de sbado da 1a semana ]
................|- semana2 ... ate 6a semana
............|- mensal
................|- [ backup para o ultimo dia do ms ]
........|- fevereiro ...
|- outro municipio ...

Quadro Q2 Estrutura proposta para organizao dos backups

http://postgresqlnoamapa.wordpress.com/

13/04/2011

PostgreSQL Amap

Pgina 7 de 10

c) Em algumas situaes, copiar o backup entre diferentes sistemas de arquivos, sistema

operacionais e servios de transferncia pode alterar atributos importantes como a data do arquivo.
Colocar a data e hora da execuo do backup no nome do mesmo pode evitar grandes transtornos
e dores de cabea.
d) Uma conveno para o nome dos backups poderia ser NomeServidor_AnoMesDia(HhMmSm)
Semana_BD.pgb. Assim fica fcil para organizar e localizar os arquivos com expresses
regulares.
Ex: srvdb01_20090307(14h13m09s)sab_dbsit.pgb
2.5. Caso tenha ocorrido algum problema na execuo do backup, o SGBD informou o evento de
alguma forma? O backup foi realizado at o final ou interrompido durante a execuo?
a) Por esse e outros motivos importante guardar as mensagens da execuo do backup e possuir
alguma forma de identificar se o backup foi concludo com xito.
b) Supondo que durante a execuo de um backup faltou energia e o servidor desligou durante o
dump dos bytes finais da ltima tabela, o SGBD no apresentar nenhuma mensagem de erro no
log do backup, afinal, ele, o hardware e o SO estavam perfeitamente bem. Nesta situao o
tamanho do backup no poder ser utilizado como parmetro em um banco OLPT devido a
volatilidade do mesmo.
Para facilitar a identificao deste tipo de problema sempre adicionado uma cadeia de
caracteres no final do arquivo indicando sua concluso com xito. A cadeia escolhida foi
#!@BackupConcluidoComExito@!#.
Poderia tambm verificar em outros logs, como o do SO, para saber se o servio foi
reiniciado no perodo do evento, entretanto a rotatividade dos logs e o fato de possuir vrios
servidores para gerenciar pode dificultar e tornar a pesquisa muito demorada.
c) O histrico da execuo do backup tambm armazena informaes como o cdigo de erro do
backup, mas ele s gerado aps a concluso o interrupo do mesmo. Em caso de queda de
energia o backup ficar incompleto e o histrico no chegar a ser criado.
3. A TRANSFERNCIA VIA FTP
3.1. O backup jpa estava incompleto quando chegou servidor de arquivamento ou ocorreu algum
erro durante a transferncia?
a) Nosso estado, o Amap, possui muita instabilidade nos links de comunicao em todos os
municpios, principalmente porque a maioria dos links disponibilizado via satlite. Assim sendo,
o script deve possuir controles para retransmitir backups que tiveram sua transmisso
interrompida.
Para economizar banda, um backup que foi recebido corretamente via FTP no retransmitido,
por outro lado, um que teve sua transmisso interrompida sempre retransmitido.
b) gerado o MD5 do backup no momento em que ele realizado localmente no servidor,
facilitando a identificao de erros quando o mesmo chega no servidor de bakups via FTP.
Gerar o MD5 pode demorar alguns minutos, e dependendo do tamanho do backup pode ser
invivel, mas mais rpido checar um MD5 do que restaurar um backup e descobrir que
no foram transmitidos os bytes finais. O MD5 pode servir como complemento da
verificao da consistncia dos backups.
c) Para facilitar a identificao dos erros, a transmisso realizada na seguinte seqncia: I) log do
backup; II) MD5 e III) arquivo de backup
3.2. Quanto tempo demora a transmisso do backup? Existe muitas variaes na taxa de
transmisso? O empresa concessionria do link esta fornecendo o que ofereceu?
a) A transferncia dos arquivos so mantidos em histrico, guardando informaes como tempo de
transferncia, cdigo de erro entre outras. Um mesmo arquivo pode possuir vrias tentativas de
transferncia, at que se consiga xito em sua transmisso.

http://postgresqlnoamapa.wordpress.com/

13/04/2011

PostgreSQL Amap

Pgina 8 de 10

b) Sabendo o tempo de transmisso e o volume de crescimento da base voc poder prever, por
exemplo, que daqui a uma ano e meio sero necessrias 6 horas para transferir m nico arquivo de
backup.

Tabela T2 Resumo com incio e mdia de tempo para a transferncia do arquivo de backup via
FTP, realizada dia 13/03/2009.

Tabela T3 Valores aproximados para as taxas de transferncia via FTP.

Nota 1: Parece que o nome da empresa concessionria do Link Rubinho Barrichelos Telecom.
Nota 2: Um arquivo de 203 MB levou impressionantes 03:55 para ser transferido. Se algum
pegar esse mesmo arquivo, gravar em um CD, pegar um carro 1.0 e se dirigir para a capital ainda
vai chegar mais rpido no nosso servidor de backup do que utilizando o link de comunicao. Este
foi outro fator considerado na escolha do nvel de compactao Z9.

http://postgresqlnoamapa.wordpress.com/

13/04/2011

PostgreSQL Amap

Pgina 9 de 10

3.3. A organizao da hierarquia de diretrio do backup no servidor FTP a mesma adotada no

servidor local? Existe essa necessidade?
a) Para manter consistncia da organizao, seguida a mesma hierarquia de diretrios no
servidor local e no FTP. Caso necessrio os diretrios so criados sob demanda em ambos os
servidores.
3.4. Todos os backups desta semana foram enviados para o servidor de arquivamento? Quais od
backups tem prioridade de serem enviados?
a) Por mais que uma comarca passe vrios dias com o link indisponvel, o script sempre tenta
enviar todos os arquivos que esto na fila de pendentes de envio, obedecendo sempre a ordem
decrescente de data de criao do arquivo, ou seja, os backups mais recentes tem prioridades sobre
os mais antigos.
4. O ARMAZENAMENTO E ARQUIVAMENTO DEFINITIVO
4.1. Os backups que foram realizados corretamente podem ser restaurados sem problema? Quais
backups esto sendo arquivados em fita ou outra mdia? Os arquivos so de fcil localizao?
Quantos restores foram executados sem xito at hoje? Esta margem aceitvel?
a) To importante quanto o backup o restore. De nada adianta ter um backup que teve todos os
procedimentos executados sem nenhum erro, mas foi arquivado em uma mdia (fita, dvd, blue-ray,
etc) com problemas. Invariavelmente alguns ambiente no possuem uma infraestrutura capaz de
testar todos os backups realizados, por isso, pode ser mais vantajoso executar os teste por
amostragem, de uma forma aleatria para que durante um perodo determinado, por exemplo uma
semana, todos os servidores tenham pelo menos um de seus backups testados.
b) Possuir e seguir a poltica de armazenamento. O armazenamento e a identificao das mdias
so igualmente importantes. Para facilitar a localizao das informao naquela montanha de
mdias pode ser aconselhvel a utilizao de uma ferramenta para essa finalidade, como por
exemplo o Bacula. E claro, no se esquea que alm da identificao lgica imprescindvel uma
identificao fsica como o nmero do volume, a data, nome dos bancos e responsvel pelo
arquivamento.
c) Quanto mais informaes voc tiver sobre sua rotina melhor. Saber quanto tempo leva um
restore, a transferncia dos dados da mdia e os erros encontrados iram favorecer que suas aes
sejam tomadas com uma maior preciso. Quando ocorrer algum tipo de problema no banco, todos
iro querer saber em quantos minutos o sistema estar de volta.
Certamente voc deve concordar com alguns pontos e discordar de outros que no se adaptam ao
seu ambiente, mas o mais importante que sempre ser bem vinda qualquer melhoria que
possamos incluir na nossa rotina de administrao de banco de dados. Se esse artigo possuir pelo
menos um tpico relevante para voc, j ter pago o tempo que voc passou lendo-o.
Seguindo as recomendaes do Fabio Telles (Adote um artigo sobre PostgreSQL), vou verificar
se interessante incluir o presente artigo no wiki do postgresql. Neste ponto tenho uma sugesto
que acredito ser relevante para a organizao e estruturao dos artigos do wiki do PostgreSQL
em portugus. Em um passado no muito remoto, Telles (sempre ele) sugeriu como deveria ser
um livro sobre PostgreSQL (como deveria ser um livro sobre PostgreSQL). A estrutura
sugerida bastante completa e lgica, e se ns pudermos segui-la quando fossemos postar um
artigo, poderamos ter em pouco tem um passo inicial para a elaborao do livro proposto.
Pretendo em breve elaborar um artigo mostrando a construo do script aqui proposto em um
passo-a-passo para ajudar usurios iniciantes, assim como eu, a entender melhor as linhas nele
contido. Aguardo a colaborao e a sugesto de todos.
Se voc continua agindo sempre da mesma forma, continuar obtendo sempre os mesmo
resultados. (No lembro o nome do autor da frase)
Comentrios (11)

http://postgresqlnoamapa.wordpress.com/

13/04/2011

PostgreSQL Amap

Pgina 10 de 10

Pginas:
About
Blogroll
Blog no WordPress.com.
Blog no WordPress.com.
Categorias:
PostgreSQL
Pesquisar:
Procurar

Arquivos:
maro 2009
Meta:
Registrar-se
Login
RSS
RSS dos comentrios
XHTML Vlido
XFN
Blog no WordPress.com.
Theme: Silver is the New Black. Blog no WordPress.com.

http://postgresqlnoamapa.wordpress.com/

13/04/2011