Volume Shadow Copy (VSS): mekanisme dan praktik — mengapa perangkat lunak cadangan bisa menyalin file yang sedang dipakai

«Saya mencoba menyalin file yang dibuka aplikasi lain, lalu diberitahu proses tidak bisa mengakses file karena sedang dipakai proses lain.» «Kami diminta mencadangkan folder data tanpa menghentikan sistem inti.» «Mengapa perangkat lunak cadangan bisa dengan tenang menyalin file basis data yang sedang dipakai?» — Entah Anda mengembangkan aplikasi bisnis atau mengoperasikan file server, ini pertanyaan yang cepat atau lambat Anda temui.

Di pusat jawabannya ada Volume Shadow Copy Service (VSS). Mekanisme ini sudah tertanam di Windows lebih dari dua puluh tahun, dan Windows Server Backup, System Restore, serta hampir setiap produk cadangan komersial semuanya duduk di fondasi yang sama.¹

Artikel ini ditujukan bagi pengembang aplikasi bisnis yang diminta menambah fungsi «salin file yang sedang dipakai», dan bagi staf TI yang mengoperasikan cadangan file server dan PC bisnis. Berpijak pada sumber primer per Agustus 2026, artikel ini menata pemeran VSS dan cara kerjanya, praktik harian mengoperasikannya dengan vssadmin, dan di mana garis harus ditarik soal seberapa jauh pengembang perlu terlibat dengan VSS. Seri «Kedalaman I/O Windows» melihat ke dalam Cache Manager dan NTFS; artikel ini adalah kelanjutannya, mencakup lapisan «snapshot» yang duduk langsung di atas volume.

1. Intinya dulu

• VSS adalah kumpulan antarmuka COM dan layanan koordinasi yang memungkinkan mencadangkan volume sementara aplikasi terus menulis ke dalamnya. Mekanisme ini tertanam di Windows sejak Windows XP.²
• Ada tiga peran plus koordinator. Layanan VSS menengahi antara requester yang meminta shadow copy (perangkat lunak cadangan), writer yang menjamin konsistensi data di sisi aplikasi (SQL Server, misalnya), dan provider yang benar-benar membuat snapshot.¹
• Provider sistem standar Windows memakai copy-on-write. Alih-alih menggandakan seluruh volume, ia hanya memindahkan blok yang ditimpa setelah snapshot — dan hanya isi sebelum-tulisnya — ke area selisih (diff area). Area selisih harus berada di volume NTFS.¹
• Titik konsistensi dibuat lewat «freeze writer (hingga 60 detik) → buat snapshot (dalam 10 detik) → thaw.» Jika salah satu batas waktu terlampaui, pembuatan dibatalkan dan requester mencoba lagi.¹
• Apakah writer bekerja sama mengubah kualitas salinan. Snapshot yang diambil tanpa kerja sama writer setara dengan «disk pada saat daya diputus» (crash consistent); yang diambil dengan kerja sama sudah menggulung log dan mem-flush cache, meninggalkan keadaan konsisten yang dijamin aplikasi itu sendiri dapat dipulihkan (application consistent).³¹
• vssadmin adalah alat untuk memeriksa keadaan operasional. Pakai list shadows / list writers / list shadowstorage untuk melihat keadaan saat ini, dan resize shadowstorage untuk menyesuaikan batas area selisih. Ketika area selisih habis, shadow copy tertua dihapus diam-diam.⁴⁵¹
• Membangun requester VSS ke dalam aplikasi sendiri adalah pekerjaan besar. Itu API native berbasis COM tanpa pembungkus .NET resmi. Dalam banyak kasus, percobaan ulang, menyesuaikan mode berbagi, atau penghentian singkat sudah cukup; jika VSS benar-benar diperlukan, menskrip DiskShadow adalah jawaban praktis (hanya Windows Server).⁶⁷
• Shadow copy bukan cadangan itu sendiri. Karena selisih copy-on-write bergantung pada blok utuh volume asli, ia tidak melindungi dari kegagalan yang menghabisi volume asli sepenuhnya, seperti kegagalan disk atau pencurian. Ia juga tidak bisa diandalkan terhadap ransomware, karena shadow copy itu sendiri bisa dihapus (bagian 7.3) atau area selisih dikuras oleh penimpaan massal (bagian 7.4). Ia baru bermakna ketika digabung dengan cadangan yang disimpan di media terpisah.¹

2. Menata masalah — mengapa file yang sedang dipakai tidak bisa disalin secara biasa?

Titik berangkatnya adalah mode berbagi file Windows. Ketika Anda membuka file di Windows (CreateFile), Anda menyatakan, sebagai mode berbagi (dwShareMode), apa yang akan Anda izinkan proses lain lakukan sementara Anda membukanya. Sementara suatu proses memegang file terbuka dengan cara yang tidak mengizinkan berbagi baca, proses mana pun yang kemudian mencoba membukanya untuk dibaca gagal dengan pelanggaran berbagi (ERROR_SHARING_VIOLATION, error 32).⁸ Di .NET ini adalah IOException yang akrab («Proses tidak dapat mengakses file karena sedang digunakan oleh proses lain»).

Poin pentingnya: ini bukan bug, melainkan mekanisme yang benar untuk melindungi data. Jika file yang sedang ditulis dibaca di tengah jalan, pembaca berakhir dengan keadaan setengah jadi yang sedang berlangsung. Seperti dibahas rinci di «Dasar eksklusi bersama untuk integrasi berbasis file — praktik terbaik kunci file dan klaim atomik», desain eksklusi bersama adalah fondasi integrasi antaraplikasi.

Tetapi mekanisme yang benar ini bertabrakan secara mendasar dengan cadangan.

• Dinding pelanggaran berbagi: file yang tetap dibuka basis data atau aplikasi bisnis mungkin bahkan tidak bisa dibuka sebagai sumber salinan.
• Dinding konsistensi: bahkan jika Anda bisa membukanya (karena berbagi baca diizinkan), menyalin butuh waktu. Karena aplikasi terus menulis selama salinan berlangsung, paruh pertama dan paruh kedua file bisa mencerminkan titik waktu yang berbeda, atau beberapa file (file data dan lognya, misalnya) bisa tidak selaras satu sama lain. Dan seperti kita lihat di edisi «Cache Manager», sebuah tulis mendarat di cache dalam memori lebih dulu, jadi melihat hanya file di disk tidak menjamin Anda melihat isi terbaru.
• Dinding operasional: «kalau begitu hentikan saja aplikasinya lalu salin» adalah jawaban yang masuk akal secara prinsip, tetapi tidak bisa diterima untuk sistem bisnis atau file server yang berjalan sepanjang waktu.

Dengan kata lain, yang sebenarnya diinginkan adalah «salinan satu momen yang konsisten, tanpa menghentikan aplikasi.» Itu terlalu berat untuk diselesaikan masing-masing aplikasi sendiri, jadi VSS dibangun sebagai mekanisme tingkat OS untuk menyediakannya. VSS ditawarkan sebagai kerangka antarmuka COM yang memungkinkan mencadangkan volume bahkan sementara aplikasi terus menulis ke dalamnya.²

3. Pemeran VSS — requester, writer, provider

Struktur VSS terurai menjadi tiga peran dan layanan yang menengahi di antara mereka.¹

Keanggunan pembagian kerja ini adalah bahwa produk yang tidak tahu apa-apa tentang satu sama lain tetap bisa bekerja sama. Perangkat lunak cadangan (requester) tidak tahu struktur internal SQL Server, tetapi writer SQL Server menyatakan, sebagai metadata, file mana (komponen) yang perlu dicadangkan, dan merapikan datanya sendiri tepat di sekitar titik konsistensi — jadi requester bisa mengambil cadangan yang konsisten cukup dengan mengikuti pimpinan itu.¹⁹ Hampir setiap produk cadangan pihak ketiga yang berjalan di Windows adalah requester VSS.¹

Dalam operasi TI, momen Anda benar-benar perlu memikirkan tiga peran ini adalah pemecahan masalah. Apakah kegagalan cadangan adalah masalah requester (sisi perangkat lunak), writer tertentu (sisi aplikasi), atau provider / area selisih (sisi infrastruktur) mengubah sama sekali ke mana Anda harus melihat (bagian 5 dan 7).

4. Cara kerja snapshot — copy-on-write dan «titik konsistensi»

4.1. Copy-on-write — menyimpan «saat itu» tanpa menggandakan volume

Mendengar kata «snapshot» membuat Anda membayangkan menggandakan seluruh volume, tetapi metode yang benar-benar dipakai provider sistem standar Windows adalah copy-on-write. Pada saat snapshot diambil, hampir tidak ada yang disalin. Kemudian, ketika sebuah blok di volume asli hampir ditimpa, isi sebelum-tulis blok itu dipindahkan ke area selisih (diff area, penyimpanan shadow copy) sebelum penimpaan selesai, dan baru kemudian tulis diizinkan lewat.¹ Pemindahan hanya perlu terjadi pada kali pertama setiap blok ditimpa; menimpa blok yang sudah dipindahkan tidak menambah area selisih lagi.

Untuk membaca «volume sebagaimana adanya pada saat itu», blok yang tidak berubah dibaca dari volume asli, dan blok yang berubah dibaca dari area selisih, lalu keduanya digabung. Karena hanya porsi yang berubah yang pernah disalin, pembuatan terjadi seketika dan ruang yang terpakai hanyalah selisihnya. Sisi baliknya: semakin berat sebuah volume ditulis, semakin cepat area selisih terkuras (bayangan ke bagian 7), dan area selisih duduk di volume NTFS pada mesin yang sama dengan data sumber.¹ Yang menopang mekanisme ini adalah file komponen provider sistem, swprv.dll, dan driver yang mencegat I/O volume, volsnap.sys.¹ Jika Anda tertarik pada «cara» mencegat tumpukan I/O, lihat juga «Filter driver dan minifilter».

Ada juga metode lain: full copy, yang memisahkan cermin, dan redirect-on-write, yang menulis perubahan ke volume terpisah; provider perangkat keras memakai metode mana pun yang paling cocok untuk array penyimpanan.¹

4.2. Alur membuat titik konsistensi — freeze 60 detik, pembuatan 10 detik

Jika copy-on-write adalah tentang bagaimana data disimpan, nilai sesungguhnya VSS terletak pada keadaan momen mana yang disimpan — dengan kata lain, bagaimana titik konsistensi dibuat. Pembuatan shadow copy berlangsung sebagai berikut.¹

flowchart TB
    accTitle: Alur pembuatan shadow copy
    accDescr: Alur pembuatan shadow copy. Yang benar-benar berhenti hanya beberapa detik hingga puluhan detik; cadangan itu sendiri dijalankan terhadap snapshot.
    R["Requester meminta pembuatan<br/>mengenumerasi writer dan mengumpulkan metadata"] --> M["Setiap writer menyatakan target cadangan<br/>(komponen) sebagai XML"]
    M --> P["Setiap writer menyiapkan datanya<br/>menggulung log, mem-flush cache, dll.<br/>menuju keadaan konsisten yang dapat dipulihkan"]
    P --> F["I/O tulis writer di-freeze<br/>(baca tetap diizinkan. Maksimal 60 detik)"]
    F --> FS["VSS mem-flush buffer sistem file<br/>lalu membekukan sistem file"]
    FS --> C["Provider membuat shadow copy<br/>(dalam 10 detik. Selama ini I/O tulis dibekukan)"]
    C --> T["Sistem file dilepas → writer di-thaw<br/>aplikasi melanjutkan penulisan"]
    T --> B["Requester menjalankan cadangan dari<br/>shadow copy, dengan waktu yang cukup"]

Gambar 1: Alur pembuatan shadow copy. Yang benar-benar berhenti hanya beberapa detik hingga puluhan detik; cadangan itu sendiri dijalankan terhadap snapshot.

Ada tiga poin yang perlu dicatat.

1. Aplikasi hanya berhenti sekejap yang dibutuhkan untuk membuat titik konsistensi. Freeze dibatasi 60 detik, dan pembuatan (commit) oleh provider dibatasi 10 detik; lampaui salah satunya dan pembuatan dibatalkan lalu requester mencoba lagi.¹ Cadangan yang sesungguhnya, yang bisa memakan waktu berjam-jam, dijalankan terhadap shadow copy baca-saja yang sudah jadi sementara aplikasi terus berjalan.
2. Baca tetap mungkin selama freeze. Hanya I/O tulis yang berhenti.¹
3. Sistem file juga dibekukan. Karena VSS mem-flush buffer sistem file sebelum membekukan, tulis yang duduk di cache, dan metadata sistem file, tercermin di snapshot dalam urutan yang konsisten.¹

4.3. Crash consistency dan application consistency

Di sinilah muncul pembedaan penting yang menentukan kualitas cadangan.

Shadow copy yang dibuat tanpa kerja sama writer berada dalam keadaan yang dalam istilah Microsoft disebut crash consistent. Definisi resminya adalah «keadaan disk yang setara dengan keadaan yang akan ditemukan setelah kegagalan katastropik yang mematikan sistem secara tiba-tiba», dan memulihkan darinya digambarkan sebagai «setara dengan mulai ulang setelah pematian mendadak».³ Sebagai sistem file ia tidak rusak, tetapi dari sudut pandang aplikasi itu «saat daya ditarik sementara ia sedang menulis». Basis data dengan mekanisme pemulihan log transaksi sering bisa pulih dari ini, tetapi pemrosesan pemulihan harus dijalankan lebih dulu — itu prasyarat, bukan bonus.

Dengan kerja sama writer, setiap writer menggulung log transaksinya dan mem-flush cachenya tepat sebelum titik konsistensi, membawa data ke keadaan konsisten yang dijamin aplikasi itu sendiri dapat dipulihkan dengan benar.¹ Inilah application consistency, dan itulah seluruh alasan mekanisme writer ada. Yang perlu dicatat: yang dijamin writer adalah «keadaan konsisten yang dapat dipulihkan sejauh menyangkut aplikasi» — ia tidak diam-diam meng-commit dan menyelesaikan transaksi yang sedang berjalan atas nama Anda. Pekerjaan yang belum di-commit di-rollback saat pemulihan, sama seperti pemulihan basis data biasa. Writer menyampaikan jaminan kualitas ini tanpa menghentikan aplikasi, memakai tidak lebih dari freeze yang berlangsung puluhan detik.

Alasan perangkat lunak cadangan punya pengaturan seperti «gunakan VSS» atau «jamin konsistensi aplikasi» justru adalah pembedaan ini. Untuk kumpulan file biasa di file server, crash consistency jarang menjadi masalah; tetapi di server yang menampung basis data atau mail store, apakah writer yang sesuai sehat, itu sendiri adalah kualitas cadangannya.

5. Operasi VSS sehari-hari — vssadmin dan «Versi Sebelumnya»

Alat yang dipakai staf TI dalam praktik untuk memeriksa keadaan VSS adalah vssadmin (jalankan dari Command Prompt yang ditinggikan). Referensi perintah terkini mencantumkan list shadows / list writers / delete shadows / resize shadowstorage sebagai tersedia di klien maupun server.⁴ Referensi yang berorientasi Windows Server tambahan mencantumkan create shadow / list shadowstorage / list providers, di antaranya.⁵ Catat bahwa vssadmin hanya bisa mengelola shadow copy yang dibuat provider sistem.¹

Jika list writers menampilkan writer dalam keadaan error, yang perlu dicurigai bukan VSS itu sendiri melainkan aplikasi yang menyediakan writer itu. Periksa keadaan layanan aplikasi pemilik dan log peristiwa Application/System (bagian 7).

/maxsize milik resize shadowstorage memungkinkan Anda menentukan batas dengan satuan seperti KB/MB/GB; biarkan tidak disetel dan tidak ada batas sama sekali. Yang perlu dicatat: dokumentasi Microsoft menyatakan secara eksplisit bahwa mengubah batas penyimpanan — mengecilkannya khususnya — itu sendiri bisa menyebabkan shadow copy hilang.¹⁰ Jangan dengan enteng mengecilkan batas di volume di mana Anda ingin menyimpan beberapa generasi.

5.1. Hubungan dengan «Versi Sebelumnya»

Mengaktifkan Shadow Copies of Shared Folders di file server secara berkala menahan salinan titik-waktu file di share, memungkinkan pengguna memulihkan file yang mereka hapus atau timpa dari Versi Sebelumnya tanpa bantuan administrator.¹ Ini penerapan VSS yang paling akrab, dan yang andal memangkas beban help desk.

Ada batasnya, bagaimanapun. Shadow copy provider sistem maksimal 512 per volume, di antaranya fitur Shadow Copies of Shared Folders menyimpan hingga 64 secara default (bisa diubah lewat nilai registri MaxShadowCopies).¹ Dan seperti dibahas dari bagian berikutnya, jika area selisih menipis, generasi tertua dihapus otomatis. Paling aman memahami bahwa «berapa generasi yang benar-benar Anda simpan» diputuskan bukan oleh angka yang Anda konfigurasikan, melainkan oleh seberapa banyak yang ditulis dan ukuran area selisih.

6. Sudut pandang pengembang — apakah aplikasi sendiri perlu VSS?

Dari sini, ini sudut pandang pengembang. Ketika Anda diminta «tambahkan fitur cadangan yang bisa menyalin file bahkan sementara sedang dipakai», bagaimana seharusnya Anda mendekati VSS?

6.1. Menulis requester sendiri adalah pekerjaan besar

API VSS, baik untuk requester maupun writer, disediakan sebagai antarmuka COM dan C++ (inti requester adalah IVssBackupComponents).⁶ Tidak ada pembungkus .NET resmi, dan Anda harus mengimplementasikan dengan benar segala sesuatu mulai dari mengumpulkan metadata writer, lewat mengelola kumpulan snapshot, hingga membersihkan setelah error — jadi ini bukan sesuatu yang bisa Anda pasang sambil lalu sebagai satu fitur aplikasi bisnis. Dalam perkiraan pengembangan kontrak kami sendiri, «membangun requester VSS» diperlakukan sebagai butir terpisah.

Ada dua jawaban realistis. Pertama, serahkan pada produk cadangan yang sudah sadar VSS. Kedua, di Windows Server, jalankan DiskShadow dari skrip. DiskShadow adalah requester VSS yang ikut OS; selain mode interaktif ia punya mode skrip (diskshadow /s script.txt), dan satu skrip bisa mencakup membuat shadow copy, mengeksposnya sebagai huruf drive (expose), menjalankan proses batch yang melakukan penyalinan (exec), dan membersihkan sesudahnya.⁷¹ Anda bisa membangun alur «buat shadow copy → tarik file darinya dengan logika salin sendiri → hapus» tanpa menulis satu baris COM pun. Namun, DiskShadow hanya untuk Windows Server dan tidak disertakan di edisi klien OS.¹ Jika PC klien juga masuk lingkup syarat, fakta itu sendiri mendorong ke arah mengadopsi produk cadangan yang sudah ada.

6.2. Apakah VSS bahkan diperlukan? — tabel keputusan

Dari pengalaman kami, sebagian besar permintaan «salin file yang sedang dipakai» bisa diselesaikan tanpa VSS. Pastikan persis tingkat syarat yang Anda hadapi sebelum memilih alat.

6.3. Haruskah aplikasi sendiri mendaftarkan writer?

Perlu juga memperjelas pertanyaan sebaliknya: haruskah aplikasi bisnis Anda menyediakan writer VSS? Jika Anda menulisnya, data aplikasi Anda dicadangkan dengan application consistency apa pun produk cadangan yang dipakai pelanggan. Ada juga mekanisme yang lebih ringan daripada writer biasa, express writer (IVssExpressWriter), tetapi yang dilakukannya hanyalah mendaftarkan metadata yang menyatakan file mana yang disertakan atau dikecualikan.⁶ Ia tidak menerima pemberitahuan freeze/thaw, jadi ia tidak bisa menjeda tulis aplikasi Anda agar selaras dengan pembuatan snapshot. Express writer hanya pantas ketika dipasangkan dengan desain penyimpanan yang tidak rusak meski ditangkap di tengah tulis (yaitu crash consistency sudah cukup); jika Anda benar-benar perlu koordinasi di titik konsistensi, Anda perlu implementasi writer penuh.

Itu dikatakan, aturan praktis untuk memutuskan sederhana.

• Jika data Anda hidup di basis data seperti SQL Server, Anda tidak memerlukannya. Writer basis data itu sendiri menjamin konsistensi.¹
• Untuk penyimpanan berbasis file yang sederhana, selesaikan dulu lewat desain rutin simpan. Jika Anda menulis tuntas ke file sementara lalu menukarnya masuk dengan ganti nama atomik, snapshot crash-consistent tidak akan pernah meninggalkan file simpan yang rusak.
• Mendaftarkan writer baru patut dipertimbangkan hanya untuk aplikasi yang mempertahankan toko data proprietary yang menjangkau beberapa file dan membutuhkan konsistensi bersama di antara mereka pada titik konsistensi. Bisa jadi lebih dulu patut ditinjau ulang apakah menahan sebanyak itu data dalam format buatan sendiri adalah keputusan yang tepat sama sekali.

7. Jebakan — empat hal yang benar-benar menusuk dalam operasi

7.1. VSS bukan cadangan itu sendiri

Ini jebakan paling penting. Shadow copy provider sistem adalah selisih yang duduk di disk mesin yang sama persis dengan data asli. Jika area selisih hilang, tidak ada yang tersisa untuk direkonstruksi, jadi ia tidak menawarkan perlindungan sama sekali terhadap kegagalan disk, mesin yang dicuri atau hilang, atau enkripsi seluruh volume. Dokumentasi Microsoft sendiri menarik garis tegas antara shadow copy dan cadangan: «isi yang disalin dari shadow copy ke media seperti pita adalah cadangan, dan shadow copy itu sendiri boleh dihapus setelah salinan itu dibuat.»¹ Shadow copy adalah titik konsistensi dan cara cepat pulih dari kesalahan — bukan pengganti cadangan yang disimpan di media terpisah di lokasi terpisah.

7.2. Error writer adalah masalah di sisi aplikasi

Ketika perangkat lunak cadangan gagal dengan «error VSS», mulailah dengan mengidentifikasi writer mana yang gagal, memakai vssadmin list writers. Karena writer, pada hakikatnya, adalah komponen milik aplikasi (atau komponen Windows)¹, medan utama menyelidiki penyebab adalah keadaan layanan aplikasi itu dan log peristiwanya. Terseret penampilan permukaan «error dari perangkat lunak cadangan» dan terus menyelidiki hanya perangkat lunak cadangan membawa Anda berputar jauh. Pola umum untuk mempersempit ini sama dengan yang dibahas di «Ketika Anda mewarisi sistem tanpa kode sumber dan tanpa dokumentasi — buku pedoman praktis agar tetap berjalan»: persempit daftar tersangka dari fakta yang benar-benar bisa Anda amati.

7.3. Ransomware datang untuk shadow copy Anda

Ini fakta yang patut diketahui semata-mata sebagai pertimbangan defensif. Menggoda untuk berharap bahwa jika Anda bisa mengembalikan dengan Versi Sebelumnya, Anda bisa pulih bahkan setelah terkena ransomware — tetapi sudah diketahui luas bahwa banyak ransomware menghapus shadow copy sebelum atau sesudah mengenkripsi, secara khusus untuk menutup jalur pemulihan ini. Menghapus shadow copy bisa dilakukan dengan perintah yang sepenuhnya sah selama Anda punya hak administrator, jadi ia tidak bisa menjadi garis pertahanan terakhir terhadap penyerang yang sudah masuk. Pilar penanggulangannya, maka, adalah: (1) perlakukan shadow copy sebagai «berguna jika ada» alih-alih sebagai «bagian dari rencana pemulihan»; (2) simpan cadangan offline di lokasi terpisah yang tidak bisa dijangkau penyerang; dan (3) jangan pernah memberikan hak administrator ke akun yang dipakai untuk operasi harian. Untuk pertahanan di seluruh siklus hidup PC, termasuk cadangan, enkripsi, dan pembuangan, lihat juga «Panduan praktis BitLocker — enkripsi drive yang dimulai dari pengelolaan kunci pemulihan» dan «Yang harus dilakukan sebelum membuang PC Windows — daftar periksa praktis penghapusan data, pelepasan akun, dan cadangan».

7.4. Ketika area selisih habis, generasi tertua menghilang diam-diam

Seperti dibahas di bagian 4, copy-on-write mengonsumsi area selisih hanya ketika setiap blok ditimpa untuk pertama kali setelah snapshot diambil. Menimpa blok yang sudah dipindahkan berapa kali pun selanjutnya tidak menambah konsumsi, jadi seberapa banyak yang terpakai diputuskan bukan oleh «berapa banyak tulis terjadi» melainkan oleh «seberapa luas rentang blok yang ditimpa sejak snapshot yang ditahan diambil.» Dan begitu area selisih mencapai batasnya, shadow copy volume itu dihapus, yang tertua lebih dulu.¹ Tidak ada yang diberitahukan ke pengguna interaktif, jadi ini sering baru ketahuan ketika «saya seharusnya bisa mengembalikan ke versi minggu lalu» ternyata tidak lagi benar. Ia tidak sepenuhnya sunyi, bagaimanapun: log System memang mencatat peristiwa dari sumber volsnap (event ID 25 ketika salinan dihapus karena ruang tidak bisa dibebaskan untuk area selisih, 35/36 ketika perluasan gagal atau dibatalkan setelah mencapai batas, dan seterusnya). Di luar pemeriksaan berkala, menyertakan peristiwa volsnap ini dalam pemantauan dan peringatan memungkinkan Anda menangkap kehilangan dengan cepat. Alasan operasi massal yang «menyapu seluruh volume» — pembaruan file massal, konversi batch, defragmentasi — bisa menelan area selisih sekaligus turun ke sifat ini: konsumsi diputuskan oleh rentang blok yang ditimpa. Periksa secara berkala apakah jumlah generasi yang Anda tahan masih memenuhi syarat bisnis («paling lama berapa hari bisa berlalu sebelum seseorang menyadari penghapusan yang tidak disengaja?») terhadap pemakaian yang ditampilkan vssadmin list shadowstorage, dan perlebar batas jika perlu.⁵¹⁰

8. Ringkasan

• Alasan file yang sedang dipakai biasanya tidak bisa disalin adalah soal pelanggaran berbagi dan konsistensi, dan itu mekanisme yang benar untuk melindungi data. VSS adalah jawaban tingkat OS untuk «saya ingin salinan yang konsisten tanpa menghentikan aplikasi.»
• VSS adalah kerangka di mana layanan VSS menengahi tiga peran — requester (meminta), writer (menjamin konsistensi), dan provider (membuat) — membiarkan perangkat lunak cadangan dan aplikasi bisnis yang tidak tahu apa-apa tentang satu sama lain bekerja sama.
• Provider sistem memakai copy-on-write, dan titik konsistensi dibuat lewat «freeze writer (hingga 60 detik) → buat (dalam 10 detik) → thaw.» Tanpa kerja sama writer Anda mendapat crash consistency; dengan kerja sama, application consistency.
• Periksa keadaan operasional dengan vssadmin (list shadows / list writers / list shadowstorage). Curigai sisi aplikasi untuk error writer, dan periksa pemakaian area selisih secara berkala.
• Pengembang harus lebih dulu memakai tabel keputusan untuk memeriksa apakah percobaan ulang, mode berbagi, jendela penghentian, atau desain integrasi bisa menyelesaikan masalah, dan beralih ke VSS hanya ketika benar-benar diperlukan. Skrip DiskShadow (hanya Server) atau produk yang sudah ada adalah jawaban realistis, di depan membangun implementasi sendiri.
• Shadow copy bukan cadangan. Ia tidak lebih dari selisih yang bergantung pada blok utuh volume asli; ia tak berdaya terhadap hilangnya volume asli itu, seperti pada kegagalan disk, dan ia juga tidak bisa diandalkan terhadap ransomware, mengingat shadow copy bisa dihapus atau area selisih dikuras. Pasangkan dengan cadangan offline yang disimpan di lokasi terpisah.

Artikel terkait

• Dasar eksklusi bersama untuk integrasi berbasis file — praktik terbaik kunci file dan klaim atomik
• Kedalaman I/O Windows (bagian 4) — Cache Manager: kapan WriteFile Anda benar-benar sampai ke disk?
• Kedalaman I/O Windows (bagian 5) — Interior NTFS: memahami sistem file lewat MFT
• Ketika Anda mewarisi sistem tanpa kode sumber dan tanpa dokumentasi — buku pedoman praktis agar tetap berjalan
• Panduan praktis BitLocker — enkripsi drive yang dimulai dari pengelolaan kunci pemulihan
• Yang harus dilakukan sebelum membuang PC Windows — daftar periksa praktis penghapusan data, pelepasan akun, dan cadangan

Area konsultasi terkait

KomuraSoft LLC menangani desain dan pengembangan aplikasi bisnis dengan fitur seperti «salin file yang sedang dipakai» dan cadangan, investigasi akar masalah pelanggaran berbagi seputar integrasi file dan kegagalan cadangan (error writer VSS), serta menata struktur operasional cadangan file server dan pengelolaan generasi. Kami senang memulai dari pertanyaan apakah VSS bahkan syarat yang tepat sejak awal.

• Pengembangan aplikasi Windows
• Investigasi bug dan akar masalah
• Konsultasi teknis dan tinjauan desain
• Hubungi kami

Tautan referensi

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Jika sudah ada shadow copy, apakah cadangan masih diperlukan?

Ya, tetap diperlukan. Shadow copy yang dibuat provider sistem standar Windows adalah selisih copy-on-write — bukan salinan lengkap volume pada saat itu yang disimpan terpisah, melainkan bergantung pada blok volume asli yang belum ditimpa. Bahkan jika area selisih (diff area) diletakkan di volume lain, faktanya tetap: jika volume asli hilang, pemulihan mustahil, dan ini tidak melindungi dari peristiwa yang menghabisi volume asli sepenuhnya, seperti kegagalan disk atau PC yang dicuri atau hilang. Hal yang sama berlaku untuk ransomware: operasi tulis saat enkripsi memang memindahkan blok sebelum-tulis ke area selisih, tetapi dalam serangan nyata shadow copy itu sendiri dihapus, atau area selisih dikuras oleh penimpaan massal, jadi ini tidak bisa diandalkan. Dokumentasi Microsoft sendiri membedakan keduanya dengan tegas: cadangan adalah data yang disalin dari shadow copy ke media seperti pita, dan setelah salinan itu dibuat, shadow copy itu sendiri boleh dihapus. Shadow copy adalah «snapshot titik waktu untuk mengambil cadangan» dan «cara cepat pulih dari kesalahan ringan» — bukan pengganti cadangan yang disimpan di media terpisah di lokasi terpisah.

Saya ingin aplikasi bisnis buatan sendiri menyalin file yang sedang dipakai — haruskah memakai VSS?

Langkah pertama yang realistis adalah mencari jalan agar tidak memerlukannya. Requester VSS harus ditulis terhadap API native berbasis COM (misalnya IVssBackupComponents), dan tidak ada pembungkus .NET resmi, jadi membangunnya ke dalam aplikasi sendiri adalah pekerjaan besar. Jika syaratnya hanya «pada akhirnya bisa membaca file yang sedang ditulis proses lain», percobaan ulang sudah cukup; jika «aplikasi lain mengizinkan berbagi baca», membuka file dengan mode berbagi yang cocok sudah cukup. Jika aplikasi bisa dihentikan sebentar, menyalin pada jeda alami operasional adalah opsi paling sederhana dan paling andal. VSS baru pantas dipakai ketika syaratnya «mereplikasi seluruh kumpulan data dari aplikasi yang tidak bisa dihentikan, dalam keadaan konsisten» — dan bahkan lalu, lihat dulu produk cadangan yang sadar VSS atau skrip DiskShadow sebelum membangun implementasi sendiri.

vssadmin list writers menampilkan writer dalam keadaan error. Apa yang harus dilakukan?

Pendekatan dasarnya adalah menyelidikinya sebagai masalah di sisi aplikasi yang memiliki writer itu. vssadmin list writers menampilkan writer yang terdaftar beserta keadaannya, jadi mulailah dengan mengidentifikasi writer mana yang gagal. Karena writer disediakan oleh aplikasi seperti SQL Server atau oleh komponen Windows (registri, misalnya), penyebabnya hampir selalu ada di keadaan layanan aplikasi pemilik, atau di error yang tercatat di log peristiwa Application/System, bukan di VSS itu sendiri. Mulai ulang layanan terkait dan persempit kondisi reproduksinya; jika itu tidak menyelesaikan, periksa informasi dukungan aplikasi tersebut. Ini juga langkah triase pertama yang tepat ketika perangkat lunak cadangan gagal dengan error VSS.

Shadow copy menghilang tanpa saya sadari. Mengapa?

Penyebab paling umum adalah area selisih (penyimpanan shadow copy) kehabisan ruang. Dengan copy-on-write, isi setiap blok dipindahkan ke area selisih pada kali pertama blok itu ditimpa setelah snapshot diambil, jadi semakin luas rentang blok yang ditimpa, semakin banyak area selisih yang terpakai. Begitu batas yang ditetapkan tercapai, Windows menghapus shadow copy tertua lebih dulu untuk membebaskan ruang. Ini terjadi diam-diam, tanpa pemberitahuan ke pengguna interaktif, jadi biasanya baru ketahuan ketika seseorang mengharapkan bisa mengembalikan versi minggu lalu dari Versi Sebelumnya dan ternyata tidak ada (log System memang mencatat peristiwa seperti event ID 25 dari sumber volsnap, jadi memantaunya memungkinkan Anda mengetahuinya). Periksa pemakaian dan batas dengan vssadmin list shadowstorage, dan naikkan batas dengan vssadmin resize shadowstorage jika perlu. Ingat, bagaimanapun, bahwa mengubah batas — terutama mengecilkannya — itu sendiri bisa menyebabkan shadow copy hilang.

Bagaimana hubungan «Versi Sebelumnya» di File Explorer dengan VSS?

«Versi Sebelumnya» adalah salah satu pintu masuk untuk mengambil versi lampau sebuah file dari shadow copy yang dibuat VSS. Di file server, mengaktifkan «Shadow Copies of Shared Folders» membuat shadow copy diambil menurut jadwal, dan pengguna bisa mengklik kanan file di folder berbagi lalu memulihkannya sendiri dari Versi Sebelumnya. Manfaatnya, pengguna bisa membatalkan penghapusan atau penimpaan yang tidak disengaja tanpa bantuan administrator. Tetapi karena di bawahnya dibangun di atas shadow copy, ada batas atas berapa generasi yang bisa disimpan, dan jika area selisih menipis, generasi tertua menghilang lebih dulu. Seperti dibahas di tubuh artikel, «kami punya Versi Sebelumnya» tidak berarti «kami tidak perlu cadangan».

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.