วิธีใช้ Restic สำรองข้อมูล VPS ไปยังที่อื่น

ทำไมการสำรองข้อมูลไว้ในเซิร์ฟเวอร์เครื่องเดิมจึงไม่ใช่การสำรองข้อมูลที่แท้จริง

Restic เป็นเครื่องมือสำรองข้อมูลแบบ open source ที่ใช้งานได้ฟรี โดยจะส่ง snapshot ของไฟล์ที่ผ่านการเข้ารหัสและทำ deduplication ไปยัง repository ที่อื่น เช่น VPS เครื่องที่สอง, เครื่องคอมพิวเตอร์ที่บ้าน หรือ object storage ที่รองรับ S3 คู่มือนี้จะสอนการติดตั้งบน Ubuntu 24.04 ตั้งแต่ขั้นตอนการติดตั้ง, การสร้าง repository ผ่าน SFTP, การสำรองข้อมูลครั้งแรก, การตั้งค่า systemd timer สำหรับการทำงานรายคืน, การกำหนดนโยบายการเก็บรักษาข้อมูล (retention policy) และการทดสอบการกู้คืนข้อมูลเพื่อยืนยันว่าระบบทำงานได้จริง ทั้งนี้ ปลายทางที่เก็บข้อมูลต้องเป็นเครื่องอื่นเท่านั้น เพราะหากเก็บสำเนาไว้ในเซิร์ฟเวอร์เครื่องเดียวกัน ข้อมูลจะสูญหายไปพร้อมกับเซิร์ฟเวอร์นั้น

การเก็บ directory backup/ ไว้ในเครื่องที่ทำการสำรองข้อมูลจะช่วยป้องกันได้เพียงกรณีเดียวเท่านั้น คือการลบไฟล์โดยไม่ตั้งใจ ข้อมูลจะไม่สามารถกู้คืนได้หาก disk เสีย เนื่องจากข้อมูลถูกเก็บไว้บน disk ชุดนั้น ข้อมูลจะไม่สามารถกู้คืนได้หากถูกผู้โจมตีที่มีสิทธิ์ root เข้าถึง เพราะผู้โจมตีจะลบสำเนาข้อมูลทิ้งเป็นอันดับแรก และข้อมูลจะไม่สามารถกู้คืนได้หากเกิดความผิดพลาดในการจัดการบัญชีที่ทำให้ VPS ถูกลบออกไป Datacenter ที่ไม่มีประสิทธิภาพที่สุดในโลก ล้อเลียนเรื่องไฟล์ tarball ชื่อ backup_final_v2_REAL ที่เก็บไว้บน array ชุดเดียวกับข้อมูลหลัก ซึ่งเป็นเรื่องที่เกิดขึ้นจริงกับผู้ใช้งานจำนวนมาก กฎเหล็กคือต้องเก็บข้อมูลไว้คนละเครื่อง และ restic คือวิธีที่ง่ายที่สุดในการปฏิบัติตามกฎนี้

Restic ใน 4 แนวคิดหลัก

Repository. สถานที่สำหรับเขียนข้อมูลของ restic เป็น directory ในรูปแบบเฉพาะของ restic ซึ่งประกอบด้วย encrypted blobs และมีเพียง restic เท่านั้นที่สามารถอ่านได้ ห้ามแก้ไขข้อมูลด้วยตนเองโดยตรง การจัดการข้อมูลต้องทำผ่าน restic commands และ -r address เท่านั้น

Snapshot. ภาพจำลองสถานะของไฟล์ที่สำรองข้อมูล ณ เวลาใดเวลาหนึ่ง การสำรองข้อมูลแต่ละครั้งจะสร้าง snapshot ขึ้นมาหนึ่งชุด โดยแต่ละ snapshot สามารถนำมา restore แยกกันได้ และแต่ละชุดจะทำหน้าที่เสมือนเป็นข้อมูลฉบับสมบูรณ์ ณ ขณะนั้น

Deduplication. restic จะแบ่งไฟล์ออกเป็น chunks ตามเนื้อหา และจะอัปโหลดเฉพาะ chunks ที่ repository ยังไม่มีข้อมูลเท่านั้น การสำรองข้อมูลครั้งแรกจะเป็นการอัปโหลดข้อมูลทั้งหมด ส่วนการสำรองข้อมูลครั้งถัดไปจะอัปโหลดเฉพาะข้อมูลที่มีการเปลี่ยนแปลงเป็นหลัก ตัวอย่างเช่น หากมี snapshot รายคืนขนาด 20 GB และมีการเปลี่ยนแปลง 50 MB การสำรองข้อมูลจะใช้พื้นที่เพิ่มเพียงประมาณ 50 MB ด้วยเหตุนี้การเก็บ snapshot จำนวนมากจึงใช้พื้นที่น้อย

Encryption by default. repository ของ restic จะถูกเข้ารหัสเสมอ (AES-256) และทุกคำสั่งจำเป็นต้องใช้ password ของ repository เครื่องที่ทำการ backup หรือผู้ให้บริการ storage จะเห็นเพียง encrypted blobs เท่านั้น ผลที่ตามมาคือ หากสูญเสีย password ข้อมูลจะสูญหายไปอย่างถาวรตามการออกแบบ โปรดเก็บสำเนา password ไว้ในที่อื่นที่ไม่ใช่บน server เครื่องนี้ เรื่องนี้มีความสำคัญมากจนต้องกล่าวถึงอีกสองครั้งในเนื้อหาถัดไป

Install restic on Ubuntu 24.04

sudo apt update && sudo apt install -y restic
restic version

บน Ubuntu 24.04 จะเป็นการติดตั้ง restic เวอร์ชัน 0.16.4 ในขณะที่เวอร์ชันล่าสุดจากต้นทางคือ 0.19.1 สาเหตุที่เวอร์ชันต่างกันเนื่องจากรุ่น LTS (long term support) จะมีการกำหนดเวอร์ชันของ package ให้คงที่ อย่างไรก็ตาม เวอร์ชัน 0.16.4 สามารถใช้งานตามคู่มือนี้ได้ครบถ้วน หากต้องการเวอร์ชันล่าสุดเพื่อประสิทธิภาพด้านความเร็ว ให้ดาวน์โหลด single-binary build อย่างเป็นทางการจากหน้า GitHub releases ของโปรเจกต์ restic จากนั้นแตกไฟล์ด้วย bunzip2 และติดตั้งไปยัง /usr/local/bin/restic การติดตั้ง restic มีเพียงขั้นตอนเหล่านี้เท่านั้น

การสร้าง repository บนเซิร์ฟเวอร์อื่นผ่าน SFTP

คุณต้องมีเครื่องปลายทาง: โดยทั่วไปคือ VPS ขนาดเล็กเครื่องที่สอง หรือเครื่องใดก็ได้ที่มี SSH server และมีพื้นที่ว่างบน disk เพียงพอ เนื่องจาก Restic รองรับโปรโตคอล SFTP (file transfer over SSH) เครื่อง host สำหรับเก็บ backup จึงไม่จำเป็นต้องติดตั้งซอฟต์แวร์ใดๆ ในคู่มือนี้ เครื่อง host สำหรับเก็บ backup คือ 10.0.0.12 โดยมีผู้ใช้ชื่อ restic ห้ามตั้งชื่อผู้ใช้ว่า backup เนื่องจาก Ubuntu และ Debian มีบัญชีระบบที่ถูกจองไว้คือ backup (uid 34, no login shell) ในทุกการติดตั้ง ซึ่งจะทำให้ adduser backup ล้มเหลว และ ssh backup@... จะไปอยู่ที่ nologin

งานที่รันตอนกลางคืน (nightly job) จะทำงานด้วยสิทธิ์ root บนเซิร์ฟเวอร์ที่ถูก backup ดังนั้น root จึงต้องสามารถ login เข้าเครื่อง backup ด้วย key ได้ ให้สร้าง key เฉพาะที่ไม่มี passphrase เนื่องจากไม่มีผู้ใช้งานมาพิมพ์รหัสผ่านในช่วงเวลา 03:00 น. จากนั้นจึงคัดลอก key ไปยังเครื่องปลายทาง:

sudo ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519 -N "" -C "web1-restic"
sudo ssh-copy-id -i /root/.ssh/id_ed25519.pub restic@10.0.0.12
sudo ssh restic@10.0.0.12 true && echo key login works

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

ถัดไปคือการตั้งรหัสผ่านสำหรับ repository ให้สร้างรหัสผ่านที่คาดเดายากลงในไฟล์ที่อนุญาตให้เฉพาะ root เท่านั้นที่เข้าถึงได้:

openssl rand -base64 32 | sudo tee /root/.restic-password
sudo chmod 600 /root/.restic-password

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

การเริ่มต้นใช้งาน (Initialise) repository:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password init

created restic repository 9f3c2a1b0d at sftp:restic@10.0.0.12:/srv/restic/web1

ปลายทางอีกรูปแบบหนึ่งคือ S3-compatible object storage ซึ่งเป็นทางเลือกที่เหมาะสมหากคุณไม่ต้องการรันเครื่องเซิร์ฟเวอร์เครื่องที่สอง Bucket ที่รองรับ S3 ทุกรูปแบบสามารถใช้งานในลักษณะเดียวกัน โดยจะเปลี่ยนเพียงที่อยู่ (address) และตัวแปร credential สองตัวเท่านั้น:

export AWS_ACCESS_KEY_ID=your-key-id
export AWS_SECRET_ACCESS_KEY=your-secret-key
sudo -E restic -r s3:https://s3.example.com/web1-backups --password-file /root/.restic-password init

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

การสำรองข้อมูลครั้งแรก พร้อมการยกเว้นไฟล์

สำรองเฉพาะข้อมูลที่ไม่สามารถติดตั้งใหม่ได้ ไม่ใช่ทั้ง filesystem การติดตั้งระบบปฏิบัติการใหม่สามารถทำได้ แต่การตั้งค่าและข้อมูลของคุณไม่สามารถทำได้เช่นนั้น สำหรับ VPS ทั่วไป ข้อมูลเหล่านั้นคือ /etc, /home และตำแหน่งที่แอปพลิเคชันเก็บข้อมูลสถานะ เช่น /srv หรือ /var/www ควรยกเว้นไฟล์ cache เนื่องจากมีขนาดใหญ่ มีการเปลี่ยนแปลงทุกวัน และสามารถสร้างขึ้นใหม่ได้เอง:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password backup /etc /home /srv --exclude '/home/*/.cache'

Files:        4181 new,     0 changed,     0 unmodified
Added to the repository: 731.204 MiB (312.418 MiB stored)
snapshot 5b8a3f2c saved

การทำงานครั้งแรกจะอัปโหลดข้อมูลทั้งหมดจึงใช้เวลานาน เมื่อรันคำสั่งเดิมอีกครั้งจะเสร็จสิ้นภายในไม่กี่วินาที โดยจะรายงานว่ามีไฟล์เปลี่ยนแปลงเพียงเล็กน้อยและมีข้อมูลเพิ่มขึ้นเพียงไม่กี่ MiB เนื่องจากระบบ deduplication จะอัปโหลดเฉพาะ chunk ใหม่เท่านั้น ตรวจสอบรายการข้อมูลของคุณด้วยคำสั่ง:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password snapshots

แต่ละ snapshot จะแสดง ID, เวลา และ path ที่บรรจุอยู่ ID เหล่านี้คือสิ่งที่ใช้ในการ restore ข้อมูล

การรันงานแบบ Nightly ด้วย systemd timer

การพิมพ์ repository address ในทุกคำสั่งเป็นเรื่องที่เสียเวลา และการสำรองข้อมูลด้วยตนเองมักจะถูกลืมภายในหนึ่งเดือน วิธีแก้ปัญหาทั้งสองนี้คือการใช้ script และ timer เพียงอย่างเดียว โดย script จะกำหนด environment variables สองตัวที่ restic ต้องใช้ คือ RESTIC_REPOSITORY และ RESTIC_PASSWORD_FILE เพื่อให้คำสั่งภายใน script สั้นลง:

sudo nano /usr/local/bin/restic-backup.sh

#!/usr/bin/env bash
set -euo pipefail
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password

restic backup /etc /home /srv --exclude '/home/*/.cache'
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

sudo chmod 700 /usr/local/bin/restic-backup.sh

รายละเอียดของบรรทัด forget และ check จะอธิบายในสองส่วนถัดไป สำหรับการตั้งเวลา จะใช้ oneshot service เพื่อรัน script และใช้ timer เพื่อสั่งให้ทำงานตอน 03:00 ของทุกคืน การใช้ timer มีข้อดีกว่า cron เนื่องจาก log การทำงานจะถูกบันทึกลงใน journal และ Persistent=true จะสั่งให้รันการสำรองข้อมูลที่พลาดไปทันทีเมื่อ server กลับมาออนไลน์หลังจาก downtime

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Nightly restic backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/restic-backup.sh

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run the nightly restic backup

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target

เปิดใช้งาน timer จากนั้นให้ลองรัน service ด้วยตนเองหนึ่งครั้งเพื่อตรวจสอบการทำงาน:

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
sudo journalctl -u restic-backup.service -f

คำสั่ง systemctl list-timers จะแสดงเวลาที่การรันครั้งถัดไปจะเริ่มขึ้น คุณสามารถสร้างไฟล์ unit ทั้งสองไฟล์ได้โดยตรงแทนการพิมพ์เอง:

รูปแบบการทำงานทั้งหมดของไฟล์ทั้งสองนี้ รวมถึงไวยากรณ์แบบปฏิทินและคำสั่ง hardening สำหรับ service สามารถศึกษาได้ที่ running a program as a systemd service on a VPS

การสำรองข้อมูลจะมีค่าก็ต่อเมื่อคุณสามารถกู้คืนได้จริง

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

ขั้นตอนแรกคือ restic check ซึ่งสคริปต์จะทำงานทุกคืนอยู่แล้ว ขั้นตอนนี้จะตรวจสอบโครงสร้างของ repository และ index เพื่อให้ตรวจพบความเสียหายของข้อมูล (corruption) บน backup host ได้ในคืนถัดไป แทนที่จะไปพบในวันที่ต้องกู้คืนข้อมูลจริง ทุกๆ หนึ่งเดือน ให้รันคำสั่งเวอร์ชันที่ละเอียดกว่าเดิม ซึ่งจะทำการดาวน์โหลดและตรวจสอบความถูกต้องทางรหัสผ่าน (cryptographically verify) ข้อมูลจริงแบบสุ่มจำนวน 10%:

sudo -i
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic check --read-data-subset=10%

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

ขั้นตอนที่สองคือ การซ้อมกู้คืนข้อมูล (restore drill) ให้ใช้ root shell จากขั้นตอนข้างต้น เพื่อกู้คืน directory จริงหนึ่งรายการจาก snapshot ล่าสุดไปยังตำแหน่งชั่วคราว (scratch location) แล้วทำการเปรียบเทียบกับไฟล์ที่ใช้งานอยู่จริง:

restic restore latest --target /srv/restore-drill --include /etc/ssh
diff -r /etc/ssh /srv/restore-drill/etc/ssh

หาก diff ไม่แสดงผลใดๆ แสดงว่าข้อมูลทุก byte ถูกกู้คืนมาอย่างถูกต้องและเหมือนเดิมทุกประการ ซึ่งเป็นหลักฐานเดียวที่เชื่อถือได้ หลังจากนั้นให้ลบ /srv/restore-drill ทิ้ง ให้ทำขั้นตอนการซ้อมนี้ทุกเดือน และปีละ 1 หรือ 2 ครั้ง ให้ทำเวอร์ชันเต็ม โดยการกู้คืน snapshot ล่าสุดทั้งหมดลงบน VPS ชั่วคราว และตรวจสอบว่า application สามารถเริ่มต้นทำงานจากข้อมูลนั้นได้จริง ในวันที่คุณจำเป็นต้องกู้คืนข้อมูลภายใต้ความกดดัน คุณควรมีขั้นตอนที่เคยทำจนเป็นกิจวัตรเตรียมพร้อมไว้แล้ว

Retention: forget และ prune

หากไม่มีการกำหนด policy จะทำให้ snapshot สะสมเพิ่มขึ้นเรื่อยๆ และทำให้ repository มีขนาดใหญ่ขึ้นอย่างต่อเนื่อง คำสั่งในบรรทัด forget ของ script จะใช้ policy ทุกคืน โดย --keep-daily 7 จะเก็บไว้หนึ่ง snapshot ต่อวันสำหรับเจ็ดวันที่ผ่านมา, --keep-weekly 4 จะเก็บไว้หนึ่ง snapshot ต่อสัปดาห์สำหรับสี่สัปดาห์ และ --keep-monthly 6 จะเก็บไว้หนึ่ง snapshot ต่อเดือนสำหรับหกเดือน ข้อมูลใดๆ ที่ไม่อยู่ภายใต้กฎที่กำหนดจะถูกลบออก

คำสั่ง forget เพียงอย่างเดียวจะลบเฉพาะรายการ snapshot เท่านั้น แต่ data chunks จะยังคงอยู่ใน repository จนกว่าจะมีการลบออกอย่างสมบูรณ์ นั่นคือหน้าที่ของ --prune ซึ่งจะค้นหา chunks ที่ไม่มี snapshot ใดอ้างอิงถึงแล้วทำการลบออก ซึ่งเป็นขั้นตอนที่ทำให้ได้พื้นที่ดิสก์คืนมาจริงๆ การ prune คือการจัดการข้อมูลใน repository จริงๆ ดังนั้นใน repository ขนาดใหญ่ บางคนจึงรัน forget ทุกคืน และรัน --prune ทุกสัปดาห์ สำหรับ VPS ขนาดทั่วไป การรันทุกคืนก็เพียงพอแล้ว

Databases: dump first, then back up the dump

Restic จะคัดลอกไฟล์ในขณะที่กำลังอ่านข้อมูล แต่ฐานข้อมูลจะเขียนข้อมูลลงไฟล์อย่างต่อเนื่อง หากคัดลอกไฟล์ฐานข้อมูลที่กำลังทำงานอยู่จะทำให้ฐานข้อมูลเสียหายเมื่อนำมา restore เนื่องจากข้อมูลที่คัดลอกมาเป็นข้อมูลที่ผสมกันระหว่างหน้าข้อมูล (pages) ก่อนและหลังการเขียน วิธีแก้ไขมาตรฐานคือ ให้ database engine ทำการ export ข้อมูลที่สมบูรณ์ออกมาเป็นไฟล์ จากนั้นจึงให้ restic ทำการ backup ไฟล์นั้น

สำหรับ PostgreSQL ให้เพิ่มคำสั่ง dump ไว้ที่ด้านบนของ restic-backup.sh ก่อนคำสั่ง restic backup และต้องระบุ directory ของ dump ลงใน backup paths ด้วย:

mkdir -p /var/backups/db
sudo -u postgres pg_dump myapp | gzip > /var/backups/db/myapp.sql.gz

mysqldump ใช้หลักการเดียวกันสำหรับ MariaDB และ MySQL สำหรับตัวอย่างการใช้งานรูปแบบนี้ทั้งหมด ส่วนการ backup Nextcloud จะทำการเปิด maintenance mode, ทำการ dump Postgres และคัดลอกไฟล์ทั้งหมดเป็นชุดข้อมูลที่สอดคล้องกัน ซึ่งเป็นชุดข้อมูลที่ restic ควรคัดลอกออกจากระบบในทุกคืน ส่วน SQLite ใช้หลักการเดียวกันแต่ใช้วิธีที่ง่ายกว่า: คู่มือ Vaultwarden จะหยุดการทำงานของ container ชั่วคราวเพื่อทำการคัดลอก db.sqlite3 แบบ cold copy และไฟล์ archive นั้นคือสิ่งที่ restic จะส่งออกจาก server

FAQ

การสำรองข้อมูลด้วย restic มีการเข้ารหัสหรือไม่?

มีเสมอ ทุก repository ของ restic จะถูกเข้ารหัสด้วย AES-256 โดยไม่มีโหมดที่ไม่เข้ารหัส และทุกคำสั่งจำเป็นต้องใช้รหัสผ่านของ repository เครื่องคอมพิวเตอร์หรือผู้ให้บริการที่เก็บ repository จะเก็บได้เพียงข้อมูลที่เข้ารหัสแล้วเท่านั้น ดังนั้นหาก host ที่เก็บ backup ถูกบุกรุก ไฟล์ของคุณจะยังคงปลอดภัย ข้อตกลงนี้มีความเด็ดขาด: หากไม่มีรหัสผ่าน จะไม่มีใครสามารถกู้คืนข้อมูลได้ ดังนั้นควรเก็บสำเนารหัสผ่านไว้ในที่ที่ปลอดภัยแยกจาก server

restic ทำการสำรองข้อมูลแบบ incremental หรือไม่?

ทุก snapshot ของ restic ทำงานเสมือนการสำรองข้อมูลแบบ full backup แต่ใช้พื้นที่จัดเก็บแบบ incremental โดย restic จะแบ่งไฟล์ออกเป็น chunks และอัปโหลดเฉพาะ chunks ที่ repository ยังไม่มีอยู่เท่านั้น ดังนั้นการรันงานทุกคืนจะส่งข้อมูลเฉพาะส่วนที่เปลี่ยนแปลงในวันนั้น ต่างจากระบบ incremental แบบดั้งเดิมที่ต้องไล่ลำดับตาม chain: snapshot ใดๆ สามารถกู้คืนได้โดยตรง และการลบ snapshot เก่าจะไม่ส่งผลกระทบต่อ snapshot ที่ใหม่กว่า

ฉันจะกู้คืนไฟล์จาก restic backup ได้อย่างไร?

รัน restic snapshots เพื่อหา snapshot ID จากนั้นรัน restic restore <id> --target /some/empty/dir เพื่อกู้คืน หรือเพิ่ม --include /path เพื่อกู้คืนเพียงบางส่วน สามารถใช้ latest แทน ID ได้ restic จะสร้างโครงสร้างไดเรกทอรีเดิมขึ้นมาใหม่ภายใต้ตำแหน่งปลายทาง ดังนั้นการกู้คืน /etc/ssh จะไปอยู่ที่ /some/empty/dir/etc/ssh ควรทดลองทำก่อนใช้งานจริง เพราะการสำรองข้อมูลที่ไม่ได้ทดสอบนั้นเชื่อถือไม่ได้

ฉันควรรัน restic backup บ่อยแค่ไหน?

สำหรับการใช้งาน server การรันทุกคืนเป็นระดับขั้นต่ำที่เหมาะสม และการทำ deduplication ช่วยให้ประหยัดทรัพยากร เนื่องจากแต่ละครั้งที่รันจะอัปโหลดเฉพาะ chunks ที่เปลี่ยนไปจากครั้งล่าสุดเท่านั้น สำหรับข้อมูลที่มีการเปลี่ยนแปลงเร็วหรือข้อมูลที่สูญเสียไม่ได้แม้เพียงวันเดียว สามารถตั้งเวลาให้รันทุกๆ ไม่กี่ชั่วโมงได้ด้วยรูปแบบ timer แบบเดียวกัน ความถี่ในการรันเป็นเรื่องง่าย แต่ควรต้องรัน restic check อย่างสม่ำเสมอและทดสอบการกู้คืน (restore drill) ทุกเดือน เพราะการตั้งตารางเวลาโดยไม่มีการตรวจสอบคือความสบายใจที่หลอกลวง

จะเกิดอะไรขึ้นหากฉันลืมรหัสผ่าน restic repository?

ข้อมูลสำรองจะไม่สามารถกู้คืนได้ การเข้ารหัสของ restic ไม่มีช่องทางพิเศษ (back door) และไม่มีระบบรีเซ็ต ดังนั้นรหัสผ่านจึงมีความสำคัญเท่ากับตัวข้อมูลสำรองเอง ควรเก็บสำเนาไว้ใน password manager หรือที่เก็บข้อมูลที่ทนทานอื่นๆ ที่ไม่ใช่ server ที่สำรองข้อมูลไว้ ในขณะที่ยังเข้าถึงได้ คุณสามารถใช้ restic key add เพื่อลงทะเบียนรหัสผ่านที่สองสำหรับ repository เดิมเพื่อใช้เป็นรหัสสำรองได้