Backup ขึ้นว่าสำเร็จ แล้วเคยลองกู้หรือยัง

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

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

การทดลองกู้จึงช่วยตรวจทั้งสำเนาและความรู้ในการประกอบระบบกลับ ไม่จำเป็นต้องเริ่มจากจำลองเหตุใหญ่ทันที แต่ควรทำในพื้นที่แยกและรู้ว่าผลที่ผ่านจะยืนยันอะไรบ้าง

เลือกโจทย์ให้ชัดว่ากำลังกู้อะไร

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

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

เครื่องมืออย่าง restic มีวิธีเลือก snapshot และเป้าหมาย restore ให้ใช้ แต่ผู้ดูแลยังต้องตรวจว่าตัวกรองกำลังเลือกสำเนาหรือเลือกเฉพาะไฟล์ที่คืนตามรูปแบบของคำสั่ง เพราะตัวเลือกชื่อคล้ายกันอาจมีขอบเขตต่างกันได้

บันทึกรหัสสำเนาที่ใช้ไว้กับผลทดสอบ จะช่วยให้ย้อนดูได้ว่าความสำเร็จนั้นเป็นหลักฐานของชุดไหน ไม่ให้ผลของสำเนาเก่าที่เคยกู้ผ่านถูกนำไปใช้รับรองชุดใหม่ทุกคืนโดยไม่มีการตรวจต่อ

เตรียมพื้นที่แยกก่อนเปิดสำเนา

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

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

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

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

เปิดไฟล์ได้ยังต้องดูความหมายของข้อมูล

หลัง restore ให้ตรวจทั้งรายชื่อ ขนาด และสิ่งที่สำคัญต่อแอป การเปรียบเทียบ checksum ช่วยตรวจความตรงของข้อมูลในขอบเขตที่เลือก แต่ไม่ได้ยืนยันว่า backup ต้นทางมีข้อมูลครบตามงานตั้งแต่แรก หรือว่าฐานข้อมูลนั้นเปิดด้วยแอปรุ่นที่ต้องใช้ได้แล้ว

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

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

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

ตรวจ repository กับทดลองกู้ช่วยคนละด้าน

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

การตรวจ repository จึงควรอยู่คู่กับการทดลองกู้ ไม่ถูกใช้แทนกันทั้งหมด เพราะขั้นกู้ยังมีเรื่องปลายทาง สิทธิ์ รุ่นแอป และองค์ประกอบที่ระบบใช้งานต้องการ ซึ่งการตรวจสำเนาภายในไม่ได้เปิดแอปยืนยันแทนเรา

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

จับเวลาตามเส้นทางที่ต้องทำจริง

เริ่มนับตั้งแต่สิ่งที่วันกู้ต้องเตรียม เช่น ขอสิทธิ์ หา key เตรียมพื้นที่ และย้ายข้อมูล ไม่ใช่เฉพาะวินาทีที่คำสั่ง restore กำลังทำงาน เมื่อแบ่งเวลาแต่ละช่วงไว้ เราจะเห็นว่าควรปรับขั้นตอนไหนเพื่อกลับมาใช้งานได้ทันเป้าหมาย

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

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

ทบทวนหลังระบบเปลี่ยน ไม่รอถึงรอบใหญ่เท่านั้น

เมื่อย้ายฐานข้อมูล เปลี่ยน path เก็บไฟล์ เพิ่มบริการ หรือเปลี่ยนวิธีเข้ารหัส สิ่งที่เคยกู้ผ่านอาจไม่ครอบคลุมระบบปัจจุบันแล้ว ควรผูกการทบทวนกับการเปลี่ยนเหล่านี้ และมีรอบตรวจตามความสำคัญของข้อมูล

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

สรุป

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