surfup

ทดสอบการกู้คืน PostgreSQL ก่อนย้ายระบบ

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

นี่คือการซ้อม ไม่ใช่คู่มือ restore production ให้ยืนยัน database engine/version เจ้าของข้อมูล ระยะเวลาเก็บรักษา encryption และพื้นที่ดิสก์ที่พร้อมใช้ก่อนคัดลอก ห้ามทดสอบโดยเขียนทับ production

สร้างและระบุข้อมูลสำรอง

  • ใช้วิธี backup ที่เอกสารของโปรเจกต์กำหนดและ snapshot ที่สอดคล้องกัน บันทึก source database, version, timestamp/timezone, ขนาด, ผู้ถือครอง encryption key และ checksum
  • จัดเก็บสำเนาที่เข้ารหัสแยกจาก production host เก็บ secrets ให้พ้นจาก shell history, tickets และ screenshots; ตรวจว่าบุคลากรที่ได้รับอนุญาตเรียกใช้ key ได้

Restore ไปยังเป้าหมายที่แยกไว้

  • สร้าง database ว่างใหม่ด้วย major version ที่ต้องการและ roles/extensions ที่เข้ากันได้ Restore ลงที่นั่นด้วยเครื่องมือ PostgreSQL ที่ตรงกัน; ห้ามชี้คำสั่งไปยัง production
  • ตรวจตารางที่คาดไว้ จำนวนแถวของข้อมูลสำคัญ constraints การเริ่มทำงานของแอป และ workflow ตัวอย่างแบบอ่านอย่างเดียว บันทึกเวลา restore และความไม่ตรงกันก่อนอนุมัติ migration

ตัวอย่างและผลลัพธ์ที่คาดหวัง

  • เลือกเครื่องมือตามรูปแบบไฟล์: plain SQL ใช้ psql; custom/tar archives ใช้ pg_restore (ตรวจด้วย pg_restore --list backup.dump) Restore ลง disposable database ที่แยกไว้ ปิด workers และ outbound integrations และใช้ test secrets เท่านั้น ห้ามใช้ production ในการซ้อมนี้
  • บันทึก exit code เวลาที่ใช้ จำนวนตารางที่คาดไว้ และ aggregate checks ที่ทราบ หาก restore ล้มเหลวหรือจำนวนไม่ตรง ให้หยุดและตรวจ error, extensions และ roles บน test host ก่อน migration pg_dump ครอบคลุม database เดียว; global roles ต้อง backup แยกต่างหาก

แหล่งข้อมูลหลัก