Restic ou BorgBackup: qual usar no backup Linux?

Restic vs BorgBackup: em um parágrafo

Restic e BorgBackup executam a mesma tarefa 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 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 outro lado. 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 já é a resposta. Se o destino for outro sistema Linux sob o seu controlo, o Borg é uma opção e muitas vezes é mais rápido.

As restantes diferenças são menores. Ambos dividem os ficheiros em blocos com base no conteúdo, por isso um diretório de 40 GB alterado em 200 MB envia aproximadamente 200 MB. Ambos encriptam os dados no cliente. Ambos montam um snapshot com FUSE (filesystem in userspace) para permitir copiar um ficheiro. Em julho 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 a versão 1.4 é a que deve implementar 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 que o restic pode utilizar tantos backends. Qualquer armazenamento que consiga colocar, 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 tudo o que o rclone conseguir alcançar.

Um repositório Borg também é composto 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 comunica com esse processo usando o seu próprio protocolo. O lado do servidor executa trabalho real: mantém o repositório, aplica a transação e responde a consultas sobre o índice. É 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.

Esse ú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 conceção, não existe qualquer mecanismo de recuperação.

No Borg, a encriptação é uma opção escolhida durante a criação do repositório, e essa escolha é permanente. borg init --encryption=repokey mantém a chave encriptada dentro do repositório, pelo que a frase-passe, por si só, permite restaurar os dados. --encryption=keyfile mantém a chave no cliente, em ~/.config/borg/keys/, pelo que 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. Esta variante é mais rápida 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.

Compactação e por que o restic a implementou tarde

O Borg tem compactação desde o início. A predefinição é lz4, escolhida porque é suficientemente rápida para permanecer ativada em todos os casos. 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 importa mais do que o tempo. auto executa uma heurística por bloco, para que os dados já compactados não sejam compactados novamente.

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

O restic não tinha compactação até ao formato 2 do repositório, que requer o restic 0.14.0 ou posterior. Atualmente, o formato 2 é o formato predefinido para um repositório novo, e a compactação é configurada com --compression, usando os valores auto, off ou max. Um repositório antigo no formato 1 permanece sem compactação até ser migrado. Portanto, se o seu repositório do 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, ao 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, uma combinação comum: execute MinIO para 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, ao aceder a um repositório remoto, precisa de SSH e de uma instalação do Borg no sistema remoto. A versão instalada nesse sistema também tem de ser compatível com o cliente. Isso cria dificuldades quando o sistema remoto não é administrado por si. Não cria dificuldades quando é um segundo servidor que já administra. Nesse caso, obtém o controlo mais forte contra ransomware que qualquer uma das duas ferramentas oferece: uma chave SSH apenas para adicionar 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 adicionar dados. Com S3 simples, obtém o mesmo efeito através de uma política do bucket ou de object lock. Essa proteção é responsabilidade do fornecedor, não do restic. Restrinja também o transporte. A parte SSH merece o mesmo cuidado que qualquer outro início de sessão: aplique SSH apenas com chave e uma entrada authorized_keys restrita à conta de backup.

Velocidade: o que cada arquitetura implica

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

Borg over SSH é rápido numa ligação com latência porque o lado do servidor é inteligente. O cliente faz uma consulta, o processo remoto borg serve responde a partir do índice do repositório e a transação é confirmada num único local. As consultas de chunks não se transformam em round trips de 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 e mantém uma cache local em ~/.cache/restic, para que a execução seguinte não tenha de obter novamente todo o índice. Se eliminar essa cache, a cópia de segurança seguinte será lenta enquanto a reconstrói. Numa ligação com latência elevada 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 bloqueia exclusivamente o repositório durante toda a operação. Dois clientes a escreverem no mesmo repositório ao mesmo tempo não funcionam: o segundo espera e depois falha devido ao tempo limite do bloqueio. O padrão suportado é um repositório por cliente. Isto 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 usa um bloqueio partilhado e apenas operações de manutenção, como prune, usam um bloqueio exclusivo. Dez servidores semelhantes que utilizem o mesmo repositório Restic fazem deduplicação entre si, e o segundo servidor em diante normalmente armazena muito poucos dados. O custo é o raio de impacto: existe uma única palavra-passe e um único repositório com tudo. Se perder a palavra-passe, perde os dados dos dez servidores.

Retenção: esquecer e depois podar, ou podar e depois compactar

Ambas as ferramentas separam a decisão sobre o que manter da recuperação do 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 a poda e nunca compacta deixa o repositório a crescer indefinidamente, enquanto a lista de arquivos permanece curta. No restic, forget sem --prune remove apenas as referências aos snapshots, e os dados permanecem até ser executada uma poda.

Execute restic check depois da poda. O comando verifica as estruturas do repositório e indica 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 restaurar 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. Nenhum erro indica o motivo. A extração também escreve no diretório de trabalho atual. Mude primeiro para um diretório temporário. Caso contrário, poderá substituir ficheiros ativos por versões antigas.

Independentemente da ferramenta escolhida, o agendamento é apenas metade do trabalho. Execute uma restauração para um diretório temporário, com um temporizador que monitorize efetivamente. Faça-o da mesma forma que o guia completo em o restante do guia de backup do restic para um VPS, que utiliza um temporizador do systemd.

Qual é a melhor opção para cada tarefa

Escolha o restic quando o destino for armazenamento de objetos, quando quiser usar um único binário sem software no sistema remoto, 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 o repositório, e isso é difícil de superar do ponto de vista operacional.

Escolha o Borg quando o destino for uma máquina Linux sob o seu controlo, 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 opções são válidas. A opção errada é aquela que nunca testa. Se já cria dumps ao nível da aplicação, mantenha-os: o padrão em configuração do Nextcloud no Docker com dumps da base de dados aplica-se a ambas as ferramentas, porque copiar um ficheiro de base de dados ativa num momento aleatório não é fazer 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 ganhar 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 bloco. O restic tende a ganhar 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. Uma alternativa é montar o armazenamento de objetos como um sistema de ficheiros com rclone, mas o projeto Borg não recomenda esta 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 uma restauração local rápida, e restic para armazenamento de objetos, para 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 há duas palavras-passe para guardar 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 sua chave a partir da palavra-passe com scrypt e não existe forma de contornar esse mecanismo. No modo repokey, o Borg armazena a chave cifrada 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 utilizar 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 indica que deve ser utilizado apenas para testes. A série estável é a 1.4, atualmente na versão 1.4.5. Comece já com a 1.4. O Borg 2 altera o formato do repositório e disponibiliza um procedimento de atualização documentado, por isso começar hoje não o deixará preso à versão atual.