Restic hay BorgBackup: bạn nên chạy cái nào?

So sánh Restic và BorgBackup

Restic và BorgBackup đều thực hiện cùng một công việc cốt lõi: sao lưu tăng dần, có mã hóa và chống trùng lặp (deduplication) cho máy chủ Linux. Sự khác biệt quyết định lựa chọn nằm ở đích đến của bản sao lưu. Restic hỗ trợ native S3 và các API lưu trữ đối tượng (object storage) khác, vì vậy một bucket là đích đến trực tiếp mà không cần cài đặt gì ở phía bên kia. Borg bản ổn định cần chương trình borg được cài đặt trên máy lưu trữ repository, vì repository của Borg được phục vụ bởi một tiến trình chứ không phải bởi filesystem hay API. Nếu đích đến của bạn là object storage, đó chính là câu trả lời. Nếu đích đến là một máy Linux thứ hai do bạn quản lý, Borg là lựa chọn khả thi và thường nhanh hơn.

Mọi yếu tố khác chỉ là khác biệt nhỏ. Cả hai đều chia nhỏ file bằng cơ chế content-defined chunking, nên một thư mục 40 GB thay đổi 200 MB thì chỉ cần upload khoảng 200 MB. Cả hai đều mã hóa tại client. Cả hai đều cho phép mount snapshot bằng FUSE (filesystem in userspace) để bạn có thể copy lẻ một file ra ngoài. Tính đến tháng 10 năm 2026, restic đang ở phiên bản 0.19.1 và dòng ổn định của Borg là 1.4, tại bản 1.4.5. Borg 2.0 đã ở trạng thái beta nhiều năm và vẫn chỉ được đánh dấu là bản thử nghiệm, vì vậy 1.4 là phiên bản bạn nên triển khai hiện nay.

Mô hình repository là điểm khác biệt thực sự

Một repository của restic là một thư mục chứa các file: config, keys/, snapshots/, index/ và data/ chứa đầy các pack file. Không cần gì khác để đọc nó. Đó là lý do tại sao restic có thể vận hành trên nhiều backend như vậy. Bất kỳ kho lưu trữ nào có thể thực hiện các thao tác put, get, list và delete các blob đều có thể chứa một repository restic. Đây là cách một binary duy nhất hỗ trợ các đường dẫn cục bộ, SFTP, REST server riêng, S3, Backblaze B2, Azure, Google Cloud Storage và bất cứ thứ gì rclone có thể kết nối.

Một repository của Borg cũng là các file trên đĩa, nhưng Borg không bao giờ giao tiếp với nó qua một transport đơn giản. Đối với repository từ xa, Borg khởi chạy borg serve ở phía bên kia qua SSH và sử dụng giao thức riêng để nói chuyện với tiến trình đó. Phía server thực hiện công việc thực tế: nó lưu trữ repository, áp dụng transaction và trả lời các câu hỏi về index. Đây là lý do tại sao dòng Borg 1.4 ổn định không có backend S3. Không có tiến trình nào để chạy bên trong một bucket. Borg 2 thay đổi điều này: nó chuyển việc lưu trữ vào một lớp mới gọi là borgstore, và tài liệu của nó mô tả các URL repository sftp://, rclone:remote:path và s3: hoặc b2:. Tuy nhiên, Borg 2 vẫn đang ở bản beta mà dự án khuyến cáo không nên dùng trong môi trường production, vì vậy đối với các bản backup thực tế hiện nay, lỗ hổng S3 vẫn còn đó.

Chính sự thật về thiết kế đơn lẻ đó tạo ra hầu hết các khác biệt thực tế dưới đây.

# 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

Mã hóa: có thể tắt một bên

Restic luôn mã hóa. Restic không có chế độ không mã hóa. restic init yêu cầu mật khẩu, dùng scrypt để dẫn xuất key từ mật khẩu đó, sau đó mọi pack file được ghi đều được mã hóa và xác thực. Nếu mất mật khẩu thì dữ liệu cũng mất, vì theo thiết kế không có cách khôi phục.

Borg cho chọn mã hóa khi tạo repository, và lựa chọn này là vĩnh viễn. borg init --encryption=repokey lưu key đã mã hóa bên trong repository, nên chỉ cần passphrase là có thể khôi phục. --encryption=keyfile lưu key trên client trong ~/.config/borg/keys/, nên ngay cả khi ai đó lấy cắp toàn bộ repository thì họ vẫn không có key; vì vậy bạn phải backup riêng file key đó, nếu không archive sẽ không thể đọc được. Mỗi mode đều có biến thể -blake2, dùng BLAKE2b để xác thực thay cho HMAC-SHA256. Biến thể này nhanh hơn trên phần cứng không có tăng tốc SHA. --encryption=none cũng tồn tại. Đây là lựa chọn phù hợp khi repository nằm trên encrypted disk do bạn sở hữu.

Quy tắc thực tế: dùng repokey-blake2 cho backup server thông thường, dùng keyfile khi repository nằm ở nơi bạn không hoàn toàn tin cậy, và không bao giờ dùng none trên máy thuê.

Nén dữ liệu và lý do restic cập nhật tính năng này muộn

Borg đã hỗ trợ nén dữ liệu ngay từ đầu. Mặc định là lz4, được chọn vì tốc độ đủ nhanh để bật cho mọi tác vụ. zstd chấp nhận các mức từ 1 đến 22 với mặc định là 3, zlib và lzma dành cho các trường hợp bạn ưu tiên dung lượng lưu trữ hơn thời gian xử lý, còn auto chạy một thuật toán heuristic trên từng chunk để dữ liệu đã nén sẵn không bị nén lại lần nữa.

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

Restic hoàn toàn không có tính năng nén cho đến khi repository format 2 ra đời, yêu cầu restic phiên bản 0.14.0 trở lên. Format 2 hiện là mặc định cho các repository mới, và tính năng nén được thiết lập bằng --compression với một trong năm giá trị: auto (mặc định), off, fastest, better hoặc max. Các chế độ fastest và better xuất hiện từ restic 0.19.0, vì vậy các bản binary cũ hơn chỉ chấp nhận auto, off và max. Một repository format 1 cũ sẽ không được nén cho đến khi bạn thực hiện migrate. Do đó, nếu repository restic của bạn được tạo trước bản 0.14 và bạn chưa từng migrate, bạn vẫn đang tốn dung lượng tối đa cho các file văn bản, log và bản dump cơ sở dữ liệu.

Đích từ xa: S3 và SSH

Đây thường là yếu tố quyết định lựa chọn.

restic kết nối đến S3 cần credentials trong environment và không cần chạy thêm thành phần nào ở nơi khác. Cách này cũng áp dụng cho bucket do bạn tự host. Đây là mô hình kết hợp phổ biến: chạy MinIO cung cấp S3 API trên VPS của bạn rồi trỏ restic đến đó.

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 kết nối đến repository từ xa cần SSH và một bản cài Borg ở phía máy chủ từ xa. Phiên bản Borg ở đó cũng phải tương thích với client. Đây là điểm bất tiện nếu máy chủ từ xa không thuộc quyền quản trị của bạn. Nếu đó là server thứ hai mà bạn đã quản trị thì không có vấn đề gì. Mô hình này còn cung cấp cơ chế kiểm soát mạnh nhất để chống ransomware mà một trong hai công cụ có thể cung cấp: SSH key chỉ cho phép append. Buộc key chạy borg serve để client có thể thêm archive nhưng không thể xóa chúng. Vì vậy, máy bị breach không thể xóa lịch sử backup của chính nó.

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

restic chỉ có cơ chế tương đương khi bạn chạy REST server riêng của nó, với hỗ trợ chế độ chỉ cho phép append. Với S3 thông thường, bạn đạt hiệu ứng tương tự bằng bucket policy hoặc object lock. Đây là trách nhiệm của provider, không phải của restic. Hãy khóa chặt cả transport, vì phần SSH này cần được bảo vệ như mọi phiên đăng nhập khác: áp dụng SSH chỉ dùng key với mục authorized_keys bị giới hạn cho backup account.

Tốc độ: mỗi thiết kế có ý nghĩa gì

Cả hai dự án đều không công bố benchmark mà bạn nên tin tưởng cho dữ liệu của mình, vì vậy hãy suy luận từ cơ chế hoạt động.

Borg over SSH nhanh trên đường truyền có độ trễ cao vì phía server có khả năng xử lý thông minh. Client gửi một truy vấn, tiến trình borg serve ở remote trả lời từ index của repository, và transaction được commit tại một nơi. Việc tra cứu chunk không biến thành một round trip qua network cho từng file nhỏ.

Restic trên object storage không có server side, nên phải dựng thông tin trạng thái từ các file index và pack file được tải qua HTTP. Để giữ số lượng request ở mức hợp lý, restic đóng gói nhiều chunk nhỏ vào các pack file lớn hơn trước khi upload. Nó cũng giữ local cache trong ~/.cache/restic để lần chạy tiếp theo không phải tải lại toàn bộ index. Nếu xóa cache đó, lần backup tiếp theo sẽ chậm trong khi restic dựng lại cache. Trên đường truyền có độ trễ cao với hàng triệu file nhỏ, đây là trường hợp restic có cảm giác chậm hơn Borg khi xử lý cùng một dữ liệu.

Trên disk cục bộ hoặc LAN nhanh, chênh lệch này phần lớn biến mất. Khi đó, cả hai tool thường bị giới hạn bởi tốc độ đọc và hash source.

Khóa và backup nhiều máy

Borg 1.4 khóa độc quyền repository trong toàn bộ quá trình. Hai client cùng ghi vào một repository sẽ không hoạt động: client thứ hai phải chờ, rồi fail do timeout khi chờ lock. Cách được hỗ trợ là dùng một repository cho mỗi client. Điều đó cũng có nghĩa là deduplication chỉ diễn ra bên trong repository của một máy. Vì vậy, mười server gần như giống nhau sẽ lưu mười bản sao của cùng một hệ thống cơ sở.

Restic cho phép nhiều client cùng backup vào một repository vì thao tác backup dùng shared lock, còn chỉ các tác vụ maintenance như prune mới dùng exclusive lock. Mười server tương tự cùng trỏ đến một repository của restic sẽ deduplicate lẫn nhau. Server thứ hai trở đi thường chỉ lưu thêm rất ít dữ liệu. Đổi lại là phạm vi ảnh hưởng lớn hơn: một password và một repository chứa toàn bộ dữ liệu. Nếu mất password, bạn sẽ mất quyền truy cập vào cả mười server.

Retention: forget và prune so với prune và compact

Cả hai công cụ đều tách việc “quyết định cần giữ lại gì” khỏi việc “thu hồi dung lượng”, và bạn phải chạy bước thứ hai.

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

Cạm bẫy trong cả hai công cụ là như nhau và cần nói rõ. Trong Borg, borg prune xóa archive nhưng tự nó không giải phóng dung lượng đĩa. Dung lượng chỉ được trả lại khi chạy borg compact. Vì vậy, cron job chỉ prune mà không compact sẽ khiến repository tăng dung lượng mãi, trong khi danh sách archive vẫn ngắn. Trong restic, forget nếu không đi kèm --prune chỉ xóa các tham chiếu đến snapshot; dữ liệu vẫn còn cho đến khi chạy prune.

Chạy restic check sau khi prune. Lệnh này kiểm tra cấu trúc repository và cho biết repository có bị hỏng hay không. Phát hiện lỗi theo cách này tốt hơn nhiều so với chỉ biết lỗi khi đang restore.

Khôi phục, đây mới là bài kiểm tra có ý nghĩa

Cả hai công cụ đều mount một snapshot để bạn có thể duyệt nội dung. Đây là cách nhanh nhất để lấy lại một file.

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

Lưu ý dạng đường dẫn trong borg extract. Các đường dẫn bên trong archive được lưu không có dấu slash ở đầu, vì vậy etc/nginx là đúng, còn /etc/nginx không khớp với gì và không trích xuất được gì; công cụ cũng không báo lỗi để cho biết lý do. Quá trình trích xuất cũng ghi vào thư mục làm việc hiện tại, vì vậy hãy chuyển sang một thư mục tạm trước. Nếu không, bạn có thể ghi đè file đang dùng bằng các bản cũ.

Một lần khôi phục hoàn tất mà không báo lỗi vẫn chưa chứng minh được hệ thống đã khôi phục đúng, vì application bên trên có tiêu chí riêng về một lần khôi phục hoàn chỉnh: một Immich server được dựng lại từ bản sao của Postgres data directory sẽ có đầy đủ ảnh trên disk nhưng timeline không hiển thị gì. Đây chính là lỗi mà việc backup và khôi phục Immich phải xử lý.

Dù chọn công cụ nào, schedule chỉ mới hoàn thành một nửa công việc. Hãy chạy khôi phục vào một thư mục tạm theo timer mà bạn thực sự theo dõi, giống như walkthrough đầy đủ trong hướng dẫn backup restic cho VPS thực hiện bằng systemd timer.

Công cụ nào phù hợp với công việc nào

Chọn restic khi đích là object storage, khi bạn muốn chỉ dùng một binary và không cài phần mềm ở phía bên kia, khi nhiều máy cần deduplicate với nhau, hoặc khi người khôi phục dữ liệu có thể không phải là bạn. Đây là một static binary duy nhất, chỉ cần URL của repository. Xét về vận hành, cách này rất khó bị đánh bại.

Chọn Borg khi đích là một máy Linux do bạn kiểm soát, khi đường truyền có độ trễ và dataset chứa hàng triệu file nhỏ, khi bạn muốn dùng SSH key chỉ cho phép append để chống ransomware, hoặc khi muốn tinh chỉnh compression cho từng job. Đây là công cụ lâu đời hơn. Dòng phiên bản ổn định của nó thay đổi chậm. Với phần mềm backup, đó là một ưu điểm.

Cả hai đều là lựa chọn đúng. Lựa chọn sai là lựa chọn bạn chưa bao giờ test. Nếu bạn đã tạo application-level dump, hãy giữ lại chúng. Mẫu trong cấu hình Nextcloud trên Docker kèm database dump áp dụng cho cả hai công cụ, vì một file database được copy tại một thời điểm ngẫu nhiên khi database đang chạy không phải là bản backup của database.

FAQ

Restic hay BorgBackup nhanh hơn?

Trên ổ đĩa cục bộ hoặc mạng LAN tốc độ cao, hiệu năng của cả hai khá tương đồng và đều bị giới hạn bởi tốc độ đọc và băm (hash) tại nguồn. Borg thường chiếm ưu thế hơn qua kết nối SSH có độ trễ cao với nhiều file nhỏ, vì tiến trình borg serve ở phía xa có thể trả lời các truy vấn chỉ mục mà không cần thực hiện round trip mạng cho từng chunk. Restic thường nhanh hơn khi đích đến là object storage, nơi mà phiên bản Borg ổn định không hỗ trợ.

BorgBackup có thể backup lên S3 hoặc Backblaze B2 không?

Không, với dòng 1.4 ổn định. Repository của Borg 1.4 được phục vụ bởi tiến trình borg serve qua SSH, và không có tiến trình nào như vậy chạy bên trong bucket. Borg 2 bổ sung các URL repository s3:, b2: và rclone: thông qua lớp borgstore, nhưng tính đến tháng 10 năm 2026, Borg 2 vẫn đang ở giai đoạn beta và dự án khuyến cáo không nên sử dụng trong môi trường production. Với bản 1.4, người dùng thường giải quyết vấn đề này bằng cách mount object storage thành filesystem thông qua rclone. FAQ của Borg khuyên không nên dùng network filesystem cho repository và cảnh báo rằng FUSE cùng các filesystem mạng có thể gây chậm hoặc hỏng dữ liệu. Nếu bạn cần dùng object storage cho backup production ngay lúc này, hãy dùng restic.

Tôi có thể chạy cả hai công cụ trên cùng một tập dữ liệu không?

Có, và một số người đã làm như vậy: dùng Borg backup sang server thứ hai để khôi phục nhanh tại chỗ, và dùng restic backup sang object storage để lưu trữ offsite. Chúng không chia sẻ bất kỳ dữ liệu nào với nhau, vì vậy bạn sẽ phải tốn chi phí đọc và băm dữ liệu hai lần, đồng thời phải quản lý hai mật khẩu riêng biệt. Chỉ thực hiện việc này nếu bạn đã kiểm tra kỹ quy trình khôi phục của cả hai.

Điều gì xảy ra nếu tôi mất mật khẩu repository?

Dữ liệu sẽ không thể khôi phục được với cả hai công cụ. Restic tạo key từ mật khẩu bằng scrypt và không có cách nào để bỏ qua. Borg ở chế độ repokey lưu trữ key đã mã hóa bên trong repository, nên chỉ cần passphrase là đủ để khôi phục; còn ở chế độ keyfile, bạn cần thêm file key từ ~/.config/borg/keys/. Hãy lưu mật khẩu vào một trình quản lý mật khẩu không nằm trên server đang được backup, và export key của Borg bằng borg key export nếu bạn sử dụng keyfile.

Tôi có nên đợi Borg 2.0 không?

Không. Tính đến tháng 10 năm 2026, Borg 2.0 vẫn đang ở giai đoạn beta, phiên bản 2.0.0b25 (phát hành ngày 27 tháng 9 năm 2026), và dự án chỉ gắn nhãn nó cho mục đích thử nghiệm. Dòng ổn định hiện tại là 1.4, phiên bản 1.4.5. Hãy bắt đầu với 1.4 ngay bây giờ. Borg 2 thay đổi định dạng repository và cung cấp lộ trình nâng cấp có tài liệu hướng dẫn (borg transfer --from-borg1), nên việc bắt đầu từ hôm nay sẽ không khiến bạn bị kẹt lại. Borg 2 cũng là nơi hỗ trợ native cho S3, B2 và rclone sẽ xuất hiện khi nó đạt trạng thái ổn định.