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

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 โดยไม่ต้องเสียค่าใช้จ่ายในการดาวน์โหลดข้อมูลทั้งหมด

ขั้นตอนที่สองคือการซ้อมกู้คืน ในขณะที่ยังอยู่ใน 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 และรวมไดเรกทอรีที่เก็บไฟล์ดัมพ์ไว้ในรายการ path ที่ต้องการสำรองข้อมูล:

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 จะทำการหยุดคอนเทนเนอร์ไว้ชั่วครู่เพื่อคัดลอกไฟล์ db.sqlite3 แบบ cold copy และไฟล์ที่เก็บถาวรนั้นเองคือสิ่งที่ restic จะนำออกจากเซิร์ฟเวอร์ไป

FAQ

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

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

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

snapshot ทุกตัวของ restic ทำงานเสมือนการสำรองข้อมูลแบบเต็ม แต่ใช้พื้นที่จัดเก็บแบบ incremental โดย restic จะแบ่งไฟล์ออกเป็นส่วนย่อย (chunks) และอัปโหลดเฉพาะส่วนที่ยังไม่มีใน 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 ไม่มีช่องทางลับ (back door) และไม่มีการรีเซ็ต ดังนั้นรหัสผ่านจึงมีความสำคัญเท่ากับตัวข้อมูลสำรองเอง ควรเก็บสำเนารหัสผ่านไว้ในโปรแกรมจัดการรหัสผ่านของคุณและในที่ที่ทนทานอื่น ๆ ซึ่งไม่ใช่เซิร์ฟเวอร์ที่ถูกสำรองข้อมูล ในขณะที่คุณยังเข้าถึงข้อมูลได้อยู่ คุณสามารถใช้ restic key add เพื่อลงทะเบียนรหัสผ่านที่สองสำหรับ repository เดียวกัน ซึ่งจะช่วยให้คุณมีรหัสผ่านสำรองไว้ใช้งาน