ลบ container แล้วข้อมูลหาย เพราะเราเก็บไว้ตรงไหน

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

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

ลองแยกวงจรชีวิตของตัวแอปกับข้อมูลออกจากกันก่อนครับ เพราะรูปแบบที่เก็บต่างกันจะทำให้การลบ สร้างใหม่ ย้ายเครื่อง และสำรองมีความหมายต่างกันด้วย

ไฟล์ที่อยู่ใน container อาจไม่ได้อยู่ถาวรตามที่คิด

แอปเขียนไฟล์ลง path ภายในได้ แต่ถ้า path นั้นยังอยู่บน writable layer ของ container โดยไม่มีที่เก็บแยก ข้อมูลก็ผูกกับ container ตัวนั้น การแทนด้วยตัวใหม่จาก image ไม่ได้เอาสิ่งที่เคยเขียนกลับมาด้วยโดยอัตโนมัติ

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

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

ก่อนแก้การตั้งค่า ลองดูข้อมูล mounts ของ container ที่ใช้อยู่และเทียบกับเอกสารแอป พร้อมจดว่า path ใดมาจาก volume ใดหรือ directory บน host จุดนี้ช่วยให้เราเริ่มจากสิ่งที่เกิดจริง แทนการอ่านเฉพาะไฟล์ที่อาจไม่ตรงกับชุดที่รันอยู่แล้ว

named volume กับ bind mount เลือกจากวิธีดูแล

named volume เป็นทรัพยากรที่ Docker จัดการและนำมา mount ให้ container ส่วน bind mount ผูก path ที่เลือกบน host เข้ากับ path ใน container ทั้งสองแบบช่วยแยกข้อมูลออกจาก writable layer ได้ แต่มีรายละเอียดการย้ายและสิทธิ์ที่ต้องดูต่างกัน

ถ้าใช้ bind mount เราต้องรู้ว่า path บน host อยู่ที่ใด เป็นของใคร และถูกสำรองอย่างไร หากย้ายเครื่องไปที่โครง directory ต่างกัน ต้องตรวจการตั้งค่าใหม่ให้ตรง ไม่คาดหวังว่าระบบจะตามหาโฟลเดอร์เดิมให้เอง

ถ้าใช้ named volume ก็ต้องรู้ชื่อจริงของทรัพยากรและวิธีที่ Compose จัดชื่อให้ ไม่จำเพียงชื่อสั้นในไฟล์ เพราะชื่อ project อาจเป็นส่วนหนึ่งของชื่อที่สร้างจริง การเปลี่ยนชื่อชุดจึงอาจทำให้ container ใหม่ไปใช้ volume อีกตัว

ส่วน anonymous volume ต้องเข้าใจวิธีอ้างอิงกลับตามคำสั่งที่ใช้ หากข้อมูลมีวงจรชีวิตสำคัญ การตั้งชื่อและรายการ mount ให้ชัดจะช่วยให้ตามได้ง่ายขึ้น แต่ชื่อที่ชัดก็ยังต้องมีกติกาว่าเมื่อใดลบได้ ไม่ใช่ถือว่าเป็น named แล้วไม่มีใครลบได้อีก

ข้อมูลอาจไม่ได้หาย แต่อาจกำลังมองคนละที่

หากบริการใหม่ดูว่าง ให้ตรวจ mounts ก่อนสั่งล้างหรือสร้างข้อมูลทับ เพราะอาจเป็นการเริ่มกับ volume ใหม่ ขณะที่ข้อมูลเดิมยังอยู่ในทรัพยากรอีกตัว การตรวจต้องอิงสิ่งที่ยังมีอยู่จริง ไม่รับรองล่วงหน้าว่าข้อมูลเก่าต้องกู้ได้เสมอ

อีกกรณีคือ mount มาทับ path ที่มีไฟล์อยู่ใน image ทำให้สิ่งที่เห็นเปลี่ยนตามที่เก็บภายนอก พฤติกรรมการเริ่มต้นหรือคัดลอกข้อมูลเข้าสู่ volume ก็ต้องดูตามรูปแบบ mount และแอป ไม่สรุปว่าการเห็นโฟลเดอร์ว่างหมายถึง image ไม่มีไฟล์นั้นแน่นอน

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

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

คำสั่งจัดการต้องอ่านผลต่อข้อมูลด้วย

การหยุดหรือลบ container กับการลบ volume เป็นคนละการกระทำ แต่คำสั่งบางรูปแบบสามารถรวมการลบทรัพยากรข้อมูลไปด้วยได้ จึงควรตรวจ option ที่ใช้และรายชื่อเป้าหมายก่อนสั่ง โดยเฉพาะคำสั่ง cleanup หรือ prune ในเครื่องที่มีหลายบริการ

สำหรับ Compose การใช้ตัวเลือกที่เกี่ยวกับ volume ต้องดูว่ามันครอบคลุม named, anonymous หรือ external แบบใดตามเอกสาร ไม่คัดคำสั่งล้างจากสภาพทดลองมาใช้กับระบบที่มีข้อมูลจริงเพียงเพราะอยากให้เริ่มใหม่สะอาด

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

persistent ยังต้องมี backup ที่กู้ได้

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

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

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

รายการที่เก็บควรมีทั้งชื่อ service, path ใน container, ชื่อ volume หรือ path ต้นทาง และวิธีสำรอง เพื่อให้เวลาคนอื่นรับช่วงสามารถตามจากแอปไปถึงข้อมูลได้ โดยไม่ต้องเปิดทุก directory ค้นด้วยความจำของคนติดตั้ง

สรุป

ข้อมูลของ container ต้องถูกตามจาก path ที่แอปเขียนไปถึงที่เก็บจริง ไม่ใช่ดูเพียงชื่อบริการ เมื่อแยก writable layer, volume และ bind mount รวมถึงระบุตัวตนของ mounts ได้ เราจะจัดการสร้างใหม่หรือย้ายระบบได้ชัดขึ้น และรู้ว่าการรักษาข้อมูลกับการสำรองเป็นงานส่วนใดที่ยังต้องทำต่อครับ