Backup automatizado para salão de cabeleireiro Perdizes: proteção de dados

Seu salão em Perdizes perdeu todos os agendamentos da semana porque o disco do servidor falhou na terça-feira de manhã? Essa é a pergunta que nenhum dono de salão de beleza feminino em São Paulo quer responder na prática. Dados de clientes, histórico de serviços, preferências de cor, alergias a produtos e a agenda lotada de sexta-feira — tudo vive no banco de dados MySQL. Quando o hardware falha, o ransomware criptografa arquivos ou um comando DELETE sem WHERE é executado por acidente, o relógio começa a correr. Sem backup automatizado testado, a recuperação vira improvisação cara e estressante.

A boa notícia: backup não é mistério, é engenharia. MySQL oferece ferramentas nativas (mysqldump, mysqlpump, binary logs, réplicas) e o ecossistema traz soluções maduras como Percona XtraBackup para cópias físicas quentes sem travar tabelas. O segredo não é escolher a ferramenta mais cara, mas desenhar uma estratégia que cubra RPO (quanto de dado você aceita perder) e RTO (em quanto tempo precisa voltar online) compatíveis com a realidade de um salão que não pode fechar as portas.

Por que salões de beleza em Perdizes precisam de estratégia de backup específica

Diferente de um e-commerce que vende 24/7, um salão de cabeleireiro em Perdizes tem picos previsíveis: manhãs de sábado, vésperas de feriado, dezembro inteiro. O banco de dados cresce em rajadas — novos clientes, pacotes de fidelidade, fotos de antes/depois salvas como BLOBs. Um backup único à noite deixa uma janela de 14 a 16 horas onde cada agendamento confirmado pelo WhatsApp Business, cada venda de produto no PDV e cada anotação da colorista ficam vulneráveis. Perder a agenda de um sábado cheio significa receita perdida, clientes insatisfeitos e reputação abalada no bairro.

Além do volume, há a sensibilidade: dados pessoais (nome, telefone, e-mail), dados de saúde (alergias, tratamentos capilares) e financeiros (cartão tokenizado, histórico de pagamentos) enquadram-se na LGPD. Vazamento ou perda irreversível desses dados aciona obrigações de notificação à ANPD e aos titulares. Backup automatizado, criptografado e auditável deixa de ser “TI” e vira conformidade legal.

Arquitetura de backup em camadas: regra 3-2-1 aplicada ao MySQL

A regra 3-2-1 continua imbatível: 3 cópias dos dados, em 2 mídias diferentes, com 1 fora do site. No contexto MySQL de um salão, isso se traduz em:

1. Cópia primária: backup físico comprimido (Percona XtraBackup) no storage local do servidor — restauração mais rápida (minutos).
2. Cópia secundária: backup lógico (mysqlpump com --parallel) enviado via rsync sobre SSH para NAS na mesma rede, mas rack diferente — protege contra falha de disco do servidor.
3. Cópia terciária (off-site): upload automatizado para bucket S3-compatível (AWS S3, Wasabi, Backblaze B2) com versionamento e Object Lock (WORM) — protege contra incêndio, enchente, ransomware que criptografa rede local.

#!/bin/bash
set -euo pipefail
DATE=$(date +%F_%H-%M)
BACKUP_DIR="/backup/mysql"
S3_BUCKET="s3://salao-perdizes-backups/mysql"

xtrabackup --backup --target-dir="${BACKUP_DIR}/full_${DATE}" \
  --compress --compress-threads=4 --encrypt=AES256 \
  --encrypt-key-file=/etc/mysql/backup_key.txt

xtrabackup --prepare --target-dir="${BACKUP_DIR}/full_${DATE}"

rsync -avz --delete "${BACKUP_DIR}/full_${DATE}/" \
  backup-nas::mysql/full_${DATE}/

aws s3 sync "${BACKUP_DIR}/full_${DATE}/" "${S3_BUCKET}/full_${DATE}/" \
  --storage-class STANDARD_IA --sse AES256

find "${BACKUP_DIR}" -type d -mtime +7 -name 'full_*' -exec rm -rf {} +

O script acima roda em 12 a 18 minutos para banco de 8–12 GB típico de salão médio. Binary logs (binlog) com expire_logs_days=2 garantem recuperação point-in-time entre backups completos — se o disco falhar às 14h30, você restaura o full das 03h00 e aplica binlogs até 14h29.

Automação e validação: o backup que ninguém testa não existe

Agendar cron é o começo; validar é o fim. Muitos salões descobrem backup corrompido só na hora do desastre. A validação deve ser automatizada, frequente e mensurável:

• Semanal: job que restaura o último backup completo em instância staging (container Docker efêmero), roda CHECKSUM TABLE nas tabelas críticas (agendamentos, clientes, servicos, vendas) e compara contagem de registros com produção.
• Mensal: simulado de recuperação point-in-time aleatório (ex: “restaurar estado de 15 dias atrás às 10h15”) com cronômetro — mede RTO real.
• Alertas: falha de backup, tempo de execução > 2× média, espaço em disco < 20% livre no destino — tudo no mesmo painel que monitora slow_queries e replication_lag.

Como geradores de backup asseguram a performance de bancos de dados críticos explica como separar I/O de backup da carga transacional usando réplica dedicada — essencial se seu salão usa o mesmo servidor para site, PDV e agendamento online.

LGPD, criptografia e gestão de chaves: não complique, padronize

Criptografar o arquivo .xbstream.xbcrypt do XtraBackup é trivial; o difícil é gerenciar a chave sem criar ponto único de falha. Evite:

• Chave hardcoded no script (vaza no Git, no histórico do shell).
• Chave no mesmo servidor do banco (se o servidor some, a chave some junto).
• Chave guardada só na cabeça do dono (bus factor = 1).

Use cofre de segredos (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, ou até pass/gopass para times pequenos). O script lê a chave em runtime via API autenticada com token de curta duração. Roteção de chaves a cada 90 dias com re-criptografia dos backups antigos (ou marque-os como “chave legada” e mantenha acesso à chave antiga no cofre).

Tabela de responsabilidades sugerida:

Boas práticas em arquitetura de banco de dados para otimizar sistemas MySQL detalha como particionar tabelas grandes (agendamentos por mês, vendas por trimestre) para acelerar tanto backup quanto restore seletivo.

Recuperação point-in-time: o seguro contra erro humano

O cenário mais comum não é disco queimado — é UPDATE clientes SET telefone = '' WHERE id > 0 executado por estagiário às 16h22. Com binlog_format=ROW e log_slave_updates=ON na réplica, você tem duas opções:

1. Flashback via binlog: mysqlbinlog --start-datetime="2024-11-15 16:20:00" --stop-datetime="2024-11-15 16:23:00" binlog.000123 | mysql -u root -p — reverte só a transação problemática.
2. Restauração seletiva: restaura backup full das 03h00 em staging, aplica binlogs até 16h21, exporta tabela clientes (mysqldump --single-transaction --where="id > 0"), importa em produção.

Ambas exigem que você saiba o horário exato do erro. Por isso, log de auditoria de aplicação (quem fez o quê, quando) é tão vital quanto o binlog. Integre com pgaudit/MariaDB Audit Plugin ou camada de aplicação.

Monitoramento que avisa antes do cliente ligar reclamando

Backup silencioso que falha há 3 semanas é pior que nenhum backup — dá falsa segurança. Métricas mínimas no seu dashboard:

• mysql_backup_last_success_timestamp (gauge, segundos desde epoch) — alerta se > 30 horas.
• mysql_backup_duration_seconds (histogram) — alerta se p95 > 2× média móvel 7 dias.
• mysql_backup_size_bytes — crescimento súbito indica tabela nova sem particionamento ou BLOBs não previstos.
• mysql_binlog_lag_seconds (se usa réplica para backup) — alerta se > 300s.
• disk_free_percent no destino de backup — alerta < 15%.

Diagnóstico slow queries MySQL mostra como correlacionar picos de I/O de backup com queries lentas no horário comercial — ajuste innodb_io_capacity e innodb_max_dirty_pages_pct para suavizar.

Plano de continuidade: do backup ao salão funcionando

Backup é meio; fim é continuidade do negócio. Documente um runbook de 1 página plastificado na recepção:

1. Detecção: erro de conexão, site fora, PDV não abre — quem aciona? (Gerente + DBA plantão).
2. Diagnóstico rápido: systemctl status mysql, df -h, tail -f /var/log/mysql/error.log — 5 min.
3. Decisão: restaurar no mesmo hardware (se só banco corrompeu) ou subir container em cloud (se servidor físico morreu) — RTO alvo: 45 min.
4. Restauração: script testado mês passado, um comando (./restore_latest.sh --target=prod).
5. Validação: login no sistema, checar agenda de hoje, fazer agendamento teste, confirmar PDV.
6. Comunicação: aviso no WhatsApp Business “Sistema instável 14h–14h45, agendamentos confirmados manualmente”.
7. Pós-incidente: root cause analysis em 48h, atualizar runbook.

Centros automotivos precisam de consultoria para gerenciar dados de clientes traz lições de outro setor com agendamento recorrente e dados sensíveis — a estrutura do runbook é surpreendentemente parecida.

Um salão em Perdizes que atende cabelo curto feminino em Pinheiros e região não pode tratar backup como item de “quando sobrar tempo”. A agenda de sexta-feira não espera. Implemente a camada física + lógica + nuvem, valide semanalmente, documente o restore e durma tranquilo sabendo que, se o disco falhar amanhã de manhã, seu time sabe exatamente o que fazer — e em quanto tempo.

Backup automatizado não é custo de TI; é apólice de continuidade escrita em código testado. Comece hoje com o script acima, adapte ao seu volume, agende a primeira validação para sexta que vem. Seu futuro eu (e suas clientes) agradecem.

Checklist prático

Perguntas frequentes