Auditor de Controle Externo - Área de Informática - Administrador de Banco de Dados
O gerenciamento de backups no MySQL é uma prática essencial para garantir a segurança e a recuperação de dados em caso de falhas. Suponha que um banco de dados MySQL tenha sofrido uma falha grave que faz com que os dados devam ser restaurados até um ponto específico no tempo, evitando alterações feitas após esse ponto.Essa restauração
Apode ser feita usando o comando “mysqlbinlog” para aplicar os logs binários até o ponto específico no tempo desejado.
Bpode ser feita por meio do último backup completo criado antes do ponto desejado no tempo e dos logs de consultas gerais.
Cpode ser feita usando o comando "mysqldump" para recuperar as transações até o ponto específico.
Drequer a utilização de um backup diferencial seguido de backups incrementais, usando logs de erro.
Epode ser feita através de um backup lógico, atualizado manualmente.
Revelar gabarito e comentário▾
GabaritoA — pode ser feita usando o comando “mysqlbinlog” para aplicar os logs binários até o ponto específico no tempo desejado.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Recuperação Point-in-Time no MySQL
Gabarito: letra A. Para restaurar um banco MySQL a um ponto específico no tempo (Point-in-Time Recovery), utiliza-se o comando mysqlbinlog para aplicar os logs binários (binary logs) até o momento desejado. Esse procedimento é o padrão no MySQL e depende de backups completos anteriores combinados com a aplicação incremental dos logs binários. As demais alternativas trocam a ferramenta correta ou os logs necessários.
1Backup completo anterior
2Binary logs (binlog)
3mysqlbinlog até o ponto desejado
4Restauração das transações
LEVEL · soulevel.com.br
Alternativa A — ✅ Correta ⟵ GABARITO
Descreve exatamente o processo: "mysqlbinlog" aplica os registros do binlog até o ponto no tempo desejado, permitindo restaurar transações posteriores ao último backup completo. O binlog é essencial para recuperação incremental e PITR.
Alternativa B — ❌ Incorreta
Menciona "logs de consultas gerais" (general query log), que não são usados para recuperação de dados. A recuperação usa o binary log (binlog), não o general query log. O backup completo combinado com binlogs (não query logs) é a abordagem correta.
Alternativa C — ❌ Incorreta
O comando mysqldump cria backups lógicos (dumps), mas não permite restaurar até um ponto específico no tempo. Ele gera um snapshot do banco no momento da execução, não possibilita reproduzir transações posteriores. Para PITR, é necessário aplicar binlogs após o restore do dump.
Alternativa D — ❌ Incorreta
Afirma que é necessário backup diferencial e incremental usando logs de erro. Logs de erro registram problemas, não dados transacionais. A abordagem correta usa backups completos + binlogs (para incremento). Backup diferencial/incremental pode ser usado, mas com base em binlogs, não logs de erro.
Alternativa E — ❌ Incorreta
"Backup lógico atualizado manualmente" não é um método confiável nem automático para PITR. A recuperação deve ser baseada em logs binários e backups estruturados, não em atualizações manuais.
PEGA ESSA DICA!
Lembre-se: mysqlbinlog + binary logs = Point-in-Time Recovery. O mysqlbinlog é a ferramenta que lê os binlogs e gera comandos SQL para reexecutar transações. Combine com um backup completo prévio e você terá a restauração até qualquer ponto.