Restic ou BorgBackup: qual usar no backup Linux?

Restic vs BorgBackup, em um parágrafo

Restic e BorgBackup fazem o mesmo trabalho principal: backups incrementais, encriptados e com deduplicação de um servidor Linux. A diferença que determina a escolha é o destino do backup. O Restic comunica nativamente com S3 e outras APIs de armazenamento de objetos, por isso um bucket é um destino de primeira classe sem ser necessário instalar nada no outro extremo. O Borg precisa do programa borg instalado na máquina que contém o repositório, porque um repositório Borg é disponibilizado por um processo, não por um sistema de ficheiros ou uma API. Se o destino for armazenamento de objetos, essa diferença já determina a escolha. Se o destino for outro sistema Linux sob o seu controlo, o Borg é uma opção e costuma ser mais rápido.

As restantes diferenças são menores. Ambos dividem os ficheiros em blocos com divisão baseada no conteúdo, por isso um diretório de 40 GB que sofreu alterações de 200 MB envia aproximadamente 200 MB. Ambos encriptam os dados no cliente. Ambos montam um snapshot com FUSE (filesystem in userspace), para que possa copiar um ficheiro para fora. Em julho de 2026, o Restic está na versão 0.19.1 e a série estável do Borg é a 1.4, na versão 1.4.5. O Borg 2.0 está em beta há anos e continua marcado apenas como testing, por isso a versão 1.4 é a que deve implementar atualmente.

A diferença real está no modelo de repositório

Um repositório restic é um diretório de ficheiros: config, keys/, snapshots/, index/ e data/, cheio de ficheiros pack. Não é necessário mais nada para o ler. É por isso que o restic pode utilizar tantos backends. Qualquer armazenamento que consiga colocar, obter, listar e eliminar blobs pode alojar um repositório restic. É assim que um único binário suporta caminhos locais, SFTP, o seu próprio servidor REST, S3, Backblaze B2, Azure, Google Cloud Storage e qualquer destino acessível pelo rclone.

Um repositório Borg também é constituído por ficheiros no disco, mas o Borg nunca comunica com ele através de um transporte simples. Para um repositório remoto, o Borg inicia borg serve no sistema remoto através de SSH e utiliza o seu próprio protocolo para comunicar com esse processo. O lado do servidor executa trabalho real: mantém o repositório, aplica a transação e responde a consultas sobre os índices. É por isso que o Borg não tem um backend S3 e que o projeto não adicionou um. Não existe nenhum processo para executar dentro de um bucket.

Este único facto de conceção produz a maioria das diferenças práticas abaixo.

# restic: the repository is a URL, and the backend is part of it
restic -r /srv/restic-repo init
restic -r sftp:backup@198.51.100.20:/srv/restic-repo init
restic -r s3:s3.us-east-1.amazonaws.com/my-backup-bucket init

# borg: a local path, or user@host:path, with borg installed on that host
borg init --encryption=repokey-blake2 /srv/borg/vps1
borg init --encryption=repokey-blake2 backup@198.51.100.20:/srv/borg/vps1

Criptografia: uma delas pode ser desativada

O Restic está sempre encriptado. Não existe um modo sem encriptação. restic init pede uma palavra-passe, deriva uma chave a partir dela com scrypt e todos os ficheiros pack escritos depois disso são encriptados e autenticados. Se perder a palavra-passe, os dados ficam irrecuperáveis, porque, por definição, não existe um mecanismo de recuperação.

No Borg, a encriptação é uma escolha feita durante a criação do repositório, e essa escolha é permanente. borg init --encryption=repokey mantém a chave encriptada dentro do repositório, por isso a passphrase é suficiente para restaurar os dados. --encryption=keyfile mantém a chave no cliente, em ~/.config/borg/keys/, por isso alguém que roube o repositório completo continua sem acesso aos dados. Nesse caso, é necessário fazer uma cópia de segurança separada desse ficheiro de chave; caso contrário, os arquivos ficam ilegíveis. Cada modo tem uma variante -blake2 que autentica com BLAKE2b em vez de HMAC-SHA256, o que é mais rápido em hardware sem aceleração SHA. --encryption=none também existe e é uma opção válida quando o repositório está num disco encriptado que lhe pertence.

A regra prática é: repokey-blake2 para uma cópia de segurança normal de um servidor, keyfile quando o repositório está num local em que não confia totalmente e nunca none numa máquina alugada.

Compressão e por que o restic a introduziu mais tarde

O Borg oferece compressão desde o início. O padrão é lz4, escolhido por ser suficientemente rápido para permanecer ativo em todos os casos. zstd aceita níveis de 1 a 22 e usa 3 por padrão. zlib e lzma existem para os casos em que o tamanho em bytes é mais importante do que o tempo. auto aplica uma heurística a cada bloco, para evitar comprimir novamente dados que já estão comprimidos.

borg create --compression zstd,3 --stats --progress \
  /srv/borg/vps1::'{hostname}-{now}' /etc /home /srv

O restic não oferecia compressão até ao formato de repositório 2, que requer o restic 0.14.0 ou posterior. Atualmente, o formato 2 é o padrão para um repositório novo, e a compressão é configurada com --compression usando os valores auto, off ou max. Um repositório antigo no formato 1 permanece sem compressão até ser migrado. Portanto, se o seu repositório restic for anterior à versão 0.14 e nunca tiver sido migrado, continua a ocupar o tamanho total com texto, logs e dumps de bases de dados.

Destinos remotos: S3 versus SSH

É neste ponto que a escolha costuma ser feita.

O restic a aceder ao S3 precisa de credenciais no ambiente e de mais nada em execução noutro local. O mesmo padrão funciona com um bucket que aloje por sua conta. Esta é uma combinação comum: execute o MinIO para disponibilizar uma API S3 no seu próprio VPS e aponte o restic para esse serviço.

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export RESTIC_REPOSITORY=s3:https://objects.example.com/backups
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /home /srv --exclude-caches

O Borg a aceder a um repositório remoto precisa de SSH e de uma instalação do Borg no servidor remoto. A versão instalada nesse servidor também tem de ser compatível com o cliente. Isto cria uma limitação quando o servidor remoto não é administrado por si. Não cria qualquer problema quando o servidor remoto é um segundo servidor que já administra. Nesse caso, oferece o controlo mais forte contra ransomware que qualquer uma das duas ferramentas disponibiliza: uma chave SSH apenas para anexar dados. Force a chave a executar borg serve. Assim, o cliente pode adicionar arquivos, mas não os pode eliminar. Um sistema comprometido não consegue apagar o próprio histórico.

command="borg serve --append-only --restrict-to-path /srv/borg/vps1",restrict ssh-ed25519 AAAA...

O restic só tem um equivalente quando executa o seu próprio servidor REST, que suporta um modo apenas para anexar dados. Com S3 simples, obtém o mesmo efeito através da política do bucket ou do object lock. Essa proteção é responsabilidade do fornecedor, não do restic. Restrinja também o transporte. A configuração SSH deve receber o mesmo cuidado que qualquer outro login: aplique SSH apenas com chave e uma entrada authorized_keys restrita à conta de backup.

Velocidade: o que cada desenho implica

Nenhum dos projetos publica um benchmark em que deva confiar para os seus próprios dados. Por isso, raciocine a partir do mecanismo.

O Borg através de SSH é rápido numa ligação com latência porque o lado do servidor é inteligente. O cliente faz uma pergunta, o processo remoto borg serve responde a partir do índice do repositório e a transação é confirmada num único local. As pesquisas de chunks não se transformam numa ida e volta pela rede para cada ficheiro pequeno.

O Restic em armazenamento de objetos não tem um lado do servidor. Por isso, tem de construir a sua visão a partir de ficheiros de índice e ficheiros pack que obtém através de HTTP. Para manter controlado o número de pedidos, agrupa muitos chunks pequenos em ficheiros pack maiores antes de os carregar. Também mantém uma cache local em ~/.cache/restic para que a execução seguinte não tenha de obter novamente o índice completo. Se eliminar essa cache, a cópia de segurança seguinte será lenta enquanto a reconstrói. Numa ligação com elevada latência e milhões de ficheiros pequenos, este é o cenário em que o Restic parece mais lento do que o Borg com os mesmos dados.

Num disco local ou numa LAN rápida, a diferença diminui sobretudo, e ambas as ferramentas acabam limitadas pela velocidade a que conseguem ler e calcular o hash da origem.

Bloqueio e cópia de segurança de várias máquinas

O Borg 1.4 obtém um bloqueio exclusivo no repositório durante toda a operação. Dois clientes não conseguem escrever no mesmo repositório ao mesmo tempo: o segundo espera e depois falha devido ao tempo limite do bloqueio. O padrão suportado é usar um repositório por cliente. Isso também significa que a deduplicação só ocorre dentro do repositório de uma máquina. Assim, dez servidores quase idênticos armazenam dez cópias do mesmo sistema base.

O Restic permite que vários clientes façam cópias de segurança no mesmo repositório ao mesmo tempo, porque uma cópia de segurança obtém um bloqueio partilhado e apenas operações de manutenção, como prune, obtêm um bloqueio exclusivo. Dez servidores semelhantes que usem o mesmo repositório Restic fazem deduplicação entre si, e o segundo servidor em diante normalmente armazena muito pouco. O custo é o raio de impacto: existe uma única palavra-passe e um único repositório com todo o conteúdo. Se perder a palavra-passe, perde os dados dos dez servidores.

Retenção: forget mais prune versus prune mais compact

As duas ferramentas separam "decidir o que manter" de "recuperar o espaço", e em ambas é necessário executar a segunda etapa.

restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune
restic check

borg prune --list --glob-archives '{hostname}-*' \
  --keep-daily=7 --keep-weekly=4 --keep-monthly=6 /srv/borg/vps1
borg compact /srv/borg/vps1

A armadilha é a mesma nas duas ferramentas, e vale a pena explicá-la claramente. No Borg, borg prune remove arquivos, mas não liberta espaço em disco por si só. O espaço só é recuperado quando borg compact é executado. Por isso, uma tarefa do cron que faz prune e nunca executa compact deixa o repositório a crescer indefinidamente, embora a lista de arquivos permaneça curta. No restic, forget sem --prune apenas remove referências a snapshots, e os dados permanecem até ser executado um prune.

Execute restic check depois do prune. O comando verifica as estruturas do repositório e informa se algo está danificado. Isto é muito melhor do que descobrir o problema durante uma restauração.

Restauração: o único teste que conta

Ambas as ferramentas montam um snapshot para que possa navegá-lo. Esta é a forma mais rápida de recuperar um ficheiro.

restic snapshots
restic restore latest --target /tmp/restore --include /etc/nginx
restic mount /mnt/restore

borg list /srv/borg/vps1
borg extract --list /srv/borg/vps1::vps1-2026-07-30T02:00:00 etc/nginx
borg mount /srv/borg/vps1::vps1-2026-07-30T02:00:00 /mnt/restore

Tenha em atenção o formato do caminho em borg extract. Os caminhos dentro de um arquivo são armazenados sem a barra inicial. Por isso, etc/nginx está correto, enquanto /etc/nginx não corresponde a nada e não extrai nada, sem apresentar um erro que explique o motivo. A extração também escreve no diretório de trabalho atual. Por isso, mude primeiro para um diretório temporário. Caso contrário, irá substituir ficheiros ativos por versões antigas.

Uma restauração que termina sem erro ainda não é uma prova. A aplicação tem a sua própria definição de restauração completa. Por exemplo, um servidor Immich reconstruído a partir de uma cópia do diretório de dados do Postgres pode voltar com todas as fotografias presentes no disco e com uma linha do tempo vazia. É exatamente esta falha que fazer backup e restaurar o Immich tem de contornar.

Independentemente da ferramenta escolhida, o agendamento é apenas metade do trabalho. Execute periodicamente uma restauração num diretório temporário e monitorize-a de facto, tal como o guia completo em guia de backup do restic para um VPS faz com um temporizador do systemd.

Qual escolher para cada tarefa

Escolha restic quando o destino for armazenamento de objetos, quando quiser usar um único binário e não instalar software no destino remoto, quando várias máquinas deverem deduplicar dados entre si ou quando a pessoa que fará a restauração puder não ser você. É um único binário estático que usa uma URL para um repositório, e isso é difícil de superar do ponto de vista operacional.

Escolha Borg quando o destino for uma máquina Linux que você controla, quando a ligação tiver latência e o conjunto de dados contiver milhões de ficheiros pequenos, quando quiser usar a chave SSH append only como controlo contra ransomware ou quando quiser ajustar a compressão por tarefa. É a ferramenta mais antiga, a sua série estável evolui lentamente e, em software de backup, isso é uma vantagem.

As duas são respostas corretas. A resposta errada é aquela que você nunca testa. Se já cria dumps ao nível da aplicação, mantenha-os: o padrão em a configuração do Nextcloud no Docker com dumps da base de dados aplica-se a qualquer uma das ferramentas, porque um ficheiro de base de dados ativo copiado num momento aleatório não é um backup de uma base de dados.

FAQ

O restic ou o BorgBackup é mais rápido?

Num disco local ou numa LAN rápida, o desempenho é semelhante, e ambos acabam limitados pela velocidade de leitura e de cálculo de hashes na origem. O Borg tende a ser mais rápido através de uma ligação SSH com latência elevada e muitos ficheiros pequenos, porque um processo borg serve no lado remoto responde às consultas ao índice sem uma viagem de rede por chunk. O restic tende a ser mais rápido quando o destino é armazenamento de objetos, onde o Borg não pode funcionar diretamente.

O BorgBackup pode fazer cópias de segurança para S3 ou Backblaze B2?

Não diretamente. Um repositório Borg é servido pelo processo borg serve através de SSH, e não existe um processo desse tipo dentro de um bucket. É possível contornar esta limitação montando o armazenamento de objetos como um sistema de ficheiros com rclone, mas o projeto Borg não recomenda essa abordagem, porque uma montagem que seja interrompida a meio de uma transação pode corromper o repositório. Se precisar de armazenamento de objetos, use o restic.

Posso executar ambas as ferramentas sobre os mesmos dados?

Sim, e algumas pessoas fazem isso: Borg para um segundo servidor, para permitir uma restauração local rápida, e restic para armazenamento de objetos, para manter uma cópia externa. As ferramentas não partilham nada, por isso o custo de leitura e cálculo de hashes é pago duas vezes, e existem duas palavras-passe para armazenar em segurança. Faça isto apenas se tiver testado ambas as restaurações.

O que acontece se eu perder a palavra-passe do repositório?

Os dados ficam irrecuperáveis em ambas as ferramentas. O restic deriva a chave a partir da palavra-passe com scrypt e não existe nenhum mecanismo de bypass. No modo repokey do Borg, a chave cifrada é armazenada dentro do repositório, por isso basta a frase-passe para restaurar. No modo keyfile, também precisa do ficheiro de chave de ~/.config/borg/keys/. Guarde a palavra-passe num gestor de palavras-passe que não esteja no servidor do qual é feita a cópia de segurança e exporte a chave Borg com borg key export se usar keyfile.

Devo esperar pelo Borg 2.0?

Não. Em julho de 2026, o Borg 2.0 ainda está em beta, na versão 2.0.0b22, e o projeto classifica-o apenas como destinado a testes. A série estável é a 1.4, atualmente na versão 1.4.5. Comece agora com a 1.4. O Borg 2 altera o formato do repositório e disponibiliza um processo de atualização documentado, por isso começar hoje não o deixa preso à versão atual.