วิธีตั้งค่า VPS เป็นที่เก็บข้อมูลสำรองแบบ Off-site

เป้าหมายการสำรองข้อมูลแบบ off-site คืออะไร

เป้าหมายการสำรองข้อมูลแบบ off-site คือเครื่องที่สองซึ่งเก็บสำเนาข้อมูลของคุณไว้และมีความล้มเหลวที่เป็นอิสระจากเครื่องต้นทาง โดย VPS จากผู้ให้บริการรายอื่นเป็นตัวเลือกที่ประหยัดที่สุดสำหรับผู้อ่านส่วนใหญ่ รูปแบบที่เป็นไปได้จริงมี 3 แบบ ได้แก่ การรัน Proxmox Backup Server บน VPS, การใช้ restic repository ผ่าน SSH หรือ S3 หรือการทำ rsync mirror ที่โฮสต์สำรองข้อมูลเป็นผู้ดึงข้อมูลมา รูปแบบที่เหมาะสมจะขึ้นอยู่กับว่าคุณต้องการกู้คืนข้อมูลอะไรและต้องการความเร็วในการกู้คืนแค่ไหน ส่วนผู้ที่มีสิทธิ์ลบสำเนาข้อมูลจะเป็นตัวกำหนดปัจจัยที่เหลือ

คำว่า off-site หมายถึงขอบเขตความล้มเหลว (failure domain) ที่แตกต่างกัน ซึ่งหมายถึงการใช้ผู้ให้บริการรายอื่น และบัญชีผู้ใช้ที่ไม่มีการใช้ข้อมูลล็อกอินร่วมกับบัญชีที่รันเซิร์ฟเวอร์หลักของคุณ การมีเซิร์ฟเวอร์เครื่องที่สองในภูมิภาคอื่นของผู้ให้บริการรายเดียวกันอาจช่วยให้รอดพ้นจากเหตุไฟไหม้ในอาคารเดียวได้ แต่จะไม่รอดพ้นจากการถูกเจาะระบบผ่านบัญชีผู้ใช้ control panel เพราะบัญชีเดียวสามารถควบคุมสำเนาข้อมูลทั้งสองชุดได้

Snapshot ที่ผู้ให้บริการจัดเตรียมไว้ไม่ใช่สำเนาชุดที่สอง เพราะมันอยู่ภายใต้รหัสผ่านของ control panel ชุดเดียวกัน ดังนั้นผู้ที่ได้รหัสผ่านนั้นไปจะสามารถลบเซิร์ฟเวอร์และ snapshot ทั้งหมดได้ในการเข้าถึงเพียงครั้งเดียว นอกจากนี้ บริการ snapshot ยังคิดค่าบริการต่อกิกะไบต์ต่อเดือนในอัตราที่สูงกว่าพื้นที่ดิสก์ปกติมาก ทำให้การเก็บ snapshot ไว้ถึง 90 วันมีค่าใช้จ่ายสูง ความแตกต่างระหว่าง VPS snapshots และ backups เป็นบทความที่ควรอ่านก่อนที่คุณจะพึ่งพาบริการเหล่านี้

รูปแบบใดที่เหมาะสมกับคุณ

• Proxmox Backup Server (PBS): ต้นทางคือ Proxmox VE (virtual environment) และสิ่งที่คุณกู้คืนคือเครื่องเสมือนทั้งเครื่อง โดยจะสำรองข้อมูลในระดับ disk-image และงานตรวจสอบ (verify jobs) จะทำการอ่านข้อมูลที่อยู่บนปลายทางซ้ำอีกครั้ง
• A restic repository: ต้นทางคือโฮสต์ Linux หนึ่งหรือหลายเครื่อง และสิ่งที่คุณกู้คืนคือไดเรกทอรีหรือไฟล์ดัมพ์ฐานข้อมูล โดยจะเข้ารหัสข้อมูลที่ฝั่งไคลเอนต์ รองรับโปรโตคอล SSH และ S3 รวมถึงโปรโตคอล REST ของตนเอง
• rsync over SSH, pulled by the backup host: คุณต้องการให้ไฟล์บนปลายทางอยู่ในรูปแบบไฟล์ปกติ ซึ่งสามารถอ่านได้ด้วย ls และ cat โดยไม่จำเป็นต้องใช้ซอฟต์แวร์ไคลเอนต์ใดๆ ในการกู้คืนข้อมูลกลับมา

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

การประเมินขนาดพื้นที่: ค่าใช้จ่ายในการเก็บข้อมูลย้อนหลังหนึ่งเดือน

Deduplication คือเหตุผลที่ตัวเลขมีขนาดเล็กกว่าที่หลายคนคาดคิด ทั้ง restic และ PBS จะแบ่งไฟล์ออกเป็นส่วนย่อย (chunks) ที่มีขนาดต่างกันและทำ hashing ในแต่ละส่วน โดยส่วนที่ซ้ำกันจะถูกจัดเก็บเพียงครั้งเดียว ดังนั้นการสำรองข้อมูลครั้งที่สองของชุดข้อมูลขนาด 500 GB จึงไม่ได้เพิ่มพื้นที่อีก 500 GB แต่จะเพิ่มเฉพาะส่วนที่เปลี่ยนแปลงไปเท่านั้น

ด้วยเหตุนี้ ขนาดของ repository จึงขึ้นอยู่กับอายุของ snapshot ที่เก่าที่สุด ไม่ใช่จำนวนของ snapshot ตัวอย่างเช่น หากมีข้อมูลตั้งต้น 500 GB และมีข้อมูลใหม่ที่ไม่ซ้ำเดิมเพิ่มขึ้นวันละ 5 GB ตัว repository จะเก็บข้อมูลฐาน 500 GB รวมกับข้อมูลใหม่ประมาณ 5 GB ต่อวันย้อนหลังไปจนถึง snapshot ที่เก่าที่สุดตามนโยบายการเก็บข้อมูล

[
  {
    "label": "7 daily",
    "repo_size_gb": 535,
    "usd_at_10_per_tb": 5.35
  },
  {
    "label": "7 daily, 4 weekly",
    "repo_size_gb": 640,
    "usd_at_10_per_tb": 6.4
  },
  {
    "label": "7 daily, 4 weekly, 6 monthly",
    "repo_size_gb": "1,400",
    "usd_at_10_per_tb": 14.0
  },
  {
    "label": "7 daily, 4 weekly, 12 monthly",
    "repo_size_gb": "2,325",
    "usd_at_10_per_tb": 23.25
  }
]

คอลัมน์ดอลลาร์เป็นการคำนวณราคา repository ที่ 10 ดอลลาร์สหรัฐต่อ TB ต่อเดือน ซึ่งเป็นเพียงตัวเลขสมมติสำหรับการคำนวณ ไม่ใช่ราคาเสนอจากผู้ให้บริการรายใด ดังนั้นโปรดแทนที่ด้วยราคาต่อ TB จริงของแผนที่คุณกำลังพิจารณา การเก็บข้อมูลรายวันเป็นเวลาหนึ่งสัปดาห์จะใช้พื้นที่ประมาณ 535 GB ในขณะที่ประวัติข้อมูลตลอดทั้งปีจะใช้พื้นที่ 2,325 GB ซึ่งคิดเป็นค่าใช้จ่าย $23.25 ต่อเดือน เมื่อเทียบกับ $5.35 สำหรับการเก็บข้อมูลหนึ่งสัปดาห์ การเก็บประวัติข้อมูลนั้นมีราคาถูก สิ่งที่คุณต้องจ่ายจริงคือค่าพื้นที่สำหรับข้อมูลชุดตั้งต้น

Deduplication จะไม่มีผลกับข้อมูลที่ถูกบีบอัดหรือเข้ารหัสมาแล้ว ข้อมูล database dump ที่ถูกบีบอัดด้วย gzip จะเปลี่ยนไปโดยสิ้นเชิงในการสำรองข้อมูลแต่ละครั้ง ทำให้ dump แต่ละชุดถูกจัดเก็บเป็น chunks ใหม่ทั้งหมด และ repository จะขยายขนาดขึ้นเท่ากับขนาดของ dump เต็มชุดในทุกคืน แนะนำให้เขียนไฟล์ dump โดยไม่บีบอัดแล้วปล่อยให้เครื่องมือสำรองข้อมูลเป็นผู้จัดการแทน เนื่องจาก restic รองรับ repository แบบบีบอัดมาตั้งแต่เวอร์ชัน 0.14 และในเวอร์ชัน 0.19 ได้เพิ่มโหมด fastest และ better zstd เข้ามา สำหรับคลังรูปภาพและวิดีโอจะทำ deduplication ได้ไม่ดีด้วยเหตุผลเดียวกัน ดังนั้นควรประเมินขนาดจากอัตราการเติบโตจริงแทนการใช้ตัวเลขจากตารางด้านบน

ในกรณีนี้ คุณกำลังซื้อพื้นที่ดิสก์ที่ไม่ได้ใช้งานมากกว่าการใช้ CPU ซึ่งเป็นสถานการณ์ที่ storage VPS มีความคุ้มค่ากว่า VPS ทั่วไป

เหตุใดแบนด์วิดท์และระยะเวลาในการกู้คืนจึงเป็นตัวกำหนดแผน

พื้นที่จัดเก็บข้อมูลบนดิสก์มีราคาถูก แต่การอัปโหลดครั้งแรกและการกู้คืนข้อมูลในภายหลังคือส่วนที่มีต้นทุนสูง ข้อมูลขนาด 500 GB เทียบเท่ากับ 4 ล้านล้านบิต ดังนั้นการนำความเร็วของลิงก์มาหารจะทำให้ทราบระยะเวลาขั้นต่ำที่ต้องใช้ในการกู้คืนข้อมูลทั้งหมด

[
  {
    "label": "40 Mbit/s home upload",
    "elapsed_h": 27.8
  },
  {
    "label": "100 Mbit/s",
    "elapsed_h": 11.1
  },
  {
    "label": "500 Mbit/s",
    "elapsed_h": 2.2
  },
  {
    "label": "1 Gbit/s VPS port",
    "elapsed_h": 1.1
  }
]

ตัวเลขเหล่านี้คือความเร็วสูงสุดตามทฤษฎีโดยยังไม่รวม overhead ของโปรโตคอล จึงควรพิจารณาว่าเป็นกรณีที่ดีที่สุดเท่านั้น ที่ความเร็ว 100 Mbit/s การกู้คืนข้อมูลทั้งหมดต้องใช้เวลา 11.1 ชั่วโมงก่อนที่จะเริ่มเข้าถึงข้อมูลได้ หากอัปโหลดจากที่บ้านด้วยความเร็ว 40 Mbit/s จะต้องใช้เวลา 27.8 ชั่วโมง และบนพอร์ตความเร็ว 1 Gbit/s การกู้คืนเดียวกันนี้จะใช้เวลา 1.1 ชั่วโมง การสำรองข้อมูลไฟล์ขนาดเล็กจำนวนมากจะทำงานช้ากว่าการคำนวณทางคณิตศาสตร์ เนื่องจาก overhead ต่อไฟล์จะส่งผลกระทบอย่างมากเมื่อไฟล์มีขนาดต่ำกว่าไม่กี่ร้อยกิโลไบต์

ข้อสรุปมีสองประการ ประการแรก หากเป้าหมายระยะเวลาการกู้คืน (RTO) หรือระยะเวลาที่ระบบล่มได้ที่คุณยอมรับได้คือ 4 ชั่วโมง การกู้คืนข้อมูล 500 GB ผ่านลิงก์ 100 Mbit/s จะไม่สามารถทำได้ตามเป้าหมาย และการใช้ดิสก์ที่ราคาถูกลงก็ไม่ได้ช่วยแก้ปัญหานี้ ประการที่สอง แผนบริการ VPS ส่วนใหญ่มีการจำกัดปริมาณการรับส่งข้อมูลขาออก ดังนั้นการกู้คืนข้อมูลเต็มรูปแบบหนึ่งครั้งจะใช้โควตา 0.5 TB จากโควตาต่อเดือนของโฮสต์สำรองข้อมูล คุณควรตรวจสอบโควตาดังกล่าวและตรวจสอบว่าผู้ให้บริการมีมาตรการอย่างไรเมื่อคุณใช้งานเกินโควตาก่อนที่จะถึงเวลาที่ต้องใช้งานข้อมูลจริง

การสำรองข้อมูลครั้งแรกคือการสำรองข้อมูลทั้งหมดและจะเป็นการทำงานที่ช้าที่สุดที่คุณเคยทำ ควรเริ่มในวันศุกร์และจำกัดอัตราความเร็วเพื่อไม่ให้ใช้แบนด์วิดท์ขาขึ้นของต้นทางจนเต็ม โดย restic ใช้ --limit-upload ในหน่วย KiB ต่อวินาที ส่วน rsync ใช้ --bwlimit

รูปแบบที่ 1: การใช้ Proxmox Backup Server เป็น datastore ระยะไกล

PBS เหมาะสมเมื่อแหล่งข้อมูลคือ Proxmox VE และหน่วยของการกู้คืนคือเครื่องเสมือน (virtual machine) เนื่องจาก VPS ไม่สามารถบูตผ่าน Proxmox ISO ได้ ให้ติดตั้ง PBS ลงบน Debian แทน โดยเวอร์ชัน 4.2 เป็นเวอร์ชันปัจจุบัน ณ เดือนสิงหาคม 2026 ซึ่งสร้างขึ้นบน Debian 13 (trixie)

wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg \
  -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

เปรียบเทียบค่า checksum นั้นกับค่าที่ประกาศไว้บน หน้า repository แพ็กเกจของ Proxmox ความน่าเชื่อถือของ apt repository ขึ้นอยู่กับคีย์ที่คุณตรวจสอบ จากนั้นให้พิมพ์ /etc/apt/sources.list.d/proxmox.sources:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update && sudo apt install -y proxmox-backup-server
sudo proxmox-backup-manager datastore create offsite /mnt/datastore/offsite

จัดสรร filesystem หรือ volume แยกต่างหากให้กับ datastore การที่ datastore เต็มจะทำให้การสำรองข้อมูลหยุดลง และหาก datastore ใช้ filesystem ร่วมกับ root จะทำให้เซิร์ฟเวอร์ทั้งเครื่องหยุดทำงานเมื่อพื้นที่เต็ม

ถัดไป ให้สร้างบัญชีที่แหล่งข้อมูลจะใช้ และกำหนด token ให้แทนการใช้รหัสผ่าน

sudo proxmox-backup-manager user create backup@pbs
sudo proxmox-backup-manager user generate-token backup@pbs pve1
sudo proxmox-backup-manager acl update /datastore/offsite DatastoreBackup \
  --auth-id 'backup@pbs!pve1'

ค่า token secret จะแสดงเพียงครั้งเดียวและไม่สามารถอ่านย้อนหลังได้ ดังนั้นให้บันทึกไว้ทันทีที่ปรากฏ บทบาท (role) มีความสำคัญพอๆ กับตัว token โดย DatastoreBackup สามารถสร้างและกู้คืนข้อมูลสำรองของตนเองได้ และไม่มีสิทธิ์ Datastore.Prune ดังนั้น token ดังกล่าวจึงไม่สามารถลบ snapshot ที่เขียนไว้แล้วได้

การกำหนดนโยบายการเก็บรักษา (retention) บน PBS มีสองส่วน และส่วนที่สองคือส่วนที่คนมักมองข้าม การทำ prune คือการลบ snapshot ออก ส่วนการทำ garbage collection คือการลบ chunk ที่ไม่มี snapshot ใดๆ อ้างอิงถึง พื้นที่ว่างจะปรากฏขึ้นหลังจากทำ garbage collection ไม่ใช่หลังจากทำ prune

proxmox-backup-client prune host/web1 \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run
sudo proxmox-backup-manager garbage-collection start offsite
sudo proxmox-backup-manager verify offsite

เรียกใช้ --dry-run เมื่อรายการ snapshot ที่ต้องการลบดูถูกต้องแล้ว การทำ garbage collection จะทำงานในสองขั้นตอน คืออัปเดตเวลาการเข้าถึง (access time) ของทุก chunk ที่ยังมีการอ้างอิงอยู่ จากนั้นจึงลบ chunk ที่มีเวลาการเข้าถึงเก่ากว่าระยะเวลาที่กำหนด ซึ่งคือ 24 ชั่วโมงกับอีก 5 นาที ก่อนที่การทำงานจะเริ่มขึ้น ระยะเวลาผ่อนผันนี้มีไว้เพื่อให้ chunk ที่กำลังถูกเขียนโดยการสำรองข้อมูลที่ยังไม่เสร็จสมบูรณ์ไม่ถูกลบออกไป ให้ตั้งเวลาการทำ prune เป็นรายวันและ garbage collection เป็นรายสัปดาห์บน datastore และเพิ่มงาน verify เพื่อให้ปลายทางอ่าน chunk ของตนเองซ้ำและรายงานความเสียหายบนดิสก์ก่อนที่จะเกิดการกู้คืนจริง

หากแหล่งข้อมูลเป็นอินสแตนซ์ PBS เช่นกัน เครื่องที่อยู่ภายนอกไซต์ (off-site) สามารถดึงข้อมูล (pull) แทนการรอรับข้อมูลที่ถูกส่งมา (push)

sudo proxmox-backup-manager remote create home1 \
  --host pbs.home.example --userid sync@pam --password 'SECRET' \
  --fingerprint '64:d3:ff:3a:50:38:53:5a:9b:f7:50:ab:fe'
sudo proxmox-backup-manager sync-job create home1-offsite \
  --remote home1 --remote-store main --store offsite --schedule 'Wed 02:30'

เรียกใช้งาน sync job นั้นบน VPS ในทิศทางการดึงข้อมูลแบบปกติ VPS จะเข้าถึง datastore หลัก ซึ่งหมายความว่าเครื่องที่บ้านจะไม่มี credential ใดๆ ที่สามารถเข้าถึงสำเนาที่อยู่ภายนอกไซต์ได้

รูปแบบที่ 2: restic repository ผ่าน SSH หรือ S3

Debian และ Ubuntu มีแพ็กเกจ restic ให้ใช้งานทั้งคู่ แต่เวอร์ชันมักจะตามหลังเวอร์ชันหลัก เวอร์ชัน 0.19.1 เป็นเวอร์ชันปัจจุบัน ณ เดือนสิงหาคม 2026 ให้ติดตั้ง binary อย่างเป็นทางการบนโฮสต์ต้นทาง

curl -LO https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2
bunzip2 restic_0.19.1_linux_amd64.bz2
sudo install -m 755 restic_0.19.1_linux_amd64 /usr/local/bin/restic
restic version

restic version จะแสดงเวอร์ชันและ Go compiler ที่ใช้สร้างโปรแกรม สำหรับการอัปเกรดในภายหลังให้ใช้ sudo restic self-update ซึ่งใช้ได้กับ binary อย่างเป็นทางการเท่านั้น ไม่สามารถใช้กับสำเนาที่ติดตั้งผ่าน apt ได้

บน VPS สำรองข้อมูล ให้สร้างบัญชีผู้ใช้ที่ไม่มีสิทธิ์เข้าถึงข้อมูลอื่น จากนั้นคัดลอก public key ของโฮสต์ต้นทางลงใน /home/resticsrv/.ssh/authorized_keys

sudo adduser --disabled-password --gecos '' resticsrv
sudo install -d -m 700 -o resticsrv -g resticsrv /srv/restic

เริ่มต้นใช้งาน repository จากโฮสต์ต้นทางผ่าน SFTP

sudo sh -c 'umask 077; head -c 32 /dev/urandom | base64 > /root/.restic-password'
export RESTIC_REPOSITORY='sftp:resticsrv@backup.example.net:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init
restic backup /etc /srv /var/backups --exclude-caches

เก็บรหัสผ่านนั้นไว้ในที่ที่ปลอดภัย ซึ่งไม่ใช่ทั้งเซิร์ฟเวอร์นี้และไม่ใช่เป้าหมายสำรองข้อมูล หากทำรหัสผ่านหาย repository จะไม่สามารถอ่านได้และไม่มีช่องทางกู้คืนใดๆ ทั้งสิ้น นี่คือเงื่อนไขของการเข้ารหัสลับฝั่งไคลเอนต์

การกำหนดนโยบายการเก็บรักษาข้อมูลทำได้ด้วยคำสั่งเดียว และส่วนที่สองของคำสั่งคือส่วนที่ช่วยคืนพื้นที่ดิสก์

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=10%

forget ใช้สำหรับลบ snapshot ส่วน prune ใช้ลบไฟล์ pack ที่ถูกอ้างอิงโดย snapshot เหล่านั้นเท่านั้น และ --prune จะรันคำสั่งนี้โดยอัตโนมัติเมื่อมีการลบข้อมูลจริง หากไม่มีคำสั่งนี้ repository จะไม่ลดขนาดลงเลย restic check ใช้ตรวจสอบโครงสร้างของ repository และ --read-data-subset=10% จะอ่านและทำ hash ซ้ำในสัดส่วนหนึ่งในสิบของไฟล์ pack ทั้งหมด ซึ่งช่วยตรวจหาความเสียหายบนเป้าหมายโดยไม่ต้องอ่านข้อมูลทั้งหมด อีกรูปแบบหนึ่งคือ --read-data-subset=1/10 ซึ่งจะตรวจสอบสัดส่วนหนึ่งในสิบที่กำหนดไว้ตายตัว ดังนั้นการเพิ่มตัวเลขแรกขึ้นทีละหนึ่งในแต่ละสัปดาห์จะทำให้ครอบคลุมการตรวจสอบ repository ทั้งหมดภายในสิบสัปดาห์

หากการทำงานถูกสั่งยกเลิกกะทันหัน การรันครั้งถัดไปจะหยุดลงพร้อมข้อความ repository is already locked exclusively by PID ให้ตรวจสอบให้แน่ใจว่าไม่มีการสำรองข้อมูลใดๆ กำลังทำงานอยู่ จากนั้นจึงล้างสถานะด้วย restic unlock

สำหรับ object storage สตริงของ repository จะเปลี่ยนเป็น s3:https://s3.example.net/web1 โดยระบุข้อมูลรับรองใน AWS_ACCESS_KEY_ID และ AWS_SECRET_ACCESS_KEY ขั้นตอนที่เหลือทั้งหมดจะเหมือนเดิม ซึ่งเป็นวิธีที่ restic ใช้สื่อสารกับ a self-hosted MinIO object store ที่รันอยู่บน VPS เดียวกัน

รูปแบบที่ 3: rsync ผ่าน SSH ด้วยกุญแจแบบอ่านได้อย่างเดียว (pull-only)

คุณสมบัติด้านความปลอดภัยของรูปแบบนี้คือทิศทางการเชื่อมต่อ โดย VPS สำรองข้อมูลจะเป็นฝ่ายเชื่อมต่อเข้าไปยังต้นทางเพื่ออ่านข้อมูล ต้นทางจะไม่มีกุญแจและไม่มีเส้นทางเชื่อมต่อไปยังโฮสต์สำรอง ดังนั้นหากต้นทางถูกบุกรุก ผู้บุกรุกจะไม่สามารถเข้าถึงข้อมูลสำรองได้เลย

สร้างคู่กุญแจบน VPS สำรองข้อมูล จากนั้นติดตั้งกุญแจสาธารณะไว้ที่ต้นทางพร้อมกำหนดคำสั่งบังคับ (forced command)

command="rrsync -ro /srv",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA offsite-pull

rrsync ถูกรวมอยู่ในแพ็กเกจ rsync ที่ /usr/bin/rrsync บน Debian 13 และ Ubuntu 24.04 โดย -ro จะอนุญาตให้ทำได้เพียงการอ่านเท่านั้นและมีผลรวมถึง -no-del ดังนั้นกุญแจนี้จึงไม่สามารถเขียนข้อมูลหรือลบสิ่งใดบนต้นทางได้ ส่วน restrict จะปิดฟีเจอร์ SSH ที่ไม่จำเป็นออกไป รวมถึงการส่งต่อพอร์ต (port forwarding) และ pty ทำให้กุญแจนี้ไม่สามารถนำไปใช้ล็อกอินแบบโต้ตอบได้ เส้นทางไฟล์จะอ้างอิงจากไดเรกทอรีที่คุณระบุ ดังนั้นเส้นทางระยะไกล / จึงหมายถึง /srv บนต้นทาง

การดึงข้อมูล (pull) จะเก็บประวัติโดยใช้ hardlinks ไฟล์ที่ไม่มีการเปลี่ยนแปลงในโครงสร้างใหม่จะเป็น hardlink ไปยังโครงสร้างก่อนหน้า จึงใช้เพียงพื้นที่ของ directory entry แทนที่จะเป็นการคัดลอกไฟล์ซ้ำ

DEST=/srv/mirror/web1
TODAY=$(date +%F)
LAST=$(ls -1d "$DEST"/2* 2>/dev/null | tail -1)
LINK=""
if [ -n "$LAST" ]; then LINK="--link-dest=$LAST"; fi
rsync -aH --numeric-ids $LINK -e 'ssh -i /root/.ssh/pull_ed25519' \
  pull@web1.example.net:/ "$DEST/.$TODAY.partial/"
mv "$DEST/.$TODAY.partial" "$DEST/$TODAY"

การเปลี่ยนชื่อในขั้นตอนสุดท้ายคือสิ่งที่ทำให้ไดเรกทอรีที่ระบุวันที่มีความน่าเชื่อถือ โดยชื่อไดเรกทอรีจะปรากฏขึ้นก็ต่อเมื่อ rsync ทำงานเสร็จสิ้นด้วย exit code 0 เท่านั้น ดังนั้นการถ่ายโอนข้อมูลที่ถูกขัดจังหวะจะไม่ถูกมองว่าเป็น snapshot ที่สมบูรณ์ คุณสามารถลบโครงสร้างเก่าทิ้งได้ด้วยคำสั่งบรรทัดเดียว โดยเก็บไว้เพียง 30 ชุด

ls -1d /srv/mirror/web1/2* | sort | head -n -30 | xargs -r rm -rf

ต้องยอมรับตามตรงถึงข้อจำกัดของรูปแบบนี้ การใช้ hardlinks จะทำ deduplication ได้เฉพาะไฟล์ทั้งไฟล์เท่านั้น ดังนั้นหากมีการเปลี่ยนแปลงเพียง 1 ไบต์ภายในไฟล์ disk image ขนาด 4 GB ระบบจะคัดลอกข้อมูลทั้งหมด 4 GB ในขณะที่ restic หรือ PBS จะจัดเก็บเฉพาะส่วนที่เปลี่ยนแปลงเพียงเล็กน้อยเท่านั้น นอกจากนี้ ปลายทางยังเก็บไฟล์ของคุณในรูปแบบข้อความธรรมดา (plaintext) ดังนั้นใครก็ตามที่มีสิทธิ์ root บน VPS สำรองข้อมูลจะสามารถอ่านไฟล์เหล่านี้ได้ทั้งหมด

การเข้ารหัสฝั่งไคลเอ็นต์ เพื่อไม่ให้ปลายทางเห็นข้อมูลดิบ

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

restic จะเข้ารหัสข้อมูลทุกส่วนที่ต้นทางก่อนส่งออกไป ดังนั้น repository จึงมีเพียงข้อมูลที่ถูกเข้ารหัส (ciphertext) และข้อมูลเมตาเกี่ยวกับขนาดและเวลาเท่านั้น สำหรับ PBS การเข้ารหัสเป็นทางเลือกเสริม: ให้สร้างคีย์ขึ้นมาแล้วระบุคีย์นั้นในการสำรองข้อมูลทุกครั้ง

proxmox-backup-client key create /root/pbs-encryption.key
proxmox-backup-client backup root.pxar:/ --keyfile /root/pbs-encryption.key
proxmox-backup-client key paperkey --output-format text > qrkey.txt

ให้พิมพ์คีย์ที่เป็นกระดาษออกมาและเก็บไว้ในสถานที่จริง เอกสารของ Proxmox ระบุไว้อย่างชัดเจนว่าหากไม่มีคีย์ ไฟล์ที่สำรองไว้จะไม่สามารถกู้คืนได้ ห้ามเก็บคีย์ไว้ในเครื่องปลายทางที่ใช้สำรองข้อมูล เพราะการเก็บคีย์ไว้คู่กับข้อมูลที่เข้ารหัสย่อมไม่ช่วยป้องกันอะไรได้เลย

การทำ rsync mirror ไม่มีกลไกในลักษณะเดียวกัน ไฟล์จะถูกคัดลอกไปในรูปแบบไฟล์ปกติ หากข้อมูลมีความสำคัญ คุณต้องยอมรับว่าปลายทางสามารถอ่านข้อมูลนั้นได้ หรือเลือกใช้รูปแบบอื่นในสองวิธีที่กล่าวไปข้างต้น

การป้องกันไม่ให้แหล่งข้อมูลที่ถูกบุกรุกทำลายข้อมูลสำรองของตนเอง

ผู้โจมตีที่เข้าถึงแหล่งข้อมูลได้มักจะมองหาข้อมูลสำรองในลำดับถัดไป และข้อมูลประจำตัว (credential) ที่ใช้ในการอัปโหลดข้อมูลสำรองเหล่านั้นก็มักจะถูกเก็บไว้บนเครื่องเดียวกัน หากข้อมูลประจำตัวนั้นมีสิทธิ์ในการลบ ผู้โจมตีก็จะใช้สิทธิ์ดังกล่าวทันที

PBS แก้ไขปัญหานี้ด้วยการใช้บทบาท (roles) โดย token ที่ถือสิทธิ์เพียง DatastoreBackup จะสามารถเขียน snapshot ใหม่และกู้คืนข้อมูลของตนเองได้ แต่จะไม่สามารถลบข้อมูลได้ เนื่องจากกระบวนการลบ snapshot จำเป็นต้องใช้สิทธิ์ Datastore.Prune แยกต่างหาก ให้คุณตั้งค่าการเก็บรักษาข้อมูล (retention) จากฝั่ง PBS แทน เพื่อให้แหล่งข้อมูลไม่มีข้อมูลประจำตัวที่สามารถลบสิ่งใดได้เลย

การใช้งาน restic ผ่าน SFTP ไม่มีการแบ่งสิทธิ์ในลักษณะนี้ เนื่องจาก SSH key ที่ใช้เขียนข้อมูลลงใน repository สามารถลบข้อมูลออกจาก repository ได้เช่นกัน วิธีแก้ไขคือการใช้ REST backend ให้รัน rest-server บน backup VPS ด้วย --append-only ซึ่งอนุญาตให้สร้างข้อมูลสำรองใหม่ได้ แต่ป้องกันการลบหรือแก้ไขข้อมูลที่มีอยู่เดิม จากนั้นให้ชี้ client ไปที่ rest:https://backup.example.net:8000/web1 โดยใช้ RESTIC_REST_USERNAME และ RESTIC_REST_PASSWORD เมื่อมีการสั่ง restic forget --prune จากแหล่งข้อมูล คำสั่งนั้นจะล้มเหลวซึ่งเป็นผลลัพธ์ที่ต้องการ ดังนั้นการจัดการ retention จึงต้องทำจากเครื่องที่สองซึ่งมีข้อมูลประจำตัวของตนเอง คู่มือของ restic ยังแนะนำให้ใช้ --keep-within แทนการกำหนดนโยบายตามจำนวน (count-based policies) บน repository แบบ append-only เนื่องจากผู้โจมตีที่ส่ง snapshot ขยะจำนวนมากเข้ามาอาจทำให้ snapshot จริงของคุณหลุดออกจากกรอบเวลา --keep-last ได้

rsync แก้ไขปัญหาเดียวกันนี้ในเชิงโครงสร้างด้วยการดึงข้อมูล (pull) เนื่องจากแหล่งข้อมูลไม่มีข้อมูลประจำตัวสำหรับปลายทาง

กฎข้อเดียวที่ครอบคลุมทั้งสามรูปแบบคือ ข้อมูลประจำตัวที่สามารถลบข้อมูลสำรองได้จะต้องถูกเก็บไว้บนเครื่องที่ไม่ใช่เครื่องที่กำลังถูกสำรองข้อมูล

กำหนดตารางเวลาสำหรับการซ้อมกู้คืนข้อมูล

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

restic snapshots
restic restore latest --target /var/tmp/restore-test --include /etc/nginx
diff -r /etc/nginx /var/tmp/restore-test/etc/nginx

diff -r หากไม่แสดงผลลัพธ์ใดๆ หมายความว่าโครงสร้างข้อมูลที่กู้คืนมาตรงกับข้อมูลจริง สำหรับ PBS การซ้อมในลักษณะเดียวกันคือ proxmox-backup-client restore host/web1/2026-08-13T02:30:00Z root.pxar /var/tmp/restore-test/ รวมถึงการตั้งค่าจ็อบตรวจสอบ (verify job) ตามกำหนดการ ซึ่งจะอ่านข้อมูลเป็นส่วนๆ บนปลายทางและรายงานหากพบความผิดพลาดของ checksum

การซ้อมกู้คืนต้องพิสูจน์ให้ได้มากกว่าแค่ความสมบูรณ์ของไบต์ข้อมูล

• ให้กู้คืนจากเครื่องที่สามที่ไม่ใช่เครื่องต้นทาง เพราะคุณกำลังตั้งสมมติฐานว่าเครื่องต้นทางนั้นเสียหายไปแล้ว นั่นหมายความว่ารหัสผ่านของ repository หรือคีย์ของ PBS จะต้องสามารถเข้าถึงได้โดยไม่ต้องพึ่งพาเครื่องต้นทาง
• จับเวลาในการกู้คืนและจดบันทึกไว้ จากนั้นนำไปเปรียบเทียบกับ RTO ที่คุณกำหนดไว้ แผนภูมิด้านบนแสดงถึงขีดจำกัดขั้นต่ำของการถ่ายโอนข้อมูล แต่ตัวเลขจริงจะรวมถึงเวลาในการถอดรหัส การเขียนลงดิสก์ และเวลาที่ใช้ในการตัดสินใจเลือก snapshot ที่ต้องการ
• กู้คืนข้อมูลที่มีสถานะ (state) เช่น ไฟล์ดัมพ์ของฐานข้อมูลที่คุณนำไปโหลดลงในอินสแตนซ์ทดสอบ การที่ไฟล์ tar แตกไฟล์ได้สำเร็จไม่ใช่เครื่องพิสูจน์ว่าแอปพลิเคชันจะสามารถเริ่มทำงานได้จริง

ดิสก์ที่ราคาถูกที่สุดในโลกจะไม่มีค่าใดๆ เลย จนกว่าคุณจะเคยใช้มันกู้คืนข้อมูลสำเร็จอย่างน้อยหนึ่งครั้ง

FAQ

Snapshot ที่ผู้ให้บริการ VPS มีให้ ถือเป็น off-site backup หรือไม่?

ไม่ถือเป็น off-site backup เนื่องจาก snapshot ของผู้ให้บริการจะอยู่ในบัญชีเดียวกัน ภายใต้การเข้าสู่ระบบเดียวกัน และอยู่ในใบแจ้งหนี้เดียวกันกับเซิร์ฟเวอร์ต้นทาง หากผู้ใดเข้าถึงบัญชีดังกล่าวได้ ก็สามารถลบทั้งเซิร์ฟเวอร์และ snapshot ทั้งหมดทิ้งได้ในการดำเนินการครั้งเดียว Snapshot มีประโยชน์สำหรับการย้อนกลับอย่างรวดเร็ว (rollback) ก่อนการอัปเกรดที่มีความเสี่ยง แต่ไม่ใช่การสำรองข้อมูลในสถานที่อื่น การสำรองข้อมูลแบบ off-site ที่แท้จริงต้องอยู่ในบัญชีที่แตกต่างกัน และควรอยู่กับผู้ให้บริการรายอื่น โดยใช้ข้อมูลรับรอง (credentials) ที่เครื่องต้นทางไม่มีสิทธิ์เข้าถึง

ต้องใช้พื้นที่ดิสก์เท่าใดสำหรับการเก็บสำรองข้อมูลย้อนหลัง 1 เดือน?

ให้คำนวณจากอายุของ snapshot ที่เก่าที่สุด แทนที่จะนับจำนวน snapshot เครื่องมือที่ทำ deduplication จะจัดเก็บข้อมูลส่วนที่ซ้ำกันเพียงชุดเดียว ดังนั้นขนาดของ repository จะเท่ากับขนาดของข้อมูลต้นทาง บวกกับข้อมูลใหม่ที่ไม่ซ้ำกันในแต่ละวันคูณด้วยจำนวนวันที่เก็บรักษา หากคุณมีข้อมูล 500 GB และมีการเปลี่ยนแปลงวันละ 5 GB การเก็บข้อมูลรายวันย้อนหลัง 1 สัปดาห์จะใช้พื้นที่ประมาณ 535 GB และหากเก็บประวัติย้อนหลัง 1 ปี จะใช้พื้นที่ 2,325 GB ควรเผื่อพื้นที่ว่างไว้เสมอ เพราะหากดิสก์เต็ม การสำรองข้อมูลครั้งถัดไปจะล้มเหลว และกระบวนการ prune ของ restic จำเป็นต้องใช้พื้นที่ว่างในการ repack ไฟล์ก่อนที่จะคืนพื้นที่ให้

เซิร์ฟเวอร์ที่ถูกบุกรุกสามารถลบข้อมูลสำรอง off-site ของตัวเองได้หรือไม่?

สามารถทำได้ หากคุณไม่ได้ออกแบบระบบป้องกันไว้ ในกรณีที่ใช้ repository แบบ SSH หรือ SFTP ทั่วไป กุญแจที่ใช้เขียนข้อมูลก็มีสิทธิ์ลบข้อมูลได้เช่นกัน คุณควรให้สิทธิ์เครื่องต้นทางเฉพาะที่จำเป็น เช่น ใช้ PBS API token ที่มีบทบาทเพียง DatastoreBackup ซึ่งไม่มีสิทธิ์ Datastore.Prune หรือใช้ restic ร่วมกับ rest-server ที่รันด้วยแฟล็ก --append-only ซึ่งจะปฏิเสธการลบหรือแก้ไขข้อมูลสำรองที่มีอยู่เดิม การออกแบบระบบแบบ pull จะปลอดภัยยิ่งขึ้น เพราะเครื่องต้นทางจะไม่มีข้อมูลรับรองใดๆ ของโฮสต์สำรองข้อมูลเลย และควรจัดการเรื่องการเก็บรักษาข้อมูล (retention) จากฝั่งที่ไม่ใช่เครื่องต้นทาง

ควรใช้ Proxmox Backup Server หรือ restic บน VPS สำรองข้อมูล?

ให้เลือกเครื่องมือตามหน่วยที่คุณต้องการกู้คืน หากต้นทางเป็น Proxmox VE และคุณต้องการกู้คืนทั้ง virtual machine ให้ใช้ PBS เพราะเป็นการสำรองข้อมูลในระดับ disk-image และกู้คืน VM ได้ในขั้นตอนเดียว หากต้นทางเป็น Linux host และคุณต้องการกู้คืนไฟล์หรือ database dumps ให้ใช้ restic ซึ่งต้องการเพียงบัญชี SSH บนปลายทางและทำการเข้ารหัสข้อมูลก่อนส่ง การใช้งานทั้งสองอย่างร่วมกันเป็นเรื่องปกติ คือใช้ PBS สำหรับ hypervisor และใช้ restic สำหรับเซิร์ฟเวอร์อื่นๆ ที่ไม่ได้อยู่บนนั้น

การกู้คืนข้อมูลจาก VPS backup ใช้เวลานานเท่าใด?

ให้คำนวณโดยนำขนาดข้อมูลหารด้วยความเร็วเครือข่ายเพื่อหาเวลาขั้นต่ำ จากนั้นบวกเวลาสำหรับการถอดรหัสและการเขียนข้อมูลลงดิสก์ ข้อมูลขนาด 500 GB บนลิงก์ความเร็ว 100 Mbit/s จะใช้เวลา 11.1 ชั่วโมงตามทฤษฎี และหากกู้คืนผ่านพอร์ต 1 Gbit/s จะใช้เวลา 1.1 ชั่วโมง การกู้คืนไฟล์ขนาดเล็กจำนวนมากจะช้ากว่าตัวเลขทางคณิตศาสตร์นี้เนื่องจากมี overhead ต่อไฟล์ คุณควรทดสอบการกู้คืนจริงหนึ่งครั้งและใช้ตัวเลขที่วัดได้นั้นเป็นเกณฑ์ เพราะเป็นตัวเลขเดียวที่แผนการกู้คืนของคุณเชื่อถือได้จริง