- ความสำคัญของ การสำรองข้อมูล มักถูกประเมินต่ำกว่าความเป็นจริงอยู่บ่อยครั้ง
- หลายคนพอใจกับการ พึ่งพาคลาวด์ โดยไม่ตระหนักว่าความรับผิดชอบในการปกป้องข้อมูลยังเป็นของตนเอง
- หากไม่มี แผนสำรองข้อมูล และอาศัยเพียงการคัดลอกธรรมดา ก็จะก่อให้เกิดความเสี่ยงสูง
- การสำรองแบบทั้งดิสก์หรือแบบ แยกไฟล์รายไฟล์ ต่างก็มีข้อดีข้อเสียของตัวเอง
- การสำรองข้อมูลที่เชื่อถือได้มีองค์ประกอบสำคัญคือการใช้ สแนปช็อต และการมี พื้นที่จัดเก็บภายนอก
ความสำคัญของการสำรองข้อมูลและความเป็นจริง
- การสำรองข้อมูล เป็นเรื่องที่หลายคนไม่ได้มองอย่างจริงจัง
- ข้อมูลจำนวนมากสูญหายเพราะวิธีการที่ผิดหรือความเข้าใจเชิงแนวคิดที่คลาดเคลื่อน (เช่น RAID ไม่ใช่การสำรองข้อมูล)
- ข้อมูลคือทรัพย์สินสำคัญที่ต้อง เก็บรักษา ไว้ด้วยหลายวิธี
ความเข้าใจผิดเกี่ยวกับคลาวด์และการสำรองข้อมูล
- หลายคนฝากข้อมูลทั้งหมดไว้กับ คลาวด์ โดยไม่เคยถามจริง ๆ ว่าข้อมูลได้รับการปกป้องอย่างไร
- ผู้ให้บริการคลาวด์รายใหญ่ก็ใช้ โมเดลความรับผิดชอบร่วมกัน
- ผู้ให้บริการดูแลความปลอดภัยของโครงสร้างพื้นฐาน แต่ความรับผิดชอบในการปกป้องข้อมูลเป็นของผู้ใช้
- แม้ในสภาพแวดล้อมอย่างคลาวด์ เซิร์ฟเวอร์ส่วนตัว หรือ Kubernetes ก็ยังพบความเสี่ยงจาก การไม่มีระบบสำรองข้อมูล อยู่บ่อยครั้ง
ประสบการณ์ของผู้เขียนในการกู้คืนข้อมูล
- เคยเผชิญกับกรณีข้อมูลสูญหายหลายรูปแบบ เช่น ไฟไหม้ดาต้าเซ็นเตอร์ ห้องเซิร์ฟเวอร์น้ำท่วม แผ่นดินไหว แรนซัมแวร์ การโจมตีโดยเจตนาร้าย และความผิดพลาดของผู้ดูแลระบบ
- สำหรับเซิร์ฟเวอร์ที่เชื่อมต่ออินเทอร์เน็ตอยู่ตลอด (เช่น อีคอมเมิร์ซ เมล ฯลฯ) ทั้ง ความสมบูรณ์ของข้อมูล และ ความต่อเนื่องของบริการ ล้วนสำคัญ
- การสำรองข้อมูลไม่ใช่แค่การคัดลอกธรรมดา โดยเฉพาะการคัดลอกไฟล์ฐานข้อมูลที่กำลังทำงานอยู่ ซึ่งอาจทำให้กู้คืนไม่ได้
คำถามสำคัญในการวางกลยุทธ์สำรองข้อมูล
- "ยอมรับความเสี่ยงได้มากแค่ไหน?", "ต้องปกป้องข้อมูลอะไรบ้าง?", "ถ้าข้อมูลสูญหาย ยอมให้ระบบหยุดทำงานได้นานเท่าไร?", "มีพื้นที่จัดเก็บให้ใช้เท่าไร?"
- การเก็บชุดสำรองไว้บนเครื่องเดียวกันจะไร้ประโยชน์หากเครื่องเสียหาย ดังนั้นการสำรองไปยัง พื้นที่จัดเก็บภายนอก จึงปลอดภัยกว่า
- ปัจจัยเชิงปฏิบัติ เช่น แบนด์วิดท์เครือข่าย ความเร็วในการกู้คืน และพื้นที่จัดเก็บ ก็ต้องนำมาพิจารณาด้วย
สำรองทั้งดิสก์ vs สำรองรายไฟล์
การสำรองทั้งดิสก์
- ข้อดี
- สามารถ กู้คืนได้ครบถ้วน และคืนระบบกลับสู่สถานะเดิมได้อย่างรวดเร็ว
- มีประโยชน์เมื่อใช้ร่วมกับระบบ virtualization โดย Proxmox เป็นต้น รองรับการสำรองแบบนี้ได้สะดวก
- บางโซลูชันรองรับการ กู้คืนไฟล์รายไฟล์ จากชุดสำรองทั้งดิสก์ด้วย
- ข้อเสีย
- ในกรณีเซิร์ฟเวอร์จริงอาจต้องมี downtime
- ใช้พื้นที่มาก และเก็บข้อมูลที่ไม่จำเป็นไปด้วย
- อาจช้าหรือมีปัญหาด้านความเข้ากันได้ตามคุณสมบัติของไฟล์ซิสเต็ม
การสำรองรายไฟล์
- ข้อดี
- ทำได้ด้วยยูทิลิตีพื้นฐานของระบบ (
tar, cp, rsync เป็นต้น)
- สามารถ สำรองเฉพาะส่วนที่เปลี่ยนแปลง เพื่อลดการใช้พื้นที่และปริมาณการส่งข้อมูล
- ยืดหยุ่นต่อการกู้คืนรายไฟล์ การย้ายข้อมูล การบีบอัด และการกำจัดข้อมูลซ้ำซ้อน
- ดำเนินงานได้โดยไม่ต้องหยุดระบบ
- ข้อเสีย
- การคัดลอกแบบธรรมดาต้องใช้พื้นที่จัดเก็บมาก
- หากสำรองไฟล์ซิสเต็มที่กำลังทำงานโดยไม่มี สแนปช็อต อาจเกิด ความไม่สอดคล้องและข้อผิดพลาด ได้
การใช้สแนปช็อตในการสำรองข้อมูล
- เมื่อเป้าหมายของการสำรองเป็นไฟล์ซิสเต็มที่กำลังทำงานอยู่ ข้อมูลอาจเปลี่ยนแปลงระหว่างจุด "เริ่ม" และ "สิ้นสุด" ของการสำรอง ทำให้ ความสอดคล้องของข้อมูล เสียหาย
- ฐานข้อมูลที่เปิดใช้งานอยู่ เช่น MySQL หรือประวัติของเบราว์เซอร์ อาจกู้คืนไม่ได้หากใช้เพียงการคัดลอกไฟล์
- หากต้องการรับประกันการสำรองที่สอดคล้องกัน ควรใช้ความสามารถ สแนปช็อต ของไฟล์ซิสเต็มก่อน
- วิธีที่ใช้กันทั่วไป
- สแนปช็อตของไฟล์ซิสเต็มแบบเนทีฟ (ระบบที่รองรับ BTRFS, ZFS)
- LVM snapshot: อาจสิ้นเปลืองพื้นที่ และมีโอกาสทำให้ระบบหยุดชะงักตอนลบสแนปช็อต
- DattoBD: บางครั้งมีประเด็นด้านความเสถียร แต่สามารถนำไปใช้ร่วมกับ UrBackup เป็นต้นได้
วิธีการสำรองข้อมูล: Push vs Pull
- Push: เครื่องต้นทางของข้อมูลเชื่อมต่อไปยังเซิร์ฟเวอร์เพื่อส่งข้อมูลสำรอง
- Pull: เซิร์ฟเวอร์สำรองส่วนกลางเชื่อมต่อเข้าไปยังแต่ละเซิร์ฟเวอร์เพื่อทำการสำรอง
- ในมุมความปลอดภัย วิธีแบบ Pull ปลอดภัยกว่า เพราะสามารถปิดกั้นการเข้าถึงจากภายนอกมายังเซิร์ฟเวอร์สำรอง และให้เข้าถึงไคลเอนต์เฉพาะเวลาที่จำเป็น
- เพื่อป้องกันการลบข้อมูลสำรองในกรณีถูกเจาะระบบหรือเกิดแรนซัมแวร์ ควรเก็บ สแนปช็อต ของตัวเซิร์ฟเวอร์สำรองเองแยกไว้ในระยะยาวด้วย
คุณสมบัติหลักของระบบสำรองข้อมูลที่แนะนำ
- กู้คืนได้ทันทีและประมวลผลได้รวดเร็ว
- เก็บไว้ใน พื้นที่จัดเก็บภายนอก (แต่ยังคงมี local snapshot ไว้สำหรับ rollback ทันที)
- แนะนำให้หลีกเลี่ยง คลาวด์เชิงพาณิชย์ อย่าง Google Drive, Dropbox เป็นต้น ควรถือครองข้อมูลด้วยตนเอง
- มีการ บีบอัดและกำจัดข้อมูลซ้ำซ้อน เพื่อบริหารพื้นที่อย่างมีประสิทธิภาพ
- ควรมีองค์ประกอบเพิ่มเติมที่จำเป็นต่อการทำงานให้น้อยที่สุด
แผนการเขียนตอนต่อไป
- จะนำเสนอทั้งสถานการณ์การสำรองข้อมูลหลากหลายรูปแบบ เซิร์ฟเวอร์ที่ใช้งานจริง การตั้งค่าหลัก รวมถึงซอฟต์แวร์และเทคนิคต่าง ๆ
- ตอนถัดไปจะกล่าวถึงวิธีสร้างเซิร์ฟเวอร์สำรองข้อมูลบนพื้นฐาน FreeBSD
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เครื่องที่จำเป็นต้องทำแบ็กอัปแบบ “push” ควรถูกจำกัดให้เข้าถึงได้แค่พื้นที่ของตัวเองเท่านั้น และที่สำคัญกว่านั้นคือเซิร์ฟเวอร์แบ็กอัปควรเก็บ filesystem snapshot ของตัวเองไว้ช่วงระยะเวลาหนึ่งเพื่อความปลอดภัย แบบนี้แม้ในสถานการณ์เลวร้ายที่สุดที่ workload ถูกทำลายและมีการเข้าถึงเซิร์ฟเวอร์แบ็กอัปเพื่อลบแบ็กอัปไปเรียกค่าไถ่ ก็ยังมี snapshot เหลืออยู่บนเซิร์ฟเวอร์ วิธีที่ฉันชอบคือให้ไคลเอนต์เขียนได้เฉพาะแบ็กอัปใหม่และห้ามลบโดยสิ้นเชิง ส่วนการลบให้ทำผ่านขั้นตอนแยกต่างหาก (เช่น manual หรือ cron) วิธีนี้ทำได้บน rsync/ssh ด้วยฟีเจอร์ allowed command ใน
.ssh/authorized_keysฉันใช้ทั้งสองแบบ แต่ยังไงก็ต้องเก็บแบ็กอัปไว้สองที่อยู่แล้ว และเดิมทีฉันก็ต้องการโครงสร้างแบ็กอัปคู่แบบนี้ แหล่งข้อมูลที่ต้องแบ็กอัปจะ push ไปยังตำแหน่งกลาง แล้วคลังแบ็กอัปหลักค่อย pull จากที่นั่น ตำแหน่งกลางมีพื้นที่น้อยจึงเก็บ snapshot ได้จำกัด แต่สตอเรจหลักกับต้นทางนั้นยืนยันตัวตนหากันไม่ได้เลย ต่างฝ่ายต่างยืนยันตัวตนได้เฉพาะกับตำแหน่งกลาง และไม่มีการยืนยันตัวตนย้อนกลับด้วย ดังนั้นต่อให้ใน 3 จุดนี้ถูกแฮ็กไป 1 หรือ 2 จุด ที่เหลือก็มักยังปลอดภัย แบ็กอัปใบรับรองถูกแยกจัดการต่างหากโดยสมบูรณ์ เพื่อไม่ให้ไปอยู่บนเซิร์ฟเวอร์ที่ต่ออินเทอร์เน็ตทั้งหมด ข้อมูลที่สำคัญจริง ๆ ก็เพิ่มชั้นด้วยแบ็กอัปออฟไลน์อีกที การแยกโครงสร้างแบบนี้ทำให้การตรวจสอบแบ็กอัปจริงยุ่งยากขึ้น แต่สตอเรจแบ็กอัปจะตรวจสอบ checksum เป็นระยะและส่งผลไปยังโฮสต์กลาง เพื่อนำไปเทียบกับ hash ที่สร้างจากโฮสต์ต้นทางและจับเหตุการณ์ข้อมูลเสียหาย ผลที่ได้คือแบ็กอัปแบบ “soft offline” ชนิดหนึ่งที่ต้นทางไม่สามารถทำลาย snapshot ของแบ็กอัปได้โดยตรง
อีกวิธีคือใช้คอนเทนเนอร์แยกหรือผู้ใช้เฉพาะสำหรับงานแบ็กอัป เช่น systemd-nspawn ซึ่งใช้ได้เหมือน chroot jail แบบเบา ๆ และสามารถบล็อกไม่ให้รัน
rmข้างในได้เลย คุณสามารถสร้าง chroot ได้ง่าย ๆ ด้วยpacman/pacstrapแล้วจัดการด้วยsystemd-nspawn/machinectlวิธีนี้ให้การควบคุมที่ยืดหยุ่นมาก ไม่ต่างจาก systemd ปกติ ทั้งการควบคุมการเข้าถึง การจำกัด path ของไฟล์ การจำกัดหน่วยความจำ/CPU การอนุญาตเฉพาะบางช่วง IP ไปจนถึงเงื่อนไขการบูตที่ละเอียดขึ้น ใช้ BTRFS subvolume ได้ด้วย และถ้าจำเป็นก็แยกระบบทั้งก้อนได้เลยด้วยsystemd-vmspawnการทำสำเนาอัตโนมัติด้วยimportctlก็สะดวกมากฉันชอบแบบ pull ที่ “เซิร์ฟเวอร์แบ็กอัปไม่มีสิทธิ์ใด ๆ เหนือเซิร์ฟเวอร์ต้นทางเลย” เพราะถึงเซิร์ฟเวอร์จริงจะถูกแฮ็กจนได้สิทธิ์ root ก็ไม่กระทบระบบแบ็กอัป
ฉันใช้
rclone copyสำหรับแบ็กอัป และใช้แค่ API key ที่ไม่มีสิทธิ์ลบ object ถ้าใช้แบบซิงก์อย่างrclone syncมันอาจลบข้อมูลตามไปด้วย วิธีนี้เลยปลอดภัยกว่าอยากให้ syncoid มีตัวเลือกแบบ “ไคลเอนต์คัดลอกเฉพาะ snapshot/แบ็กอัป และให้เซิร์ฟเวอร์แบ็กอัปจัดการการลบเอง” ตอนนี้ยังต้องให้สิทธิ์ลบอยู่ เลยเสียดาย
มีคนจำนวนมากอย่างน่าตกใจที่ไม่ให้ความสำคัญกับแบ็กอัป ทั้งบริษัทเล็กและใหญ่เหมือนกันหมด บริษัทที่ฉันไปคอนซัลต์ให้ซึ่งมีรายได้ปีละ 1 พันล้านยูโร ก็ไม่มีแบ็กอัปของตัวเองเลย พึ่งพาแค่การคัดลอกดิสก์แบบไม่สม่ำเสมอจากผู้ให้บริการดาต้าเซ็นเตอร์ และไม่เคยทดสอบการกู้คืนด้วยตัวเอง ไม่นานมานี้ฐานข้อมูล production ถูกลบจนหมดจากความผิดพลาดของผู้ใช้ และแบ็กอัปล่าสุดก็เป็นของเมื่อ 4 วันก่อน ทำให้ต้องไล่สร้างธุรกรรมทั้งหมดในช่วงนั้นขึ้นมาใหม่ แต่ถึงจะเกิดเหตุแบบนี้ก็ไม่มีใครตกใจ ทุกอย่างก็ผ่านไปเหมือนไม่มีอะไรเกิดขึ้น
ดูเหมือนว่าถ้ามันไม่ถึงขั้นทำลายธุรกิจจริง ๆ พวกเขาก็คิดว่าไม่เป็นไร
อีกเรื่องที่เห็นบ่อยคือการทำให้ข้อกำหนดด้านแบ็กอัปซับซ้อนเกินความจำเป็น
อาจเป็นเรื่องกฎหมายก็ได้ เพราะการมีแบ็กอัปเองอาจกลายเป็นความเสี่ยงจากคดีความหรือภาระการเก็บรักษาข้อมูลตามกฎหมาย
นี่เป็นผลข้างเคียงของนโยบายกู้คืนความเสียหายที่ผ่านการตรวจ soc2 บริษัทที่ฉันเคยทำงานก็ตรวจนโยบายกู้คืนความเสียหายของทุกทีม (ทั้งหมดผ่าน soc2) แล้วสุดท้ายก็สรุปว่า ถ้าเกิดเหตุใหญ่จริง การปิดบริษัทแล้วกลับบ้านน่าจะเร็วกว่าการกู้คืนตามปกติ
ถ้าเรื่องการสูญเสียข้อมูล 4 วันของฐานข้อมูล production ทั้งหมดเป็นเรื่องจริง ฉันก็สงสัยว่าลูกค้าไม่โกรธกันหรือ บริษัทระดับนั้นน่าจะเสียหายหนักมาก เลยอยากรู้ว่าจัดการกันยังไงจริง ๆ
ขอบคุณที่แชร์เนื้อหา ฉันพัฒนาซอฟต์แวร์แบ็กอัปและ disaster recovery มา 10 ปี และมีประโยคที่พูดกันเสมอว่า “อย่าแนะนำให้เพื่อนสร้างโซลูชันแบ็กอัป/DR ใช้เอง” เพราะการทำ BCDR มีหลุมพรางที่พลาดได้ง่ายเต็มไปหมด เลยอยากแชร์ประเด็นสำคัญสักหน่อย: แบ็กอัปไม่ใช่ “disaster recovery” ถ้าเกิดเหตุจริง คุณต้องกู้กลับมาได้ภายในไม่กี่นาทีถึงไม่กี่ชั่วโมงจึงจะรักษาความเชื่อมั่นทางธุรกิจไว้ได้ สิ่งสำคัญคือ RTO และ RPO การทำสำเนาไฟล์ด้วย
rsync copyอย่างเดียวไม่ใช่ point-in-time backup เพราะ filesystem เปลี่ยนแปลงอยู่ตลอด แบ็กอัปแบบ point-in-time ที่ถูกต้องต้องเป็นแบบ “crash-consistent” หรือ “application-consistent” โดยแบบหลังหมายถึงให้แอปสำคัญ flush state ลงดิสก์และหยุดไว้ระหว่างแบ็กอัป ฟีเจอร์อย่าง Microsoft VSS ก็มีไว้ทำเรื่องนี้ คุณไม่ควรไว้ใจrsync copyหรือแม้แต่แบ็กอัปแบบ crash-consistent แบบสุดตัว เพราะกับสตอเรจนั้น Murphy's law ใช้ได้เสมอ จึงจำเป็นต้องมีแบ็กอัปหลายสถานที่ (กลยุทธ์ 3-2-1) จากประสบการณ์ตรง ดิสก์ทุกชนิดพังได้หมด แม้ NVMe SSD > SSD > HDD จะทนกว่าตามลำดับ แต่ก็ไม่มีข้อยกเว้น อยากเขียนต่ออีกมากแต่ดึกแล้ว ขอหยุดไว้แค่นี้อุปมา 3-2-1 เป็นแนวคิดยุคก่อน ปัจจุบันที่เก็บข้อมูลแทบไม่จำกัดแล้ว snapshot ในเครื่อง การทำสำเนาระยะไกล และแบ็กอัปสองหรือสามชั้นด้วยวิธีที่ต่างกันสำคัญกว่า ฉันใช้ zfs snapshot เป็นพื้นฐาน และเพิ่ม Borg อีกชั้น ซึ่งชุดนี้ก็เพียงพอแทบทุกเหตุการณ์แล้ว
ประโยคนั้นทำให้ฉันนึกถึงคำพูดคล้ายกันที่เคยได้ยินในคอนเสิร์ต Alice in Chains โซลูชัน BCDR เป็นสัญลักษณ์ของความเชื่อใจระหว่างธุรกิจ ระบบแบบนี้ปกป้องข้อมูลระดับหลายสิบถึงหลายร้อยล้านล้าน และถ้าคุณเป็น CTO ก็คงไม่เอาแบ็กอัปบริษัทไปฝากกับแนวทางโอเพนซอร์สแน่ ๆ งบ IT ขององค์กรโดยมากจะค่อย ๆ เพิ่มขึ้นตามมูลค่าสินทรัพย์และกลยุทธ์ต้าน vendor lock-in จากประสบการณ์ของผู้เชี่ยวชาญ ความไม่เปลี่ยนแปลงของข้อมูล (immutability) และแบ็กอัปแบบ WORM คือหัวใจในการป้องกันแรนซัมแวร์ และฉันก็เคยเจอหลายกรณีในงาน IT ภาครัฐที่มีปัญหาเพราะไม่ปฏิบัติตามข้อกำหนด แม้ผู้ให้บริการ BCDR จะใช้แรนซัมแวร์เป็นจุดขาย แต่ความไม่เปลี่ยนแปลงที่แท้จริงจะพิสูจน์ได้จากการทำสำเนาข้อมูลข้ามหลายสถานที่ ซึ่งตรงนี้เองที่กลยุทธ์ 3-2-1 แสดงคุณค่า อยากฟังความคิดเห็นเกี่ยวกับหลักการแบ็กอัปเพิ่มเติม
ถ้าใช้ NAS ก็ควรหลีกเลี่ยงการใช้ฮาร์ดดิสก์ยี่ห้อและรุ่นเดียวกันทั้งสองฝั่ง
เห็นด้วยเต็มที่กับคำว่า “ต้องมีแบ็กอัปหลายสถานที่ (3-2-1)” แต่สำหรับคนส่วนใหญ่ “1” (offsite) แทบเป็นไปไม่ได้ในทางปฏิบัติ สุดท้ายถ้าไม่ใช้บริการแบ็กอัป ก็แทบไม่มีเหตุผลจะทำเอง เพราะฉันไม่มีใครนอกเมืองที่จะเปิดคอมพิวเตอร์ 24 ชั่วโมงและคอยดูแลให้ได้
ส่วนที่บอกว่า “ห้ามเชื่อใจ
rsync copyหรือแม้แต่แบ็กอัปแบบ crash-consistent” ทำให้สรุปได้ว่า ในเมื่อทุกระบบ/บริการสร้างใหม่ได้จากเครื่องมือโครงสร้างพื้นฐาน ก็แค่ต้องแบ็กอัปฐานข้อมูลกับที่เก็บไฟล์/ออบเจ็กต์อย่างจริงจัง ส่วนการแบ็กอัป VM ทั้งก้อนให้ซับซ้อนนั้นแทบไม่มีประโยชน์จริงเป็นบทความที่เขียนได้เรียบร้อย แต่มีจุดที่น่าเสียดายคือ ระบบแบ็กอัปที่ดีจริงต้องมีความชัดเจนเรื่องความเร็วและขั้นตอนการกู้คืน ฉันเจอมาหลายครั้งว่าคนมั่นใจว่าแบ็กอัปทำงานดี แต่พอถึงเวลาต้องกู้กลับจริง กลับกู้ได้แค่บางส่วนหรือใช้เวลาหลายวันจนเสียหายหนัก เครื่องมือชื่อ restic มีประโยชน์มากเพราะทำแบ็กอัปแบบ snapshot พร้อม dedup ระดับไฟล์ได้ เหมาะเมื่อไม่มี snapshot filesystem อย่าง ZFS และถ้าเป็นแบ็กอัปแบบ “push” แรนซัมแวร์อาจลบแบ็กอัปได้ด้วย ดังนั้นแบบ “pull” จึงเหมาะกว่า ถ้าจำเป็นต้อง push อย่างน้อยก็ควรใช้สื่ออ่านอย่างเดียว (เช่น Bluray) หรืออย่างน้อยต้องมี auto-snapshot/ZFS เพื่อย้อนกลับตามเวลาได้
ต่อให้แรนซัมแวร์ลบ push backup ได้ แต่ถ้าจำกัดสิทธิ์ของเซิร์ฟเวอร์ดีพอก็ไม่มีปัญหา Borg และ Restic รับประกัน append-only ผ่าน ssh ได้ และฝั่งโลคัลก็หมุนเวียนไดรฟ์แบ็กอัปออฟไลน์เป็นแนวป้องกันชั้นสุดท้าย วิธีทำจริงดูได้ที่นี่
สงสัยว่าใน append-only mode ของ restic ถ้าให้ pruning เป็นงานที่รันเป็นระยะจากฝั่งเซิร์ฟเวอร์เท่านั้น แบบนี้จะโอเคโดยไม่ต้องใช้ pull ไหม เท่าที่รู้ นี่คือวิธีป้องกันแรนซัมแวร์ที่ restic แนะนำอย่างเป็นทางการ
“ความเร็วในการกู้คืน” ขึ้นกับความต้องการจริงมาก สำหรับฉัน ถ้ากู้รูปครอบครัวใช้เวลา 6 เดือนก็ยังโอเค
แทนที่จะใช้สื่ออ่านอย่างเดียว จะใช้เซิร์ฟเวอร์ push ที่จำกัดสิทธิ์ก็ได้ เช่น อนุญาต ssh ให้ใช้ได้เฉพาะ
scp, จำกัดอยู่ในchrootและแบ็กอัปแบบหมุนโฟลเดอร์รายวัน แบบนี้ถึงเป็นแรนซัมแวร์ก็ลบข้อมูลเก่าไม่ได้ ขั้นตอนแบ็กอัปของฉันก็จัดการผ่านเซิร์ฟเวอร์ ssh ที่อนุญาตแค่ chroot+scp และยังใช้สื่ออ่านอย่างเดียวควบคู่ไปด้วยฉันไม่ได้ต้องการระบบแบ็กอัปแยกต่างหาก แค่อยากได้วิธีมาตรฐานที่มีประสิทธิภาพในการรวมรูปถ่ายตลอด 25 ปีของคนในครอบครัว 4 คน (จากโทรศัพท์ กล้อง ไฟล์ดาวน์โหลด สแกน ฯลฯ) ไว้ด้วยกัน แต่จนถึงตอนนี้ยังไม่เจอวิธีที่ถูกใจ
ฉันรัน Immich บน NAS และแบ็กอัปทั้งสื่อกับ Immich DB dump ไปยัง AWS S3 Deep Archive ทุกวัน Immich ให้ฟีเจอร์ได้มากพอ ๆ กับ Google Photos และถ้าเพิ่มรูปหรือไฟล์สแกนจากเดสก์ท็อปเข้า NAS ไว้ Immich ก็จะดึงเข้าไปอัตโนมัติ ถ้าเป็นผู้ใช้ HN การตั้งค่าไม่น่ายาก
มีคนแซวว่า “รูปถ่าย 25 ปี” เป็นหน่วยข้อมูลแบบอเมริกาเหนือหรือเปล่า แล้วชี้ว่าจริง ๆ แล้วคุณจำเป็นต้องมีระบบแบ็กอัปแน่นอน ฉันใช้ syncthing เป็น mesh บน gnu/linux/windows/android แล้วทำ snapshot archive เป็นระยะลง Debian VM สองตัว จากนั้นแบ็กอัปชั้นสองด้วย borgbackup RPO คือ 24 ชั่วโมง แต่ถ้าต้องการก็ลดได้อีก ข้อเสียคืออุปกรณ์ Apple ไม่เหมาะกับชุดนี้เพราะ syncthing ถูกรันเบื้องหลังไม่ได้ ในกรณีของฉัน รูปมี 500GB และเอกสารอื่น ๆ อีกหลายสิบถึงหลายร้อย GB แต่แบ็กอัปแบบ diff ทำให้ยังมีประสิทธิภาพ
ไฟล์ดาวน์โหลดกับไฟล์สแกน ถ้าไม่สำคัญจริงก็เป็นข้อมูลที่ทิ้งได้อยู่แล้ว ส่วนโทรศัพท์/กล้องก็ซิงก์ด้วย Nextcloud และให้การแบ็กอัปทำงานเฉพาะในโฮมเน็ตเวิร์ก จากนั้นให้ NAS แบ็กอัปทุกวันและเช็กสุขภาพ สุดท้ายใช้คลาวด์แบ็กอัปที่เชื่อถือได้หรือไดรฟ์ที่บ้านอื่น เท่านี้ก็ได้แบ็กอัปชั้นสองแล้ว
โซลูชัน self-host อย่าง PhotoPrism หรือ Immich มีประโยชน์มากสำหรับลบรูปซ้ำ ค้นหา และติดแท็ก ส่วนคลาวด์แบ็กอัปใช้คู่ Backblaze B2 + Cryptomator ได้ เพื่อให้เป็นสตอเรจเข้ารหัสและใช้อัปโหลดด้วยสคริปต์ DIY ค่าใช้จ่ายระดับประมาณ 1 ดอลลาร์ต่อ TB ต่อเดือน
ฉันใช้ syncthing อยู่ แม้ทางการจะไม่รองรับ Android แต่ถ้าใช้เวอร์ชัน fork ก็ทำงานได้ดี อีกอย่างขอแนะนำ ente.io หรือ self-hosted immich สำหรับแบ็กอัปรูป ส่วนเอกสารควรจัดการแยกด้วย paperless ngx หรือคล้ายกัน
Dirvish เป็น rsync wrapper ขนาดเบาที่ควรลองสักครั้ง ให้ฟีเจอร์ยอดเยี่ยมอย่าง rotation, incremental, retention และสคริปต์ก่อน/หลังทำงาน มันช่วยชีวิตข้อมูลของฉันมานานกว่า 20 ปี และเข้ากันได้ดีกับประเด็นที่บทความยกขึ้นมา เว็บไซต์ทางการของ dirvish, เว็บไซต์ทางการของ rsync
ฉันจัดการได้แม้ด้วยวิธีขี้เกียจมาก ๆ ครอบคลุมทั้งฮาร์ดแวร์พังและการโจรกรรม โดยใช้ชุดเก็บข้อมูลชั่วคราวในเดสก์ท็อป, ดิสก์ภายนอกในบ้าน, และดิสก์ภายนอกแบบ offsite (ทั้งหมดเป็น Samsung T7 Shield) ใช้
robocopy /MIRคัดลอกทุกวันลงที่ชั่วคราวหรือหลังทำงานเสร็จ แบ็กอัปลงดิสก์ภายนอกสัปดาห์ละครั้ง และสลับดิสก์ offsite เดือนละครั้งจังหวะพอดีเลย ฉันขอแชร์การตั้งค่า archlinux และกลยุทธ์แบ็กอัปของฉัน พร้อมทั้งเปิดซอร์ส สคริปต์ตั้งค่า/อัตโนมัติแบ็กอัป และ เลเยอร์อัตโนมัติสำหรับ borg
ข้อมูลมีค่าของฉันมีไม่ถึง 100MiB จึงแค่เลือกบาง path มาทำ
tar+บีบอัด+เข้ารหัส แล้วแบ็กอัปสัปดาห์ละสองครั้ง เก็บแบบหมุนเวียนไว้ไม่กี่เดือน วางไว้ทั้งในและนอกบ้าน แทบไม่ต้องตรวจเช็กหรือบำรุงรักษาอะไรเลย เป็นชุดที่ธรรมดาแต่ใช้งานได้ดี และทำอัตโนมัติด้วย sh script ไม่กี่บรรทัดถ้าพรุ่งนี้ฉันตายกะทันหัน ก็ควรย้อนคิดว่าข้อมูลอะไรที่ครอบครัวและลูกหลานควรค่าแก่การกู้คืนจริง ๆ บางทีไม่จำเป็นต้องมีไฟล์นับแสน แค่รูป วิดีโอ และข้อความสำคัญไม่กี่อย่างก็พอแล้ว
คอมเมนต์นี้ทำให้ฉันกลับมาคิดจริงจังว่าอะไรคือข้อมูลที่มีค่าจริงสำหรับฉัน รูปของฉันต่อให้บีบอัดแล้วก็ยังมีอย่างน้อยหลาย GB ส่วนรายชื่อผู้ติดต่อหรือของไม่สำคัญก็เล็ก โดยรวมอย่างอื่นหายไปก็ไม่เป็นไร คีย์กู้คืนควรเก็บให้ปลอดภัยกว่านี้ แต่บัญชีที่สำคัญที่สุดกลับไม่มีคีย์กู้คืนด้วยซ้ำ แค่รูปก็เกือบ 2TB แล้ว (ชะตากรรมของช่างภาพสมัครเล่น)
ส่วนที่ยากที่สุดของความสอดคล้องในการแบ็กอัปคือ แทบเป็นไปไม่ได้ที่จะสำรองข้อมูลแอปให้สอดคล้องกันโดยไม่ต้องหยุดบริการ ด้วย disk snapshot อย่างไรก็เลี่ยงไม่ได้ที่จะมีบางบริการอยู่กลางการเขียนในจังหวะที่ snapshot ถูกสร้าง ทำให้ตอนกู้คืนมีโอกาสสูงที่จะได้สภาพข้อมูลที่เสียหาย DB dump ช่วยบรรเทาปัญหานี้ได้มาก แต่ก็มักต้องทำจากภายนอกบริการ จึงอาจไปชนกลางคิวรีอยู่ดี ถ้าใครมีประสบการณ์หรือเทคนิคกับเรื่องนี้ก็อยากฟัง
โดยทั่วไป DB มักทนทานกับเรื่องนี้มาก ดังนั้นต่อให้จับ disk snapshot ตอนไหนก็เพียงพอสำหรับใช้เป็นแบ็กอัป สิ่งที่น่ากังวลคือกรณีพิเศษอย่างแคชที่ไม่มีแบตเตอรี่ แต่ทุกวันนี้ระบบคลาวด์และระบบสมัยใหม่แทบไม่ใช้โครงสร้างแบบนั้นแล้ว จึงไม่ค่อยมีปัญหา
กลยุทธ์จะต่างกันไปตามว่ามี state ของแอปอื่นนอกจาก DB ที่ต้องเก็บด้วยหรือไม่ (เช่น ต้องแบ็กอัป cache ด้วยหรือเปล่า)
pg_dump/mysqldumpทำให้ snapshot ของฐานข้อมูลที่กำลังใช้งานอยู่ทำได้อย่างปลอดภัยจริง แต่ก็มีต้นทุนอย่างความช้าและขนาด dump ที่ใหญ่ขึ้น ถ้าอยากหลีกเลี่ยงปัญหานี้ สำหรับ PostgreSQL ขนาดใหญ่ ฉันเคยใช้ read-only replica สำหรับงานแบ็กอัปโดยเฉพาะ หยุด replication ชั่วคราวแล้วรันแบ็กอัป จากนั้นค่อยเปิด replication ต่อ