Backups incrementais do PostgreSQL com pgBackRest. Parte 2. Criptografia, inicialização em S3, restauração em um novo servidor, PITR

Este artigo é uma continuação do artigo "Backups incrementais Postgresql com pgbackrest - o curso de um jovem soldado do desenvolvedor".



Na primeira parte, aprendemos como fazer backups incrementais, enviá-los a um servidor remoto (repositório com backups) e reverter para o último backup.

Neste artigo, aprenderemos como criptografar backups, fazer upload deles para armazenamento compatível com S3 (em vez de um segundo servidor de repositório), recuperar em um cluster limpo e, finalmente, recuperação pontual (PITR).


Momento O



autor não tem a pretensão de ser um DBA, mas às vezes gosta de configurar e ver tudo sozinho.



Treinamento



Para reproduzir este manual, precisamos:



  1. Servidor de banco de dados (instalaremos o pgbackrest nele);
  2. Armazenamento S3 (você pode usar Amazon ou qualquer compatível com S3, usarei Amazon S3);
  3. Terceiro servidor. Opcional. Nele praticaremos a implantação do postgresql e do pgbackrest do zero, implantando um backup existente do armazenamento S3 (o servidor queimou, mudou, etc.);


Presume-se que você já tenha o postgresql instalado e, portanto, o usuário postgres também exista.



Descrevi o processo de instalação do pgbackrest no artigo anterior, mas para o caso de o duplicar novamente (lembro a você: antes de instalar, crie um usuário sudo para você - usarei um usuário sudo com o nome de usuário pgbackrest).



Para que você tenha menos problemas ao reproduzir as instruções, escrevo em itálico onde, por qual usuário e com quais direitos executei o comando ao escrever e verificar o artigo.



Seguiremos por este caminho:



Configurar postgresql e pgbackrest Configurar

criptografia de backups (duas linhas)

Aprender como fazer backup e enviar para armazenamento S3 (cinco linhas)

Faça um backup

Vamos imaginar que quebramos o cluster, implantamos em um novo servidor, conectamos o repositório S3 existente e

fazemos o backup. Vamos dar uma olhada em PITR (Point In Time Recovery): vamos recuperar até um certo ponto no tempo (digamos que pgbackrest já tenha feito backup da tabela suspensa, mas precisamos reverter 4 horas quando o sinal ainda existia)



Vamos!



Instalando o pgBackRest



usuário sudo ou root:



1. Baixe o arquivo de pgbackrest e transfira seu conteúdo para a pasta / build:



sudo mkdir /build
sudo wget -q -O - \
       https://github.com/pgbackrest/pgbackrest/archive/release/2.18.tar.gz | \
       sudo tar zx -C /build


2. Instale as dependências necessárias para a construção:



sudo apt-get update
sudo apt-get install build-essential libssl-dev libxml2-dev libperl-dev zlib1g-dev \
       libpq-dev


3. Montagem do encosto pgbackrest:



cd /build/pgbackrest-release-2.18/src && sudo ./configure
sudo make -s -C /build/pgbackrest-release-2.18/src


4. Copie o arquivo executável para o diretório / usr / bin:



sudo cp /build/pgbackrest-release-2.18/src/pgbackrest /usr/bin
sudo chmod 755 /usr/bin/pgbackrest


5.pgBackRest requer perl. Instalar:



sudo apt-get install perl


6. Crie diretórios para os registros, conceda a eles certos direitos:



sudo mkdir -p -m 770 /var/log/pgbackrest
sudo chown postgres:postgres /var/log/pgbackrest
sudo mkdir -p /etc/pgbackrest
sudo mkdir -p /etc/pgbackrest/conf.d
sudo touch /etc/pgbackrest/pgbackrest.conf
sudo chmod 640 /etc/pgbackrest/pgbackrest.conf
sudo chown postgres:postgres /etc/pgbackrest/pgbackrest.conf


7. Verifique:



pgbackrest version


Configurando postgresql e pgBackRest



usuário sudo ou root:



1. Faça as configurações necessárias em postgresql.conf (ele está localizado na pasta / etc / postgresql / 11 / main) para que o pgBackRest funcione:



archive_command = 'pgbackrest --stanza=main archive-push %p' #  main -  .   postgres    main.
archive_mode = on
max_wal_senders = 3
wal_level = replica


2. Vamos fazer as configurações necessárias no arquivo de configuração pgbackrest (/etc/pgbackrest/pgbackrest.conf):



[main]
pg1-path=/var/lib/postgresql/11/main

[global]
log-level-file=detail
repo1-cipher-pass=tr5+BXdfdoxeyUqfo6AzLTrW+c+Jfd/1QbQj2CDMMBwtB0YGH3EJajry4+Eeen6D
repo1-cipher-type=aes-256-cbc
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2 # ,     . ..           ,      .    "     " -     .
repo1-type=s3
repo1-s3-bucket=pgbackrest-part2-tutorial
repo1-s3-endpoint=s3.us-east-1.amazonaws.com
repo1-s3-region=us-east-1
repo1-s3-key=9wdS3G8U5wz7kNsFWVGck7DDZ7DtVDtbM
repo1-s3-key-secret=A9zRmW16zXKt2vVA8mmNsFWy2mUAPYHa
start-fast=y

[global:archive-push]
compress-level=3


Como você entende, aqui configuramos imediatamente a criptografia e configuramos o suporte para armazenamento S3.



PS Não deve haver nenhum comentário na configuração.

PS Para gerar uma chave de criptografia forte, você pode usar o comando:



openssl rand -base64 48


Criação de repositório



usuário sudo ou root:



sudo mkdir -m 770 /var/lib/pgbackrest
sudo chown -R postgres /var/lib/pgbackrest/
sudo -u postgres pgbackrest --stanza=main stanza-create


Se tudo deu certo, então no balde S3 você verá os arquivos gerados pelo pgbackrest.



Fazendo um backup:



usuário sudo ou root:



sudo -u postgres pgbackrest --log-level-console=info --stanza=main backup


pgBackRest criará o primeiro backup completo. Se desejar, você pode executar o comando backup novamente e certificar-se de que o sistema criará um backup incremental.



Se quiser refazer um backup completo, especifique um sinalizador adicional:



sudo -u postgres pgbackrest --log-level-console=info --stanza=main --type=full backup


Você pode ver a lista de backups usando o comando:



sudo -u postgres pgbackrest --stanza=main info




Restaurando o backup:



usuário sudo ou root:



1. Pare o cluster em execução:



sudo pg_ctlcluster 11 main stop


2. Recuperando de um backup:



sudo -u postgres pgbackrest --stanza=main --log-level-console=info --delta --recovery-option=recovery_target=immediate restore


Para restaurar o banco de dados ao estado do último backup FULL, use o comando sem especificar recovery_target:



sudo -u postgres pgbackrest --stanza=main --log-level-console=info --delta restore


Importante! Após a recuperação, pode acontecer que o banco de dados trava no modo de recuperação (ocorrerão erros como ERROR: não é possível executar DROP DATABASE em uma transação somente leitura). Resolve-se da seguinte forma (terá de aguardar um pouco depois de executar o comando):



sudo -u postgres psql -c "select pg_wal_replay_resume()"


UPD: Pelo que entendi, esse erro ocorre devido ao fato de que após a recuperação com recovery_target = imediato, pgbackrest pausa o banco de dados . Para evitar isso, você precisa especificar adicionalmente alguns sinalizadores (você pode ler seu significado aqui e aqui ):



sudo -u postgres pgbackrest --stanza=main --log-level-console=info --delta --recovery-option=recovery_target=immediate --target-action=promote --type=immediate restore


Na verdade, é possível restaurar um backup específico por seu nome. Aqui , fornecerei apenas um link para a descrição desse recurso na documentação . Os desenvolvedores aconselham o uso desse parâmetro com cuidado e explicam o porquê. Por conta própria, posso acrescentar que o usei. O principal é certificar-se de que após a recuperação o banco de dados saiu do modo de recuperação (selecione pg_is_in_recovery () deve mostrar "f") e apenas no caso de fazer um backup completo após a recuperação.



3. Inicie o cluster:



sudo pg_ctlcluster 11 main start


Depois de restaurar o backup, faremos um segundo backup:

sudo -u postgres pgbackrest --log-level-console=info --stanza=main backup


Restaurando o backup para um cluster limpo:



Vamos imaginar que algo terrível aconteceu - o servidor queimou (caiu, inundou, perdeu o acesso). Você precisa restaurar tudo em um servidor novo e limpo. No novo servidor, já criamos um usuário sudo, instalamos o pgbackrest, instalamos o postgresql e temos um cluster principal limpo e novo.



Tudo o que precisamos fazer é definir a configuração do postgresql e do pgBackRest da mesma forma que no servidor anterior, reiniciar o postgresql e executar a ordem de comando semelhante à restauração:



usuário sudo ou root:



1. Pare o cluster em execução:



sudo pg_ctlcluster 11 main stop


2. Recuperando de um backup:



sudo -u postgres pgbackrest --stanza=main --log-level-console=info --delta --recovery-option=recovery_target=immediate  --target-action=promote --type=immediate restore


PS Eu descrevi as nuances e sutilezas desse comando acima. 



3. Inicie o cluster:



sudo pg_ctlcluster 11 main start


Depois de restaurar o backup, precisamos fazer um segundo backup:



sudo -u postgres pgbackrest --log-level-console=info --stanza=main backup


Isso, na verdade, é tudo. O fogo está apagado.



Recuperação pontual (PITR)



Imaginemos tal situação que às 16h00 foi criado um backup e às 18h05 apagámos acidentalmente uma placa importante na qual conseguiram entrar em 2 horas muitos dados importantes que não gostaríamos de perder. O PgBackRest às custas do PostgreSQL nos oferece essa oportunidade: podemos retroceder para um ponto específico no tempo, desde que tenhamos informações suficientes para recuperar.



Funciona assim:



  1. Dizemos que queremos voltar para o horário 18:04;
  2. pgBackRest procura o último backup atual (16:00);
  3. Restaura, mas nem tudo rola, mas apenas o que conseguimos fazer antes de 18.04;


PS este mecanismo é construído em logs do WAL. Você pode ler aqui .



Você pode realizar a recuperação em um ponto específico no tempo (após interromper o cluster) com este comando:



sudo -u postgres pgbackrest --stanza=main --log-level-console=info --delta --type=time "--target=2020-09-06 18:27:24.561458+02" --target-action=promote restore


Observação importante - o PostgreSQL só pode reproduzir logs do WAL para a frente, não para trás. O que isso significa na prática?



Digamos que um backup foi criado às 16:00. Às 18h05 apagamos acidentalmente a tabela, e às 18h10 um backup foi criado novamente com a tabela já apagada. Quando você tenta fazer um PITR, pgBackRest pegará o backup que foi criado às 16:00 e fará o rollover de tudo o que era antes das 18:05, e não fará o backup que foi criado às 18:10 e irá reverter tudo. É importante entender isso. Este mecanismo é descrito com mais detalhes aqui .



Suponha que você tenha feito um backup, que já contém informações sobre como excluir uma tabela. Usando o sinalizador --set, digamos qual backup deve ser usado para a base (aquele em que a tabela ainda estava). pgBackRest fará esse backup e fará o rollover de tudo o que estava antes de a tabela ser excluída.



sudo -u postgres pgbackrest --stanza=main --log-level-console=info --delta --type=time --set=20200905-183838F_20200906-182612I "--target=2020-09-06 18:27:24.561458+02" --target-action=promote restore


PS Mostrei o comando para obter a lista de backups acima.



Vamos iniciar o cluster. Depois de começar, vamos examinar o arquivo /var/log/postgresql/postgresql-11-main.log. Nele, estamos interessados ​​nas seguintes linhas, mostrando que a recuperação para o ponto especificado no tempo foi bem-sucedida:



starting point-in-time recovery to 2020-09-07 11:26:52.493127+02
...
recovery stopping before commit of transaction 576, time 2020-09-07 11:27:14.584496+02
...
last completed transaction was at log time 2020-09-07 11:24:09.583761+02


Isso é tudo. Aconselho vivamente que experimente esta ferramenta antes de a utilizar em combate.



All Articles