RPO RTO คืออะไร และทดสอบ restore เป็นรอบอย่างไรให้รู้ตัวเลขจริง

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

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

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

RPO กับ RTO คืออะไร และต่างกันอย่างไร

NIST SP 800-34 ซึ่งเป็นคู่มือวางแผนความต่อเนื่องของระบบสารสนเทศของสหรัฐฯ ให้นิยามไว้ชัด RTO คือเวลาสูงสุดที่ทรัพยากรของระบบหยุดได้ ก่อนจะกระทบกระบวนการทางธุรกิจที่มันรองรับ ส่วน RPO คือจุดเวลาก่อนเกิดเหตุที่ข้อมูลจะกู้กลับมาได้ โดยอิงจากสำเนา backup ล่าสุด (อ้างอิง: NIST SP 800-34 Rev.1 หัวข้อ 3.2.1)

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

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

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

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

ตัวเลขใน TOR คือเป้า ระบบอาจทำไม่ได้ตามนั้น

RPO ที่ระบบทำได้จริงขึ้นกับสามอย่าง คือรอบของ backup เวลาที่ backup job แต่ละรอบใช้จนเสร็จ และความหน่วงของการ replicate ข้อมูลไปอีกที่ ถ้า TOR เขียนว่า RPO สี่ชั่วโมง แต่ backup รันวันละครั้ง ตัวเลขในเอกสารกับความสามารถจริงของระบบห่างกันตั้งแต่วันแรก

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

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

ข้อมูลโตขึ้นทุกเดือน และเวลา restore ก็โตตาม

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

ทดสอบ restore สามระดับ แต่ละระดับพิสูจน์คนละเรื่อง

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

ระดับที่สองคือ restore ฐานข้อมูลทั้งก้อน ถ้าระบบรองรับ ควรลองกู้แบบ point-in-time ไปยังจุดเวลาที่เลือกด้วย ระดับนี้ให้ตัวเลขสองตัวที่ผู้บริหารถามมากที่สุด คือ restore ฐานข้อมูลขนาดปัจจุบันใช้เวลานานเท่าไร และรายการสุดท้ายที่กู้กลับมาได้คือของเวลาไหน

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

Google Cloud เขียนหลักนี้ไว้ในเอกสาร Well-Architected Framework ว่าการทดสอบ restore ควรวัดผลด้วยความถูกต้องของข้อมูล RTO และ RPO ควรทดสอบทั้ง application stack กับบริการโครงสร้างพื้นฐานที่สำคัญบนข้อมูลที่กู้มา และควร restore ในสภาพแวดล้อมที่ไม่ใช่ production (อ้างอิง: Google Cloud, Perform testing for recovery from data loss อัปเดต 30 ธ.ค. 2024)

ควรทดสอบถี่แค่ไหน

NIST SP 800-34 แบ่งการทดสอบตามระดับผลกระทบของระบบ ระบบผลกระทบต่ำใช้การซ้อมบนโต๊ะ (tabletop) ก็พอ ระบบผลกระทบปานกลางควรมีการซ้อมที่รวมขั้นตอนกู้ระบบจาก backup จริง ส่วนระบบผลกระทบสูงควรซ้อมเต็มรูปแบบ รวมถึงการกู้ server หรือฐานข้อมูลจาก backup และกู้ระบบกลับสู่สถานะที่รู้แน่ว่าถูกต้อง ความถี่ของทุกระดับ NIST ให้องค์กรกำหนดเอง (อ้างอิง: NIST SP 800-34 Rev.1 หัวข้อ 3.5.1)

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

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

อีกด้านที่ควรตั้งไว้คู่กันคือการเฝ้าดู backup job ทุกวัน Google Cloud แนะนำให้ตั้ง consistency check อัตโนมัติหลัง backup ทุกรอบ และตั้ง alert เมื่อช่วงห่างของ backup เกิน RPO ที่กำหนด การตั้ง alert ให้เตือนเฉพาะเรื่องที่ควรตื่นมาแก้ เราเล่าไว้ในบทความ ตั้ง monitoring และ alert ให้เตือนเรื่องที่ควรตื่นมาแก้

จุดที่ restore มักพัง ทั้งที่ backup ขึ้นสถานะผ่าน

สถานะสำเร็จของ backup job บอกแค่ว่าการคัดลอกจบโดยไม่มี error มันไม่ได้บอกว่าสิ่งที่คัดลอกไปพอจะประกอบระบบกลับขึ้นมาได้ จุดที่การทดสอบ restore มักเจอมีรูปแบบซ้ำกันอยู่ไม่กี่แบบ

backup แค่ข้อมูล แต่ลืมของที่ทำให้ข้อมูลใช้งานได้ ฐานข้อมูลกลับมาครบ แต่ไฟล์ config, secret ของระบบ หรือ encryption key ที่ใช้ถอดรหัสข้อมูลไม่ได้อยู่ใน backup ชุดเดียวกัน ถ้า key อยู่ในบัญชีที่เข้าไม่ได้แล้ว ข้อมูลที่กู้มาก็อ่านไม่ออก เรื่องใครถือสิทธิ์บัญชีและ key ขององค์กร เราเล่าไว้ในบทความ ใครถือกุญแจบัญชี Cloud ขององค์กรอยู่จริง

backup อยู่ในที่เดียวกับสิ่งที่มันป้องกัน ถ้าบัญชีที่ลบ production ได้ ลบ backup ได้ด้วย ผู้โจมตีที่ได้บัญชีนั้นไปก็ทำลายทั้งสองอย่างพร้อมกัน CISA ระบุใน #StopRansomware Guide ว่า ransomware หลายตัวพยายามหาแล้วลบหรือเข้ารหัส backup ที่เข้าถึงได้ และแนะนำให้เก็บ backup แบบ offline เข้ารหัส และทดสอบความพร้อมใช้กับความถูกต้องของ backup เป็นประจำในสถานการณ์ DR (อ้างอิง: CISA #StopRansomware Guide ก.ย. 2023) บน cloud ทางเลือกที่ใกล้เคียงคือ backup แบบ immutable ซึ่งผู้ให้บริการอย่าง Microsoft Azure มีโหมดที่เมื่อล็อกแล้วจะย้อนกลับไม่ได้ จึงควรทดสอบผลกระทบให้แน่ใจก่อนล็อก

ความเสี่ยงนี้มีตัวเลขรองรับ รายงานของ Sophos ซึ่งสำรวจผู้ดูแล IT และความปลอดภัย 2,974 คนจากองค์กรขนาด 100 ถึง 5,000 คนใน 14 ประเทศที่โดน ransomware ในรอบปีก่อนหน้า เก็บข้อมูลเดือนมกราคมถึงกุมภาพันธ์ 2024 พบว่า 94% ขององค์กรเหล่านั้นถูกผู้โจมตีพยายามเจาะ backup และ 57% ของความพยายามนั้นสำเร็จ องค์กรที่ backup โดนเจาะมีค่าใช้จ่ายกู้คืนค่ากลางราว 3 ล้านดอลลาร์สหรัฐ เทียบกับราว 375,000 ดอลลาร์สหรัฐในกลุ่มที่ backup ไม่โดน (ที่มา: Sophos, The Impact of Compromised Backups on Ransomware Outcomes, มี.ค. 2024) ตัวเลขชุดนี้เป็นการสำรวจที่ vendor ด้านความปลอดภัยเป็นผู้ว่าจ้าง และ 14 ประเทศในรายงานไม่มีประเทศไทย จึงใช้เป็นภาพรวมระดับโลกได้ แต่ไม่ได้บอกสถานการณ์ในไทยโดยตรง

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

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

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

วัดและบันทึกผลแต่ละรอบให้เทียบกันได้

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

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

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

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

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

รายงานช่องว่างให้ผู้บริหารตัดสินใจ

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

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

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

ข้อจำกัดที่ต้องพูดตรง ๆ

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

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

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

จะเริ่มตรงไหน

เลือกระบบที่สำคัญที่สุดหนึ่งระบบ restore ฐานข้อมูลล่าสุดลงในสภาพแวดล้อมแยก จับเวลาแต่ละช่วง ดู timestamp ของรายการสุดท้ายที่กลับมา แล้ววางสองตัวเลขนั้นข้างเป้าใน TOR การทดสอบครั้งแรกแบบนี้ใช้เวลาไม่มาก และให้ข้อมูลที่องค์กรส่วนใหญ่ยังไม่มี คือ RPO และ RTO ตัวจริงของระบบที่รันอยู่วันนี้

ถ้าผลออกมาตรงเป้า คุณมีหลักฐานไปตอบผู้บริหารแล้ว ถ้าไม่ตรง คุณก็รู้ก่อนวันที่ต้องใช้จริง

สรุป

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

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

หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ สำหรับองค์กรที่ยังอยู่ระหว่างทบทวนแผนสำรองข้อมูลและกู้คืน เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน และหากคุยแล้วพบว่าขั้นตอนที่มีอยู่เพียงพอแล้ว เราจะบอกตรง ๆ