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à loại bỏ dữ liệu trùng lặp cho máy chủ Linux. Yếu 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à target chính thức mà không cần cài gì ở đầu bên kia. Borg cần cài chương trình borg trên máy chứa 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 quản lý, Borg là lựa chọn phù hợp 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 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 tháng 7 năm 2026, restic ở phiên bản 0.19.1 còn nhánh 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, vì vậy hiện tại 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 restic repository 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ành phần nào 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ỳ nơi lưu trữ nào có thể put, get, list và delete blob đều có thể chứa một restic repository. Đây là cách một binary hỗ trợ local path, SFTP, REST server riêng, S3, Backblaze B2, Azure, Google Cloud Storage và mọi nơi 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 động borg serve ở đầu bên kia 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ế: giữ repository, áp dụng transaction và trả lời các truy vấn index. Đây là lý do Borg không có S3 backend và project chưa bổ sung 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: một trong hai công cụ có thể tắt mã hóa

Restic luôn mã hóa dữ liệu. 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 đó, rồi mã hóa và xác thực mọi pack file được ghi sau đó. Nếu mất mật khẩu, dữ liệu cũng mất vì thiết kế của Restic không có cơ chế 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ó key; bạn phải backup 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 và là lựa chọn phù hợp khi repository nằm trên một disk đã mã hóa 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à tuyệt đối không dùng none trên máy thuê.

Nén dữ liệu và lý do restic hỗ trợ 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, còn zlib và lzma phù hợp khi bạn ưu tiên giảm số byte hơn thời gian chạy; auto áp dụng heuristic cho từng chunk để không nén lần thứ hai những 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, và bạn thiết lập 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 nó. 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 đầy đủ 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. Mô hình tương tự 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 máy chủ từ xa. 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 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 đang quản trị thì việc này không đáng kể. Đổ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 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 quả 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. Đồng thời, hãy khóa chặt transport, vì phần SSH này cần được bảo vệ như mọi cơ chế login khác: áp dụng SSH chỉ dùng key với mục authorized_keys bị giới hạn cho tài khoản backup.

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 là sẽ áp dụ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 câu hỏi, tiến trình borg serve từ xa trả lời dựa trên repository index, rồi 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 mạng cho từng file nhỏ.

Restic trên object storage không có server side, nên phải dựng thông tin từ các index file và pack file được tải qua HTTP. Để giữ số lượng request ở mức hợp lý, restic gộp nhiều chunk nhỏ vào các pack file lớn hơn trước khi upload, đồng thời giữ cache cục bộ tại ~/.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 trên cùng dữ liệu.

Trên disk cục bộ hoặc LAN nhanh, chênh lệch này phần lớn không còn đáng kể. Cả hai công cụ cuối cùng đều bị giới hạn 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ộ quá trình thao tác. Hai client cùng ghi vào một repository tại cùng thời điểm sẽ không hoạt động: client thứ hai chờ, rồi thất bại do hết thời gian chờ lock. Mô hình đượ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 từng máy, nên 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 sao lưu vào cùng một repository tại cùng thời điểm, vì thao tác sao lưu dùng shared lock và chỉ các tác vụ bảo trì như prune mới dùng exclusive lock. Mười server tương tự cùng trỏ đến một repository Restic sẽ deduplicate dữ liệu của nhau; từ server thứ hai trở đi thường chỉ lưu thêm rất ít dữ liệu. Đổi lại là blast radius lớn hơn: một password và một repository chứa toàn bộ dữ liệu, nên nếu mất password thì mất quyền truy cập vào cả mười máy.

Lưu giữ: forget rồi prune, so với prune rồi 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à cả hai đều yêu cầu bạn 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

Điểm dễ mắc lỗi ở cả hai công cụ là như nhau và cần 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 mãi, dù danh sách archive vẫn ngắn. Trong restic, forget nếu không chạy cùng --prune chỉ xóa các tham chiếu đến snapshot; dữ liệu vẫn còn cho đến khi chạy prune.

Hãy 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ó dữ liệu bị hỏng. Cách này tốt hơn nhiều so với việc chỉ phát hiện lỗi khi restore.

Khôi phục mới là bài kiểm tra duy nhất có giá trị

Cả hai công cụ đều mount 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 gạch chéo ở đầu, vì vậy etc/nginx là đúng; /etc/nginx không khớp gì và không extract gì, nhưng không có lỗi nào cho biết lý do. Quá trình extraction cũng ghi vào thư mục làm việc hiện tại, vì vậy hãy chuyển vào một thư mục scratch trước. Nếu không, bạn có thể ghi đè các file đang dùng bằng bản cũ.

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

Chọn công cụ nào cho 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 ở đầu bên kia, khi nhiều máy cần deduplicate dữ liệu của 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. Về mặt vận hành, rất khó có lựa chọn đơn giản hơn.

Chọn Borg khi đích là một máy Linux do bạn quản lý, 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 append-only để chống ransomware, hoặc khi muốn tinh chỉnh compression cho từng job. Đây là công cụ ra đời trước, 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ờ test. Nếu bạn đã tạo application-level dump, hãy tiếp tục duy trì chúng: mô hình trong thiết lập Nextcloud trên Docker với database dump áp dụng cho cả hai công cụ, vì copy một file database đang được sử dụng tại một thời điểm bất kỳ không tạo thành bản backup của database.

FAQ

Restic hay BorgBackup nhanh hơn?

Trên ổ đĩa cục bộ hoặc LAN nhanh, hai công cụ này gần như tương đương. Cả hai thường bị giới hạn bởi tốc độ đọc và tốc độ băm trên 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ì tiến trình borg serve ở phía xa có thể xử lý các truy vấn index mà không cần một network round trip cho từng chunk. Restic thường nhanh hơn khi đích là object storage, nơi Borg hoàn toàn không thể ghi 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 phục vụ bởi tiến trình borg serve qua SSH, trong khi 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 thành filesystem bằng rclone. Tuy nhiên, Borg project 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 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 chia sẻ dữ liệu backup, nên bạn phải trả chi phí đọc và băm hai lần, đồng thời phải lưu an toàn 2 password. Chỉ làm vậy sau khi đã kiểm thử cả hai lần restore.

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

Dữ liệu sẽ không thể khôi phục bằng cả hai công cụ. Restic dùng scrypt để dẫn xuất key từ password và không có cách bypass. Ở chế độ repokey của Borg, encrypted key được lưu bên trong repository, nên chỉ cần passphrase là có thể restore. Ở chế độ keyfile, bạn cũng cần key file từ ~/.config/borg/keys/. Hãy lưu password trong password manager không nằm trên server được backup, và export Borg key 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, 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ó tài liệu, nên bắt đầu hôm nay không khiến bạn bị mắc kẹt.