การวางแผนกู้คืนจากภัยพิบัติ
RPO, RTO และคู่มือปฏิบัติการ
การวางแผนกู้คืนจากภัยพิบัติ เป็นบทเรียน SQL Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน SQL Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส SQL Academy มีบทเรียนทั้งหมด 4 บทเรียน
การกู้คืนจากภัยพิบัติคืออะไร
การกู้คืนจากภัยพิบัติ (DR) คือชุดนโยบาย เครื่องมือ และขั้นตอนปฏิบัติที่ออกแบบมาเพื่อให้สามารถกู้คืนโครงสร้างพื้นฐานด้านเทคโนโลยีและระบบที่สำคัญหลังเกิดภัยพิบัติทางธรรมชาติหรือภัยพิบัติที่เกิดจากมนุษย์
ในบริบทของฐานข้อมูล การวางแผน DR ช่วยให้มั่นใจได้ว่าข้อมูลของคุณยังปลอดภัย และระบบสามารถกลับมาออนไลน์ได้ภายในกรอบเวลาที่ยอมรับได้หลังเกิดเหตุการณ์ต่าง ๆ เช่น ฮาร์ดแวร์ขัดข้อง การลบข้อมูลโดยไม่ตั้งใจ การโจมตีด้วยแรนซัมแวร์ หรือศูนย์ข้อมูลหยุดให้บริการ
เป้าหมายจุดกู้คืน (RPO)
RPO กำหนดปริมาณข้อมูลสูญหายสูงสุดที่ยอมรับได้ โดยวัดเป็นเวลา หาก RPO ของคุณคือ 1 ชั่วโมง คุณต้องสามารถกู้คืนข้อมูลได้จนถึงอย่างน้อย 1 ชั่วโมงก่อนเกิดภัยพิบัติ
RPO ที่สั้นลงทำให้ต้องสำรองข้อมูลบ่อยขึ้นหรือจำลองข้อมูลอย่างต่อเนื่อง คุณสามารถสืบค้นประวัติการสำรองข้อมูลเพื่อตรวจสอบว่าคุณบรรลุเป้าหมาย RPO หรือไม่
-- Check the last backup time and calculate data loss window
SELECT
backup_id,
backup_type,
started_at,
finished_at,
EXTRACT(EPOCH FROM (NOW() - finished_at)) / 3600 AS hours_since_backup
FROM backup_log
WHERE status = 'SUCCESS'
ORDER BY finished_at DESC
LIMIT 5;เป้าหมายเวลาการกู้คืน (RTO)
RTO กำหนดระยะเวลาสูงสุดที่ยอมรับได้ซึ่งระบบของคุณจะออฟไลน์หลังเกิดภัยพิบัติ หาก RTO ของคุณคือ 4 ชั่วโมง ฐานข้อมูลต้องกลับมาทำงานได้เต็มรูปแบบภายใน 4 ชั่วโมงนับจากเกิดความขัดข้อง
RTO มีผลต่อการตัดสินใจเกี่ยวกับเซิร์ฟเวอร์สำรอง ระบบสลับการทำงานอัตโนมัติเมื่อขัดข้อง และขั้นตอนการกู้คืน การติดตามระยะเวลาการกู้คืนในช่วงเวลาต่าง ๆ ช่วยให้คุณคาดการณ์ได้ว่าจะบรรลุ RTO หรือไม่
-- Track restore durations to validate RTO compliance
SELECT
restore_id,
triggered_at,
completed_at,
EXTRACT(EPOCH FROM (completed_at - triggered_at)) / 60 AS restore_minutes,
CASE
WHEN EXTRACT(EPOCH FROM (completed_at - triggered_at)) / 3600 <= 4
THEN 'WITHIN RTO'
ELSE 'RTO BREACHED'
END AS rto_status
FROM restore_log
ORDER BY triggered_at DESC;RPO กับ RTO — ความแตกต่างสำคัญ
เมตริกทั้งสองนี้มักทำให้สับสน วิธีจดจำที่ง่ายที่สุดมีดังนี้:
- RPO = คุณยอมให้ข้อมูลสูญหายได้มากเพียงใด (มองย้อนกลับ วัดเป็นช่วงเวลาก่อนเกิดภัยพิบัติ)
- RTO = คุณยอมให้ระบบหยุดทำงานได้นานเพียงใด (มองไปข้างหน้า วัดเป็นช่วงเวลาหลังเกิดภัยพิบัติ)
เมื่อรวมกัน เมตริกทั้งสองจะกำหนดช่วงเวลาการกู้คืนของคุณ และมีอิทธิพลโดยตรงต่อความถี่ในการสำรองข้อมูล กลยุทธ์การจำลองข้อมูล และงบประมาณโครงสร้างพื้นฐาน
-- Store RPO and RTO targets per database in a DR configuration table
CREATE TABLE dr_config (
db_name VARCHAR(100) PRIMARY KEY,
rpo_minutes INT NOT NULL,
rto_minutes INT NOT NULL,
tier VARCHAR(20) CHECK (tier IN ('CRITICAL', 'HIGH', 'MEDIUM', 'LOW')),
updated_at TIMESTAMP DEFAULT NOW()
);
INSERT INTO dr_config (db_name, rpo_minutes, rto_minutes, tier) VALUES
('orders_db', 15, 60, 'CRITICAL'),
('analytics_db', 120, 240, 'MEDIUM'),
('archive_db', 480, 480, 'LOW');ประเภทของข้อมูลสำรอง
มีกลยุทธ์การสำรองข้อมูลหลักสามแบบ โดยแต่ละแบบสร้างสมดุลระหว่างความเร็วและพื้นที่จัดเก็บ:
- ข้อมูลสำรองเต็มรูปแบบ: ภาพสถานะที่สมบูรณ์ของฐานข้อมูลทั้งหมด สร้างช้าที่สุด แต่กู้คืนได้เร็วที่สุด
- ข้อมูลสำรองส่วนต่าง: บันทึกเฉพาะการเปลี่ยนแปลงนับจากข้อมูลสำรองเต็มรูปแบบครั้งล่าสุด มีความเร็วปานกลางทั้งในการสร้างและการกู้คืน
- ข้อมูลสำรองแบบเพิ่มพูน: บันทึกเฉพาะการเปลี่ยนแปลงนับจากข้อมูลสำรองครั้งล่าสุดไม่ว่าจะเป็นประเภทใด สร้างได้เร็วที่สุด แต่กู้คืนช้าที่สุด เนื่องจากต้องใช้หลายไฟล์
กลยุทธ์ DR ส่วนใหญ่ผสานข้อมูลสำรองเต็มรูปแบบรายสัปดาห์เข้ากับข้อมูลสำรองแบบเพิ่มพูนรายวัน เพื่อสร้างสมดุลระหว่าง RPO และต้นทุนพื้นที่จัดเก็บ
-- Log each backup with its type for audit and recovery planning
CREATE TABLE backup_log (
backup_id SERIAL PRIMARY KEY,
db_name VARCHAR(100) NOT NULL,
backup_type VARCHAR(20) CHECK (backup_type IN ('FULL', 'DIFFERENTIAL', 'INCREMENTAL')),
started_at TIMESTAMP NOT NULL,
finished_at TIMESTAMP,
size_mb NUMERIC(12, 2),
status VARCHAR(20) DEFAULT 'IN_PROGRESS'
);
INSERT INTO backup_log (db_name, backup_type, started_at, finished_at, size_mb, status) VALUES
('orders_db', 'FULL', '2024-06-01 01:00:00', '2024-06-01 02:15:00', 45200, 'SUCCESS'),
('orders_db', 'INCREMENTAL', '2024-06-02 01:00:00', '2024-06-02 01:08:00', 320, 'SUCCESS'),
('orders_db', 'INCREMENTAL', '2024-06-03 01:00:00', '2024-06-03 01:07:00', 290, 'SUCCESS');การกู้คืน ณ จุดเวลา (PITR)
การกู้คืน ณ จุดเวลาช่วยให้คุณกู้คืนฐานข้อมูลไปยังช่วงเวลาใดเวลาหนึ่งโดยเฉพาะ ไม่ใช่เพียงเวลาที่สร้างข้อมูลสำรองครั้งล่าสุด วิธีนี้ทำได้โดยเล่นบันทึกธุรกรรมซ้ำ ซึ่งก็คือ WAL ใน PostgreSQL บนข้อมูลสำรองฐาน
PITR มีความสำคัญเมื่อคุณต้องกู้คืนจากข้อมูลเสียหายหรือการลบข้อมูลโดยไม่ตั้งใจที่เกิดขึ้นในเวลาซึ่งทราบแน่ชัด คุณสามารถกู้คืนไปยังช่วงเวลาก่อนเกิดเหตุการณ์ที่สร้างความเสียหายได้
-- Record WAL archive events for PITR tracking
CREATE TABLE wal_archive_log (
segment_name VARCHAR(200) PRIMARY KEY,
archived_at TIMESTAMP DEFAULT NOW(),
size_bytes BIGINT,
storage_path TEXT
);
-- Find all WAL segments archived within a recovery window
SELECT
segment_name,
archived_at,
ROUND(size_bytes / 1024.0 / 1024.0, 2) AS size_mb
FROM wal_archive_log
WHERE archived_at BETWEEN '2024-06-03 09:00:00' AND '2024-06-03 11:00:00'
ORDER BY archived_at;ฐานข้อมูลสำรองและการจำลองข้อมูล
ฐานข้อมูลสำรองหรือฐานข้อมูลแบบจำลองคือสำเนาของฐานข้อมูลหลักที่ได้รับการอัปเดตอย่างต่อเนื่องและทำงานอยู่บนฮาร์ดแวร์แยกต่างหาก ฐานข้อมูลนี้มีประโยชน์ต่อ DR สองด้าน:
- ฐานข้อมูลสำรองแบบพร้อมใช้งานทันที: รับคำสั่งสืบค้นเพื่ออ่านได้ และสลับไปทำงานแทนได้ภายในไม่กี่วินาที (RTO ใกล้ศูนย์)
- ฐานข้อมูลสำรองแบบเตรียมพร้อม: ซิงค์ข้อมูลให้ตรงกันอยู่เสมอ แต่ยังไม่ให้บริการรับการรับส่งข้อมูล การสลับไปทำงานแทนใช้เวลาหลายนาที
การตรวจสอบความล่าช้าของการจำลองข้อมูลเป็นสิ่งสำคัญอย่างยิ่ง — ฐานข้อมูลแบบจำลองที่ล่าช้าหมายความว่า RPO ที่เกิดขึ้นจริงแย่กว่าที่คาดไว้
-- Monitor replication lag on a PostgreSQL primary
SELECT
client_addr,
application_name,
state,
sent_lsn,
replay_lsn,
(sent_lsn - replay_lsn) AS lag_bytes,
EXTRACT(EPOCH FROM (NOW() - reply_time)) AS seconds_since_reply
FROM pg_stat_replication
ORDER BY lag_bytes DESC;คู่มือปฏิบัติการ: การจัดทำเอกสารขั้นตอนการกู้คืน
คู่มือปฏิบัติการ คือชุดคำแนะนำทีละขั้นตอนที่จัดทำเป็นเอกสาร ซึ่งผู้ปฏิบัติงานใช้ระหว่างเหตุการณ์กู้คืนจากภัยพิบัติ หากไม่มีคู่มือปฏิบัติการ แม้แต่ผู้ดูแลฐานข้อมูลที่มีประสบการณ์ก็อาจทำผิดพลาดซึ่งมีค่าใช้จ่ายสูงเมื่ออยู่ภายใต้แรงกดดัน
คู่มือปฏิบัติการ DR ที่ดีควรระบุผู้ที่ต้องติดต่อ ระบบที่ได้รับผลกระทบ คำสั่งที่ต้องเรียกใช้โดยละเอียด ผลลัพธ์ที่คาดไว้ในแต่ละขั้นตอน และขั้นตอนย้อนกลับหากการกู้คืนล้มเหลว การจัดเก็บข้อมูลกำกับของคู่มือปฏิบัติการไว้ในฐานข้อมูลช่วยติดตามรุ่นและตรวจสอบการใช้งานได้
-- Store runbook metadata in the database for audit tracking
CREATE TABLE runbook (
runbook_id SERIAL PRIMARY KEY,
title VARCHAR(200) NOT NULL,
scenario VARCHAR(100),
version VARCHAR(20) DEFAULT '1.0',
last_tested DATE,
owner VARCHAR(100),
doc_url TEXT
);
INSERT INTO runbook (title, scenario, version, last_tested, owner, doc_url) VALUES
('Full Database Restore from S3', 'total_loss', '2.1', '2024-05-15', 'dba_team', 'https://wiki.internal/dr/full-restore'),
('Failover to Hot Standby', 'primary_down', '1.4', '2024-04-20', 'dba_team', 'https://wiki.internal/dr/failover'),
('PITR to Specific Timestamp', 'data_corruption','1.2', '2024-03-10', 'dba_team', 'https://wiki.internal/dr/pitr');การบันทึกการดำเนินการตามคู่มือปฏิบัติการ
ทุกครั้งที่มีการดำเนินการตามคู่มือปฏิบัติการ ไม่ว่าจะเป็นระหว่างภัยพิบัติจริงหรือการซ้อมก็ตาม ควรบันทึกไว้ บันทึกการดำเนินการช่วยให้คุณวัดระยะเวลาที่การกู้คืนใช้จริงได้ ซึ่งเป็นการตรวจสอบ RTO ระบุขั้นตอนที่ช้าหรือมีแนวโน้มเกิดข้อผิดพลาด และแสดงการปฏิบัติตามข้อกำหนดแก่ผู้ตรวจสอบ
-- Log each runbook execution for RTO validation and audit
CREATE TABLE runbook_execution (
execution_id SERIAL PRIMARY KEY,
runbook_id INT REFERENCES runbook(runbook_id),
triggered_by VARCHAR(100),
is_drill BOOLEAN DEFAULT FALSE,
started_at TIMESTAMP NOT NULL,
completed_at TIMESTAMP,
outcome VARCHAR(20) CHECK (outcome IN ('SUCCESS', 'PARTIAL', 'FAILED'))
);
-- Report average restore time per runbook
SELECT
r.title,
COUNT(*) AS executions,
ROUND(AVG(EXTRACT(EPOCH FROM (e.completed_at - e.started_at)) / 60), 1) AS avg_minutes,
MAX(EXTRACT(EPOCH FROM (e.completed_at - e.started_at)) / 60) AS max_minutes
FROM runbook_execution e
JOIN runbook r ON r.runbook_id = e.runbook_id
WHERE e.outcome = 'SUCCESS'
GROUP BY r.title;การทดสอบ DR: การซ้อมเป็นประจำ
แผน DR ที่ไม่เคยทดสอบไม่ใช่แผน แต่เป็นเพียงความหวัง การซ้อมเป็นประจำเป็นสิ่งจำเป็น เพื่อให้มั่นใจว่าทีมของคุณสามารถดำเนินการตามคู่มือปฏิบัติการได้จริงภายใน RTO ที่กำหนดไว้ และข้อมูลสำรองสามารถกู้คืนได้จริง
การกำหนดเวลาและติดตามการซ้อมในฐานข้อมูลจะสร้างร่องรอยการตรวจสอบ และช่วยให้คุณค้นพบคู่มือปฏิบัติการที่เลยกำหนดทดสอบ
-- Find runbooks that have not been drilled in over 90 days
SELECT
r.runbook_id,
r.title,
r.scenario,
MAX(e.completed_at) AS last_drill,
CURRENT_DATE - MAX(e.completed_at::DATE) AS days_since_drill
FROM runbook r
LEFT JOIN runbook_execution e
ON e.runbook_id = r.runbook_id
AND e.is_drill = TRUE
AND e.outcome = 'SUCCESS'
GROUP BY r.runbook_id, r.title, r.scenario
HAVING MAX(e.completed_at) IS NULL
OR CURRENT_DATE - MAX(e.completed_at::DATE) > 90
ORDER BY days_since_drill DESC NULLS FIRST;นโยบายการเก็บรักษาข้อมูลสำรอง
นโยบายการเก็บรักษากำหนดว่าจะเก็บข้อมูลสำรองไว้นานเท่าใด การเก็บข้อมูลสำรองทุกชุดไว้ตลอดไปทำให้สิ้นเปลืองพื้นที่จัดเก็บ ส่วนการลบเร็วเกินไปจะละเมิด RPO และข้อกำหนดด้านการปฏิบัติตามกฎระเบียบ
นโยบายทั่วไปคือ เก็บข้อมูลสำรองแบบเพิ่มพูนรายวันเป็นเวลา 7 วัน ข้อมูลสำรองเต็มรูปแบบรายสัปดาห์เป็นเวลา 4 สัปดาห์ และข้อมูลสำรองเต็มรูปแบบรายเดือนเป็นเวลา 12 เดือน คุณสามารถบังคับใช้และตรวจสอบนโยบายการเก็บรักษาด้วยคำสั่งสืบค้น SQL ที่เรียกใช้กับบันทึกข้อมูลสำรอง
-- Identify backups that are outside their retention window and ready to purge
SELECT
backup_id,
db_name,
backup_type,
finished_at,
CURRENT_DATE - finished_at::DATE AS age_days,
CASE backup_type
WHEN 'INCREMENTAL' THEN 7
WHEN 'DIFFERENTIAL' THEN 28
WHEN 'FULL' THEN 365
END AS retention_days,
CASE
WHEN (CURRENT_DATE - finished_at::DATE) >
CASE backup_type
WHEN 'INCREMENTAL' THEN 7
WHEN 'DIFFERENTIAL' THEN 28
WHEN 'FULL' THEN 365
END
THEN 'PURGE'
ELSE 'KEEP'
END AS action
FROM backup_log
WHERE status = 'SUCCESS'
ORDER BY finished_at;ตรวจสอบความเข้าใจ
ทดสอบความเข้าใจเกี่ยวกับคำจำกัดความของ RPO และ RTO
ทบทวน: การวางแผนกู้คืนจากภัยพิบัติ
ในบทเรียนนี้ คุณได้สำรวจพื้นฐานของการวางแผนกู้คืนฐานข้อมูลจากภัยพิบัติ:
- RPO กำหนดระยะเวลาการสูญเสียข้อมูลสูงสุดที่ยอมรับได้ ยิ่ง RPO สั้นลง ก็ยิ่งต้องสำรองข้อมูลบ่อยขึ้นหรือจำลองข้อมูลอย่างต่อเนื่อง
- RTO กำหนดว่าต้องกู้คืนระบบให้เร็วเพียงใด ยิ่ง RTO สั้นลง ก็ยิ่งต้องใช้ระบบสำรองพร้อมใช้งานและการสลับไปใช้ระบบสำรองโดยอัตโนมัติ
- ประเภทของการสำรองข้อมูล ได้แก่ แบบเต็ม แบบต่างส่วน และแบบเพิ่มส่วน แต่ละประเภทมีข้อแลกเปลี่ยนระหว่างพื้นที่จัดเก็บ ความเร็วในการสร้าง และความเร็วในการกู้คืนแตกต่างกัน
- PITR (การกู้คืน ณ จุดเวลา) ใช้บันทึกธุรกรรมเพื่อกู้คืนไปยังช่วงเวลาที่แม่นยำใด ๆ ซึ่งช่วยป้องกันผลกระทบจากการเปลี่ยนแปลงโดยไม่ตั้งใจ
- คู่มือปฏิบัติงาน บันทึกทุกขั้นตอนของกระบวนการกู้คืน การบันทึกการดำเนินการช่วยยืนยันว่า RTO ของคุณสามารถทำได้จริง
- การซ้อมกู้คืนระบบ DR เป็นวิธีเดียวที่จะยืนยันได้ว่าการสำรองข้อมูลสามารถกู้คืนได้ และทีมของคุณสามารถบรรลุเป้าหมาย RPO และ RTO ภายใต้แรงกดดันจริง
- นโยบายการเก็บรักษาข้อมูล ช่วยสร้างสมดุลระหว่างค่าใช้จ่ายในการจัดเก็บ การปฏิบัติตามข้อกำหนด และข้อกำหนดด้านการกู้คืน
แผน DR ที่ผ่านการทดสอบอย่างดีเป็นหนึ่งในการลงทุนที่มีค่าที่สุดที่ทีมฐานข้อมูลสามารถทำได้
คำถามที่พบบ่อย
บทเรียน “การวางแผนกู้คืนจากภัยพิบัติ” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “การวางแผนกู้คืนจากภัยพิบัติ” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส SQL Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส SQL Academy มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “การวางแผนกู้คืนจากภัยพิบัติ”
RPO, RTO และคู่มือปฏิบัติการ คุณปฏิบัติ SQL Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน SQL Academy หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน SQL Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน
บทเรียน “การวางแผนกู้คืนจากภัยพิบัติ” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน SQL Academy นี้ได้ไหม
ได้ บทเรียน SQL Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- การสำรองข้อมูลเชิงตรรกะเทียบกับเชิงกายภาพ
- การกู้คืน ณ เวลาใดเวลาหนึ่ง
- การทดสอบการกู้คืนข้อมูลของคุณ
- การวางแผนกู้คืนจากภัยพิบัติ