ทุกเครื่องเสมือนในบ้านถูกเก็บทุกคืน ทุกคอนเทนเนอร์ทุกวันโดยไม่ต้องหยุด และทั้งสองสำเนาออกจากตัวอาคาร: ประวัติเครื่องไปยัง Cloudflare R2 โดยกล่องที่อ่านได้อย่างเดียวเป็นผู้ดึง ไฟล์เก็บของคอนเทนเนอร์และคลังรูปภาพไปยัง Dropbox ภายใต้การตรวจหกด่านที่กันไม่ให้วันแย่ ๆ ถูกมิเรอร์ตามไป ไม่มีอะไรนับว่าสำรองแล้วจนกว่าจะอ่านกลับมาเทียบตรงกัน หน้านี้คือทั้งสายโซ่ พร้อมตัวเลข
สามชั้น เรียงตามลำดับที่คุณจะกู้คืน สองชั้นแรกเป็นสำเนา ณ จุดเวลาพร้อมระยะการเก็บ ชั้นที่สามคือการตรวจสอบ เพราะการสำรองที่ไม่เคยอ่านกลับคือแค่ความหวัง
| อะไร | จุดเวลา ในบ้าน | นอกสถานที่ | ตรวจโดย |
|---|---|---|---|
| เครื่องเสมือน มันสมองของสมาร์ทโฮม โฮสต์บริการ เซิร์ฟเวอร์ GPU เกมเซิร์ฟเวอร์ ระบบเฝ้าระวังความปลอดภัย | Proxmox Backup Server บนเซิร์ฟเวอร์เก็บข้อมูล ทุกคืน ลดข้อมูลซ้ำ เก็บห้าชุดล่าสุด และคอนฟิกของไฮเปอร์ไวเซอร์เองเก็บแบบขั้นบันได รายวัน 14 / รายสัปดาห์ 8 / รายเดือน 6 | Cloudflare R2 ดึงทุกเช้าด้วยโทเคนแบบอ่านอย่างเดียว รายวัน 14 รายสัปดาห์ 8 รายเดือน 6 | การตรวจสอบรายสัปดาห์ที่อ่านชังก์กลับจาก R2 และคำนวณแฮชใหม่ |
| เครื่องเสมือนของเครื่อง AI ระบบเสียง บ้านเดโม AI NAS | ที่เก็บข้อมูลของตัวเองบนเซิร์ฟเวอร์สำรองตัวเดียวกัน ทุกคืน | บักเก็ต R2 เดียวกัน ในเนมสเปซของตัวเองเพื่อไม่ให้ชนกัน | การตรวจสอบรายสัปดาห์เดียวกัน |
| คอนเทนเนอร์ 36 ตัวบนเซิร์ฟเวอร์เก็บข้อมูล: สื่อ ดาวน์โหลด มอนิเตอร์ | สแนปช็อต Btrfs ของ appdata ตอน 08:30 ขณะที่ทุกอย่างยังทำงาน ไฟล์เก็บบีบอัดหนึ่งไฟล์ต่อคอนเทนเนอร์ เก็บห้าวัน พร้อมไดรฟ์แฟลชและเทมเพลตคอนเทนเนอร์อยู่ข้างกัน | Dropbox ตอน 11:00 มิเรอร์ชุดที่ลงวันที่ | แมนิเฟสต์ต่อการรัน การแจ้งเตือนเมื่อล้มเหลว และเปิดไฟล์เก็บในโฟลเดอร์ชั่วคราวเพื่อพิสูจน์ว่าแตกไฟล์ได้ |
| คลังรูปภาพ | อาร์เรย์ ภายใต้ parity คู่ | Dropbox ในการมิเรอร์รายวันชุดเดียวกัน | ด่านตรวจหกด่านของการมิเรอร์เอง |
| ตัวเซิร์ฟเวอร์สำรองเอง | ดิสก์ระบบของมันถูกทำอิมเมจทุกวันตอน 06:00 ด้วยปลั๊กอิน Unraid VM Backup เก็บสองชุด ไว้ในแชร์ backups เดียวกัน | Dropbox พร้อมกับส่วนที่เหลือของแชร์นั้น | — ข้อมูลที่มันปกป้องอยู่ใน R2 แล้ว อิมเมจแค่ช่วยไม่ต้องติดตั้งใหม่ |
ทุกอย่างบนไฮเปอร์ไวเซอร์ของบ้าน รวมถึง Home Assistant เป็นเครื่องเสมือน มันสมองของสมาร์ทโฮมจึงกู้คืนได้ทั้งเครื่องจากสแนปช็อตรายคืนชุดใดก็ได้
ไฮเปอร์ไวเซอร์ทั้งสองเครื่องสำรองเครื่องเสมือนไปยัง Proxmox Backup Server ที่รันเป็น VM บนเซิร์ฟเวอร์เก็บข้อมูล โดยมีที่เก็บข้อมูลอยู่บนอาร์เรย์ การลดข้อมูลซ้ำคือสิ่งที่ทำให้สแนปช็อตเต็มทุกคืนเป็นไปได้: ที่เก็บของโฮสต์บ้านใช้ดิสก์ 671 GiB ด้วยอัตราลดซ้ำ 9.6 ส่วนของเครื่อง AI ใช้ 197 GiB ที่ 16× กฎการเก็บในบ้านเรียบง่าย — ห้าสแนปช็อตล่าสุดต่อเครื่อง — เพราะประวัติยาวอยู่นอกสถานที่ ซึ่งปลอดภัยกว่า
ข้อเท็จจริงด้านการดูแลสองข้อที่ควรรู้ ถ้าคุณรันระบบแบบนี้ งาน prune ที่ไม่จำกัดความลึกจะไล่ลงไปทุกเนมสเปซข้างใต้ “เก็บห้าชุดล่าสุด” ที่ระดับรูทจึงแบนขั้นบันไดที่ยาวกว่าซึ่งเก็บในเนมสเปซย่อยไปอย่างเงียบ ๆ งาน prune แต่ละงานที่นี่จึงถูกตรึงความลึกของตัวเอง และเครื่องที่หยุดส่งข้อมูลสำรองจะเก็บ N สแนปช็อตสุดท้ายไว้ตลอดไป เพราะ prune นับเฉพาะสิ่งที่เข้ามา: เครื่องที่ปลดระวางต้องลบด้วยมือ และพื้นที่จะคืนมาใน garbage collection ครั้งที่สอง หลังช่วงผ่อนผัน 24 ชั่วโมง
คอนเทนเนอร์ 36 ตัวบนเซิร์ฟเวอร์เก็บข้อมูลสำรองจากสแนปช็อต Btrfs ของพูล appdata: ทุกคอนเทนเนอร์ถูกพักชั่วขณะที่สแนปช็อตบันทึก — การหยุดนิ่งแบบเดียวกับที่ Proxmox ใช้กับคอนเทนเนอร์ในโหมดสแนปช็อต — แล้วจึงทำงานต่อ และไฟล์เก็บถูกเขียนจากต้นไม้ที่หยุดนิ่ง ขณะที่ตัวจริงทำงานต่อไป หนึ่งไฟล์ .tar.zst ต่อคอนเทนเนอร์ ราว 130 GiB ต่อวัน เก็บห้าวัน กู้คืนได้จากหน้าเว็บ วิธีทั้งหมด พร้อมสคริปต์และค่าตั้งปลั๊กอินที่แน่นอน อยู่ในคู่มือสแนปช็อต appdata
เซิร์ฟเวอร์สำรองที่ถือข้อมูลไม่มีข้อมูลรับรองคลาวด์เลย Proxmox Backup Server ตัวที่สอง เป็น VM ขนาดเล็กบนเครื่อง AI ที่มีดิสก์แคช 128 GB ถือโทเคนแบบอ่านอย่างเดียวของตัวแรก และดึงทุกเช้าตอน 07:30 เข้าที่เก็บข้อมูลแบบ S3 ใน R2 ใครที่เจาะเซิร์ฟเวอร์เก็บข้อมูลได้จะไม่พบอะไรที่เอื้อมถึงสำเนานอกสถานที่ การลบก็ไม่ถูกส่งต่อ: งานซิงค์ตั้งไว้ไม่ให้ลบสิ่งที่หายไปจากต้นทาง ระยะการเก็บนอกสถานที่จึงเป็นของงาน prune ของมันเองทั้งหมด — รายวัน 14 รายสัปดาห์ 8 รายเดือน 6 คือ 28 สแนปช็อตต่อเครื่อง เทียบกับ 5 ในบ้าน ช่องว่างนั้นตั้งใจ: มันคือระยะเวลาที่ผู้บุกรุกเงียบ ๆ ต้องรอให้ผ่านไป
ผู้ให้บริการถูกวัดผล ไม่ใช่สันนิษฐาน เวลาไป-กลับจากกรุงเทพฯ ถึงผู้สมัคร: ที่เก็บอ็อบเจกต์ในสิงคโปร์ 55 ms สองรายในยุโรปราว 190 ms ภูมิภาคในสหรัฐฯ 240–270 ms R2 อยู่หลัง anycast เวลาไป-กลับของมันจึงไม่บอกอะไร การโอนจริงขนาด 2 GiB วัดได้ 24 MiB/s ขาขึ้นที่ค่าเริ่มต้น และ 57 MiB/s เมื่อเพิ่มการอัปโหลดพร้อมกันเป็น 32 ขาลง 50 MiB/s ตัวเลือกสิงคโปร์แพ้แม้ latency ดีกว่า: การเก็บขั้นต่ำ 90 วันขัดกับการเปลี่ยนชังก์ตลอดเวลาของเซิร์ฟเวอร์สำรอง และค่าส่งออกถูกจำกัดตามปริมาณที่เก็บ — ซึ่งลงโทษการตรวจสอบ งานที่สำคัญที่สุด R2 ถูกเลือกเพราะค่าส่งออกเป็นศูนย์ การอ่านทุกไบต์กลับบ่อยเท่าไรก็ได้จึงฟรี กับผู้ให้บริการที่คิดค่าส่งออก มีกรณีเซิร์ฟเวอร์สำรองที่บันทึกไว้ว่าทราฟฟิกการตรวจสอบอย่างเดียวทำให้บิลรายเดือนเพิ่มขึ้นหลายเท่า
สิ่งที่การตรวจสอบเต็มครั้งแรกสอน ความพยายามแรกในการอ่าน 868 GiB กลับผ่านการเชื่อมต่อเดียว เผยให้เห็นการอ่านที่หลุดไม่กี่ครั้งบนดิสก์ที่ใหญ่ที่สุดสี่ลูก — ไม่มีแฮชไม่ตรงเลย มีแค่ข้อผิดพลาดการเชื่อมต่อชั่วคราวที่อ่านซ้ำก็หาย จำนวนตัวอ่านถูกลดจากแปดเหลือสี่ และรอบฐานที่ตามมากลับมาสะอาด 100 %: ทุกชังก์อ่านจาก R2 ทุกแฮชตรงกัน จากนี้งานรายสัปดาห์จะอ่านซ้ำเฉพาะสิ่งที่ใหม่ ส่วนที่เก่ากว่า 30 วันจะถูกตรวจซ้ำในรอบของมันเอง
แชร์ backups — ชุดคอนเทนเนอร์ที่ลงวันที่ อิมเมจดิสก์ของเซิร์ฟเวอร์สำรองเอง อิมเมจไดรฟ์แฟลช และสแนปช็อตฐานข้อมูลของแคตตาล็อกหนังสือ — และคลังรูปภาพ ถูกมิเรอร์ไปยัง Dropbox ด้วย rclone จากเซิร์ฟเวอร์ GPU ซึ่งรันงานตามกำหนดเวลาของบ้าน แชร์คือต้นฉบับ และ Dropbox ตามมัน รวมถึงการลบด้วย สิ่งที่ทำให้ปลอดภัยคือแชร์เก็บห้าชุด ณ จุดเวลา ไม่ใช่โฟลเดอร์สด มิเรอร์จะมิเรอร์การลบด้วย ไฟล์เก็บที่ลงวันที่และไม่เปลี่ยนแปลงจึงเป็นชั้นที่คุณกู้คืน และมิเรอร์คือสำเนาของมันที่อยู่ที่อื่น
| เวลา | หน้าที่ | ที่ไหน |
|---|---|---|
| ช่วงกลางคืน | ทุกเครื่องเสมือนบนไฮเปอร์ไวเซอร์ทั้งสองไปยังเซิร์ฟเวอร์สำรอง คอนฟิกของไฮเปอร์ไวเซอร์เองตอน 03:00 ตามขั้นบันไดยาว prune ในบ้านตอนเที่ยงคืน | เซิร์ฟเวอร์เก็บข้อมูล |
| 06:00 | ดิสก์ระบบของเซิร์ฟเวอร์สำรองถูกทำอิมเมจ เก็บสองชุด | เซิร์ฟเวอร์เก็บข้อมูล |
| 07:30 | ที่เก็บข้อมูลทั้งสองถูกดึงไปยัง R2 | เครื่อง AI → R2 |
| 08:30 | คอนเทนเนอร์ถูกพัก ถ่ายสแนปช็อต แล้วทำงานต่อ ไฟล์เก็บหนึ่งไฟล์ต่อคอนเทนเนอร์เขียนจนถึงราว 10:25 | เซิร์ฟเวอร์เก็บข้อมูล |
| 09:00 / 10:00 | prune นอกสถานที่ แล้วจึง garbage collection นอกสถานที่ | R2 |
| 11:00 | แชร์ backups และคลังรูปภาพมิเรอร์ไปยัง Dropbox ราวสองชั่วโมง | เซิร์ฟเวอร์ GPU → Dropbox |
| วันเสาร์ 11:00 | การตรวจสอบอ่านชังก์ใหม่ของสัปดาห์กลับจาก R2 และคำนวณแฮชใหม่ | R2 |
ลำดับคือหัวใจ: ไม่มีอะไรอ่านโฟลเดอร์ที่งานอื่นยังเขียนอยู่ และ prune นอกสถานที่รันหลังการซิงค์ส่งสแนปช็อตของวันมาถึงแล้ว ไม่เคยรันก่อน