แบ็กอัปที่กู้ได้จริง: ทดสอบก่อนวันจำเป็น

คำถามที่เราได้ยินจริง

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

ทำไมแบ็กอัปถึงล้มเหลวตอนต้องกู้จริง

แบ็กอัปทำให้คุณผิดหวังได้อย่างน้อยห้าแบบ และเราเห็นครบทุกแบบในไซต์จริง

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

แบบที่สอง แบ็กอัปพังไปพร้อมต้นฉบับ NAS ที่วางข้างเซิร์ฟเวอร์จมน้ำท่วมครั้งเดียวกัน ไหม้ไฟครั้งเดียวกัน และถูกแรนซัมแวร์เข้ารหัสผ่านเครือข่ายครั้งเดียวกัน แฟลชไดรฟ์ USB ที่ไม่เคยหมุนเวียนอาจมีสำเนาเก่าชุดเดียวถ้ามีเลย การซิงก์ไฟล์ขึ้นคลาวด์ก็ไม่ใช่แบ็กอัปเช่นกัน เมื่อแรนซัมแวร์เปลี่ยนชื่อไฟล์ เครื่องมือซิงก์จะอัปโหลดไฟล์ที่ถูกเปลี่ยนชื่อภายในไม่กี่นาที ดูความต่างระหว่างซิงก์กับแบ็กอัปได้ที่ กฎแบ็กอัป 3-2-1

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

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

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

RPO กับ RTO แบบเข้าใจง่าย

คำสั้น ๆ สองคำกำหนดการออกแบบแบ็กอัปทั้งหมด มาอธิบายด้วยตัวอย่าง

RPO (recovery point objective) ตอบว่า เรายอมเสียงานได้มากแค่ไหน RPO หนึ่งวันหมายถึงแบ็กอัปเมื่อคืนพอแล้ว และการคีย์รายการของวันนี้ใหม่ด้วยมือรับได้ RPO หนึ่งชั่วโมงหมายถึงต้องมีสำเนาทุกชั่วโมง เพราะการเสียยอดใบแจ้งหนี้ทั้งเช้าของร้านที่งานยุ่งนั้นเจ็บหนัก RPO สั้นลงหมายถึงต้องรันแบ็กอัปถี่ขึ้นและใช้พื้นที่เก็บมากขึ้น

RTO (recovery time objective) ตอบว่า เราหยุดนิ่งได้นานแค่ไหน RTO สี่ชั่วโมงหมายถึงระบบต้องกลับมาใช้งานได้ พร้อมข้อมูลและพนักงานล็อกอิน ภายในสี่ชั่วโมงหลังเกิดเหตุ RTO รวมทุกอย่าง ตั้งแต่หาจุดเสีย นำสำเนามา ถ่ายโอนข้อมูล สตาร์ตบริการ และทดสอบล็อกอิน สำหรับสำนักงานขนาดเล็กทั่วไป เราแนะนำ RTO ครึ่งวันทำงานสำหรับระบบหลัก เพราะการสัญญาหนึ่งชั่วโมงฟังดูกล้าหาญ แต่ต้องมีเครื่องสำรองจอดรอไว้ ซึ่งบริษัทเล็กไม่กี่แห่งยอมจ่ายให้เครื่องจอดเฉย ๆ

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

การทดสอบห้าแบบกับความถี่ของแต่ละแบบ

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

มีข้อควรทราบของแต่ละแบบ การกู้ไฟล์เดี่ยวห้ามกู้ทับต้นฉบับ ให้ใช้โฟลเดอร์ชั่วคราวเสมอ สำเนาที่เสียจะได้ไม่ทำร้ายข้อมูลจริง การกู้ VM เรื่องเครือข่ายแยกสำคัญมาก โดเมนคอนโทรลเลอร์หรือเมลเซิร์ฟเวอร์ที่กู้ขึ้นมาแล้วแตะเครือข่ายจริงอาจสร้างความเสียหายในไม่กี่วินาที ถอดสายก่อน ตรวจซ้ำสองรอบ การทดสอบฐานข้อมูลแค่เปิดไฟล์ได้ยังไม่พอ ต้องล็อกอินผ่านแอปแล้วตรวจระเบียนของสัปดาห์ล่าสุด เพราะฐานข้อมูลเปิดได้แต่ข้อมูลช่วงหลังหายก็มี สำหรับการทดสอบ bare-metal ให้เตรียมเครื่องสำรองหนึ่งเครื่อง หรืออย่างน้อยบูต USB ที่ทดสอบแล้ว ฤดูฝนในลาวฟ้าผ่าบ่อยจนเพาเวอร์ซัพพลายพัง และนั่นคือเวลาที่คุณต้องใช้สิ่งนี้พอดี การซ้อมเต็มรูปแบบควรอิงตาม แผนรับมือเหตุขัดข้อง ที่เขียนไว้ โดยมีคนหนึ่งจับเวลาแต่ละขั้นตอน

วัดผลการกู้คืนให้ถูกต้อง

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

คำนวณคร่าว ๆ ก่อนทดสอบจะได้รู้ว่าควรคาดหวังอะไร การกู้ 500 GB ผ่านลิงก์ออฟฟิศ 1 Gbps ที่วิ่งจริงราว 100 MB ต่อวินาทีหลังหัก overhead ใช้เวลาราว 90 นาที 500 GB เท่ากันผ่านอินเทอร์เน็ต 50 Mbps ใช้เวลาราวหนึ่งวันเต็ม ผ่านไดรฟ์ USB 2.0 เก่าที่ 25 MB ต่อวินาทีใช้เวลาใกล้หกชั่วโมง ทวนตัวเลขเหล่านี้สองรอบกับความเร็วลิงก์ของตัวเองก่อนสัญญาเวลากับเจ้าของกิจการ ถ้าเวลาที่วัดได้เกิน RTO ให้แก้การออกแบบ เพิ่มสำเนาในไซต์ แยกภาระระบบสำคัญมากู้ก่อน หรือเตรียมเครื่องสแตนด์บาย

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

สำเนาที่แก้ไม่ได้กับบันทึกการทดสอบ

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

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

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

เช็กลิสต์สั้น ๆ ก่อนเรียกระบบใดว่าได้รับการป้องกันแล้ว

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

ขั้นต่อไปของคุณ ทดสอบกู้หนึ่งครั้งในเดือนนี้

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

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