Restic ou BorgBackup: qual usar no Linux?

Restic vs BorgBackup em um parágrafo

Restic e BorgBackup fazem o mesmo trabalho principal: backups incrementais, criptografados e com deduplicação de um servidor Linux. A diferença que determina a escolha é onde o backup é armazenado. O Restic oferece suporte nativo ao S3 e a outras APIs de armazenamento de objetos, portanto um bucket é um destino de primeira classe sem exigir nada instalado no outro lado. O Borg precisa que o programa borg esteja 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 arquivos ou uma API. Se o destino for armazenamento de objetos, essa já é a resposta. Se o destino for outro servidor Linux sob seu controle, o Borg é uma opção e costuma ser mais rápido.

Todo o restante são diferenças menores. Os dois dividem os arquivos usando chunking definido pelo conteúdo, portanto um diretório de 40 GB que sofreu alterações de 200 MB envia aproximadamente 200 MB. Os dois criptografam os dados no cliente. Os dois montam um snapshot com FUSE (filesystem in userspace), para que você possa copiar um arquivo específico. 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 ainda é marcado apenas como testing, portanto a versão 1.4 é a que você deve implantar hoje.

O modelo do repositório é a diferença real

Um repositório do restic é um diretório de arquivos: config, keys/, snapshots/, index/ e data/, cheio de arquivos pack. Nada mais é necessário para lê-lo. Por isso, o restic pode usar tantos backends. Qualquer armazenamento que consiga gravar, obter, listar e excluir blobs pode armazenar um repositório do restic. É assim que um único binário oferece suporte a caminhos locais, SFTP, seu próprio servidor REST, S3, Backblaze B2, Azure, Google Cloud Storage e tudo o que o rclone conseguir acessar.

Um repositório do Borg também consiste em arquivos no disco, mas o Borg nunca se comunica com ele por meio de um transporte simples. Para um repositório remoto, o Borg inicia borg serve no outro lado por SSH e usa seu próprio protocolo para se 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 índices. Por isso, o Borg não tem backend S3 e o projeto não adicionou um. Não há um processo para executar dentro de um bucket.

Esse único fato de projeto 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 é sempre criptografado. Não existe um modo sem criptografia. restic init solicita uma senha, deriva uma chave a partir dela com scrypt, e todo arquivo pack gravado depois disso é criptografado e autenticado. Se você perder a senha, os dados serão perdidos, porque não existe um mecanismo de recuperação por decisão de projeto.

O Borg permite escolher a criptografia na criação do repositório, e essa escolha é permanente. borg init --encryption=repokey mantém a chave criptográfica dentro do repositório, portanto somente a frase secreta é suficiente para restaurar os dados. --encryption=keyfile mantém a chave no cliente, em ~/.config/borg/keys/, portanto alguém que roubar o repositório inteiro ainda não terá acesso aos dados. Nesse caso, você precisa fazer backup desse arquivo de chave separadamente; caso contrário, seus arquivos de backup ficarão 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 para SHA. --encryption=none também existe e é uma opção válida quando o repositório fica em um disco criptografado que pertence a você.

A regra prática é: use repokey-blake2 para um backup normal de servidor, keyfile quando o repositório estiver em um local em que você não confia completamente e nunca use none em uma máquina alugada.

Compressao e por que o restic demorou a adicionar esse recurso

O Borg oferece compressao desde o inicio. O padrao e lz4, escolhido porque e suficientemente rapido para permanecer ativado em todos os casos. zstd aceita os niveis 1 a 22 e usa 3 por padrao. zlib e lzma existem para situacoes em que a economia de bytes e mais importante que o tempo. auto aplica uma heuristica a cada chunk para evitar que dados ja comprimidos sejam comprimidos novamente.

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

O restic nao oferecia compressao ate o formato de repositorio 2, que requer o restic 0.14.0 ou mais recente. Atualmente, o formato 2 e o padrao para novos repositorios, e a compressao e configurada com --compression usando os valores auto, off ou max. Um repositorio antigo no formato 1 permanece sem compressao ate que voce o migre. Portanto, se o seu repositorio do restic foi criado antes da versao 0.14 e nunca foi migrado, voce ainda ocupa o tamanho completo para textos, logs e dumps de banco de dados.

Destinos remotos: S3 versus SSH

É aqui que a escolha geralmente é feita.

O restic acessando o S3 precisa de credenciais no ambiente e de nenhum outro processo em execução em outro local. O mesmo padrão funciona com um bucket que você hospeda, uma combinação comum: execute MinIO para uma API S3 no seu próprio VPS e aponte o restic para ele.

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 acessando um repositório remoto precisa de SSH e de uma instalação do Borg no outro lado. A versão instalada lá também precisa ser compatível com a do cliente. Isso é uma limitação quando o outro lado não está sob sua administração. Não é uma limitação quando o outro lado é um segundo servidor que você já administra. Nesse caso, você obtém a proteção mais forte contra ransomware que qualquer uma das duas ferramentas oferece: uma chave SSH somente para adição. Force a chave a executar borg serve. Assim, o cliente pode adicionar arquivos, mas não pode excluí-los. Portanto, uma máquina comprometida não pode apagar o próprio histórico.

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

O restic tem um equivalente somente quando você executa o próprio servidor REST, que oferece um modo somente para adição. Com S3 puro, você obtém o mesmo efeito usando uma política de bucket ou o object lock. Essa configuração é responsabilidade do provedor, não do restic. Restrinja também o transporte, porque o acesso SSH exige o mesmo cuidado que qualquer outro login: aplique SSH somente com chave e uma entrada authorized_keys restrita à conta de backup.

Velocidade: o que cada projeto implica

Nenhum dos dois projetos publica um benchmark em que você deva confiar para os seus próprios dados. Portanto, use o mecanismo para avaliar o desempenho.

Borg sobre SSH é rápido em um link com latência porque o lado do servidor é inteligente. O cliente faz uma consulta, o processo remoto borg serve responde com base no índice do repositório, e a transação é confirmada em um único local. As consultas de chunks não se transformam em uma viagem de rede para cada arquivo pequeno.

O Restic em armazenamento de objetos não tem processamento no lado do servidor. Por isso, precisa construir sua visão a partir de arquivos de índice e arquivos pack obtidos por HTTP. Para manter uma quantidade razoável de requisições, ele reúne muitos chunks pequenos em arquivos pack maiores antes do upload. Ele também mantém um cache local em ~/.cache/restic para que a próxima execução não precise obter novamente todo o índice. Se você excluir esse cache, o próximo backup será lento enquanto ele o reconstrói. Em um link com alta latência e milhões de arquivos pequenos, esse é o cenário em que o restic parece mais lento que o Borg com os mesmos dados.

Em um disco local ou em uma LAN rápida, a diferença diminui principalmente. As duas ferramentas acabam limitadas pela velocidade com que conseguem ler e calcular o hash da origem.

Bloqueio e backup 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 podem gravar no mesmo repositório ao mesmo tempo: o segundo aguarda e depois falha devido ao tempo limite do bloqueio. O padrão compatível é usar um repositório por cliente. Isso também significa que a deduplicação ocorre somente dentro do repositório de uma máquina. Portanto, dez servidores quase idênticos armazenam dez cópias do mesmo sistema básico.

O Restic permite que vários clientes façam backup no mesmo repositório ao mesmo tempo, porque um backup obtém um bloqueio compartilhado e somente tarefas de manutenção, como prune, obtêm um bloqueio exclusivo. Dez servidores semelhantes apontados para um único repositório do Restic fazem deduplicação entre si, e o segundo servidor geralmente armazena muito pouco. O custo é o raio de impacto: uma senha e um repositório contendo tudo. Se a senha for perdida, todos os dez backups serão perdidos.

Retenção: esquecer e podar versus podar e compactar

As duas ferramentas separam "decidir o que manter" de "recuperar o espaço", e ambas exigem que você execute 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 explicá-la claramente. No Borg, borg prune remove arquivos, mas não libera espaço em disco por si só. O espaço é recuperado quando borg compact é executado. Portanto, uma tarefa do cron que poda arquivos, mas nunca compacta, deixa o repositório crescer indefinidamente enquanto a lista de arquivos permanece curta. No restic, forget sem --prune apenas remove as referências aos snapshots, e os dados permanecem até que uma poda seja executada.

Execute restic check após a poda. Esse comando verifica as estruturas do repositório e informa se algo está danificado. Isso é muito melhor do que descobrir o problema durante uma restauração.

A restauração é o único teste que realmente importa

As duas ferramentas montam um snapshot para que você possa navegá-lo. Essa é a forma mais rápida de recuperar um arquivo.

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

Observe o formato do caminho em borg extract. Os caminhos dentro de um arquivo compactado 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. Nenhum erro informa o motivo. A extração também grava no diretório de trabalho atual. Portanto, mude primeiro para um diretório temporário. Caso contrário, você poderá sobrescrever arquivos ativos com versões antigas.

Independentemente da ferramenta escolhida, o agendamento é apenas metade do trabalho. Execute uma restauração em um diretório temporário usando um agendador que você realmente monitore. Faça isso da mesma forma que o guia completo de backup do restic para uma VPS usa um timer do systemd.

Qual ferramenta é melhor para cada tarefa

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

Escolha o Borg quando o destino for um servidor Linux sob seu controle, quando o link tiver latência e o conjunto de dados contiver milhões de arquivos pequenos, quando você quiser usar a chave SSH somente para anexação como proteção contra ransomware ou quando quiser ajustar a compactação para cada tarefa. É a ferramenta mais antiga, sua série estável avança lentamente e, em software de backup, isso é uma vantagem.

As duas opções são válidas. A opção errada é aquela que você nunca testa. Se você já faz dumps no nível da aplicação, continue fazendo isso: o padrão em a configuração do Nextcloud no Docker com dumps do banco de dados aplica-se a qualquer uma das ferramentas, porque um arquivo de banco de dados copiado em um momento aleatório, enquanto está em uso, não é um backup do banco de dados.

FAQ

O restic ou o BorgBackup é mais rápido?

Em um disco local ou em uma 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 em uma conexão SSH de alta latência com muitos arquivos pequenos, porque um processo borg serve no lado remoto responde às consultas de índice sem uma viagem de rede por bloco. O restic tende a ser mais rápido quando o destino é um armazenamento de objetos, ao qual o Borg não pode se conectar diretamente.

O BorgBackup pode fazer backup para S3 ou Backblaze B2?

Não diretamente. Um repositório Borg é disponibilizado pelo processo borg serve via SSH, e nenhum processo desse tipo é executado dentro de um bucket. Como alternativa, algumas pessoas montam o armazenamento de objetos como um sistema de arquivos com rclone. O projeto Borg não recomenda isso, porque uma montagem que seja interrompida no meio de uma transação pode corromper o repositório. Se você precisa de armazenamento de objetos, use o restic.

Posso executar as duas ferramentas nos mesmos dados?

Sim, e algumas pessoas fazem isso: Borg em um segundo servidor para uma restauração local rápida, e restic em um armazenamento de objetos para a cópia externa. As ferramentas não compartilham nada, portanto você paga o custo de leitura e cálculo de hashes duas vezes e precisa armazenar duas senhas com segurança. Faça isso somente se tiver testado as duas restaurações.

O que acontece se eu perder a senha do repositório?

Os dados não poderão ser recuperados em nenhuma das duas ferramentas. O restic deriva a chave da senha usando scrypt, e não há como contornar isso. O Borg no modo repokey armazena a chave criptografada dentro do repositório, portanto somente a senha permite restaurar os dados. No modo keyfile, você também precisa do arquivo de chave de ~/.config/borg/keys/. Mantenha a senha em um gerenciador de senhas que não esteja no servidor do qual é feito o backup e exporte a chave do Borg com borg key export se você usar keyfile.

Devo esperar pelo Borg 2.0?

Não. Em julho de 2026, o Borg 2.0 ainda está na versão beta, em 2.0.0b22, e o projeto o classifica somente 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 oferece um caminho de atualização documentado, portanto começar hoje não fará com que você fique sem opção de migração.