Backup, restore e PITR com Percona XtraBackup

Backup físico com Percona XtraBackup: instalação da versão compatível do XtraBackup, usuário de backup com auth_socket, script de backup full + incremental com compressão/criptografia, agendamento com systemd timer ou cron, cópia de binlogs e ensaio de restore. Os cartões de cenário cobrem restore completo, restore a partir de uma cadeia incremental, recuperação para um ponto no tempo (PITR), restore de uma única tabela, criação de replica a partir de backup e restore em outro servidor. Use este guia para o backup diário de bancos grandes e para recuperação de desastres; para migração, dump de um único schema/tabela ou mudança entre versões, use o guia de backup lógico (mysqldump / MySQL Shell).

Topologia: 1 servidor (standalone, source, replica ou secondary de InnoDB Cluster); área de backup em disco local ou NFS

Cenários

• Configurar o backup, agendar e testar o restore (fluxo completo) — Instalação do XtraBackup, usuário de backup, script de backup full + incremental, agendamento e um ensaio de restore (incluindo PITR). Escolha esta opção se estiver configurando pela primeira vez. O backup é feito com o servidor no ar; sem downtime, apenas aumenta a carga de disco/CPU.
• Restore completo: voltar ao último backup full — O diretório de dados foi perdido/corrompido ou o servidor não inicia; basta voltar ao backup full da cadeia. O MySQL fica parado durante todo o restore.
• Restore com a cadeia full + incremental (até o último incremental) — Você quer voltar ao momento do último backup incremental (ou de um incremental escolhido); os incrementais são aplicados em ordem sobre o full com --apply-log-only. O MySQL fica parado durante todo o restore.
• Recuperar para um ponto no tempo (PITR): antes de um DELETE / DROP errado — Dados apagados ou corrompidos por engano: o último backup é restaurado e os binlogs são aplicados até imediatamente antes da transação com erro (por horário, posição ou GTID). O MySQL fica parado durante todo o restore e as gravações feitas depois do erro também são desfeitas; se apenas uma tabela foi afetada, avalie primeiro o cenário de tabela única.
• Restaurar uma única tabela (--export + IMPORT TABLESPACE) — Você precisa apenas da versão de uma tabela que está no backup; sem restaurar o servidor inteiro, a tabela é importada do backup com o nome t_restore e os dados são corrigidos a partir dela. O servidor continua no ar.
• Criar uma nova replica a partir de backup — Você quer preparar uma replica nova (ou a ser reconstruída) a partir de um backup XtraBackup existente, em vez de clonar pela rede, e conectá-la ao source (dados grandes, carga no source). O source não é afetado; os dados do servidor de destino são substituídos.
• Restaurar o backup em outro servidor (migração, teste, clone) — Você quer abrir um backup de produção em um servidor de teste/desenvolvimento, migrar um servidor ou verificar em um servidor separado que o backup realmente restaura. O servidor de origem não é afetado.

Antes de começar

• O MySQL … está rodando (se foi instalado com o guia Instalação do MySQL em servidor único do DBAtlas, os caminhos são os mesmos); o root do sistema operacional consegue conectar sem senha com o comando mysql (auth_socket ou ~/.mylogin.cnf).
• O diretório de backup … está em um disco/NFS separado e tem pelo menos (tamanho dos dados × número de cadeias) de espaço… (com zstd costuma ficar 3–6 vezes menor)…. O restore exige em … espaço livre de pelo menos 2 vezes o tamanho dos dados (descompressão + prepare).
• Binary log ativado e GTID habilitado (para PITR e consistência dos incrementais).
• O servidor consegue acessar repo.percona.com via HTTPS, ou há um mirror interno configurado.
• Há um local seguro fora do servidor (cofre, gerenciador de senhas) preparado para guardar uma cópia da chave de criptografia. Se a chave for perdida, os backups não podem ser abertos.
• De preferência há um servidor de teste separado para o teste de restore (instalado com a mesma versão do MySQL e o mesmo my.cnf). Os passos de restore substituem o diretório de dados do servidor em que são executados.
• Este servidor é uma replica saudável: as threads IO e SQL estão Yes, o atraso é baixo. Se os binlogs forem copiados (PITR), log_replica_updates deve estar ativo (ativo por padrão no 8.x); caso contrário, o binlog da replica não contém as transações que vêm do source.
• Este servidor é membro de um InnoDB Cluster e está no momento SECONDARY / ONLINE. O backup é agendado neste membro; se o membro virar primary no futuro, o script registra um aviso e faz o backup mesmo assim.
• A cadeia de backup a restaurar está em …… (no servidor …)… e completa: o full e os incrementais a usar, junto com os diretórios de metadados -lsn…; chave de criptografia em …….
• O MySQL … e o XtraBackup … estão instalados neste servidor; a versão secundária do MySQL é igual ou mais nova que a do servidor em que o backup foi feito (o valor server_version do backup aparece no passo de diagnóstico).
• …Não há dados a preservar no servidor de destino: o diretório de dados é substituído pelo backup (o antigo é movido para .old-<timestamp>).…A janela de manutenção e a indisponibilidade da aplicação foram aprovadas: o MySQL fica parado durante o restore; a aplicação não deve se conectar a este servidor.…
• A tabela é InnoDB e está em seu próprio arquivo .ibd com innodb_file_per_table = ON (padrão do 8.x); a estrutura da tabela (colunas, índices) não mudou desde que o backup foi feito. O servidor continua no ar.

Fases do guia

• Instalação do XtraBackup — Adicionar o repositório da Percona · Instalar o XtraBackup
• Usuário de backup e chave — Verificar o plugin auth_socket · Criar o usuário de backup · Testar a conexão · Criar a chave de criptografia
• Script de backup e agendamento — Criar o diretório de backup · Escrever o script de backup · Tornar o script executável · Fazer o primeiro backup full · Testar um backup incremental · Escrever o serviço systemd …
• Restore — Copiar a cadeia para o diretório de trabalho · Descriptografar / descompactar · Preparar o backup full (prepare, apply-log-only) · Aplicar os incrementais em ordem · Prepare final · Parar o MySQL e mover os dados existentes …
• Recuperação para um ponto no tempo (PITR) — Determinar o momento alvo · Aplicar os binlogs até o momento alvo · Verificar o resultado e fazer um novo backup
• Limpeza — Apagar os dados movidos e o diretório de trabalho
• 1. Diagnóstico: qual backup, qual método? — Verificar o estado do servidor e as versões · Listar as cadeias de backup e seu conteúdo
• 2. Rede de segurança — Registrar o estado atual e a configuração
• 3. Aplicação: preparar o backup — Copiar a cadeia para o diretório de trabalho · Copiar a cadeia para o diretório de trabalho · Descriptografar / descompactar · Preparar o backup full (prepare, apply-log-only) · Aplicar os incrementais em ordem · Prepare final
• 3. Aplicação: restaurar os dados — Parar o MySQL e mover os dados existentes · Copiar o backup para o diretório de dados (copy-back) · Iniciar o MySQL e verificar · Verificar a configuração de replicação restaurada do backup
• 3. Aplicação: aplicar os binlogs até o alvo (PITR) — Verificar a transação com erro e o ponto alvo · Aplicar os binlogs até o alvo
• 4. Verificação — Verificar que a transação com erro foi desfeita · Verificar os dados
• 5. Depois — Fazer um novo backup full · Apagar os dados movidos e o diretório de trabalho · Causa raiz e topologia
• 1. Diagnóstico: a tabela e o backup são adequados? — Mostrar o estado atual e a estrutura da tabela · Listar as cadeias de backup e seu conteúdo
• 2. Rede de segurança — Fazer backup do estado atual da tabela
• 3. Aplicação: preparar o backup com --export — Copiar a cadeia para o diretório de trabalho · Descriptografar / descompactar · Preparar o backup full (prepare, apply-log-only) · Aplicar os incrementais em ordem · Prepare final (--export)
• 3. Aplicação: importar a tabela para uma tabela intermediária — Criar a tabela intermediária e descartar seu tablespace · Copiar os arquivos do backup e importar (IMPORT TABLESPACE)
• 4. Verificação — Verificar a tabela intermediária e comparar com a tabela original
• 5. Depois: copiar os dados e limpar — Copiar as linhas necessárias para a tabela original · Remover a tabela intermediária e apagar o diretório de trabalho
• 1. Diagnóstico: o servidor de destino e o backup são adequados? — Verificar a versão, a identidade e o disco do servidor de destino · Listar as cadeias de backup e seu conteúdo (…)
• 2. Rede de segurança — Registrar o estado atual e a configuração
• 3. Aplicação: trazer e preparar o backup — Trazer a cadeia do servidor de backup · Copiar a cadeia para o diretório de trabalho · Descriptografar / descompactar · Preparar o backup full (prepare, apply-log-only) · Aplicar os incrementais em ordem · Prepare final
• 3. Aplicação: restaurar os dados — Parar o MySQL e mover os dados existentes · Copiar o backup para o diretório de dados (copy-back) · Iniciar o MySQL e verificar · Verificar a configuração de replicação restaurada do backup
• 3. Aplicação: iniciar a replicação a partir do ponto do backup — Determinar o ponto de partida · Configurar e iniciar a replicação
• 4. Verificação — Verificar os dados
• 5. Depois — Apagar os dados movidos e o diretório de trabalho · Colocar o servidor em operação no novo papel