เปรียบเทียบ 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 (filesystem in userspace) เพื่อให้คุณคัดลอกไฟล์ออกมาได้ ณ เดือนกรกฎาคม 2026 restic อยู่ที่เวอร์ชัน 0.19.1 และซีรีส์เสถียรของ Borg คือ 1.4 ที่เวอร์ชัน 1.4.5 ส่วน Borg 2.0 อยู่ในสถานะเบต้ามาหลายปีและยังคงระบุว่าเป็นเวอร์ชันสำหรับการทดสอบเท่านั้น ดังนั้น 1.4 จึงเป็นเวอร์ชันที่คุณควรเลือกใช้งานในปัจจุบัน

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

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

ที่เก็บข้อมูลของ Borg ก็เป็นไฟล์บนดิสก์เช่นกัน แต่ Borg ไม่เคยสื่อสารกับที่เก็บข้อมูลผ่านช่องทางการส่งข้อมูลแบบทั่วไป สำหรับที่เก็บข้อมูลระยะไกล Borg จะเริ่มการทำงานของ borg serve ที่ฝั่งปลายทางผ่าน SSH และสื่อสารด้วยโปรโตคอลของตัวเองกับกระบวนการนั้น ฝั่งเซิร์ฟเวอร์จะทำหน้าที่ประมวลผลจริง คือการดูแลที่เก็บข้อมูล การทำธุรกรรม และการตอบคำถามเกี่ยวกับดัชนี นี่คือเหตุผลที่ Borg ไม่มีแบ็กเอนด์สำหรับ 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 และไฟล์แพ็กทุกไฟล์ที่เขียนลงไปหลังจากนั้นจะถูกเข้ารหัสและตรวจสอบความถูกต้อง หากทำรหัสผ่านหาย ข้อมูลจะสูญหายทันที เนื่องจากไม่มีช่องทางสำหรับการกู้คืนตามการออกแบบของซอฟต์แวร์

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

กฎในทางปฏิบัติคือ: ใช้ repokey-blake2 สำหรับการสำรองข้อมูลเซิร์ฟเวอร์ทั่วไป ใช้ keyfile เมื่อที่เก็บข้อมูลอยู่ในสถานที่ที่คุณไม่ไว้วางใจอย่างเต็มที่ และห้ามใช้ 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 format 2 มาใช้ ซึ่งจำเป็นต้องใช้ restic เวอร์ชัน 0.14.0 หรือใหม่กว่า ปัจจุบัน format 2 เป็นค่าเริ่มต้นสำหรับ repository ใหม่ และการตั้งค่าการบีบอัดจะใช้ --compression โดยกำหนดค่าเป็น auto, off หรือ max สำหรับ repository รูปแบบเก่า (format 1) จะยังคงไม่มีการบีบอัดจนกว่าคุณจะทำการย้ายข้อมูล (migrate) ดังนั้นหาก repository ของ restic ที่คุณใช้งานอยู่มีเวอร์ชันเก่ากว่า 0.14 และคุณไม่เคยทำการย้ายข้อมูล คุณยังคงต้องเสียพื้นที่จัดเก็บเต็มจำนวนสำหรับไฟล์ข้อความ ไฟล์บันทึก (logs) และไฟล์สำรองฐานข้อมูล (database dumps)

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

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

การที่ restic เข้าถึง S3 ได้นั้นจำเป็นต้องมีข้อมูลประจำตัวในสภาพแวดล้อม และไม่ต้องรันกระบวนการอื่นใดที่อื่น รูปแบบเดียวกันนี้สามารถใช้กับ 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 เข้าถึงที่เก็บข้อมูลระยะไกลจำเป็นต้องใช้ SSH ร่วมกับการติดตั้ง Borg ที่ฝั่งปลายทาง และต้องการให้เวอร์ชันที่นั่นเข้ากันได้กับไคลเอ็นต์ นี่เป็นอุปสรรคหากฝั่งปลายทางไม่ใช่ของคุณ แต่จะไม่มีปัญหาเลยหากฝั่งปลายทางเป็นเซิร์ฟเวอร์เครื่องที่สองที่คุณดูแลอยู่แล้ว และมันจะช่วยให้คุณได้รับการควบคุมที่แข็งแกร่งที่สุดในการป้องกันแรนซัมแวร์ที่เครื่องมือทั้งสองตัวมีให้ นั่นคือ SSH key แบบ append only ให้บังคับใช้ key เพื่อรัน borg serve แล้วไคลเอ็นต์จะสามารถเพิ่มไฟล์เก็บถาวรได้แต่ไม่สามารถลบได้ ดังนั้นเครื่องที่ถูกบุกรุกจึงไม่สามารถลบประวัติของตัวเองได้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

FAQ

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

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

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

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

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

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

จะเกิดอะไรขึ้นหากฉันทำรหัสผ่านของ 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 และมาพร้อมกับแนวทางการอัปเกรดที่มีเอกสารรองรับ ดังนั้นการเริ่มต้นใช้งานตั้งแต่วันนี้จะไม่ทำให้คุณติดปัญหาในการอัปเกรดในอนาคต