O que você vai configurar
Atacantes que entram em uma rede costumam tentar apagar ou criptografar os backups antes de criptografar os servidores. Um backup que uma conta de administrador roubada consegue apagar, portanto, não basta. Este guia monta com o BackupZit uma proteção em camadas: um backup principal em armazenamento local, uma cópia em outro lugar e um armazenamento onde os backups não podem ser destruídos antes do fim de um período definido, nem mesmo com as credenciais do armazenamento. O BackupZit é gratuito e de código aberto (AGPLv3); tudo o que está descrito aqui faz parte do produto gratuito.
A regra 3-2-1, e 3-2-1-1-0
A regra 3-2-1: 3 cópias dos seus dados, em 2 mídias diferentes, 1 delas fora da empresa. A extensão 3-2-1-1-0 acrescenta 1 cópia imutável ou offline e 0 erros na verificação dos backups. No BackupZit:
| Parte | No BackupZit |
|---|
| 3 cópias | Os dados de produção, uma tarefa de backup e uma tarefa de cópia. |
| 2 mídias | Dois destinos de armazenamento, p. ex. um NAS via SMB ou SFTP e um bucket S3. |
| 1 externa | A cópia vai para a nuvem (S3, Azure Blob Storage) ou para um repositório protegido em outro prédio. |
| 1 imutável ou offline | S3 com Object Lock, um repositório protegido ou discos USB em rodízio. |
| 0 erros | Os testes de restauração automáticos e a verificação de todos os dados armazenados, com um alerta quando algo falha. |
Você precisa de um console BackupZit com agentes nas máquinas que protege; os guias de Proxmox VE, Hyper-V e imagens de disco do Windows mostram esses primeiros passos.
Passo 1 — Armazenamento principal para restaurações rápidas
No console, abra Armazenamento → Adicionar destino de armazenamento. Para a primeira cópia, escolha armazenamento na rede local, para que backups e restaurações rodem em velocidade total: um compartilhamento SMB em um servidor de arquivos ou NAS, ou um servidor Linux ou NAS via SFTP (a chave do host é fixada). Dê ao destino uma conta própria que só possa gravar na pasta de backups e não coloque o armazenamento de backup no domínio Windows.
Ao salvar, o console testa o destino na hora: uma senha, chave de host ou compartilhamento errados aparecem agora, e não no primeiro backup. Testar conexão na lista de armazenamento repete o teste.
Passo 2 — Adicionar armazenamento imutável
O BackupZit tem dois tipos de armazenamento em que os backups não podem ser apagados nem sobrescritos antes do fim do seu período. O ideal é que ele também fique fora da empresa, para que um único destino cubra as duas coisas.
Opção A: S3 com Object Lock
- Crie o bucket com Object Lock ativado — na AWS, Wasabi e Backblaze B2 é uma opção ao criar o bucket; no MinIO,
mc mb --with-lock.
- Adicione uma regra de ciclo de vida que exclua versões não atuais após um dia (MinIO:
mc ilm rule add --noncurrent-expire-days 1 --expire-delete-marker). Apagar um backup bloqueado só adiciona um marcador de exclusão; a regra libera o espaço quando os bloqueios terminam.
- No console, adicione um destino do tipo Compatível com S3 (AWS, Wasabi, Backblaze B2, MinIO, …) com endpoint, bucket e uma chave de acesso para esse bucket.
- Marque Backups imutáveis (S3 Object Lock, modo compliance) por … dias (30 por padrão) e escolha um período pelo menos tão longo quanto a retenção que você quer proteger.
Cada arquivo gravado pelos agentes fica então bloqueado em modo compliance por esse período mais um dia: ninguém — nem um atacante com as chaves, nem o dono do bucket — pode apagá-lo ou sobrescrevê-lo antes disso. Os dados que um novo backup reaproveita dos anteriores têm o bloqueio estendido, de modo que cada ponto de restauração fica protegido pelo período inteiro. Em armazenamento imutável, o teste de conexão apenas entra e lista, e verifica se o bucket realmente tem Object Lock.
Azure e Google Cloud: para o Azure Blob Storage, ative no Azure a imutabilidade em nível de versão com uma política de retenção baseada em tempo no contêiner. O Google Cloud Storage funciona como destino S3, mas sem a opção Object Lock; em vez disso, defina no Google Cloud uma política de retenção do bucket (e bloqueie-a).
Opção B: repositório protegido no seu próprio servidor Linux
Um servidor Linux dedicado executa o backupzit-repo (os pacotes deb e rpm acompanham cada versão no GitHub):
apt install ./backupzit-repo_*.deb # ou: dnf install ./backupzit-repo-*.rpm
vi /etc/backupzit-repo/repo.env # BACKUPZIT_REPO_LOCK_DAYS=30
systemctl start backupzit-repo
backupzit-repo add-key office-console # mostra a chave de acesso uma única vez
backupzit-repo fingerprint # impressão digital do certificado
No console, adicione um destino do tipo Repositório protegido (backupzit-repo no Linux, imutável) com o endereço do servidor (porta 8500 por padrão), a chave de acesso e a impressão digital.
- Agentes e console só podem adicionar arquivos; os existentes nunca são sobrescritos.
- Cada arquivo recebe o atributo imutável (
chattr +i) pelo período configurado nesse servidor, mais um dia. Nem o root consegue apagá-lo sem antes remover o atributo.
- Exclusões vindas dos clientes — pela retenção ou por um atacante com a chave de acesso — apenas ocultam os arquivos até o fim do seu período.
- O período é configurado só no servidor do repositório; console e agentes não podem alterá-lo.
Depois da configuração, desative o SSH e qualquer outro acesso remoto a esse servidor e proteja seu console local, iDRAC/iLO ou o acesso ao hipervisor: a proteção é tão forte quanto a conta root dele.
Passo 3 — Criptografia e chave de recuperação
Deixe Criptografar backups (AES-256) ligado (padrão). Conteúdo dos arquivos, nomes, estrutura de pastas e listas de snapshots são criptografados com AES-256-GCM antes de sair do agente, e qualquer alteração nos dados é detectada. A imutabilidade impede a exclusão, a criptografia impede a leitura — você precisa das duas.
Para cada destino criptografado, o console mostra uma Chave de recuperação e oferece uma folha de recuperação. Guarde-a offline e separada dos backups: com a chave, o local do armazenamento e suas credenciais você restaura mesmo sem o console; sem a chave, ninguém consegue ler os backups — nem o suporte do BackupZit.
Passo 4 — Tarefa de backup e retenção
Crie a tarefa em Tarefas de backup com o armazenamento principal do passo 1. Em Manter backups, defina os N mais recentes mais pontos de restauração diários, semanais e mensais — por exemplo, 3 recentes, 7 diários, 4 semanais e 6 mensais guardam cerca de meio ano com uns 20 pontos de restauração. A deduplicação armazena dados inalterados uma única vez.
Objetivo de ponto de recuperação (RPO), horas diz quanto o último backup bom pode envelhecer, p. ex. 26 para uma tarefa diária. Uma tarefa que não o cumpre aparece no painel e é notificada, o que também pega um agente offline há dias ou um agendamento removido por engano.
Passo 5 — Cópia externa com uma tarefa de cópia
Crie uma segunda tarefa e escolha Cópia de backup. Em Copiar os backups de, selecione a tarefa do passo 4 e, como Destino de armazenamento, o destino imutável ou externo do passo 2.
- O agente da tarefa de origem copia os backups existentes; a máquina protegida não é lida de novo.
- Só são enviados os dados que ainda não estão no destino, criptografados de novo com a chave do destino.
- Após cada backup da tarefa de origem (padrão) mantém a cópia em dia; um agendamento normal também serve, p. ex. uma vez por noite com uma linha lenta.
- A cópia tem sua própria retenção, p. ex. 7 diários no NAS e 12 mensais na nuvem. Cada ponto de restauração fica bloqueado por N dias a partir da sua criação; com um bloqueio de 30 dias, os pontos mensais mais antigos já não estão protegidos. Um bloqueio mais longo protege mais deles, mas também ocupa mais dados.
Backups de arquivos e de VMs (Proxmox VE, Hyper-V, VMware) são restaurados a partir da cópia como do original; cópias de imagens de disco, com o agente de linha de comando. Copiar agora inicia uma cópia na hora.
Cópia offline para escritórios pequenos: o tipo de destino Discos USB / removíveis em rodízio (cópias offline) encontra os discos pelo rótulo do volume (BZBACKUP1, BZBACKUP2 …). Aponte uma tarefa de cópia para ele, troque os discos p. ex. semanalmente e guarde o desconectado em local seguro. Se nenhum disco estiver conectado, a execução falha com um alerta.
Passo 6 — Testes de restauração e verificação dos dados
Um backup só está comprovado depois de restaurado. Em Configurações → Testes de restauração:
- Testar automaticamente o backup mais recente de cada tarefa (semanal por padrão): uma amostra aleatória de arquivos do backup mais recente é restaurada em uma pasta temporária, verificada byte a byte com as somas de verificação armazenadas e apagada; em imagens de disco, blocos aleatórios são verificados. Isso põe à prova o acesso ao armazenamento, as credenciais, a chave e os dados.
- Verificar os dados armazenados (mensal por padrão): cada pedaço de dados de cada repositório é lido e verificado, o que revela cedo um disco de NAS falhando ou degradação silenciosa de dados. Em S3 e Azure só roda com Também em armazenamento na nuvem (S3, Azure) ligado — baixa tudo, atenção aos custos de download.
- Tarefas de VM do Proxmox podem acrescentar um teste de inicialização que liga cada VM a partir do backup com a rede desconectada.
Testar restauração e Verificar dados na página de uma tarefa iniciam isso na hora. Os resultados aparecem em Atividade e Relatórios; um teste com falha envia um alerta como qualquer falha.
Passo 7 — Alertas e detecção de ransomware
Uma cópia externa que falha há semanas não é cópia. Configure Configurações → Notificações por e-mail (confira com Enviar e-mail de teste) e deixe Falhas ligado: um e-mail por execução com falha, com o motivo — backups, cópias, restaurações e testes de restauração — e, se quiser, um relatório diário. Configurações → Chat e webhooks envia o mesmo para Slack, Microsoft Teams ou qualquer endpoint HTTP. No painel, Requer atenção lista tarefas com falha, agendamentos e RPOs perdidos, agentes offline e armazenamentos 90 % cheios ou que ficarão cheios em 30 dias.
Cada backup também é comparado com o histórico recente da sua tarefa. Ele é marcado como suspeito quando mudaram muito mais arquivos do que o normal, os dados novos não se comprimem mais (arquivos criptografados parecem aleatórios), o número de arquivos caiu um terço ou mais ou a quantidade de dados novos disparou. O BackupZit então envia um alerta, lista o backup em backups suspeitos para revisar e pausa a retenção da tarefa (A retenção está pausada), para que os últimos backups limpos não sejam apagados mesmo que backups danificados continuem chegando. Depois de verificar a máquina, clique em Revisado — retomar a retenção.
Passo 8 — Proteger o console
O armazenamento imutável protege os backups; o console continua decidindo o que é copiado e mantido. Em Configurações → Login e segurança, exija autenticação de dois fatores para administradores e ative a Aprovação a quatro olhos: excluir tarefas ou destinos de armazenamento, encurtar a retenção, retomar a retenção após um backup suspeito e desligar a aprovação passam a exigir um segundo usuário. Mantenha o console na rede interna, não publique a porta 8443 na internet e use uma VPN para a administração remota. Com Configurações → Backup do console, o console também faz backup de si mesmo todos os dias em um destino de armazenamento de rede.
Depois de um ataque
Se backups foram apagados ou sobrescritos, leia o armazenamento como estava antes do ataque — somente leitura, em S3 com Object Lock e no repositório protegido:
backupzit-agent snapshots --repo <repositório> --as-of 2026-10-01T14:30
backupzit-agent restore --repo <repositório> --as-of 2026-10-01T14:30 --target D:\Restore latest
Em um repositório protegido, o administrador também pode trazer de volta os arquivos ocultos, para que os backups continuem normalmente:
backupzit-repo status
backupzit-repo undelete --since 2026-10-01T14:00
Limites a conhecer
- A imutabilidade só dura enquanto dura o bloqueio. Um backup apagado some de verdade quando o seu período termina; escolha o período pensando em quanto tempo um ataque poderia passar despercebido.
- Um repositório protegido é tão seguro quanto a sua conta root e o acesso ao seu console, iDRAC/iLO ou hipervisor.
- SMB, SFTP e discos locais não têm imutabilidade própria; combine-os com uma cópia imutável ou offline.
- Dados bloqueados ocupam espaço até o fim do bloqueio, mesmo depois de apagados; sem a regra de ciclo de vida, o espaço no S3 não é liberado.
- A imutabilidade não limpa os dados: arquivos criptografados antes do backup são copiados criptografados. Restaure um ponto anterior ao ataque — a detecção os preserva pausando a retenção.
- Sem a chave de recuperação, ninguém consegue ler backups criptografados.
- A aprovação a quatro olhos vale para o console; os grupos de administradores no Active Directory ou no Entra ID precisam ser protegidos lá.
