Restic vs BorgBackup 선택 가이드: 백업 도구 비교

Restic과 BorgBackup 비교

Restic과 BorgBackup은 리눅스 서버의 중복 제거, 암호화, 증분 백업이라는 핵심 기능을 동일하게 수행합니다. 두 도구 중 하나를 선택하는 결정적인 기준은 백업 저장소의 위치입니다. Restic은 S3 및 기타 객체 스토리지 API를 기본적으로 지원하므로, 별도의 소프트웨어 설치 없이 버킷을 직접 백업 대상으로 사용할 수 있습니다. 반면 Borg는 저장소를 보관하는 장비에 borg 프로그램이 설치되어 있어야 합니다. Borg 저장소는 파일 시스템이나 API가 아닌 프로세스를 통해 서비스되기 때문입니다. 백업 대상이 객체 스토리지라면 Restic이 적합하며, 직접 관리하는 별도의 리눅스 서버라면 Borg가 더 빠르고 효율적일 수 있습니다.

그 외의 차이점은 부차적입니다. 두 도구 모두 콘텐츠 기반 청킹(content-defined chunking) 방식을 사용하여 파일을 분할하므로, 40 GB 디렉터리에서 200 MB만 변경되어도 약 200 MB만 업로드됩니다. 또한 두 도구 모두 클라이언트 측에서 암호화를 수행하며, FUSE(filesystem in userspace)를 통해 스냅샷을 마운트하여 개별 파일을 복구할 수 있습니다. 2026년 7월 기준으로 Restic은 0.19.1 버전이며, Borg의 안정화 버전은 1.4.5입니다. Borg 2.0은 수년간 베타 상태로 테스트 단계에 머물러 있으므로, 현재 운영 환경에는 1.4 버전을 배포하는 것이 권장됩니다.

리포지토리 모델이 진정한 차이점입니다

restic 리포지토리는 config, keys/, snapshots/, index/, data/와 같은 팩 파일로 가득 찬 디렉터리입니다. 이를 읽기 위해 다른 것은 필요하지 않습니다. 이것이 restic이 그토록 많은 백엔드를 구동할 수 있는 이유입니다. 블롭(blob)을 저장, 조회, 나열, 삭제할 수 있는 모든 저장소는 restic 리포지토리를 담을 수 있습니다. 단일 바이너리가 로컬 경로, SFTP, 자체 REST 서버, S3, Backblaze B2, Azure, Google Cloud Storage 및 rclone이 접근할 수 있는 모든 것을 지원하는 방식이 바로 이것입니다.

Borg 리포지토리 역시 디스크상의 파일이지만, Borg는 단순 전송 방식을 통해 리포지토리와 통신하지 않습니다. 원격 리포지토리의 경우, Borg는 SSH를 통해 원격지에 borg serve를 실행하고 해당 프로세스와 자체 프로토콜로 통신합니다. 서버 측은 리포지토리를 유지하고, 트랜잭션을 적용하며, 인덱스 관련 질의에 응답하는 등 실질적인 작업을 수행합니다. 이것이 Borg에 S3 백엔드가 없는 이유이며, 프로젝트가 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를 사용하여 비밀번호로부터 키를 도출합니다. 그 이후 작성되는 모든 팩 파일은 암호화 및 인증됩니다. 설계상 복구 경로가 존재하지 않으므로 비밀번호를 분실하면 데이터도 사라집니다.

Borg는 저장소 생성 시 암호화 여부를 선택하게 하며, 이 선택은 영구적입니다. borg init --encryption=repokey은 암호화된 키를 저장소 내부에 보관하므로 비밀번호만으로 복구가 가능합니다. --encryption=keyfile은 키를 클라이언트의 ~/.config/borg/keys/에 보관합니다. 따라서 저장소 전체를 탈취당해도 공격자는 아무것도 얻을 수 없으며, 사용자는 해당 키 파일을 별도로 백업해야 합니다. 그렇지 않으면 아카이브를 읽을 수 없습니다. 각 모드에는 HMAC-SHA256 대신 BLAKE2b로 인증하는 -blake2 변형이 있으며, 이는 SHA 가속 기능이 없는 하드웨어에서 더 빠릅니다. --encryption=none도 존재하며, 저장소가 사용자가 소유한 암호화된 디스크에 위치할 때 선택할 수 있는 실질적인 옵션입니다.

실무 지침: 일반적인 서버 백업에는 repokey-blake2를 사용하고, 완전히 신뢰할 수 없는 곳에 저장소가 위치할 때는 keyfile을 사용하며, 임대 서버에서는 절대 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은 restic 0.14.0 이상에서 지원하는 리포지토리 형식 2가 도입되기 전까지 압축 기능을 전혀 지원하지 않았습니다. 현재는 형식 2가 새 리포지토리의 기본값이며, 압축 설정은 --compression을 통해 auto, off 또는 max 값으로 지정할 수 있습니다. 이전 형식 1 리포지토리는 마이그레이션하기 전까지 압축되지 않은 상태로 유지됩니다. 따라서 사용 중인 restic 리포지토리가 0.14 버전 이전의 것이고 마이그레이션을 수행하지 않았다면, 텍스트, 로그, 데이터베이스 덤프 파일에 대해 여전히 압축되지 않은 전체 용량만큼의 저장 공간을 사용하고 있는 것입니다.

원격 대상: S3와 SSH 비교

보통 여기서 선택이 갈립니다.

Restic이 S3에 접근하려면 환경 변수에 자격 증명만 설정하면 되며, 다른 곳에서 실행 중인 프로세스는 필요 없습니다. 이 방식은 직접 호스팅하는 버킷에도 동일하게 적용되며, 흔히 자체 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가 원격 저장소에 접근하려면 SSH 연결과 원격지에 설치된 Borg가 필요하며, 원격지의 버전이 클라이언트와 호환되어야 합니다. 원격지가 본인 소유가 아니라면 이는 번거로운 제약이 됩니다. 하지만 원격지가 이미 관리 중인 두 번째 서버라면 아무런 문제가 되지 않으며, 두 도구 중 가장 강력한 랜섬웨어 방어 수단인 '추가 전용(append only) SSH 키'를 사용할 수 있습니다. SSH 키가 borg serve만 실행하도록 강제하면 클라이언트는 아카이브를 추가할 수는 있지만 삭제할 수는 없으므로, 서버가 침해당하더라도 기존 백업 기록을 삭제할 수 없습니다.

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

Restic은 자체 REST 서버를 실행할 때만 이와 동일한 기능을 제공하며, 이때 추가 전용 모드를 지원합니다. 일반 S3를 사용할 때는 버킷 정책이나 객체 잠금(object lock) 기능을 통해 동일한 효과를 얻을 수 있는데, 이는 Restic이 아닌 서비스 제공업체의 영역입니다. SSH 연결 역시 다른 로그인과 마찬가지로 주의를 기울여야 하므로, 백업 계정에는 제한된 authorized_keys 항목을 사용하는 키 기반 SSH를 적용하여 전송 계층을 보호하십시오.

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

어떤 프로젝트도 사용자의 데이터에 대해 신뢰할 만한 벤치마크를 게시하지 않으므로, 메커니즘을 바탕으로 추론해야 합니다.

SSH 기반의 Borg는 서버 측이 지능적이므로 지연 시간이 있는 링크에서도 빠릅니다. 클라이언트가 질문하면 원격 borg serve 프로세스가 저장소 인덱스에서 답변하고, 트랜잭션이 한 곳에서 커밋됩니다. 청크 조회를 위해 모든 작은 파일마다 네트워크 왕복이 발생하지 않습니다.

객체 스토리지 기반의 Restic은 서버 측 기능이 없으므로, HTTP로 가져온 인덱스 파일과 팩 파일로부터 전체 구조를 파악해야 합니다. 요청 횟수를 적절하게 유지하기 위해 업로드 전 많은 작은 청크를 더 큰 팩 파일로 묶으며, 다음 실행 시 전체 인덱스를 다시 가져오지 않도록 ~/.cache/restic에 로컬 캐시를 유지합니다. 이 캐시를 삭제하면 다음 백업은 재구축 과정 때문에 느려집니다. 지연 시간이 긴 링크에서 수백만 개의 작은 파일을 다룰 때, Restic은 동일한 데이터 환경의 Borg보다 느리게 느껴질 수 있습니다.

로컬 디스크나 빠른 LAN 환경에서는 이러한 격차가 대부분 사라지며, 두 도구 모두 원본 데이터를 읽고 해싱하는 속도에 의해 성능이 제한됩니다.

잠금 및 여러 서버의 백업

Borg 1.4는 전체 작업 동안 리포지토리에 대해 배타적 잠금을 수행합니다. 두 클라이언트가 동시에 하나의 리포지토리에 쓰는 것은 불가능합니다. 두 번째 클라이언트는 대기하다가 잠금 시간 초과로 실패합니다. 권장되는 방식은 클라이언트당 하나의 리포지토리를 사용하는 것입니다. 이는 중복 제거가 해당 머신의 리포지토리 내부에서만 발생함을 의미하므로, 거의 동일한 서버 10대를 백업하면 동일한 기본 시스템의 사본 10개가 저장됩니다.

Restic은 여러 클라이언트가 동시에 하나의 리포지토리에 백업하는 것을 허용합니다. 백업은 공유 잠금을 사용하고 prune와 같은 유지보수 작업만 배타적 잠금을 사용하기 때문입니다. 유사한 서버 10대를 하나의 restic 리포지토리를 가리키도록 설정하면 서로 간에 중복 제거가 이루어지며, 두 번째 서버부터는 저장되는 데이터 양이 매우 적어지는 경우가 많습니다. 이에 따른 위험은 영향 범위입니다. 하나의 비밀번호와 하나의 리포지토리에 모든 데이터가 담기므로, 비밀번호를 분실하면 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만 실행하면 스냅샷 참조만 삭제될 뿐, 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 타이머를 사용하여 수행하는 전체 과정과 동일하게, 실제로 모니터링하는 타이머를 설정하여 임시 디렉터리로 복구 테스트를 수행하십시오.

어떤 작업에 무엇을 선택할 것인가

대상 저장소가 오브젝트 스토리지이거나, 단일 바이너리만 필요하고 원격지에 별도 소프트웨어를 설치하고 싶지 않을 때, 여러 대의 머신이 서로 중복 제거를 수행해야 할 때, 혹은 복구 작업을 본인이 직접 하지 않을 수도 있을 때는 restic을 선택하십시오. restic은 저장소 URL을 사용하는 단일 정적 바이너리이므로 운영 측면에서 이보다 뛰어난 도구를 찾기 어렵습니다.

대상 저장소가 직접 제어하는 Linux 서버일 때, 네트워크 지연이 있고 데이터셋이 수백만 개의 작은 파일로 구성되어 있을 때, 랜섬웨어 방지를 위해 추가 전용(append-only) SSH 키를 사용하고 싶을 때, 혹은 작업별로 압축 설정을 최적화해야 할 때는 Borg를 선택하십시오. Borg는 더 오래된 도구이며 안정적인 버전이 천천히 업데이트되는데, 백업 소프트웨어에서는 이것이 곧 장점입니다.

두 도구 모두 올바른 선택입니다. 잘못된 선택은 한 번도 테스트하지 않는 것입니다. 이미 애플리케이션 수준의 덤프를 생성하고 있다면 이를 유지하십시오. 데이터베이스 덤프를 포함한 Docker 기반 Nextcloud 설정에 사용된 패턴은 두 도구 모두에 적용됩니다. 라이브 데이터베이스 파일을 임의의 시점에 복사하는 것만으로는 데이터베이스 백업이라고 할 수 없기 때문입니다.

FAQ

restic과 BorgBackup 중 어느 것이 더 빠른가요?

로컬 디스크나 빠른 LAN 환경에서는 두 도구의 성능이 비슷하며, 둘 다 원본 데이터의 읽기 및 해시 속도에 따라 성능이 제한됩니다. 지연 시간이 긴 SSH 연결 환경에서 작은 파일이 매우 많을 경우, 원격지의 borg serve 프로세스가 청크당 네트워크 왕복 없이 인덱스 관련 질의에 응답하므로 Borg가 더 유리합니다. 대상이 오브젝트 스토리지인 경우에는 Borg가 지원하지 않으므로 restic이 더 유리합니다.

BorgBackup으로 S3나 Backblaze B2에 백업할 수 있나요?

직접적으로는 불가능합니다. Borg 저장소는 SSH를 통해 borg serve 프로세스가 담당하는데, 버킷 내부에서는 해당 프로세스가 실행되지 않기 때문입니다. rclone을 사용하여 오브젝트 스토리지를 파일 시스템으로 마운트하는 우회 방법을 사용하기도 하지만, Borg 프로젝트는 이를 권장하지 않습니다. 트랜잭션 도중 마운트가 끊기면 저장소가 손상될 수 있기 때문입니다. 오브젝트 스토리지가 필요하다면 restic을 사용하십시오.

동일한 데이터에 두 도구를 모두 사용할 수 있나요?

네, 가능합니다. 실제로 일부 사용자는 빠른 로컬 복구를 위해 Borg를 두 번째 서버로 백업하고, 오프사이트 복사본을 위해 restic으로 오브젝트 스토리지에 백업하는 방식을 사용합니다. 두 도구는 서로 아무것도 공유하지 않으므로 읽기 및 해시 비용이 두 번 발생하며, 두 개의 암호를 안전하게 보관해야 합니다. 두 도구 모두 복구 테스트를 완료한 경우에만 이 방식을 사용하십시오.

저장소 암호를 분실하면 어떻게 되나요?

두 도구 모두 데이터를 복구할 수 없습니다. Restic은 scrypt를 사용하여 암호로부터 키를 도출하며 우회 방법은 없습니다. Borg는 repokey 모드에서 암호화된 키를 저장소 내부에 저장하므로 암호만으로 복구가 가능하지만, keyfile 모드에서는 ~/.config/borg/keys/의 키 파일도 필요합니다. 백업 대상 서버에 저장되지 않는 암호 관리자에 암호를 보관하고, keyfile를 사용하는 경우 borg key export을 통해 Borg 키를 내보내 두십시오.

Borg 2.0을 기다려야 할까요?

아니요. 2026년 7월 기준으로 Borg 2.0은 2.0.0b22 버전으로 여전히 베타 상태이며, 프로젝트 측에서도 테스트 용도로만 분류하고 있습니다. 안정화 버전은 1.4 시리즈이며 현재 1.4.5입니다. 지금 바로 1.4 버전을 시작하십시오. Borg 2는 저장소 형식을 변경하지만 문서화된 업그레이드 경로를 제공하므로, 지금 시작해도 나중에 문제가 되지 않습니다.