Tive perda de dados sem backup
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.
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.
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.
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Cópias locais nas máquinas dos usuários. Pasta de Downloads, arquivos abertos recentemente, cópias salvas localmente para trabalho offline.
- 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.
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.
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.
- 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