ไม่มี Backup / แบ็กอัปผิดวิธี — วันที่เว็บหายจริง คุณถึงจะรู้ว่ามันต่างกัน

"พี่อ๊อด เว็บผมหายหมดเลย... แล้ว backup ไม่มี"

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

"พี่ครับ เว็บลูกค้าผมอัปเดตปลั๊กอินตัวเดียว แล้วจอขาวหมดเลย เข้าหลังบ้านก็ไม่ได้ ผมกะว่าจะ restore กลับ แต่... ผมไม่มี backup เลยพี่ ลูกค้าฝากเว็บไว้กับผมสามปี ของในนั้นมีทั้งบทความ ทั้งรูป ทั้งออเดอร์ ผมจะบอกเขายังไงดี"

ผมเชื่อว่าถ้าคุณเป็นคนทำเว็บ คุณเคยเจอ หรือกลัวจะเจอ ข้อความประมาณนี้มาก่อน

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

ผมเขียนโค้ด ทำเว็บมา 20 ปี และทำโฮสติ้งมา 11 ปี ดูแลเว็บลูกค้ารวมกันกว่า 5,000 เว็บ และ VPS อีกราว 600 เครื่อง เคส "เว็บหาย" ที่ผ่านตาผมมีทุกแบบ — เผลอลบ, อัปเดตแล้วพัง, โดนแฮก, เซิร์ฟเวอร์เสีย, ไฟล์พัง บทความนี้ผมจะเล่าให้ฟังแบบเพื่อนคุยกับเพื่อน ว่า ทำไมยังไงก็ต้องมีวันได้ใช้ backup, กฎ 3-2-1 ที่มืออาชีพเขาใช้กัน (และทำไมเดี๋ยวนี้มันขยับเป็น 3-2-1-1-0), backup กับ snapshot ต่างกันยังไง, ต้อง backup อะไรบ้าง, ตั้ง backup อัตโนมัติใน DirectAdmin ยังไง, ทำไม "backup ที่ไม่เคยลองกู้ = ไม่มี backup", และคำว่า RPO/RTO ที่ฟังดูหรูแต่จริงๆ มันคือคำถามง่ายๆ สองข้อ

ตั้งใจอ่านให้จบนะครับ เพราะเรื่องนี้คือเรื่องที่ "ไม่เจ็บก็ไม่รู้สึก" — แต่วันที่รู้สึก มันมักจะสายไปแล้ว

ย้ำก่อนเหมือนทุกครั้ง: บทความนี้เป็น เนื้อหาเชิงป้องกันและการปกป้องเว็บของคุณเอง — สอนการสำรองและกู้คืนข้อมูลเว็บที่คุณเป็นเจ้าของ ไม่มีสอนวิธีโจมตีหรือยุ่งกับเว็บใครทั้งสิ้น

ส่วนที่ 1 — ทำไมยังไงคุณก็ต้องมีวันได้ใช้ backup

มีความเชื่อหนึ่งที่ผมอยากแก้ก่อนเลย คือหลายคนคิดว่า "เว็บผมไม่ได้ดังขนาดนั้น คงไม่มีอะไรหรอก" — แต่ความจริงคือ เว็บส่วนใหญ่ไม่ได้หายเพราะเรื่องดราม่าใหญ่โต มันหายเพราะเรื่องธรรมดาๆ ที่เกิดขึ้นทุกวันนี่แหละ ลองดูสาเหตุที่ผมเจอบ่อยที่สุด:

• เผลอลบเอง (human error) — นี่คืออันดับหนึ่งจริงๆ ไม่ใช่แฮกเกอร์ ลบโฟลเดอร์ผิด, drop ตารางฐานข้อมูลผิดตัว, เขียนทับไฟล์ตอนอัปเดต, ลูกค้าหรือทีมงานเข้าไปลบเองโดยไม่รู้ว่ามันสำคัญ — คนเราพลาดกันได้ทั้งนั้น
• อัปเดตแล้วพัง — อัปเดต WordPress core, ปลั๊กอิน, ธีม หรือ PHP เวอร์ชันใหม่ แล้วชนกัน จอขาว (white screen) เข้าหลังบ้านไม่ได้ บางทีปลั๊กอินสองตัวตีกันเองหลังอัปเดต
• โดนแฮก / โดนฝังมัลแวร์ — เว็บถูกฝังโค้ด เด้งไปเว็บพนัน หรือไฟล์ถูกเข้ารหัสเรียกค่าไถ่ (ransomware) ทางกู้ที่เร็วและสะอาดที่สุดคือย้อนกลับไปหา backup ก่อนวันโดน (เรื่องนี้ผมเขียนละเอียดไว้ที่ เว็บโดนแฮก)
• ฮาร์ดแวร์ / เซิร์ฟเวอร์เสีย — ดิสก์พัง (disk failure), RAID เสียพร้อมกัน, เครื่องดับแล้วไฟล์ระบบเสียหาย — ไม่มีเครื่องไหนในโลกที่การันตีว่าฮาร์ดแวร์จะไม่มีวันพัง
• ไฟล์/ฐานข้อมูลพัง (corrupt) — ไฟฟ้าดับกลางการเขียนข้อมูล ตารางฐานข้อมูล corrupt เปิดเว็บมาเจอ error เชื่อมต่อฐานข้อมูลไม่ได้ ทั้งที่ไม่มีใครไปแตะอะไรเลย

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

backup ไม่ใช่ของฟุ่มเฟือยสำหรับเว็บใหญ่ มันคือเข็มขัดนิรภัย — คุณคาดมันไว้ทุกวันโดยหวังว่าจะไม่ได้ใช้ แต่วันที่ได้ใช้ มันคือสิ่งเดียวที่อยู่ระหว่างคุณกับหายนะ

ส่วนที่ 2 — กฎ 3-2-1 ที่มืออาชีพใช้ (และทำไมเดี๋ยวนี้ขยับเป็น 3-2-1-1-0)

ทีนี้พอบอกว่า "ต้องมี backup" หลายคนก็ทำ — แต่ทำแบบที่พอถึงวันจริงกลับใช้ไม่ได้ เพราะเก็บผิดที่ กฎที่เป็นมาตรฐานสากลและจำง่ายที่สุดคือ กฎ 3-2-1 ครับ:

• 3 — มีข้อมูลอย่างน้อย 3 สำเนา นับตัวจริงที่ใช้งานอยู่เป็น 1 และ backup อีกอย่างน้อย 2 ชุด เพราะถ้ามีสำเนาเดียวแล้วมันพัง คุณก็จบ
• 2 — เก็บบนสื่อ/ที่เก็บอย่างน้อย 2 ชนิด ไม่ใช่กองรวมไว้ที่เดียวกันหมด เช่น ชุดหนึ่งอยู่บนเซิร์ฟเวอร์ อีกชุดอยู่บน cloud storage หรืออีกที่หนึ่งคนละระบบ
• 1 — มีอย่างน้อย 1 ชุดเก็บไว้นอกสถานที่ (offsite) คือไม่ได้อยู่บนเครื่องเดียวกับเว็บจริง ถ้าเครื่องที่วางเว็บพังหรือถูกยึด สำเนา offsite นี้คือตัวที่รอดและกู้กลับได้

ฟังดูไม่มีอะไรใช่ไหมครับ แต่จุดที่คนพลาดกันมากที่สุดคือข้อ "1" — เก็บ backup ไว้บนเซิร์ฟเวอร์เครื่องเดียวกับเว็บ

ผมขอย้ำตรงนี้หนักๆ เลย เพราะมันคือความเข้าใจผิดที่อันตรายที่สุดในเรื่อง backup: ถ้าคุณ backup เว็บแล้วเก็บไฟล์ backup ไว้บนเครื่องเดียวกัน วันที่ดิสก์พัง วันที่โดนแฮกทั้งเครื่อง วันที่เซิร์ฟเวอร์โดนยึด — เว็บกับ backup ของมันหายไปพร้อมกัน เหมือนคุณถ่ายเอกสารสำคัญไว้ แต่เก็บใบถ่ายไว้ในกระเป๋าใบเดียวกับตัวจริง พอกระเป๋าหาย ก็หายทั้งคู่ (เคสนี้ผมเจอบ่อยมากจนเขียนแยกเป็นบทความเต็มเรื่อง "มี backup แล้ว แต่เก็บที่เดียว ทำไมยังไม่พอ" ไว้ที่ SEC-09 — บทความนี้ผมจะโฟกัสที่ "ตั้งยังไงให้กู้ได้จริง" เป็นหลัก)

backup ที่ดีต้องอยู่ "คนละที่" กับสิ่งที่มันปกป้องเสมอ นี่คือหัวใจของคำว่า offsite และเป็นเหตุผลว่าทำไมแค่ "มี backup" ยังไม่พอ — มันต้องอยู่ถูกที่ด้วย

แล้วทำไมเดี๋ยวนี้เขาขยับเป็น 3-2-1-1-0?

เรื่องนี้แหละที่ผมอยากเพิ่มให้ เพราะโลกของ backup มันขยับไปไกลกว่า 3-2-1 แล้ว สาเหตุหลักคือ ransomware (มัลแวร์เรียกค่าไถ่) สมัยใหม่มันฉลาดพอจะตามไป "เข้ารหัส/ลบ" สำเนาสำรองที่เชื่อมต่ออยู่ได้ด้วย แปลว่าต่อให้คุณมี offsite แต่ถ้ามันยัง "เขียนทับ/ลบ/เข้ารหัสได้" ผ่านการเชื่อมต่อ มันก็ยังเสี่ยง วงการเลยขยายกฎเป็น 3-2-1-1-0 เพิ่มมาสองตัวท้าย:

• +1 = มีอย่างน้อย 1 สำเนาที่ "แก้ไข/ลบไม่ได้" (immutable) หรือตัดขาดจากระบบ (offline/air-gapped) — เป็นสำเนาที่ต่อให้ ransomware หรือแฮกเกอร์เข้าถึงเครื่องได้ ก็ไป "แตะ" มันไม่ได้ ลบไม่ได้ เขียนทับไม่ได้ ออกแบบมากันเคส "โดนแฮกแล้วของในเครื่องโดนล็อก/ลบหมด" โดยตรง
• +0 = ต้องมี "ศูนย์ error" ตอนกู้ คือต้องเคยลองกู้จริงแล้วผ่าน — backup ที่ไม่เคยทดสอบกู้ ถือว่ายังเชื่อไม่ได้ จนกว่าจะพิสูจน์ว่ากู้กลับมาได้ครบจริง (เดี๋ยวผมขยายข้อนี้เต็มๆ ในส่วนที่ 5)

ไม่ต้องจำตัวเลขเป๊ะก็ได้ครับ ขอแค่จับแก่นว่า offsite อย่างเดียวยังไม่พอถ้ามันถูกลบ/เข้ารหัสตามได้ — ควรมีสำเนาที่ "แตะไม่ได้" และต้อง "เคยลองกู้จริง" สองตัวท้ายนี้แหละที่แยก backup ที่ "ดูดี" ออกจาก backup ที่ "รอดจริงในวันโดน ransomware"

🔎 ไม่ใช่แค่ผมพูดเอง: หลัก backup พวกนี้เป็นสิ่งที่หน่วยงานความมั่นคงไซเบอร์ระดับชาติแนะนำตรงกัน — ฝั่งสหรัฐ CISA (หน่วยงานความมั่นคงไซเบอร์ฯ) แนะนำให้สำรองข้อมูลแบบ "อัตโนมัติสม่ำเสมอ + ผสมที่เก็บในเครื่องกับนอกเครื่อง + มีสำเนา offline + ทดสอบกู้คืนตามกำหนด" ส่วนฝั่งไทย NT ก็อธิบายกฎ 3-2-1 ไว้เป็นภาษาไทยชัดเจน (3 ชุด / 2 เทคโนโลยี / 1 ชุดนอก Data Center หรือเก็บแบบ offline) · พูดง่ายๆ คือสิ่งที่ผมกำลังเล่า ไม่ใช่ "สไตล์ของ PhalconHost" แต่เป็นมาตรฐานที่คนทั้งวงการยึดเหมือนกันหมด — ผมแค่เอามาทำให้มันเกิดขึ้นจริงกับเว็บคุณ

ส่วนที่ 3 — backup ≠ snapshot และต้อง backup "อะไรบ้าง"

มีอีกสองเรื่องเทคนิคที่ผมอยากให้เข้าใจให้ตรง เพราะมันทำให้คนนึกว่าตัวเองปลอดภัยทั้งที่ไม่:

backup ไม่ใช่ snapshot snapshot (เช่น snapshot ของ VPS) คือการ "จับภาพสถานะของเครื่องทั้งลูก ณ วินาทีนั้น" มันดีสำหรับย้อนเครื่องกลับเร็วๆ แต่มันมักเก็บอยู่บน storage ระบบเดียวกับเครื่อง และไม่ได้ออกแบบมาให้เก็บย้อนหลังยาวๆ หรือดึงเอาเฉพาะ "เว็บเดียว/ฐานข้อมูลเดียว" ออกมาได้ง่าย ส่วน backup จริงๆ คือการ "ก๊อปข้อมูลออกมาเป็นชุดที่หยิบกลับมาใช้ได้เอง" และควรถูกส่งไปเก็บ offsite พูดง่ายๆ คือ snapshot เหมาะกับ "ย้อนเครื่องทั้งลูกเร็วๆ" ส่วน backup เหมาะกับ "กู้ข้อมูลจริงในวันที่ทุกอย่างพัง" — อย่าเอา snapshot อย่างเดียวมาแทน backup (และที่สำคัญ snapshot ที่อยู่บนระบบเดียวกับเครื่อง มันก็ผิดข้อ "+1 แตะไม่ได้/offline" ของ 3-2-1-1-0 ที่เพิ่งคุยกัน)

Full vs Incremental backup

• Full backup = สำรองทุกอย่างทั้งหมดในรอบนั้น ข้อดีคือกู้ง่ายเพราะครบในชุดเดียว ข้อเสียคือกินพื้นที่และเวลา
• Incremental backup = หลังจาก full แล้ว รอบถัดไปเก็บเฉพาะ "ส่วนที่เปลี่ยนไป" ข้อดีคือเร็วและประหยัดพื้นที่ ทำถี่ๆ ได้ ข้อเสียคือเวลากู้ต้องมี full ตั้งต้นที่ดีก่อน แล้วต่อด้วย incremental เป็นทอดๆ

แนวที่ใช้งานจริงได้ดีคือผสมกัน — Full เป็นรอบใหญ่ (เช่นรายสัปดาห์) แล้วมี Incremental ถี่ๆ คั่นระหว่างนั้น (เช่นรายวัน) เพื่อให้ได้ทั้งความครบและความถี่ (DirectAdmin เองก็มีตัวเลือกทำ incremental + ส่งไปเก็บ remote ได้ เช่นผ่านเครื่องมือฝั่ง CLI เดี๋ยวพูดถึงในส่วนถัดไป)

ต้อง backup อะไรบ้าง (อย่าลืมข้อใดข้อหนึ่ง) นี่คือจุดที่คนพลาดบ่อยมาก — backup แค่ไฟล์เว็บแต่ลืมฐานข้อมูล แล้วพอกู้กลับ เว็บโล่งเป็นกระดาษเปล่า เพราะเนื้อหา WordPress ทั้งหมดอยู่ในฐานข้อมูล ต้องครบทั้งสี่อย่างนี้:

1. ไฟล์เว็บ (files) — ทั้งโค้ด, ธีม, ปลั๊กอิน, รูปภาพและไฟล์อัปโหลด (โฟลเดอร์ uploads)
2. ฐานข้อมูล (database) — หัวใจของเว็บไดนามิกอย่าง WordPress/WooCommerce บทความ ออเดอร์ ผู้ใช้ การตั้งค่า อยู่ในนี้หมด ขาดอันนี้ = กู้ไฟล์มาก็เป็นเว็บเปล่า (WordPress เองก็ย้ำเรื่องนี้ว่าฐานข้อมูลอยู่ "แยก" จากไฟล์ ต้อง export/dump ออกมาต่างหาก ไม่ได้ติดมากับการ copy ไฟล์เฉยๆ)
3. อีเมล (email) — ถ้าใช้อีเมลของโดเมน กล่องจดหมายลูกค้าก็ต้องสำรองด้วย ไม่งั้นเมลธุรกิจหายเกลี้ยง
4. การตั้งค่า (configuration) — ค่า DNS zone, cron jobs, ค่า account, การตั้งค่าโดเมน/ฐานข้อมูล ฯลฯ ที่ทำให้ทุกอย่างกลับมาทำงานได้เหมือนเดิม ไม่ใช่ต้องมานั่งตั้งใหม่ทีละอย่าง

ข่าวดีคือถ้าใช้ระบบ backup ระดับบัญชีของ DirectAdmin มันจะรวมทั้งสี่อย่างนี้ให้ในชุดเดียว ซึ่งกู้กลับมาได้ครบ — เดี๋ยวผมจะเล่าวิธีตั้งในส่วนถัดไป

ส่วนที่ 4 — ตั้ง backup อัตโนมัติใน DirectAdmin (ทำครั้งเดียว ทำงานเองทุกวัน)

หัวใจของ backup ที่เชื่อถือได้คือ "อัตโนมัติ" ครับ — เพราะ backup ที่ต้องอาศัยให้คนกดเองทุกวัน สุดท้ายมักจะลืม และมักจะลืมในวันที่จำเป็นที่สุดพอดี (นี่ก็คือเหตุผลที่ CISA ขึ้นต้นคำแนะนำด้วยคำว่า "อัตโนมัติสม่ำเสมอ" เลย) ถ้าคุณดูแลเว็บบน DirectAdmin นี่คือแนวทางตั้งให้มันทำงานเอง:

ระดับผู้ดูแลระบบ (Admin) — สำรองทั้งเซิร์ฟเวอร์เป็นรอบ ใน DirectAdmin เมนูฝั่ง Admin จะมีเครื่องมือ Admin Backup/Transfer และ System Backup สำหรับตั้งสำรองข้อมูลของบัญชีผู้ใช้ทั้งหมดบนเครื่องเป็นรอบ จุดที่ต้องตั้งให้ครบมีสามอย่าง:

• Schedule (รอบเวลา) — ตั้งให้รันอัตโนมัติ เช่น ทุกวันตอนกลางคืนที่คนใช้งานน้อย ระบบจะสร้าง cron job ให้อัตโนมัติเมื่อคุณกำหนดรอบ (ไม่ต้องไปเขียน cron เองด้วยมือ แต่เบื้องหลังมันคือ cron นั่นแหละ)
• What to back up (สำรองอะไร) — เลือกให้รวมไฟล์ + ฐานข้อมูล + อีเมล + การตั้งค่าของแต่ละบัญชี (ตามส่วนที่ 3)
• Where to store (เก็บที่ไหน) — อันนี้สำคัญที่สุด: เลือกส่งไป offsite DirectAdmin รองรับการส่ง backup ไปเก็บที่อื่นได้หลายแบบ เช่นผ่าน FTP/SFTP ไปยังเซิร์ฟเวอร์สำรองอีกเครื่อง หรือ remote server/cloud storage — อย่าเลือกเก็บไว้ Local (บนเครื่องเดียวกัน) อย่างเดียวเด็ดขาด ไม่งั้นก็ผิดกฎ 3-2-1 ข้อ offsite ที่เพิ่งคุยกันไป (และถ้าทำให้ปลายทาง remote นั้น "ลบทับยาก" ได้ด้วย ก็เข้าใกล้ข้อ "+1 แตะไม่ได้" ของ 3-2-1-1-0 อีกขั้น)

ระดับผู้ใช้ (User) — สำรองเฉพาะบัญชี/เว็บของตัวเอง ถ้าคุณเป็นเจ้าของบัญชีเอง ในเมนู User จะมี Create/Restore Backups ให้สร้าง backup ของเว็บ + ฐานข้อมูลตัวเองเป็นไฟล์เดียว ดาวน์โหลดเก็บไว้ที่อื่นได้ (นี่คือวิธีง่ายๆ ที่ช่วยให้คุณมีสำเนา offsite ในมือเองอีกชุด นอกเหนือจากที่ระบบทำให้)

กำหนดความถี่ (frequency) — backup บ่อยแค่ไหน? ขึ้นกับว่าข้อมูลเปลี่ยนบ่อยแค่ไหน:

• เว็บที่มีออเดอร์/คอมเมนต์/ข้อมูลเข้าทุกวัน (เช่นร้านค้า WooCommerce, เว็บข่าว) → อย่างน้อยวันละครั้ง หรือถี่กว่านั้นถ้าข้อมูลสำคัญมาก
• เว็บบริษัทที่นานๆ อัปเดตที → รายวันก็ยังดี เพราะต้นทุนการ backup ถูกกว่าวันที่ข้อมูลหายมาก

🔎 จุดที่อยากให้สังเกตเงียบๆ ตรงนี้: ความถี่ระดับ "รายวัน" เป็นเรื่องที่ควรเป็น "ค่ามาตรฐาน" ของการดูแลเว็บ — เพราะถ้า backup ทำแค่ อาทิตย์ละครั้ง แปลว่าวันที่เกิดเรื่อง คุณอาจเสียข้อมูลย้อนหลังได้ถึงเกือบหนึ่งสัปดาห์ (ออเดอร์/คอมเมนต์/บทความทั้งอาทิตย์) เก็บความรู้สึกนี้ไว้ เดี๋ยวเราจะวกกลับมาเรื่อง RPO ในส่วนที่ 6

เก็บกี่ชุด (retention) อย่าเก็บแค่ชุดเดียวแล้วเขียนทับทุกวัน เพราะถ้าเว็บโดนฝัง backdoor หรือข้อมูลพังเงียบๆ มาหลายวันก่อนคุณรู้ตัว backup ชุดล่าสุดก็อาจติดของเสียมาด้วย — ควรเก็บย้อนหลังหลายชุด/หลายวัน (เช่น รายวันเก็บ 7–14 ชุด, รายสัปดาห์เก็บอีกหลายสัปดาห์) เพื่อให้มี "จุดสะอาด" ให้เลือกย้อนกลับไปได้จริง การมีหลายเวอร์ชันให้เลือกนี่แหละที่ช่วยชีวิตเวลาเจอเคสแบบ "โดนแฮกมาตั้งแต่เมื่อไหร่ก็ไม่รู้"

ตั้งครบสามเรื่องนี้ครั้งเดียว — รอบเวลา, ส่ง offsite, เก็บหลายชุด — แล้วระบบจะทำงานเงียบๆ ให้คุณทุกคืนโดยไม่ต้องลุ้น

ส่วนที่ 5 — "Untested backup = No backup": backup ที่ไม่เคยลองกู้ ก็เหมือนไม่มี

นี่คือส่วนที่ผมอยากให้คุณขีดเส้นใต้ไว้ที่สุดในบทความนี้ เพราะมันคือบทเรียนราคาแพงที่คนทำเว็บเจ็บกันมาเยอะ และมันคือ "เลข 0" ในกฎ 3-2-1-1-0 ที่ผมเล่าไปในส่วนที่ 2 — 0 error ตอนกู้:

คุณไม่มีทางรู้ว่า backup ใช้ได้จริง จนกว่าคุณจะลองกู้มันกลับมา

ผมเจอเคสแบบนี้บ่อยกว่าที่คิด — ตั้ง backup ไว้ดูดี รันทุกวันสวยงาม ไฟล์กองเต็มไปหมด พอถึงวันเว็บพังจริง เปิดไฟล์ backup มา... เจอว่าไฟล์ไม่ครบ, ฐานข้อมูลไม่ได้ถูกรวมมาด้วย, ไฟล์เสียกู้ไม่ขึ้น, หรือ backup หยุดทำงานเงียบๆ มาสองเดือนแล้วโดยไม่มีใครรู้ ที่ผ่านมามันแค่ "ดูเหมือนทำงาน"

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

backup ที่ไม่เคยถูกทดสอบกู้ มันคือ ความอุ่นใจปลอมๆ ที่อันตรายกว่าการรู้ตัวว่าไม่มี backup เสียอีก เพราะคุณจะวางใจผิดที่ และไปรู้ความจริงเอาวันที่สายเกินแก้

เพราะฉะนั้น ทำสองอย่างนี้เป็นกิจวัตร:

1. ลอง restore จริงเป็นรอบ — ไม่ใช่แค่ดูว่ามีไฟล์ แต่เอา backup ไปกู้ขึ้นมาบนพื้นที่ทดสอบ (เช่นซับโดเมนทดสอบ หรือ staging) แล้วเปิดดูว่าเว็บกลับมาครบจริงไหม เนื้อหาอยู่ครบ ฐานข้อมูลต่อติด รูปไม่หาย — ทำสักไตรมาสละครั้งเป็นอย่างน้อย
2. เช็กว่า backup ยังรันอยู่จริง — เปิดดูว่าไฟล์ชุดล่าสุดเป็นของเมื่อวานจริงไหม ไม่ใช่ค้างอยู่ที่เดือนที่แล้ว

วิธี restore ใน DirectAdmin คร่าวๆ: ฝั่ง User เข้าเมนู Create/Restore Backups เลือกไฟล์ backup ที่ต้องการ แล้วสั่ง restore (เลือกได้ว่าจะกู้ทั้งบัญชี หรือเฉพาะบางส่วน เช่นเฉพาะฐานข้อมูล หรือเฉพาะไฟล์) ส่วนฝั่ง Admin ใช้ Admin Backup/Transfer ในโหมด Restore เพื่อกู้คืนทั้งบัญชีจากไฟล์ที่สำรองไว้ (รวมถึงดึงจาก remote/FTP ที่ส่งไปเก็บได้) — จุดสำคัญคือ ก่อนถึงวันฉุกเฉิน คุณควร "เคยกดปุ่มนี้มาก่อน" แล้ว ไม่ใช่มางมเอาตอนมือสั่น

จำประโยคนี้ไว้เลยครับ: มี backup ที่ไม่เคยลองกู้ = ยังไม่มี backup

ส่วนที่ 6 — RPO / RTO: คำหรูๆ ที่จริงๆ คือคำถามง่ายๆ สองข้อ

เวลาคนพูดเรื่อง backup แบบมืออาชีพ จะมีสองคำนี้โผล่มา ฟังดูน่ากลัวแต่จริงๆ มันคือคำถามภาษาคนสองข้อที่คุณควรตอบให้ได้:

RPO (Recovery Point Objective) = "คุณยอมเสียข้อมูลย้อนหลังได้กี่ชั่วโมง?" ถ้าเว็บพังตอนบ่ายสาม แล้ว backup ล่าสุดของคุณคือเมื่อเที่ยงคืน แปลว่าคุณจะเสียข้อมูลของวันนั้นไป 15 ชั่วโมง (ออเดอร์ คอมเมนต์ บทความที่เพิ่งเขียน) — ช่องว่างตรงนี้แหละคือ RPO ถ้าธุรกิจคุณรับการเสียข้อมูล 15 ชั่วโมงไม่ได้ คุณก็ต้อง backup ถี่ขึ้น (RPO เล็กลง = backup บ่อยขึ้น) นี่แหละคือเหตุผลที่ผมบอกในส่วนที่ 4 ว่า backup รายวันควรเป็นพื้นฐาน ไม่ใช่รายสัปดาห์ — เพราะ "รายสัปดาห์" แปลว่า RPO ของคุณคือเกือบ 7 วัน

RTO (Recovery Time Objective) = "คุณต้องกู้เว็บกลับให้เสร็จภายในกี่ชั่วโมง?" นับจากวินาทีที่เว็บล่ม คุณรับได้ว่าเว็บจะ down นานแค่ไหนก่อนจะกลับมาออนไลน์ — 1 ชั่วโมง? ครึ่งวัน? ยิ่งธุรกิจขายของออนไลน์ ทุกชั่วโมงที่เว็บล่มคือยอดที่หายและลูกค้าที่หนีไปคู่แข่ง RTO ที่สั้นต้องมาจากการที่ backup กู้ง่าย กู้เร็ว และคุณเคยซ้อมกู้มาแล้ว (วนกลับไปส่วนที่ 5) — และที่คนมักลืมคิด: RTO ยังขึ้นกับว่า "วันเว็บล่มตอนตี 2 มีใครที่รู้วิธีกู้อยู่ข้างคุณไหม" ไม่ใช่แค่มีไฟล์ backup เฉยๆ

พอตอบสองข้อนี้ได้ คุณจะออกแบบระบบ backup ได้ตรงกับธุรกิจจริง ไม่ใช่ทำมั่วๆ ตามที่คนอื่นบอก — เว็บร้านค้าที่ขายทั้งวันก็ต้อง RPO/RTO สั้น ส่วนเว็บโปรไฟล์บริษัทที่นิ่งๆ ก็ผ่อนได้

ส่วนที่ 7 — ข้อผิดที่เจอบ่อยที่สุด (เช็กดูว่าคุณติดข้อไหนไหม)

ทีนี้ผมรวบข้อผิดที่เจอซ้ำๆ มาให้เช็กเป็นข้อๆ เลย — ลองอ่านแล้วถามตัวเองตรงๆ ว่าเว็บที่คุณดูแลอยู่ตอนนี้ติดข้อไหนบ้าง:

• 🔴 ไม่ backup เลย — "เดี๋ยวค่อยทำ" ที่ไม่เคยมาถึงสักที จนถึงวันที่สายไปแล้ว
• 🔴 เก็บ backup ไว้บนเซิร์ฟเวอร์เดียวกับเว็บ — เครื่องพัง/โดนแฮก = หายพร้อมกันทั้งคู่ (ผิดกฎ 3-2-1 ข้อ offsite)
• 🔴 ไม่มีสำเนาที่ "แตะไม่ได้" (immutable/offline) — มี offsite แล้วก็จริง แต่ถ้า ransomware ยังเอื้อมไปลบ/เข้ารหัสตามได้ ก็ยังเสี่ยง (ผิดข้อ "+1" ของ 3-2-1-1-0)
• 🔴 ไม่เคยลองกู้ (untested) — ดูเหมือนมี backup แต่พอกู้จริงใช้ไม่ได้ และมารู้วันที่สายเกินไป (ผิดข้อ "0")
• 🔴 backup ถี่น้อยเกินไป — เก็บเดือนละครั้ง/อาทิตย์ละครั้ง พอพังจริงข้อมูลทั้งเดือน/ทั้งอาทิตย์หายเกลี้ยง (RPO ใหญ่เกินรับได้)
• 🔴 ลืม backup ฐานข้อมูล — สำรองแต่ไฟล์ พอกู้กลับเป็นเว็บเปล่าๆ เพราะเนื้อหาอยู่ในฐานข้อมูลที่ไม่ได้สำรอง
• 🔴 เก็บชุดเดียวแล้วเขียนทับทุกวัน — พอข้อมูลเสีย/โดนฝังของไม่ดีมาหลายวัน backup ก็ทับเอาของเสียมาหมด ไม่มีจุดสะอาดให้ย้อน
• 🔴 ใช้ snapshot อย่างเดียวแทน backup — แล้วลืมว่ามันมักอยู่บน storage ระบบเดียวกับเครื่อง ไม่ใช่ offsite

🧭 3M ของเรื่องนี้

ในข้อเหล่านี้ มี 3M ของคนทำเว็บซ่อนอยู่

🔵 (ความเข้าใจผิด)

("เก็บ backup บนเครื่องเดียวกันก็พอ", "มี backup แล้ว = สบายใจได้" และ "โฮสต์ต้องมี backup ให้แน่ๆ อยู่แล้ว ฉันไม่ต้องทำเอง")

🟠 (สิ่งที่ขาด)

(ไม่มีระบบ backup อัตโนมัติ + ไม่มีสำเนาที่แตะไม่ได้ + ไม่มีรอบทดสอบ restore)

🔴 (สิ่งที่พลาด)

(ไม่ backup เลย / ไม่เคยลองกู้ / เขียนทับชุดเดียว)

ส่วนที่ 8 — "backup ที่ทำถูกต้อง" ไม่ควรเป็นของเสริมที่ต้องจ่ายเพิ่ม

ขอแก้ (ความเข้าใจผิด) ข้อสุดท้ายที่ผมเกริ่นไว้ข้างบนหน่อยนะครับ เพราะมันสำคัญมากและคนพลาดเยอะ — หลายคนคิดว่า "โฮสต์ต้องมี backup ให้แน่ๆ อยู่แล้ว" แล้ววางใจ ไม่ทำสำเนาของตัวเองไว้เลย

ความจริงคือคำว่า "โฮสต์มี backup ให้" ของแต่ละเจ้า ไม่เท่ากันเลย — และตรงนี้ผมเล่าจากที่เห็นในตลาดจริงๆ (ไม่เอ่ยชื่อใคร เพราะผมไม่ได้มาเทียบว่าใครดีกว่าใคร แต่อยากให้คุณรู้ว่ามีกี่แบบ):

• บางเจ้า backup ให้จริง แต่มันเป็นบริการ "จ่ายเพิ่ม/ซื้อแยก" ถ้าคุณไม่ได้ซื้อก็ไม่มี — แล้วพอข้อมูลหายจริงค่อยมารู้ว่า "อ้าว ฉันไม่ได้ซื้อไว้นี่"
• บางเจ้ามีให้ แต่ทำ อาทิตย์ละครั้ง — สัปดาห์นึงโดนอะไรไป ข้อมูลก็หายไปเป็นอาทิตย์ (RPO ใหญ่อย่างที่คุยในส่วนที่ 6)
• บางเจ้าให้แค่ "เครื่องมือ/คู่มือ" ให้คุณไปกดสำรองเอง ซึ่ง default ของมันก็มักเก็บไว้ที่เดียวกับเว็บอีก — วนกลับมาปัญหาเดิมเป๊ะ

สังเกตไหมครับว่าตลาดส่วนใหญ่วาง backup ที่ "ทำถูกต้อง" ไว้เป็น ของเสริมที่ต้องจ่ายเพิ่ม หรือเป็นการบ้านที่โยนให้ลูกค้าไปทำเอง — กรอบความคิดมันเลยกลายเป็น "อยากปลอดภัย = จ่ายเพิ่ม หรือไปทำเอง" ทั้งที่ในมุมของผม การปกป้องข้อมูลลูกค้ามันควรเป็น มาตรฐานพื้นฐาน ที่มาพร้อมกับการฝากเว็บไว้ ไม่ใช่ของที่ "ถ้าไม่ติ๊กซื้อก็ไม่มี"

เพราะฉะนั้น อย่าเดาเอาเอง ให้รู้ให้ชัดว่าโฮสต์ของคุณ backup ให้ไหม ทำบ่อยแค่ไหน เก็บนอกที่ไหม ย้อนได้กี่วัน และวันเว็บโดนตอนตี 2 ใครเป็นคนช่วยกู้ แล้วทำสำเนาของตัวเองไว้อีกชั้นเสมอเป็นดีที่สุด (เรื่อง "โฮสต์มี backup ให้ พอไหม" ผมแยกเขียนเจาะลึกไว้แล้วที่ SEC-09 — 4 คำถามถามโฮสต์ก่อนวางใจ)

แล้ว PhalconHost ช่วยเรื่องนี้ยังไง?

ผมเล่าตรงๆ จากใจคนที่เคยเป็นคนทำเว็บนะครับ — เรื่อง backup ฟรีนี้ผมไม่ได้ทำเพราะอยากให้ดู "คุ้ม" หรือ "ได้ของแถม" แต่ผมทำเพราะผมเคยเป็นคนที่ยืนอยู่ในวันที่ข้อมูลหายมาก่อน และผมรู้ว่ามันเจ็บแค่ไหน

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

ผมเลยตัดสินใจตั้งแต่วันแรกที่เปิด PhalconHost ว่าจะเอาหลัก 3-2-1 ที่เล่าทั้งบทความมา "ทำให้เป็นค่ามาตรฐาน" ไม่ใช่ข้อความโฆษณา:

• Auto backup ฟรีให้ลูกค้าทุกคน เก็บแยก ไม่ใช่กองไว้ที่เดียวกับเว็บ — และเป็นมาตรฐาน ไม่ใช่ของเสริมที่ขายเพิ่ม เพราะผมเขียนเรื่องกฎ 3-2-1 มาทั้งบทความ ผมจะไม่ทำในสิ่งที่บอกคุณว่าอย่าทำ และผมไม่อยากให้การปกป้องข้อมูลของคุณ เป็นออปชันที่ "ถ้าไม่ติ๊กซื้อก็ไม่มี" — มันคือ ตาข่ายกันตกที่ควรมาพร้อมกับการฝากเว็บไว้ เป็นความรับผิดชอบพื้นฐานของคนที่ดูแลข้อมูลคนอื่น ไม่ใช่เรื่องของแถมราคาถูก
• DNA ของที่นี่คือ "ข้อมูลต้องกู้คืนได้แน่นอน" — ผมไม่ได้เน้นว่าเครื่องต้องสเปกแรงหรือทันสมัยที่สุด ผมเน้นที่ว่า วันมีปัญหาแล้วข้อมูลต้องกู้คืนมาได้ เพราะนั่นคือสิ่งเดียวที่สำคัญจริงในวันวิกฤต
• วันที่ติดจริง ทำเองไม่ไหว — "แจ้งมา เราจัดให้" ผมขอพูดตรงๆ ตามจริงนะครับ: รูปแบบบริการของเราคือคุณดูแลเว็บของคุณเองเป็นหลัก (คุณคือคนทำเว็บ คุณถนัดอยู่แล้ว) แต่ วันที่เว็บคุณหายแล้วคุณติดจริงๆ ทำเองไม่ได้ — ทักมาเล่าให้ผมฟังได้ ผมเป็น dev มา 20 ปี ผมช่วยดูให้ว่าควรดึง backup เวอร์ชันไหนถึงจะสะอาด (ไม่ติดมัลแวร์ที่ฝังมาก่อน) restore ยังไงให้ครบทั้งไฟล์ทั้งฐานข้อมูล — ผมไม่ได้บอกว่าผมจะนั่งกู้ให้ทุกเว็บทุกเคสแทนคุณเหมือนทีม managed เต็มรูปแบบนะครับ แต่ผมไม่ทิ้งให้คุณงมเองตอนมือสั่นแน่นอน เคสที่ช่วยได้ผมช่วย เคสที่ต้องลงมือด้วยกันผมก็อยู่ตรงนั้น นี่แหละคือความหมายของ "Dev ดูแล Dev" ในแบบของเรา

ตรงนี้ผมอยากพูดให้แฟร์ด้วยนะครับ — ถ้าคุณกำลังมองหาเจ้าที่รับ "ดูแลทุกอย่างให้หมด 24 ชม. แบบ managed เต็มรูป" ตั้ง-ดูแล-กู้ให้ทุกขั้นโดยคุณไม่ต้องแตะอะไรเลย ตรงนั้นเราไม่ได้ทำถึงขั้นนั้น และผมจะบอกคุณตรงๆ ตั้งแต่แรกดีกว่าให้คุณมาผิดหวังทีหลัง · แต่ถ้าคุณเป็นคนทำเว็บที่อยากดูแลเองได้ แค่อยากได้พื้นฐานที่ดี (auto backup เก็บแยกฟรีทุกคน) + มี dev ที่เข้าใจงานคุณคอยเป็นที่ปรึกษาและช่วยในวันที่ติดจริง — อันนี้แหละคือสิ่งที่เราทำได้ดี

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

11 ปีที่ผ่านมา ลูกค้าที่ย้ายมาหาผมเกือบทุกคนพูดประโยคเดียวกันว่า "ทำไมไม่ได้เจอคุณตั้งนานแล้ว" — เพราะที่นี่ Dev ดูแล Dev เรื่องสำรองข้อมูลและการกู้คืนเราดูแลพื้นฐานให้และอยู่ช่วยในวันจำเป็น คุณเอาเวลาไปโฟกัสกับงานลูกค้าของคุณ

ปิดท้าย

backup เป็นเรื่องที่น่าเบื่อจนกว่าจะถึงวันที่มันกลายเป็นฮีโร่ — และวันนั้นมักมาโดยไม่บอกล่วงหน้า ขอแค่คุณจำหลักของกฎ 3-2-1-1-0 ไว้ก็พอ: มีหลายสำเนา, เก็บ offsite ไม่ใช่ที่เดียวกับเว็บ, มีสำเนาที่ลบ/เข้ารหัสตามไม่ได้ (กัน ransomware), ทำอัตโนมัติจะได้ไม่ลืม, และลองกู้จริงเป็นรอบ (0 error) เท่านี้คุณก็จะเป็นคนทำเว็บที่นอนหลับสบายขึ้นมากในคืนที่เกิดเรื่อง

และอย่าลืม (ความเข้าใจผิด) ที่อันตรายที่สุด: อย่าหยุดคิดแค่คำว่า "มี backup" หรือ "โฮสต์มีให้แล้ว" — ให้ถามต่อว่า "วันเว็บหาย มันยังอยู่ไหม กู้ได้จริงไหม ถี่พอไหม และใครช่วยกู้"

ย้ำอีกครั้งว่าทั้งหมดนี้คือการ สำรองและกู้เว็บของคุณเอง — ไม่ใช่การไปยุ่งกับเว็บใคร

ถ้าตอนนี้คุณไม่แน่ใจว่าเว็บที่ดูแลอยู่มี backup ที่กู้ได้จริงหรือเปล่า เก็บถูกที่ไหม ถี่พอไหม เคยลองกู้ไหม — ทักไลน์มาเล่าให้ผมฟังได้เลยครับ เล่ามาคร่าวๆ ว่าตอนนี้คุณ backup ยังไงอยู่ เก็บไว้ที่ไหน เก็บกี่ชุด เดี๋ยวผมช่วยดูให้ว่าจุดไหนเสี่ยง ควรปรับตรงไหน — แม้คำตอบจะเป็น "ของคุณโอเคแล้ว ไม่ต้องย้ายมาก็ได้" ผมก็จะบอกตามนั้น คุยกับ Dev ตัวจริง ไม่ใช่บอท 🙂

หากคุณอ่านมาถึงตรงนี้แล้วยังคิดว่า "ข้อมูลของฉันหายไม่ได้เลยแม้แต่นาทีเดียว ธุรกิจนี้ซีเรียส ต้องมั่นใจ 100% เท่านั้น" ก็สามารถติดต่อมาสอบถามได้ครับ เราช่วยประเมินและแนะนำได้ว่า หากต้องการเป้าหมายระดับ "ไม่มีข้อมูลสูญหายเลยแม้แต่นาทีเดียว" ต้องวางระบบแบบไหน เพิ่ม replication, high availability, off-site backup และ monitoring ระดับใด และต้องมีต้นทุนหรือเงื่อนไขอะไรบ้าง เพื่อให้สิ่งที่ต้องการการันตีเป็นระบบที่ออกแบบ ตรวจสอบ และทดสอบได้จริง