Restic ou BorgBackup: qual usar no backup Linux?

Restic vs BorgBackup, num parágrafo

Restic e BorgBackup fazem o mesmo trabalho principal: backups deduplicados, encriptados e incrementais de um servidor Linux. A diferença que determina a escolha é o destino do backup. O Restic suporta nativamente S3 e outras APIs de armazenamento de objetos, por isso um bucket é um destino de primeira classe sem ser necessário instalar nada no sistema remoto. O Borg estável 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 é a resposta. Se o destino for outro sistema Linux sob o seu controlo, o Borg é uma opção e muitas vezes é mais rápido.

Tudo o resto são diferenças menores. Ambos dividem os ficheiros em blocos com segmentação definida pelo 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. Em outubro de 2026, o Restic está na versão 0.19.1 e a série estável do Borg é a 1.4, atualmente na versão 1.4.5. O Borg 2.0 está em beta há anos e continua marcado apenas como testing, por isso deve implementar a versão 1.4 atualmente.

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

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, o restic consegue utilizar tantos backends. Qualquer armazenamento que consiga gravar, obter, listar e eliminar blobs pode conter 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 que o rclone consiga alcançar.

Um repositório Borg também é composto por ficheiros em 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 comunica através do seu próprio protocolo com esse processo. O lado do servidor executa trabalho efetivo: mantém o repositório, aplica a transação e responde a consultas ao índice. É por isso que a série estável Borg 1.4 não tem backend S3. Não existe um processo para executar dentro de um bucket. O Borg 2 altera este modelo: move o armazenamento para uma nova camada chamada borgstore, e a documentação descreve URLs de repositórios sftp://, rclone:remote:path e s3: ou b2:. No entanto, o Borg 2 ainda é uma versão beta que o projeto recomenda não utilizar em produção. Por isso, para backups reais atualmente, a limitação relativa ao S3 mantém-se.

Este único facto de design produz a maior parte 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 razão o restic a recebeu mais tarde

O Borg tem compressão desde o início. A predefinição é lz4, escolhida por ser suficientemente rápida para ficar sempre ativa. zstd aceita níveis de 1 a 22 e usa 3 por predefinição. zlib e lzma destinam-se aos casos em que o tamanho em bytes é mais importante do que o tempo. auto aplica uma heurística a cada chunk, para que os dados já comprimidos não sejam comprimidos novamente.

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

O restic não tinha compressão até ao formato de repositório 2, que requer o restic 0.14.0 ou posterior. Atualmente, o formato 2 é a predefinição para um repositório novo, e a compressão é configurada com --compression usando um de cinco valores: auto (a predefinição), off, fastest, better ou max. Os modos fastest e better foram introduzidos no restic 0.19.0. Por isso, os binários mais antigos aceitam apenas auto, off e max. Um repositório antigo no formato 1 permanece sem compressão até ser migrado. Assim, se o seu repositório restic for anterior à versão 0.14 e nunca tiver sido migrado, continua a ocupar o tamanho total de textos, 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, têm 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 elevada latência e muitos ficheiros pequenos, porque um processo borg serve no lado remoto responde às consultas ao índice sem uma ida e volta de rede por chunk. O restic tende a ser mais rápido quando o destino é armazenamento de objetos, onde a versão estável do Borg não pode funcionar.

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

Não na série estável 1.4. Um repositório Borg 1.4 é servido pelo processo borg serve através de SSH, e não existe um processo desse tipo dentro de um bucket. O Borg 2 adiciona URLs de repositório s3:, b2: e rclone: através da sua camada borgstore, mas, em outubro de 2026, o Borg 2 ainda está em beta e o projeto recomenda não o utilizar em produção. Com a versão 1.4, é possível contornar esta limitação montando o armazenamento de objetos como um sistema de ficheiros com rclone. A FAQ do Borg desaconselha sistemas de ficheiros de rede para armazenar repositórios e avisa que FUSE e sistemas de ficheiros de rede podem causar lentidão ou corrupção. Se precisar de armazenamento de objetos para cópias de segurança de produção hoje, use 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 a 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 perder a palavra-passe do repositório?

Os dados ficam irrecuperáveis em ambas as ferramentas. O restic deriva a sua chave da palavra-passe com scrypt e não existe forma de contornar esse requisito. No modo repokey, o Borg armazena a chave cifrada dentro do repositório, por isso a frase-passe é suficiente para restaurar. No modo keyfile, também precisa do ficheiro de chave de ~/.config/borg/keys/. Mantenha a palavra-passe num gestor de palavras-passe que não esteja no servidor onde as cópias de segurança são armazenadas e exporte a chave do Borg com borg key export se usar keyfile.

Devo esperar pelo Borg 2.0?

Não. Em outubro de 2026, o Borg 2.0 ainda está em beta, na versão 2.0.0b25, lançada em 27 de setembro de 2026, e o projeto classifica-o apenas como adequado para testes. A série estável é a 1.4, atualmente na versão 1.4.5. Comece agora com a versão 1.4. O Borg 2 altera o formato do repositório e disponibiliza um caminho de atualização documentado (borg transfer --from-borg1), por isso começar hoje não o deixa sem uma via de migração. O Borg 2 também é a versão que adiciona suporte nativo para S3, B2 e rclone, assim que ficar estável.