Tive perda de dados sem backup

Backup não funcionou, foi corrompido ou nunca existiu — avaliação do que pode ser recuperado, comunicação ao negócio e plano emergencial de recuperação.

Resposta rápida

Perda de dados sem backup viável é uma das piores situações de TI, mas tem caminho. Em ordem: pare imediatamente qualquer escrita no ambiente afetado, para não sobrescrever o que ainda pode ser recuperado. Esgote tentativas técnicas de recuperação — backup secundário esquecido, replicação, snapshot, log de transação, recuperação forense via empresa especializada (vale a tentativa mesmo com custo alto se o dado for crítico). Em paralelo, comunique o negócio com honestidade total: o que se perdeu, o que se está tentando, qual o cenário pior caso. Comece imediatamente a reconstrução paliativa: o que pode ser refeito manualmente, o que pode ser recuperado de cópias parciais (e-mails, planilhas locais, outros sistemas), o que terá que ser declarado perda. E reestruture o processo de backup como prioridade imediata — para que o próximo incidente tenha resposta diferente.

Pequena até 50 colaboradores

Na empresa pequena, a perda costuma vir da combinação clássica: backup nunca foi testado, ou era feito num HD externo que falhou, ou estava na mesma máquina que pifou. Antes de declarar perda, esgote o óbvio: e-mails antigos podem ter anexos importantes; arquivos locais nas máquinas de quem usava aquele sistema; backup do fornecedor de SaaS (alguns guardam 30 ou 90 dias sem o cliente saber); cópia em pen drive ou OneDrive pessoal de algum colaborador. Vale considerar empresa especializada em recuperação de dados se o disco está físico e o dado é crítico — custa, mas a chance existe. Comunique o dono e os clientes afetados rápido e em tom honesto. E contrate solução de backup gerenciado imediatamente — não dá para sair dessa crise sem ter resolvido o que a causou.

Média 51–500 colaboradores

Na empresa média, a perda costuma revelar o que se desconfiava: o backup formal existia mas não foi testado, ou estava configurado num escopo menor do que se imaginava, ou foi corrompido sem alerta. Mobilize o time interno em uma frente de tentativa técnica (backup secundário, replicação, snapshot de storage, log de banco) e outra de comunicação ao negócio. Se houve exposição de dados pessoais junto com a perda — incidente misto não é incomum —, jurídico precisa estar na sala desde o primeiro dia. Para a comunicação à diretoria, leve cenários (pessimista, realista, otimista) e o plano de reconstrução paliativa em paralelo às tentativas. Depois da crise estabilizada, faça RCA e reforme o processo de backup com testes regulares — promessa de "nunca mais" sem mudança estrutural é frágil.

Grande +500 colaboradores

Na empresa grande, perda total sem qualquer backup costuma ser raríssima — o mais comum é perda parcial em sistema específico onde o processo de backup falhou ou onde havia gap entre backups. Acione imediatamente o time de infraestrutura, o fornecedor de storage e o time de banco de dados; em paralelo, comunicação corporativa e jurídico precisam estar acionados pela escala dos dados envolvidos. Para sistemas com regulamentação (financeiro, saúde, dados pessoais em escala), há obrigações específicas de comunicação que correm em prazos curtos. Trate como incidente formal com incident commander, RCA pós-evento mandatório e plano de remediação aprovado em comitê executivo. A reforma do processo de backup costuma envolver revisão de arquitetura inteira — não basta apertar parafusos.

Você está vivendo isso se…
  • Arquivos críticos sumiram e a primeira tentativa de restaurar falhou
  • O backup mais recente está corrompido, vazio ou desatualizado em meses
  • O backup era manual e há tempos ninguém executava
  • O sistema crítico não tinha backup configurado, ninguém percebeu
  • O dispositivo que guardava o backup também foi afetado pelo incidente
  • O fornecedor disse que não tem cópia recuperável

Parar o sangramento antes de tudo

A primeira ação, antes mesmo de tentar recuperar, é interromper qualquer escrita no ambiente onde os dados estavam. Cada gravação nova pode sobrescrever blocos de disco onde o dado perdido ainda existe fisicamente. Em caso de falha de disco, isole o equipamento. Em caso de exclusão acidental, paralise o sistema. Em caso de corrupção, congele o processo que estava causando o problema. Isso preserva a chance — pequena, mas real — de recuperação por empresa especializada.

Esgote as tentativas de recuperação antes de declarar perda

Antes de aceitar que o dado se perdeu, vá metodicamente por todas as possibilidades. Mesmo quando "não tinha backup", costuma haver cópias parciais em lugares improváveis.

Onde procurar antes de declarar perda
  1. Backup secundário esquecido. Cópia antiga em HD externo, backup do estagiário, cópia que o ex-funcionário deixou. Pergunte a todos que poderiam ter tocado o sistema.
  2. Backup do fornecedor de SaaS. Muitas plataformas guardam backup interno por 30, 60 ou 90 dias sem o cliente saber. Abra ticket pedindo restauração mesmo se não estiver contratada — vale tentar.
  3. Snapshot de storage ou replicação. Em ambientes mais maduros, pode haver snapshot do storage ou replicação assíncrona que sobreviveu ao evento. Confirme com o fornecedor de infra.
  4. Log de transações do banco de dados. Se a perda foi no banco, log de transações pode permitir replay até um ponto anterior, dependendo de quanto tempo de log existe.
  5. E-mails e anexos antigos. Relatórios exportados, planilhas anexadas em mensagens, comprovantes — buscas amplas em caixas de e-mail costumam revelar cópia parcial do que se perdeu.
  6. Cópias locais nas máquinas dos usuários. Pasta de Downloads, arquivos abertos recentemente, cópias salvas localmente para trabalho offline.
  7. Recuperação forense via empresa especializada. Para dado crítico em disco físico danificado ou apagado recentemente, vale a tentativa mesmo com custo alto. A chance existe.
Atenção comum: a recuperação forense profissional precisa do disco no estado em que ficou após o incidente. Tentativas amadoras de recuperação (rodar utilitário gratuito, formatar e reinstalar para "ver se volta") podem destruir a chance que ainda existia. Se o dado é crítico, isole o disco e procure especialista antes de qualquer tentativa caseira.

Comunicar o negócio com honestidade

O reflexo de adiar a comunicação esperando "ver se recupera" é o caminho mais rápido para perder a confiança da diretoria. Comunique no momento em que a situação for confirmada, mesmo que ainda haja tentativa em curso. Estrutura útil para a comunicação: o que aconteceu (descrição factual sem floreio), o que se perdeu até agora (escopo identificado), o que se está tentando (frentes de recuperação ativas), cenário realista (o que provavelmente se recupera vs o que provavelmente não), próximos passos imediatos, próxima atualização em quanto tempo. Não invente prazos otimistas; honestidade sobre o que ainda não se sabe constrói credibilidade.

O plano paliativo enquanto se tenta recuperar

Em paralelo às tentativas técnicas, comece imediatamente a reconstrução paliativa: o que pode ser refeito manualmente a partir de informação que existe em outros lugares (e-mail, papel, memória), o que pode ser reconstituído a partir de cópias parciais, o que vai ter que ser declarado perda. Distribua tarefas: cada área afetada precisa mapear o que perdeu e o que dá para reconstruir, com prazo. Esse trabalho costuma ser maior do que parece — meses de dados não voltam em uma semana.

Depois da crise: por que o backup falhou

Quando a crise estabilizar, é mandatório entender por que o backup falhou (ou nunca existiu). As causas mais comuns: backup configurado mas nunca testado, backup com escopo menor do que se imaginava, backup no mesmo ambiente que foi atingido (HD externo no mesmo prédio, backup em nuvem com mesma credencial comprometida), processo manual que dependia de uma pessoa, alerta de falha desabilitado ou ignorado. A reforma estrutural costuma envolver: backup gerenciado por terceiro com SLA, teste de restauração mensal, isolamento real (3-2-1 — três cópias, dois meios, uma offsite), monitoramento ativo com alerta.

Armadilhas comuns na crise de perda de dados

Adiar comunicação esperando "ver se recupera". Quando a diretoria descobre por terceiros que perdemos dados, o problema técnico vira crise de credibilidade. Comunique no momento em que a situação for confirmada.

Tentativas amadoras de recuperação em disco físico. Rodar utilitário, formatar, reinstalar pode destruir o que ainda era recuperável por especialista. Isole o disco e consulte profissional antes de qualquer tentativa caseira.

Continuar escrevendo no ambiente afetado. Cada gravação pode sobrescrever blocos onde o dado perdido ainda existia fisicamente. Pare a escrita antes de qualquer outra ação.

Não procurar cópias parciais. Antes de declarar perda total, esgote sistematicamente: backup do SaaS, snapshot, log, e-mails, cópias locais, HD externo esquecido. O óbvio às vezes está lá.

Prometer "isso nunca mais vai acontecer" sem mudança estrutural. Sem reforma do processo de backup, a próxima crise é só questão de tempo. Tratar o pós como reforma de arquitetura, não como aperto de parafuso.

Antes de declarar perda definitiva, confira:
  • Toda escrita no ambiente afetado foi interrompida
  • Backup secundário, snapshot e replicação foram verificados
  • Fornecedor de SaaS foi consultado sobre backup interno
  • Log de transações de banco foi avaliado
  • E-mails, anexos e cópias locais foram pesquisados
  • Empresa especializada em recuperação foi consultada se aplicável
  • Comunicação ao negócio aconteceu antes de a diretoria descobrir por terceiros

O que fazer quando perdi dados e o backup não funciona?

Pare imediatamente qualquer escrita no ambiente afetado, para preservar a chance de recuperação. Esgote tentativas técnicas: backup secundário esquecido, backup interno do fornecedor de SaaS, snapshot de storage, log de banco, cópias locais, recuperação forense profissional para dado crítico. Em paralelo, comunique o negócio com honestidade e comece a reconstrução paliativa do que pode ser refeito. Só declare perda definitiva depois de esgotar metodicamente todas as possibilidades.

Vale tentar empresa especializada em recuperação de dados?

Sim, quando o dado é crítico e o custo da perda supera o custo do serviço. Empresas especializadas conseguem recuperar dados de discos com falha física, partições corrompidas e até de eventos como apagamento recente, dependendo do estado do dispositivo. A chance existe mas não é garantida. Importante: isole o disco no estado em que ficou após o incidente e não tente recuperações caseiras antes — utilitários gratuitos e reinstalação podem destruir o que ainda era recuperável por especialista.

Como comunicar a diretoria que perdemos dados?

No momento em que a situação for confirmada, mesmo com tentativa em curso. Estrutura: o que aconteceu, o que se perdeu até agora, o que está sendo tentado, cenário realista (o que provavelmente se recupera vs o que provavelmente não), próximos passos, próxima atualização em quanto tempo. Não invente prazos otimistas para acalmar — quando a diretoria descobrir por terceiros, o problema técnico vira crise de credibilidade. Honestidade sobre o que ainda não se sabe constrói confiança.

Perda de dados sem backup viola a LGPD?

Pode violar, dependendo do que se perdeu. A LGPD obriga proteger dados pessoais — perda por falha de segurança e disponibilidade configura incidente que pode exigir comunicação à ANPD e aos titulares quando houver risco. Se a perda envolve dados pessoais e havia obrigação de mantê-los disponíveis (contratual, regulatória, do próprio titular), há exposição. Acione o jurídico ou DPO desde o primeiro momento para avaliar obrigações de comunicação e mitigar consequências.

Como evitar que isso aconteça de novo?

Tratar o pós-crise como reforma estrutural, não como aperto de parafuso. Os pilares são: regra 3-2-1 (três cópias dos dados, em dois meios diferentes, sendo uma offsite e idealmente offline ou imutável), backup gerenciado com SLA e monitoramento ativo, teste de restauração regular (mensal idealmente, trimestral no mínimo), isolamento real entre produção e backup, alerta automático de falha de backup. Promessa de "nunca mais" sem mudar arquitetura é frágil.