---
title: "Como configurar backup automático da VPS com restic e cron"
description: "Configure backup automático da VPS com restic e cron: destino externo, frequência, retenção com forget e o teste de restauração que prova que funciona."
url: "https://streethosting.com.br/guias/vps/automatizar-backup-vps-restic-cron"
category: "vps"
slug: "automatizar-backup-vps-restic-cron"
datePublished: "2026-06-17"
dateModified: "2026-09-28"
author: "Equipe StreetHosting"
difficulty: "avancado"
language: "pt-BR"
keywords:
  - "backup vps restic cron"
  - "backup automatico vps linux"
  - "restic snapshot criptografado"
  - "agendar backup cron vps"
  - "retencao de backup restic"
  - "restaurar backup vps"
---

# Backup automático da VPS com restic e cron: estratégia, retenção e restauração

Backup que depende de você lembrar não funciona. Com restic e cron você cria snapshots criptografados, envia para fora da VPS, controla a retenção e testa a restauração sem esforço diário.

> **Resposta rápida**
>
> Para automatizar o **backup da VPS com restic e cron**, instale o restic, inicialize um repositório criptografado num destino externo, escreva um script que gera os dumps dos bancos, faz o backup e aplica retenção com forget e prune, e agende no cron em horário tranquilo. Guarde a senha do repositório fora da VPS, avise um monitor quando o backup terminar e teste a restauração todo mês.

## Por que restic

O restic faz snapshots incrementais, criptografados e com deduplicação, o que economiza espaço e protege os dados. Cada execução envia só os blocos que mudaram, mas todo snapshot pode ser restaurado sozinho, sem depender de uma cadeia de incrementais. É um binário único, sem servidor próprio, e fala com vários destinos: pasta local, outro servidor por SFTP, armazenamento compatível com S3 e o rest server do próprio projeto.

Aliado ao cron, ele transforma backup numa rotina invisível. Esse hábito é a base prática da [estratégia de backup 3 2 1](https://streethosting.com.br/guias/infraestrutura/estrategia-backup-3-2-1-servidor), que explica por que ter três cópias em dois meios, uma delas fora do local. Aqui o foco é a execução: o que copiar, o script, o agendamento, a retenção e o teste.

## O que copiar, quando e por quanto tempo

A frequência responde a uma pergunta: quanto dado você aceita perder? Com backup diário às 3h, uma falha às 23h leva quase um dia de trabalho. Nem tudo precisa do mesmo ritmo:

| O que | Frequência | Retenção sugerida | Observação |
| --- | --- | --- | --- |
| Bancos de dados | Diária ou a cada poucas horas | 7 diários, 4 semanais, 6 mensais | Sempre por dump, nunca copiando os arquivos do banco em uso |
| Uploads e arquivos da aplicação | Diária | 7 diários, 4 semanais, 6 mensais | Exclua cache, logs e dependências que se reinstalam |
| Configurações do sistema | Diária | Mesma do resto | Pasta etc, arquivos do Compose, crontabs, certificados |
| Código em repositório Git | Não precisa | Não se aplica | Já existe fora da VPS; copie só o que não está no Git |
| Sistema operacional e pacotes | Não precisa | Não se aplica | Reinstalar é mais rápido que restaurar |

Há dois lugares para as cópias. A cópia local, como os dumps que ficam numa pasta da própria VPS, restaura em segundos um arquivo apagado por engano, mas some junto com a máquina e ocupa o disco dela. A cópia externa, em outro servidor ou num armazenamento compatível com S3, é a que salva você quando a VPS inteira se perde, é invadida ou alguém roda o comando errado como root. O script abaixo faz as duas: gera o dump local e manda tudo para fora.

## Preparar o repositório

```
sudo apt update && sudo apt install -y restic
restic version

# senha aleatória do repositório, legível só pelo root
sudo sh -c 'openssl rand -base64 32 > /root/.restic-senha && chmod 600 /root/.restic-senha'
```

> **Atenção**
>
> A senha do repositório criptografa tudo. Se você perder essa senha, os backups ficam irrecuperáveis. Copie o conteúdo de `/root/.restic-senha` para um gerenciador de senhas, fora da própria VPS: se a VPS sumir, o arquivo some junto.

As variáveis do repositório ficam num arquivo que o script carrega. Escolha um dos destinos:

### Outro servidor por SFTP

Crie um usuário comum no servidor de destino e autorize a chave SSH do root da VPS nele, do jeito descrito em [configurar chave SSH sem senha](https://streethosting.com.br/guias/vps/configurar-chave-ssh-sem-senha-vps). No destino, a pasta `/srv/restic` precisa existir e pertencer a esse usuário. Depois, conecte uma vez manualmente como root, com `sudo ssh backup@IP_DO_SERVIDOR_DE_BACKUP`, para aceitar a identidade do servidor: o cron não tem como digitar senha nem responder a essa pergunta.

```
# /root/.restic-env  (chmod 600)
export RESTIC_REPOSITORY="sftp:backup@IP_DO_SERVIDOR_DE_BACKUP:/srv/restic/minha-vps"
export RESTIC_PASSWORD_FILE="/root/.restic-senha"
```

### Armazenamento compatível com S3

Serve qualquer provedor que fale o protocolo S3, ou um MinIO seu em outro servidor, como em [instalar MinIO na VPS](https://streethosting.com.br/guias/vps/instalar-minio-vps). Crie uma chave de acesso restrita ao bucket de backup.

```
# /root/.restic-env  (chmod 600)
export RESTIC_REPOSITORY="s3:https://s3.seu-provedor.com/nome-do-bucket/minha-vps"
export RESTIC_PASSWORD_FILE="/root/.restic-senha"
export AWS_ACCESS_KEY_ID="SUA_CHAVE_DE_ACESSO"
export AWS_SECRET_ACCESS_KEY="SEU_SEGREDO"
```

Com o arquivo pronto, inicialize o repositório uma única vez. A partir daí, cada backup vira um snapshot que você pode restaurar de forma independente.

```
sudo chmod 600 /root/.restic-env
sudo bash -c 'source /root/.restic-env && restic init'
```

## Script de backup

O script faz quatro coisas em ordem: gera os dumps, envia o backup, aplica a retenção e avisa um monitor que terminou. Com `set -euo pipefail`, qualquer erro interrompe a execução antes do aviso final, e é esse silêncio que vira alerta.

```
#!/usr/bin/env bash
# /usr/local/sbin/backup-restic.sh
set -euo pipefail
umask 077  # dumps e arquivos criados aqui ficam legíveis só pelo root
source /root/.restic-env

# 1. dumps dos bancos (deixe só o que a VPS usa)
mkdir -p /var/backups/db
sudo -u postgres pg_dump -Fc app > /var/backups/db/app.dump
# mariadb-dump --single-transaction --routines --all-databases > /var/backups/db/mariadb.sql

# 2. backup para o repositório externo
restic backup /etc /srv /opt /var/backups/db \
  --exclude-caches \
  --exclude "node_modules" \
  --tag diario

# 3. retenção
restic forget --tag diario --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

# 4. avisa o monitor que deu tudo certo
curl -fsS -m 10 "https://kuma.seu-dominio.com.br/api/push/SEU_TOKEN?status=up&msg=OK" > /dev/null
```

```
sudo chmod 700 /usr/local/sbin/backup-restic.sh
sudo /usr/local/sbin/backup-restic.sh
```

> **Dica**
>
> Para bancos de dados, gere um dump antes do backup. Copiar o arquivo do banco em uso pode resultar num snapshot inconsistente. O `pg_dump` e o `mariadb-dump --single-transaction` geram uma cópia coerente sem parar a aplicação.

A última linha usa o monitor Push do Uptime Kuma: se o script falhar ou nem rodar, a chamada não chega e o alerta dispara. Como criar esse monitor está em [monitoramento da VPS com Uptime Kuma](https://streethosting.com.br/guias/vps/monitoramento-vps-com-uptime-kuma). Configure o intervalo do monitor um pouco acima de 24 horas para um backup diário.

## Agendar com cron

Adicione o script ao cron para rodar em horário de baixo uso, como de madrugada. Se ainda não domina o agendamento, veja [cron e tarefas agendadas na VPS](https://streethosting.com.br/guias/vps/configurar-cron-tarefas-agendadas-vps). Um arquivo em `/etc/cron.d` deixa a rotina visível e versionável:

```
# /etc/cron.d/backup-restic
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# backup diário às 3h30
30 3 * * * root flock -n /run/backup-restic.lock /usr/local/sbin/backup-restic.sh >> /var/log/backup-restic.log 2>&1

# domingo às 5h: confere a integridade lendo 10% dos dados, sorteados
0 5 * * 0 root source /root/.restic-env && restic check --read-data-subset=10\% >> /var/log/backup-restic.log 2>&1
```

O `flock -n` impede que um backup comece enquanto o anterior ainda roda, o que acontece quando o volume cresce ou o destino fica lento. A checagem semanal lê 10% dos dados, sorteados a cada execução, e ao longo das semanas detecta corrupção no destino antes que você precise dele. Na linha de comando o valor é só `10%`; no crontab, a barra invertida antes do símbolo é obrigatória, porque o cron transforma porcentagem sem escape em quebra de linha. Monitore o log para detectar falhas antes que vire emergência.

## Retenção com forget e prune

Sem retenção, o repositório cresce para sempre. O `forget` decide quais snapshots ficam, e o `prune` apaga os dados que nenhum snapshot restante usa. A política do script funciona assim:

- **keep daily 7:** o último snapshot de cada um dos 7 dias mais recentes que tiveram backup.
- **keep weekly 4:** o último de cada uma das 4 semanas mais recentes.
- **keep monthly 6:** o último de cada um dos 6 meses mais recentes.

São até 17 pontos de restauração cobrindo meio ano. Por causa da deduplicação, isso não ocupa 17 vezes o tamanho dos dados: cada snapshot só acrescenta o que mudou. Antes de alterar a política, veja o que seria removido:

```
sudo bash -c 'source /root/.restic-env && restic forget --tag diario --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run'
sudo bash -c 'source /root/.restic-env && restic stats --mode raw-data'
```

Em repositórios grandes, o prune é a etapa mais pesada. Se ele começar a atrasar o backup, tire o `--prune` do script diário e rode o prune uma vez por semana, no cron. E mantenha os caminhos do backup estáveis: o forget agrupa snapshots por máquina e por lista de pastas, e mudar a lista cria um grupo novo com retenção própria.

## Testar a restauração

O teste de restauração é o que separa um backup real de uma falsa sensação de segurança. Uma vez por mês, restaure uma pasta e um banco numa área temporária e compare:

```
sudo -i
source /root/.restic-env
restic snapshots
restic ls latest /etc/nginx

# restaura só uma pasta num diretório de teste
restic restore latest --target /tmp/restore-teste --include /etc/nginx
diff -r /etc/nginx /tmp/restore-teste/etc/nginx

# restaura o dump do banco e carrega numa base de teste
restic restore latest --target /tmp/restore-teste --include /var/backups/db
sudo -u postgres createdb app_teste
sudo -u postgres pg_restore -d app_teste < /tmp/restore-teste/var/backups/db/app.dump
```

De tempos em tempos, faça o ensaio completo: contrate uma VPS nova, instale o restic, aponte para o mesmo repositório usando a senha guardada no gerenciador, restaure tudo e suba a aplicação. Anote quanto tempo levou. Esse ensaio prova que a senha realmente está fora da VPS, que a chave de acesso ao destino funciona numa máquina nova e que o passo a passo está escrito. Quando precisar mover algum arquivo avulso entre as máquinas durante o teste, [SCP e rsync](https://streethosting.com.br/guias/vps/transferir-arquivos-vps-scp-rsync) resolvem.

- [ ] Snapshots criados em destino externo
- [ ] Senha do repositório guardada fora da VPS
- [ ] Política de retenção controlando o espaço
- [ ] Monitor Push avisando quando o backup não roda
- [ ] Restauração testada num ambiente separado

## Onde guardar o backup

As VPS da StreetHosting não têm snapshot automático nem serviço de backup incluso: a rotina deste guia é o que protege os seus dados, e vale montar no mesmo dia em que a VPS entra em produção. A VPS em si roda em São Paulo, com acesso root, AntiDDoS e ativação em até 60 segundos, então o restic funciona sem nenhuma restrição.

Para o destino externo, uma segunda VPS dedicada a guardar backups é o caminho mais simples com SFTP. Como o restic deduplica, repositórios de algumas dezenas de GB cabem numa VPS Xeon de 40 GB de NVMe por R$ 43,00 por mês ou de 80 GB por R$ 77,00. Uma ressalva honesta: duas VPS no mesmo datacenter protegem contra perda da máquina, invasão e erro humano, mas não contra um problema que atinja o local inteiro. Para a cópia fora do local que a regra 3 2 1 pede, mantenha também um repositório em armazenamento compatível com S3 em outra região ou num servidor em outro endereço. Compare os planos na [página de VPS](https://streethosting.com.br/vps).

> **Dica**
>
> Pense também em quem invade a VPS. Com root, o invasor lê o `/root/.restic-env` e pode apagar o repositório junto com o servidor. Para fechar essa porta, use um destino que a VPS consiga gravar mas não apagar: o rest server do restic em modo `--append-only` ou uma chave S3 sem permissão de exclusão. Nesse arranjo, o forget e o prune saem do script da VPS e passam a rodar a partir de outra máquina de confiança, com credenciais que a VPS não conhece.

## Perguntas frequentes

### Por que enviar o backup para fora da VPS?

Porque backup na mesma máquina não protege contra perda do servidor, ransomware ou exclusão acidental. Guardar uma cópia externa, em outro servidor ou num armazenamento compatível com S3, segue a regra de manter cópias em locais diferentes.

### O restic criptografa os backups?

Sim. O restic criptografa tudo com a senha do repositório antes de enviar ao destino. Por isso, guarde essa senha em local seguro e separado da VPS. Sem ela, nem você recupera os dados.

### Como evito o backup encher o disco?

Com a política de retenção. O forget com opções como keep daily, keep weekly e keep monthly define quais snapshots ficam, e o prune apaga os dados que nenhum snapshot usa mais, controlando o espaço no destino.

### Com que frequência devo fazer backup da VPS?

Depende de quanto dado você aceita perder. Um backup diário atende a maioria dos projetos. Bancos com muita escrita pedem dumps a cada poucas horas, e arquivos de configuração podem entrar em todo backup porque ocupam quase nada.

### Backup automático dispensa teste?

Não. Backup que nunca foi restaurado não é confiável. Restaure uma pasta todo mês e faça uma recuperação completa numa VPS nova de tempos em tempos para garantir que os dados voltam de verdade quando você precisar.

## Guias relacionados

- [Estratégia de backup 3 2 1 para servidores](https://streethosting.com.br/guias/infraestrutura/estrategia-backup-3-2-1-servidor.md)
- [Como agendar tarefas na VPS com cron](https://streethosting.com.br/guias/vps/configurar-cron-tarefas-agendadas-vps.md)
- [Como instalar MinIO na VPS: S3, HTTPS e alternativas](https://streethosting.com.br/guias/vps/instalar-minio-vps.md)
- [Como instalar Uptime Kuma na VPS e monitorar sites e portas](https://streethosting.com.br/guias/vps/monitoramento-vps-com-uptime-kuma.md)
- [Como transferir arquivos para a VPS com SCP e rsync](https://streethosting.com.br/guias/vps/transferir-arquivos-vps-scp-rsync.md)

## Produtos citados

- https://streethosting.com.br/vps
- https://streethosting.com.br/vps/xeon

## Dados estruturados

```json
[
  {
    "@context": "https://schema.org",
    "@type": [
      "Article",
      "TechArticle"
    ],
    "headline": "Backup automático da VPS com restic e cron: estratégia, retenção e restauração",
    "name": "Como configurar backup automático da VPS com restic e cron",
    "abstract": "Backup que depende de você lembrar não funciona. Com restic e cron você cria snapshots criptografados, envia para fora da VPS, controla a retenção e testa a restauração sem esforço diário.",
    "description": "Configure backup automático da VPS com restic e cron: destino externo, frequência, retenção com forget e o teste de restauração que prova que funciona.",
    "datePublished": "2026-06-17",
    "dateModified": "2026-09-28",
    "author": {
      "@type": "Organization",
      "name": "Equipe StreetHosting"
    },
    "publisher": {
      "@type": "Organization",
      "name": "StreetHosting",
      "url": "https://streethosting.com.br"
    },
    "inLanguage": "pt-BR",
    "mainEntityOfPage": {
      "@type": "WebPage",
      "@id": "https://streethosting.com.br/guias/vps/automatizar-backup-vps-restic-cron"
    }
  },
  {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
      {
        "@type": "Question",
        "name": "Por que enviar o backup para fora da VPS?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Porque backup na mesma máquina não protege contra perda do servidor, ransomware ou exclusão acidental. Guardar uma cópia externa, em outro servidor ou num armazenamento compatível com S3, segue a regra de manter cópias em locais diferentes."
        }
      },
      {
        "@type": "Question",
        "name": "O restic criptografa os backups?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Sim. O restic criptografa tudo com a senha do repositório antes de enviar ao destino. Por isso, guarde essa senha em local seguro e separado da VPS. Sem ela, nem você recupera os dados."
        }
      },
      {
        "@type": "Question",
        "name": "Como evito o backup encher o disco?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Com a política de retenção. O forget com opções como keep daily, keep weekly e keep monthly define quais snapshots ficam, e o prune apaga os dados que nenhum snapshot usa mais, controlando o espaço no destino."
        }
      },
      {
        "@type": "Question",
        "name": "Com que frequência devo fazer backup da VPS?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Depende de quanto dado você aceita perder. Um backup diário atende a maioria dos projetos. Bancos com muita escrita pedem dumps a cada poucas horas, e arquivos de configuração podem entrar em todo backup porque ocupam quase nada."
        }
      },
      {
        "@type": "Question",
        "name": "Backup automático dispensa teste?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Não. Backup que nunca foi restaurado não é confiável. Restaure uma pasta todo mês e faça uma recuperação completa numa VPS nova de tempos em tempos para garantir que os dados voltam de verdade quando você precisar."
        }
      }
    ]
  }
]
```
