Autor: Dailson Igo; Colaboradores: Marco Craveiro, Gustavo e Jucicléia.
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. Não consegui formatar as tabelas, por isso optei por transformar em imagens.
Você já questionou a eficiência do seu script de backup? Já parou algumas horas para tentar melhorá-lo? Se deparou com alguma situação em que ele se mostrou ineficiente ou inapropriado?
Caso seu script de backup se resuma a apenas executar uma instrução do tipo “pg_dump -h 127.0.0.1 -U postgres -v -o -b -i -Z9 -Fc -f NomeBackup NomeBanco”, pode ser necessário considerar alguns pontos que poderão 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 Justiça do Estado do Amapá (TJAP) que, para atender seu principal sistema de nome Tucujuris (Sistema de Gestão Judiciária de 1º e 2º Grau) possui um banco de dados em cada uma das 12 comarcas, um na capital (Macapá-AP) e os outros onze em municípios distintos.
Figura F1 – Disposição geográfica dos municípios 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 municípios. Os outros municípios possuem seus dados e alguns outros que são comuns a todos os municípios/comarcas. A sincronização de dados é realizada com uma replicação multi-master assíncrona fornecida pela empresa dbExperts, além de algumas implementações feitas pelo TJAP. Na verdade a replicação vai um pouco além do multi-master, ela possui um esquema de rotas, mas vamos deixar isso para um momento mais apropriado.
Não foi possível utilizar apenas um único servidor com o PostgreSQL para atender a demanda de todos os 12 municípios pela fato da precariedade dos links de comunicação dentro de nosso Estado (para fora também é igualmente precário), onde a comunicação via satélite é utilizado na maior parte das situações, e em uma menor quantidade, a comunicação via rádio.
Em ambas as formas de comunicação é muito comum a instabilidade do link, o que poderia ocasionar falta de comunicação por períodos de várias semanas (como já aconteceu diversas vezes), ou seja, várias semanas sem comunicação, várias semanas sem BD, várias semanas de trabalho sem sistema, se possível fosse trabalhar. Como se não bastasse a concessionária de energia elétrica também peca na qualidade dos serviços prestados a todos os municípios, o que já ocasionou a danificação de vários discos e equipamentos.
Para minimizar as chances de perda e corrupção de dados, recentemente no ano de 2008 novos servidores foram instalados com RAID 10 na capital e RAID 5 nos demais municípios. A pouco tempo somente na capital e em Santana possuíamos uma máquina que poderíamos chamar de “servidor”, nos outros municípios tínhamos desktops com uma modesta configuração de estação de trabalho para atender a demanda.
O cenário, que não veio de nenhum filme de terror (tenho minhas dúvidas ;-), exige muita atenção e cuidado na execução dos backups, na transferência dele e em todos os recursos possíveis que possam evitar a perda e corrupção de dados. Guardar os backups somente localmente nos municípios é arriscado porque os discos ou até mesmo o servidor pode ser danificado permanentemente. Enviar os dados para a capital não é tão fácil, pois, os links são lentos e instáveis, como poderemos constatar em breve neste artigo.
Em resumo o script de backup faz o seguinte: a) realiza a cópia full on-line localmente nos municípios; b) transferem para um servidor de backup remoto, que se encontra em Macapá-AP, via FTP; e c) geram um histórico de execução do backup e da transferência via FTP, registrando os erros identificados.
Como uma rotina de backup deve estar de acordo com o ambiente, adversidade, recursos disponíveis e tipos de backups pretendidos, é importante fazer alguns questionamentos e colocar alguns pontos bastante relevantes, sendo que muitos já foram incluídos na política de backup do TJAP. Todos os backups mencionados aqui são full e on-line, de forma que os backups e as tranferências são executado pela tarde e a noite em algumas situações. O PITR é utilizado mas não será detalhado aqui.
ORGANIZAÇÃO DOS TÓPICOS:
1. Orientações Gerais
2. O Backup
3. A Transferências Via FTP
4. O Armazenamento e Arquivamento Definitivo
1. ORIENTAÇÕES GERAIS
1.1. Você deve possuir, seguir e verificar constantemente a execução de sua política de backup.
1.2. Do que devo fazer backup?
a) Principalmente:
- Das bases de produção.
- Dos usuários, grupos e permissões. Algumas pessoas ignoram ou deixam muito defasados este tipo de backup.
- Dos arquivos de configuração do PostgreSQL. Outro backup ignorado.
- Dos scripts de backup e monitoramento, scripts de inicialização personalizada.
- Das bases de teste que estão sendo utilizadas.
- E tudo mais que possa ter importância e reduzir retrabalho para você e para sua empresa.
1.3. Não esqueça que o backup faz parte de sua rotina para aumentar a disponibilidade do SGBD. Em um grave problema de hardware, somado a ausência de uma rotina eficiente de backup, pode-de ter a perda de trabalho de vários dias ou até mesmo meses.
1.4. Se você já passou por alguma situação de perda de dados, desorganização, backups que desapareceram ou não correspondem a data que apresentam, pare e reveja suas rotinas e sua equipe em busca de melhorias. Seu emprego pode estar ameaçado e não se esqueça que sua reputação profissional está constantemente sendo construída. Um erro, dependendo da gravidade, pode ser perfeitamente contornado. Mas o mesmo erro cometido repetidas vezes pode demonstrar falta de competência, de compromisso e de profissionalismo. Diga não as demissões por justa causa! Corrija e assuma seus erros;
Tabela T1 Exemplo de relatório possível de ser construído com as informações coletadas durante o backup e sua transferência.
Nota 1: Relatório do backups do dia 12 de março de 2009, quinta-feira, com nível de compactação Z9. Data de emissão do relatório acima: 13/03/2009 16:41:54.
Nota 2: Algumas informações foram omitidas ou trocadas de forma que não comprometam a análise.
Nota 3: As células em vermelho (espaços sem informação preenchida) representam a ausência da transferência via FTP com êxito para a capital até o dia e horário da emissão do relatório.
Nota 4: Vocês 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 município “dois” (Santana) até o município “doze” (Vitória do Jarí), teremos o valor 19.437 MB, acima do tamanho da capital. Isto se deve porque muitos dados, como a tabela de pessoas, são comuns a todas as comarcas, ou seja, tem apenas uma cópia na capital que é replicada para os outros municípios. Os dados que são enviados para o concentrador são os dados que não estão na capital.
1.5. Caso existam vários 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 tranferência via FTP, devido a grande quantidade de variáveis e funções comuns às duas tarefas. O script também é utilizado em todos os servidores, as customizações necessárias são realizadas em arquivos de configuração separados. Assim, basta checar o MD5 do script para saber se existe alguma diferença. Uma nova alteração pode ser realizada em um único local e facilmente copiada via “scp” para todos os demais municípios, sem a necessidade de alterar um a um para adaptar a cada servidor.
b) Como os links de comunicação estão muitas vezes indisponíveis, uma alteração importante pode ser realizada e aplicada a maioria dos servidores, e, após o restabelecimento do link, que pode levar vários dias, o servidor correspondente pode ter seu script esquecido de ser atualizado.
1.6. Você deve tentar automatizar o máximo possível para minimizar a necessidade de intervenção humana, que deve ficar, sempre que possível, mais dedicada ao monitoramento e busca contínua de melhorias. Trabalhos repetitivos são para máquinas, na maioria das vezes.
1.7. Os níveis de backup que o SGBD fornece estão sendo considerados e aproveitados?
a) Conhecer os tipos de backup que seu SGBD oferece irá permitir uma maior consistência na elaboração de sua política. Você deve ser capaz de planejar quantas vezes e quais horários o backup full deverá ser executado. Se é necessário ou não ativar o PITR. Em quanto tempo os logs de transação serão enviados para uma outra unidade.
b) Você poderá utilizar outras ferramentas, como as disponíveis no SO para gerar um backup incremental e diferencial a partir de vários backups full para facilitar o armazenamento. Você pode utilizar algo como o diff e o patch. Tome cuidado porque esse tipo de backup é mais frágil e trabalhoso. Frágil porque só se?a possível restaurar até o ponto anterior a um patch com problema, pois, um patch problemático 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 solução adotada.
c) Cuidado na hora de agendar as transferências para que o servidor de arquivamento dos backups não fique congestionado devido ao recebimento de dados de vários servidores ao mesmo tempo.
1.8. Alguns pontos aqui apresentados podem ser supridos pelo pgAdmin, mas com um scripts você não necessita da instalação de nenhum outro módulo, além de ter muito mais flexibilidade.
1.9. Observe com cuidado o material que você está consultado, pois, o script e as instruções aqui apresentado, assim como qualquer outro material na internet, não está isento de erros. Contamos com a sua colaboração e suas críticas para melhorar e corrigir qualuqer tipo de problema.
2. O BACKUP
2.1. Todos os backups realizados durante o mês de novembro de 2008 foram realizados com sucesso?
a) Existem vários fatores que podem impedir a execução do backup, tais como hardware com problema, falta de espaço, falta de energia, interrupção via “kill” de uma rotina de backup em horário inapropriado que acabou comprometendo significativamente a carga do sistema, entre outros. O mais importante é possuir uma ou várias formas de fazer essa verificação o mais fácil possível. Descobrir somente quando for necessário restaurar um backup que o mesmo foi interrompido, não é o momento mais apropriado.
b) Adotou-se guardar os logs da execução dos backups e das transferências via FTP em arquivos csv, além de alimentar tabelas no banco de dados com as mesmas informações. As tabelas são replicadas para a capital, assim, no lugar de sair fazendo SSH em 12 municípios, consultamos duas tabelas para verificar se tudo ocorreu perfeitamente. Isso facilitou imensamente a verificação do backup.
2.2. Qual foi o crescimento médio mensal da minha principal base de dados no último ano? Qual o banco de dados que mais cresceu? Algum possuiu alguma redução anormal de tamanho?
a) Manter um histórico da execução do backup é importante por vários motivos como:
- Informações para projeção de crescimento que sustentem o dimensionamento do hardware de armazenamento atual;
- Identificação de reduções anormais do tamanho da base que podem ter sido ocasionadas por exclusão do histórico, alteração de estrutura e normalização dos dados; Vacuum que estavam por algum motivo desligados ou não sendo realizados durante vários meses, exclusão acidental ou criminal de um grande volume de dados, entre outros.
- Alterações consideráveis no volume de dados podem alterar o comportamento do banco em relação aos índices.
- Você pode optar por guardar informações sobre o tamanho e a quantidade de registros das tabela no próprio BD. Lembre-se que algumas estatísticas utilizadas na instrução SQL abaixo, como “C.reltuples” só estarão atualizadas apos o “vacuum”, estão, cuidado ao coletar e considerar fielmente estas informações. Você pode optar por fazer um “count(*)” dentro de uma função 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','publico','public')
ORDER BY n.nspname;
Quadro Q1 Consulta SQL com o tamanho e quantidade de registros das tabelas
Referências:
http://keniamilene.wordpress.com/2007/09/25/volumetria-de-banco-postgresql/
http://amd.co.at/adminwiki/PostgreSQL
2.3. O tempo de execução de backup de minhas bases é aceitável? Qual é a relação tamanho/tempo para meu hardware atual? Será que as alterações realizadas nos arquivos de configuração do SGBD ou do SO ofereceram-me um melhor rendimento na execução do backup?
a) O tempo de backup é outra informação importante que está relacionada a vários fatores, tais como: tamanho da base, tipos de dados armazenados, nível de compressão adotada para o backup, horário de execução vs quantidade de usuários on-line, versão do SGBD, arquivos de configuração do SGBD e do sistema operacional, local e mídia de destino do backup, entre outros.
2.4. A hierarquia de diretórios planejada está sendo seguida? A estrutura adotada para o nome do arquivo de backup é suficientemente simples e completo a ponto de fornecer informações importantes?
a) É bem provável que tenha sido adotada uma rotina de backups onde existam cópias diárias, quinzenais, semanais, mensais, ou alguma organização de períodos semelhantes. Para constatar se o backup que foi planejado para sábado está sendo arquivado em uma pasta referente à cópia da semana conforme planejado, é importante possuir essa informação em algum lugar, o que também ajudará a identificar alterações nos critérios de arquivamento.
b) Caso se possua o mesmo banco de dados sendo executado em vários municípios distintos, pode-se optar por utilizar a seguinte estrutura de diretórios 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 sábado da 1a semana ] ................|- semana2 ... ate 6a semana ............|- mensal ................|- [ backup para o ultimo dia do mês ] ........|- fevereiro ... |- outro municipio ...
Quadro Q2 Estrutura proposta para organização dos backups
c) Em algumas situações, copiar o backup entre diferentes sistemas de arquivos, sistema operacionais e serviços de transferência pode alterar atributos importantes como a data do arquivo. Colocar a data e hora da execução do backup no nome do mesmo pode evitar grandes transtornos e dores de cabeça.
d) Uma convenção para o nome dos backups poderia ser “NomeServidor_AnoMesDia(HhMmSm)Semana_BD.pgb”. Assim fica fácil para organizar e localizar os arquivos com expressões regulares.
Ex: “srvdb01_20090307(14h13m09s)sab_dbsit.pgb”
2.5. Caso tenha ocorrido algum problema na execução do backup, o SGBD informou o evento de alguma forma? O backup foi realizado até o final ou interrompido durante a execução?
a) Por esse e outros motivos é importante guardar as mensagens da execução do backup e possuir alguma forma de identificar se o backup foi concluído com êxito.
b) Supondo que durante a execução de um backup faltou energia e o servidor desligou durante o dump dos bytes finais da última tabela, o SGBD não apresentará nenhuma mensagem de erro no log do backup, afinal, ele, o hardware e o SO estavam perfeitamente bem. Nesta situação o tamanho do backup não poderá ser utilizado como parâmetro em um banco OLPT devido a volatilidade do mesmo.
- Para facilitar a identificação deste tipo de problema sempre é adicionado uma cadeia de caracteres no final do arquivo indicando sua conclusão com êxito. A cadeia escolhida foi “#!@BackupConcluidoComExito@!#”.
- Poderia também verificar em outros logs, como o do SO, para saber se o serviço foi reiniciado no período do evento, entretanto a rotatividade dos logs e o fato de possuir vários servidores para gerenciar pode dificultar e tornar a pesquisa muito demorada.
c) O histórico da execução do backup também armazena informações como o código de erro do backup, mas ele só é gerado após a conclusão o interrupção do mesmo. Em caso de queda de energia o backup ficará incompleto e o histórico não chegará a ser criado.
3. A TRANSFERÊNCIA VIA FTP
3.1. O backup jpa estava incompleto quando chegou servidor de arquivamento ou ocorreu algum erro durante a transferência?
a) Nosso estado, o Amapá, possui muita instabilidade nos links de comunicação em todos os municípios, principalmente porque a maioria dos links é disponibilizado via satélite. Assim sendo, o script deve possuir controles para retransmitir backups que tiveram sua transmissão interrompida.
Para economizar banda, um backup que foi recebido corretamente via FTP não é retransmitido, por outro lado, um que teve sua transmissão interrompida sempre é retransmitido.
b) É gerado o MD5 do backup no momento em que ele é realizado localmente no servidor, facilitando a identificação 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 inviável, mas é mais rápido checar um MD5 do que restaurar um backup e descobrir que não foram transmitidos os bytes finais. O MD5 pode servir como complemento da verificação da consistência dos backups.
c) Para facilitar a identificação dos erros, a transmissão é realizada na seguinte seqüência: I) log do backup; II) MD5 e III) arquivo de backup
3.2. Quanto tempo demora a transmissão do backup? Existe muitas variações na taxa de transmissão? O empresa concessionária do link esta fornecendo o que ofereceu?
a) A transferência dos arquivos são mantidos em histórico, guardando informações como tempo de transferência, código de erro entre outras. Um mesmo arquivo pode possuir várias tentativas de transferência, até que se consiga êxito em sua transmissão.
b) Sabendo o tempo de transmissão e o volume de crescimento da base você poderá prever, por exemplo, que daqui a uma ano e meio serão necessárias 6 horas para transferir m único arquivo de backup.
Tabela T2 – Resumo com início e média de tempo para a transferência do arquivo de backup via FTP, realizada dia 13/03/2009.
Tabela T3 – Valores aproximados para as taxas de transferência via FTP.
Nota 1: Parece que o nome da empresa concessionária do Link é Rubinho Barrichelo’s Telecom.
Nota 2: Um arquivo de 203 MB levou impressionantes 03:55 para ser transferido. Se alguém pegar esse mesmo arquivo, gravar em um CD, pegar um carro 1.0 e se dirigir para a capital ainda vai chegar mais rápido no nosso servidor de backup do que utilizando o link de comunicação. Este foi outro fator considerado na escolha do nível de compactação Z9.
3.3. A organização da hierarquia de diretório do backup no servidor FTP é a mesma adotada no servidor local? Existe essa necessidade?
a) Para manter consistência da organização, é seguida a mesma hierarquia de diretórios no servidor local e no FTP. Caso necessário os diretórios são 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 vários dias com o link indisponível, o script sempre tenta enviar todos os arquivos que estão na “fila” de pendentes de envio, obedecendo sempre a ordem decrescente de data de criação 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 estão sendo arquivados em fita ou outra mídia? Os arquivos são de fácil localização? Quantos restores foram executados sem êxito até hoje? Esta margem é aceitável?
a) Tão 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 mídia (fita, dvd, blue-ray, etc) com problemas. Invariavelmente alguns ambiente não possuem uma infraestrutura capaz de testar todos os backups realizados, por isso, pode ser mais vantajoso executar os teste por amostragem, de uma forma aleatória para que durante um período determinado, por exemplo uma semana, todos os servidores tenham pelo menos um de seus backups testados.
b) Possuir e seguir a política de armazenamento. O armazenamento e a identificação das mídias são igualmente importantes. Para facilitar a localização das informação naquela montanha de mídias pode ser aconselhável a utilização de uma ferramenta para essa finalidade, como por exemplo o Bacula. E claro, não se esqueça que além da identificação lógica é imprescindível uma identificação física como o número do volume, a data, nome dos bancos e responsável pelo arquivamento.
c) Quanto mais informações você tiver sobre sua rotina melhor. Saber quanto tempo leva um restore, a transferência dos dados da mídia e os erros encontrados iram favorecer que suas ações sejam tomadas com uma maior precisão. Quando ocorrer algum tipo de problema no banco, todos irão querer saber em quantos “minutos” o sistema estará de volta.
Certamente você deve concordar com alguns pontos e discordar de outros que não se adaptam ao seu ambiente, mas o mais importante é que sempre será bem vinda qualquer melhoria que possamos incluir na nossa rotina de administração de banco de dados. Se esse artigo possuir pelo menos um tópico relevante para você, já terá pago o tempo que você passou lendo-o.
Seguindo as recomendações do Fabio Telles (Adote um artigo sobre PostgreSQL), vou verificar se é interessante incluir o presente artigo no wiki do postgresql. Neste ponto tenho uma sugestão que acredito ser relevante para a organização e estruturação dos artigos do wiki do PostgreSQL em português. Em um passado não 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 lógica, e se nós pudermos segui-la quando fossemos postar um artigo, poderíamos ter em pouco tem um passo inicial para a elaboração do livro proposto.
Pretendo em breve elaborar um artigo mostrando a construção do script aqui proposto em um passo-a-passo para ajudar usuários iniciantes, assim como eu, a entender melhor as linhas nele contido. Aguardo a colaboração e a sugestão de todos.
Se você continua agindo sempre da mesma forma, continuará obtendo sempre os mesmo resultados. (Não lembro o nome do autor da frase)
