สำรองข้อมูล VPS ให้กู้คืนไฟล์ได้จริง
สำเนาที่สำรองไว้มีประโยชน์เมื่อดึงกลับมาจากนอก VPS และกู้คืนไฟล์ที่ต้องการได้ แบบฝึกนี้ใช้ไฟล์เว็บสแตติกหนึ่งไฟล์กับ config Nginx อีกหนึ่งไฟล์ ตรวจไบต์ด้วย SHA-256 และไม่แก้เว็บไซต์ที่กำลังทำงาน
VPSuntu · อัปเดต · อ่านประมาณ 5 นาที
เนื้อหาในคู่มือนี้
กำหนดขอบเขตการฝึก
ใช้ Bash, GNU tar, sha256sum และ OpenSSH บน Ubuntu หรือ client Linux/WSL เปิดเทอร์มินัลเซิร์ฟเวอร์หนึ่งอันและ client บนอีกคอมพิวเตอร์หนึ่งอันค้างไว้ เพื่อให้ตัวแปรอยู่ครบ หยุดเมื่อคำสั่งผิดพลาด
สร้างไฟล์ฝึกสองไฟล์ใน home directory ไม่เปลี่ยน Nginx หรือไฟร์วอลล์ และไม่แตกไฟล์ด้วย root ตัวอย่างนี้ไม่ใช่แบ็กอัปทั้งเครื่องหรือฐานข้อมูล เว็บจริงต้องสำรวจ assets, redirects, includes, DNS และ dependencies เพิ่ม
เตรียมไฟล์ฝึกบนเซิร์ฟเวอร์
คำสั่งต่อไปนี้สร้างโฟลเดอร์ส่วนตัวและไฟล์ตัวอย่าง config เป็นไฟล์สำหรับเก็บสำรองเท่านั้น ไม่เปิดใช้งานกับ Nginx ข้อความ HTML และผลคำสั่งเป็นภาษาอังกฤษตามต้นฉบับเพื่อเทียบผลได้
umask 077
backup_lab=$(mktemp -d "$HOME/ubuntu-vps-backup.XXXXXX")
mkdir -p "$backup_lab/payload/site" "$backup_lab/payload/nginx" "$backup_lab/export"
printf '%s\n' '<!doctype html><html lang="en"><title>Restore drill</title><h1>Recovered static page</h1></html>' > "$backup_lab/payload/site/index.html"
printf '%s\n' 'server {' ' listen 8080;' ' server_name example.test;' ' root /var/www/first-site;' '}' > "$backup_lab/payload/nginx/first-site.conf"
printf 'Practice directory: %s\n' "$backup_lab"ใช้ไฟล์ฝึกนี้ก่อน อย่าแทน path ด้วยข้อมูลระบบจริงโดยไม่ได้กำหนดขอบเขต ตัวอย่างตั้งใจไม่คัดลอก TLS private key หรือไดเรกทอรีระบบทั้งชุด
สร้าง archive และ checksum สองชั้น
รันบนเซิร์ฟเวอร์โดยไม่แก้ payload ระหว่างขั้นตอน จด checksum ของไฟล์ภายใน บีบอัด path แบบ relative แล้วจด checksum ของ archive
(
cd "$backup_lab/payload" &&
sha256sum site/index.html nginx/first-site.conf > SHA256SUMS
)
tar -czf "$backup_lab/export/static-site.tar.gz" -C "$backup_lab/payload" site nginx SHA256SUMS
(
cd "$backup_lab/export" &&
sha256sum static-site.tar.gz > static-site.tar.gz.sha256
)
tar -tzf "$backup_lab/export/static-site.tar.gz"
printf 'Server export directory: %s\n' "$backup_lab/export"รายการควรมี site/, nginx/, ไฟล์สองไฟล์ และ SHA256SUMS checksum ภายนอกตรวจการเปลี่ยนของ archive ระหว่างส่ง ส่วน manifest ภายในตรวจไฟล์หลังแตก ทั้งสองไม่ได้ยืนยันความน่าเชื่อถือหากผู้โจมตีเปลี่ยนทั้งข้อมูลและ checksum ได้
คัดลอกไปคอมพิวเตอร์อีกเครื่อง
บน client ตั้ง remote_backup ให้ตรงกับ export directory ที่เซิร์ฟเวอร์แสดง แทน IP, บัญชี และคีย์ด้วยค่าที่ใช้ได้จริง 203.0.113.10 เป็นตัวอย่าง และ REPLACE ไม่ใช่ suffix ที่ mktemp สร้าง
umask 077
recovery_dir=$(mktemp -d "$HOME/ubuntu-vps-restore.XXXXXX")
remote_backup=/home/deploy/ubuntu-vps-backup.REPLACE/export
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz" "$recovery_dir/"
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz.sha256" "$recovery_dir/"ยืนยัน SSH host fingerprint ก่อนรับปลายทางใหม่ หากเข้าถึงไม่ได้ ใช้การแก้ปัญหา SSH ไม่ปิด host-key checking เพื่อให้ส่งผ่าน SCP ป้องกันข้อมูลระหว่างส่ง แต่ tar.gz เป็นเพียงการบีบอัด ไม่เข้ารหัส จึงต้องป้องกันบัญชีและ storage ปลายทางด้วย
สำเนาอีกโฟลเดอร์บน VPS เดิมยังไม่ใช่สำเนานอกเซิร์ฟเวอร์ หากข้อมูลต้องเข้ารหัสเมื่อจัดเก็บ ให้เตรียมวิธีจัดเก็บที่เหมาะสมแยกต่างหาก
ตรวจและกู้คืนในโฟลเดอร์ว่างใหม่
บน client ตรวจ checksum ก่อนแตกไฟล์ ดำเนินต่อเมื่อได้ OK เท่านั้น ถ้าไม่ตรงให้ตรวจหรือส่งใหม่ ไม่เปลี่ยน checksum เพื่อให้ผ่าน
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"แตกเฉพาะ archive ที่เชื่อถือได้ในโฟลเดอร์ใหม่ keep-old-files ปฏิเสธการแทนไฟล์เดิมและ no-same-owner ไม่คืน owner จาก archive ห้ามเปลี่ยนปลายทางเป็น / หรือใช้ sudo
restore_dir=$(mktemp -d "$recovery_dir/restored.XXXXXX")
tar -xzf "$recovery_dir/static-site.tar.gz" -C "$restore_dir" --keep-old-files --no-same-owner
(
cd "$restore_dir" &&
sha256sum -c SHA256SUMS
)
cat "$restore_dir/site/index.html"ต้องได้ OK สำหรับ site/index.html และ nginx/first-site.conf และเห็น Recovered static page สิ่งนี้ยืนยันเนื้อหาไฟล์ ไม่ยืนยัน owner, ACL, service หรือ dependencies ทั้งหมด
แยกการคืนไฟล์กับการคืนบริการ
config ที่กู้กลับมายังเป็นข้อความที่ไม่ active ก่อนใช้บนเครื่องทดแทนต้องตรวจ path, includes, modules, permissions และ certificate ทดสอบ config Nginx ที่ประกอบจริงบนเครื่องนั้นก่อน reload แล้วตรวจ HTTP/HTTPS จากภายนอก การทดสอบ config บนเครื่องเดิมไม่ยืนยันสำเนาที่กู้คืน
ตัวอย่างไม่เก็บ TLS private keys ต้องวางแผนออกใบรับรองใหม่หรือเก็บสำรองแบบป้องกันแยก อย่าใช้ tar ชุดนี้คัดลอกไฟล์ฐานข้อมูลที่กำลังทำงาน ต้องใช้วิธี consistent backup ของฐานข้อมูล
Snapshot อาจช่วยกู้ทั้งเครื่อง แต่ต้องตรวจการเก็บรักษา ขอบเขตความเสียหาย และวิธีกู้คืน การมี snapshot ไม่ได้ยืนยันว่า export ของเว็บไซต์ใช้สร้างบริการบนโฮสต์อื่นได้
บันทึกเป้าหมายและผลกู้คืน
RPO คือช่วงเวลาข้อมูลที่ยอมเสียได้ ส่วน RTO คือเป้าหมายเวลาคืนบริการ เช่น RPO 24 ชั่วโมงและ RTO 60 นาทีสำหรับเว็บข้อมูลขนาดเล็ก เป็นเป้าหมายสมมติ ไม่ใช่ผลวัดของแบบฝึกนี้ สำรองทุกวันจะตรงแผนก็ต่อเมื่อสำเร็จและยังดึงคืนได้
บนหน้าจอขนาดเล็ก เลื่อนตารางด้านข้างเพื่อดูทุกคอลัมน์
| บันทึก | ใช้ยืนยันอะไร |
|---|---|
| เวลาสำรองและ release | คืนข้อมูลเวอร์ชันใดได้ |
| ปลายทางอิสระและ retention | สำเนาอยู่ที่ไหนและนานเท่าไร |
| ผล checksum ของ archive และไฟล์ | ไบต์ที่เลือกกลับมาครบหรือไม่ |
| เวลาเริ่มและจบการกู้คืน | ใช้เวลากับขั้นตอนที่กำหนดเท่าไร |
| ไฟล์ สิทธิ์ หรือ dependency ที่ขาด | งานก่อนคืนบริการจริง |
| HTTPS ภายนอกบนเครื่องทดแทน | เว็บไซต์กลับมาทำงานหรือไม่ |
วัดกระบวนการทั้งชุด รวมสิทธิ์เข้า การสร้างเครื่อง config, certificates และ DNS การแตกไฟล์เร็วไม่ใช่ benchmark การกู้ outage เก็บจุดกู้คืนหลายชุดและตรวจงานสำรองที่ล้มเหลว ดูเงื่อนไขทรัพยากรและการช่วยกู้คืนก่อนเลือกโฮสต์
คำถามที่พบบ่อย
ต้องลบเว็บเดิมเพื่อพิสูจน์ว่าสำรองได้ไหม?
ไม่ต้อง กู้คืนลงโฟลเดอร์ว่างแยกและตรวจ manifest ได้โดยไม่ทำให้เว็บหยุด ส่วนบริการทั้งชุดให้ทดสอบในสภาพแวดล้อมทดแทน
Checksum ผ่านแปลว่าสำรองทั้งเว็บครบไหม?
ยืนยันเฉพาะไฟล์ที่อยู่ใน manifest ไม่สามารถค้นหา assets ฐานข้อมูล หรือ dependencies ที่ไม่ได้ใส่มาได้