Paylaşılan Klasörlerde Volume Shadow Copy (VSS) Yapılandırması

Bir kullanıcının paylaşılan klasördeki bir Excel dosyasının üzerine yanlış veri kaydetmesi, bir klasörü yanlışlıkla silmesi veya bir dosyanın sabah halini istemesi, dosya sunucusu yöneten herkesin haftalık rutininin parçasıdır. Bu taleplerin her biri için yedekleme yazılımını açıp ilgili Job'u bulmak, doğru tarihi seçmek ve geri yükleme yapmak hem zaman alır hem de basit bir dosya talebini yönetici işine dönüştürür. Shadow Copies of Shared Folders, tam olarak bu boşluğu dolduran ve Windows Server'da yerleşik gelen bir özelliktir.

Özellik arka planda Volume Shadow Copy Service (VSS) altyapısını kullanır. Belirlenen zamanlarda Volume'un o anki hali Shadow Copy olarak kaydedilir ve bu Shadow Copy'ler, paylaşılan klasöre ağ üzerinden erişen kullanıcılara Previous Versions sekmesi üzerinden sunulur. Böylece kullanıcı, yetkisi olan bir dosyanın veya klasörün önceki halini kendisi açabilir, başka bir yere geri yükleyebilir veya mevcut içeriğin üzerine geri yazabilir.

Burada doğru beklentiyi baştan kurmak gerekiyor. Shadow Copy bir yedekleme çözümü yerine geçmez. Shadow Copy'ler, Diff Area adı verilen bir depolama alanında tutulur ve bu makaledeki senaryoda Diff Area, verilerin bulunduğu D:\ Volume'unun kendisi üzerindedir. Diskin arızalanması, Volume'un bozulması veya sunucunun kaybedilmesi durumunda Shadow Copy geçmişi de kaybolur. Özelliğin gerçek değeri, kısa vadeli ve kullanıcı kaynaklı geri dönüşleri hızlı ve self-service şekilde karşılamasıdır.

Makale boyunca önce Copy-on-Write mekanizmasının nasıl çalıştığına bakacağız, ardından D:\ üzerinde özelliği etkinleştirip depolama alanını ve Schedule'ı yapılandıracağız. Sonrasında Client tarafında önceki sürüme dönüşü, Diff Area boyutlandırmasını, vssadmin ile yönetimi ve iki Shadow Copy arasında hangi dosyaların değiştiğinin PowerShell ile nasıl raporlanacağını ele alacağız.

İşe mekanizmadan başlamak gerekiyor, çünkü depolama planlamasıyla ilgili yanlış kararların neredeyse tamamı bu noktanın yanlış anlaşılmasından doğuyor. Windows'un varsayılan VSS System Provider'ı Copy-on-Write yöntemiyle çalışır ve Shadow Copy alındığı anda Volume'un tam bir kopyası oluşturulmaz.

Shadow Copy alındıktan sonra D:\ üzerindeki bir blok değiştirilmek istendiğinde, VSS önce o bloğun eski içeriğini Diff Area'ya kopyalar ve yeni veri ancak bundan sonra yazılır. Diff Area aynı Volume üzerinde tutulduğunda bu veriler D:\ altındaki System Volume Information klasöründe saklanır. Shadow Copy'ye erişildiğinde değişmemiş bloklar doğrudan Volume'un güncel halinden, değişmiş blokların eski hali ise Diff Area'dan okunur.

Shadow Copy anı (T0)
        |
        v
D:\ Volume
+------------------------------------------------+
| Üretim verisi                                  |
|   Blok A  (T0 hali)                            |
|   Blok B  (T0 hali)                            |
|                                                |
| Diff Area (System Volume Information)          |
|   (boş)                                        |
+------------------------------------------------+

T0 sonrası Blok B değiştirilmek istenir
        |
        v
1. Blok B'nin T0 hali D:\ üzerindeki Diff Area'ya kopyalanır
2. Yeni veri Blok B'ye yazılır

Shadow Copy okunurken:
Blok A  -> Üretim verisinden (değişmedi)
Blok B  -> Diff Area'dan (T0 hali)

Bu davranışın pratik sonucu olarak Diff Area'yı büyüten şey D:\ Volume'unun boyutu değil, Shadow Copy'den sonra değişen blokların miktarıdır. Bu yüzden ilk Shadow Copy oluşturulduğu anda Volume boyutunun belirli bir yüzdesi kadar alan tüketilmez. Oluşturma anında yalnızca VSS Metadata ve Index bilgisi için az miktarda alan kullanılır, tüketim değişen bloklarla birlikte artar.

Yapılandırma, D:\ Volume'unun Properties penceresindeki Shadow Copies sekmesinden başlar. Bu sekmeye en kısa yoldan File Explorer'da sürücüye sağ tıklayıp Configure Shadow Copies seçeneğiyle ulaşılır. Açılan pencerede sunucudaki Volume'lar ve her birinin Shadow Copy durumu listelenir.

Özelliğin paylaşım bazında değil, Volume bazında çalıştığını unutmamak gerekir. D:\ üzerinde etkinleştirilen Shadow Copy, o Volume üzerindeki tüm paylaşılan klasörler için geçerli olur.




Enable butonuna basmadan önce Settings ekranına geçmek doğru sıralamadır. Burada Diff Area'nın hangi Volume üzerinde tutulacağı ve bu alan için ne kadar limit tanımlanacağı belirlenir. Located on this volume alanında bu senaryo için D:\ seçili bırakılır, yani Shadow Copy'ler verilerin bulunduğu Volume üzerinde tutulur. Bu konum, ilk Shadow Copy alınmadan önce belirlenmelidir, çünkü konumu sonradan değiştirmek mevcut Shadow Copy geçmişini korumaz.



Aynı ekrandaki Maximum size bölümü, bu yapılandırmanın en belirleyici ayarıdır. Use limit seçeneğiyle Diff Area için MB cinsinden sabit bir üst sınır verilir, No limit ile alan sınırsız bırakılır. Bu değer, kullanıcıların Previous Versions sekmesinde ne kadar geriye gidebileceğini doğrudan belirler. Diff Area limite ulaştığında VSS en eski Shadow Copy'leri silerek yer açar, yani düşük bir limit Schedule ne olursa olsun geçmişin kısa kalmasına yol açar.

Bu ortamda Use limit alanında 10238 MB değeri görünür. Bu, arayüzün sunduğu bir başlangıç değeridir ve ortamın veri değişim oranını hesaba katmaz. Bu yüzden olduğu gibi bırakılmamalı, makalenin ilerleyen bölümünde anlatılan gözleme dayalı hesapla belirlenmelidir. Limit sonradan aynı ekrandan veya vssadmin resize shadowstorage komutuyla değiştirilebilir. Ekranın altındaki not ise Shadow Copy oluşturulabilmesi için Volume üzerinde en az 300 MB boş alan bulunması gerektiğini hatırlatır.

Diff Area, D:\ üzerinde tutulduğu için Shadow Copy'ler ile üretim verisi aynı boş alanı paylaşır. Limit, D:\ üzerindeki verinin büyümesine yetecek kadar boş alan bırakacak şekilde belirlenmelidir. Aynı Volume kullanımının bir diğer sonucu da Copy-on-Write yazmalarının üretim verisiyle aynı diskin I/O kapasitesini paylaşmasıdır. Tipik bir dosya sunucusunda bu yük genellikle hissedilmez, ancak yoğun yazma alan Volume'larda göz önünde tutulması gereken bir noktadır.

Settings ekranındaki Schedule butonu, Shadow Copy'lerin ne zaman alınacağını belirler. Varsayılan Schedule hafta içi her gün 07:00 ve 12:00 olmak üzere günde iki Shadow Copy alır. Bu zamanlama çoğu dosya sunucusu için makul bir başlangıçtır, ancak kullanıcıların gün içinde hangi aralıklarla geri dönüş talep ettiğine göre ayarlanmalıdır.

Örneğin mesai sonuna bir Shadow Copy daha eklemek, gün içinde yapılan değişikliklerin ertesi sabaha kadar geri alınabilir kalmasını sağlar. Microsoft, Shadow Copy'lerin saatte birden daha sık alınmamasını önerir ve bu uyarı Settings ekranının Schedule bölümünde de yer alır. Daha sık alınan Shadow Copy'ler Diff Area tüketimini artırır ve geçmişin daha hızlı tükenmesine yol açar.



Ayarlar tamamlandıktan sonra Shadow Copies penceresine dönüp Enable butonuna basıldığında Windows, ilk Shadow Copy'yi hemen oluşturur ve tanımlanan Schedule'ı Task Scheduler üzerinde bir görev olarak kaydeder. D:\ satırında Next Run Time sütunu bir sonraki planlı çalışmayı, Shares sütunu Volume üzerindeki paylaşım sayısını, Used sütunu ise Diff Area için kullanılan alanı gösterir.

Bu ortamda Used sütununda görülen değerin, vssadmin çıktısındaki Allocated Shadow Copy Storage space değeriyle aynı olduğu gözlemlenmiştir. Pencerenin alt bölümünde de oluşturulan ilk Shadow Copy tarih ve saatiyle listelenir.



Create Now butonu, Schedule'ı beklemeden manuel bir Shadow Copy almak için kullanılır. Büyük bir dosya taşıma işlemi veya toplu değişiklik öncesinde manuel bir Shadow Copy almak, olası bir hatada dönülecek net bir nokta bırakır. Aşağıdaki ekranda, ilk Shadow Copy'den sonra paylaşımdaki verilerde 8 dosya silinmiş, 12 dosya değiştirilmiş, 6 dosya yeniden adlandırılmış ve 6 yeni dosya oluşturulmuş, ardından Create Now ile ikinci bir Shadow Copy alınmıştır.



Aynı türde değişiklikler bir kez daha yapılıp Create Now ile üçüncü Shadow Copy alındığında liste üç girdiye çıkar. Used sütunundaki değer bu arada yalnızca birkaç MB artar. VSS, Diff Area için alanı parçalar halinde önceden ayırdığı için bu değer değişen veri miktarını birebir yansıtmaz, ancak Volume'un tamamının değil yalnızca değişikliklerin yer kapladığını açıkça gösterir.



Asıl kazanımın görüldüğü yer istemci tarafıdır. Kullanıcı \\SunucuAdı yolu üzerinden sunucuya eriştiğinde, paylaşımın kendisine, içindeki bir klasöre veya dosyaya sağ tıklayıp Properties penceresindeki Previous Versions sekmesini açar. Sekmede, seçilen öğenin Shadow Copy'ler içindeki halleri tarih ve saat bilgisiyle listelenir ve sunucu tarafında alınan her Shadow Copy'nin zaman damgası burada birebir karşılık bulur.

Listede yalnızca seçilen öğenin gerçekten farklı olduğu sürümler görünür. Bir dosya iki Shadow Copy arasında hiç değişmediyse aynı sürüm iki kez gösterilmez. Paylaşım veya klasör düzeyinde ise içerikteki herhangi bir değişiklik, o sürümün listede yer alması için yeterlidir. Aşağıdaki ekranda paylaşım düzeyinde bakıldığı için sunucuda alınan üç Shadow Copy'nin üçü de listelenir.



Windows 8 ve sonraki Windows Client sürümlerinde bu sekmede Open ve Restore olmak üzere iki buton bulunur. Bir sürüm seçilip Open butonuna basıldığında, o sürüm salt okunur olarak açılır.



Paylaşım veya klasör düzeyinde kullanıldığında Open, o Shadow Copy anındaki tüm klasör yapısını ve dosyaları File Explorer'da gezilebilir halde görüntüler. Adres çubuğunda paylaşım adının yanında Shadow Copy'nin tarihi ve ne kadar süre önce alındığı yer alır. Kullanıcı bu pencerede alt klasörlere girip dosyaları açabilir ve doğru sürümü bulup bulmadığını kontrol edebilir.



Open penceresi, silinmiş dosyaların geri getirilmesinde de en pratik yoldur. Silinmiş bir dosyaya sağ tıklanamaz, ancak bulunduğu klasörün veya paylaşımın Previous Versions sekmesinden silme işleminden önceki bir sürüm Open ile açıldığında, silinmiş dosyalar o pencerede yerinde durur. Gerekli dosyalar buradan seçilip asıl konuma veya başka bir yere kopyalanabilir.

Restore ise seçilen sürümü asıl konuma geri yazar ve aynı adlı mevcut dosyaların üzerine yazar. Restore butonunun yanındaki oktan açılan Restore To seçeneği sürümü farklı bir konuma geri yükler ve mevcut içeriğe dokunmaz. Kullanıcıya önerilecek pratik yol, önce Open ile sürümü doğrulamak, mevcut içerikte korunması gereken değişiklikler varsa Restore yerine Restore To kullanmak veya ihtiyaç duyulan dosyaları Open penceresinden kopyalamaktır.

Restore işleminin ve geri kopyalamanın, kullanıcının asıl konuma yazma yetkisine sahip olmasını gerektirdiğini de hatırlatmak gerekir. Shadow Copy, kullanıcıya NTFS ve Share izinlerinin izin verdiğinden fazlasını açmaz.

Özellik çalışmaya başladıktan sonra en sık sorulan soru, Diff Area için ne kadar alan ayrılması gerektiğidir. Volume boyutuna bağlı evrensel bir yüzde kuralı yoktur ve sıkça dolaşan %10-%20 gibi oranlar Microsoft'un belgelenmiş bir önerisi değildir. Gerekli alanı belirleyen üç faktör veri değişim oranı, Shadow Copy sıklığı ve geriye dönük tutulmak istenen geçmiş, yani Retention süresidir.

Bunu somut bir senaryoyla düşünelim. Veriler, 10 TB büyüklüğünde D:\ Volume'unda duruyor ve Shadow Copy'ler de aynı Volume üzerinde tutulacak. Diff Area limiti, D:\ boyutunun bir yüzdesi olarak hesaplanmaz. Doğru yaklaşım, Shadow Copy'yi etkinleştirip bir süre gerçek kullanımı gözlemlemek, ortalama günlük değişen veri miktarını bulmak ve kaba bir başlangıç tahmini yapmaktır. Gözlem için aşağıdaki komut kullanılır.

vssadmin list shadowstorage

Çıktıdaki satırların karşılığı aşağıdaki tabloda yer alır.

Çıktıda Used Shadow Copy Storage space değerinin (5.95 MB) Allocated Shadow Copy Storage space değerinin (484 MB) oldukça altında kaldığı görülür. Daha önce D:\ sürücüsüne sağ tıklayıp Configure Shadow Copies ile açılan Shadow Copies penceresine bakıldığında, D:\ satırındaki Used sütununda da aynı 484 MB değerinin yer aldığı görülür. Yani bu penceredeki Used sütunu fiili kullanımı değil, vssadmin çıktısındaki Allocated değerini gösterir. Bu nedenle günlük değişimin gözleminde pencere yerine vssadmin çıktısındaki Used değeri, diskte fiilen ne kadar yer kaplandığının takibinde ise Allocated değeri esas alınmalıdır.

Başlangıç tahmini için günlük değişen veri ile tutulacak gün sayısı çarpılır ve üzerine bir büyüme payı eklenir. Varsayımsal değerlerle, günde ortalama 50 GB veri değişiyorsa ve 14 günlük geçmiş isteniyorsa 50 x 14 = 700 GB eder. Pay eklendiğinde yaklaşık 1 TB boyutunda bir limit makul bir başlangıç olur. Bu senaryoda D:\ üzerinde üretim verisinin büyüme ihtiyacına ek olarak bu 1 TB'lık alanın da ayrılabilir olması gerekir.

Bu Microsoft'un formülü değil, gözleme dayalı bir başlangıç tahminidir. Copy-on-Write'ta aynı blok iki Shadow Copy arasında birden fazla kez değişse de yalnızca bir kez kopyalanır, buna VSS Metadata ve Index overhead'i de eklenir. Bu nedenle gerçek tüketim hesaptan farklı çıkabilir ve limit, gerçek kullanıma göre sonradan ayarlanmalıdır.

Değişim oranının Diff Area üzerindeki etkisi, dosya boyutundan bağımsızdır. Birkaç dosyanın güncellendiği veya küçük dosyaların eklendiği bir paylaşımda Diff Area yavaş büyür ve uzun bir geçmiş tutulabilir. Büyük bir Database dosyasının her gün yoğun şekilde değiştiği bir Volume'da ise Diff Area hızlı dolar ve eski Shadow Copy'ler daha erken silinir.

Belirleyici olan değişen blok miktarıdır. 500 GB'lık bir dosyanın yalnızca küçük bir kısmı değişiyorsa Diff Area'ya yalnızca o bloklar kopyalanır.

Aynı mantık, kaç Shadow Copy tutulabileceği sorusu için de geçerlidir. Shadow Copy'ler birbirinden bağımsız, sabit boyutlu dosyalar değildir. Diff Area, ortak değişmiş bloklar ve Index bilgisi üzerinden çalışır. Bu yüzden ayrılan alanı ortalama Snapshot boyutuna bölerek Snapshot sayısı hesaplamak güvenilir sonuç vermez.

Tutulabilecek geçmişi belirleyenler veri değişim oranı, Shadow Copy zamanlaması, Diff Area limiti ve Volume başına Shadow Copy sayısı sınırıdır. Shadow Copies of Shared Folders için MaxShadowCopies değeri varsayılan olarak 64'tür ve VSS bu Registry değerinde teknik olarak en fazla 512'yi destekler. Bu sınıra ulaşıldığında Diff Area'da yer olsa bile yeni bir Shadow Copy alınırken en eski Shadow Copy silinir.

Ancak Windows Server 2012 ve sonraki sürümlerde SMB Server, paylaşıma bağlanan kullanıcılara Volume başına en fazla 500 Previous Version listeleyebilir. Daha uzun bir geçmiş için MaxShadowCopies değeri, izin verilen en yüksek değer olan 512'ye çıkarıldığında sunucuda 512 Shadow Copy tutulur, fakat kullanıcının Previous Versions sekmesinde bunların yalnızca 500'ü görünür. Görünmeyen 12 Shadow Copy ise en eski değil, en yeni olanlardır. Kullanıcıların en sık ihtiyaç duyduğu son sürümler listeden düştüğü için paylaşılan klasör senaryosunda MaxShadowCopies değeri 512 yerine 500 olarak ayarlanmalıdır.

reg add "HKLM\SYSTEM\CurrentControlSet\Services\VSS\Settings" /v MaxShadowCopies /t REG_DWORD /d 500 /f

Alan dolduğunda ne olacağı da netleştirilmesi gereken bir konudur. Diff Area aynı Volume üzerinde olsa da Shadow Copy verisi üretim verisinin üzerine yazılmaz. Diff Area limitine ulaşıldığında veya D:\ üzerindeki boş alan tükendiğinde VSS, Shadow Copy'leri en eskiden başlayarak silebilir. Kaybedilen şey üretim verisi değil, mevcut Shadow Copy ve Previous Versions geçmişidir.

D:\ Volume'unun tamamen dolması ise ayrıca normal dosya sistemi ve uygulama sorunlarına yol açar. Diff Area ile üretim verisi aynı boş alanı paylaştığı için D:\ üzerindeki boş alanın düzenli izlenmesi bu senaryoda daha da önemli hale gelir.

Grafik arayüzün yaptığı her şey komut satırından da yönetilebilir. Aşağıdaki komutlar mevcut Shadow Copy'leri ve depolama ilişkilerini listeler, manuel Shadow Copy oluşturur, D:\ için Diff Area'yı yine D:\ üzerinde tanımlar, limiti değiştirir ve Shadow Copy'leri siler. Komutlar yükseltilmiş, yani Run as Administrator ile açılmış bir CMD veya PowerShell penceresi gerektirir.

vssadmin list shadows
vssadmin list shadowstorage

vssadmin create shadow /for=D:

vssadmin add shadowstorage /for=D: /on=D: /maxsize=1TB
vssadmin resize shadowstorage /for=D: /on=D: /maxsize=1TB

vssadmin delete shadows /for=D: /oldest
vssadmin delete shadows /for=D: /all

add shadowstorage, D:\ için henüz bir depolama ilişkisi tanımlanmamışsa kullanılır. Özellik arayüzden etkinleştirildiyse bu ilişki zaten oluşmuştur ve limit resize shadowstorage ile değiştirilir.

/maxsize parametresi sabit bir değer (örneğin 1TB), Volume'un yüzdesi (örneğin 15%) veya UNBOUNDED olarak verilebilir. Diff Area üretim verisiyle aynı Volume'da tutulduğu için UNBOUNDED kullanmak, Shadow Copy'lerin D:\ üzerindeki boş alanı sınırsız şekilde tüketebilmesi anlamına gelir. Bu senaryoda sabit bir limit tercih etmek daha öngörülebilir bir kapasite yönetimi sağlar.

Previous Versions sekmesi bir dosyanın veya klasörün hangi sürümlerinin bulunduğunu gösterir, ancak iki Shadow Copy arasında tam olarak hangi dosyaların eklendiğini, silindiğini veya değiştiğini listelemez. Bir kullanıcı dün öğleden sonra bir klasörde neyin değiştiğini sorduğunda ya da toplu bir silme işleminin kapsamı belirlenmek istendiğinde bu bilgiye ihtiyaç duyulur.

Bunun için Shadow Copy'lerin paylaşım üzerinden doğrudan erişilebilir olmasından yararlanılır. Her Shadow Copy, paylaşım yolunun sonuna eklenen @GMT ile başlayan bir zaman damgasıyla açılabilir. Örneğin \\ABCISTSRVFS01\corporate data\@GMT-2026.10.11-21.14.47 yolu, İstanbul saati UTC+3 iken o paylaşımın 12 Ekim 00:14:47'deki halini gösterir. Open penceresinde açılan klasörlerin konumuna bakıldığında da bu yapı görülür.

Bu zaman damgası UTC cinsindendir. Sunucu saati İstanbul'a, yani UTC+3'e göre ayarlı olduğu için 12 Ekim 00:14'te alınan Shadow Copy, damgada 11 Ekim 21:14 olarak görünür. Doğru değerleri elle hesaplamak yerine sunucuda aşağıdaki komut çalıştırılarak her Shadow Copy'nin yerel saati ve karşılık gelen @GMT değeri listelenir.

Get-CimInstance Win32_ShadowCopy | Sort-Object InstallDate | ForEach-Object {
    [PSCustomObject]@{
        LocalTime = $_.InstallDate
        GMTToken  = $_.InstallDate.ToUniversalTime().ToString("'@GMT-'yyyy.MM.dd-HH.mm.ss")
    }
}

Çıktıdaki LocalTime sütunu Shadow Copies penceresinde ve Previous Versions sekmesinde görülen saatle, GMTToken sütunu ise paylaşım yolunda kullanılacak değerle birebir eşleşir.



Bu değerler alındıktan sonra karşılaştırma, aşağıdaki Compare-VSSSnapshot.ps1 Script'iyle yapılır. Script, listedeki her Shadow Copy'yi bir sonrakiyle karşılaştırır. Her iki Shadow Copy içindeki dosyaları alt klasörlerle birlikte tarar, dosyaları paylaşım içindeki göreli yollarına göre eşleştirir ve boyutu veya son değiştirilme zamanı farklı olanları Modified, yalnızca yenide bulunanları Added, yalnızca eskide bulunanları Removed olarak işaretler.

Sonuç, ekrana yazılırken aynı zamanda Script'in bulunduğu klasöre tarih ve saat damgalı bir TXT dosyası olarak da kaydedilir. Kullanmadan önce $share değişkenine kendi paylaşım yolunuzu, $snapshots listesine de bir önceki komutun çıktısındaki GMTToken değerlerini yazmanız yeterlidir. Label değerleri yalnızca rapor başlığında görünen serbest metinlerdir ve karşılaştırmayı etkilemez. Bu örnekte Shadow Copies penceresindeki 12 saatlik gösterimle aynı olsun diye 12:03, 12:11 ve 12:14 olarak yazılmıştır, yani 24 saat formatında 00:03, 00:11 ve 00:14'e karşılık gelir. Script, paylaşıma okuma yetkisi olan herhangi bir makinede çalıştırılabilir.

$share = "\\ABCISTSRVFS01\corporate data"

$snapshots = @(
    @{ Label = "12:03"; Token = "@GMT-2026.10.11-21.03.02" },
    @{ Label = "12:11"; Token = "@GMT-2026.10.11-21.11.02" },
    @{ Label = "12:14"; Token = "@GMT-2026.10.11-21.14.47" }
)

$logFile  = Join-Path $PSScriptRoot ("Compare-VSSSnapshot_{0}.txt" -f (Get-Date -Format "yyyyMMdd_HHmmss"))
$utf8Bom  = New-Object System.Text.UTF8Encoding($true)

function Write-Log($text) {
    Write-Host $text
    [System.IO.File]::AppendAllText($logFile, $text + [Environment]::NewLine, $utf8Bom)
}

function Get-Snap($root) {
    $h = @{}
    Get-ChildItem -LiteralPath $root -Recurse -File | ForEach-Object {
        $h[$_.FullName.Substring($root.Length)] = $_
    }
    return $h
}

Write-Log ("Compare-VSSSnapshot  |  {0}  |  {1}" -f (Get-Date -Format "yyyy-MM-dd HH:mm:ss"), $share)

for ($i = 0; $i -lt $snapshots.Count - 1; $i++) {
    $oldLabel = $snapshots[$i].Label
    $newLabel = $snapshots[$i + 1].Label
    $ha = Get-Snap "$share\$($snapshots[$i].Token)"
    $hb = Get-Snap "$share\$($snapshots[$i + 1].Token)"

    $result = foreach ($p in (@($ha.Keys) + @($hb.Keys) | Sort-Object -Unique)) {
        if (-not $hb.ContainsKey($p))     { [PSCustomObject]@{ Change = 'Removed';  Path = $p } }
        elseif (-not $ha.ContainsKey($p)) { [PSCustomObject]@{ Change = 'Added';    Path = $p } }
        elseif ($ha[$p].Length -ne $hb[$p].Length -or $ha[$p].LastWriteTime -ne $hb[$p].LastWriteTime) {
                                            [PSCustomObject]@{ Change = 'Modified'; Path = $p } }
    }

    Write-Log ""
    Write-Log "===== $oldLabel  ->  $newLabel ====="
    Write-Log ($result | Sort-Object Change, Path | Format-Table -AutoSize | Out-String -Width 300).TrimEnd()
    Write-Log ""
    Write-Log ($result | Group-Object Change | Sort-Object Name | Select-Object Name, Count | Format-Table -AutoSize | Out-String).TrimEnd()
}

Write-Log ""
Write-Log "Log: $logFile"

Script kaydedilip çalıştırılmak istendiğinde, özellikle Windows Client işletim sistemlerinde running scripts is disabled on this system hatası alınabilir. Bunun nedeni PowerShell Execution Policy ayarının Script çalıştırmaya izin vermemesidir. Sistem genelindeki politikayı değiştirmeden, yalnızca açık olan PowerShell penceresi için Script çalıştırmaya izin vermek üzere aşağıdaki komut kullanılır.

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

Script çalıştırıldığında her aralık için ayrı bir başlık, altında değişen dosyaların listesi ve en altta her değişiklik türünün sayısı yer alır. Son satırda da oluşturulan log dosyasının tam yolu yazdırılır.



Sonuçlar test sırasında yapılan değişikliklerle birebir örtüşür. Burada bilinmesi gereken tek nokta, yeniden adlandırılan dosyaların nasıl göründüğüdür. Script dosyaları adlarına göre eşleştirdiği için adı değişen bir dosyayı iki ayrı kayıt olarak görür. Eski adı artık bulunmadığı için Removed, yeni adı daha önce olmadığı için Added olarak listelenir. Modified ise yalnızca adı aynı kalıp boyutu veya son değiştirilme zamanı farklılaşan dosyalar için kullanılır, bu yüzden yeniden adlandırılan bir dosya hiçbir zaman Modified olarak görünmez.

Bu yüzden her aralıkta silinen 8 dosyaya yeniden adlandırılan 6 dosyanın eski adları eklenir ve toplam 14 Removed görünür. Yeni oluşturulan 6 dosyaya yeniden adlandırılan 6 dosyanın yeni adları eklenir ve toplam 12 Added görünür. İçeriği değiştirilen 12 dosya ise doğrudan 12 Modified olarak listelenir.

Ekrandaki çıktının aynısı Log dosyasına da yazılır. Dosya, Windows'un karakter kodlamasını doğru tanıyabilmesi için UTF-8 with BOM olarak kaydedilir. BOM, dosyanın başına eklenen ve içeriğin UTF-8 olduğunu belirten küçük bir işarettir. Bu işaret olmadığında bazı Windows araçları Türkçe karakterleri ve özel karakterleri bozuk gösterebilir.

PowerShell'in kendi Out-File komutu bu konuda sürüme göre farklı davranır. Windows PowerShell 5.1'de BOM'lu, PowerShell 7'de ise BOM'suz dosya üretir. Script, bu farktan etkilenmemek için Log dosyasını doğrudan .NET üzerinden UTF-8 with BOM olarak yazar. Böylece hangi PowerShell sürümüyle çalıştırılırsa çalıştırılsın aynı log dosyası oluşur ve bu dosya bir olay kaydı ya da kullanıcıya iletilecek rapor olarak doğrudan kullanılabilir.




Shadow Copies of Shared Folders doğru planlandığında, kullanıcı kaynaklı dosya kayıplarının büyük bölümü yöneticiye hiç ulaşmadan Previous Versions sekmesinden çözülür. Tek Volume'lu bir yapıda sağlıklı bir kurulum için Diff Area limitini ilk Shadow Copy'den önce ve D:\ üzerindeki verinin büyümesine yer bırakacak şekilde belirlemek, Schedule'ı kullanıcıların gerçek ihtiyacına göre ayarlamak ve limiti birkaç haftalık vssadmin gözlemine göre güncellemek yeterlidir.

Uzun vadeli koruma ve felaket senaryoları için ise ayrı bir yedekleme çözümü her zaman bu yapının yanında yer almalıdır.

Bu makalede, Windows Server üzerinde Shadow Copies of Shared Folders özelliğiyle paylaşılan klasörlerdeki dosyaların önceki sürümlerine nasıl dönülebileceği, verilerin ve Diff Area'nın aynı Volume üzerinde tutulduğu bir senaryo üzerinden ele alındı.

Özelliğin arka planında çalışan Volume Shadow Copy Service, Copy-on-Write yöntemiyle yalnızca değişen blokların eski halini saklar. Bu nedenle Diff Area ihtiyacı Volume boyutuna göre değil, veri değişim oranı, Shadow Copy sıklığı ve Retention süresine göre belirlenir ve Use limit değeri bu üç faktöre göre planlanmalıdır.

İstemci tarafında Previous Versions sekmesi, kullanıcıların NTFS ve Share izinleri çerçevesinde paylaşım, klasör ve dosyaların önceki hallerini Open ile görüntülemesine, Restore veya Restore To ile geri yüklemesine imkan tanır. Volume başına Shadow Copy sınırı, MaxShadowCopies Registry değeri ve SMB Server'ın 500 sürüm sınırı, tutulabilecek geçmişin planlanmasında dikkate alınması gereken noktalardır.

vssadmin ile depolama ilişkisinin ve limitin yönetimi, @GMT zaman damgaları üzerinden PowerShell Script'iyle Shadow Copy'ler arasındaki dosya değişikliklerinin raporlanması ise yönetici tarafındaki operasyonel ihtiyaçları karşılar. Shadow Copy kısa vadeli geri dönüşler için güçlü bir araçtır, ancak bir yedekleme stratejisinin yerini tutmaz.

Faydalı olması dileğiyle...