Um backup que realmente utiliza
A maioria das empresas só descobre que o backup não funciona quando acontece o desastre. Por isso aconselhamos tratar o backup como um processo, não como uma formalidade: cópias automáticas, guardadas longe do servidor de produção e restauros testados com regularidade. No cPanel o backup diário corre automaticamente e restaura-o a partir do painel; em VPS e servidores dedicados, a equipa de DevOps pode configurar testes de restauro agendados com as horas incluídas.
Que backup inclui cada plano
O alojamento cPanel tem um backup diário automático que restaura a partir do painel. Um VPS tem snapshots — cópias completas do estado do servidor — sem frequência garantida. Os servidores dedicados não incluem backup por defeito: os discos NVMe vêm em pares e o RAID é configurado na instalação, mas o RAID não é um backup. O backup externo, o PITR para bases de dados e os testes de restauro são configurados pela nossa equipa com as horas de DevOps incluídas (5–10 h/mês nos dedicados).
| Plano | Backup | Restauro | Localização |
|---|---|---|---|
| Alojamento cPanel | Backup diário automático | A partir do painel de cliente | UE (Frankfurt) |
| VPS | Snapshots, sem frequência garantida | A partir de um snapshot | UE (Frankfurt) |
| VPS — backup externo | A pedido, com horas de DevOps | Conforme a estratégia configurada | Acordado com a equipa |
| Servidor dedicado | Não incluído por defeito — configurado a pedido | Conforme a estratégia (3-2-1, PITR) | UE (Frankfurt) + armazenamento externo a pedido |
RPO e RTO — os números que deve definir
Em vez de “backup o mais depressa possível”, compensa fixar dois valores concretos. O RPO (Recovery Point Objective) indica quantos dados pode permitir-se perder. O RTO (Recovery Time Objective) indica quanto tempo pode demorar um restauro. A equipa constrói a estratégia em torno destes valores.
A perda máxima de dados que pode aceitar. Um backup diário significa até um dia perdido; com streaming de WAL, uma base de dados fica abaixo de um minuto — configurado a pedido.
O tempo de restauro depende do volume de dados e da estratégia escolhida. Não garantimos um RTO — o único valor fiável é o medido num teste de restauro.
Cenários de desastre — e como se proteger
Os desastres são raros, mas de grande impacto. Eis os cenários mais comuns e a proteção que recomendamos para cada um. Em VPS e servidores dedicados, a equipa configura estas medidas com as horas de DevOps incluídas.
Falha de hardware (disco, RAM)
A causa mais comum de perda de dados. Os servidores dedicados têm discos NVMe em pares com RAID configurado na instalação, além de RAM ECC nos escalões EPYC e Xeon. O RAID mantém o servidor a funcionar quando um disco falha, mas não substitui o backup — continua a ser necessária uma cópia externa.
Proteção: RAID + backup externoRansomware ou comprometimento de conta
O atacante cifra os ficheiros do servidor — e qualquer cópia a que o servidor consiga aceder. Por isso, pelo menos uma cópia deve ficar fora do servidor, onde a conta de produção não a possa alterar (imutável ou offline). Configuramo-la a pedido, com as horas de DevOps.
Proteção: cópia isoladaEliminação acidental de dados
“DROP TABLE users” executado em produção. O erro humano mais comum. Se a base de dados tiver recuperação para um ponto no tempo (PITR) configurada, volta ao instante imediatamente anterior ao erro; um backup diário só o leva de volta à última cópia.
Proteção: PITR a pedidoFalha total do centro de dados
Incêndio, inundação, indisponibilidade prolongada do operador. A proteção é uma cópia noutra localização, como um segundo centro de dados. A replicação e o failover não estão incluídos por defeito; a equipa configura-os a pedido, com as horas de DevOps.
Proteção: cópia noutra localizaçãoUm erro da aplicação corrompe os dados
Um deploy introduz um erro que corrompe registos da base de dados. Com um backup separado da base de dados, restaura apenas a BD (não o servidor inteiro) — os ficheiros da aplicação ficam, os dados recuam.
Proteção: backup separado da BDMigração para outro servidor
Ultrapassa o plano atual. Um VPS sobe para um escalão superior com mais vCPU, RAM e disco; para uma mudança para outro servidor, planeamos a migração com antecedência para manter o tempo de inatividade curto.
Dica: planeie a migração cedoBackup de bases de dados — estratégias por motor
Um backup completo do VPS nem sempre chega. As bases de dados têm os seus próprios mecanismos de recuperação para um ponto no tempo (PITR) — permitem voltar exatamente ao momento escolhido, e não apenas ao último snapshot. Configuramo-los a pedido, com as horas de DevOps incluídas.
O que está incluído — e o que é configurado a pedido
Não existe um “backup premium” vendido à parte: o que está incluído vem indicado em cada plano e tudo o que vá além disso a equipa constrói com as horas de DevOps da sua subscrição. As horas acima da quota são faturadas à parte, ao preço por hora.
- cPanel: backup diário automático, restauro a partir do painel — incluído
- VPS: snapshots, sem frequência garantida — incluído
- Servidores dedicados: discos NVMe em pares, RAID configurado na instalação — backup não incluído por defeito
- Backup externo segundo a regra 3-2-1 — a pedido, com horas de DevOps (5–10 h/mês nos dedicados)
- PITR para bases de dados (WAL, binlog, oplog) — a pedido, com horas de DevOps
- Testes de restauro e período de retenção — acordados com a equipa e configurados com horas de DevOps
Restaurar um backup — em 4 passos
Abra o painel
Inicie sessão no painel de cliente. No cPanel restaura aí o backup diário; no VPS escolhe um snapshot.
Escolha um ponto no tempo
Escolha a cópia imediatamente anterior ao problema. A mais recente nem sempre é a certa, se o erro já lá estiver há algum tempo.
Clique em “Restaurar”
Um restauro substitui o estado atual. Se tiver dúvidas, peça à equipa que restaure primeiro para um ambiente separado, para poder comparar.
Verifique o resultado
Confirme que a aplicação funciona e que os dados estão onde devem estar. O tempo que o restauro demora depende do volume de dados.
Perguntas frequentes
Um snapshot exige parar o servidor?
Normalmente não: um snapshot de VPS é feito com o servidor em funcionamento. No caso de uma base de dados, porém, o snapshot de um servidor em execução nem sempre é consistente, por isso recomendamos um backup separado da base de dados (dump ou WAL/binlog), que a equipa configura a pedido.
Quanto tempo demora restaurar um snapshot muito grande (p. ex. 500 GB)?
Depende do volume de dados, do disco e do local onde a cópia está guardada — restaurar a partir de uma cópia externa demora mais do que a partir de uma local. Não prometemos um tempo fixo: o valor realista vem de um teste de restauro, que podemos realizar consigo.
Os backups são cifrados?
A cifragem dos backups externos faz parte da estratégia que configuramos a pedido — por exemplo, cópias que saem do servidor apenas de forma cifrada, com as chaves guardadas separadamente da produção. Indique à equipa os seus requisitos quando pedir a configuração.
E se quiser uma retenção superior a 30 dias?
A retenção dos backups externos é definida quando a equipa configura a estratégia, de acordo com as suas necessidades e as suas obrigações legais de arquivo. O armazenamento para uma retenção mais longa é acordado com a equipa; encontra os planos na página de preços.
Posso descarregar um snapshot localmente?
Em VPS e servidores dedicados tem acesso root e copia os seus dados com as ferramentas que preferir (rsync, tar). A equipa também pode configurar cópias automáticas para armazenamento externo com as horas de DevOps, como AWS S3, Google Cloud Storage ou Azure Blob.
Os seus dados valem demasiado para ficarem entregues à sorte
O cPanel inclui backup diário e o VPS inclui snapshots. Nos servidores dedicados, a equipa constrói a estratégia de backup com as horas de DevOps incluídas. Consulte os preços para mais detalhes.
Ver planos →