การทดสอบการกู้คืนข้อมูลของคุณ
ข้อมูลสำรองที่กู้คืนไม่ได้ก็ไร้ประโยชน์
การทดสอบการกู้คืนข้อมูลของคุณ เป็นบทเรียน SQL Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน SQL Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส SQL Academy มีบทเรียนทั้งหมด 4 บทเรียน
ข้อมูลสำรองที่กู้คืนไม่ได้ก็ไร้ค่า
หลายทีมทุ่มเวลาไปกับการตั้งค่าการสำรองข้อมูลอัตโนมัติ แต่ไม่เคยตรวจสอบว่าข้อมูลสำรองเหล่านั้นสามารถนำไปกู้คืนข้อมูลได้จริงหรือไม่ ข้อมูลสำรองที่ล้มเหลวระหว่างการกู้คืนก็ไม่ต่างจากไม่มีข้อมูลสำรองเลย
บทเรียนนี้จะอธิบายแนวทางอย่างเป็นระบบของการทดสอบการกู้คืน และวิธีตรวจสอบว่าข้อมูลสำรองของคุณใช้งานได้ ก่อนที่ภัยพิบัติจริงจะบังคับให้คุณค้นพบความจริงด้วยวิธีที่ยากลำบาก
การทดสอบการกู้คืนประกอบด้วยอะไรบ้าง
การทดสอบการกู้คืนประกอบด้วยการนำไฟล์สำรองข้อมูลมาโหลดลงในฐานข้อมูล ซึ่งโดยทั่วไปจะเป็นระบบฐานข้อมูลสำหรับการทดสอบที่แยกต่างหาก จากนั้นเรียกใช้คำสั่งสืบค้นกับฐานข้อมูลนั้นเพื่อยืนยันว่าข้อมูลครบถ้วนและสอดคล้องกัน
ขั้นตอนมีดังนี้: 1) รับไฟล์สำรองข้อมูล 2) กู้คืนไฟล์ไปยังสภาพแวดล้อมจำลอง 3) เรียกใช้คำสั่งสืบค้นเพื่อตรวจสอบความถูกต้อง 4) เปรียบเทียบผลลัพธ์กับระบบจริง
การสร้างภาพสถานะฐานสำหรับการเปรียบเทียบ
ก่อนที่คุณจะตรวจสอบการกู้คืนได้ คุณต้องมีค่าฐาน ซึ่งเป็นชุดจำนวนและผลรวมตรวจสอบที่ทราบแน่ชัดจากระบบจริง เพื่อใช้เปรียบเทียบกับสำเนาที่กู้คืนแล้ว
เรียกใช้คำสั่งนี้กับฐานข้อมูลจริงและบันทึกผลลัพธ์ไว้:
SELECT
'orders' AS tbl, COUNT(*) AS row_count FROM orders
UNION ALL
SELECT
'customers' AS tbl, COUNT(*) AS row_count FROM customers
UNION ALL
SELECT
'order_items' AS tbl, COUNT(*) AS row_count FROM order_items;การตรวจสอบจำนวนแถวหลังการกู้คืน
เมื่อกู้คืนข้อมูลสำรองลงในฐานข้อมูลทดสอบแล้ว ให้เรียกใช้คำสั่งสืบค้นเดิมและเปรียบเทียบตัวเลข หากจำนวนตรงกัน แสดงว่าโครงสร้างพื้นฐานของการกู้คืนสมบูรณ์ดี
หากจำนวนไม่ตรงกัน สิ่งนี้จะบอกคุณทันทีว่าข้อมูลสูญหายระหว่างการสำรองข้อมูลหรือการกู้คืน ก่อนที่คุณจะไปแตะต้องระบบจริงเสียอีก
-- Run on the RESTORED test database
SELECT
'orders' AS tbl, COUNT(*) AS row_count FROM orders
UNION ALL
SELECT
'customers' AS tbl, COUNT(*) AS row_count FROM customers
UNION ALL
SELECT
'order_items' AS tbl, COUNT(*) AS row_count FROM order_items;การตรวจสอบข้อมูลล่าสุด
จำนวนแถวยืนยันปริมาณข้อมูล แต่ไม่ได้ยืนยันความเป็นปัจจุบัน ตรวจสอบว่าฐานข้อมูลที่กู้คืนแล้วมีระเบียนล่าสุดอยู่หรือไม่ ข้อมูลสำรองควรสะท้อนข้อมูลจนถึงช่วงเวลาที่สร้างข้อมูลสำรองนั้น
SELECT
MAX(created_at) AS latest_order,
MIN(created_at) AS oldest_order,
COUNT(*) AS total_orders
FROM orders;การตรวจสอบความถูกต้องของการอ้างอิงระหว่างตาราง
แม้จำนวนแถวจะตรงกัน การกู้คืนก็อาจทิ้งแถวกำพร้าไว้ได้ ซึ่งก็คือระเบียนลูกที่ไม่มีระเบียนแม่อยู่อีกต่อไป เหตุการณ์นี้มักเกิดขึ้นเมื่อไม่มีการบังคับใช้คีย์ต่างประเทศระหว่างการสำรองข้อมูลหรือการกู้คืน
ใช้ LEFT JOIN เพื่อตรวจหาแถวรายการสั่งซื้อที่เป็นแถวกำพร้า:
SELECT
oi.id AS orphaned_item_id,
oi.order_id AS missing_order_id
FROM order_items oi
LEFT JOIN orders o ON o.id = oi.order_id
WHERE o.id IS NULL;การใช้ผลรวมตรวจสอบเพื่อตรวจจับข้อมูลเสียหาย
สำหรับตารางสำคัญ ให้สร้างผลรวมตรวจสอบของข้อมูลเพื่อตรวจจับข้อมูลเสียหายในระดับบิต ใน PostgreSQL คุณสามารถรวม MD5 เข้ากับการแปลงชนิดข้อมูลของทั้งแถวได้
หากผลรวมตรวจสอบจากระบบจริงและสำเนาที่กู้คืนแล้วแตกต่างกัน แสดงว่าข้อมูลถูกเปลี่ยนแปลงหรือเสียหายในบางช่วงเวลา
SELECT
MD5(string_agg(row_data, ',' ORDER BY row_data)) AS table_checksum
FROM (
SELECT CAST(ROW(id, customer_id, total, created_at) AS TEXT) AS row_data
FROM orders
) sub;การสร้างตารางตรวจสอบการกู้คืน
เพื่อติดตามประวัติการทดสอบการกู้คืน ให้สร้างตารางบันทึกผลการตรวจสอบโดยเฉพาะ บันทึกการทดสอบแต่ละครั้งพร้อมวันที่ของข้อมูลสำรอง จำนวนแถวหลังการกู้คืน และผลว่าการตรวจสอบผ่านหรือไม่
CREATE TABLE IF NOT EXISTS restore_validation_log (
id SERIAL PRIMARY KEY,
backup_taken_at TIMESTAMP NOT NULL,
restored_at TIMESTAMP NOT NULL DEFAULT NOW(),
table_name VARCHAR(100) NOT NULL,
expected_rows INT NOT NULL,
actual_rows INT NOT NULL,
passed BOOLEAN NOT NULL
);การแทรกผลการตรวจสอบ
หลังการทดสอบการกู้คืนแต่ละครั้ง ให้แทรกแถวลงในบันทึกผลการตรวจสอบ วิธีนี้จะสร้างร่องรอยการตรวจสอบที่พิสูจน์ว่าข้อมูลสำรองได้รับการทดสอบแล้ว และแสดงรูปแบบของผลผ่านหรือไม่ผ่านเมื่อเวลาผ่านไป
INSERT INTO restore_validation_log
(backup_taken_at, table_name, expected_rows, actual_rows, passed)
VALUES
('2024-06-09 02:00:00', 'orders', 15482, 15482, TRUE),
('2024-06-09 02:00:00', 'customers', 8201, 8201, TRUE),
('2024-06-09 02:00:00', 'order_items', 47310, 47310, TRUE);การสืบค้นประวัติการตรวจสอบ
ตรวจสอบบันทึกผลการตรวจสอบเป็นประจำเพื่อค้นหาความเสื่อมถอย ข้อมูลสำรองที่ผ่านเมื่อสัปดาห์ก่อนแต่ไม่ผ่านในสัปดาห์นี้เป็นสัญญาณว่ามีปัญหาในกระบวนการสำรองข้อมูลของคุณ ซึ่งต้องตรวจสอบทันที
SELECT
backup_taken_at,
table_name,
expected_rows,
actual_rows,
passed,
CASE
WHEN passed THEN 'OK'
ELSE 'MISMATCH - investigate!'
END AS status
FROM restore_validation_log
ORDER BY backup_taken_at DESC, table_name;การตรวจสอบการกู้คืน ณ จุดเวลา
ฐานข้อมูลสมัยใหม่รองรับการกู้คืน ณ จุดเวลา (PITR) ซึ่งช่วยให้คุณกู้คืนไปยังช่วงเวลาใด ๆ ได้โดยใช้ข้อมูลสำรองฐานร่วมกับคลัง WAL (บันทึกแบบเขียนล่วงหน้า)
เพื่อตรวจสอบว่า PITR ทำงาน ให้กู้คืนไปยังการประทับเวลาที่ทราบแน่ชัด และตรวจสอบว่าเรกคอร์ดที่สร้างหลังการประทับเวลานั้นไม่ (NOT) ปรากฏในฐานข้อมูลที่กู้คืนแล้ว:
-- After a PITR restore to '2024-06-09 03:00:00',
-- this order (created at 03:45) should NOT exist:
SELECT id, created_at, total
FROM orders
WHERE created_at > '2024-06-09 03:00:00'
ORDER BY created_at
LIMIT 5;
-- Zero rows = PITR worked correctlyตรวจสอบอย่างรวดเร็ว
คำสั่งสืบค้นใดต่อไปนี้มีประโยชน์มากที่สุดในการตรวจหาระเบียนลูกที่เป็นแถวกำพร้าหลังจากกู้คืนข้อมูลสำรองแล้ว
สรุปบทเรียน: การทดสอบการกู้คืนข้อมูล
ในบทเรียนนี้ คุณได้เรียนรู้ว่าเหตุใดการทดสอบการกู้คืนจึงเป็นส่วนที่จำเป็นของกลยุทธ์การสำรองข้อมูลทุกแบบ และได้เรียนรู้วิธีนำไปใช้ด้วย SQL:
- ภาพสถานะฐาน — บันทึกจำนวนแถวของระบบจริงก่อนการทดสอบ
- การเปรียบเทียบจำนวนแถว — เรียกใช้คำสั่งสืบค้นเดียวกันกับฐานข้อมูลที่กู้คืนแล้วและเปรียบเทียบผลลัพธ์
- การตรวจสอบความเป็นปัจจุบัน — ยืนยันว่าระเบียนล่าสุดตรงกับช่วงเวลาที่คาดว่าจะอยู่ในข้อมูลสำรอง
- ความถูกต้องของการอ้างอิงระหว่างตาราง — ใช้ LEFT JOIN เพื่อค้นหาแถวลูกที่เป็นแถวกำพร้า
- การตรวจสอบผลรวม — ตรวจจับข้อมูลเสียหายในระดับบิตด้วยการรวมค่า MD5
- ตารางบันทึกผลการตรวจสอบ — ติดตามการทดสอบทุกครั้งเพื่อให้มีประวัติที่ตรวจสอบย้อนหลังได้
- การตรวจสอบ PITR — ยืนยันว่าการกู้คืน ณ จุดเวลานั้นไปถึงช่วงเวลาที่ถูกต้อง
ข้อมูลสำรองจะดีได้เท่ากับการทดสอบการกู้คืนที่สำเร็จครั้งล่าสุดเท่านั้น กำหนดเวลาตรวจสอบเหล่านี้เป็นประจำ และถือว่าความล้มเหลวทุกครั้งเป็นเหตุการณ์ร้ายแรง
คำถามที่พบบ่อย
บทเรียน “การทดสอบการกู้คืนข้อมูลของคุณ” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “การทดสอบการกู้คืนข้อมูลของคุณ” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส SQL Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส SQL Academy มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “การทดสอบการกู้คืนข้อมูลของคุณ”
ข้อมูลสำรองที่กู้คืนไม่ได้ก็ไร้ประโยชน์ คุณปฏิบัติ SQL Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน SQL Academy หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน SQL Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน
บทเรียน “การทดสอบการกู้คืนข้อมูลของคุณ” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน SQL Academy นี้ได้ไหม
ได้ บทเรียน SQL Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- การสำรองข้อมูลเชิงตรรกะเทียบกับเชิงกายภาพ
- การกู้คืน ณ เวลาใดเวลาหนึ่ง
- การทดสอบการกู้คืนข้อมูลของคุณ
- การวางแผนกู้คืนจากภัยพิบัติ