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

Restic 與 BorgBackup 的比較

Restic 與 BorgBackup 的核心功能相同，皆提供 Linux 伺服器的去重複、加密與增量備份。兩者的選擇關鍵在於備份儲存位置。Restic 原生支援 S3 及其他物件儲存 API，因此儲存桶（bucket）可直接作為備份目標，遠端無需安裝任何軟體。穩定的 Borg 則需要在存放儲存庫的機器上安裝 borg 程式，因為 Borg 儲存庫是由處理程序（process）而非檔案系統或 API 提供服務。若您的目標是物件儲存，Restic 即為首選；若目標是您管理的另一台 Linux 主機，則可考慮 Borg，其效能通常較佳。

其餘差異較小。兩者皆採用內容定義分塊（content-defined chunking）技術，因此 40 GB 的目錄若僅變更 200 MB，上傳量約為 200 MB。兩者皆在用戶端進行加密，並支援透過 FUSE 掛載快照以提取單一檔案。截至 2026 年 10 月，restic 版本為 0.19.1，Borg 穩定版系列為 1.4，目前版本為 1.4.5。Borg 2.0 雖已進入測試階段多年，但仍標記為僅供測試，因此目前應部署 1.4 版本。

儲存庫模型是真正的差異所在

restic 儲存庫本質上是一組檔案目錄：包含 config、keys/、snapshots/、index/ 以及裝滿 pack 檔案的 data/。讀取儲存庫無需其他額外條件，這正是 restic 能支援眾多後端的原因。任何能執行 put、get、list 與 delete blob 操作的儲存空間皆可存放 restic 儲存庫；這也是為何單一執行檔即可支援本機路徑、SFTP、專屬 REST server、S3、Backblaze B2、Azure、Google Cloud Storage 以及任何 rclone 可存取的目標。

Borg 儲存庫同樣由磁碟上的檔案組成，但 Borg 從不透過簡易傳輸協定（dumb transport）與其溝通。若為遠端儲存庫，Borg 會透過 SSH 在遠端啟動 borg serve，並與該程序進行專屬協定通訊。伺服器端負責實際運算：維護儲存庫、執行交易並回應索引查詢。這就是為何穩定的 Borg 1.4 系列沒有 S3 後端的原因，因為在儲存桶（bucket）內無法執行任何程序。Borg 2 改變了此架構：它將儲存層移至名為 borgstore 的新層級，其文件描述了 sftp://、rclone:remote:path 與 s3: 或 b2: 格式的儲存庫 URL。然而，Borg 2 目前仍處於測試階段，專案官方建議勿用於生產環境，因此就目前的實際備份需求而言，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 或更新版本。目前建立新儲存庫時，預設皆採用 format 2，並透過 --compression 設定五種壓縮值之一：auto（預設值）、off、fastest、better 或 max。fastest 與 better 模式於 restic 0.19.0 引入，因此較舊的執行檔僅支援 auto、off 與 max。舊有的 format 1 儲存庫在遷移前將保持不壓縮狀態。因此，若您的 restic 儲存庫建立於 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）環境下，兩者效能相近，最終皆受限於來源端的讀取與雜湊（hash）速度。若透過高延遲的 SSH 連線處理大量小檔案，Borg 通常表現較佳，因為遠端的 borg serve 程序可直接回應索引查詢，無需針對每個區塊進行網路來回傳輸。若目標為物件儲存（object storage），restic 通常勝出，因為穩定版的 Borg 無法直接支援此類儲存。

BorgBackup 能備份到 S3 或 Backblaze B2 嗎？

穩定版的 1.4 系列無法支援。Borg 1.4 的儲存庫（repository）需透過 SSH 上的 borg serve 程序提供服務，而該程序無法在儲存桶（bucket）內執行。Borg 2 透過其 borgstore 層新增了 s3:、b2: 與 rclone: 儲存庫 URL，但截至 2026 年 10 月，Borg 2 仍處於測試階段，官方建議勿用於生產環境。針對 1.4 版本，使用者通常透過 rclone 將物件儲存掛載為檔案系統來解決此限制。Borg 常見問題集（FAQ）建議不要將網路檔案系統用於儲存庫，並警告 FUSE 與網路檔案系統可能導致效能低落或資料損毀。若您目前需要在生產環境使用物件儲存進行備份，請使用 restic。

我可以對同一份資料同時使用這兩套工具嗎？

可以，有些人確實這麼做：使用 Borg 備份至第二台伺服器以實現快速本地還原，並使用 restic 備份至物件儲存作為異地備份。由於兩者互不干涉，您需支付兩倍的讀取與雜湊成本，並需妥善保管兩組密碼。請務必在確認兩者的還原程序皆測試無誤後，才採取此方案。

如果遺失儲存庫密碼會發生什麼事？

兩套工具的資料皆無法復原。restic 使用 scrypt 從密碼衍生金鑰，且無任何繞過機制。Borg 在 repokey 模式下將加密金鑰儲存於儲存庫內，僅需密碼即可還原；而在 keyfile 模式下，您還需要來自 ~/.config/borg/keys/ 的金鑰檔案。請將密碼存放在備份伺服器以外的密碼管理員中，若使用 keyfile，請務必透過 borg key export 匯出 Borg 金鑰。

我應該等待 Borg 2.0 嗎？

不需要。截至 2026 年 10 月，Borg 2.0 仍處於測試階段（版本為 2.0.0b25，於 2026 年 9 月 27 日發布），專案組將其標記為僅供測試使用。目前的穩定系列為 1.4（現為 1.4.5）。請現在就開始使用 1.4 版本。Borg 2 變更了儲存庫格式並提供已記錄的升級路徑（borg transfer --from-borg1），因此現在開始使用並不會導致未來無法升級。待 Borg 2 穩定後，將會原生支援 S3、B2 與 rclone。