Restic 與 BorgBackup 怎麼選？比較 S3、SSH 與速度

Restic 與 BorgBackup：一段說明

Restic 與 BorgBackup 的核心工作相同：為 Linux 伺服器建立去重、加密的增量備份。決定選擇的差異在於備份的儲存位置。Restic 原生支援 S3 與其他物件儲存 API，因此可直接將 bucket 作為目標，遠端不必安裝任何程式。Borg 則需要在存放 repository 的機器上安裝 borg 程式，因為 Borg repository 是由程序提供服務，而不是由檔案系統或 API 提供。如果目標是物件儲存，答案已經很明確。如果目標是由你管理的另一台 Linux 主機，Borg 就適用，而且通常速度更快。

其他差異都較小。兩者都會使用依內容定義的分塊方式切割檔案，因此 40 GB 的目錄若只有 200 MB 變更，約會上傳 200 MB。兩者都在用戶端進行加密。兩者都能透過 FUSE（userspace 中的檔案系統）掛載快照，讓你複製出單一檔案。截至 July 2026，restic 的版本為 0.19.1，而 Borg 的穩定版本系列為 1.4，目前版本是 1.4.5。Borg 2.0 多年來一直處於 beta，至今仍標示為僅供測試，因此目前應部署 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/ 中，因此即使有人竊取整個 repository，也無法取得資料；但你必須另外備份這個金鑰檔案，否則無法讀取 archive。每種模式都有使用 BLAKE2b、而非 HMAC-SHA256 進行驗證的 -blake2 變體。這在沒有 SHA 加速功能的硬體上速度較快。--encryption=none 也可以使用。當 repository 位於你擁有的加密磁碟上時，這是合理的選擇。

實務規則如下：一般伺服器備份使用 repokey-blake2；repository 位於你不完全信任的位置時使用 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

直到 repository format 2，Restic 才開始支援壓縮；這需要 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 安裝版本；遠端版本也必須與用戶端相容。若遠端主機不由你管理，這會增加部署複雜度。若遠端主機是你已管理的第二台伺服器，則不成問題，還能取得兩種工具中對抗勒索軟體最強的控制方式：append-only SSH key。強制該金鑰執行 borg serve，用戶端就只能新增 archive，無法刪除 archive，因此遭入侵的機器無法清除自己的歷史備份。

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

restic 只有在執行自有 REST server 時，才具備等效功能；該 server 支援 append-only 模式。使用一般 S3 時，則可透過 bucket policy 或 object lock 達到相同效果；這屬於供應商負責的功能，不是 restic 的功能。也要限制傳輸通道，因為 SSH 端同樣需要按照其他登入方式謹慎設定：針對備份帳號套用 僅允許金鑰的 SSH 與受限 authorized_keys 項目。

速度：每種設計代表的意義

這兩個專案都沒有發布可供你信賴、且適用於自有資料的基準測試，因此應從運作機制來判斷。

Borg over SSH 在高延遲連線上仍然很快，因為伺服器端具備智慧處理能力。用戶端提出查詢，遠端的 borg serve 程序會從儲存庫索引回答，交易也會在單一位置提交。區塊查詢不會讓每個小檔案都產生一次網路往返。

Restic on object storage 沒有伺服器端處理能力，因此必須透過 HTTP 擷取索引檔案與 pack 檔案，逐步建立儲存庫狀態。為了控制請求數量，它會在上傳前將許多小區塊封裝到較大的 pack 檔案中，並在 ~/.cache/restic 保留本機快取，讓下次執行時不必重新擷取完整索引。刪除該快取後，下次備份會因重新建立快取而變慢。在高延遲連線且包含數百萬個小檔案的情況下，restic 在相同資料上的體感速度會比 Borg 慢。

在本機磁碟或快速 LAN 上，兩者的差距大多會縮小，最後都受限於讀取及計算來源資料雜湊的速度。

鎖定與備份多台機器

Borg 1.4 在整個操作期間會對儲存庫取得獨佔鎖定。兩個用戶端同時寫入同一個儲存庫並不可行：第二個用戶端會等待，接著因鎖定逾時而失敗。支援的模式是每個用戶端使用一個儲存庫。這也表示重複資料刪除只會在單一機器的儲存庫內進行，因此 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 則不會匹配任何內容，也不會擷取任何檔案，而且不會顯示錯誤來說明原因。擷取作業也會將檔案寫入目前工作目錄，因此請先切換到暫存目錄，否則舊檔案會覆寫線上檔案。

還原作業即使在沒有錯誤的情況下完成，也不能證明還原成功。上層應用程式對完整還原有自己的判定方式：從 Postgres 資料目錄副本重建的 Immich 伺服器，磁碟上仍有所有相片，但時間軸卻沒有任何內容。這正是 Immich 的備份與還原 必須處理的失敗情況。

無論選用哪一種工具，排程都只完成一半工作。請定期將資料還原到暫存目錄，並實際監看還原結果；完整操作指南 VPS 的 restic 備份指南 也是透過 systemd timer 來執行這項工作。

哪一個工具適合哪種工作

目標是物件儲存、希望只使用單一二進位檔且不在遠端安裝軟體、需要讓多台機器彼此進行去重，或負責還原的人可能不是自己時，請選擇 restic。它是單一靜態二進位檔，只需指定儲存庫 URL；就操作面而言，很難找到更簡單的方案。

目標是自己控管的 Linux 主機、連線延遲較高且資料集包含數百萬個小檔案、希望使用 append-only SSH key 作為防範勒索軟體的控制措施，或希望依工作調整壓縮設定時，請選擇 Borg。這是較早期的工具，其穩定系列更新速度較慢；對備份軟體而言，這反而是優點。

兩者都是正確答案。錯誤的答案是你從未測試過的那一個。如果你已經執行應用程式層級的傾印，請保留這些傾印：Nextcloud 搭配 Docker 與資料庫傾印的設定所採用的模式同樣適用於這兩個工具，因為在隨機時間點複製正在使用中的資料庫檔案，並不等於備份資料庫。

FAQ

restic 或 BorgBackup 哪個速度較快？

在本機磁碟或高速 LAN 上，兩者速度接近，最後都會受來源端的讀取與雜湊速度限制。面對高延遲的 SSH 連線和大量小檔案時，Borg 通常較快，因為遠端的 borg serve 程序可處理索引查詢，不必為每個區塊各自往返網路一次。目標是物件儲存時，restic 通常較快，因為 Borg 完全無法直接使用物件儲存。

BorgBackup 可以備份到 S3 或 Backblaze B2 嗎？

不能直接備份。Borg repository 由 SSH 上的 borg serve 程序提供服務，而 bucket 內不會執行這類程序。有人會使用 rclone 將物件儲存掛載為檔案系統，以此繞過限制，但 Borg 專案不建議這麼做，因為掛載點若在交易進行到一半時中斷，可能會損毀 repository。若需要物件儲存，請使用 restic。

我可以讓兩個工具處理相同的資料嗎？

可以，有些人確實會這樣做：使用 Borg 備份到第二台伺服器，以便快速在本機還原；再使用 restic 備份到物件儲存，作為異地副本。兩者不共用任何資料，因此讀取與雜湊成本會計算兩次，還需要安全保存兩組密碼。只有在測試過兩者的還原流程後，才應採用這種做法。

如果遺失 repository 密碼，會發生什麼事？

兩個工具中的資料都將無法復原。restic 使用 scrypt 從密碼衍生金鑰，沒有任何繞過方式。Borg 在 repokey 模式中會將加密金鑰儲存在 repository 內，因此只要有 passphrase 即可還原；在 keyfile 模式中，還需要 ~/.config/borg/keys/ 中的金鑰檔案。如果使用 keyfile，請將密碼儲存在不位於備份目標伺服器上的密碼管理器中，並使用 borg key export 匯出 Borg 金鑰。

我應該等待 Borg 2.0 嗎？

不用。截至 July 2026，Borg 2.0 仍處於 beta 版本，目前為 2.0.0b22，專案也標示僅供測試使用。穩定版本系列為 1.4，目前版本是 1.4.5。現在即可開始使用 1.4。Borg 2 會變更 repository 格式，並提供有文件說明的升級路徑，因此現在開始使用不會讓日後無法升級。