Dump de produção no notebook: como depurar sem levar dado de cliente para casa

Para entender por que a tela de pedidos quebrava com um cliente específico, o desenvolvedor rodou mysqldump na base de produção e baixou 4 GB para o notebook. O bug era de layout: um nome de produto longo demais. O arquivo tinha nome, CPF, endereço e histórico de compra de 80 mil clientes. Duas semanas depois, o notebook foi furtado num café, sem criptografia de disco. A resposta curta: dado de produção não vai para máquina de desenvolvimento. Use massa sintética para o dia a dia e, quando precisar de volume ou de formato real, gere uma cópia mascarada no servidor, onde o dado já está, e só ela sai de lá.

Quando um caso real for mesmo indispensável, ele vem como recorte mínimo, com autorização, numa máquina com disco criptografado, e é apagado ao fim. A cópia é produção, mesmo fora do servidor.

Por que o dump completo é o atalho errado

O dump completo resolve a pergunta "como reproduzo isso?" com a resposta mais cara: copiar tudo. A maior parte dos bugs não depende de quem é o cliente, e sim do formato do dado: um texto longo, um acento, um valor nulo, uma data no limite. Esse formato dá para reproduzir sem a pessoa real.

O custo aparece depois. O arquivo vai para a pasta de downloads, entra no backup pessoal na nuvem, é anexado num chamado para outro colega, e ninguém lembra de apagar. Cada cópia é um lugar a mais onde um vazamento pode acontecer, e um lugar que não aparece em nenhum inventário da empresa. Para a LGPD, o tratamento continua sendo seu, esteja o dado no servidor ou no notebook de alguém. Isto não substitui a orientação de um profissional habilitado em proteção de dados.

Três caminhos, do mais seguro ao mais arriscado

1. Massa sintética para o dia a dia

Um script de seed que cria clientes, produtos e pedidos falsos cobre a maioria das necessidades. Inclua de propósito os casos que costumam quebrar: nome com 120 caracteres, acentos, apóstrofo, campo opcional vazio, pedido com 300 itens. Quando um bug novo aparecer em produção, a primeira ação é adicionar ao seed o formato que o causou.

2. Cópia mascarada gerada no servidor

Quando você precisa de volume real, como para testar uma consulta lenta, restaure o backup mais recente num banco separado no próprio servidor, aplique o mascaramento lá e exporte só o resultado. O dado verdadeiro nunca sai do ambiente controlado.

3. Recorte real, autorizado e temporário

Para um caso que só acontece com aquele cliente, prefira investigar no servidor, com acesso registrado. Se a cópia for inevitável, leve só as linhas envolvidas, com aprovação de quem responde pelo dado, e combine a data de exclusão.

Como gerar a cópia mascarada passo a passo

1. Crie um banco separado no servidor de backup ou de homologação, nunca no banco de produção.
2. Restaure nele o backup mais recente. Isso também testa o seu backup, como recomenda backup de MySQL que restaura.
3. Rode o script de mascaramento, que sobrescreve os campos pessoais e esvazia tabelas sensíveis.
4. Verifique com consultas que provem que nenhum dado real sobrou.
5. Exporte só o banco mascarado e apague-o do servidor se não for reaproveitar.

Os comandos

mysql -e "CREATE DATABASE loja_mascarada CHARACTER SET utf8mb4"
gunzip -c /backups/loja-2026-10-17.sql.gz | mysql loja_mascarada
mysql loja_mascarada < mascarar.sql
mysql loja_mascarada < verificar.sql
mysqldump --single-transaction --routines --triggers loja_mascarada | gzip > loja_mascarada.sql.gz
mysql -e "DROP DATABASE loja_mascarada"

As credenciais vêm de um arquivo de opções do MySQL com permissão restrita, não da linha de comando, para não aparecerem no histórico do shell nem na lista de processos.

O script de mascaramento

-- mascarar.sql
UPDATE clientes SET
  nome     = CONCAT('Cliente ', id),
  email    = CONCAT('cliente', id, '@exemplo.invalid'),
  cpf      = LPAD(id, 11, '0'),
  telefone = NULL,
  endereco = CONCAT('Rua Exemplo, ', id),
  nascimento = NULL;

UPDATE pedidos SET observacao = NULL WHERE observacao IS NOT NULL;

TRUNCATE TABLE sessoes;
TRUNCATE TABLE redefinicoes_senha;
TRUNCATE TABLE logs_acesso;

UPDATE usuarios SET
  email = CONCAT('usuario', id, '@exemplo.invalid'),
  senha_hash = NULL;

-- verificar.sql
SELECT COUNT(*) AS emails_reais FROM clientes WHERE email NOT LIKE '%@exemplo.invalid';
SELECT COUNT(*) AS telefones FROM clientes WHERE telefone IS NOT NULL;
SELECT COUNT(*) AS sessoes FROM sessoes;

Todas as contagens precisam dar zero. Os hashes de senha somem junto (o exemplo assume a coluna aceitando nulo); quem precisa entrar no ambiente local define a própria senha pelo script de seed. O domínio .invalid é reservado para uso que nunca resolve, então um e-mail disparado por engano do ambiente de desenvolvimento não chega a ninguém. O CPF gerado pelo LPAD tem 11 dígitos e não é um documento válido, o que basta para testar layout e máscara de exibição.

O ponto fraco desse método é o campo que ninguém lembrou: a coluna observacao onde o atendente escreveu o telefone, o JSON com o endereço de entrega, o anexo com nome de arquivo. Antes de liberar o script, liste todas as colunas de texto do banco e decida, uma por uma, se ficam, mudam ou somem.

Regras para o notebook

Disco criptografado em toda máquina que toca código do sistema: BitLocker no Windows, FileVault no macOS, LUKS no Linux. Arquivos .sql e .sql.gz no .gitignore. Nenhum dump em chamado, chat ou e-mail; se o colega precisa, ele gera a própria cópia mascarada. E se um dump real já foi parar num repositório, trate como vazamento, como explica segredo no Git se troca antes de limpar.

Erros comuns

• Baixar a base inteira para um bug de layout. Você assume o risco de 80 mil pessoas para reproduzir o problema de uma linha.
• Mascarar no notebook, depois do download. O dado real já saiu; mascarar ali só reduz o risco daqui para frente.
• Esquecer colunas de texto livre e JSON. O nome some do campo nome e continua na observacao.
• Manter e-mails reais em homologação. Um teste de campanha dispara mensagem para clientes de verdade.
• Anexar dump em chamado. O sistema de chamados vira um repositório de dados pessoais sem controle de acesso adequado.
• Não marcar data para apagar o recorte real. O "só para esse caso" continua no disco um ano depois.

Checklist

• O seed sintético cobre os formatos que já causaram bug.
• A cópia mascarada é gerada no servidor, a partir do backup.
• Um script de verificação prova que não sobrou e-mail, telefone ou sessão real.
• Todas as colunas de texto e JSON foram revisadas no script de mascaramento.
• Toda máquina de desenvolvimento tem disco criptografado.
• Arquivos de dump estão no .gitignore e fora de chamados e chats.
• Recortes reais têm aprovação registrada e data de exclusão.

Procure agora na sua máquina e nas dos colegas: o último dump que saiu do servidor de produção ainda está em alguma pasta de downloads?