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

การเก็บรักษาข้อมูล: การเปรียบเทียบระหว่าง 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 จะลบ 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) ก่อน มิฉะนั้นไฟล์ปัจจุบันของคุณอาจถูกเขียนทับด้วยไฟล์เก่า

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

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

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

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

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

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 ไม่แนะนำ เนื่องจากหากการ mount หลุดระหว่างการทำธุรกรรม อาจทำให้ repository เสียหายได้ หากคุณต้องการใช้ object storage ให้เลือกใช้ restic

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

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