Pritunl สำรองข้อมูล: สถานะการควบคุมกับโปรไฟล์ที่สร้างขึ้น

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

สองวัตถุดูเหมือนข้อมูลสำรองและมีเพียงหนึ่งเดียวที่คืนค่าบริการ

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

สำเนาการกำหนดค่าของโฮสต์ก็เป็นเพียงบางส่วนเช่นกัน /etc/pritunl.conf เก็บการตั้งค่าระดับโฮสต์ รวมถึงวิธีเข้าถึงฐานข้อมูล และไม่มีวัตถุ VPN เอง

สิ่งที่ฐานข้อมูลเป็นเจ้าของและสิ่งที่โฮสต์เป็นเจ้าของ

Pritunl เก็บคำจำกัดความเซิร์ฟเวอร์ ผู้ใช้ องค์กร และกุญแจไว้ใน MongoDB ฐานข้อมูลนั้นคือระนาบควบคุมที่เชื่อถือได้ และทุกไฟล์ OpenVPN ที่สร้างขึ้นบนดิสก์เป็นเอาต์พุตที่ได้มาจากมัน การเปลี่ยนแปลงที่ทำโดยตรงในไฟล์ที่สร้างขึ้นจะอยู่รอดจนถึงการสร้างใหม่ครั้งถัดไปแล้วหายไป นี่คือเหตุผลที่การแก้ไขไฟล์ขณะรันไทม์ไม่ใช่การแก้ไขที่ยั่งยืน กฎเดียวกันใช้กับเส้นทางและอินเทอร์เฟซที่มีผล พวกมันอธิบายสิ่งที่ระนาบควบคุมผลิตออกมา ไม่ใช่สิ่งที่ควรผลิต

โฮสต์มีส่วนร่วมด้วยชุดค่าที่เล็กกว่าแต่ถ่ายโอนไม่ได้ หนึ่งในนั้นคือ /var/lib/pritunl/pritunl.uuid ตัวตนของโหนดนั้นโดยเฉพาะ

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

ทำดัมป์ที่สอดคล้องกัน ไม่ใช่สำเนาไดเรกทอรี

การคัดลอกไดเรกทอรีข้อมูล MongoDB ขณะที่บริการกำลังเขียนทำให้เกิดไฟล์ที่อาจไม่ก่อให้เกิดฐานข้อมูลที่ใช้งานได้ ใช้เส้นทางดัมป์ที่ฐานข้อมูลรองรับแทน โดยรันกับโทโพโลยีที่คุณมีจริง:

mongodump --uri="mongodb://127.0.0.1:27017/pritunl" --out=/var/backups/pritunl/db
sudo tar czf /var/backups/pritunl/host.tgz /etc/pritunl.conf /var/lib/pritunl/pritunl.uuid

โฮสต์เดี่ยวทนรูปแบบง่ายนั้นได้ ชุดรีพลิกาต้องการจุดเวลาที่สอดคล้องกัน และดัมป์ที่อิง oplog มีข้อกำหนดที่ดัมป์ธรรมดาไม่มี ขั้นตอนที่รองรับขึ้นอยู่กับเวอร์ชันและโทโพโลยี MongoDB ของคุณ ดังนั้นอย่าสรุปจากการมีอยู่ของไดเรกทอรีข้อมูล เก็บเลเยอร์โฮสต์ไว้ข้างดัมป์ ในการรันเดียวกัน ด้วยการประทับเวลาเดียวกัน

ซ้อมการคืนค่าก่อนที่คุณจะต้องใช้

ข้อมูลสำรองที่ไม่มีใครคืนค่าเป็นเพียงสมมติฐาน สร้างบริการในเครือข่ายที่แยกออก คืนค่าดัมป์ และวางไฟล์โฮสต์กลับคืน:

mongorestore --uri="mongodb://127.0.0.1:27017" --drop /var/backups/pritunl/db
sudo tar xzf /var/backups/pritunl/host.tgz -C /

จากนั้นตรวจสอบวัตถุแทนกระบวนการ ล็อกอิน ยืนยันว่าองค์กรและผู้ใช้อยู่ และเริ่มไคลเอนต์ทดสอบหนึ่งตัวกับคำจำกัดความเซิร์ฟเวอร์ที่คุณรู้จัก ห้ามโฮสต์ที่คืนค่าแล้วโฆษณาปลายทางการผลิตหรือรับการเชื่อมต่อจริงจนกว่าที่อยู่และตัวตนจะเป็นเจตนา ที่นี่คุณยังค้นพบว่าไฟล์เก็บถาวรต้องการข้อมูลรับรองที่อาศัยอยู่เฉพาะบนเครื่องที่ล้มเหลว ดังนั้นเก็บข้อมูลรับรองการกู้คืนไว้ในที่ที่เป็นอิสระ การคืนค่าที่ขึ้นอยู่กับโฮสต์ที่คุณเพิ่งสูญเสียไปไม่ใช่แผนการคืนค่า

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