Quase todo provedor anuncia backup diário. Poucos explicam a retenção, o tempo de restauração e quem paga a conta se a recuperação falhar. O guia abaixo mostra o que perguntar antes de assinar.
Uma agência digital de Campinas descobriu, numa quinta-feira, que o banco de dados do principal cliente estava corrompido havia cinco dias. Ninguém tinha percebido: o site continuava no ar, só que gravando registros incompletos. O provedor de hospedagem oferecia backup diário, exatamente como prometido no site. O detalhe é que a retenção era de sete dias em rotação, e as cópias mais recentes já continham a corrupção. Restava uma cópia limpa. Ela expirava no dia seguinte.
Deu tempo. Por pouco.
“Backup diário” virou item de checklist comercial. Inclusive, aparece em plano de hospedagem compartilhada de R$ 30 por mês e em contrato corporativo de seis dígitos. A expressão é a mesma; o que ela entrega, porém, é completamente diferente.
Este artigo faz três coisas: primeiro, mostra o que cada tipo de provedor de hospedagem realmente oferece quando promete backups diários; em seguida, explica por que a frequência é a menos importante das variáveis; por fim, dá uma lista de perguntas que separa contrato bom de contrato bonito.
Quais provedores de hospedagem oferecem backups diários hoje
Praticamente todos os tipos de provedor oferecem alguma forma de backup diário: hospedagem compartilhada, VPS, servidor dedicado, nuvem pública e nuvem gerenciada. A diferença, no entanto, está em o que é copiado, por quanto tempo é guardado, se está incluso no preço e quem executa a restauração.
O panorama, por categoria:
| Tipo de provedor | Backup diário | Retenção típica | Quem restaura | Ponto de atenção |
|---|---|---|---|---|
| Hospedagem compartilhada | Geralmente incluso | 7 a 14 dias | Cliente, via painel | Cópia costuma ficar no mesmo servidor |
| VPS / servidor virtual | Incluso ou adicional | 7 a 30 dias | Cliente | Snapshot de disco, não backup de aplicação |
| Servidor dedicado | Quase sempre adicional | Configurável | Cliente ou provedor | Depende de contratar espaço extra |
| Nuvem pública (hyperscaler) | Recurso disponível, cobrado à parte | Definida pelo cliente | Cliente | Mesma conta = mesmo raio de exposição |
| Nuvem gerenciada / provedor dedicado | Incluso no serviço | Definida em contrato | Provedor, com SLA | Verificar se há teste de restauração |
Observe, sobretudo, a última coluna. É ela que concentra o risco real.
Em hospedagem compartilhada, o backup costuma ser gravado no mesmo servidor físico que hospeda o site. Se o disco falha, some tudo junto. Já em VPS, o que o painel chama de backup frequentemente é um snapshot: uma imagem congelada do disco em determinado instante. Snapshot é ótimo para desfazer uma atualização mal feita e péssimo para recuperar um único registro de banco de dados.
Na nuvem pública, por sua vez, o backup existe e é robusto, mas por padrão vive na mesma conta e responde às mesmas credenciais da produção. Ou seja: um invasor que obtém acesso administrativo apaga produção e cópia com o mesmo comando.
O que “backup diário” costuma significar na letra miúda
Backup diário significa apenas que existe uma rotina que roda uma vez por dia. Não diz, portanto, o que é copiado, onde a cópia é gravada, quanto tempo ela sobrevive, nem se alguém já testou recuperá-la.
Cinco lacunas que aparecem com frequência nos contratos:
- Escopo indefinido. “Backup do servidor” pode significar arquivos, mas não o banco de dados. Ou o banco, mas não as configurações de e-mail. Ou tudo, exceto o que está montado em volume externo. Portanto, exija a lista do que entra.
- Retenção em rotação curta. Sete cópias diárias sobrescritas em ciclo dão sete dias de história. Contudo, corrupção silenciosa, fraude interna e ransomware com detonação atrasada costumam ultrapassar essa janela.
- Backup no mesmo domínio de falha. Cópia no mesmo servidor, na mesma conta ou na mesma região não protege contra o evento que atinge a infraestrutura inteira. Por exemplo, é o caso do incêndio, da falha de disco e da conta comprometida.
- Restauração como serviço cobrado. Vários provedores incluem o backup e cobram pela restauração, às vezes com prazo de 24 a 72 horas para atendimento. O dado existe. A pressa, não.
- Ausência de responsabilidade contratual. A cláusula clássica: “o backup é oferecido como cortesia, sem garantia de integridade ou disponibilidade”. Se ela está lá, o backup não é um serviço. É um brinde.
Nenhuma dessas lacunas é ilegal ou desonesta. Elas estão escritas. No entanto, ninguém lê a página 7 do termo de uso antes de contratar.
Frequência é só uma das quatro variáveis: RPO, RTO, retenção e integridade
A frequência do backup define apenas quanto dado você pode perder. Sozinha, ela não diz nada sobre quanto tempo o sistema fica fora do ar, por quanto tempo você consegue voltar no passado, nem se a cópia é confiável.
As quatro variáveis, com tradução:
- RPO (Recovery Point Objective), ou objetivo de ponto de recuperação: quanto dado a empresa aceita perder, medido em tempo. Backup diário às 2h da manhã significa RPO de até 24 horas. Logo, se der problema às 23h, perdeu-se o dia inteiro de trabalho.
- RTO (Recovery Time Objective), ou objetivo de tempo de recuperação: quanto tempo o sistema pode ficar indisponível até voltar. Não adianta ter cópia de 15 minutos atrás se restaurar leva dois dias.
- Retenção: por quanto tempo as cópias são mantidas. É o que define até onde no passado você consegue voltar.
- Integridade: a cópia é verificável e restaurável? Um backup que nunca foi testado não passa de hipótese.
Veja um exemplo hipotético, para tornar concreto. Uma distribuidora fatura, em média, R$ 40 mil por dia útil pelo e-commerce. RPO de 24 horas significa aceitar a perda potencial de um dia de pedidos, além do retrabalho de reconciliação. Já RTO de 8 horas significa um dia de operação praticamente perdido. Nesse cenário, portanto, backup diário com restauração lenta custa muito mais caro do que o valor economizado no plano.
Em resumo, a conta que importa não é o preço do backup. É o custo da hora parada multiplicado pelo RTO.
Onde o backup diário falha na prática
Backup diário falha por três motivos recorrentes: a cópia está no mesmo lugar do original, pode ser apagada por quem tem acesso à produção, e nunca foi testada.
Mesmo domínio de falha
Isso vale para o disco, o servidor, a conta e a região. A regra 3-2-1 (três cópias do dado, em dois tipos de mídia diferentes, com uma delas fora do local principal) nasceu como boa prática de fotografia digital (Peter Krogh, The DAM Book, 2005) e virou padrão de mercado justamente porque resolve esse ponto. Na prática, a cópia externa é a que sobrevive ao evento local.
Cópia alcançável pela produção
Este é o vetor que mais mudou nos últimos anos. O relatório State of Ransomware da Sophos (2024) registrou que, na grande maioria dos ataques analisados, os criminosos tentaram comprometer os backups da vítima. Além disso, o mesmo levantamento indicou que as organizações cujos backups foram comprometidos acabaram pagando resgates significativamente maiores.
A resposta técnica para isso é o backup imutável: uma cópia que não pode ser alterada nem excluída durante um período definido, nem mesmo por administrador. Combinada com air gap (ausência de rota de rede direta entre produção e repositório de cópias), ela é o que sobra quando a credencial cai em mãos erradas.
Restauração nunca testada
Este é o mais banal e o mais frequente. A rotina roda, o log diz “sucesso”, ninguém abre o arquivo. Então, no meio do incidente, descobre-se que o dump do banco estava truncado desde a mudança de versão em março.
Backup que nunca foi restaurado não é backup. É esperança agendada.
A pergunta que resolve: quando foi o último teste de restauração?
Um teste de restauração é o exercício de pegar uma cópia real, subir em ambiente isolado e verificar se a aplicação funciona com ela. É a única evidência de que o backup existe de verdade. Por isso, deve acontecer no mínimo a cada seis meses e ser documentado.
Como fazer, sem parar a operação:
- Escolha um dado crítico e uma data aleatória dentro da janela de retenção.
- Restaure em ambiente separado, nunca sobre a produção.
- Cronometre. O tempo real do processo é o seu RTO verdadeiro, não o que está no contrato.
- Valide o conteúdo: registros mais recentes, integridade referencial do banco, arquivos abrindo.
- Registre data, responsável, tempo gasto e falhas encontradas.
O item 3, sobretudo, costuma ser o mais revelador. Empresas descobrem que o RTO contratado de 4 horas vira 11 horas na prática, porque ninguém contou o tempo de download de 900 GB, a reinstalação de dependências e o ajuste de DNS.
Se o seu provedor não consegue apresentar um relatório de teste de restauração, a resposta à pergunta do título deste bloco é “nunca”.
Checklist: 10 perguntas para o seu provedor de hospedagem
Mande por e-mail. Afinal, resposta por escrito vale mais do que promessa em call.
- O que exatamente entra no backup diário? Peça a lista de diretórios, bancos e configurações.
- Qual é a retenção? Existe cópia semanal e mensal, além da diária?
- Onde a cópia é gravada? Mesmo servidor, outro servidor, outra região ou outro data center?
- A cópia é imutável? Por quanto tempo?
- O acesso ao repositório de backup usa credencial diferente da produção?
- Qual é o RTO contratual, em horas, por escrito?
- A restauração é cobrada à parte? Qual o prazo de atendimento?
- Quem executa a restauração: o cliente pelo painel ou o time do provedor?
- Existe relatório de teste de restauração? Quando foi o último?
- O contrato prevê responsabilidade sobre a integridade da cópia, ou é oferecido “sem garantia”?
Se as respostas às perguntas 4, 5 e 9 forem negativas ou evasivas, o backup diário existe no marketing e não na arquitetura.
Vale complementar essa auditoria com os critérios de armazenamento em nuvem seguro e, no caso de bases transacionais, com o checklist de proteção de banco de dados.
Como a Prodb estrutura backup para quem não pode perder dado
A Prodb Tecnologia trabalha com infraestrutura em nuvem há 15 anos e atende mais de 550 clientes a partir da região de Campinas, em São Paulo. Backup aqui não é linha de rodapé no contrato de hospedagem: é serviço com escopo, política e responsável definidos.
O que muda na prática:
- A política começa pelo negócio, não pelo disco. Antes de definir frequência, a conversa é sobre quanto tempo cada sistema pode ficar fora do ar e quanto dado a operação aceita perder. Assim, RPO e RTO viram números escritos, e a arquitetura é montada para atendê-los.
- Cópia separada da produção. Os planos de backup da Prodb são desenhados com credenciais, políticas de retenção e camadas de imutabilidade independentes do ambiente que geram o dado. Dessa forma, se a produção cai, é comprometida ou é apagada, a cópia não vai junto.
- Dado no Brasil. Infraestrutura com certificações internacionais de cloud, servidores em território nacional e faturamento em real. Isso simplifica a conformidade com a LGPD (Lei nº 13.709/2018) e, de quebra, tira o câmbio do orçamento.
- Teste de restauração como rotina, não como emergência. A verificação faz parte do serviço. O cliente sabe quanto tempo leva para voltar porque isso já foi cronometrado antes.
- Suporte técnico dedicado. Na hora de restaurar, o atendimento é com quem conhece o ambiente. Não é fila genérica.
Uma ressalva honesta: nenhum plano de backup compensa um ambiente mal configurado. Se as permissões estão largas, se não há MFA e se o servidor de aplicação está exposto, o backup vai funcionar. E você vai usá-lo com frequência. Por outro lado, o bom desenho de servidores cloud reduz o número de vezes que a cópia precisa ser acionada. Para entender o outro lado dessa equação, vale ler sobre as vantagens do backup em nuvem.
Perguntas frequentes
Quais provedores de hospedagem oferecem backups diários?
Praticamente todos os tipos: hospedagem compartilhada, VPS, servidor dedicado, nuvem pública e nuvem gerenciada. O que muda entre eles é o que é copiado, por quanto tempo a cópia é guardada, onde ela fica, se o backup está incluso no preço e quem executa a restauração.
Backup diário é suficiente para proteger os dados da empresa?
Não por si só. A frequência define apenas quanto dado pode ser perdido. Também importam o tempo de restauração (RTO), a retenção, a separação entre cópia e produção, a imutabilidade e, principalmente, a existência de testes de restauração documentados.
Qual a diferença entre snapshot e backup?
Snapshot é uma imagem congelada do disco em um instante, útil para desfazer uma atualização mal feita. Backup de aplicação copia arquivos e bancos de dados de forma que seja possível recuperar itens específicos, como um único registro, e costuma ter retenção e armazenamento separados.
Sete dias de retenção de backup são suficientes?
Na maioria dos casos, não. Corrupção silenciosa de dados, fraude interna e ransomware com detonação atrasada costumam ser percebidos depois dessa janela. Vale combinar cópias diárias com cópias semanais e mensais e definir a retenção em contrato.
Com que frequência devo testar a restauração do backup?
No mínimo a cada seis meses, com registro. O teste consiste em restaurar uma cópia real em ambiente isolado, cronometrar o processo, validar o conteúdo e documentar data, responsável, tempo gasto e falhas encontradas.
O que perguntar ao provedor de hospedagem sobre backup?
O que entra no backup, qual a retenção, onde a cópia é gravada, se ela é imutável, se usa credencial diferente da produção, qual o RTO contratual, se a restauração é cobrada, quem a executa, quando foi o último teste e se o contrato garante a integridade da cópia.
Seu provedor consegue responder às 10 perguntas?
Se ficou dúvida em alguma delas, o risco não está no papel: está no próximo incidente. Nosso time avalia sua política de backup atual e aponta as lacunas.

