Blog e Artigos Tecnologia

Blog e Artigos Tecnologia

Who am I?

Sou ūüíĽ Desenvolvedor PHP | Laravel #Fullstack #Dev #DevOps #Laravel #PHP #lucena


What I write about


Recent Posts

Qual a forma correta de se fazer backup?

SQL DUMP

     Também conhecido como pg_dump, essa é a abordagem mais simples de ser executada/implementada. Sua utilização consiste na execução do programa pg_dump.

     Os pré-requisitos para sua utilização são: ter acesso a partir de um host remoto, ou local, acesso liberado ao database para o usuário, e permissão de leitura nas tabelas do banco de dados.

     Obs.: Normalmente se executa o pg_dump com um usuário SUPERUSER, como por exemplo o postgres, para que não haja problemas com permissão de acesso.

                Vantagens:

  • O dump pode ser restaurado em qualquer inst√Ęncia contendo uma vers√£o mais recente do PostgreSQL;
  • O dump pode ser restaurado em um servidor com arquitetura diferente, indo de uma m√°quina 32-bits para uma 64-bits, por exemplo;
  • √Č uma c√≥pia fiel dos dados no momento em que foi iniciada sua execu√ß√£o;
  • √Č poss√≠vel gerar dump de objetos espec√≠ficos ou excluir alguns objetos do dump;
  • Possibilita paralelismo da execu√ß√£o, caso seja utilizado ‚Äúdirectory‚ÄĚ como¬†archive format.

                Desvantagens:

  • Por ser uma c√≥pia fiel dos dados no momento em que o pg_dump come√ßou a ser executado, talvez o tempo entre o √ļltimo¬†dump¬†e o momento de uma poss√≠vel falha, torne invi√°vel a utiliza√ß√£o desse dump para redisponibiliza√ß√£o do ambiente com a menor perda de dados poss√≠vel;
  • Caso seja utilizado o formato PLAIN TEXT, o arquivo gerado pode ser muito grande;
  • O ponto apresentado como ‚Äúvantagem n√ļmero 5‚ÄĚ, esbarra na limita√ß√£o do I/O de disco, ou seja, v√°rios processos podem ser abertos para dump, mas n√£o necessariamente os processos conseguir√£o escalar a leitura e a escrita dos dados no disco.

FILESYSTEM LEVEL BACKUP (sem PITR)

Esse método consiste em realizar uma cópia do diretório de dados do PostgreSQL. A cópia pode ser realizada de muitas formas, como por exemplo: pelo comando cp, rsync, tar, etc.

                Vantagens:

Se executado via rsync, em uma segunda execução, o tempo de geração do backup será muito menor.

                Desvantagens:

  • Para que o backup seja um backup ‚Äú√ļtil‚ÄĚ, √© necess√°rio que a inst√Ęncia de banco de dados esteja off-line¬†ou¬†que seja sinalizado, via comando¬†pg_start_backup(), o in√≠cio da execu√ß√£o de um¬†backup;
  • √Č necess√°rio que a inst√Ęncia esteja off-line para restaura√ß√£o do¬†backup;
  • N√£o √© poss√≠vel determinar quais objetos ser√£o alvo do¬†backup. Com isso, todos os objetos da inst√Ęncia de banco de dados far√£o parte do¬†backup;
  • Em caso de¬†crash, todas as altera√ß√Ķes que ocorreram entre o momento em que¬†backup¬†foi executado e a falha, ser√£o perdidas (Caso n√£o esteja configurado o¬†Point-in-Time Recovery).

CONTINUOUS ARCHIVE + POINT-IN-TIME RECOVERY

Por padrão, o PostgreSQL retém os logs de transação no diretório $PGDATA/pg_xlog. Após um determinado tempo, esses logs de transação podem ser arquivados em uma área específica a seu critério (Ex.: servidor de arquivos, TSM, fita, etc.). Dessa forma, é possível combinarmos o FILE-SYSTEM-LEVEL BACKUP com os logs de transação arquivados. Em caso de crash é possível restaurar o backup de filesystem e, posteriormente, executar os logs de transação até um momento anterior à falha.

                Vantagens:

  • Em caso de crash, a perda de dados √© m√≠nima devido √† execu√ß√£o dos logs de transa√ß√£o arquivados, sobre o¬†filesystem level backup¬†da inst√Ęncia;
  • √Č poss√≠vel executar o backup com o banco de dados online;

                Desvantagem:

  • N√£o √© poss√≠vel determinar quais objetos ser√£o alvo do backup. Com isso, todos os objetos da inst√Ęncia de banco de dados far√£o parte do backup;
  • Durante a execu√ß√£o do backup, a quantidade de logs de transa√ß√£o retidos no $PGDATA/pg_xlog pode aumentar substancialmente devido ao fato de, durante o backup, o PostgreSQL reter logs de transa√ß√£o para que durante o processo de restaura√ß√£o, a base de dados esteja em um estado de consist√™ncia adequado.
  • A administra√ß√£o de desse m√©todo √© uma das mais trabalhosas;

Existem outras solu√ß√Ķes de backup para o PostgreSQL que vale √† pena dar uma olhada, como por exemplo: pg_rman, barman, etc.

√Č muito importante que entendamos que essas metodologias n√£o devem ser utilizadas individualmente, mas sim devemos focar na hip√≥tese de CRIAR NOSSA PR√ďPRIA SOLU√á√ÉO DE BACKUP. Por exemplo:

√Č extremamente interessante mantermos uma rotina de backup f√≠sico (filesystem level backup), aliada ao PITR (Point-in-time recovery). Estando funcional, essa rotina nos transmitir√° um pouco mais de confian√ßa em rela√ß√£o a poss√≠veis desastres. O principal problema reside no fato de que esse backup s√≥ poder√° ser restaurado em um servidor com as mesmas configura√ß√Ķes do servidor de origem (Arquitetura, vers√£o de SO, Vers√£o do PostgreSQL, etc.).

Para complementar essa ‚Äúsolu√ß√£o de backup‚ÄĚ, √© bastante interessante manter em paralelo a execu√ß√£o de backups l√≥gicos (pg_dump ou pg_dumpall). Imagine que voc√™ precise restaurar um backup de 10 anos atr√°s em um momento onde o PostgreSQL estava na vers√£o 7.0, sistema operacional Red Hat 3 ‚Äúx86‚ÄĚ. Em uma situa√ß√£o dessas voc√™ dever√° CONSTRUIR UM SERVIDOR NOVO COM ESSES MESMOS RECURSOS¬†ou, caso tenha dispon√≠vel, restaurar seu dump em qualquer vers√£o superior do PostgreSQl, seja l√° qual for a vers√£o do sistema operacional ou a arquitetura.

post 1 - Perguntas e Respostas - melhor forma de backup_4
http://pghelp.com.br/index.php/2016/08/24/perguntas-e-respostas-qual-a-forma-correta-de-se-fazer-backup/