Volume Shadow Copy (VSS): กลไกและงานปฏิบัติ — ทำไมซอฟต์แวร์สำรองจึงคัดลอกไฟล์ที่กำลังใช้อยู่ได้

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

ศูนย์กลางของคำตอบคือ Volume Shadow Copy Service (VSS) มันฝังใน Windows มากว่ายี่สิบปี และ Windows Server Backup, System Restore รวมถึงซอฟต์แวร์สำรองเชิงพาณิชย์เกือบทั้งหมด นั่งบนฐานเดียวกันนี้¹

บทความนี้มุ่งนักพัฒนาแอปธุรกิจที่ถูกขอให้เพิ่มฟีเจอร์ «คัดลอกไฟล์ที่กำลังใช้อยู่» และเจ้าหน้าที่สารสนเทศที่ดำเนินงานสำรองของไฟล์เซิร์ฟเวอร์กับพีซีงาน โดยยึดแหล่งปฐมภูมิ ณ สิงหาคม 2026 จัดตัวละครและกลไกของ VSS งานปฏิบัติด้วย vssadmin และเกณฑ์ว่านักพัฒนาควรยุ่งกับ VSS แค่ไหน ซีรีส์ «เชิงลึกของ Windows I/O» ดูภายใน Cache Manager กับ NTFS มาแล้ว บทความนี้เป็นภาคต่อ ว่าด้วยชั้น «สแนปช็อต» ที่แทรกอยู่เหนือ volume โดยตรง

1. สรุปก่อนเลย

• VSS คือชุดอินเทอร์เฟซ COM และบริการประสาน ที่ทำให้สำรอง volume ได้ขณะแอปยังเขียนอยู่ ฝังใน Windows ตั้งแต่ Windows XP²
• มีสามบทบาทบวกผู้ประสาน บริการ VSS เป็นตัวกลางระหว่าง ตัวร้องขอ (requester) ที่ขอสำเนาเงา (ซอฟต์แวร์สำรอง) ไรเตอร์ (writer) ที่รับประกันความสอดคล้องของข้อมูลฝั่งแอป (เช่น SQL Server) และ โปรไวเดอร์ (provider) ที่สร้างสแนปช็อตจริง¹
• โปรไวเดอร์ระบบมาตรฐานของ Windows ใช้คัดลอกเมื่อเขียน (copy-on-write) ไม่ได้ทำสำเนาทั้ง volume แต่ย้ายเฉพาะบล็อกที่ถูกเขียนทับหลังสแนปช็อต และเฉพาะเนื้อหาก่อนเขียน เข้าพื้นที่ส่วนต่าง (diff area) พื้นที่ส่วนต่างต้องอยู่บน volume NTFS¹
• จุดนิ่งถูกสร้างด้วยลำดับ «แช่แข็งไรเตอร์ (นานสุด 60 วินาที) → สร้างสแนปช็อต (ภายใน 10 วินาที) → ละลาย» หากเกินขีดเวลา การสร้างถูกยกเลิกแล้วตัวร้องขอลองใหม่¹
• คุณภาพของสำเนาเปลี่ยนตามว่าไรเตอร์ร่วมมือหรือไม่ สแนปช็อตที่ไร้ความร่วมมือของไรเตอร์เทียบเท่า «ดิสก์ ณ วินาทีที่ถูกถอดปลั๊ก» (สอดคล้องแบบ crash) ส่วนที่มีความร่วมมือได้โรลล็อกและฟลัชแคชแล้ว จึงเป็นสถานะสอดคล้องที่แอปเองรับประกันว่ากู้คืนได้ (สอดคล้องระดับแอปพลิเคชัน)³¹
• เครื่องมือตรวจสถานะปฏิบัติงานคือ vssadmin ใช้ list shadows / list writers / list shadowstorage ดูสถานะปัจจุบัน และ resize shadowstorage ปรับขีดพื้นที่ส่วนต่าง เมื่อพื้นที่ส่วนต่างหมด สำเนาเงาเก่าจะถูกลบเงียบ ๆ⁴⁵¹
• การฝังตัวร้องขอ VSS เข้าแอปของตนเองเป็นงานใหญ่ เป็น API เนทีฟบน COM ไม่มีแรปเปอร์ .NET ทางการ กรณีส่วนใหญ่ การลองใหม่ การปรับโหมดแชร์ หรือการหยุดช่วงสั้นก็พอ หากจำเป็นต้องใช้ VSS จริง คำตอบที่เป็นไปได้คือสคริปต์ DiskShadow (เฉพาะ Windows Server)⁶⁷
• สำเนาเงาไม่ใช่การสำรองข้อมูลในตัวเอง ส่วนต่างแบบคัดลอกเมื่อเขียนพึ่งบล็อกที่ยังไม่เสียของ volume ต้น จึงไร้พลังต่อความล้มเหลวที่เสียทั้ง volume ต้น เช่น ดิสก์พังหรือถูกขโมย ต้านแรนซัมแวร์ก็พึ่งไม่ได้ เพราะสำเนาเงาเองถูกลบได้ (หมวด 7.3) หรือพื้นที่ส่วนต่างหมดเพราะการเขียนทับจำนวนมาก (หมวด 7.4) จะมีความหมายเมื่อคู่กับการสำรองบนสื่ออื่น¹

2. ตั้งโจทย์ — ทำไมไฟล์ที่กำลังใช้อยู่จึงคัดลอกตามปกติไม่ได้

จุดตั้งต้นคือโหมดแชร์ไฟล์ของ Windows เมื่อเปิดไฟล์ใน Windows (CreateFile) คุณประกาศเป็นโหมดแชร์ (dwShareMode) ว่า จะอนุญาตให้โพรเซสอื่นทำอะไรได้บ้างขณะที่คุณเปิดอยู่ ขณะมีโพรเซสถือไฟล์เปิดในแบบที่ไม่อนุญาตการแชร์อ่าน โพรเซสที่มาเปิดเพื่ออ่านทีหลังจะล้มด้วย การละเมิดการแชร์ (ERROR_SHARING_VIOLATION, ข้อผิดพลาด 32)⁸ ใน .NET นี่คือ IOException ที่คุ้น («The process cannot access the file because it is being used by another process»)

ข้อสำคัญคือสิ่งนี้ ไม่ใช่บั๊ก แต่เป็นกลไกที่ถูกต้องเพื่อปกป้องข้อมูล หากไฟล์ที่กำลังถูกเขียนถูกอ่านกลางคัน ฝ่ายที่อ่านได้สถานะค้างคาที่เขียนค้าง หากกลไกการกีดกันถูกออกแบบอย่างไร อยู่ใน «พื้นฐานการกีดกันสำหรับการเชื่อมผ่านไฟล์ - แนวปฏิบัติล็อกไฟล์และการเคลมแบบอะตอมิก» การออกแบบการกีดกันคือฐานของการเชื่อมระหว่างแอป

แต่กลไกที่ถูกต้องนี้ชนกับการสำรองข้อมูลโดยพื้นฐาน

• กำแพงการละเมิดการแชร์: ไฟล์ที่ฐานข้อมูลหรือแอปธุรกิจเปิดค้าง อาจเปิดเป็นต้นทางคัดลอกไม่ได้ตั้งแต่ต้น
• กำแพงความสอดคล้อง: แม้เปิดได้ (เพราะอนุญาตการแชร์อ่าน) การคัดลอกก็ใช้เวลา ระหว่างคัดลอกแอปยังเขียนต่อ จึงเกิดได้ที่ครึ่งแรกกับครึ่งหลังของไฟล์สะท้อนคนละจุดเวลา หรือหลายไฟล์ (ไฟล์ข้อมูลกับล็อก เป็นต้น) คลาดกัน และดังที่เห็นในตอน «Cache Manager» การเขียนลงแคชในหน่วยความจำก่อน จึงดูแต่ไฟล์บนดิสก์แล้วยังไม่รับประกันว่าเป็นเนื้อหาล่าสุด
• กำแพงปฏิบัติงาน: «งั้นก็หยุดแอปแล้วคัดลอก» เป็นคำตอบที่ถูกต้องในหลักการ แต่ระบบธุรกิจหรือไฟล์เซิร์ฟเวอร์ที่เดินตลอด 24 ชั่วโมงยอมรับไม่ได้

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

3. ตัวละครของ VSS — ตัวร้องขอ ไรเตอร์ โปรไวเดอร์

โครงของ VSS แยกเป็นสามบทบาทกับบริการที่เป็นตัวกลาง¹

ความงามของการแบ่งงานนี้คือ สินค้าที่ไม่รู้จักกันยังร่วมมือได้ ซอฟต์แวร์สำรอง (ตัวร้องขอ) ไม่รู้โครงภายในของ SQL Server แต่ไรเตอร์ของ SQL Server แจ้งเป็นเมทาดาตาว่าไฟล์ใด (คอมโพเนนต์) ต้องสำรอง และจัดข้อมูลของตนเองรอบจุดนิ่ง ตัวร้องขอจึงสำรองอย่างสอดคล้องได้เพียงเดินตามนั้น¹⁹ ซอฟต์แวร์สำรองของบุคคลที่สามบน Windows เกือบทุกตัวเป็นตัวร้องขอ VSS¹

ในงานสารสนเทศ ช่วงที่ต้องคิดถึงสามบทบาทนี้จริง ๆ คือการแก้ปัญหา ว่าความล้มเหลวของการสำรองเป็นปัญหาตัวร้องขอ (ฝั่งซอฟต์แวร์) ไรเตอร์เฉพาะ (ฝั่งแอป) หรือโปรไวเดอร์ / พื้นที่ส่วนต่าง (ฝั่งโครงสร้าง) เปลี่ยนที่ที่ต้องดูทั้งก้อน (หมวด 5 และ 7)

4. กลไกสแนปช็อต — คัดลอกเมื่อเขียนกับ «จุดนิ่ง»

4.1. คัดลอกเมื่อเขียน — เก็บ «วินาทีนั้น» โดยไม่ทำสำเนาทั้ง volume

ได้ยินคำว่า «สแนปช็อต» แล้วนึกถึงการทำสำเนาทั้ง volume แต่วิธีที่โปรไวเดอร์ระบบมาตรฐานของ Windows ใช้จริงคือ คัดลอกเมื่อเขียน (copy-on-write) ณ วินาทีที่ถ่ายสแนปช็อต แทบไม่คัดลอกอะไร ภายหลัง เมื่อบล็อกบน volume ต้นกำลังจะถูกเขียนทับ เนื้อหาก่อนเขียนของบล็อกนั้นถูกย้ายเข้าพื้นที่ส่วนต่าง (diff area, ที่เก็บสำเนาเงา) ก่อนการเขียนทับจะเสร็จ แล้วจึงปล่อยให้เขียนผ่าน¹ การย้ายเกิดเฉพาะครั้งแรกที่แต่ละบล็อกถูกเขียนทับ การเขียนทับบล็อกที่ย้ายแล้วไม่ทำพื้นที่ส่วนต่างโตต่อ

เมื่อจะอ่าน «volume ตามที่เป็น ณ วินาทีนั้น» บล็อกที่ไม่เปลี่ยนอ่านจาก volume ต้น บล็อกที่เปลี่ยนอ่านจากพื้นที่ส่วนต่าง แล้วประกอบกัน เพราะคัดลอกเฉพาะส่วนที่เปลี่ยน การสร้างจึงทันที และพื้นที่ที่กินมีแค่ส่วนต่าง ด้านกลับคือ volume ที่ถูกเขียนหนักยิ่งกินพื้นที่ส่วนต่างเร็ว (ซึ่งจะกลับมาในหมวด 7) และพื้นที่ส่วนต่างอยู่บน volume NTFS ของเครื่องเดียวกับข้อมูลต้น¹ สิ่งที่รองรับกลไกนี้คือไฟล์คอมโพเนนต์ของโปรไวเดอร์ระบบ swprv.dll และไดรเวอร์ที่ดักจับ I/O ของ volume volsnap.sys¹ หากสนใจ «วิธีดักจับ» ของสแต็ก I/O ดู «ไดรเวอร์กรองและมินิฟิลเตอร์» ด้วย

ยังมีวิธีอื่น: คัดลอกเต็ม (full copy) ที่แยกมิเรอร์ออก และ redirect-on-write ที่เขียนการเปลี่ยนแปลงไป volume อื่น โปรไวเดอร์ฮาร์ดแวร์ใช้วิธีที่เหมาะกับอาร์เรย์จัดเก็บที่สุด¹

4.2. ลำดับการสร้างจุดนิ่ง — ประสานแช่แข็ง 60 วินาที สร้าง 10 วินาที

หากคัดลอกเมื่อเขียนคือ วิธีเก็บข้อมูล คุณค่าแท้ของ VSS อยู่ที่ สถานะของวินาทีใดถูกเก็บ — คือวิธีสร้างจุดนิ่ง การสร้างสำเนาเงาเดินดังนี้¹

flowchart TB
    accTitle: ลำดับการสร้างสำเนาเงา
    accDescr: ลำดับการสร้างสำเนาเงา สิ่งที่หยุดจริง ๆ คือไม่กี่วินาทีถึงไม่กี่สิบวินาที และการสำรองหลักทำกับสแนปช็อตทีหลัง
    R["ตัวร้องขอส่งคำขอสร้าง<br/>แจกแจงไรเตอร์และเก็บเมทาดาตา"] --> M["แต่ละไรเตอร์แจ้งเป้าหมายสำรอง<br/>(คอมโพเนนต์) เป็น XML"]
    M --> P["แต่ละไรเตอร์เตรียมข้อมูล<br/>โรลล็อก ฟลัชแคช ฯลฯ<br/>จัดสู่สถานะสอดคล้องที่กู้คืนได้"]
    P --> F["แช่แข็ง I/O เขียนของไรเตอร์<br/>(อ่านได้ นานสุด 60 วินาที)"]
    F --> FS["VSS ฟลัชบัฟเฟอร์ระบบไฟล์<br/>แล้วแช่แข็งระบบไฟล์"]
    FS --> C["โปรไวเดอร์สร้างสำเนาเงา<br/>(ภายใน 10 วินาที ช่วงนี้ I/O เขียนถูกแช่แข็ง)"]
    C --> T["ปล่อยระบบไฟล์ → ละลายไรเตอร์ (thaw)<br/>แอปกลับมาเขียนต่อ"]
    T --> B["ตัวร้องขอสำรองจากสำเนาเงา<br/>ใช้เวลาตามที่ต้องการ"]

ภาพ 1: ลำดับการสร้างสำเนาเงา สิ่งที่หยุดจริง ๆ คือไม่กี่วินาทีถึงไม่กี่สิบวินาที และการสำรองหลักทำกับสแนปช็อตทีหลัง

มีสามจุดที่ควรจำ

1. แอปหยุดเฉพาะวินาทีที่ใช้สร้างจุดนิ่ง การแช่แข็งจำกัดที่ 60 วินาที และการสร้าง (commit) โดยโปรไวเดอร์จำกัดที่ 10 วินาที หากเกินอย่างใดอย่างหนึ่ง การสร้างถูกยกเลิกแล้วตัวร้องขอลองใหม่¹ การสำรองหลักซึ่งอาจใช้หลายชั่วโมง รันกับสำเนาเงาอ่านอย่างเดียวที่เสร็จแล้ว ขณะแอปเดินต่อ
2. ระหว่างแช่แข็ง อ่านได้ หยุดเฉพาะ I/O เขียน¹
3. ระบบไฟล์ถูกแช่แข็งด้วย เพราะ VSS ฟลัชบัฟเฟอร์ระบบไฟล์ก่อนแช่แข็ง การเขียนที่ค้างในแคชและเมทาดาตาของระบบไฟล์จึงสะท้อนในสแนปช็อตตามลำดับที่สอดคล้อง¹

4.3. สอดคล้องแบบ crash กับสอดคล้องระดับแอปพลิเคชัน

นี่คือข้อแยกสำคัญที่กำหนดคุณภาพของการสำรอง

สำเนาเงาที่สร้าง โดยไร้ความร่วมมือของไรเตอร์ อยู่ในสถานะที่ศัพท์ของ Microsoft เรียก สอดคล้องแบบ crash (crash consistent) นิยามทางการคือ «สถานะดิสก์ที่เทียบเท่าสถานะที่จะพบหลังความล้มเหลวหายนะที่ปิดระบบอย่างฉับพลัน» และการกู้จากมันถูกอธิบายว่า «เทียบเท่าการรีสตาร์ตหลังการปิดฉับพลัน»³ ในฐานะระบบไฟล์มันไม่เสีย แต่ในมุมแอปคือ «วินาทีที่ถูกถอดปลั๊กขณะกำลังเขียน» ฐานข้อมูลที่มีกลไกกู้จากล็อกธุรกรรมมักกู้จากจุดนี้ได้ แต่ต้องรันการกู้ก่อน — เป็นเงื่อนไข ไม่ใช่โบนัส

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

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

5. คำสั่งปฏิบัติงาน — vssadmin กับ «รุ่นก่อนหน้า»

เครื่องมือที่เจ้าหน้าที่สารสนเทศใช้ตรวจสถานะ VSS ในงานจริงคือ vssadmin (รันจาก Command Prompt ที่ยกสิทธิ์) อ้างอิงคำสั่งปัจจุบันระบุว่า list shadows / list writers / delete shadows / resize shadowstorage ใช้ได้ทั้งไคลเอนต์และเซิร์ฟเวอร์⁴ อ้างอิงฝั่ง Windows Server เพิ่ม create shadow / list shadowstorage / list providers เป็นต้น⁵ พึงทราบว่า vssadmin จัดการได้เฉพาะสำเนาเงาที่โปรไวเดอร์ระบบสร้าง¹

หาก list writers แสดงไรเตอร์ในสถานะข้อผิดพลาด สิ่งที่ควรสงสัยไม่ใช่ตัว VSS แต่ แอปที่ให้ไรเตอร์นั้น ตรวจสถานะบริการของแอปเจ้าของและบันทึกเหตุการณ์ Application/System (หมวด 7)

/maxsize ของ resize shadowstorage ให้ระบุขีดพร้อมหน่วยอย่าง KB/MB/GB หากไม่ระบุ จะไม่มีขีดเลย ข้อที่ควรจำคือ เอกสารของ Microsoft ระบุชัดว่า การเปลี่ยนขีดที่เก็บ โดยเฉพาะการย่อ อาจทำให้สำเนาเงาหายได้เอง¹⁰ อย่าย่อขีดบน volume ที่อยากเก็บหลายรุ่นอย่างง่าย ๆ

5.1. ความสัมพันธ์กับ «รุ่นก่อนหน้า»

การเปิด สำเนาเงาของโฟลเดอร์ที่ใช้ร่วมกัน (Shadow Copies of Shared Folders) บนไฟล์เซิร์ฟเวอร์ ทำให้เก็บสำเนา ณ จุดเวลาของไฟล์บนแชร์เป็นระยะ ผู้ใช้กู้ไฟล์ที่ลบหรือเขียนทับจากรุ่นก่อนหน้าได้ โดยไม่ต้องพึ่งผู้ดูแล¹ นี่คือการประยุกต์ VSS ที่คุ้นที่สุด และลดภาระเฮลป์เดสก์ได้อย่างชัวร์

แต่มีขีด สำเนาเงาของโปรไวเดอร์ระบบสูงสุด 512 ต่อ volume ในนั้นฟีเจอร์สำเนาเงาของโฟลเดอร์ที่ใช้ร่วมกันเก็บสูงสุด 64 โดยค่าเริ่มต้น (เปลี่ยนได้ด้วยค่ารีจิสทรี MaxShadowCopies)¹ และดังที่กล่าวตั้งแต่หมวดถัดไป หากพื้นที่ส่วนต่างขาด รุ่นเก่าถูกลบอัตโนมัติ ปลอดภัยที่สุดคือเข้าใจว่า «เก็บกี่รุ่นจริง» ถูกตัดสิน ไม่ใช่ด้วยจำนวนที่ตั้ง แต่ด้วยปริมาณที่ถูกเขียนและขนาดพื้นที่ส่วนต่าง

6. มุมนักพัฒนา — แอปของตนเองต้องใช้ VSS หรือไม่

ต่อจากนี้เป็นมุมนักพัฒนา เมื่อถูกขอให้ «เพิ่มฟีเจอร์สำรองที่คัดลอกไฟล์ได้แม้กำลังใช้อยู่» ควรเข้าหา VSS อย่างไร

6.1. การเขียนตัวร้องขอเองเป็นงานใหญ่

API ของ VSS ทั้งตัวร้องขอและไรเตอร์ ถูกให้เป็น อินเทอร์เฟซ COM และ C++ (แกนของตัวร้องขอคือ IVssBackupComponents)⁶ ไม่มีแรปเปอร์ .NET ทางการ และต้องอิมพลีเมนต์ให้ถูกตั้งแต่เก็บเมทาดาตาของไรเตอร์ จัดการชุดสแนปช็อต จนถึงเก็บกวาดหลังข้อผิดพลาด จึงไม่ใช่สิ่งที่เสียบเป็นฟีเจอร์หนึ่งของแอปธุรกิจได้ง่าย ๆ ในการประมาณงานรับจ้างของเรา «สร้างตัวร้องขอ VSS» ถูกจัดเป็นรายการแยกต่างหาก

คำตอบที่เป็นจริงมีสองทาง หนึ่ง ปล่อยให้ซอฟต์แวร์สำรองที่รองรับ VSS ที่มีอยู่ทำ สอง บน Windows Server ขับ DiskShadow จากสคริปต์ DiskShadow คือตัวร้องขอ VSS ที่มากับ OS นอกโหมดโต้ตอบยังมีโหมดสคริปต์ (diskshadow /s script.txt) และสคริปต์เดียวครอบการสร้างสำเนาเงา การเปิดเป็นอักษรไดรฟ์ (expose) การรันแบตช์ที่คัดลอก (exec) และการเก็บกวาดหลังจบ⁷¹ คุณประกอบลำดับ «สร้างสำเนาเงา → ดึงไฟล์ออกด้วยตรรกะคัดลอกของตนเอง → ลบ» ได้โดยไม่เขียน COM สักบรรทัด อย่างไรก็ตาม DiskShadow มีเฉพาะ Windows Server ไม่รวมในรุ่นไคลเอนต์¹ หากพีซีไคลเอนต์อยู่ในขอบความต้องการ ข้อเท็จจริงนี้เพียงอย่างเดียวก็เอนไปทางรับซอฟต์แวร์สำรองที่มีอยู่

6.2. จำเป็นต้องใช้ VSS ตั้งแต่ต้นหรือไม่ — ตารางตัดสินใจ

จากประสบการณ์ คำขอ «คัดลอกไฟล์ที่กำลังใช้อยู่» ส่วนใหญ่แก้ได้โดยไม่ใช้ VSS จัดระดับความต้องการให้ชัดก่อนเลือกเครื่องมือ

6.3. แอปของตนเองควรลงทะเบียนไรเตอร์หรือไม่

คำถามกลับทิศก็ควรจัดให้ชัด: แอปธุรกิจของตนเองควรให้ไรเตอร์ VSS หรือไม่ หากเขียนไรเตอร์ ข้อมูลของแอปคุณจะถูกสำรองแบบสอดคล้องระดับแอปพลิเคชัน ไม่ว่าลูกค้าใช้ซอฟต์แวร์สำรองตัวใด ยังมีกลไกเบากว่าไรเตอร์ปกติ คือ express writer (IVssExpressWriter) แต่สิ่งที่ทำคือ ลงทะเบียนเมทาดาตาที่ประกาศ ว่าไฟล์ใดรวมหรือตัดออก⁶ ไม่ได้รับแจ้งแช่แข็ง/ละลาย จึง ไม่สามารถ หยุดการเขียนของแอปให้ตรงกับการสร้างสแนปช็อต express writer เหมาะเฉพาะเมื่อคู่กับการออกแบบที่เก็บที่ไม่เสียแม้ถูกจับกลางการเขียน (คือสอดคล้องแบบ crash ก็พอ) หากต้องการประสานที่จุดนิ่งจริง ต้องอิมพลีเมนต์ไรเตอร์เต็ม

กระนั้น หลักตัดสินง่าย

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

7. กับดัก — สี่เรื่องที่กระทบงานจริง

7.1. VSS ไม่ใช่การสำรองข้อมูลในตัวเอง

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

7.2. ข้อผิดพลาดของไรเตอร์เป็นปัญหาฝั่งแอป

เมื่อซอฟต์แวร์สำรองล้มด้วย «ข้อผิดพลาด VSS» ให้เริ่มจากระบุว่าไรเตอร์ใดล้ม ด้วย vssadmin list writers เพราะไรเตอร์โดยสาระเป็นส่วนประกอบของแอป (หรือส่วนประกอบ Windows)¹ สนามหลักของการหาสาเหตุคือสถานะบริการของแอปนั้นกับบันทึกเหตุการณ์ หากถูกหน้าตา «ข้อผิดพลาดจากซอฟต์แวร์สำรอง» ลากไปแล้วขุดแต่ซอฟต์แวร์สำรอง จะอ้อม แบบทั่วไปของการแคบผู้ต้องสงสัยจากข้อเท็จจริงที่สังเกตได้ อยู่ใน «เมื่อได้รับช่วงระบบที่ไม่มีซอร์สและไม่มีเอกสาร — คู่มือปฏิบัติเพื่อเดินเครื่องต่อ»

7.3. แรนซัมแวร์มาลบสำเนาเงา

นี่คือข้อเท็จจริงที่ควรรู้ในฐานะข้อพิจารณาป้องกัน มักอยากหวังว่าหากย้อนด้วยรุ่นก่อนหน้าได้ ก็จะกู้ได้แม้โดนแรนซัมแวร์ — แต่ เป็นที่รู้กันกว้างว่าแรนซัมแวร์จำนวนมากลบสำเนาเงาก่อนหรือหลังเข้ารหัส โดยเจาะจงเพื่อตัดทางกู้นี้ การลบสำเนาเงาทำได้ด้วยคำสั่งที่ถูกกฎหมายตราบมีสิทธิ์ผู้ดูแล จึงเป็นแนวสุดท้ายต้านผู้โจมตีที่เข้ามาแล้วไม่ได้ เสาของมาตรการจึงเป็น: (1) วางสำเนาเงาเป็น «มีแล้วเร็ว» ไม่ใช่ «ส่วนของแผนกู้»; (2) ถือ สำรองออฟไลน์ที่อื่น ที่ผู้โจมตีไปไม่ถึงแยกต่างหาก; และ (3) อย่าให้สิทธิ์ผู้ดูแลแกบัญชีที่ใช้เดินงานประจำ สำหรับการป้องกันทั้งวงจรชีวิตพีซี รวมสำรอง การเข้ารหัส และการทิ้ง ดู «คู่มือปฏิบัติ BitLocker — เริ่มเข้ารหัสไดรฟ์จากการจัดการคีย์กู้คืน» และ «สิ่งที่ควรทำก่อนทิ้งพีซี Windows — รายการตรวจการลบข้อมูล ยกเลิกบัญชี และการสำรอง» ด้วย

7.4. เมื่อพื้นที่ส่วนต่างหมด รุ่นเก่าจะหายไปเงียบ ๆ

ดังที่เห็นในหมวด 4 คัดลอกเมื่อเขียนกินพื้นที่ส่วนต่างเฉพาะเมื่อแต่ละบล็อกถูกเขียนทับ ครั้งแรก หลังถ่ายสแนปช็อต การเขียนทับบล็อกที่ย้ายแล้วกี่ครั้งก็ไม่เพิ่มการกิน ดังนั้นปริมาณที่ถูกกินไม่ได้ตัดสินด้วย «เขียนกี่ครั้ง» แต่ด้วย «ช่วงบล็อกที่ถูกเขียนทับกว้างแค่ไหน นับแต่สแนปช็อตที่ยังถืออยู่» และ เมื่อพื้นที่ส่วนต่างชนขีด สำเนาเงาของ volume นั้นถูกลบจากเก่าสุดก่อน¹ ไม่มีอะไรแจ้งผู้ใช้แบบโต้ตอบ จึงมักรู้เมื่อ «น่าจะย้อนไปรุ่นสัปดาห์ก่อนได้» กลับไม่ได้แล้ว แต่ก็ไม่ไร้เสียงทั้งหมด: บันทึก System บันทึกเหตุการณ์จากแหล่ง volsnap (รหัส 25 เมื่อสำเนาถูกลบเพราะคืนพื้นที่ส่วนต่างไม่ได้, 35/36 เมื่อการขยายล้มหรือถูกยกเลิกหลังชนขีด เป็นต้น) นอกการตรวจเป็นระยะ การใส่เหตุการณ์ volsnap เหล่านี้ในการเฝ้าดูและเตือน ทำให้รู้การสูญเสียเร็ว เหตุที่งานจำนวนมากที่ «กวาดทั้ง volume» — อัปเดตไฟล์ยกชุด การแปลงเป็นชุด การจัดเรียงข้อมูล — กินพื้นที่ส่วนต่างรวดเดียว มาจากสมบัตินี้พอดี: การกินถูกตัดสินด้วยช่วงบล็อกที่ถูกเขียนทับ ตรวจเป็นประจำว่าจำนวนรุ่นที่ถือยังตรงความต้องการทางธุรกิจ («นานสุดกี่วันกว่าใครจะรู้ว่าลบพลาด») เทียบกับการใช้ที่ vssadmin list shadowstorage แสดง และขยายขีดหากต้อง⁵¹⁰

8. สรุป

• เหตุที่ไฟล์ที่กำลังใช้อยู่คัดลอกตามปกติไม่ได้คือเรื่องการละเมิดการแชร์และความสอดคล้อง และนั่นคือกลไกที่ถูกต้องเพื่อปกป้องข้อมูล VSS คือคำตอบระดับ OS ต่อ «อยากได้สำเนาที่สอดคล้องโดยไม่หยุดแอป»
• VSS เป็นเฟรมเวิร์กที่บริการ VSS เป็นตัวกลางระหว่างสามบทบาท — ตัวร้องขอ (ขอ) ไรเตอร์ (รับประกันความสอดคล้อง) โปรไวเดอร์ (สร้าง) — ให้ซอฟต์แวร์สำรองกับแอปธุรกิจที่ไม่รู้จักกันร่วมมือได้
• โปรไวเดอร์ระบบใช้คัดลอกเมื่อเขียน และจุดนิ่งถูกสร้างผ่าน «แช่แข็งไรเตอร์ (นานสุด 60 วินาที) → สร้าง (ภายใน 10 วินาที) → ละลาย» หากไรเตอร์ไม่ร่วมมือได้สอดคล้องแบบ crash หากร่วมมือได้สอดคล้องระดับแอปพลิเคชัน
• ตรวจสถานะปฏิบัติงานด้วย vssadmin (list shadows / list writers / list shadowstorage) สงสัยฝั่งแอปเมื่อไรเตอร์ผิด และดูการใช้พื้นที่ส่วนต่างเป็นประจำ
• นักพัฒนาควรใช้ตารางตัดสินใจตรวจก่อนว่าการลองใหม่ โหมดแชร์ หน้าต่างหยุด หรือการออกแบบเชื่อม แก้ได้หรือไม่ แล้วหันมา VSS เฉพาะเมื่อจำเป็นจริง ๆ สคริปต์ DiskShadow (เฉพาะ Server) หรือสินค้าที่มีอยู่คือคำตอบที่เป็นจริง นำหน้าการสร้างเอง
• สำเนาเงาไม่ใช่การสำรอง เป็นเพียงส่วนต่างที่พึ่งบล็อกที่ยังไม่เสียของ volume ต้น ไร้พลังต่อการสูญเสีย volume ต้นอย่างดิสก์พัง และพึ่งไม่ได้ต่อแรนซัมแวร์เช่นกัน เพราะสำเนาเงาถูกลบได้หรือพื้นที่ส่วนต่างหมดได้ จับคู่กับสำรองออฟไลน์ที่อื่น

บทความที่เกี่ยวข้อง

• พื้นฐานการกีดกันสำหรับการเชื่อมผ่านไฟล์ - แนวปฏิบัติล็อกไฟล์และการเคลมแบบอะตอมิก
• เชิงลึกของ Windows I/O (ตอนที่ 4) — Cache Manager: WriteFile ของคุณไปถึงดิสก์เมื่อใด
• เชิงลึกของ Windows I/O (ตอนที่ 5) — ภายใน NTFS: เข้าใจระบบไฟล์ผ่าน MFT
• เมื่อได้รับช่วงระบบที่ไม่มีซอร์สและไม่มีเอกสาร — คู่มือปฏิบัติเพื่อเดินเครื่องต่อ
• คู่มือปฏิบัติ BitLocker — เริ่มเข้ารหัสไดรฟ์จากการจัดการคีย์กู้คืน
• สิ่งที่ควรทำก่อนทิ้งพีซี Windows — รายการตรวจการลบข้อมูล ยกเลิกบัญชี และการสำรอง

ด้านให้คำปรึกษาที่เกี่ยวข้อง

KomuraSoft LLC รับออกแบบและพัฒนาแอปธุรกิจที่มีฟีเจอร์อย่าง «คัดลอกไฟล์ที่กำลังใช้อยู่» และการสำรองข้อมูล สอบสวนสาเหตุของการละเมิดการแชร์รอบการเชื่อมไฟล์และความล้มเหลวของการสำรอง (ข้อผิดพลาดไรเตอร์ VSS) รวมถึงจัดระเบียบการดำเนินงานสำรองไฟล์เซิร์ฟเวอร์และการจัดการรุ่น เริ่มจากคำถามว่า VSS เป็นความต้องการที่ถูกตั้งแต่ต้นหรือไม่ก็ได้

• พัฒนาแอป Windows
• ตรวจสอบบั๊กและหาสาเหตุ
• ที่ปรึกษาเทคนิคและรีวิวการออกแบบ
• ติดต่อเรา

ลิงก์อ้างอิง

บทความที่เกี่ยวข้อง

บทความล่าสุดที่มีแท็กเดียวกัน เพื่อเจาะลึกหัวข้อใกล้เคียง

หัวข้อที่เกี่ยวข้อง

หน้าเหล่านี้วางหัวข้อไว้ในบริบทที่กว้างขึ้นของบริการและการตัดสินใจ

บริการที่เกี่ยวข้องกับหัวข้อนี้

บทความนี้เกี่ยวข้องโดยตรงกับบริการต่อไปนี้

คำถามที่พบบ่อย

คำถามที่มักพบในการปรึกษาเกี่ยวกับหัวข้อของบทความนี้

มีสำเนาเงาแล้ว ไม่ต้องสำรองข้อมูลอีกหรือไม่?

ยังต้องสำรองอยู่ สำเนาเงาที่โปรไวเดอร์ระบบมาตรฐานของ Windows สร้างเป็นส่วนต่างแบบคัดลอกเมื่อเขียน ไม่ได้ถือ «สำเนาสมบูรณ์ ณ เวลานั้น» แยกไว้ต่างหาก แต่พึ่งบล็อกบน volume ต้นที่ยังไม่ถูกเขียนทับ แม้ย้ายพื้นที่ส่วนต่าง (diff area) ไป volume อื่น หาก volume ต้นหายก็กู้คืนไม่ได้เช่นกัน จึงไร้พลังต่อเหตุที่เสียทั้ง volume ต้น เช่น ดิสก์พัง พีซีถูกขโมยหรือหาย สำหรับแรนซัมแวร์ การเขียนเข้ารหัสเองย้ายบล็อกก่อนเขียนไปพื้นที่ส่วนต่าง แต่ในการโจมตีจริง สำเนาเงามักถูกลบ หรือพื้นที่ส่วนต่างหมดเพราะการเขียนทับจำนวนมาก จึงพึ่งไม่ได้ เอกสารของ Microsoft ก็แยกสองสิ่งนี้ชัด: ข้อมูลที่คัดลอกจากสำเนาเงาไปสื่ออย่างเทปคือการสำรอง และหลังคัดลอกแล้วจะลบสำเนาเงาเองก็ได้ สำเนาเงาคือ «จุดนิ่งสำหรับใช้สำรอง» และ «ทางกู้จากความผิดพลาดเล็กน้อยอย่างเร็ว» ไม่ใช่ตัวแทนของการสำรองบนสื่ออื่นและที่อื่น

อยากให้แอปธุรกิจของตนเองคัดลอกไฟล์ที่กำลังใช้อยู่ ควรใช้ VSS หรือไม่?

ทางที่เป็นจริงอันดับแรกคือหาทางเลี่ยงไม่ให้ต้องใช้ VSS ตัวร้องขอของ VSS ต้องเขียนด้วย API เนทีฟบน COM (เช่น IVssBackupComponents) และไม่มีแรปเปอร์ .NET ทางการ การฝังเข้าแอปของตนเองจึงเป็นงานใหญ่ หากความต้องการเป็นเพียง «อ่านไฟล์ที่โพรเซสอื่นกำลังเขียนได้สักวันก็พอ» การลองใหม่ก็พอ หาก «แอปอีกฝ่ายอนุญาตการแชร์อ่าน» การเปิดด้วยโหมดแชร์ที่ตรงกันก็พอ หากหยุดแอปได้ช่วงสั้น การคัดลอกตอนว่างของงานคือทางง่ายและชัวร์ที่สุด VSS มีที่ยืนเมื่อความต้องการคือ «ทำสำเนาชุดข้อมูลทั้งก้อนจากแอปที่หยุดไม่ได้ ในสถานะที่สอดคล้อง» และถึงตอนนั้นก็ให้ดูซอฟต์แวร์สำรองที่รองรับ VSS หรือสคริปต์ DiskShadow ก่อนลงมืออิมพลีเมนต์เอง

vssadmin list writers แสดงไรเตอร์อยู่ในสถานะข้อผิดพลาด ควรทำอย่างไร?

หลักคือสอบสวนในฐานะปัญหาฝั่งแอปพลิเคชันที่ถือไรเตอร์นั้น vssadmin list writers แสดงไรเตอร์ที่ลงทะเบียนพร้อมสถานะ จึงเริ่มจากระบุว่าไรเตอร์ใดล้มเหลว ไรเตอร์มาจากแอปอย่าง SQL Server หรือส่วนประกอบของ Windows (เช่น รีจิสทรี) ดังนั้นสาเหตุเกือบทั้งหมดอยู่ที่สถานะบริการของแอปเจ้าของ หรือข้อผิดพลาดในบันทึกเหตุการณ์ Application/System ไม่ใช่ที่ตัว VSS เอง รีสตาร์ตบริการที่เกี่ยวข้องและแคบเงื่อนไขที่ทำซ้ำได้ หากยังไม่หาย ให้ดูข้อมูลสนับสนุนของแอปนั้น ขั้นตอนเดียวกันนี้คือการแยกเบื้องต้นที่ถูกเมื่อซอฟต์แวร์สำรองล้มด้วยข้อผิดพลาด VSS

สำเนาเงาหายไปโดยไม่รู้ตัว ทำไม?

สาเหตุที่พบบ่อยสุดคือพื้นที่ส่วนต่าง (ที่เก็บสำเนาเงา) เต็ม ในแบบคัดลอกเมื่อเขียน เนื้อหาของแต่ละบล็อกถูกย้ายเข้าพื้นที่ส่วนต่างเมื่อถูกเขียนทับครั้งแรกหลังถ่ายสแนปช็อต ยิ่งช่วงบล็อกที่ถูกเขียนทับกว้าง พื้นที่ส่วนต่างยิ่งถูกกิน เมื่อถึงขีดที่กำหนด Windows ลบสำเนาเงาเก่าสุดก่อนเพื่อคืนพื้นที่ การลบเกิดเงียบ ๆ โดยไม่แจ้งผู้ใช้แบบโต้ตอบ จึงมักรู้เมื่อใครสักคนคาดว่าจะกู้รุ่นสัปดาห์ก่อนจาก «รุ่นก่อนหน้า» แล้วพบว่าไม่มี (บันทึก System มีเหตุการณ์จากแหล่ง volsnap เช่น รหัส 25 จึงเฝ้าดูไว้จะรู้ทัน) ตรวจการใช้และขีดด้วย vssadmin list shadowstorage และขยายขีดด้วย vssadmin resize shadowstorage หากจำเป็น แต่พึงจำว่าการเปลี่ยนขีด โดยเฉพาะการย่อ อาจทำให้สำเนาเงาหายได้เช่นกัน

«รุ่นก่อนหน้า» ของ File Explorer สัมพันธ์กับ VSS อย่างไร?

«รุ่นก่อนหน้า» คือทางเข้าหนึ่งในการดึงรุ่นเก่าของไฟล์จากสำเนาเงาที่ VSS สร้าง บนไฟล์เซิร์ฟเวอร์ การเปิด «สำเนาเงาของโฟลเดอร์ที่ใช้ร่วมกัน» (Shadow Copies of Shared Folders) ทำให้ถ่ายสำเนาเงาตามตาราง และผู้ใช้คลิกขวาไฟล์บนโฟลเดอร์แชร์แล้วกู้เองจากรุ่นก่อนหน้าได้ ข้อดีคือผู้ใช้แก้การลบหรือเขียนทับพลาดได้โดยไม่ต้องพึ่งผู้ดูแล แต่เพราะชั้นล่างคือสำเนาเงา จำนวนรุ่นที่เก็บได้มีขีด และหากพื้นที่ส่วนต่างขาด รุ่นเก่าจะหายก่อน ตามที่กล่าวในเนื้อบท «มีรุ่นก่อนหน้า» ไม่ได้แปลว่า «ไม่ต้องสำรองข้อมูล»

โปรไฟล์ผู้เขียน

หน้าแนะนำผู้เขียนบทความ

Go Komura

ผู้แทนของ KomuraSoft LLC

เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ Windows ที่ปรึกษาเทคนิค และการตรวจสอบบั๊ก โดยเฉพาะโปรเจกต์ที่มีระบบเดิมและบั๊กที่ทำซ้ำได้ยาก