0Pricing
SQL Academy · บทเรียน

การวางแผนกู้คืนจากภัยพิบัติ

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 ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. การสำรองข้อมูลเชิงตรรกะเทียบกับเชิงกายภาพ
  2. การกู้คืน ณ เวลาใดเวลาหนึ่ง
  3. การทดสอบการกู้คืนข้อมูลของคุณ
  4. การวางแผนกู้คืนจากภัยพิบัติ
← กลับไปที่ SQL Academy