Restic과 BorgBackup, 어떤 것을 실행할까?

Restic과 BorgBackup 비교, 한 문단으로

Restic과 BorgBackup은 모두 Linux 서버에서 중복 제거, 암호화, 증분 백업을 수행합니다. 선택을 결정하는 차이는 백업을 저장하는 위치입니다. Restic은 기본적으로 S3 및 기타 object storage API를 사용하므로, 원격 측에 아무것도 설치하지 않고도 bucket을 기본 대상로 사용할 수 있습니다. Borg는 repository를 보유한 시스템에 borg 프로그램을 설치해야 합니다. Borg repository는 filesystem이나 API가 아니라 process가 제공하기 때문입니다. 대상이 object storage라면 이미 선택이 정해집니다. 직접 관리하는 두 번째 Linux 시스템이 대상이라면 Borg를 사용할 수 있으며, 대개 더 빠릅니다.

그 밖의 차이는 상대적으로 작습니다. 두 제품 모두 content-defined chunking으로 파일을 분할하므로, 200 MB만 변경된 40 GB directory를 백업하면 대략 200 MB를 업로드합니다. 두 제품 모두 client에서 암호화합니다. 두 제품 모두 FUSE (filesystem in userspace)를 사용해 snapshot을 mount하므로, 파일 하나를 복사해 꺼낼 수 있습니다. 2026년 7월 기준으로 restic은 0.19.1이며, Borg의 stable series는 1.4이고 최신 버전은 1.4.5입니다. Borg 2.0은 수년째 beta 상태이며 아직 testing only로 표시되어 있으므로, 현재 배포해야 할 버전은 1.4입니다.

실제 차이는 저장소 모델에 있습니다

restic 저장소는 파일 디렉터리입니다. config, keys/, snapshots/, index/, data/에는 pack 파일이 들어 있습니다. 저장소를 읽는 데 다른 요소는 필요하지 않습니다. 따라서 restic은 다양한 백엔드를 사용할 수 있습니다. blob을 저장하고, 가져오고, 나열하고, 삭제할 수 있는 저장소라면 restic 저장소를 보관할 수 있습니다. 이 방식으로 하나의 바이너리가 로컬 경로, SFTP, 자체 REST 서버, S3, Backblaze B2, Azure, Google Cloud Storage 및 rclone이 접근할 수 있는 모든 대상을 지원합니다.

Borg 저장소도 디스크의 파일로 구성됩니다. 그러나 Borg는 단순한 전송 방식을 통해 저장소에 접근하지 않습니다. 원격 저장소를 사용할 때 Borg는 SSH를 통해 원격 측에서 borg serve를 시작하고, 해당 프로세스와 자체 프로토콜로 통신합니다. 서버 측은 실제 작업을 수행합니다. 저장소를 보관하고 트랜잭션을 적용하며 인덱스 조회에 응답합니다. 따라서 Borg에는 S3 백엔드가 없으며 프로젝트에서도 이를 추가하지 않았습니다. 버킷 내부에서 실행할 프로세스가 없기 때문입니다.

이 하나의 설계 원칙이 아래에 설명하는 실질적인 차이 대부분을 만듭니다.

# 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

암호화: 둘 중 하나는 끌 수 있음

Restic은 항상 암호화됩니다. 암호화되지 않은 모드는 없습니다. restic init은(는) 암호를 요청하고, scrypt를 사용해 암호에서 키를 파생합니다. 그 후 기록되는 모든 pack file은 암호화되고 인증됩니다. 암호를 잃으면 데이터를 복구할 수 없습니다. 설계상 복구 경로가 없기 때문입니다.

Borg에서는 repository를 만들 때 암호화를 선택하며, 이 선택은 영구적입니다. borg init --encryption=repokey은(는) 암호화된 키를 repository 내부에 저장하므로 passphrase만으로 복원할 수 있습니다. --encryption=keyfile은(는) ~/.config/borg/keys/의 client에 키를 저장합니다. 따라서 누군가 repository 전체를 훔쳐도 아무것도 얻을 수 없습니다. 대신 해당 키 파일을 별도로 백업해야 합니다. 키 파일이 없으면 archive를 읽을 수 없습니다. 각 모드에는 HMAC-SHA256 대신 BLAKE2b로 인증하는 -blake2 변형도 있습니다. SHA 가속 기능이 없는 hardware에서 더 빠릅니다. --encryption=none도 존재합니다. repository가 소유한 암호화된 disk에 있는 경우에는 --encryption=none을(를) 실제로 선택할 수 있습니다.

실무 규칙은 다음과 같습니다. 일반적인 server backup에는 repokey-blake2을(를) 사용합니다. repository가 완전히 신뢰할 수 없는 위치에 있을 때는 keyfile을(를) 사용합니다. 대여한 machine에서는 none을(를) 절대 사용하지 않습니다.

압축과 restic에 압축 기능이 늦게 추가된 이유

Borg는 처음부터 압축을 지원했습니다. 기본값은 lz4입니다. 모든 작업에서 활성화해도 충분히 빠르기 때문에 이 값이 선택되었습니다. zstd은 1부터 22까지의 수준을 지원하며 기본값은 3입니다. zlib과 lzma은 처리 시간보다 바이트 수를 더 중요하게 여기는 경우에 사용합니다. auto은 각 청크에 휴리스틱을 적용하여 이미 압축된 데이터가 두 번 압축되지 않도록 합니다.

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

restic은 repository format 2가 도입될 때까지 압축을 지원하지 않았습니다. repository format 2를 사용하려면 restic 0.14.0 이상이 필요합니다. 현재 새 repository의 기본 형식은 format 2이며, 압축은 --compression에 auto, off 또는 max 값을 지정하여 설정합니다. 기존 format 1 repository는 마이그레이션할 때까지 압축되지 않은 상태로 유지됩니다. 따라서 restic repository가 0.14보다 이전에 생성되었고 한 번도 마이그레이션하지 않았다면, 텍스트, 로그 및 데이터베이스 덤프에 여전히 압축되지 않은 전체 용량을 사용하고 있습니다.

원격 대상: S3와 SSH

일반적으로 여기서 선택이 결정됩니다.

restic이 S3에 연결하려면 환경에 자격 증명이 있어야 하며, 다른 곳에서 실행 중인 것은 필요하지 않습니다. 직접 호스팅하는 bucket에도 같은 방식을 사용할 수 있습니다. 다음과 같이 함께 구성하는 경우가 많습니다. 자체 VPS에서 S3 API용 MinIO 실행 후 restic이 해당 대상에 연결하도록 설정합니다.

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

Borg가 원격 repository에 연결하려면 SSH와 원격 측의 Borg 설치가 필요합니다. 또한 원격 측의 버전이 client와 호환되어야 합니다. 원격 측을 직접 관리하지 않는다면 이 방식은 부담이 됩니다. 이미 관리하는 두 번째 server라면 문제가 되지 않습니다. 대신 두 도구에서 ransomware에 대응하는 가장 강력한 제어 기능인 append only SSH key를 사용할 수 있습니다. 해당 key가 borg serve만 실행하도록 강제하면 client는 archive를 추가할 수 있지만 삭제할 수는 없습니다. 따라서 침해된 machine이 자체 백업 이력을 삭제할 수 없습니다.

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

restic에서는 자체 REST server를 실행할 때만 이에 상응하는 기능을 사용할 수 있습니다. 이 server는 append only mode를 지원합니다. 일반 S3에서는 bucket policy 또는 object lock으로 동일한 효과를 얻을 수 있습니다. 이는 restic이 아니라 provider가 담당하는 기능입니다. 전송도 제한해야 합니다. SSH 측도 다른 login과 동일한 주의가 필요하기 때문입니다. backup account에 제한된 authorized_keys 항목을 사용하는 key only SSH를 적용합니다.

속도: 각 설계가 의미하는 것

두 프로젝트 모두 사용자 데이터에 대해 신뢰할 수 있는 벤치마크를 제공하지 않습니다. 따라서 작동 방식에 따라 판단해야 합니다.

SSH를 통한 Borg는 지연 시간이 있는 연결에서도 빠릅니다. 서버 측이 지능적으로 처리하기 때문입니다. 클라이언트가 질의하면 원격 borg serve 프로세스가 repository index에서 답을 찾습니다. 트랜잭션은 한 곳에서 커밋됩니다. 청크 조회 때문에 작은 파일마다 네트워크 왕복이 발생하지 않습니다.

object storage를 사용하는 restic에는 서버 측 처리가 없습니다. 따라서 HTTP를 통해 가져온 index 파일과 pack 파일을 바탕으로 상태를 구성해야 합니다. 요청 수를 적절한 수준으로 유지하기 위해 업로드 전에 많은 작은 청크를 더 큰 pack 파일로 묶습니다. 또한 다음 실행에서 전체 index를 다시 가져오지 않도록 ~/.cache/restic에 로컬 캐시를 유지합니다. 이 캐시를 삭제하면 다음 백업에서는 캐시를 다시 구성하는 동안 속도가 느려집니다. 지연 시간이 높고 작은 파일이 수백만 개 있는 연결에서는 동일한 데이터에서 restic이 Borg보다 느리게 느껴집니다.

로컬 디스크나 빠른 LAN에서는 차이가 대부분 줄어듭니다. 두 도구 모두 결국 원본을 읽고 해시할 수 있는 속도에 의해 제한됩니다.

여러 시스템 잠금 및 백업

Borg 1.4는 전체 작업 동안 repository에 배타적 잠금을 설정합니다. 두 client가 동시에 하나의 repository에 쓰는 방식은 작동하지 않습니다. 두 번째 client는 대기한 후 lock timeout으로 실패합니다. 지원되는 방식은 client마다 하나의 repository를 사용하는 것입니다. 이 경우 deduplication은 한 시스템의 repository 내부에서만 수행됩니다. 따라서 거의 동일한 서버 10대가 동일한 기본 시스템을 10개 복사본으로 저장합니다.

Restic은 여러 client가 동시에 하나의 repository에 백업할 수 있도록 합니다. 백업에는 공유 잠금이 사용되고, prune 같은 maintenance 작업에만 배타적 잠금이 사용되기 때문입니다. 유사한 서버 10대를 하나의 restic repository에 연결하면 서로 간에 deduplication이 수행됩니다. 두 번째 서버부터는 저장되는 데이터가 매우 적을 수 있습니다. 그러나 blast radius가 커집니다. 하나의 password와 모든 데이터를 보관하는 하나의 repository에 의존하므로 password를 잃으면 10대 모두의 데이터에 접근할 수 없게 됩니다.

보존: forget 후 prune와 prune 후 compact 비교

두 도구 모두 “무엇을 보존할지 결정”하는 단계와 “공간 회수” 단계를 분리합니다. 두 번째 단계는 직접 실행해야 합니다.

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

두 도구에서 발생하는 함정은 동일합니다. 이를 명확히 설명할 필요가 있습니다. Borg에서 borg prune은 아카이브를 삭제하지만 그 자체로 디스크 공간을 확보하지는 않습니다. borg compact이 실행되어야 공간이 다시 확보됩니다. 따라서 prune만 실행하고 compact를 실행하지 않는 cron 작업은 아카이브 목록은 짧게 유지하면서 저장소를 계속 증가시킵니다. restic에서는 --prune 없이 forget만 실행하면 snapshot 참조만 제거되고 데이터는 prune이 실행될 때까지 남아 있습니다.

prune 후에 restic check을 실행합니다. 이 명령은 저장소 구조를 확인하고 손상 여부를 알려 줍니다. 복원 중에 손상을 발견하는 것보다 훨씬 안전합니다.

복원: 실제로 중요한 유일한 테스트

두 도구 모두 스냅샷을 마운트하므로 내용을 탐색할 수 있습니다. 특정 파일 하나를 가장 빠르게 복원하는 방법입니다.

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

borg extract의 경로 형식에 유의합니다. 아카이브 내부의 경로는 앞의 슬래시 없이 저장됩니다. 따라서 etc/nginx는 올바르지만, /etc/nginx는 일치하는 항목이 없어 아무것도 추출하지 않으며 그 이유를 알려 주는 오류도 표시되지 않습니다. 또한 추출 결과는 현재 작업 디렉터리에 기록됩니다. 먼저 임시 디렉터리로 이동해야 합니다. 그렇지 않으면 기존 파일을 오래된 파일로 덮어쓸 수 있습니다.

어떤 도구를 선택하든 일정 설정은 작업의 절반에 불과합니다. VPS용 restic 백업 가이드의 나머지 내용에서 systemd timer를 사용하는 전체 절차와 같은 방식으로, 실제로 확인하는 timer에서 임시 디렉터리로 복원을 실행합니다.

어떤 작업에 어떤 도구가 적합한가

대상이 object storage인 경우, 하나의 binary만 사용하고 원격 측에 software를 설치하지 않으려는 경우, 여러 machine이 서로 중복 제거를 수행해야 하는 경우 또는 복원하는 사람이 본인이 아닐 수 있는 경우에는 restic을 선택합니다. restic은 repository를 URL로 지정하는 단일 static binary이며, 운영 측면에서 이를 능가하기는 어렵습니다.

대상이 직접 관리하는 Linux box인 경우, 연결에 latency가 있고 dataset에 수백만 개의 작은 file이 포함된 경우, ransomware에 대한 통제 수단으로 append only SSH key를 사용하려는 경우 또는 작업별로 compression을 조정하려는 경우에는 Borg를 선택합니다. Borg는 더 오래된 tool이며 stable series의 변경 속도도 느립니다. 그러나 backup software에서는 이것이 장점입니다.

둘 다 올바른 선택입니다. 잘못된 선택은 한 번도 테스트하지 않은 선택입니다. 이미 application level dump를 생성하고 있다면 계속 유지합니다. database dump를 사용하는 Nextcloud on Docker 설정의 패턴은 두 tool 모두에 적용됩니다. 실행 중인 database file을 임의의 시점에 복사한 것은 database의 backup이 아니기 때문입니다.

FAQ

restic과 BorgBackup 중 어느 쪽이 더 빠릅니까?

로컬 디스크나 빠른 LAN에서는 성능 차이가 크지 않으며, 두 도구 모두 소스의 읽기 속도와 해시 계산 속도에 의해 제한됩니다. 파일 수가 매우 많고 SSH 연결의 지연 시간이 높은 경우에는 Borg가 더 빠른 경향이 있습니다. 원격 측의 borg serve 프로세스가 각 청크의 인덱스 조회에 응답하므로 청크마다 네트워크 왕복이 필요하지 않기 때문입니다. 대상이 object storage인 경우에는 Borg를 사용할 수 없으므로 restic이 더 적합합니다.

BorgBackup을 S3 또는 Backblaze B2에 백업할 수 있습니까?

직접 백업할 수는 없습니다. Borg repository는 SSH를 통해 borg serve 프로세스가 제공하지만, bucket 내부에서는 이러한 프로세스가 실행되지 않습니다. 일부 사용자는 rclone으로 object storage를 filesystem으로 마운트하여 우회합니다. 그러나 Borg project는 이 방법을 권장하지 않습니다. 트랜잭션 중간에 마운트가 끊기면 repository가 손상될 수 있기 때문입니다. object storage가 필요하면 restic을 사용합니다.

두 도구를 같은 데이터에 모두 사용할 수 있습니까?

가능하며, 실제로 그렇게 사용하는 경우도 있습니다. 빠른 로컬 복원을 위해 Borg를 두 번째 서버에 사용하고, offsite 복사본을 위해 restic을 object storage에 사용하는 방식입니다. 두 도구는 데이터를 공유하지 않으므로 읽기와 해시 계산 비용을 두 번 지불해야 하며, 안전하게 보관해야 할 password도 2개가 됩니다. 두 복원을 모두 테스트한 경우에만 이 구성을 사용합니다.

repository password를 잃어버리면 어떻게 됩니까?

두 도구 모두 데이터를 복구할 수 없습니다. restic은 scrypt를 사용해 password에서 key를 파생하며 우회 방법이 없습니다. Borg는 repokey 모드에서 암호화된 key를 repository 내부에 저장하므로 passphrase만으로 복원할 수 있습니다. keyfile 모드에서는 ~/.config/borg/keys/의 key file도 필요합니다. 백업 대상 서버에 저장되지 않는 password manager에 password를 보관합니다. keyfile를 사용하는 경우에는 borg key export로 Borg key를 export합니다.

Borg 2.0을 기다려야 합니까?

아니요. 2026년 7월 기준으로 Borg 2.0은 여전히 beta이며 버전은 2.0.0b22입니다. project에서도 testing 전용으로 표시하고 있습니다. stable series는 1.4이며, 현재 버전은 1.4.5입니다. 지금 1.4로 시작합니다. Borg 2는 repository format을 변경하지만 문서화된 upgrade path를 제공하므로, 지금 시작해도 이후에 전환할 수 있습니다.