คู่มือ DigitalOcean Snapshots 2026 — สำรองและ Clone Droplet

A practical guide to DigitalOcean Droplet Snapshots covering pricing, manual and scripted creation, restoring, and cloning Droplets with doctl.

Snapshot เป็นเครื่องมือพื้นฐานที่นักพัฒนาใช้เก็บภาพระบบของ Droplet ก่อนทำการเปลี่ยนแปลงเสี่ยง หรือใช้ clone สภาพแวดล้อมสำหรับทดสอบและสเกลระบบ บทความนี้อธิบายว่า Snapshot ต่างจาก Backup และ Custom Image อย่างไร ราคาที่แท้จริงคำนวณอย่างไร และวิธีสร้าง restore และ clone Droplet ด้วยคำสั่ง doctl จริงที่ใช้งานได้ทันที

Snapshot ต่างจาก Backup และ Custom Image ยังไง

DigitalOcean มีฟีเจอร์เก็บภาพระบบ (image) ของ Droplet อยู่สามแบบที่ผู้ใช้งานมักสับสน คือ Snapshot, Backups (ฟีเจอร์อัตโนมัติแยกต่างหาก) และ Custom Image ซึ่งแต่ละแบบออกแบบมาให้ทำงานต่างวัตถุประสงค์กัน Snapshot คือภาพสำเนาดิสก์ทั้งหมดของ Droplet ณ ช่วงเวลาหนึ่ง (point-in-time) ที่ผู้ใช้เป็นคนสั่งสร้างเองผ่าน Control Panel, doctl หรือ API ครอบคลุมทั้งระบบปฏิบัติการ การตั้งค่า และไฟล์ข้อมูลทั้งหมดบนดิสก์ของ Droplet ในขณะนั้น เก็บไว้ในบัญชีจนกว่าจะสั่งลบเอง ไม่มีวันหมดอายุอัตโนมัติ และนำไปใช้ทั้ง restore กลับ Droplet เดิม หรือสร้าง Droplet ใหม่ได้ทันที ส่วน Backups เป็นฟีเจอร์แยกต่างหากที่ต้องเปิดใช้งานต่อ Droplet โดยระบบจะสร้างภาพสำรองให้อัตโนมัติตามรอบเวลาที่ DigitalOcean กำหนด ไม่ใช่ผู้ใช้เลือกเวลาที่แน่นอนเอง และเก็บไว้เพียงจำนวนชุดล่าสุดตามนโยบายของแพลตฟอร์ม เหมาะกับการมี safety net พื้นฐานแบบตั้งแล้วลืม แต่ไม่เหมาะกับกรณีที่ต้องการ snapshot ณ จุดเวลาที่เจาะจง เช่น ก่อน deploy ครั้งสำคัญ ฟีเจอร์นี้มีค่าใช้จ่ายเพิ่มเติมต่อเดือนแยกจากค่า Droplet ปกติ ควรตรวจสอบตัวเลขล่าสุดที่หน้า pricing ของ DigitalOcean ก่อนเปิดใช้งาน Custom Image ต่างออกไปอีกแบบ คือการอัปโหลดไฟล์อิมเมจระบบปฏิบัติการของตัวเอง (รูปแบบเช่น qcow2, raw, vhdx, vdi หรือ iso) เข้าไปในบัญชี DigitalOcean เพื่อใช้ deploy Droplet ด้วยดิสโทรหรือระบบที่ไม่มีอยู่ใน Marketplace มาตรฐาน จุดต่างสำคัญคือ Custom Image ไม่ได้ derived มาจาก Droplet ที่รันอยู่ในบัญชีเหมือน Snapshot แต่เป็นไฟล์ ที่นำเข้าจากภายนอก สรุปสั้นๆ ให้เลือกใช้ตามงาน ถ้าต้องการภาพ ณ จุดเวลาที่ควบคุมเองได้ ใช้ Snapshot ถ้าต้องการระบบสำรองอัตโนมัติแบบ พื้นฐานไม่ต้องดูแล ใช้ Backups และถ้าต้องการนำระบบปฏิบัติการของตัวเองเข้ามาใช้งาน ใช้ Custom Image บทความนี้จะ โฟกัสที่ Snapshot เป็นหลัก เพราะเป็นฟีเจอร์ที่นักพัฒนาควบคุมได้ละเอียดที่สุดและใช้บ่อยที่สุดในงานจริง

DigitalOcean offers three types of Droplet image storage that often confuse users: Snapshots, Backups (a separate automatic feature), and Custom Images, each designed for different purposes. A Snapshot is a complete disk image copy of a Droplet at a specific point-in-time, created on-demand by the user via Control Panel, doctl, or API, covering the entire operating system, configuration, and all data files on the Droplet's disk at that moment. It's stored in the account until manually deleted, with no automatic expiration, and can be used both to restore the original Droplet or create new Droplets immediately. Backups, on the other hand, is a separate feature that must be enabled per Droplet, where the system automatically creates backup images at intervals set by DigitalOcean, not times chosen by the user, and stores only the latest set of backups according to platform policy. It suits a basic set-and-forget safety net approach, but doesn't fit cases where you need a snapshot at a specific point in time, such as before a major deployment. This feature incurs additional monthly costs separate from regular Droplet pricing and should be reviewed on the DigitalOcean pricing page before enabling. Custom Image is different again—uploading your own OS image files (formats like qcow2, raw, vhdx, vdi, or iso) into your DigitalOcean account to deploy Droplets with distributions or systems not available in the standard Marketplace. The key difference is that Custom Images are not derived from running Droplets in your account like Snapshots; they're files imported from outside. In short, choose based on your needs: use Snapshots if you want images at specific points in time under your control, Backups if you want basic automatic backup that requires no maintenance, and Custom Images if you want to bring your own OS into service. This article focuses primarily on Snapshots because it's the feature developers can control most granularly and use most frequently in real work.

• Snapshot = ภาพดิสก์ทั้งหมด ณ เวลาที่สั่งสร้างเอง เก็บไว้จนกว่าจะลบ
• Backups = ฟีเจอร์อัตโนมัติแยกต่างหาก เปิดต่อ Droplet มีค่าใช้จ่ายเพิ่ม เก็บตามรอบที่ระบบกำหนด
• Custom Image = อัปโหลดอิมเมจ OS ของตัวเองจากภายนอก ไม่ได้มาจาก Droplet ในบัญชี
• ทั้ง Snapshot และ Custom Image นำไปสร้าง Droplet ใหม่ได้เหมือนกัน

ราคา $0.06/GiB ต่อเดือน

จากการรีวิวหลายรอบ ค่าใช้จ่ายของ Droplet Snapshot บน DigitalOcean คิดในอัตรา $0.06 ต่อ GiB ต่อเดือน โดยคิดจากพื้นที่ที่ snapshot ใช้จริงหลังบีบอัด ไม่ใช่ขนาดดิสก์เต็มที่ Droplet มีอยู่ ยกตัวอย่างเช่น Droplet แผนเริ่มต้น $6/เดือน (1 GiB RAM, 1 vCPU, SSD 25 GB) ถ้าข้อมูลที่ใช้งานจริงบนดิสก์และผ่านการบีบอัดแล้วเหลือประมาณ 10 GiB ค่า snapshot ที่เกิดขึ้น จะอยู่ที่ประมาณ $0.60 ต่อเดือนต่อ 1 ชุด snapshot เท่านั้น ไม่ใช่คิดจากขนาด SSD 25 GB เต็ม ตัวเลขจริงจะแตกต่างกัน ไปตามปริมาณข้อมูลและอัตราการบีบอัดของแต่ละระบบ จึงควรดูยอดจริงในหน้า Billing ของบัญชีเป็นหลัก จุดที่ต้องระวังคือค่าใช้จ่ายนี้คิดต่อ snapshot แต่ละชุด ถ้าสร้าง snapshot ไว้หลายชุดโดยไม่ลบของเก่าทิ้ง ค่าใช้จ่ายจะสะสมเพิ่มขึ้นเรื่อยๆ ทุกเดือนแม้ Droplet ต้นทางจะถูกลบไปแล้วก็ตาม เพราะ snapshot เป็นทรัพยากรอิสระ ที่แยกบิลลิ่งออกจาก Droplet โดยสิ้นเชิง ข้อดีอย่างหนึ่งคือ DigitalOcean ไม่คิดค่าใช้จ่ายเพิ่มหากต้องการให้ snapshot พร้อมใช้งานในหลาย region พร้อมกัน ทำให้การย้าย Droplet ข้ามภูมิภาคผ่าน snapshot ไม่มีต้นทุนแอบแฝง สำหรับทีมที่ใช้ snapshot เป็นประจำ เช่น สร้างก่อน deploy ทุกครั้งหรือสร้างรายวันผ่าน cron แนะนำให้วางแผนเรื่อง การลบ snapshot เก่าควบคู่กันไปตั้งแต่แรก เพราะเป็นค่าใช้จ่ายที่มักถูกมองข้ามและไปโผล่เป็นยอดเกินคาดในใบแจ้งหนี้ ปลายเดือน ตรวจสอบยอด snapshot ทั้งหมดที่มีอยู่ได้ผ่านคำสั่ง doctl compute snapshot list ซึ่งจะแสดง ขนาดและวันที่สร้างของแต่ละชุด ช่วยให้ตัดสินใจได้ว่าชุดไหนควรเก็บหรือลบทิ้ง หมายเหตุ: ตัวเลขราคาทั้งหมดในบทความนี้อ้างอิงจากหน้า pricing ของ DigitalOcean ณ เดือนกรกฎาคม 2026 ควรตรวจสอบ ราคาล่าสุดที่เว็บไซต์ผู้ให้บริการก่อนตัดสินใจใช้งานจริงเสมอ เนื่องจากผู้ให้บริการคลาวด์มีการปรับราคาเป็นระยะ

1. อัตรา $0.06/GiB/เดือน คิดจากพื้นที่ใช้จริงหลังบีบอัด ไม่ใช่ขนาดดิสก์เต็ม
2. ไม่มีค่าใช้จ่ายเพิ่มสำหรับใช้ snapshot ข้าม region
3. snapshot แยกบิลลิ่งจาก Droplet ต้นทาง แม้ Droplet ถูกลบแล้วก็ยังเสียค่า snapshot ต่อ
4. ใช้ doctl compute snapshot list ตรวจสอบขนาดและจำนวน snapshot ที่มีอยู่
5. ราคาข้อมูล ณ กรกฎาคม 2026 ควรเช็คหน้า pricing ล่าสุดก่อนใช้งานจริง

สร้าง Snapshot ด้วยมือ vs อัตโนมัติ

การสร้าง Snapshot ด้วยมือทำได้สามช่องทางหลัก คือผ่าน Control Panel, ผ่าน doctl (CLI ทางการของ DigitalOcean) และผ่าน API โดยตรง สำหรับ Control Panel เข้าไปที่หน้า Droplet เป้าหมาย แล้วเลือกแท็บ Snapshots กดปุ่ม Take Snapshot ตั้งชื่อให้สื่อความหมาย เช่น ระบุวันที่และเหตุผลของการสร้าง ส่วนผ่าน doctl ใช้คำสั่ง doctl compute droplet-action snapshot 123456 --snapshot-name "web-01-2026-07-17" --wait โดยแทนที่ 123456 ด้วย ID ของ Droplet ซึ่งดูได้จาก doctl compute droplet list แฟล็ก --wait จะรอ จนกว่ากระบวนการจะเสร็จสมบูรณ์ก่อนคืนค่ากลับ terminal ทำให้เขียนสคริปต์ต่อได้ง่าย ข้อควรระวังสำคัญคือควรปิด Droplet (power off) ก่อนสร้าง snapshot โดยเฉพาะ Droplet ที่รันฐานข้อมูลหรือมีไฟล์ที่ กำลังเขียนอยู่ตลอดเวลา เพราะ snapshot ที่สร้างขณะ Droplet ยังทำงานอยู่มีความเสี่ยงที่ไฟล์ระบบจะอยู่ในสถานะไม่ สมบูรณ์ แม้ DigitalOcean จะอนุญาตให้ snapshot ขณะ Droplet เปิดอยู่ได้ก็ตาม สำหรับงานที่ยอมรับ downtime สั้นๆ ได้ การปิดเครื่องก่อน snapshot คือแนวทางที่ปลอดภัยที่สุด ในแง่ของระบบอัตโนมัติ DigitalOcean ไม่มีฟีเจอร์ตั้งเวลา snapshot อัตโนมัติแบบกำหนดเองในตัว ถ้าต้องการ snapshot อัตโนมัติตามรอบเวลาที่กำหนดเอง เช่น ทุกคืนเวลาตีสอง ต้องเขียนสคริปต์เรียก doctl หรือ API ผ่าน cron job บนเครื่อง แยกต่างหาก หรือรันผ่าน DigitalOcean Functions ก็ได้ ตัวอย่างการตั้ง cron อย่างง่ายบนเครื่อง management server: 0 2 * * * doctl compute droplet-action snapshot 123456 --snapshot-name "auto-$(date +\%Y\%m\%d)" --wait หากต้องการความสะดวกแบบไม่ต้องดูแลเอง และยอมรับข้อจำกัดเรื่องเลือกเวลาไม่ได้ ให้ใช้ฟีเจอร์ Backups ที่เปิดสวิตช์ ในหน้า Droplet แทน ซึ่งจะแยกเป็นค่าใช้จ่ายเพิ่มเติมต่อเดือนตามที่กล่าวไปในหัวข้อก่อนหน้า

• สร้างผ่าน Control Panel แท็บ Snapshots หรือ doctl หรือ API
• คำสั่งหลัก: doctl compute droplet-action snapshot <id> --snapshot-name "ชื่อ" --wait
• แนะนำปิด Droplet ก่อน snapshot โดยเฉพาะ Droplet ที่รันฐานข้อมูล
• ไม่มีตัวตั้งเวลา snapshot อัตโนมัติแบบกำหนดเองในตัว ต้องใช้ cron + doctl/API เอง
• ต้องการระบบสำรองอัตโนมัติแบบไม่ต้องดูแล ให้ใช้ฟีเจอร์ Backups แทน

Restore Droplet จาก Snapshot

การ restore จาก Snapshot ทำได้สองรูปแบบหลัก ขึ้นอยู่กับเป้าหมาย รูปแบบแรกคือ restore กลับเข้า Droplet เดิม ซึ่งจะเขียนทับดิสก์ทั้งหมดของ Droplet นั้นด้วยข้อมูลจาก snapshot ที่เลือก โดย Droplet ยังคง IP address และการ ตั้งค่าเครือข่ายเดิมไว้ วิธีนี้ทำผ่าน Control Panel ในหน้า Droplet เลือกแท็บ Backups & Snapshots แล้วกด Restore เลือก snapshot ที่ต้องการ หรือทำผ่าน doctl ด้วยคำสั่ง doctl compute droplet-action restore 123456 --image-id 987654321 --wait โดย image-id คือ ID ของ snapshot ที่ต้องการใช้ ดูได้จาก doctl compute snapshot list ข้อจำกัดสำคัญของการ restore แบบนี้คือใช้ได้เฉพาะกับ snapshot ที่สร้างมาจาก Droplet ตัวเดียวกันเท่านั้น จะนำ snapshot จาก Droplet อื่นมา restore ทับ Droplet ที่ไม่ใช่ต้นทางไม่ได้ นอกจากนี้ Droplet ต้องถูก power off ก่อน เริ่มกระบวนการ restore เสมอ ระบบจะปิดเครื่องให้อัตโนมัติหากยังเปิดอยู่ และระหว่างกระบวนการ Droplet จะใช้งาน ไม่ได้จนกว่าจะเสร็จ ระยะเวลาขึ้นอยู่กับขนาดของ snapshot รูปแบบที่สองคือสร้าง Droplet ใหม่ทั้งตัวโดยใช้ snapshot เป็น image ตั้งต้น เหมาะกับกรณีที่ต้องการเก็บ Droplet เดิมไว้เทียบกับตัวใหม่ก่อนตัดสินใจ หรือต้องการเปลี่ยน region/ขนาดไปพร้อมกัน วิธีนี้จะกล่าวถึงรายละเอียดใน หัวข้อถัดไป ก่อนลบ Droplet เดิมหลัง restore เสร็จ ควรตรวจสอบให้แน่ใจว่าระบบทำงานถูกต้องครบถ้วนก่อนเสมอ เช่น เช็ค service ที่ควรรันอยู่ เช็คข้อมูลในฐานข้อมูลว่าครบถ้วนตรงกับช่วงเวลาที่ snapshot ถูกสร้าง และทดสอบการเชื่อมต่อจากภายนอก ก่อนประกาศว่าระบบพร้อมใช้งานจริง การข้ามขั้นตอนตรวจสอบนี้เป็นสาเหตุที่พบบ่อยของปัญหาหลัง restore ที่ตรวจไม่พบ จนกระทั่งสาย

• Restore กลับ Droplet เดิม = เขียนทับดิสก์ทั้งหมด คง IP เดิม ต้อง power off ก่อนเริ่ม
• คำสั่ง: doctl compute droplet-action restore <droplet-id> --image-id <snapshot-id> --wait
• ใช้ restore แบบนี้ได้เฉพาะ snapshot จาก Droplet ตัวเดียวกันเท่านั้น
• ระยะเวลา restore ขึ้นกับขนาด snapshot

ใช้ Snapshot สร้าง Droplet ใหม่ (Clone/Scale)

จากที่เราทดสอบจริง — นอกจากใช้ restore กลับ Droplet เดิม Snapshot ยังใช้เป็น image ตั้งต้นสำหรับสร้าง Droplet ใหม่ทั้งตัวได้ ซึ่ง เป็นวิธีที่ยืดหยุ่นกว่าเพราะเลือก region ขนาด (size) และการตั้งค่าอื่นๆ ใหม่ได้อิสระจาก Droplet ต้นทาง ผ่าน doctl ใช้คำสั่ง doctl compute droplet create web-02 --image 987654321 --region sgp1 --size s-2vcpu-4gb --ssh-keys <fingerprint> โดยแทนที่ 987654321 ด้วย snapshot ID และเลือก region/size ตามต้องการ วิธีนี้เหมาะกับสามสถานการณ์หลักในงานจริง สถานการณ์แรกคือการ clone Droplet เพื่อทำ staging หรือ testing environment ที่มีสภาพแวดล้อมเหมือน production เป๊ะๆ โดยไม่ต้องติดตั้งทุกอย่างใหม่ตั้งแต่ต้น เพียงสร้าง snapshot จาก production แล้ว spin up Droplet ใหม่จาก snapshot นั้น ก็ได้สภาพแวดล้อมที่เหมือนกันทันที สถานการณ์ที่สองคือการ scale แนวนอน (horizontal scaling) โดยใช้ snapshot ที่เตรียมไว้เป็น golden image แล้ว spin Droplet ใหม่หลายตัวพร้อมกันเวลามี traffic เพิ่ม ซึ่งเร็วกว่า การตั้งค่า Droplet ใหม่ทุกครั้งด้วยมือมาก สถานการณ์ที่สามคือการย้าย Droplet ข้าม region เช่น จากภูมิภาคที่ไกลจากผู้ใช้ไทยไปยัง sgp1 (Singapore) ซึ่งเป็น region ที่ใกล้ผู้ใช้ในไทยที่สุด หรือ blr1 (Bangalore) เป็นตัวเลือกรองลงมา เพราะการ resize Droplet ปกติทำได้แค่ เปลี่ยนขนาดภายใน region เดียวกัน แต่ไม่สามารถย้ายข้าม region ได้โดยตรง การสร้าง snapshot แล้วนำไปสร้าง Droplet ใหม่ใน region ปลายทางจึงเป็นวิธีมาตรฐานสำหรับการย้าย region เมื่อสร้าง Droplet ใหม่จาก snapshot เสร็จแล้ว ควรตรวจสอบว่า SSH key, firewall rule, และ VPC ที่ผูกไว้เดิมถูกตั้ง ค่าใหม่ให้ถูกต้อง เพราะสิ่งเหล่านี้บางส่วนไม่ได้ถูกคัดลอกมาจาก Droplet ต้นทางโดยอัตโนมัติทั้งหมด ต้องตรวจสอบและ ตั้งค่าใหม่ทีละรายการก่อนนำไปใช้งานจริง

• คำสั่ง: doctl compute droplet create <ชื่อ> --image <snapshot-id> --region <region> --size <size>
• ใช้ clone environment สำหรับ staging/testing ที่เหมือน production
• ใช้ทำ golden image สำหรับ horizontal scaling หลาย Droplet พร้อมกัน
• ใช้ย้าย Droplet ข้าม region เช่นไปยัง sgp1 (Singapore) ที่ใกล้ผู้ใช้ไทยที่สุด

เมื่อไหร่ควรใช้ฟีเจอร์นี้ (Use Case จริง)

Snapshot เหมาะกับงานที่ต้องการจุดคืนกลับ (rollback point) ที่ควบคุมเวลาได้เอง มากกว่าใช้เป็นระบบ backup หลัก เพียงอย่างเดียว กรณีใช้งานจริงที่พบบ่อยที่สุดคือการสร้าง snapshot ก่อนทำการเปลี่ยนแปลงที่มีความเสี่ยง เช่น ก่อน อัปเกรดเวอร์ชันระบบปฏิบัติการ ก่อน deploy โค้ดชุดใหญ่ที่แก้โครงสร้างฐานข้อมูล หรือก่อนรัน migration script ที่ แก้ไขข้อมูลจำนวนมาก หากมีปัญหาเกิดขึ้นระหว่างทาง สามารถ restore กลับไปยังจุดก่อนเริ่มได้ทันทีโดยไม่ต้องไล่ debug ภายใต้ความกดดันเรื่องเวลา อีกกรณีที่ใช้บ่อยคือการเตรียม golden image สำหรับทีมที่ต้องการ Droplet ใหม่ที่มีค่าตั้งต้นเหมือนกันทุกครั้ง เช่น ติดตั้ง dependency ปรับ config และ security hardening ไว้ครบแล้วครั้งเดียวใน Droplet ต้นแบบ แล้วสร้าง snapshot เก็บไว้เป็น base image สำหรับ Droplet ใหม่ทุกตัวในทีม ลดเวลา setup และลดความคลาดเคลื่อนระหว่างสภาพแวดล้อมของ แต่ละคน สำหรับทีมที่ต้อง clone สภาพแวดล้อมเพื่อทดสอบก่อนขึ้น production จริง เช่น ทดสอบ patch ความปลอดภัยหรือทดสอบ การ scale ก่อนนำไปใช้กับระบบจริง Snapshot ช่วยให้จำลองสภาพแวดล้อมที่เหมือนของจริงได้โดยไม่กระทบระบบที่กำลัง ให้บริการอยู่ และในกรณีวางแผน disaster recovery Snapshot เป็นส่วนหนึ่งที่ควรใช้ร่วมกับการสำรองข้อมูลไปเก็บนอก แพลตฟอร์มด้วย เพราะ snapshot ยังอยู่ภายใต้บัญชี DigitalOcean เดียวกัน หากเกิดปัญหาระดับบัญชีจะไม่ใช่ตัวช่วยสุดท้าย ที่พึ่งได้ กรณีที่ไม่เหมาะจะใช้ Snapshot เป็นหลักคือการต้องการ backup รายวันแบบต่อเนื่องระยะยาวโดยไม่ต้องดูแลเอง เพราะต้อง เขียนสคริปต์ดูแล retention เอง ในกรณีนั้นฟีเจอร์ Backups อัตโนมัติหรือระบบ backup ระดับแอปพลิเคชัน เช่น pg_dump สำหรับฐานข้อมูล จะเหมาะสมกว่า

• ก่อนอัปเกรดระบบหรือ deploy โค้ดที่มีความเสี่ยงสูง
• เตรียม golden image ลดเวลา setup Droplet ใหม่ในทีม
• clone environment สำหรับทดสอบก่อนขึ้น production จริง

ข้อผิดพลาดที่พบบ่อยและวิธีแก้ไข

ในประสบการณ์ของเรา ข้อผิดพลาดแรกที่พบบ่อยคือสร้าง snapshot ขณะ Droplet ที่รันฐานข้อมูลยังเปิดอยู่และมีการเขียนข้อมูลต่อเนื่อง โดยไม่หยุดหรือ flush การเขียนก่อน ทำให้ snapshot ที่ได้อยู่ในสถานะไม่สมบูรณ์ เมื่อ restore กลับมาอาจพบข้อมูล ฐานข้อมูลเสียหายหรือไม่ครบ วิธีแก้คือปิด Droplet ก่อน snapshot ทุกครั้งที่ทำได้ หรืออย่างน้อยต้องสั่ง flush/sync ระดับแอปพลิเคชันก่อน เช่น หยุด service ฐานข้อมูลชั่วคราวหรือใช้เครื่องมือ dump เฉพาะของฐานข้อมูลนั้นควบคู่ไปด้วย ข้อผิดพลาดที่สองคือลืมลบ snapshot เก่าที่ไม่ใช้แล้ว โดยเฉพาะทีมที่สร้าง snapshot อัตโนมัติผ่าน cron ทุกวันแต่ไม่มี สคริปต์ลบของเก่าควบคู่กัน ทำให้ค่าใช้จ่ายสะสมเพิ่มขึ้นเรื่อยๆ ทุกเดือนโดยไม่รู้ตัว วิธีแก้คือเขียนสคริปต์ retention policy ควบคู่กับสคริปต์สร้าง snapshot ตั้งแต่แรก เช่น เก็บไว้แค่ 7 ชุดล่าสุดแล้วลบชุดที่เก่ากว่านั้นทิ้งอัตโนมัติ ทุกครั้งที่รัน cron ข้อผิดพลาดที่สามคือเข้าใจผิดว่า Snapshot คือระบบ backup ที่สมบูรณ์ในตัวเอง มีการหมุนเวียนและการแจ้งเตือนความ ล้มเหลวให้อัตโนมัติเหมือนโซลูชัน backup ระดับองค์กร ซึ่งในความจริง Snapshot เป็นแค่กลไกพื้นฐานที่ผู้ใช้ต้อง บริหารจัดการเองทั้งหมด ทั้งเรื่องความถี่ ที่เก็บ retention และการทดสอบ restore วิธีแก้คือถ้าต้องการระบบ backup ที่ดูแลตัวเองได้ระดับหนึ่ง ให้พิจารณาฟีเจอร์ Backups ควบคู่ไปด้วย ไม่ใช้ Snapshot เพียงอย่างเดียว ข้อผิดพลาดสุดท้ายที่พบบ่อยคือไม่เคยทดสอบ restore จาก snapshot มาก่อนจนกว่าจะเกิดเหตุฉุกเฉินจริง แล้วพบว่า กระบวนการ restore ใช้เวลานานกว่าที่คาด หรือ snapshot ที่มีอยู่ใช้งานไม่ได้จริงเพราะปัญหาบางอย่างที่ไม่เคย ตรวจสอบ วิธีแก้คือกำหนดให้มีการทดสอบ restore snapshot อย่างน้อยไตรมาสละครั้งในสภาพแวดล้อมทดสอบ เพื่อให้มั่นใจ ว่าเมื่อถึงเวลาจำเป็นจริง กระบวนการนี้ใช้งานได้จริงตามที่คาดหวังไว้

• Snapshot ขณะฐานข้อมูลกำลังเขียนข้อมูล → ข้อมูลไม่สมบูรณ์เมื่อ restore — ควร power off หรือ flush ก่อนเสมอ
• ลืมลบ snapshot เก่า → ค่าใช้จ่ายสะสม — เขียน retention script ควบคู่กับสคริปต์สร้าง snapshot
• เข้าใจผิดว่า Snapshot = ระบบ backup ที่สมบูรณ์ในตัว — ต้องบริหาร retention/rotation เอง
• ไม่เคยทดสอบ restore มาก่อน — ทดสอบอย่างน้อยไตรมาสละครั้ง
• ลืมตรวจ SSH key/Firewall/VPC หลังสร้าง Droplet ใหม่จาก snapshot

แนวทางปฏิบัติที่ดีที่สุด (Best Practices)

แนวทางแรกคือตั้งชื่อ snapshot ให้สื่อความหมายและมีวันที่กำกับเสมอ เช่น รูปแบบ web-01-YYYYMMDD-เหตุผล เพื่อให้ค้นหาและตัดสินใจลบ/เก็บได้ง่ายเมื่อมี snapshot สะสมจำนวนมาก การตั้ง ชื่อที่ไม่มีความหมาย เช่นใช้ชื่อ default ที่ระบบสร้างให้อัตโนมัติ จะทำให้ย้อนกลับมาดูทีหลังแล้วจำไม่ได้ว่าแต่ละ ชุดคืออะไร แนวทางที่สองคือทำให้กระบวนการสร้าง snapshot เป็นแบบ application-consistent สำหรับ Droplet ที่รันฐานข้อมูลหรือมี สถานะสำคัญ ไม่ใช่แค่ power off ธรรมดา ควรมีขั้นตอน flush cache, sync disk หรือหยุด service ชั่วคราวก่อน snapshot ทุกครั้ง เพื่อรับประกันว่าข้อมูลที่ restore กลับมาใช้งานได้จริงไม่เสียหาย แนวทางที่สามคืออัตโนมัติทั้งกระบวนการสร้างและการลบ snapshot ด้วยสคริปต์เดียวกัน ผ่าน cron ร่วมกับ doctl หรือ API โดยกำหนด retention policy ชัดเจนตั้งแต่แรก เช่น เก็บ 7 วันล่าสุดสำหรับ daily snapshot และเก็บแยกยาวขึ้น สำหรับ snapshot ที่สร้างก่อนเหตุการณ์สำคัญ ไม่ปล่อยให้เป็นงาน manual ที่ต้องมีคนจำมาทำเอง แนวทางที่สี่คือใช้ snapshot ร่วมกับกลยุทธ์ backup อื่นเสมอ ไม่พึ่ง snapshot เพียงอย่างเดียวเป็นแผนสำรองข้อมูล ทั้งหมด โดยเฉพาะข้อมูลสำคัญควรมีสำเนาที่เก็บนอกบัญชี DigitalOcean ด้วย เช่น export ไปยัง object storage คนละ บัญชีหรือคนละผู้ให้บริการ เพื่อป้องกันความเสี่ยงระดับบัญชีหรือแพลตฟอร์ม แนวทางสุดท้ายคือทดสอบ restore เป็นประจำและจดบันทึกระยะเวลาที่ใช้จริงในแต่ละครั้ง เพื่อให้ทีมรู้ตัวเลข RTO (Recovery Time Objective) ที่เป็นจริง ไม่ใช่ตัวเลขที่คาดเดาไว้ลอยๆ และหมั่นตรวจสอบยอด snapshot ที่มีอยู่ทั้งหมด ในบัญชีผ่าน doctl compute snapshot list เป็นระยะ เพื่อควบคุมทั้งค่าใช้จ่ายและความเป็นระเบียบของ ทรัพยากรในระยะยาว

• ตั้งชื่อ snapshot มีวันที่+เหตุผลกำกับเสมอ เช่น web-01-20260717-pre-upgrade
• ทำ snapshot แบบ application-consistent สำหรับ Droplet ที่มีฐานข้อมูล ไม่ใช่แค่ power off เฉยๆ
• อัตโนมัติทั้งสร้างและลบด้วย retention policy ชัดเจนผ่าน cron+doctl

รับ $200 Free Credit →