Introdução
Na administração de sistemas, a perda de dados não é uma questão de "se", mas de "quando". Seja causada por falhas de hardware, bugs de software ou erros humanos, a perda de dados críticos pode ser catastrófica. Por isso, backup e recuperação estão entre as habilidades mais importantes para quem trabalha com bancos de dados.
Neste laboratório, você fará uma simulação completa de "Recuperação de desastres". Primeiro, você começará com um banco de dados íntegro, fará um backup seguro, excluirá o banco (simulando um desastre) e, em seguida, o recuperará usando o backup.
Você aprenderá a:
- Criar um backup lógico usando o utilitário
mysqldump. - Simular uma falha catastrófica excluindo um banco de dados.
- Restaurar o banco de dados ao estado original a partir do arquivo de backup.
Um backup lógico armazena instruções SQL capazes de recriar o esquema e os dados. Isso é diferente de um backup físico, que copia os arquivos brutos do banco de dados. As duas abordagens existem, mas os backups lógicos são mais fáceis de ler e entender para iniciantes.
Essa diferença é importante porque cada tipo de backup resolve problemas um pouco diferentes. Backups lógicos são portáteis e legíveis por humanos, enquanto backups físicos normalmente ficam mais próximos do mecanismo de armazenamento e dos recursos internos de recuperação.
Criar um backup
Primeiro, verifique se temos um banco de dados que vale a pena salvar. Um banco chamado app_db já foi preenchido com alguns dados de usuários.
Verifique os dados atuais:
sudo mysql -e "SELECT * FROM app_db.users;"
Você deverá ver uma lista de usuários (Alice, Bob, Charlie).
Agora, crie um backup lógico usando a ferramenta mysqldump. Um backup lógico basicamente exporta um arquivo de texto que contém todos os comandos SQL (como CREATE TABLE e INSERT) necessários para recriar o banco de dados do zero.
Portanto, o arquivo de backup não é um bloco binário misterioso. Normalmente, ele é um script SQL que pode ser executado posteriormente em um servidor de banco de dados para reconstruir o esquema e os dados.
Execute o comando a seguir para salvar o banco de dados em um arquivo chamado backup.sql:
sudo mysqldump app_db > ~/project/backup.sql
Entendendo o comando:
mysqldump: o utilitário usado para exportar o conteúdo do banco de dados.app_db: o banco de dados específico que queremos copiar.>: o operador de redirecionamento do Linux, que envia a saída do comando para um arquivo.~/project/backup.sql: o caminho do arquivo de destino.
Verifique se o arquivo de backup foi criado:
ls -l ~/project/backup.sql
Você também pode consultar o início do arquivo para ver os comandos SQL:
head -n 20 ~/project/backup.sql
Simular a perda de dados
Agora vem a parte assustadora. Para testar nosso plano de recuperação, precisamos de um desastre. Vamos simular a exclusão acidental do banco de dados de produção.
Aviso: o comando abaixo exclui os dados permanentemente. Em um ambiente de produção real, você nunca o executaria, a menos que tivesse certeza absoluta de que deseja destruir os dados.
Esta etapa destrutiva está incluída porque os backups só são realmente úteis quando você consegue provar que a recuperação funciona após uma perda real. Uma estratégia de backup que nunca foi testada é apenas uma suposição.
Exclua o banco de dados app_db usando DROP DATABASE:
sudo mysql -e "DROP DATABASE app_db;"
Confirme que o desastre ocorreu tentando acessar o banco de dados:
sudo mysql -e "USE app_db;"
Você deverá ver o erro ERROR 1049 (42000): Unknown database 'app_db'.
Isso confirma que o banco de dados desapareceu. Se este fosse um servidor de produção real sem backup, seria um dia muito ruim.
Restaurar o banco de dados
Felizmente, temos o arquivo backup.sql. Podemos usá-lo para restaurar os dados.
No entanto, por padrão, o mysqldump exporta apenas o conteúdo do banco de dados, e não o comando para criar o próprio banco. Como excluímos completamente o app_db, primeiro precisamos criar uma estrutura vazia para armazenar os dados.
Esse detalhe ajuda os iniciantes a entender exatamente o que foi capturado. Backups não são cópias instantâneas mágicas de tudo, a menos que o comando e as opções escolhidos incluam explicitamente essas partes.
Crie o banco de dados vazio:
sudo mysql -e "CREATE DATABASE app_db;"
Importe os dados do arquivo de backup:
sudo mysql app_db < ~/project/backup.sql
Entendendo o comando de restauração:
sudo mysql: conecta ao servidor de banco de dados.app_db: informa ao MySQL qual banco de dados deve ser usado como destino.<: o operador de redirecionamento de entrada do Linux. Ele lê o conteúdo do arquivo e o envia para o comandomysqlcomo se você estivesse digitando esse conteúdo.
Se o comando for executado sem mostrar nada, isso normalmente significa que ele foi concluído com sucesso!
O processo de restauração consiste essencialmente em enviar novamente as instruções SQL ao servidor. Em outras palavras, a recuperação geralmente é uma reexecução controlada das instruções armazenadas no backup lógico.
Verificar a recuperação dos dados
A etapa final e mais importante de qualquer plano de backup é a verificação. O fato de o comando de restauração não ter apresentado um erro não significa que os dados estejam corretos. Precisamos conferir.
Este é um dos hábitos operacionais mais importantes em qualquer trabalho com sistemas: sucesso não significa apenas "o comando terminou". Sucesso significa que "o estado do sistema está correto depois disso".
Consulte novamente a tabela users:
sudo mysql -e "SELECT * FROM app_db.users;"
Critérios de sucesso:
Você deverá ver os dados originais:
+----+---------+---------------------+
| id | name | email |
+----+---------+---------------------+
| 1 | Alice | alice@example.com |
| 2 | Bob | bob@example.com |
| 3 | Charlie | charlie@example.com |
+----+---------+---------------------+
Se você vir Alice, Bob e Charlie, terá recuperado o banco de dados com sucesso após o desastre!
Resumo
Neste laboratório, você concluiu com sucesso um ciclo completo de recuperação de desastres. Você aprendeu a:
- Fazer backup: exportar um banco de dados para um arquivo usando
mysqldump. - Destruir: simular um evento de perda de dados usando
DROP DATABASE. - Restaurar: importar um arquivo de dump SQL usando o redirecionamento de entrada
<. - Verificar: confirmar a integridade dos dados recuperados.
Backups regulares são sua principal defesa contra a perda de dados. Em um ambiente real, você deve automatizar esse processo e testar suas restaurações com frequência.
