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

Restic và BorgBackup, trong một đoạn

Restic và BorgBackup đều thực hiện cùng một nhiệm vụ cốt lõi: backup incremental, mã hóa và deduplication cho máy chủ Linux. Khác biệt quyết định lựa chọn là nơi lưu backup. Restic hỗ trợ native S3 và các API object storage khác, nên bucket là một target chính thức mà không cần cài gì ở đầu xa. Borg cần cài chương trình borg trên máy lưu repository, vì Borg repository được phục vụ bởi một process, không phải bởi filesystem hay API. Nếu target của bạn là object storage thì đó đã là câu trả lời. Nếu target là một máy Linux thứ hai do bạn kiểm soát, Borg là một lựa chọn phù hợp và thường nhanh hơn.

Các khác biệt còn lại nhỏ hơn. Cả hai đều chia file bằng content-defined chunking, nên một directory 40 GB chỉ thay đổi 200 MB sẽ upload khoảng 200 MB. Cả hai đều mã hóa trên client. Cả hai đều mount snapshot bằng FUSE (filesystem trong userspace) để bạn có thể copy một file ra ngoài. Tính đến July 2026, restic đang ở phiên bản 0.19.1 và stable series của Borg là 1.4, cụ thể là 1.4.5. Borg 2.0 đã ở trạng thái beta trong nhiều năm và vẫn chỉ được đánh dấu là testing, vì vậy hiện tại bạn nên deploy 1.4.

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

Một restic repository là một thư mục chứa các file: config, keys/, snapshots/, index/ và data/, bên trong chứa đầy các pack file. Không cần thêm gì khác để đọc repository này. Vì vậy restic có thể làm việc với rất nhiều backend. Bất kỳ storage nào có thể ghi, đọc, liệt kê và xóa blob đều có thể lưu một restic repository. Nhờ đó, một binary hỗ trợ local path, SFTP, REST server riêng của restic, S3, Backblaze B2, Azure, Google Cloud Storage và mọi storage mà rclone truy cập được.

Borg repository cũng là các file trên disk, nhưng Borg không bao giờ truy cập repository qua một transport đơn giản. Với repository từ xa, Borg khởi chạy borg serve ở phía máy chủ qua SSH và dùng protocol riêng để giao tiếp với process đó. Phía server thực hiện công việc thực tế: lưu repository, áp dụng transaction và trả lời các truy vấn về index. Đây là lý do Borg không có S3 backend và project cũng chưa thêm backend này. Không có process nào để chạy bên trong bucket.

Chỉ một khác biệt trong thiết kế này đã tạo ra phần lớn các khác biệt thực tế bên dưới.

# 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à vì sao restic bổ sung tính năng này muộn

Borg đã hỗ trợ nén ngay từ đầu. Mặc định là lz4, vì tốc độ đủ nhanh để bật cho mọi dữ liệu. zstd chấp nhận các mức từ 1 đến 22 và mặc định là 3, zlib và lzma phù hợp khi bạn quan tâm đến dung lượng hơn thời gian, còn auto phân tích từng chunk để không nén lại dữ liệu vốn đã được nén.

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

Restic không hỗ trợ nén cho đến repository format 2, yêu cầu restic 0.14.0 trở lên. Hiện format 2 là mặc định khi tạo repository mới. Bạn bật nén bằng --compression với các giá trị auto, off hoặc max. Repository format 1 cũ vẫn không được nén cho đến khi bạn migrate. Vì vậy, nếu repository restic của bạn được tạo trước 0.14 và bạn chưa migrate, text, log và database dump vẫn chiếm toàn bộ dung lượng.

Đí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 LAN nhanh, tốc độ của hai công cụ gần như tương đương. Cả hai thường bị giới hạn bởi tốc độ đọc và tốc độ hash trên nguồn. Borg thường nhanh hơn qua kết nối SSH có độ trễ cao khi có rất nhiều file nhỏ, vì một tiến trình borg serve ở phía bên kia trả lời các truy vấn index mà không cần một network round trip cho mỗi chunk. restic thường nhanh hơn khi đích là object storage, nơi Borg hoàn toàn không thể sử dụng trực tiếp.

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

Không trực tiếp. Một Borg repository được tiến trình borg serve cung cấp qua SSH, nhưng không có tiến trình như vậy chạy bên trong bucket. Cách workaround phổ biến là mount object storage dưới dạng filesystem bằng rclone. Borg project không khuyến nghị cách này, vì một mount bị mất giữa transaction có thể làm hỏng repository. Nếu cần object storage, hãy dùng restic.

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

Có. Một số người vẫn làm như vậy: dùng Borg để backup lên server thứ hai nhằm restore cục bộ nhanh, và dùng restic để backup lên object storage làm bản sao offsite. Hai công cụ không dùng chung dữ liệu nội bộ nào, nên bạn phải trả giá đọc và hash hai lần, đồng thời phải lưu an toàn hai password. Chỉ nên làm vậy sau khi đã kiểm thử cả hai lần restore.

Điều gì xảy ra nếu mất password của repository?

Dữ liệu sẽ không thể khôi phục với cả hai công cụ. restic dùng scrypt để sinh key từ password và không có cách bypass. Ở chế độ repokey của Borg, key đã mã hóa được lưu bên trong repository, nên chỉ cần passphrase là có thể restore. Ở chế độ keyfile, bạn còn cần key file từ ~/.config/borg/keys/. Hãy lưu password trong một password manager không nằm trên server được backup, đồng thời export Borg key bằng borg key export nếu bạn dùng keyfile.

Có nên chờ Borg 2.0 không?

Không. Tính đến July 2026, Borg 2.0 vẫn đang ở giai đoạn beta, tại phiên bản 2.0.0b22, và project chỉ đánh dấu phiên bản này để testing. Dòng stable là 1.4, hiện tại là 1.4.5. Hãy bắt đầu với 1.4 ngay bây giờ. Borg 2 thay đổi repository format và cung cấp upgrade path được document, nên bắt đầu hôm nay sẽ không khiến bạn bị mắc kẹt.