วิธีสำรองข้อมูล VPS ด้วย Restic ไปยังที่เก็บข้อมูลภายนอก

เหตุผลที่การสำรองข้อมูลไว้บนเซิร์ฟเวอร์เดียวกันไม่ใช่การสำรองข้อมูล

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

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

Restic ใน 4 แนวคิด

Repository. คือพื้นที่ที่ restic ใช้เขียนข้อมูล เป็นไดเรกทอรีในรูปแบบเฉพาะของ restic ซึ่งเต็มไปด้วยข้อมูลที่เข้ารหัสไว้ และมีเพียง restic เท่านั้นที่อ่านได้ คุณไม่ควรแก้ไขไฟล์ในนี้ด้วยตัวเอง แต่ให้โต้ตอบผ่านคำสั่งของ restic และระบุที่อยู่ผ่าน -r

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

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

Encryption by default. repository ของ restic จะถูกเข้ารหัสเสมอ (AES-256) restic จะปฏิเสธการสร้างหรือเปิด repository ที่ไม่มีรหัสผ่าน เว้นแต่คุณจะระบุแฟล็ก --insecure-no-password (สำหรับ restic 0.17.0 ขึ้นไป) ดังนั้น repository ที่ตั้งค่าตามคู่มือนี้จึงจำเป็นต้องใช้รหัสผ่านในทุกคำสั่ง โฮสต์ที่สำรองข้อมูลหรือผู้ให้บริการพื้นที่จัดเก็บจะเห็นเพียงข้อมูลที่เข้ารหัสไว้เท่านั้น ผลลัพธ์ที่สำคัญคือ หากคุณทำรหัสผ่านหาย ข้อมูลจะสูญหายอย่างถาวรตามการออกแบบของระบบ โปรดเก็บสำเนาของรหัสผ่านไว้ในที่อื่นที่ไม่ใช่เซิร์ฟเวอร์นี้

การติดตั้ง restic บน 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) จะคงเวอร์ชันของแพ็กเกจไว้ตามเดิม ซึ่งไม่มีผลกระทบในกรณีนี้ เนื่องจาก 0.16.4 สามารถทำงานทุกอย่างที่ระบุในคู่มือนี้ได้ หากคุณต้องการเวอร์ชันล่าสุดเพื่อใช้ประโยชน์จากการปรับปรุงความเร็ว ให้ดาวน์โหลดไฟล์ binary เดี่ยวอย่างเป็นทางการจากหน้า GitHub releases ของโปรเจกต์ restic จากนั้นแตกไฟล์ด้วย bunzip2 และติดตั้งลงใน /usr/local/bin/restic การติดตั้ง restic ไม่มีขั้นตอนอื่นนอกเหนือจากนี้

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

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

งานสำรองข้อมูลรายคืนจะทำงานในฐานะ root บนเซิร์ฟเวอร์ที่ถูกสำรองข้อมูล ดังนั้น root จึงจำเป็นต้องเข้าสู่ระบบโฮสต์สำรองข้อมูลผ่าน 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

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

เริ่มต้นใช้งาน 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

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

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

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

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 จะอัปโหลดเฉพาะส่วนข้อมูลใหม่เท่านั้น ตรวจสอบรายการที่คุณมีด้วยคำสั่ง:

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

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

การสำรองข้อมูลรายคืนด้วย systemd timer

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

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 จะถูกอธิบายในสองส่วนถัดไป ต่อไปคือตารางเวลา: service แบบ oneshot ที่เรียกใช้สคริปต์ และ timer ที่สั่งให้ทำงานตอน 03:00 น. ของทุกคืน การใช้ timer ดีกว่าการใช้ cron ในกรณีนี้เพราะการทำงานจะถูกบันทึกลงใน journal และ Persistent=true จะเรียกใช้การสำรองข้อมูลที่พลาดไปทันทีที่เซิร์ฟเวอร์กลับมาออนไลน์หลังจากหยุดทำงาน

# /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 สามารถกำหนดได้ อยู่ใน การรันโปรแกรมในฐานะ systemd service บน VPS

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

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

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

เนื่องจากชุดข้อมูลที่ตรวจสอบจะถูกเลือกแบบสุ่มในแต่ละครั้ง เอกสารของ restic จึงระบุชัดเจนว่าการรันซ้ำหลายครั้งไม่ได้รับประกันว่าจะครอบคลุมไฟล์ pack ทั้งหมด หากคุณต้องการให้การรันรายเดือนครอบคลุม repository ทั้งหมดโดยไม่ต้องดาวน์โหลดข้อมูลทั้งหมด ให้ใช้รูปแบบการระบุกลุ่มคงที่แทน: ใช้ --read-data-subset=1/10 ในเดือนแรก 2/10 ในเดือนถัดไป และทำเช่นนี้ไปจนถึง 10/10 restic จะแบ่งไฟล์ pack ออกเป็น 10 กลุ่มที่เท่ากันโดยประมาณและตรวจสอบเฉพาะกลุ่มที่ n ดังนั้นการรันครบ 10 รอบจะเท่ากับการอ่านทุกกลุ่มครบถ้วน

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

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

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

การเก็บรักษา: การ forget และ prune

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

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

ฐานข้อมูล: ให้ดัมพ์ก่อน แล้วค่อยสำรองข้อมูลไฟล์ดัมพ์นั้น

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

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

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

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

FAQ

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

มีการเข้ารหัสเสมอ repository ของ restic ทุกแห่งจะถูกเข้ารหัสด้วย AES-256 และไม่มีโหมดที่ไม่เข้ารหัส นอกจากนี้ restic ยังปฏิเสธการใช้รหัสผ่านว่างเว้นแต่คุณจะระบุ --insecure-no-password (มีให้ใช้งานตั้งแต่ restic 0.17.0) ดังนั้น repository ที่ตั้งค่าตามคู่มือนี้จึงจำเป็นต้องใช้รหัสผ่านในทุกคำสั่ง เครื่องหรือผู้ให้บริการที่จัดเก็บ repository จะถือครองเพียงข้อมูลที่เข้ารหัสไว้เท่านั้น ดังนั้นหากโฮสต์สำรองข้อมูลถูกบุกรุก ไฟล์ของคุณก็จะไม่ถูกเปิดเผย สิ่งที่ต้องแลกคือความเด็ดขาด: หากไม่มีรหัสผ่าน จะไม่มีใครสามารถกู้คืนข้อมูลได้ ดังนั้นโปรดเก็บสำเนาไว้ในที่อื่นที่ไม่ใช่เซิร์ฟเวอร์

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

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

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

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

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

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

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

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