O que fazer se…

O backup desta noite falhou

Um backup que falhou em uma noite não é um desastre, é um atraso: a última cópia íntegra tem pelo menos 48 horas se a da noite anterior foi bem-sucedida. Várias falhas seguidas são um incidente de proteção: a causa deve ser investigada no mesmo dia, sem se limitar a reconhecer o alerta.

Atualizado em outubro de 20263 min de leitura5 fontes citadas

O essencial

Leia a mensagem de erro, e não apenas o indicador vermelho: espaço, fonte ausente, credenciais, arquivos bloqueados, largura de banda, agente parado.
Um job “bem-sucedido” pode ter copiado uma pasta vazia: verifique o tamanho copiado.
Anote a data do último backup bem-sucedido e informe-a ao responsável pela área afetada.
Execute novamente após a correção e verifique a noite seguinte.
Três falhas em um mês na mesma máquina: mude a configuração, e não apenas o botão “executar novamente”.

1. Ler o erro, e não apenas o indicador vermelho

As causas mais comuns, na ordem em que costumam aparecer:

Causa	Sinal	Correção
Sem espaço no destino, ou cota atingida	Erro de gravação, retenção que diminui	Aumentar o volume ou reduzir o histórico de forma consciente
Fonte desligada, fora da rede, caminho alterado	Letra de unidade ou compartilhamento renomeado; job “bem-sucedido” em uma pasta vazia	Restabelecer a fonte, corrigir o caminho, verificar o tamanho copiado
Credenciais recusadas	Senha de conta de serviço expirada	Restabelecer a conta: caso contrário, todas as noites falharão
Arquivos bloqueados ou banco de dados não colocado em estado consistente	Cópia parcial	Usar o método previsto para bancos de dados abertos; um banco SQL nesse estado não pode ser restaurado corretamente
Conexão lenta demais ou interrompida	Job interrompido no fim da janela	Backup incremental mais eficiente, janela mais longa ou menos dados desnecessários
Agente parado na máquina	Nenhum envio	Reiniciar o serviço e investigar por que ele parou

O caso mais enganoso é o job verde em uma pasta vazia. A ANSSI, agência nacional francesa de segurança cibernética, exige que o backup seja sistematicamente controlado, monitorando especialmente volumes de dados ou de arquivos incoerentes, lentidões de rede e alterações de configuração. Um tamanho copiado que cai bruscamente de uma noite para outra merece tanta atenção quanto uma falha.

2. Saber de quando é o último backup bem-sucedido

É a única data que importa para o RPO do dia. Se ela tiver mais de alguns dias, informe a pessoa responsável pela área afetada. Ela está trabalhando sem rede de segurança e precisa saber disso. Reconhecer o alerta no console sem essa comunicação é o gesto que transforma um incidente em perda de dados duas semanas depois.

3. Executar novamente após a correção

Execute um job manual depois que a causa for tratada. Aguarde a conclusão. Se essa nova execução falhar, a causa ainda está presente. Na manhã seguinte, verifique a noite seguinte: muitas correções “óbvias” não resistem à segunda execução.

Um job bem-sucedido prova que uma cópia foi gravada, não que ela pode ser restaurada. Para um banco de dados SQL Server, a Microsoft esclarece que o comando de verificação de um backup não controla a estrutura dos dados que ele contém. A ANSSI exige que os backups sejam testados regularmente, com um procedimento de restauração por escrito; o NIST também recomenda testar os backups para garantir que os arquivos possam ser recuperados sem erros. Depois de um incidente de backup, uma restauração de teste de um arquivo ou de um banco de dados é a melhor verificação. Veja Como testar se um backup funciona?.

4. Se isso se repetir

Três falhas em um mês na mesma máquina: o escopo, a largura de banda ou o produto não são adequados. Altere um parâmetro (excluir uma pasta enorme e inútil, dividir o job, aumentar o armazenamento), em vez de simplesmente executar novamente à mão toda segunda-feira.

Checklist da manhã

Todos os jobs da noite foram concluídos, e não apenas “sem erro”?
O tamanho copiado é coerente com o das noites anteriores?
A data do último backup bem-sucedido de cada máquina crítica tem menos de 24 horas?
Os alertas foram lidos por uma pessoa designada, e não apenas recebidos?
O espaço restante no destino cobre a retenção prevista?

Na WeDoBack

O monitoramento 24 horas por dia abrange os backups e envia um alerta quando um backup não é concluído. O alerta é o início desta página, não o fim. Na INTEGRAL, duas horas de suporte por mês podem ser usadas para tratar a causa. Na SMART, o suporte é cobrado por atendimento: a falha fica visível para o cliente no console, e cabe a ele acompanhá-la. O suporte atende pelo +33 9 72 50 78 28, das 9h às 13h e das 14h às 17h30 (horário de Paris). Para dimensionar o armazenamento, a referência publicada é o volume atual multiplicado por três, com um ajuste após uma semana de uso: um volume insuficiente se revela em jobs que falham ou em uma retenção que diminui. A chave de criptografia, mantida pelo cliente, não tem papel na falha de envio: se o job falhar, a cópia remota simplesmente não foi atualizada.

Ligar para +33 9 72 50 78 28 Conhecer a oferta INTEGRAL

Perguntas frequentes

Uma noite de falha é grave?

Raramente, se a noite anterior foi bem-sucedida e a causa for corrigida no mesmo dia. O risco vem do acúmulo: cada noite de falha aumenta a quantidade de trabalho que seria perdida em caso de sinistro. Além de alguns dias, é um incidente a ser comunicado à diretoria.

O status “bem-sucedido” basta para provar que um backup está bom?

Não. A ANSSI, agência nacional francesa de segurança cibernética, exige um controle sistemático dos backups, especialmente de volumes de dados incoerentes, e testes de restauração regulares. Para o SQL Server, a Microsoft esclarece que a verificação de um backup não controla a estrutura dos dados que ele contém: somente uma restauração real, seguida de uma verificação de consistência, comprova isso.

Quem deve monitorar os alertas de backup?

Uma pessoa designada, com um substituto para as férias. Um alerta que chega a uma caixa compartilhada que ninguém lê equivale à ausência de alerta. Defina também quem avisa a diretoria quando o último backup bem-sucedido ultrapassar um limite combinado com antecedência.

Para saber mais

Fontes

Documentos consultados em outubro de 2026.

Backup dos sistemas de informação – Os fundamentos (ANSSI-BP-100, v1.1, 27 de novembro de 2025, em francês) — ANSSI
Por que e como gerenciar bem os seus backups? (em francês) — Cybermalveillance.gouv.fr
RESTORE VERIFYONLY (Transact-SQL) — Microsoft Learn
SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
Ofertas e preços — WeDoBack

Precisa de ajuda agora?

Não restaure nada antes de identificar uma cópia íntegra. Podemos orientar você.

Ligar para +33 9 72 50 78 28 ou escreva para nós

Um incidente em andamento?

Nossas equipes ajudam você a identificar a cópia certa e a restaurar seus dados, de segunda a sexta-feira, das 9h às 13h e das 14h às 17h30 (horário de Paris).

Ligar para +33 9 72 50 78 28 Escrever para a equipe