qcow2 หรือ ZFS — ทำไมผมเพิ่งย้าย หลังใช้เครื่องเดิมมา 12 ปี

ตอน 2 ของซีรีส์ migration ผมพูดถึงการย้ายจาก mdadm RAID1 + ext4 + qcow2 ไปเป็น ZFS mirror + raw zvol แบบสั้น ๆ ผ่าน ๆ พอเขียนจบ ผมกลับมานั่งสงสัยตัวเองว่าตอนปี 2014 เลือก stack แบบนั้นทำไม แล้วเทียบกับเทคโนโลยีที่มีในยุคนั้นมันทันสมัยหรือล้าหลัง ผมเลยให้ Claude ช่วยไล่ดูจากหลักฐานในเครื่องว่าจริง ๆ แล้ว install มาตั้งแต่เมื่อไหร่ พอข้อมูลออกมา ผมแปลกใจตัวเองพอสมควร เลยอยากเล่าให้ฟังเป็นเรื่องเป็นราว เผื่อใครยังลังเลกับ storage layer ของตัวเองอยู่

บทความนี้ไม่ใช่ how-to ขั้นตอนย้าย (อันนั้นอยู่ในตอน 2 ของซีรีส์) แต่เป็นบันทึก "ทำไมตัดสินใจแบบนี้ใน timeline นี้" ซึ่งผมคิดว่ามีประโยชน์กว่า trick เปล่า ๆ

12 ปีของเครื่องนี้ — ไม่เคย reinstall เลย

ก่อนเข้าเรื่อง storage ขอเล่า trail ของเครื่องนี้ก่อน ผมเช็คจาก dpkg.log รวมกับวันที่ของ kernel file และ filesystem creation date ของ /boot ทำให้ไล่ลำดับ upgrade ได้แม่นพอสมควร ไม่ได้เดาเอา

สรุปคือ เริ่ม install PVE 3.2 / Debian 7 เมื่อ 18 มิ.ย. 2014 มาจนถึงปัจจุบันที่เป็น PVE 8.4.x / Debian 12 / kernel 6.8 อายุระบบราว 12 ปี ผ่านมา 5 PVE major versions บวก 5 Debian major versions โดย "ไม่ reinstall เลย" ทุก step เป็น in-place upgrade ทั้งหมด

ที่ทำได้แบบนี้เพราะ Debian และ PVE มีนโยบาย upgrade ตามทางอยู่แล้ว คือ stretch → buster → bullseye → bookworm แต่ละ jump มีคู่มืออย่างเป็นทางการให้ทำตาม เครื่องเดิม disk เดิม config เดิม VM เดิมทั้งหมด ลูกค้าก็ชุดเดิม ใครจะคิดว่าเป็นไปได้ว่า server ตัวเดียวรันได้ 12 ปี ผ่าน 8 major versions ของ OS — แต่นี่คือเรื่องจริง

ขอแทรกหน่อย — ทำไมเป็น Debian ไม่ใช่ Red Hat

ส่วนตัวผมเล่น Linux มาตั้งแต่ปี 2539 ราว 30 ปีแล้ว ผ่าน Red Hat, Mandrake/Mandriva, Slackware, Fedora, CentOS, Ubuntu มาเกือบหมด สรุปข้อสั่งสมง่าย ๆ ของผมคือ

ถ้าไม่ได้มีเงินซื้อ RHEL subscription จริงจัง สาย Red Hat อย่าไปยุ่งอีกเลย

เหตุผลคือนโยบายของฝั่งนั้นเปลี่ยนไปเปลี่ยนมาตลอด Fedora → CentOS → CentOS Stream → AlmaLinux / Rocky / EuroLinux และอื่น ๆ ค่ายไหนใครจะอยู่ใครจะปิด ใครจะ pivot เดาไม่ออก ตามไม่ทัน แถมต้องตามเขียนเอกสารใหม่ทุก major release

ผมเลือก Debian เพราะ update ยาว ๆ ได้โดยไม่ต้องเปลี่ยน distro นโยบายชัด timeline ชัด stretch → buster → bullseye → bookworm → trixie มี dist-upgrade path เป็นทางการเสมอ PVE เองก็เลือก Debian เป็น base ด้วยเหตุผลเดียวกัน

นี่คือเหตุผลที่เครื่องของผมอยู่บน Debian/PVE มาได้ 12 ปีโดยไม่ reinstall ไม่ใช่ความสามารถของผมหรอก แต่เป็นเพราะ distro ออกแบบมาให้อยู่ได้นาน และมีทาง upgrade ที่ชัดเจน

ปี 2014 — ทำไมไม่ใช้ ZFS ตั้งแต่แรก

ตอนนั้นตัวเลือก storage layer ของ PVE สำหรับคนทั่วไปคือ

• mdadm RAID + ext4 + qcow2 — ผมเลือกอันนี้
• mdadm RAID + ext4 + raw image
• LVM-thin
• ZFS — ยังใหม่มาก ยังไม่ stable

เหตุผลที่ผมเลือก qcow2 มี 4 ข้อ ดังนี้

1. ZFS on Linux ยังไม่นิ่ง

ZFS on Linux (ZoL) เริ่มต้นจริง ๆ ราวปี 2013 production-ready ก็ราวปี 2014–2015 แต่ตอนที่ install เครื่องนี้ (18 มิ.ย. 2014) ZFS ยังไม่อยู่ใน Proxmox main repo เลย ต้อง add 3rd-party repo แล้วลงเอง DKMS module ก็ต้อง compile ใหม่ทุก kernel update บวกกับปัญหาเรื่อง CDDL license ที่ชนกับ GPL ทำให้ ZFS เข้า mainline kernel ไม่ได้

ตอนนั้นบทความ ZFS ภาษาไทยผมยังค้นไม่เจอเลย มีแต่บทความแปลจากภาษาอังกฤษ ซึ่งผมก็อ่าน docs ภาษาอังกฤษเป็นปกติอยู่แล้ว ตรงนั้นไม่ใช่ปัญหา แต่อีกเรื่องคือ Proxmox สมัยนั้นยังเป็นลูกเมียน้อยมาก ทุกคนยังใช้ VMware กันหมด คนที่เลือก PVE ในยุคนั้นถือว่าเป็น early adopter พอสมควร

ผมเลยไม่ได้สนใจ ZFS จริงจัง แค่รู้ว่ามันคืออะไร ตั้งใจรอให้คนอื่นลองจนนิ่งก่อนค่อยตาม

แต่ด้วยที่ qcow2 + mdadm มันทนมือทนเท้า ไม่มีความจำเป็นต้องเปลี่ยน การย้าย user เกือบร้อยรายกับ data ราว 500 GB ไม่ใช่เรื่องที่ควรไปยุ่งถ้ามันยังทำงานดีอยู่ รอบที่ต้องขยับจริง ๆ คือเพราะ CentOS EOL บังคับ ไม่งั้นผมก็คงไม่แตะ

2. PVE ยังไม่ promote ZFS เป็น first-class

PVE 3.x ตอนนั้น installer ไม่ support ZFS rootfs จนกระทั่ง PVE 4.x ปี 2015 ถึงเริ่ม support แต่ยังเป็น experimental ใครจะลง ZFS เป็น root ต้องทำตามคู่มือใน Wiki ที่ค่อย ๆ อัพเดท ส่วน UI ของ PVE web panel ก็ยังไม่มี ZFS-aware feature เท่าตอนนี้

มาถึงตอนนี้ (PVE 8.x) ZFS เป็น first-class แล้ว installer support ZFS rootfs แบบ native, web UI มี ZFS storage management, replication, snapshot UI ครบ ต่างจาก 12 ปีก่อนเยอะมาก

3. ความเชื่อมั่นใน "simple recovery"

อันนี้สำคัญที่สุดสำหรับผมตอนนั้น ก่อนหน้า install เครื่องนี้ราว 1 ปี (ปี 2013) ผมโดน server พังมาก่อน data ไม่ได้หายนะ ปัญหาคือ hardware ต้องเปลี่ยน และสมัยนั้น NOC ยังไม่มีบริการ remote KVM ต้องไปถึงไซต์เอง หา hardware ทดแทน แล้วลงกลับ การกู้คืนภายใน 24 ชม. ทำไม่ได้ ลูกค้ารายใหญ่ของผมรับ downtime แบบนั้นไม่ได้ สุดท้ายเสียลูกค้ารายนั้นออกไป

หลังเคสนั้น ผมตั้งใจไว้เลยว่า storage layer ใหม่ของผมต้อง "ถ้าพังต้องกู้คืนได้ง่ายภายในไม่กี่ชั่วโมง" ไม่ใช่หลายวัน และขั้นตอน manual ต้อง minimal ที่สุด เพราะถ้า admin (คือผม) ไม่อยู่ในไซต์ คน on-site ต้องทำตามคู่มือได้

recovery plan ของ qcow2 ตอนนั้น ผมวางไว้เป็น 3-hour recovery plan ตามนี้

ขั้นตอนคร่าว ๆ คือ

• ถ้า disk data พัง — เปลี่ยน disk ใหม่ (PVE rootfs ปกติไม่พัง เพราะอยู่ disk/RAID อีกชุด)
• สร้าง mdadm RAID ใหม่ผ่าน PVE shell
• mount external HDD ที่เก็บ backup
• copy qcow2 backup ไปที่ images directory ของ PVE
• import VM config แล้ว start VM — ลูกค้ากลับมาใช้งานได้

ถ้า PVE rootfs เองพังด้วย (เจอน้อยมากในประสบการณ์ผม) ก็เพิ่มขั้น "ลง PVE ใหม่" อีกราวชั่วโมงนึง

ขั้นตอนนี้ผมเคยใช้จริง 2 ครั้งใน 12 ปีนี้ — 3 ชั่วโมงจริง ลูกค้าไม่กระทบเยอะ

อีกเรื่องคือผมใช้ mdadm software RAID มาตลอด ไม่เคยใช้ hardware RAID controller เลย เหตุผลคือสมัยก่อน NOC ยังไม่มี remote KVM service การเข้าไปตั้งค่า BIOS RAID controller ทำได้ยากมาก ต้อง physical access ทุกครั้ง ผมเลยตัด hardware RAID ออกตั้งแต่ตอนเลือก stack

ถ้าตอนนั้นเลือก ZFS recovery plan ก็ไม่ได้ซับซ้อนกว่ากันมาก pool import, replace disk, degrade/resilver เป็น standard ops ทั้งนั้น แต่ปัญหาของผมตอนนั้นคือต้องอ่าน docs เยอะกว่ามาก ความ "มั่นใจ" ในการอ่านแล้วทำตามผมไม่กังวล แต่ "เวลา" ที่ต้องเสียไปกับการอ่านนี่แหละ ที่ผมไม่อยากเสียในยุคที่ลูกค้าใหม่เข้ามาเรื่อย ๆ

4. qcow2 มี trade-off ที่ผมรับได้

• fsync amplification 3 ชั้น (qcow2 → ext4 → mdadm) — แต่ลูกค้าตอนนั้นใช้ MariaDB เบา ๆ ไม่มี high-IOPS workload
• ไม่มี native snapshot ที่เร็วเท่า ZFS — แต่ผมไม่ได้ใช้ snapshot บ่อย vzdump รายคืนก็พอ
• ไม่มี compression ฟรี — disk ตอนนั้นยังถูก เพิ่ม disk ดีกว่าเปิด compression
• ไม่มี ARC cache — แต่ RAM ที่มี allocate ให้ VM หมดอยู่แล้ว ไม่ได้กัน budget แยกให้ storage layer

ทุกข้อข้างบนคือ trade-off ที่ acceptable ในยุคนั้น

12 ปีผ่านไป — อะไรเปลี่ยน

ที่สำคัญ — disk ในเครื่องเริ่ม show อายุ

hardware ตัวเครื่อง CPU/RAM ผมยังเหมือนเดิมตั้งแต่ปี 2014 แต่ disk เริ่มมีอาการ ก่อน migrate หลายเดือนผมเห็น mdadm RAID มี degraded event ที่ recover ได้ แต่เริ่มถี่ขึ้น (เมื่อก่อนเจอครั้งทุก 2 ปี ปีล่าสุดเจอ 3 ครั้ง) เริ่มไม่สบายใจ และ ZFS ที่มี checksum ถ้าเปลี่ยนตอนนี้จะตรวจ silent corruption ได้ทันทีก่อนลูกค้ารู้สึก

ทำไมเพิ่งย้ายตอน migrate Debian — ไม่ทำแยก? ไม่ทำตั้งแต่ EOL?

หลายคนคงคิดว่า "ก็ทำ ZFS migrate ก่อนสัก 1–2 ปี ไม่ต้องรอ CentOS 7 EOL" หรือ "EOL ตั้งกลางปี 2024 ทำไมเพิ่งย้ายปี 2026"

ตอบตรง ๆ — ขี้เกียจครับ

มันต้องทำมือเองหมด ลองไปอ่านเอกสาร migration ดูว่าคำสั่งมันเยอะขนาดไหน บวกกับเคสจริงของลูกค้าเกือบร้อยราย user data ราว 500 GB ผิดพลาดครั้งเดียว rollback ก็เหนื่อย ผมเลยปล่อยให้ qcow2 + mdadm รันต่อไปเรื่อย ๆ ถึงแม้ CentOS 7 EOL ไปแล้วก็ตาม

รอบนี้ที่ทำได้เพราะ Claude

ย้ายรอบนี้ Claude ทำให้เกือบ 100% ผมแทบไม่ได้เข้า terminal เอง เข้าแค่ไล่ดูอย่างเดียวว่า Claude SSH เข้าไปสั่งถูกไหม ระบบล่มหรือเปล่า

เรื่องที่ปกติลูกพี่ผมทำ (คนที่ผมเอาเป็น reference เวลามีปัญหา) ผมก็ให้ Claude อ่าน config เก่าเข้าไปจัดการให้เลย พร้อมเขียนบันทึกทุก step ที่ทำกลับมาให้ผมเก็บไว้

ถ้าให้ผมทำมือเอง ย้ายไม่เสร็จภายใน 12 ชั่วโมงแน่ ๆ — 2–3 วันก็อาจยังไม่จบ

ด้วยวันนี้ที่เทคโนโลยีสะดวกขนาดนี้ มันเลยกลายเป็นเรื่องง่ายลงเยอะ จึงถึงเวลาที่ผมจะหันมาทำ

แต่ระวังนะ — Claude ยังไม่ 100%

ผมไม่แนะนำให้คนที่ไม่มีความรู้อะไรเลยสั่ง Claude ทำงานอย่างเดียว Claude หลายครั้งยังนอกลู่นอกทาง ผมต้องกด stop แล้วสั่งให้ทำใหม่หลายรอบ

ถ้าผมไม่รู้ว่าอันไหนถูกอันไหนผิด ผมก็จะปล่อยให้มันทำต่อไปแล้วเจอปัญหาทีหลัง ที่ผมสั่งได้ราบรื่นเพราะ knowledge Linux 30 ปีของผม (เล่นมาตั้งแต่ปี 2539) ยังเป็นส่วนสำคัญ Claude เป็นแค่ accelerator ไม่ใช่ replacement

ส่วน trick technical ที่ใช้ในการย้าย เช่น mdadm degrade ให้เหลือ disk เดียวขณะที่ VM ยังรัน แล้วเอา disk อีกใบไปทำ ZFS pool ขนานกันไป บวกกับ vzdump backup เป็น insurance ก่อนทุก critical step — ผมเล่าไว้แล้วในตอน 2 ของซีรีส์ migration ใครสนใจไปอ่านต่อในตอนนั้นได้

Lesson learned — สิ่งที่เปลี่ยน calculus จริง ๆ คือ AI tooling

จุดสำคัญที่ผมอยากแชร์ — บอกตรง ๆ ตลอด 12 ปีนี้ผมไม่ได้สนใจ ZFS มากนัก ยังคิดเรื่อง "กู้ง่าย" เป็นอันดับแรก ZFS หรือ storage layer ใหม่ ๆ ผมรู้ว่ามี อ่านผ่าน ๆ บ้าง แต่ไม่ได้ลงมือสะสมความรู้แบบจริงจัง เพราะ qcow2 + mdadm ก็ทำงานได้ recovery plan ของผมก็พิสูจน์ตัวเองมา 12 ปี

ที่เปลี่ยนเกมจริง ๆ คือ Claude

ทุกวันนี้ผมสั่งงานผ่าน editor ทั้งหมด เครื่องมี Python ให้ Claude เสกได้แทบทุกอย่าง แต่ workflow ของผมไม่ใช่ "นั่งอ่าน ZFS docs ครึ่งปีก่อนค่อยลงมือ"

workflow จริงของผมคือ "ทำไปก่อน ติดอะไรค่อยให้ Claude ค้น" ตามนี้

1. เริ่มลงมือเลย ตามขั้นตอนคร่าว ๆ ที่ Claude วางให้
2. เจอ pain point ระหว่างทาง (error, edge case, decision ที่ไม่แน่ใจ)
3. สั่ง Claude ค้น internet เรื่องนั้น
4. ระหว่าง Claude ค้น ผมคลิก reference link ดูเองว่าอ้างอิงจากที่ไหน
5. ถ้าน่าเชื่อถือ ปรับมาเป็น skill ของผมเลย แล้วใช้งานตอนนั้น ไม่รอ
6. ตอน Claude เริ่มลงมือทำตามแผนใหม่ ผมเฝ้าดู
7. ถ้าเริ่มผิด แค่ stop แล้วบอกข้อมูลที่ถูกต้องกลับไป

นี่คือสิ่งที่ต่างจาก 10 ปีก่อน ตอนนั้นถ้าไม่อ่านเองก็ทำอะไรไม่ได้ ตอนนี้ "อ่าน + ลองทำ" เกิดขึ้นพร้อมกันได้ แถม interactive ช่วยลด time-to-confidence จากเดือนเหลือชั่วโมง สำหรับ technology ที่ documented ดีพอ

เครื่องมือ AI ตอนนี้เปลี่ยน calculus ของการ adopt technology ใหม่ทั้งหมด ใครยังไม่ลองใช้ ผมแนะนำให้ลองดู

แต่ — ระวังนะ AI ไม่ใช่ silver bullet ลูกค้าที่ผมเสียไปปี 2013 จะกลับมาไม่ได้ถ้าตัดสินใจ adopt technology ใหม่ผิดจังหวะ Claude ลด research time ลงได้ก็จริง แต่ recovery plan + insurance backup ยังเป็นพื้นฐานที่ขาดไม่ได้ ผมยังทำ vzdump ก่อน critical operation เสมอ ไม่ว่าจะ ZFS หรือไม่ ZFS อันนี้เป็น habit ที่ผมไม่ทิ้ง

สรุป — ทำไม timing นี้ใช่

• ZFS โตเต็มที่แล้ว PVE ship มาให้ native พร้อม web UI integration ที่ดี
• Claude ช่วยอ่าน docs + plan + sanity-check command ผมไม่ต้องสะสม muscle memory เป็นปี ๆ ก่อนลงมือเอง
• Hardware ของผมเริ่ม show อายุ การมี ZFS checksum + scrub จะ catch silent corruption ได้
• มี blast radius ของ migrate Debian อยู่แล้ว touch storage ไปพร้อมกันคุ้ม disk slot ของผม
• Recovery plan ของผมตอนนี้ยังราว 3 ชม. (ZFS import จาก backup pool + restore VM) ไม่ต่างจาก qcow2 era สิ่งที่เปลี่ยนคือมี prevention ดีกว่า (checksum + scrub) เพิ่มขึ้นมานอกเหนือจาก recovery

ตรวจสุขภาพ pool หลังย้ายก็ทำได้ง่าย ๆ ด้วยคำสั่งเดียว

$ zpool status
  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 00:42:13 with 0 errors
config:
        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda3    ONLINE       0     0     0
            sdb3    ONLINE       0     0     0
errors: No known data errors

และตั้ง scrub รายเดือนไว้ให้มัน verify checksum เองเป็นกิจวัตร

$ zpool scrub rpool
$ systemctl list-timers | grep zfs

ปิดท้าย

ใครเริ่ม install เครื่อง PVE ใหม่ในปี 2026 ผมแนะนำ ZFS ตั้งแต่แรกเลย ไม่ต้องผ่านยุค qcow2 เหมือนผม PVE installer มี option ZFS rootfs ในตัวแล้ว community ก็แน่นแล้ว และที่สำคัญมี Claude/AI ช่วยเป็น on-call assistant ไม่ต้องนั่งอ่าน ZFS docs ครึ่งปีก่อนกล้าลงมือ

ใครเครื่อง production ตอนนี้ใช้ qcow2/LVM อยู่ แล้วยังนิ่งดี ไม่ต้องรีบย้าย pattern decision-making แบบเดียวกับผมตอน 2014 ยังใช้ได้ในปี 2026 ถ้า workload ไม่ขยับและ recovery plan ทำงานได้ ก็คงไว้ตามเดิม รอช่วง migrate ครั้งใหญ่ค่อย touch storage ไปพร้อมกัน คุ้มกว่า

เขียนกระทู้นี้แล้วได้กลับมาคิดทบทวน 12 ปีของเครื่องนี้ ปกติงานยุ่ง ๆ ผม taken-for-granted ความเสถียรของเครื่องไป บทความนี้เลยเป็นการ document ของจริง ไม่ใช่แค่ trick "ผมทำอย่างนี้" แต่เป็น "ทำไมตัดสินใจอย่างนี้ใน timeline นี้"

จะ qcow2 หรือ ZFS ตามสะดวก หลักการเหมือนกันหมด คือ recovery plan ต้องพิสูจน์ตัวเองได้ และอย่า touch storage ตอนที่มันยังดีอยู่โดยไม่มีเหตุผล ไว้นึกออกตรงไหนเพิ่มเติม ผมจะกลับมาแก้