Restic hay BorgBackup: 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, được mã hóa và deduplication cho server Linux. Điểm 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 object storage API khác, nên bucket là một target đầy đủ mà không cần cài gì ở đầu bên kia. Borg yêu cầu cài chương trình borg trên máy chứa repository, vì Borg repository được cung cấp bởi một process, không phải bởi filesystem hoặc API. Nếu target của bạn là object storage thì đó chính là lựa chọn phù hợp. Nếu target là một máy Linux thứ hai do bạn quản lý, Borg là một lựa chọn và thường nhanh hơn.

Các điểm khác đều nhỏ hơn. Cả hai đều chia file bằng content-defined chunking, nên một thư mục 40 GB chỉ thay đổi 200 MB sẽ upload khoảng 200 MB. Cả hai đều mã hóa dữ liệu 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 tháng 7 năm 2026, restic đang ở phiên bản 0.19.1 và dòng stable 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, nên hiện nay bạn nên deploy phiên bản 1.4.

Mô hình repository mới 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/, bên trong là các pack file. Không cần thêm gì để đọc repository này. Vì vậy restic có thể làm việc với nhiều backend. Bất kỳ storage nào có thể ghi, đọc, liệt kê và xóa blob đều có thể chứa repository của restic. Nhờ đó, một binary hỗ trợ local path, SFTP, REST server riêng, S3, Backblaze B2, Azure, Google Cloud Storage và mọi đích mà rclone có thể truy cập.

Borg cũng lưu repository dưới dạng các file trên disk, nhưng Borg không truy cập repository qua một transport đơn giản. Với repository remote, Borg khởi chạy borg serve ở phía máy chủ qua SSH rồi giao tiếp bằng protocol riêng 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 index. Đây là lý do Borg không có backend S3 và project chưa bổ sung backend này. Không có process để chạy bên trong bucket.

Chỉ một quyết định thiết kế này đã tạo ra phần lớn 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 trong hai

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

Borg cho phép 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 tại ~/.config/borg/keys/, nên người lấy cắp toàn bộ repository vẫn không có gì, nhưng bạn phải sao lưu riêng file key đó; nếu không, archive sẽ không thể đọc được. Mỗi chế độ đề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 bản sao lưu 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 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 để luôn 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 kích thước quan trọng hơn thời gian. auto chạy heuristic cho từng chunk để không nén lại dữ liệu đã đượ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 đặt mức 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, bạn vẫn tốn toàn bộ dung lượng cho text, log và database dump.

Đí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. Mô hình này cũng hoạt động với bucket do bạn tự host. Đây là một cách 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 vào đó.

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à cần cài Borg ở phía bên kia. Phiên bản Borg ở đó cũng phải tương thích với client. Đây là một trở ngại nếu bạn không quản lý phía bên kia. Nếu đó là server thứ hai bạn đã quản trị thì không có vấn đề gì. Đổi lại, bạn có được cơ chế kiểm soát mạnh nhất để chống ransomware mà một trong hai công cụ này cung cấp: SSH key chỉ cho phép append. Buộc key chạy borg serve để client chỉ có thể thêm archive, không thể xóa chúng. Vì vậy, máy bị xâm nhập không thể xóa lịch sử 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ệ giống như mọi login 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 qua SSH nhanh trên đường truyền có độ trễ cao vì phía server xử lý thông minh. Client gửi một yêu cầu, tiến trình borg serve ở xa trả lời dựa trên repository index, và transaction được commit tại một nơi. Việc tra cứu chunk không biến thành các lượt round trip qua mạng cho từng file nhỏ.

Restic trên object storage không có phía server xử lý, nên phải dựng trạng thái của mình từ các index file 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, đồng thời giữ một cache cục bộ 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 vì phải 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, khoảng cách này hầu như không còn, và cả hai công cụ đều bị giới hạn chủ yếu bởi tốc độ đọc và tính hash của source.

Khóa và sao lưu nhiều máy

Borg 1.4 khóa độc quyền repository trong toàn bộ thời gian thực thi. Hai client cùng ghi vào một repository sẽ không hoạt động: client thứ hai phải chờ, sau đó thất bại vì hết thời gian chờ khóa. Mô hình được hỗ trợ là mỗi client sử dụng một repository riêng. Điều đó cũng có nghĩa là deduplication chỉ diễn ra trong repository của một máy, nên mười server gần như giống hệt 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 sao lưu vào một repository vì thao tác sao lưu chỉ cần khóa dùng chung, còn các tác vụ bảo trì như prune mới cần khóa độc quyền. Mười server tương tự nhau trỏ vào một repository restic sẽ deduplicate dữ liệu với nhau, nên 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: chỉ có một password và một repository chứa mọi thứ, nên mất password đồng nghĩa với mất cả mười bản sao lưu.

Retention: forget rồi prune, so với prune rồi compact

Cả hai công cụ đều tách riêng việc “quyết định cần giữ lại” 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ụ giống nhau và cần được nói rõ. Trong Borg, borg prune xóa các 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ỉ chạy prune mà không compact sẽ khiến repository tăng dung lượng mãi, dù danh sách archive vẫn ngắn. Trong restic, chạy forget mà không chạy --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 nếu có thành phần bị hỏng. Phát hiện lỗi ở đây tốt hơn nhiều so với việc chỉ biết lỗi khi restore.

Khôi phục là bài kiểm tra duy nhất 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 mà không có dấu gạch chéo ở đầ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 gì cả. Công cụ không báo lỗi để cho biết nguyên nhân. Thao tác trích xuất cũng ghi vào thư mục làm việc hiện tại, vì vậy trước tiên hãy chuyển sang một thư mục tạm. Nếu không, bạn sẽ ghi đè các file đang dùng bằng những bản cũ.

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

Công cụ nào phù hợp với tác vụ 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 ở đầu xa, khi nhiều máy cần deduplicate lẫn 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, dùng URL cho repository, nên rất khó bị vượt qua về mặt vận hành.

Chọn Borg khi đích là một Linux box do bạn kiểm soát, khi đường truyền có độ trễ và dataset có hàng triệu file nhỏ, khi bạn muốn dùng SSH key chỉ cho phép append làm biện pháp kiểm soát ransomware, hoặc khi muốn điều chỉnh compression riêng cho từng tác vụ. Đây là công cụ ra đời lâu hơn, stable series phát triển chậm, và trong 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ờ kiểm thử. Nếu bạn đã tạo application-level dump, hãy tiếp tục giữ chúng: cách làm trong thiết lập Nextcloud trên Docker với database dump áp dụng cho cả hai công cụ, vì file database được sao chép tại một thời điểm bất kỳ trong lúc database đang hoạt động 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 nhanh, hai công cụ này có tốc độ gần tương đương. Cả hai thường bị giới hạn bởi tốc độ đọc và tốc độ băm của dữ liệu nguồn. Borg thường nhanh hơn qua kết nối SSH có độ trễ cao và chứa rất nhiều file nhỏ, vì một tiến trình borg serve ở phía máy từ xa có thể trả lời các truy vấn chỉ mục mà không cần một lượt truyền qua mạng cho mỗi chunk. Restic thường nhanh hơn khi đích là object storage, vì Borg không thể kết nối trực tiếp đến đó.

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

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

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

Có. Một số người làm như vậy: dùng Borg để sao lưu sang server thứ hai nhằm khôi phục cục bộ nhanh, và dùng restic để sao lưu sang object storage làm bản sao ngoài site. Hai công cụ không dùng chung dữ liệu nội bộ nào. Vì vậy, bạn phải trả chi phí đọc và băm hai lần, đồng thời phải lưu an toàn hai mật khẩu. Chỉ làm vậy nếu bạn đã kiểm thử việc khôi phục bằng cả hai công cụ.

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

Dữ liệu không thể khôi phục trong cả hai công cụ. Restic dẫn xuất key từ mật khẩu bằng scrypt 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 để khôi phục. Ở chế độ keyfile, bạn cũng cần key file từ ~/.config/borg/keys/. Hãy lưu mật khẩu trong password manager không chạy trên server được sao lưu, và export key Borg bằng borg key export nếu bạn dùng keyfile.

Tôi có nên chờ Borg 2.0 không?

Không. Tính đến tháng 7 năm 2026, Borg 2.0 vẫn đang ở giai đoạn beta, bản 2.0.0b22, và dự án chỉ đánh dấu 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 format của repository và cung cấp quy trình upgrade được tài liệu hóa, nên bắt đầu hôm nay không khiến bạn bị kẹt ở phiên bản cũ.