เปรียบเทียบ Restic กับ BorgBackup เลือกตัวไหนดี

การเปรียบเทียบระหว่าง Restic และ BorgBackup

Restic และ BorgBackup ทำหน้าที่หลักเหมือนกันคือการสำรองข้อมูลแบบ incremental ที่มีการทำ deduplication และเข้ารหัสบนเซิร์ฟเวอร์ Linux โดยปัจจัยตัดสินใจเลือกคือปลายทางของการสำรองข้อมูล Restic รองรับ S3 และ API ของ object storage อื่นๆ โดยตรง ทำให้สามารถสำรองข้อมูลลง bucket ได้ทันทีโดยไม่ต้องติดตั้งซอฟต์แวร์ใดๆ ที่ปลายทาง ในขณะที่ Borg จำเป็นต้องติดตั้งโปรแกรม borg ไว้บนเครื่องที่เก็บ repository เนื่องจาก repository ของ Borg ต้องอาศัยกระบวนการทำงาน (process) ในการจัดการ ไม่ใช่แค่การเข้าถึงผ่านระบบไฟล์หรือ API ดังนั้นหากปลายทางของคุณคือ object storage คำตอบคือ Restic แต่หากปลายทางคือเซิร์ฟเวอร์ Linux อีกเครื่องที่คุณดูแลเอง Borg มักจะเป็นตัวเลือกที่เหมาะสมและทำงานได้เร็วกว่า

ความแตกต่างในด้านอื่นถือเป็นเรื่องรอง ทั้งสองโปรแกรมใช้วิธีแบ่งไฟล์แบบ content defined chunking ทำให้ไดเรกทอรีขนาด 40 GB ที่มีการเปลี่ยนแปลงเพียง 200 MB จะใช้พื้นที่อัปโหลดจริงประมาณ 200 MB ทั้งคู่รองรับการเข้ารหัสที่ฝั่งไคลเอนต์และสามารถ mount snapshot ผ่าน FUSE เพื่อคัดลอกไฟล์แยกออกมาได้ สำหรับข้อมูล ณ เดือนกรกฎาคม 2026 Restic อยู่ที่เวอร์ชัน 0.19.1 ส่วน Borg เวอร์ชันเสถียรคือ 1.4.5 สำหรับ Borg 2.0 นั้นยังคงอยู่ในสถานะทดสอบมาเป็นเวลาหลายปี ดังนั้นเวอร์ชัน 1.4 จึงเป็นเวอร์ชันที่ควรเลือกใช้งานในปัจจุบัน

รูปแบบของ repository คือความแตกต่างที่แท้จริง

repository ของ restic คือไดเรกทอรีของไฟล์ต่างๆ ได้แก่ config, keys/, snapshots/, index/ และ data/ ซึ่งเต็มไปด้วยไฟล์ pack โดยไม่จำเป็นต้องมีสิ่งอื่นใดเพิ่มเติมในการอ่านข้อมูล นี่คือเหตุผลที่ restic สามารถรองรับ backend ได้หลากหลายรูปแบบ พื้นที่จัดเก็บข้อมูลใดก็ตามที่สามารถ put, get, list และ delete ข้อมูลแบบ blob ได้ ก็สามารถเก็บ repository ของ restic ได้เช่นกัน ซึ่งเป็นวิธีที่ทำให้ binary เพียงตัวเดียวรองรับทั้ง local path, SFTP, REST server ของตนเอง, S3, Backblaze B2, Azure, Google Cloud Storage และทุกสิ่งที่ rclone สามารถเข้าถึงได้

repository ของ Borg ก็เป็นไฟล์บนดิสก์เช่นกัน แต่ Borg ไม่เคยสื่อสารกับ repository ผ่านช่องทางรับส่งข้อมูลแบบทั่วไป สำหรับ repository ระยะไกล Borg จะเริ่มการทำงานของ borg serve ที่ฝั่งปลายทางผ่าน SSH และสื่อสารด้วยโปรโตคอลของตนเองกับกระบวนการนั้น ฝั่งเซิร์ฟเวอร์จะทำหน้าที่ประมวลผลจริง คือการเก็บ repository, การทำธุรกรรม (transaction) และการตอบคำถามเกี่ยวกับดัชนี นี่คือเหตุผลที่ Borg ไม่มี backend สำหรับ S3 และเหตุผลที่โครงการยังไม่ได้เพิ่มฟีเจอร์ดังกล่าว เนื่องจากไม่มีกระบวนการใดให้รันภายใน bucket ได้

ข้อเท็จจริงในการออกแบบเพียงประการเดียวนี้ส่งผลให้เกิดความแตกต่างในทางปฏิบัติส่วนใหญ่ตามรายการด้านล่าง

# 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 ทุกไฟล์ที่เขียนหลังจากนั้นจะถูกเข้ารหัสและตรวจสอบความถูกต้อง หากทำรหัสผ่านหาย ข้อมูลจะสูญหายทันทีเนื่องจากไม่มีช่องทางกู้คืนตามการออกแบบ

Borg ให้คุณเลือกการเข้ารหัสได้ในขั้นตอนการสร้าง repository และตัวเลือกนั้นจะถาวร borg init --encryption=repokey จะเก็บคีย์ที่เข้ารหัสไว้ภายใน repository ทำให้สามารถกู้คืนได้ด้วยรหัสผ่านเพียงอย่างเดียว --encryption=keyfile จะเก็บคีย์ไว้ที่ฝั่งไคลเอนต์ใน ~/.config/borg/keys/ ดังนั้นหากมีคนขโมย repository ไปทั้งหมดก็จะไม่สามารถเข้าถึงข้อมูลได้ และคุณต้องสำรองไฟล์คีย์นั้นแยกต่างหาก มิฉะนั้นไฟล์เก็บถาวรของคุณจะอ่านไม่ได้ แต่ละโหมดจะมีตัวแปร -blake2 ที่ใช้การตรวจสอบความถูกต้องด้วย BLAKE2b แทน HMAC-SHA256 ซึ่งทำงานได้เร็วกว่าบนฮาร์ดแวร์ที่ไม่มีตัวเร่งความเร็ว SHA นอกจากนี้ยังมี --encryption=none ซึ่งเป็นตัวเลือกที่ใช้งานได้จริงเมื่อ repository อยู่บนดิสก์ที่เข้ารหัสซึ่งคุณเป็นเจ้าของเอง

กฎในทางปฏิบัติ: ใช้ repokey-blake2 สำหรับการสำรองข้อมูลเซิร์ฟเวอร์ทั่วไป ใช้ keyfile เมื่อ repository อยู่ในที่ที่คุณไม่ไว้วางใจอย่างเต็มที่ และห้ามใช้ none บนเครื่องเช่าโดยเด็ดขาด

การบีบอัดข้อมูลและเหตุผลที่ restic รองรับช้ากว่า

Borg รองรับการบีบอัดข้อมูลมาตั้งแต่เริ่มต้น โดยค่าเริ่มต้นคือ lz4 ซึ่งถูกเลือกมาเพราะมีความเร็วเพียงพอที่จะเปิดใช้งานกับทุกข้อมูล zstd รองรับระดับตั้งแต่ 1 ถึง 22 โดยมีค่าเริ่มต้นอยู่ที่ 3 ส่วน zlib และ lzma มีไว้สำหรับกรณีที่คุณให้ความสำคัญกับขนาดไฟล์มากกว่าเวลาที่ใช้ และ auto จะใช้การวิเคราะห์เชิงฮิวริสติกในแต่ละส่วนข้อมูล (chunk) เพื่อป้องกันไม่ให้ข้อมูลที่ถูกบีบอัดมาแล้วถูกบีบอัดซ้ำ

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

restic ไม่มีการบีบอัดข้อมูลเลยจนกระทั่งมีการเปลี่ยนรูปแบบ repository เป็นเวอร์ชัน 2 ซึ่งจำเป็นต้องใช้ restic เวอร์ชัน 0.14.0 ขึ้นไป ปัจจุบันรูปแบบเวอร์ชัน 2 เป็นค่าเริ่มต้นสำหรับ repository ใหม่ และการบีบอัดข้อมูลจะถูกกำหนดด้วย --compression โดยมีค่าเป็น auto, off หรือ max สำหรับ repository รูปแบบ 1 แบบเก่าจะยังคงไม่มีการบีบอัดจนกว่าคุณจะทำการย้ายข้อมูล (migrate) ดังนั้นหาก repository ของ restic ของคุณถูกสร้างขึ้นก่อนเวอร์ชัน 0.14 และคุณไม่เคยทำการย้ายข้อมูล คุณยังคงต้องเสียพื้นที่จัดเก็บเต็มจำนวนสำหรับไฟล์ข้อความ, log และไฟล์สำรองฐานข้อมูล

เป้าหมายระยะไกล: S3 เทียบกับ SSH

นี่คือจุดที่มักจะนำไปสู่การตัดสินใจเลือก

การที่ Restic เข้าถึง S3 ได้นั้นต้องการเพียงแค่ credentials ใน environment โดยไม่ต้องมีโปรแกรมอื่นทำงานที่ฝั่งปลายทาง รูปแบบเดียวกันนี้สามารถใช้กับ bucket ที่คุณโฮสต์เองได้ ซึ่งเป็นการจับคู่ที่พบบ่อย: ให้รัน MinIO เพื่อใช้ S3 API บน VPS ของคุณเอง แล้วชี้ 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 ไว้ที่ฝั่งปลายทางด้วย โดยเวอร์ชันที่ฝั่งนั้นจะต้องเข้ากันได้กับฝั่ง client ซึ่งอาจเป็นอุปสรรคหากฝั่งปลายทางไม่ใช่ของคุณ แต่จะไม่มีปัญหาเลยหากฝั่งปลายทางเป็นเซิร์ฟเวอร์เครื่องที่สองที่คุณดูแลอยู่แล้ว และวิธีนี้จะช่วยให้คุณได้รับการควบคุมที่แข็งแกร่งที่สุดในการป้องกัน ransomware ซึ่งดีกว่าเครื่องมืออื่น: นั่นคือการใช้ SSH key แบบ append only หากคุณบังคับให้ key รัน borg serve ตัว client จะสามารถเพิ่ม archive ได้แต่ไม่สามารถลบได้ ดังนั้นหากเครื่องต้นทางถูกเจาะ ก็จะไม่สามารถลบประวัติการสำรองข้อมูลของตัวเองทิ้งได้

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

Restic มีฟังก์ชันที่เทียบเท่ากันก็ต่อเมื่อคุณรัน REST server ของมันเอง ซึ่งรองรับโหมด append only สำหรับการใช้งานกับ S3 ทั่วไป คุณจะได้รับผลลัพธ์เดียวกันจากการตั้งค่า bucket policy หรือ object lock ซึ่งเป็นหน้าที่ของผู้ให้บริการไม่ใช่หน้าที่ของ Restic นอกจากนี้ควรจำกัดการเชื่อมต่อให้แน่นหนาด้วย เพราะการเข้าถึงผ่าน SSH ในกรณีนี้ควรได้รับความใส่ใจเช่นเดียวกับการล็อกอินอื่นๆ: ให้ใช้ SSH แบบใช้ key เท่านั้นพร้อมการจำกัดสิทธิ์ใน authorized_keys สำหรับบัญชีที่ใช้สำรองข้อมูล

ความเร็ว: สิ่งที่การออกแบบแต่ละแบบบ่งบอก

ไม่มีโครงการใดเผยแพร่ผลการทดสอบประสิทธิภาพที่คุณควรเชื่อถือสำหรับข้อมูลของคุณเอง ดังนั้นให้พิจารณาจากกลไกการทำงานแทน

Borg over SSH ทำงานได้รวดเร็วบนลิงก์ที่มีค่า latency สูงเนื่องจากฝั่งเซิร์ฟเวอร์มีความชาญฉลาด ไคลเอนต์จะส่งคำถามไป และกระบวนการ borg serve ที่ฝั่งรีโมทจะตอบกลับโดยอ้างอิงจากดัชนีของ repository ทำให้การทำธุรกรรมเสร็จสิ้นในจุดเดียว การค้นหา chunk จึงไม่กลายเป็นการรับส่งข้อมูลผ่านเครือข่ายไปมาสำหรับไฟล์ขนาดเล็กทุกไฟล์

Restic บน object storage ไม่มีฝั่งเซิร์ฟเวอร์ จึงต้องสร้างภาพรวมของข้อมูลจากไฟล์ดัชนีและไฟล์ pack ที่ดึงผ่าน HTTP เพื่อรักษาจำนวนคำขอให้อยู่ในระดับที่เหมาะสม มันจะรวม chunk ขนาดเล็กจำนวนมากเข้าเป็นไฟล์ pack ขนาดใหญ่ก่อนอัปโหลด และเก็บแคชไว้ในเครื่องที่ ~/.cache/restic เพื่อให้การรันครั้งถัดไปไม่ต้องดึงดัชนีทั้งหมดใหม่ หากคุณลบแคชนั้น การสำรองข้อมูลครั้งถัดไปจะช้าลงในขณะที่ระบบสร้างแคชขึ้นใหม่ บนลิงก์ที่มีค่า latency สูงและมีไฟล์ขนาดเล็กจำนวนหลายล้านไฟล์ นี่คือกรณีที่ restic จะรู้สึกช้ากว่า Borg เมื่อใช้กับข้อมูลชุดเดียวกัน

บนดิสก์ภายในหรือ LAN ความเร็วสูง ช่องว่างด้านประสิทธิภาพจะลดลงจนแทบไม่ต่างกัน และเครื่องมือทั้งสองจะถูกจำกัดด้วยความเร็วในการอ่านและทำ hash ข้อมูลต้นทางเป็นหลัก

การล็อกและการสำรองข้อมูลหลายเครื่อง

Borg 1.4 จะทำการล็อก repository แบบเอกสิทธิ์ (exclusive lock) ตลอดระยะเวลาการทำงาน การที่ไคลเอนต์สองเครื่องเขียนข้อมูลลงใน repository เดียวกันในเวลาเดียวกันนั้นไม่สามารถทำได้ โดยไคลเอนต์ตัวที่สองจะรอและล้มเหลวด้วยข้อผิดพลาด lock timeout รูปแบบที่รองรับคือหนึ่ง repository ต่อหนึ่งไคลเอนต์ ซึ่งหมายความว่าการทำ deduplication จะเกิดขึ้นภายใน repository ของเครื่องนั้นๆ เท่านั้น ดังนั้นเซิร์ฟเวอร์ที่เหมือนกัน 10 เครื่องจะจัดเก็บสำเนาของระบบพื้นฐานเดียวกันไว้ถึง 10 ชุด

Restic อนุญาตให้ไคลเอนต์หลายเครื่องสำรองข้อมูลลงใน repository เดียวกันได้ในเวลาเดียวกัน เนื่องจากการสำรองข้อมูลจะใช้การล็อกแบบแชร์ (shared lock) และจะมีเพียงงานบำรุงรักษา เช่น prune เท่านั้นที่ต้องใช้การล็อกแบบเอกสิทธิ์ เซิร์ฟเวอร์ที่คล้ายกัน 10 เครื่องที่ชี้ไปยัง restic repository เดียวกันจะทำ deduplication ข้ามกันได้ ทำให้เซิร์ฟเวอร์เครื่องที่สองเป็นต้นไปมักจะใช้พื้นที่จัดเก็บข้อมูลน้อยมาก ข้อแลกเปลี่ยนคือขอบเขตความเสียหาย (blast radius): หากมีรหัสผ่านเดียวและ repository เดียวที่เก็บข้อมูลทั้งหมด การทำรหัสผ่านหายจะส่งผลให้สูญเสียข้อมูลของทั้ง 10 เครื่องไปพร้อมกัน

การเก็บรักษาข้อมูล: การลบและย่อขนาด (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 จะลบ archive ออกไปแต่ไม่ได้คืนพื้นที่ดิสก์ด้วยตัวมันเอง พื้นที่จะถูกเรียกคืนเมื่อรัน borg compact ดังนั้นหากคุณตั้งค่า cron job ให้ทำเพียงการ prune โดยไม่ทำ compact จะทำให้ repository มีขนาดเพิ่มขึ้นเรื่อยๆ ในขณะที่รายการ archive สั้นลง สำหรับ restic การใช้ forget โดยไม่มี --prune จะเป็นการลบเพียงการอ้างอิง snapshot เท่านั้น แต่ข้อมูลจะยังคงอยู่จนกว่าจะมีการรัน prune

ควรเรียกใช้ restic check หลังจากทำ prune เสมอ คำสั่งนี้จะตรวจสอบโครงสร้างของ repository และแจ้งให้คุณทราบหากมีส่วนใดเสียหาย ซึ่งดีกว่าการไปพบปัญหาในขณะที่กำลังกู้คืนข้อมูลจริง

การกู้คืนข้อมูล ซึ่งเป็นการทดสอบเพียงอย่างเดียวที่เชื่อถือได้

เครื่องมือทั้งสองตัวรองรับการ mount snapshot เพื่อให้คุณสามารถเรียกดูข้อมูลภายในได้ ซึ่งเป็นวิธีที่รวดเร็วที่สุดในการดึงไฟล์กลับมาเพียงไฟล์เดียว

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

โปรดสังเกตรูปแบบ path ใน borg extract โดยปกติแล้ว path ภายในไฟล์ archive จะถูกจัดเก็บโดยไม่มีเครื่องหมาย slash นำหน้า ดังนั้น etc/nginx จึงเป็นรูปแบบที่ถูกต้อง ในขณะที่ /etc/nginx จะไม่ตรงกับข้อมูลใดๆ และไม่สามารถแตกไฟล์ออกมาได้ โดยที่ระบบจะไม่แจ้งข้อผิดพลาดให้คุณทราบถึงสาเหตุ นอกจากนี้ การแตกไฟล์จะเขียนข้อมูลลงในไดเรกทอรีปัจจุบันที่คุณใช้งานอยู่ ดังนั้นควรเปลี่ยนไปที่ไดเรกทอรีชั่วคราว (scratch directory) ก่อนเสมอ มิฉะนั้นไฟล์ปัจจุบันของคุณอาจถูกเขียนทับด้วยไฟล์เวอร์ชันเก่า

การกู้คืนข้อมูลที่เสร็จสิ้นโดยไม่มีข้อผิดพลาดไม่ได้เป็นเครื่องยืนยันว่าข้อมูลสมบูรณ์เสมอไป เนื่องจากแอปพลิเคชันที่ทำงานอยู่เบื้องบนมีเงื่อนไขของตัวเองในการพิจารณาว่าการกู้คืนนั้นสมบูรณ์หรือไม่ ตัวอย่างเช่น เซิร์ฟเวอร์ Immich ที่สร้างขึ้นใหม่จากการคัดลอกไดเรกทอรีข้อมูล Postgres จะแสดงรูปภาพทั้งหมดที่มีอยู่บนดิสก์ แต่ในหน้า timeline กลับไม่แสดงข้อมูลใดๆ ซึ่งเป็นปัญหาที่ การสำรองและกู้คืนข้อมูล Immich จำเป็นต้องมีขั้นตอนแก้ไขเฉพาะ

ไม่ว่าคุณจะเลือกใช้เครื่องมือใด ตารางเวลาการสำรองข้อมูลเป็นเพียงครึ่งหนึ่งของงานเท่านั้น คุณควรทดสอบการกู้คืนข้อมูลลงในไดเรกทอรีชั่วคราวตามกำหนดเวลาที่คุณสามารถตรวจสอบได้จริง เช่นเดียวกับขั้นตอนการปฏิบัติงานฉบับเต็มใน คู่มือการสำรองข้อมูลด้วย restic สำหรับ VPS ที่ใช้ systemd timer ในการดำเนินการ

เลือกเครื่องมือใดสำหรับงานประเภทใด

เลือกใช้ restic เมื่อปลายทางเป็น object storage เมื่อคุณต้องการไฟล์ binary เพียงไฟล์เดียวโดยไม่ต้องติดตั้งซอฟต์แวร์ที่ฝั่งปลายทาง เมื่อต้องการให้เครื่องหลายเครื่องทำ deduplication ร่วมกัน หรือเมื่อผู้ที่ทำหน้าที่กู้คืนข้อมูลอาจไม่ใช่ตัวคุณเอง restic เป็น static binary ไฟล์เดียวที่ระบุที่อยู่ repository ด้วย URL ซึ่งในแง่การปฏิบัติงานถือว่าทำได้ยากที่จะมีเครื่องมืออื่นมาเทียบ

เลือกใช้ Borg เมื่อปลายทางเป็นเครื่อง Linux ที่คุณดูแลเอง เมื่อการเชื่อมต่อมีความหน่วงสูงและชุดข้อมูลประกอบด้วยไฟล์ขนาดเล็กจำนวนหลายล้านไฟล์ เมื่อคุณต้องการใช้ SSH key แบบ append-only เพื่อป้องกัน ransomware หรือเมื่อคุณต้องการปรับแต่งการบีบอัดข้อมูลแยกตามงาน Borg เป็นเครื่องมือที่เก่าแก่กว่า ซึ่งเวอร์ชันที่เสถียรมีการเปลี่ยนแปลงอย่างช้าๆ และในแง่ของซอฟต์แวร์สำรองข้อมูล นี่ถือเป็นคุณสมบัติที่สำคัญ

ทั้งสองเครื่องมือเป็นตัวเลือกที่ถูกต้อง คำตอบที่ผิดคือการไม่ทดสอบการสำรองข้อมูลของคุณเลย หากคุณทำ database dump ในระดับแอปพลิเคชันอยู่แล้ว ให้ทำต่อไป รูปแบบที่ระบุไว้ใน การตั้งค่า Nextcloud บน Docker พร้อมการทำ database dump สามารถใช้ได้กับเครื่องมือทั้งสอง เนื่องจากไฟล์ฐานข้อมูลที่ถูกคัดลอกขณะที่ระบบกำลังทำงานอยู่โดยไม่ได้ผ่านกระบวนการ dump ไม่ถือเป็นการสำรองข้อมูลฐานข้อมูลที่สมบูรณ์

FAQ

restic หรือ BorgBackup ทำงานเร็วกว่ากัน?

บนดิสก์ภายในหรือ LAN ความเร็วสูง ทั้งสองเครื่องมือมีความเร็วใกล้เคียงกัน โดยมักถูกจำกัดด้วยความเร็วในการอ่านและคำนวณแฮชที่ต้นทาง Borg มักจะได้เปรียบเมื่อใช้งานผ่านลิงก์ SSH ที่มีความหน่วงสูงและมีไฟล์ขนาดเล็กจำนวนมาก เนื่องจากกระบวนการ borg serve ที่ฝั่งปลายทางสามารถตอบคำถามเกี่ยวกับดัชนีได้โดยไม่ต้องรอการรับส่งข้อมูลผ่านเครือข่ายในทุกๆ chunk ส่วน restic มักจะได้เปรียบเมื่อปลายทางเป็น object storage ซึ่ง Borg ไม่รองรับการใช้งานในลักษณะนี้

BorgBackup สามารถสำรองข้อมูลไปยัง S3 หรือ Backblaze B2 ได้หรือไม่?

ไม่ได้โดยตรง Repository ของ Borg ต้องอาศัยกระบวนการ borg serve ผ่าน SSH ซึ่งไม่มีกระบวนการดังกล่าวทำงานอยู่ภายใน bucket ผู้ใช้งานมักแก้ปัญหาด้วยการ mount object storage ให้เป็นระบบไฟล์ผ่าน rclone ซึ่งโครงการ Borg ไม่แนะนำวิธีนี้ เนื่องจากหากการเชื่อมต่อหลุดระหว่างทำธุรกรรมอาจทำให้ repository เสียหายได้ หากคุณจำเป็นต้องใช้ object storage ให้เลือกใช้ restic แทน

ฉันสามารถใช้ทั้งสองเครื่องมือกับข้อมูลชุดเดียวกันได้หรือไม่?

ได้ และมีผู้ใช้งานบางส่วนทำเช่นนั้น โดยใช้ Borg สำรองข้อมูลไปยังเซิร์ฟเวอร์เครื่องที่สองเพื่อการกู้คืนที่รวดเร็วในระดับ local และใช้ restic สำรองข้อมูลไปยัง object storage เพื่อเก็บไว้นอกสถานที่ ทั้งสองเครื่องมือทำงานแยกจากกันโดยสิ้นเชิง คุณจึงต้องเสียเวลาอ่านและคำนวณแฮชข้อมูลสองรอบ รวมถึงต้องจัดเก็บรหัสผ่านสองชุดอย่างปลอดภัย ควรทำวิธีนี้ก็ต่อเมื่อคุณได้ทดสอบการกู้คืนข้อมูลจากทั้งสองเครื่องมือแล้วเท่านั้น

จะเกิดอะไรขึ้นหากฉันทำรหัสผ่านของ repository หาย?

ข้อมูลจะไม่สามารถกู้คืนได้ในทั้งสองเครื่องมือ restic สร้างคีย์จากรหัสผ่านด้วย scrypt และไม่มีช่องทางให้ข้ามขั้นตอนดังกล่าว สำหรับ Borg ในโหมด repokey จะจัดเก็บคีย์ที่เข้ารหัสไว้ภายใน repository ทำให้สามารถกู้คืนได้ด้วยรหัสผ่านเพียงอย่างเดียว ส่วนในโหมด keyfile คุณจำเป็นต้องใช้ไฟล์คีย์จาก ~/.config/borg/keys/ ด้วย ควรจัดเก็บรหัสผ่านไว้ในโปรแกรมจัดการรหัสผ่านที่ไม่ได้อยู่บนเซิร์ฟเวอร์ที่กำลังสำรองข้อมูล และส่งออกคีย์ของ Borg ด้วย borg key export หากคุณใช้ keyfile

ฉันควรรอ Borg 2.0 หรือไม่?

ไม่ควร ณ เดือนกรกฎาคม 2026 Borg 2.0 ยังคงอยู่ในสถานะเบต้าที่เวอร์ชัน 2.0.0b22 และโครงการระบุว่าเป็นเวอร์ชันสำหรับทดสอบเท่านั้น ซีรีส์ที่มีความเสถียรคือ 1.4 ซึ่งปัจจุบันอยู่ที่ 1.4.5 ให้เริ่มใช้งานเวอร์ชัน 1.4 ตั้งแต่วันนี้ Borg 2 มีการเปลี่ยนรูปแบบ repository และมาพร้อมกับแนวทางการอัปเกรดที่มีเอกสารรองรับ ดังนั้นการเริ่มต้นใช้งานตั้งแต่วันนี้จะไม่ทำให้คุณติดปัญหาในการอัปเกรดในอนาคต