Volume Shadow Copy (VSS): cơ chế và thực hành — vì sao phần mềm sao lưu copy được tệp đang dùng

«Tôi định copy tệp ứng dụng khác đang mở, thì bị bảo tiến trình không truy cập được tệp vì tiến trình khác đang dùng.» «Người ta yêu cầu sao lưu thư mục dữ liệu mà không dừng hệ thống lõi.» «Vì sao phần mềm sao lưu copy bình thản được tệp cơ sở dữ liệu đang dùng?» — Dù bạn phát triển ứng dụng nghiệp vụ hay vận hành file server, đây là câu hỏi sớm muộn cũng gặp.

Trung tâm câu trả lời là Volume Shadow Copy Service (VSS). Nó được gắn vào Windows hơn hai mươi năm, và Windows Server Backup, System Restore, cùng hầu hết sản phẩm sao lưu thương mại đều đứng trên cùng nền tảng này.¹

Bài viết hướng tới nhà phát triển ứng dụng nghiệp vụ bị yêu cầu thêm chức năng «copy tệp đang dùng», và nhân sự CNTT vận hành sao lưu file server cùng PC nghiệp vụ. Dựa trên nguồn gốc tính đến tháng 8 năm 2026, bài sắp xếp các vai và cơ chế của VSS, thực hành vận hành hàng ngày bằng vssadmin, và ranh giới nhà phát triển nên dính vào VSS đến đâu. Loạt «Độ sâu I/O Windows» đã nhìn vào Cache Manager và NTFS; bài này là phần tiếp, phủ lớp «snapshot» nằm ngay trên volume.

1. Kết luận trước

• VSS là tập giao diện COM và dịch vụ điều phối, giúp sao lưu một volume trong lúc ứng dụng vẫn ghi vào đó. Nó được gắn vào Windows từ Windows XP.²
• Có ba vai cộng một bên điều phối. Dịch vụ VSS làm trung gian giữa requester yêu cầu bản sao bóng (phần mềm sao lưu), writer bảo đảm tính nhất quán dữ liệu phía ứng dụng (SQL Server chẳng hạn), và provider thực sự tạo snapshot.¹
• System provider chuẩn của Windows dùng copy-on-write. Thay vì nhân cả volume, nó chỉ đưa các khối bị ghi đè sau snapshot — và chỉ nội dung trước khi ghi — vào vùng diff. Vùng diff phải nằm trên volume NTFS.¹
• Điểm đứng yên được tạo theo «freeze writer (tối đa 60 giây) → tạo snapshot (trong 10 giây) → thaw». Nếu vượt hạn thời gian, việc tạo bị hủy và requester thử lại.¹
• Writer có hợp tác hay không đổi chất lượng bản copy. Snapshot không có writer hợp tác tương đương «đĩa đúng lúc cắt điện» (crash consistent); snapshot có hợp tác đã cuộn log và xả cache, để lại trạng thái nhất quán mà chính ứng dụng bảo đảm khôi phục được (application consistent).³¹
• vssadmin là công cụ kiểm trạng thái vận hành. Dùng list shadows / list writers / list shadowstorage để xem hiện trạng, và resize shadowstorage để chỉnh hạn mức vùng diff. Khi vùng diff hết chỗ, bản sao bóng cũ nhất bị xóa im lặng.⁴⁵¹
• Gắn requester VSS vào ứng dụng tự viết là việc lớn. Đó là API gốc dựa COM, không có wrapper .NET chính thức. Đa số trường hợp, thử lại, chỉnh share mode, hoặc dừng ngắn là đủ; nếu thật sự cần VSS, viết kịch bản DiskShadow là lời đáp thực tế (chỉ Windows Server).⁶⁷
• Bản sao bóng không phải bản sao lưu. Vì phần khác biệt copy-on-write phụ thuộc các khối còn nguyên của volume gốc, nó vô lực trước sự cố lấy đi cả volume gốc như đĩa hỏng hay bị đánh cắp. Với ransomware cũng không dựa được, vì chính bản sao bóng có thể bị xóa (mục 7.3) hoặc vùng diff bị cạn vì ghi đè hàng loạt (mục 7.4). Nó chỉ có nghĩa khi kết hợp với sao lưu trên phương tiện khác.¹

2. Đặt vấn đề — vì sao tệp đang dùng không copy bình thường được

Điểm xuất phát là share mode tệp của Windows. Khi mở tệp trên Windows (CreateFile), bạn khai báo, dưới dạng share mode (dwShareMode), bạn cho phép tiến trình khác làm gì trong lúc mình đang giữ tệp. Trong lúc một tiến trình giữ tệp mở theo cách không cho chia sẻ đọc, tiến trình nào sau đó thử mở để đọc sẽ thất bại với vi phạm chia sẻ (ERROR_SHARING_VIOLATION, lỗi 32).⁸ Trong .NET đây là IOException quen thuộc («The process cannot access the file because it is being used by another process»).

Điểm quan trọng: đây không phải bug, mà là cơ chế đúng để bảo vệ dữ liệu. Nếu tệp đang được ghi bị đọc giữa chừng, bên đọc nhận trạng thái dở dang, đang viết. Như đã trình bày trong «Nền tảng loại trừ cho liên kết dựa trên tệp - Thực hành tốt nhất về khóa tệp và claim nguyên tử», thiết kế loại trừ là nền của liên kết giữa ứng dụng.

Nhưng cơ chế đúng đó xung đột tận gốc với sao lưu.

• Bức tường vi phạm chia sẻ: tệp mà cơ sở dữ liệu hay ứng dụng nghiệp vụ giữ mở có thể không mở được làm nguồn copy ngay từ đầu.
• Bức tường nhất quán: dù mở được (vì chia sẻ đọc được phép), việc copy mất thời gian. Vì ứng dụng vẫn ghi trong lúc copy chạy, nửa đầu và nửa sau của tệp có thể phản ánh hai thời điểm khác nhau, hoặc nhiều tệp (tệp dữ liệu và log chẳng hạn) lệch nhịp nhau. Và như đã thấy ở kỳ «Cache Manager», một lần ghi vào cache trong bộ nhớ trước, nên chỉ nhìn tệp trên đĩa không bảo đảm bạn đang thấy nội dung mới nhất.
• Bức tường vận hành: «vậy thì dừng ứng dụng rồi copy» đúng về nguyên tắc, nhưng không chấp nhận được với hệ thống nghiệp vụ hay file server chạy suốt ngày đêm.

Nói cách khác, cái thực sự muốn là «một bản copy của một khoảnh khắc nhất quán, mà không dừng ứng dụng.» Việc đó nặng quá để từng ứng dụng tự giải, nên VSS được dựng như cơ chế cấp OS để cung cấp nó. VSS được đưa ra như khung giao diện COM, giúp sao lưu volume ngay cả khi ứng dụng vẫn ghi vào đó.²

3. Các vai trong VSS — requester, writer, provider

Cấu trúc VSS tách thành ba vai và dịch vụ làm trung gian giữa chúng.¹

Sự khéo của phân vai là các sản phẩm không biết gì về nhau vẫn phối hợp được. Phần mềm sao lưu (requester) không biết cấu trúc nội bộ của SQL Server, nhưng writer của SQL Server khai báo, dưới dạng metadata, tệp nào (component) cần sao lưu, và tự sắp dữ liệu ngay quanh điểm đứng yên — nên requester lấy được bản sao lưu nhất quán chỉ bằng cách đi theo.¹⁹ Hầu hết sản phẩm sao lưu bên thứ ba chạy trên Windows đều là requester VSS.¹

Trong vận hành CNTT, lúc thực sự phải nghĩ về ba vai này là khi xử lý sự cố. Việc sao lưu thất bại thuộc requester (phía phần mềm), một writer cụ thể (phía ứng dụng), hay provider / vùng diff (phía hạ tầng) đổi hẳn chỗ bạn nên nhìn (mục 5 và 7).

4. Cơ chế snapshot — copy-on-write và «điểm đứng yên»

4.1. Copy-on-write — giữ «khoảnh khắc đó» mà không nhân bản volume

Nghe «snapshot» khiến bạn tưởng nhân cả volume, nhưng cách system provider chuẩn của Windows thực sự dùng là copy-on-write. Lúc snapshot được lấy, hầu như không copy gì. Sau đó, khi một khối trên volume gốc sắp bị ghi đè, nội dung trước khi ghi của khối đó được đưa vào vùng diff (vùng lưu trữ bản sao bóng) trước khi lần ghi đè hoàn tất, rồi lần ghi mới được cho qua.¹ Việc đưa đi chỉ cần xảy ra lần đầu mỗi khối bị ghi đè; ghi đè thêm một khối đã được đưa đi không làm vùng diff lớn thêm.

Để đọc «volume như lúc đó», khối chưa đổi được đọc từ volume gốc, khối đã đổi được đọc từ vùng diff, rồi ghép lại. Vì chỉ phần đã đổi mới bị copy, việc tạo là tức thì và chỗ chiếm chỉ là phần khác biệt. Mặt trái là volume bị ghi càng nặng thì vùng diff bị tiêu càng nhanh (báo trước mục 7), và vùng diff nằm trên volume NTFS cùng máy với dữ liệu nguồn.¹ Nền của cơ chế này là tệp thành phần của system provider, swprv.dll, và driver cắt I/O của volume, volsnap.sys.¹ Nếu bạn quan tâm «cách» cắt vào ngăn xếp I/O, xem thêm «Filter driver và minifilter».

Còn những cách khác: full copy, tách một bản gương, và redirect-on-write, ghi thay đổi sang volume riêng; hardware provider dùng cách hợp với mảng lưu trữ nhất.¹

4.2. Luồng tạo điểm đứng yên — phối hợp freeze 60 giây, tạo trong 10 giây

Nếu copy-on-write nói về cách dữ liệu được giữ, giá trị thực của VSS nằm ở trạng thái của khoảnh khắc nào được giữ — tức cách tạo điểm đứng yên. Việc tạo bản sao bóng đi như sau.¹

flowchart TB
    accTitle: Luồng tạo bản sao bóng
    accDescr: Luồng tạo bản sao bóng. Việc dừng chỉ kéo dài vài giây đến vài chục giây; bản thân sao lưu chạy trên snapshot.
    R["Requester yêu cầu tạo<br/>Liệt kê writer và thu thập metadata"] --> M["Mỗi writer khai báo đối tượng sao lưu<br/>(component) bằng XML"]
    M --> P["Mỗi writer chuẩn bị dữ liệu<br/>Cuộn log, xả cache, v.v.<br/>Đưa về trạng thái nhất quán, khôi phục được"]
    P --> F["Đóng băng I/O ghi của writer<br/>(vẫn đọc được. Tối đa 60 giây)"]
    F --> FS["VSS xả bộ đệm hệ thống tệp<br/>và đóng băng hệ thống tệp"]
    FS --> C["Provider tạo bản sao bóng<br/>(trong 10 giây. Trong lúc này I/O ghi bị đóng băng)"]
    C --> T["Giải phóng hệ thống tệp → rã đông writer (thaw)<br/>Ứng dụng tiếp tục ghi"]
    T --> B["Requester thực hiện sao lưu từ<br/>bản sao bóng, mất bao lâu tùy ý"]

Hình 1: Luồng tạo bản sao bóng. Việc dừng chỉ kéo dài vài giây đến vài chục giây; bản thân sao lưu chạy trên snapshot.

Có ba điểm cần nhớ.

1. Ứng dụng chỉ dừng đúng lúc tạo điểm đứng yên. Freeze bị giới hạn tối đa 60 giây, và việc tạo (commit) của provider tối đa 10 giây; vượt một trong hai thì việc tạo bị hủy và requester thử lại.¹ Bản sao lưu chính, có thể mất hàng giờ, chạy trên bản sao bóng chỉ-đọc đã xong, trong lúc ứng dụng vẫn chạy.
2. Vẫn đọc được trong lúc freeze. Chỉ I/O ghi dừng.¹
3. Hệ thống tệp cũng bị đóng băng. Vì VSS xả bộ đệm hệ thống tệp trước khi đóng băng, các lần ghi còn nằm trong cache và metadata hệ thống tệp được phản ánh vào snapshot theo thứ tự nhất quán.¹

4.3. Crash consistency và application consistency

Đây là chỗ xuất hiện sự phân biệt quan trọng, quyết định chất lượng sao lưu.

Bản sao bóng tạo không có writer hợp tác nằm ở trạng thái mà thuật ngữ Microsoft gọi là crash consistent. Định nghĩa chính thức là «trạng thái đĩa tương đương trạng thái tìm thấy sau sự cố thảm họa tắt hệ thống đột ngột», và khôi phục từ đó được mô tả là «tương đương khởi động lại sau tắt đột ngột».³ Với hệ thống tệp thì không hỏng, nhưng với ứng dụng thì đó là «khoảnh khắc rút điện lúc đang ghi». Cơ sở dữ liệu có cơ chế khôi phục từ transaction log thường gượng được, nhưng xử lý khôi phục phải chạy trước — đó là tiền đề, không phải phần thưởng.

Có writer hợp tác, mỗi writer cuộn transaction log và xả cache ngay trước điểm đứng yên, đưa dữ liệu tới trạng thái nhất quán mà chính ứng dụng bảo đảm khôi phục đúng được.¹ Đó là application consistency, và là toàn bộ lý do cơ chế writer tồn tại. Đáng lưu ý: cái writer bảo đảm là «trạng thái nhất quán, khôi phục được về phía ứng dụng» — nó không lặng lẽ commit và hoàn tất giao dịch đang chạy hộ bạn. Việc chưa commit bị rollback lúc khôi phục, đúng như khôi phục cơ sở dữ liệu thông thường. Writer đưa bảo đảm chất lượng này mà không dừng ứng dụng, chỉ bằng freeze kéo vài chục giây.

Lý do phần mềm sao lưu có mục như «dùng VSS» hay «bảo đảm tính nhất quán ứng dụng» chính là sự phân biệt này. Với một tập tệp thường trên file server, crash consistency hiếm khi thành vấn đề; nhưng trên máy chủ chứa cơ sở dữ liệu hay kho thư, việc writer tương ứng có khỏe hay không, tự nó đã là chất lượng bản sao lưu.

5. Thực hành vận hành VSS hàng ngày — vssadmin và «Phiên bản trước»

Công cụ nhân sự CNTT dùng trong thực tế để kiểm trạng thái VSS là vssadmin (chạy từ Command Prompt nâng quyền). Tham chiếu lệnh hiện hành liệt kê list shadows / list writers / delete shadows / resize shadowstorage là dùng được trên cả client và server.⁴ Tham chiếu hướng Windows Server còn liệt thêm create shadow / list shadowstorage / list providers, cùng vài lệnh khác.⁵ Lưu ý rằng vssadmin chỉ quản được bản sao bóng do system provider tạo.¹

Nếu list writers hiện writer ở trạng thái lỗi, thứ cần nghi không phải bản thân VSS mà là ứng dụng cung cấp writer đó. Kiểm trạng thái dịch vụ của ứng dụng sở hữu và Application/System event log (mục 7).

/maxsize của resize shadowstorage cho phép chỉ định hạn mức với đơn vị như KB/MB/GB; để trống thì không hạn chút nào. Đáng lưu ý là tài liệu Microsoft nêu tường minh: đổi hạn mức lưu trữ — đặc biệt là thu nhỏ — bản thân có thể làm mất bản sao bóng.¹⁰ Đừng thu hẹp hạn mức một cách tùy tiện trên volume mà bạn muốn giữ nhiều thế hệ.

5.1. Quan hệ với «Phiên bản trước»

Bật Shadow Copies of Shared Folders trên file server định kỳ giữ bản copy tại một thời điểm của tệp trên share, để người dùng khôi phục tệp đã xóa hay ghi đè từ Phiên bản trước mà không cần quản trị viên.¹ Đây là ứng dụng quen thuộc nhất của VSS, và chắc chắn cắt được khối lượng help desk.

Nhưng có hạn. Bản sao bóng của system provider tối đa 512 mỗi volume, trong đó tính năng Shadow Copies of Shared Folders mặc định giữ tới 64 (đổi được qua giá trị registry MaxShadowCopies).¹ Và như các mục sau trình bày, nếu vùng diff thiếu thì thế hệ cũ bị gỡ tự động. An toàn nhất là hiểu «bao nhiêu thế hệ thực sự được giữ» do lượng ghi và kích thước vùng diff quyết định, không phải con số bạn cấu hình.

6. Góc nhìn nhà phát triển — ứng dụng tự viết có cần VSS không

Từ đây là góc nhà phát triển. Khi bị yêu cầu «thêm chức năng sao lưu copy được tệp ngay cả khi đang dùng», nên tiếp cận VSS thế nào?

6.1. Tự viết requester là việc lớn

API VSS, cho cả requester lẫn writer, được cung cấp dưới dạng giao diện COM và C++ (trung tâm của requester là IVssBackupComponents).⁶ Không có wrapper .NET chính thức, và bạn phải triển khai đúng từ thu thập metadata writer, qua quản lý snapshot set, đến dọn sau lỗi — nên không phải thứ gắn tùy tiện như một tính năng của ứng dụng nghiệp vụ. Trong ước lượng phát triển nhận thầu của chúng tôi, «tự viết requester VSS» được tách thành hạng mục riêng.

Có hai lời đáp thực tế. Thứ nhất, giao cho sản phẩm sao lưu đã hỗ trợ VSS. Thứ hai, trên Windows Server, điều khiển DiskShadow từ kịch bản. DiskShadow là requester VSS đi kèm OS; ngoài chế độ tương tác, nó có chế độ kịch bản (diskshadow /s script.txt), và một kịch bản có thể phủ tạo bản sao bóng, lộ nó thành ký tự ổ (expose), chạy batch làm việc copy (exec), rồi dọn sau.⁷¹ Bạn dựng được luồng «tạo bản sao bóng → rút tệp bằng logic copy của mình → xóa» mà không viết một dòng COM. Tuy nhiên, DiskShadow chỉ dành cho Windows Server và không có trong bản client của OS.¹ Nếu PC client cũng nằm trong phạm vi yêu cầu, riêng sự thật đó đã nghiêng về chọn sản phẩm sao lưu sẵn có.

6.2. Có thật sự cần VSS không — bảng quyết định

Theo kinh nghiệm, đại đa số yêu cầu «copy tệp đang dùng» giải được không cần VSS. Hãy xác định đúng mức yêu cầu trước khi chọn công cụ.

6.3. Ứng dụng tự viết có nên đăng ký writer không

Câu hỏi ngược cũng nên làm rõ: ứng dụng nghiệp vụ tự viết có nên cung cấp writer VSS? Nếu viết một cái, dữ liệu ứng dụng của bạn được sao lưu với application consistency bất kể khách dùng sản phẩm sao lưu nào. Còn một cơ chế nhẹ hơn writer thường, express writer (IVssExpressWriter), nhưng tất cả nó làm là đăng ký metadata khai báo tệp nào đưa vào hay loại ra.⁶ Nó không nhận thông báo freeze/thaw, nên không tạm dừng lần ghi của ứng dụng cho khớp lúc tạo snapshot. Express writer chỉ hợp khi đi cùng thiết kế lưu trữ không hỏng dù bị bắt giữa lúc ghi (tức crash consistency là đủ); nếu thực sự cần phối hợp tại điểm đứng yên, bạn cần triển khai writer đầy đủ.

Dẫu vậy, thước quyết định thì đơn giản.

• Nếu dữ liệu nằm trong cơ sở dữ liệu như SQL Server, bạn không cần. Writer của chính cơ sở dữ liệu bảo đảm tính nhất quán.¹
• Với lưu trữ tệp đơn giản, hãy giải trước bằng thiết kế routine lưu. Nếu bạn ghi trọn ra tệp tạm rồi hoán bằng đổi tên nguyên tử, snapshot crash-consistent sẽ không để lại tệp lưu hỏng.
• Đăng ký writer chỉ đáng cân nhắc với ứng dụng giữ kho dữ liệu riêng trải nhiều tệp và cần nhất quán chéo giữa chúng tại điểm đứng yên. Có khi đáng xem lại trước hết việc giữ lượng dữ liệu đó bằng định dạng tự chế có phải lựa chọn đúng không.

7. Cạm bẫy — bốn điều thực sự đau trong vận hành

7.1. VSS không phải bản sao lưu

Đây là cạm bẫy quan trọng nhất. Bản sao bóng của system provider là phần khác biệt nằm trên đĩa cùng máy với dữ liệu gốc. Nếu vùng diff mất, không còn gì để ghép lại, nên nó không bảo vệ gì trước đĩa hỏng, máy bị đánh cắp hay thất lạc, hay mã hóa cả volume. Tài liệu của Microsoft cũng kẻ rõ ranh giữa bản sao bóng và sao lưu: «nội dung copy từ bản sao bóng sang phương tiện như băng mới là sao lưu, và bản sao bóng được xóa sau khi copy đó xong.»¹ Bản sao bóng là điểm đứng yên và cách khôi phục nhanh sau thao tác nhầm — không thay thế sao lưu trên phương tiện khác, tại một địa điểm khác.

7.2. Lỗi writer là vấn đề phía ứng dụng

Khi phần mềm sao lưu thất bại với «lỗi VSS», hãy bắt đầu bằng xác định writer nào thất bại, dùng vssadmin list writers. Vì writer về thực chất là thành phần thuộc ứng dụng (hoặc thành phần Windows)¹, chiến trường chính khi tìm nguyên nhân là trạng thái dịch vụ và event log của ứng dụng đó. Bị kéo theo vẻ bề ngoài «lỗi từ phần mềm sao lưu» rồi chỉ điều tra phần mềm sao lưu sẽ đi đường vòng. Mẫu thu hẹp chung giống mẫu trong «Khi bạn thừa kế hệ thống không có mã nguồn cũng không có tài liệu — Sổ tay thực tế để giữ nó chạy»: thu hẹp danh sách nghi phạm từ sự thật quan sát được.

7.3. Ransomware nhắm xóa bản sao bóng

Đây là sự thật đáng biết thuần như cân nhắc phòng thủ. Dễ hy vọng rằng nếu quay lại được bằng Phiên bản trước, bạn khôi phục được cả sau khi bị ransomware — nhưng người ta biết rộng rằng rất nhiều ransomware xóa bản sao bóng trước hoặc sau khi mã hóa, đúng để cắt đường khôi phục này. Xóa bản sao bóng làm được bằng lệnh hoàn toàn hợp lệ miễn có quyền quản trị, nên không đóng vai tuyến cuối chống kẻ đã vào. Trụ của đối sách vì thế là: (1) xem bản sao bóng là «tiện nếu còn» chứ không phải «một phần kế hoạch khôi phục»; (2) giữ sao lưu offline tại địa điểm khác mà kẻ tấn công không với tới; và (3) không cấp quyền quản trị cho tài khoản dùng vận hành hàng ngày. Về phòng thủ suốt vòng đời PC, gồm sao lưu, mã hóa và thanh lý, xem thêm «Hướng dẫn thực tế BitLocker — mã hóa ổ bắt đầu từ quản lý khóa khôi phục» và «Việc cần làm trước khi thanh lý PC Windows — Danh sách kiểm thực tế xóa dữ liệu, gỡ tài khoản và sao lưu».

7.4. Khi vùng diff hết chỗ, thế hệ cũ biến mất im lặng

Như mục 4 đã nói, copy-on-write chỉ tiêu vùng diff khi mỗi khối bị ghi đè lần đầu sau khi snapshot được lấy. Ghi đè thêm khối đã được đưa đi bao nhiêu lần nữa cũng không tăng mức tiêu, nên lượng tiêu do không phải «bao nhiêu lần ghi xảy ra» mà do «phạm vi khối bị ghi đè rộng đến đâu kể từ snapshot đang giữ.» Và khi vùng diff chạm hạn mức, bản sao bóng của volume đó bị xóa, cái cũ nhất trước.¹ Người dùng tương tác không được thông báo gì, nên việc này thường chỉ lộ khi «lẽ ra quay được về bản tuần trước» hóa ra không còn đúng. Nhưng không hoàn toàn im: System log vẫn ghi sự kiện từ nguồn volsnap (event ID 25 khi một bản bị xóa vì không lấy được chỗ cho vùng diff, 35/36 khi mở rộng thất bại hoặc bị hủy sau khi chạm hạn, v.v.). Ngoài kiểm định kỳ, đưa các sự kiện volsnap này vào giám sát và cảnh báo giúp bạn bắt được mất mát nhanh. Lý do thao tác hàng loạt «quét cả volume» — cập nhật tệp hàng loạt, chuyển đổi hàng loạt, chống phân mảnh — có thể nuốt vùng diff một lần nằm đúng ở tính chất này: mức tiêu do phạm vi khối bị ghi đè quyết định. Hãy kiểm định kỳ xem số thế hệ đang giữ còn đáp yêu cầu nghiệp vụ («lâu nhất bao nhiêu ngày trước khi ai đó nhận ra một lần xóa nhầm?») đối chiếu mức dùng hiện bởi vssadmin list shadowstorage, và nới hạn nếu cần.⁵¹⁰

8. Tóm tắt

• Lý do tệp đang dùng không copy bình thường được là chuyện vi phạm chia sẻ và tính nhất quán, và đó là cơ chế đúng để bảo vệ dữ liệu. VSS là câu trả lời cấp OS cho «tôi muốn bản copy nhất quán mà không dừng ứng dụng.»
• VSS là khung trong đó dịch vụ VSS làm trung gian giữa ba vai — requester (yêu cầu), writer (bảo đảm nhất quán), và provider (tạo) — để phần mềm sao lưu và ứng dụng nghiệp vụ không biết gì về nhau vẫn phối hợp.
• System provider dùng copy-on-write, và điểm đứng yên được tạo theo «freeze writer (tối đa 60 giây) → tạo (trong 10 giây) → thaw.» Không có writer hợp tác thì crash consistency; có thì application consistency.
• Kiểm trạng thái vận hành bằng vssadmin (list shadows / list writers / list shadowstorage). Nghi phía ứng dụng khi lỗi writer, và xem mức dùng vùng diff đều đặn.
• Nhà phát triển nên dùng bảng quyết định trước, xem thử lại, share mode, cửa sổ dừng, hay thiết kế liên kết có giải được không, và chỉ quay sang VSS khi thật sự cần. Kịch bản DiskShadow (chỉ Server) hoặc sản phẩm sẵn có là lời đáp thực tế, trước khi tự viết.
• Bản sao bóng không phải bản sao lưu. Nó chỉ là phần khác biệt phụ thuộc các khối còn nguyên của volume gốc; nó vô lực trước mất volume gốc như đĩa hỏng, và với ransomware cũng không dựa được, vì bản sao bóng có thể bị xóa hoặc vùng diff bị cạn. Hãy ghép nó với sao lưu offline tại một địa điểm khác.

Bài viết liên quan

• Nền tảng loại trừ cho liên kết dựa trên tệp - Thực hành tốt nhất về khóa tệp và claim nguyên tử
• Độ sâu I/O Windows (phần 4) — Cache Manager: WriteFile của bạn thực sự tới đĩa khi nào?
• Độ sâu I/O Windows (phần 5) — Nội bộ NTFS: hiểu hệ thống tệp qua MFT
• Khi bạn thừa kế hệ thống không có mã nguồn cũng không có tài liệu — Sổ tay thực tế để giữ nó chạy
• Hướng dẫn thực tế BitLocker — mã hóa ổ bắt đầu từ quản lý khóa khôi phục
• Việc cần làm trước khi thanh lý PC Windows — Danh sách kiểm thực tế xóa dữ liệu, gỡ tài khoản và sao lưu

Lĩnh vực tư vấn liên quan

KomuraSoft LLC đảm nhận thiết kế và phát triển ứng dụng nghiệp vụ gồm chức năng như «copy tệp đang dùng» và sao lưu, điều tra nguyên nhân gốc của vi phạm chia sẻ quanh liên kết tệp và thất bại sao lưu (lỗi writer VSS), và sắp xếp cấu trúc vận hành sao lưu file server cùng quản lý thế hệ. Chúng tôi sẵn sàng bắt đầu từ câu hỏi liệu VSS có phải yêu cầu đúng ngay từ đầu.

• Phát triển ứng dụng Windows
• Điều tra lỗi và nguyên nhân
• Tư vấn kỹ thuật và đánh giá thiết kế
• Liên hệ với chúng tôi

Liên kết tham khảo

Bài viết liên quan

Các bài viết gần đây có cùng thẻ để tìm hiểu sâu hơn những chủ đề lân cận.

Chủ đề liên quan

Các trang này đặt chủ đề trong bối cảnh rộng hơn của dịch vụ và quyết định.

Dịch vụ liên quan đến chủ đề này

Bài viết liên quan trực tiếp đến các dịch vụ sau.

Câu hỏi thường gặp

Các câu hỏi thường gặp khi tư vấn về chủ đề của bài viết.

Có bản sao bóng thì có còn cần sao lưu không?

Vẫn cần. Bản sao bóng do system provider chuẩn của Windows tạo là phần khác biệt theo kiểu copy-on-write — không phải một bản nhân đầy đủ của volume tại thời điểm đó, mà phụ thuộc các khối trên volume gốc chưa bị ghi đè. Dù đặt vùng diff (diff area) sang volume khác, sự thật vẫn là: mất volume gốc thì không khôi phục được, nên nó vô lực trước sự cố lấy đi cả volume gốc như đĩa hỏng, PC bị đánh cắp hay thất lạc. Với ransomware cũng vậy: thao tác ghi khi mã hóa có đưa khối trước khi ghi sang vùng diff, nhưng trong tấn công thực tế bản sao bóng bị xóa, hoặc vùng diff bị cạn vì ghi đè hàng loạt, nên không thể dựa vào. Tài liệu của Microsoft cũng tách rõ hai thứ: sao lưu là dữ liệu được copy từ bản sao bóng sang phương tiện như băng, và sau khi copy xong thì được xóa bản sao bóng. Bản sao bóng là «điểm đứng yên để lấy sao lưu» và «cách khôi phục nhanh sau thao tác nhầm nhẹ» — không thay thế sao lưu trên phương tiện khác, tại một địa điểm khác.

Ứng dụng nghiệp vụ tự viết muốn copy tệp đang dùng — có nên dùng VSS không?

Bước thực tế đầu tiên là tìm cách không cần đến nó. Requester VSS phải viết trên API gốc dựa COM (như IVssBackupComponents), không có wrapper .NET chính thức, nên gắn vào ứng dụng tự viết là việc lớn. Nếu yêu cầu chỉ là «cuối cùng thì đọc được tệp tiến trình khác đang ghi», thử lại là đủ; nếu «ứng dụng kia cho phép chia sẻ đọc», mở tệp với share mode khớp là đủ. Nếu ứng dụng dừng được một lúc ngắn, copy vào lúc nghỉ nghiệp vụ là cách đơn giản và chắc nhất. VSS chỉ đáng chỗ khi yêu cầu là «nhân toàn bộ dữ liệu của ứng dụng không dừng được, ở trạng thái nhất quán» — và cả khi đó, hãy xem phần mềm sao lưu đã hỗ trợ VSS hoặc kịch bản DiskShadow trước khi tự triển khai.

vssadmin list writers báo writer ở trạng thái lỗi. Phải làm gì?

Cách cơ bản là điều tra như sự cố phía ứng dụng sở hữu writer đó. vssadmin list writers hiện danh sách writer đã đăng ký kèm trạng thái, nên trước hết hãy xác định writer nào thất bại. Vì writer do ứng dụng như SQL Server hoặc thành phần Windows (registry chẳng hạn) cung cấp, nguyên nhân hầu như nằm ở trạng thái dịch vụ của ứng dụng đó, hoặc lỗi ghi trong Application/System event log, chứ không phải bản thân VSS. Khởi động lại dịch vụ liên quan và thu hẹp điều kiện tái hiện; nếu chưa hết, xem thông tin hỗ trợ của ứng dụng đó. Đây cũng là bước phân loại đầu đúng khi phần mềm sao lưu thất bại với lỗi VSS.

Bản sao bóng biến mất mà tôi không hay. Vì sao?

Nguyên nhân điển hình là vùng diff (vùng lưu trữ bản sao bóng) hết chỗ. Với copy-on-write, nội dung mỗi khối được đưa vào vùng diff lần đầu nó bị ghi đè sau khi snapshot được lấy, nên phạm vi khối bị ghi đè càng rộng thì vùng diff càng bị tiêu. Khi đạt hạn mức đã gán, Windows xóa bản sao bóng cũ nhất trước để lấy chỗ. Việc này diễn ra im lặng, không thông báo cho người dùng tương tác, nên thường chỉ lộ khi ai đó định khôi phục bản tuần trước từ Phiên bản trước thì thấy không còn (System log vẫn ghi sự kiện như event ID 25 từ nguồn volsnap, nên theo dõi cái đó giúp bạn bắt được). Kiểm tra mức dùng và hạn mức bằng vssadmin list shadowstorage, và nâng hạn bằng vssadmin resize shadowstorage nếu cần. Lưu ý rằng chính việc đổi hạn mức — đặc biệt là thu nhỏ — cũng có thể làm mất bản sao bóng.

«Phiên bản trước» của File Explorer liên hệ thế nào với VSS?

«Phiên bản trước» là một lối vào để lấy bản cũ của tệp từ bản sao bóng do VSS tạo. Trên file server, bật «Shadow Copies of Shared Folders» khiến bản sao bóng được lấy theo lịch, và người dùng có thể chuột phải tệp trên thư mục dùng chung rồi tự khôi phục từ Phiên bản trước. Lợi ích là người dùng hoàn tác được xóa hay ghi đè nhầm mà không cần quản trị viên. Nhưng vì bên dưới vẫn là bản sao bóng, số thế hệ giữ được có hạn, và nếu vùng diff thiếu thì thế hệ cũ mất trước. Như đã nói trong bài, «có Phiên bản trước» không có nghĩa «không cần sao lưu».

Hồ sơ tác giả

Trang giới thiệu tác giả bài viết.

Go Komura

Đại diện của KomuraSoft LLC

Chuyên về phát triển phần mềm Windows, tư vấn kỹ thuật và điều tra lỗi, đặc biệt trong các dự án có hệ thống hiện hữu và lỗi khó tái hiện.