Kopie zapasowe hostingu. Dwie warstwy, każdej nocy.

1. Um backup que funciona antes de precisares dele

Um backup só é útil se existir no momento de uma falha, não quando alguém promete que estará lá. No Saplo, o backup do Box é uma cópia instantânea de todo o contentor LXC, criada automaticamente às 4:00 e sem intervenção do cliente. Assim, não tens de te lembrar de exportar manualmente a base de dados antes de cada atualização arriscada.

A retenção (o número de dias durante os quais a cópia é mantida) aumenta conforme o plano: o Box L tem 7 dias, o Box XL tem 14 dias e o Box XXL tem 30 dias, além de uma cópia offsite gerada por um mecanismo separado (borg) todas as noites às 1:00 para uma localização remota em Helsinque, sem depender da cópia instantânea local no mesmo servidor.

O Box S e o Box M não incluem backup no preço porque são planos de entrada para projetos em que o custo do backup teria de aumentar o preço do plano inteiro para todos os clientes, mesmo para quem não precisa dele (por exemplo, um site de testes ou um portfólio sem dados dinâmicos).

2. Duas camadas de backup, não apenas uma

A cópia instantânea LXC local (backup_limit em dias) protege contra o cenário mais comum: um erro numa atualização, um plugin avariado ou a eliminação acidental de dados pelo próprio cliente. A restauração é rápida porque ocorre no mesmo servidor físico, sem transferência de dados pela rede.

A cópia offsite (disponível a partir do Box XXL) protege contra um cenário muito mais raro, mas mais grave: a falha do servidor físico inteiro ou do centro de dados. A cópia em Helsinque está fisicamente separada do servidor de produção em Falkenstein, pelo que mesmo a perda total do servidor não significa a perda dos dados do cliente.

A distinção entre estas duas camadas é importante ao escolher o plano: se o projeto for crítico para o negócio (uma loja com transações reais ou uma aplicação SaaS com clientes pagadores), vale a pena considerar um plano com backup offsite, e não apenas uma cópia instantânea local.

3. Backup nos concorrentes: o que está incluído e o que é preciso comprar à parte

O Concorrente A, nos planos VPS do tipo root, oferece 28 dias de retenção do backup, mas a restauração a partir da cópia é feita a pedido e tem custo, porque o cliente gere o servidor por conta própria e o backup é tratado como um serviço adicional, não como um processo totalmente automatizado (preços públicos, descrição do plano do concorrente, situação à data de 2026-10-10).

Nos planos VPS Windows do mesmo fornecedor, o backup de todo o servidor é copiado todos os dias para um servidor externo, com uma retenção de 7 a 28 dias, consoante o plano e as funcionalidades adicionais escolhidos (preços públicos, situação à data de 2026-10-10). Isto é semelhante ao modelo Saplo, embora exija um plano VPS adequado e mais caro.

Em muitos fornecedores de alojamento partilhado, o backup está disponível, mas a restauração a partir da cópia exige, com frequência, um pagamento adicional ou está limitada a um número definido de restaurações por mês. Na prática, isto significa que o backup protege contra a perda de dados, mas nem sempre está disponível sem custo quando realmente precisas dele.

No Saplo, o backup está incluído nos planos que o contemplam (Box L, Box XL e Box XXL). Não há qualquer custo adicional pelo restauro a partir de um snapshot, pois faz parte do mesmo mecanismo automático e não exige uma intervenção de suporte separada.

4. Para quem é indicado

Para um projeto de teste ou um portefólio sem dados dinâmicos, o backup não é essencial, pois, em caso de problema, basta restaurar o site a partir do código ou do repositório Git.

Para uma loja, um CRM ou uma aplicação com dados reais de clientes, o backup deixa de ser uma opção e passa a ser uma necessidade, porque a perda da base de dados de encomendas ou de contactos tem um custo direto para o negócio, não sendo apenas um inconveniente.

Para projetos críticos (SaaS com clientes que pagam, sistemas financeiros), vale a pena considerar o Box XXL com uma cópia offsite, porque um snapshot local no mesmo servidor não protege contra a falha do próprio servidor físico.

5. Como funciona o restauro a partir de uma cópia de segurança na prática

O restauro a partir de um snapshot local é feito no painel do Saplo: escolhes a data da cópia e confirmas o restauro. Num cenário típico, não precisas de contactar o suporte, porque faz parte do mecanismo automatizado de backup.

Como o snapshot inclui todo o contentor, o restauro abrange tudo de uma só vez: os ficheiros, a base de dados e a configuração da aplicação. É mais simples do que restaurar manualmente a base de dados e os ficheiros em separado, a partir de duas fontes diferentes.

Com uma cópia offsite (Box XXL), o restauro a partir da cópia guardada em Helsinque demora mais do que o restauro a partir de um snapshot local, porque exige a transferência de dados pela rede. Mas é a única opção em caso de falha total do servidor de produção.

Vale a pena testar o processo de restauro antes de precisares dele, por exemplo numa cópia de teste da aplicação, para saberes quanto tempo demora e o que podes esperar, em vez de aprenderes isso durante uma falha real.

O histórico dos backups está visível no painel, com as datas de execução, o que permite escolher o dia específico para o restauro, por exemplo, o dia anterior a uma atualização incorreta de um plugin que quebrou o funcionamento do site.

6. Backup, RGPD e dados pessoais dos clientes

O backup da base de dados com dados pessoais dos clientes (por exemplo, encomendas da loja ou contactos no CRM) está sujeito às mesmas regras do RGPD que os dados de produção, por isso vale a pena saber onde se encontra fisicamente a cópia e durante quanto tempo é mantida.

A retenção do backup (7, 14 ou 30 dias, consoante o plano) significa que os dados eliminados pelo cliente do ambiente de produção ainda podem existir na cópia de segurança durante esse período, algo relevante para o cumprimento do direito ao apagamento.

A cópia offsite em Helsinque está fisicamente separada do servidor de produção em Falkenstein. É um fator a ter em conta ao avaliar onde são realmente armazenadas as cópias dos dados pessoais dos clientes abrangidos pelo backup.

Para empresas que tratam dados pessoais em maior escala (lojas, CRM ou sistemas médicos), um plano superior com retenção mais longa e cópia offsite oferece melhor proteção contra a perda de dados, mas exige também que tenhas consciência de onde ficam fisicamente estas cópias.

7. Cenários de falha e o que o backup protege de facto

O cenário mais comum contra o qual o backup oferece proteção é o erro humano: a eliminação acidental do site, uma atualização de plugin falhada que corrompeu a base de dados ou uma alteração precipitada no código da aplicação, implementada sem testes em produção.

O segundo cenário é um ataque: um site comprometido com código malicioso injetado, em que restaurar o site a partir de uma cópia anterior à infeção é normalmente mais rápido do que limpar manualmente cada ficheiro e cada registo da base de dados à procura de código malicioso.

O terceiro cenário, o mais raro, mas também o mais grave, é a falha do próprio servidor físico ou do centro de dados. Só a cópia offsite, fisicamente separada do servidor de produção, protege contra este cenário, porque um snapshot local no mesmo disco não sobrevive à falha desse disco.

Para a maioria dos pequenos projetos, os dois primeiros cenários são muito mais prováveis do que o terceiro. Por isso, um snapshot local (Box L e Box XL) oferece uma proteção real por um preço razoável, enquanto a cópia offsite (Box XXL) só faz sentido em projetos em que até uma falha do servidor, rara mas catastrófica, seja inaceitável.

Vale ainda lembrar que o backup não protege contra erros comerciais (um preço errado na loja, o conteúdo errado de um email enviado aos clientes por automação), porque esses erros fazem parte dos dados que o backup copia fielmente com o resto, sem distinguir o erro do estado correto.

Verificar regularmente, mesmo que de forma rápida, se o backup está realmente a ser realizado (a data da última cópia aparece no painel) é uma medida simples que deteta um problema no mecanismo de backup antes de ele se manifestar no pior momento possível, precisamente quando o backup é mais necessário.

8. Como o Saplo comunica o estado do backup ao cliente

A transparência do mecanismo de backup é tão importante como a sua existência: o cliente deve poder verificar a qualquer momento quando foi realizada a última cópia, sem precisar de perguntar ao suporte qual é o estado do backup da sua aplicação.

O painel do Saplo mostra o histórico de backups realizados, com as respetivas datas, o que te permite verificar por tua conta se o mecanismo funciona corretamente, em vez de confiar apenas no regulamento, que afirma que o backup é realizado todas as noites.

Em caso de problema no mecanismo de backup (por exemplo, se um snapshot não tiver sido realizado numa noite devido a uma falha técnica), a equipa do Saplo comunica os incidentes deste tipo, de acordo com o princípio de que a prova vale mais do que a simples garantia de que tudo funciona como previsto.

Para projetos críticos para o negócio (lojas, aplicações com clientes que pagam), verificar por conta própria e com regularidade o estado do backup no painel, pelo menos uma vez por mês, é uma boa prática, independentemente de o mecanismo automático funcionar bem no dia a dia.

Uma informação clara sobre quais planos incluem o backup e quais precisam de um complemento permite-te tomar uma decisão informada ao escolher o Box, em vez de descobrir que não há backup só quando já precisares dele.

9. Backup como parte da avaliação de riscos do projeto, não como um extra para mais tarde.

Quando planeias um novo projeto, vale a pena avaliar desde o início qual seria o custo da perda de dados num dado momento do seu desenvolvimento: para um site em construção, o custo é baixo, porque o código e os conteúdos podem ser restaurados a partir do repositório, mas para uma loja com encomendas reais, a perda de até um único dia de dados pode ter um impacto financeiro significativo.

Esta avaliação deve influenciar a escolha do plano Box desde o início e não ser adiada até ao momento em que o projeto já tem valor comercial real, porque, nessa fase, a migração para um plano com backup exige um passo administrativo adicional, ainda que simples, em vez de o backup fazer parte logo da escolha inicial.

Para projetos que crescem gradualmente (começam como um site simples e acabam por acrescentar uma loja ou um sistema de reservas), o momento natural para considerar o backup é precisamente a fase de transição em que a aplicação começa a guardar dados cuja perda causaria um prejuízo real, e não apenas a perda de conteúdo superficial do site.

O custo do backup incluído num plano Box mais elevado também deve ser comparado com o custo de criares manualmente as tuas próprias cópias (exportar a base de dados, arquivar ficheiros). Embora seja tecnicamente possível em qualquer plano, isso exige uma disciplina regular por tua parte que o mecanismo automático de backup elimina por completo.

A decisão final sobre se o backup é necessário deve basear-se sempre numa avaliação realista do valor dos dados guardados na aplicação, e não no preço do complemento ou do plano mais elevado, porque é o valor dos dados perdidos, e não o custo do backup, que aqui representa o fator de risco real.

10. Resumo: o backup como uma decisão consciente, não um acaso

A escolha de um plano com backup incluído no preço (Box L e superiores) ou a compra do backup como complemento para o plano inicial deve resultar de uma avaliação consciente do valor dos dados guardados em cada aplicação, e não do acaso ou da falta de conhecimento sobre quais os planos têm backup. Num projeto de teste ou de portfólio, o risco é pequeno, mas numa loja, num CRM ou numa aplicação com clientes que pagam, o backup deixa de ser uma opção e passa a fazer parte das responsabilidades básicas de gerir o negócio, tal como o seguro ou outras medidas habituais de proteção contra o risco operacional. O custo do plano adequado com backup incluído costuma ser pequeno face ao custo de um único dia de dados transacionais perdidos, o que torna esta decisão uma das mais fáceis de justificar no orçamento de qualquer projeto online gerido a sério.