Windows sunucu yedekleme: restic ile Windows Server'dan S3 uyumlu depolamaya VSS destekli, şifreli ve zamanlanmış yedek

Windows sunucu yedekleme işini çoğu şirket aynı sunucudaki ikinci diske ya da ofisteki bir NAS'a bırakır. Disk arızasında bu yeterli olabilir. Ama fidye yazılımı, yangın ya da yanlış silme aynı ağdaki bütün kopyaları birlikte götürebilir. Bu rehber Windows Server kullanan sistem yöneticileri ve KOBİ'ler için hazırlandı. restic ile dosyaları ve SQL Server yedeklerini şirket dışındaki S3 uyumlu bir depoya şifreli, sürümlü ve her gece otomatik olarak göndermeyi adım adım anlatıyor. Logo, Mikro gibi SQL Server üzerinde çalışan programların veritabanları da kapsamda.

Windows sunucu yedeklemede Windows Server Backup neden tek başına yetmez

Windows Server Backup (wbadmin) yerleşik ve ücretsizdir. Tam sunucu yedeği, sistem durumu (system state) yedeği ve çıplak donanıma geri yükleme (bare metal recovery) yapabilir. Microsoft'un tam sunucu yedekleme belgesi bu senaryoyu anlatır. Eksik kaldığı yerler şunlar:

• Hedef olarak yerel disk ya da ağ paylaşımı kullanır. S3 uyumlu bir depoya doğrudan yazamaz.
• Ağ paylaşımına yazılan yedeğe, sunucuyu ele geçiren saldırgan da erişebilir.
• Sürüm geçmişi ve saklama politikası pek esnek değildir.

restic ise dosya düzeyinde çalışır. Veriyi istemci tarafında şifreler, tekrar eden blokları bir kez saklar (deduplication), her çalışmada yalnız değişen parçaları gönderir ve S3 API'si ile doğrudan konuşur. Eksiği de belli: restic ile Windows'u boş bir makineye tek tıkla geri kuramazsınız. Önce işletim sistemini yeniden kurar, sonra verileri restic'ten geri alırsınız.

Çoğu durumda doğru karar ikisini birlikte kullanmaktır. 3-2-1 kuralı da bunu söyler: verinin 3 kopyası olsun, kopyalar 2 farklı ortamda dursun, en az 1 tanesi şirket dışında bulunsun. Yerel ve hızlı kopyayı Windows Server Backup, şirket dışı kopyayı restic üstlenir.

Hazırlık: S3 uyumlu bucket, erişim anahtarı ve uç nokta

Başlamadan önce şunları hazırlayın:

1. Bucket: yalnız yedeğe ayrılmış, herkese kapalı bir bucket. Object lock kullanacaksanız özelliği bucket'ı oluştururken açın. Çoğu sağlayıcıda sonradan açılamıyor.
2. Erişim anahtarı: yalnız bu bucket'ta okuma ve yazma yetkisi olan bir Access Key ve Secret Key. Hesabın ana anahtarını kullanmayın.
3. Uç nokta (endpoint) ve bölge: sağlayıcınızın belgesinde yazan adres ve bölge adı. Bu rehberde örnek olarak https://s3.example.com kullanılıyor.
4. Adres biçimi: S3 uyumlu sağlayıcıların bir kısmı bucket.s3.example.com biçimini (virtual-hosted), bir kısmı s3.example.com/bucket biçimini (path-style) bekler. Belgede path-style yazıyorsa restic'e -o s3.bucket-lookup=path seçeneğini verin.
5. Yönetici yetkisi: VSS anlık görüntüsü alınabilmesi için restic'in yönetici olarak çalışması gerekir.

Verinin nerede durduğu da bir karar ölçütüdür. Kişisel veri içeren muhasebe ve ERP yedekleri için Türkiye'de kalan bir depo seçmek isteyebilirsiniz. Örneğin İstanbul'da çalışan S3 uyumlu Object Storage hizmetinde veri de kopyaları da Türkiye dışına çıkmaz. Hangi sağlayıcıyı seçerseniz seçin aşağıdaki adımlar aynıdır.

restic'i Windows Server'a kurma ve depoyu başlatma

restic'in Windows sürümünü projenin resmi GitHub deposundaki sürümler bölümünden zip olarak indirin. Zip'in içindeki .exe dosyasını C:\restic\restic.exe adıyla kaydedin. Görev Zamanlayıcı SYSTEM hesabıyla çalışacak. Bu yüzden kullanıcı profiline bağlı bir kurulum yerine sabit bir yol kullanın.

Aşağıdaki betik klasörleri oluşturur ve klasör izinlerini yalnız SYSTEM ile Administrators grubuna bırakır. Ardından rastgele bir depo parolası üretir ve bağlantı ayarlarını tek bir dosyada toplar. Windows Server 2019, 2022 ve 2025 ile PowerShell 5.1 için hazırlandı. Tekrar çalıştırırsanız var olan parola dosyasının üzerine yazmaz. Geri almak için önce Görev Zamanlayıcı görevini silin, sonra C:\restic klasörünü yedeğini alarak elle kaldırın. Parola dosyasını silmeden önce mutlaka güvenli bir yere kopyalayın.

# Yönetici PowerShell penceresinde çalıştırın.
$Kok = "C:\restic"
New-Item -ItemType Directory -Force -Path $Kok, "$Kok\log" | Out-Null

# Kalıtımı kaldır, yalnız SYSTEM (S-1-5-18) ve Administrators (S-1-5-32-544) tam yetkili olsun.
# SID kullanıldığı için Türkçe dil paketli sunucularda da çalışır.
icacls $Kok /inheritance:r /grant:r "*S-1-5-18:(OI)(CI)F" "*S-1-5-32-544:(OI)(CI)F" | Out-Null

# Depo parolası: yalnız dosya yoksa üret (idempotent).
$SifreDosyasi = "$Kok\sifre.txt"
if (-not (Test-Path $SifreDosyasi)) {
    $bayt = New-Object byte[] 32
    [System.Security.Cryptography.RandomNumberGenerator]::Create().GetBytes($bayt)
    [Convert]::ToBase64String($bayt) | Set-Content -Path $SifreDosyasi -Encoding ASCII -NoNewline
}

# Bağlantı ayarları: ORNEK_ ile başlayan değerleri kendi bilgilerinizle değiştirin.
$Ortam = @'
$env:RESTIC_REPOSITORY     = "s3:https://s3.example.com/ORNEK_BUCKET/windows-sunucu1"
$env:AWS_ACCESS_KEY_ID     = "ORNEK_ERISIM_ANAHTARI"
$env:AWS_SECRET_ACCESS_KEY = "ORNEK_GIZLI_ANAHTAR"
$env:AWS_DEFAULT_REGION    = "ORNEK_BOLGE"
$env:RESTIC_PASSWORD_FILE  = "C:\restic\sifre.txt"
'@
if (-not (Test-Path "$Kok\ortam.ps1")) { $Ortam | Set-Content -Path "$Kok\ortam.ps1" -Encoding UTF8 }

& "$Kok\restic.exe" version

Son satırın çıktısı restic 0.x.x compiled with go... on windows/amd64 gibi tek bir satır olmalı. Sonra depoyu başlatın. Betik önce deponun var olup olmadığına bakar. Depo varsa yeniden başlatmaya çalışmaz:

. C:\restic\ortam.ps1
$restic = "C:\restic\restic.exe"
$opts   = @("-o", "s3.bucket-lookup=path")   # Sağlayıcınız path-style istemiyorsa bu satırı boş dizi yapın: @()

& $restic @opts cat config *> $null
if ($LASTEXITCODE -eq 0) {
    Write-Output "Depo zaten başlatılmış."
} else {
    & $restic @opts init
}

Başarılı olursa çıktıda created restic repository ile başlayan ve sonunda depo adresinizin (örnekte s3:https://s3.example.com/ORNEK_BUCKET/windows-sunucu1) yazdığı bir satır görürsünüz. Hemen ardından sifre.txt dosyasının bir kopyasını sunucunun dışında, bir parola yöneticisinde ya da kasada saklayın. restic deposu bu parola olmadan açılmaz. Parolayı kaybederseniz yedekleri de kaybetmiş olursunuz.

VSS ile açık dosyaları ve SQL Server .bak dosyalarını yedekleme

Gün içinde açık kalan Excel dosyaları, Outlook PST'leri ya da uygulama klasörleri normal kopyalamada "dosya kullanımda" hatası verir. restic'in --use-fs-snapshot seçeneği Windows'ta Volume Shadow Copy (VSS) anlık görüntüsü alır ve dosyaları bu görüntüden okur. Seçenek yalnız yönetici yetkisiyle çalışır.

SQL Server veritabanı dosyalarını (.mdf, .ldf) doğrudan kopyalamak yerine SQL Server'ın kendi yedeğini alın, restic de bu .bak dosyalarını göndersin. Bu yol daha güvenlidir. Logo, Mikro, Netsis gibi programların şirket veritabanlarında da yöntem değişmez.

Karar ölçütleri:

• SQL Server Agent ve bakım planı varsa: bakım planı .bak dosyalarını bir klasöre yazar, restic o klasörü alır. İki işin saatleri çakışmasın. restic, bakım planı bittikten sonra başlamalı.
• SQL Server Express kullanıyorsanız: Express'te Agent yoktur. Yedeği aşağıdaki betikte sqlcmd ile alırsınız.
• Sıkıştırma: Sıkıştırılmış bir .bak dosyasında küçük bir değişiklik bile dosyanın büyük kısmını değiştirebilir. Bu da restic'in tekrar eden blokları ayıklamasını zayıflatabilir. Disk yeriniz yetiyorsa sıkıştırmasız .bak alıp sıkıştırmayı restic'e bırakmak çoğu zaman daha az veri gönderir. Kararı kendi ortamınızda iki gecede gönderilen veri miktarını karşılaştırarak verin.
• Yetki: Görev SYSTEM hesabıyla çalışacak. Yeni SQL Server sürümlerinde NT AUTHORITY\SYSTEM varsayılan olarak sysadmin değildir. Bu hesaba ilgili veritabanlarında db_backupoperator rolünü verin ya da görevi yedekleme yetkisi olan ayrı bir hizmet hesabıyla çalıştırın.

Hariç tutulacak yollar için C:\restic\haric.txt dosyası oluşturun. Her satıra bir desen yazın, örneğin *.tmp, ~$*, D:\Veri\Gecici.

Görev Zamanlayıcı ve PowerShell ile günlük otomatik yedek

Aşağıdaki C:\restic\yedek.ps1 betiği sırayla şunları yapar: SQL yedeğini alır, VSS ile restic yedeğini çalıştırır, saklama politikasını uygular, pazar günleri de depo bütünlüğünü kontrol eder. Windows Server 2019, 2022, 2025 ve PowerShell 5.1 için hazırlandı. Klasör ve veritabanı adlarını kendi ortamınıza göre değiştirin.

# C:\restic\yedek.ps1
$ErrorActionPreference = "Continue"     # restic stderr çıktısı betiği durdurmasın, çıkış kodlarına bakıyoruz
. C:\restic\ortam.ps1
$restic = "C:\restic\restic.exe"
$opts   = @("-o", "s3.bucket-lookup=path")
$log    = "C:\restic\log\yedek-$(Get-Date -Format yyyyMMdd).log"

# 1) SQL Server yedeği (Express ya da Agent kullanmayan kurulumlar için)
$SqlKlasor     = "D:\SQLYedek"
$Veritabanlari = @("ORNEK_DB1", "ORNEK_DB2")
New-Item -ItemType Directory -Force -Path $SqlKlasor | Out-Null
foreach ($db in $Veritabanlari) {
    $sorgu = "BACKUP DATABASE [$db] TO DISK = N'$SqlKlasor\$db.bak' WITH INIT, CHECKSUM"
    sqlcmd -S localhost -E -b -Q $sorgu *>> $log
    if ($LASTEXITCODE -ne 0) { "HATA: $db yedeği alınamadı" | Out-File $log -Append; exit 1 }
}

# 2) VSS destekli restic yedeği
& $restic @opts backup --use-fs-snapshot --exclude-file C:\restic\haric.txt --tag gunluk `
    "D:\Veri" $SqlKlasor *>> $log
$rc = $LASTEXITCODE
if ($rc -eq 3) {
    "UYARI: Bazı dosyalar okunamadı, snapshot yine de oluştu. Logu inceleyin." | Out-File $log -Append
} elseif ($rc -ne 0) {
    "HATA: restic backup çıkış kodu $rc" | Out-File $log -Append; exit $rc
}

# 3) Saklama politikası
& $restic @opts forget --tag gunluk --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune *>> $log

# 4) Pazar günleri verinin bir kısmını gerçekten okuyarak kontrol et
if ((Get-Date).DayOfWeek -eq "Sunday") {
    & $restic @opts check --read-data-subset=5% *>> $log
    if ($LASTEXITCODE -ne 0) { "HATA: restic check başarısız" | Out-File $log -Append; exit 1 }
}
exit 0

restic'in çıkış kodlarına dikkat edin: 0 başarı, 1 ciddi hata demektir. 3 ise bazı dosyalar okunamasa da snapshot'ın oluştuğunu gösterir. Betik 3'ü hata saymaz ama loga yazar.

Görevi kaydeden betik aşağıda. -Force sayesinde tekrar çalıştırırsanız var olan görevi günceller. Geri almak için Unregister-ScheduledTask -TaskName "ResticGunlukYedek" -Confirm:$false yeterli.

$eylem   = New-ScheduledTaskAction -Execute "powershell.exe" `
           -Argument '-NoProfile -ExecutionPolicy Bypass -File "C:\restic\yedek.ps1"'
$tetik   = New-ScheduledTaskTrigger -Daily -At 02:30
$kimlik  = New-ScheduledTaskPrincipal -UserId "SYSTEM" -LogonType ServiceAccount -RunLevel Highest
$ayarlar = New-ScheduledTaskSettingsSet -StartWhenAvailable -ExecutionTimeLimit (New-TimeSpan -Hours 6)

Register-ScheduledTask -TaskName "ResticGunlukYedek" -Action $eylem -Trigger $tetik `
    -Principal $kimlik -Settings $ayarlar -Force

# İlk çalıştırmayı hemen başlatıp sonucu kontrol edin
Start-ScheduledTask -TaskName "ResticGunlukYedek"

Görev bitince Get-ScheduledTaskInfo -TaskName "ResticGunlukYedek" komutunu çalıştırın. LastTaskResult değeri 0 olmalı. İlk yedek bütün veriyi gönderdiği için uzun sürebilir. Sonraki gecelerde yalnız değişen bloklar gider.

Saklama politikası: forget, prune ve check

forget hangi snapshot'ların tutulacağına karar verir. --prune ise artık hiçbir snapshot'ın kullanmadığı veriyi depodan siler. Yukarıdaki örnek 14 günlük, 8 haftalık ve 12 aylık snapshot tutar. Süreleri belirlerken kendinize şunu sorun: "Bir sorunu en geç kaç gün sonra fark ederiz?" Fidye yazılımı ya da bozulmuş bir muhasebe dosyası haftalarca fark edilmeyebilir. Bu yüzden aylık snapshot sayısını az tutmayın.

Prune çalışırken depo kilitlenir. Büyük depolarda prune uzun sürüyorsa forget --prune adımını haftada bir çalıştırın, günlük betikte yalnız forget kalsın.

check deponun yapısını doğrular. --read-data-subset=5% ise verinin bir bölümünü indirip gerçekten okur. Deponuzda indirme trafiği ücretliyse bu oranı maliyete göre ayarlayın.

Object lock (GOVERNANCE) ile fidye yazılımına karşı koruma

Saldırgan sunucuyu ele geçirirse ortam.ps1 içindeki anahtarı da görür ve restic ile snapshot'ları silmeyi deneyebilir. Object lock bu riske karşı ikinci bir koruma katmanı ekler:

• Bucket'ta sürümleme (versioning) ve object lock açılır. Varsayılan saklama modu GOVERNANCE, süre de örneğin 30 gün olarak ayarlanır.
• Bu süre boyunca bir nesne silinse bile önceki sürümü korunur. GOVERNANCE modunda özel atlama yetkisi olan bir hesap kilidi kaldırabilir. COMPLIANCE modunda ise süre dolmadan kimse kaldıramaz.
• Sunucudaki yedek anahtarına bu atlama yetkisini vermeyin. Yönetici anahtarını ayrı tutun.

Bilmeniz gereken yan etkiler de var. restic'in prune ile sildiği veri, saklama süresi dolana kadar eski sürüm olarak yer kaplamayı sürdürür. Süresi dolan eski sürümleri temizleyen bir yaşam döngüsü (lifecycle) kuralı tanımlamazsanız kullanılan alan sürekli büyür. Saldırıdan sonra geri dönerken de silinen nesnelerin önceki sürümlerini geri getirmeniz gerekir. İki mod arasındaki fark ve saklama süresinin nasıl seçileceği değiştirilemez yedek ve S3 Object Lock rehberinde ayrıntılı anlatılıyor.

Geri yükleme testi: tek dosya ve tam klasör

Test edilmemiş bir yedeğin çalışacağı yalnızca bir varsayımdır. Aşağıdaki adımları kurulumdan sonraki ilk hafta içinde, sonra da ayda bir uygulayın.

. C:\restic\ortam.ps1
$restic = "C:\restic\restic.exe"
$opts   = @("-o", "s3.bucket-lookup=path")

# Snapshot listesi: tarih, sunucu adı ve yollar görünmeli
& $restic @opts snapshots

# Dosyanın depoda hangi yolla saklandığını bulun (Windows yolları /D/Veri/... biçiminde görünebilir)
& $restic @opts find "fatura-2026.xlsx"

# Tek dosyayı ayrı bir klasöre geri yükleyin; asıl dosyanın üzerine yazmayın
& $restic @opts restore latest --target "D:\GeriYuklemeTesti" --include "/D/Veri/Muhasebe/fatura-2026.xlsx"

# Tüm klasörü belirli bir snapshot'tan geri yükleyin (ID'yi snapshots çıktısından alın)
& $restic @opts restore ORNEK_SNAPSHOT_ID --target "D:\GeriYuklemeTesti" --include "/D/Veri/Muhasebe"

--include değerini find çıktısında gördüğünüz yolun aynısı olarak yazın. Kontrol noktaları:

1. Geri yüklenen dosya açılıyor mu? Boyutu ve tarihi beklendiği gibi mi?
2. .bak dosyası için SQL Server'da RESTORE VERIFYONLY FROM DISK = N'D:\GeriYuklemeTesti\...\ORNEK_DB1.bak' komutu hatasız tamamlanıyor mu?
3. Daha sağlam bir test: .bak dosyasını bir test sunucusunda farklı bir veritabanı adıyla geri yükleyin ve programın şirketi açabildiğini görün.
4. Geri yüklemenin toplam süresini not edin. Bu süre, felaket anında işin kaç saat duracağını gösterir.

Test bitince yalnız o yolu hedefleyerek D:\GeriYuklemeTesti klasörünü silin.

Sık yapılan hatalar

Kilitli dosyalar ve VSS hatası. Görev yönetici yetkisiyle çalışmıyorsa --use-fs-snapshot başarısız olur. Görevin SYSTEM hesabı ve "Highest" yetkisiyle kayıtlı olduğunu kontrol edin. VSS sorunlarında vssadmin list writers çıktısına bakın ve hata durumunda bir yazıcı (writer) olup olmadığını kontrol edin.

Parola kaybı. Sunucu çökerse sifre.txt de onunla birlikte gider. Parolanın sunucu dışında en az bir kopyası yoksa yedeklerinize erişemezsiniz. Bu işi kurulum gününde halledin.

Yanlış bölge ya da adres biçimi. The specified bucket is not valid, region ya da DNS çözümleme hataları çoğunlukla iki nedenden çıkar: AWS_DEFAULT_REGION yanlıştır ya da path-style gerektiği halde seçenek verilmemiştir. Sağlayıcı belgesindeki bölge adını birebir kullanın.

SQL yedeğiyle restic'in çakışması. Bakım planı 02:00'de başlayıp 02:40'ta bitiyorsa, 02:30'da başlayan restic yarım kalmış bir .bak dosyasını alır. Saatleri ölçtüğünüz sürelere göre ayarlayın ya da yukarıdaki gibi iki işi aynı betikte sırayla çalıştırın.

Loglara bakmamak. Görev her gece "başarılı" görünse bile çıkış kodu 3 uyarıları birikebilir. Logları haftada bir okuyun ya da LastTaskResult değerini izleme sisteminize bağlayın.

Linux sunucularınız da varsa aynı depo yapısını restic ile Linux sunucuda S3 yedekleme rehberindeki systemd timer düzeniyle kurabilirsiniz.

Sık sorulan sorular

restic ile Windows sunucunun tamamını geri kurabilir miyim?

Hayır, restic dosya düzeyinde yedek alır. İşletim sistemini ve rolleri yeniden kurduktan sonra verileri, SQL yedeklerini ve yapılandırma dosyalarını restic'ten geri alırsınız. Sistem durumu yedeği ve çıplak donanıma geri yükleme için ayrıca Windows Server Backup ya da sanal makine snapshot'ı kullanın.

Canlı SQL Server veritabanı dosyalarını VSS ile doğrudan yedeklemek yeterli mi?

SQL Server, VSS yazıcısı sayesinde tutarlı bir anlık görüntüye katılabilir. Ama bu kopyalardan geri dönmek daha zahmetlidir ve log zincirini yönetmez. BACKUP DATABASE ile alınan .bak dosyası taşınabilir, ayrıca RESTORE VERIFYONLY ile doğrulanabilir. Bu yüzden .bak yolunu tercih edin.

İlk yedekten sonraki gecelerde ne kadar veri gönderilir?

Yalnız değişmiş ve depoda henüz bulunmayan bloklar gönderilir. Miktar, gün içinde ne kadar verinin değiştiğine ve .bak dosyalarının yapısına bağlıdır. İlk birkaç gecenin logundaki Added to the repository satırı, kendi ortamınızdaki değeri gösterir.

Aynı bucket'ı birden fazla sunucu için kullanabilir miyim?

Evet. Her sunucuya bucket içinde ayrı bir önek verip (ör. /windows-sunucu1, /windows-sunucu2) ayrı depo başlatırsanız yönetim kolaylaşır. Tek bir depoyu paylaşmak da mümkündür ve sunucular arasında tekrar eden veriyi azaltır. Ancak bu durumda bir sunucunun anahtarı diğer sunucuların yedeklerine de erişir.

Object lock açıkken restic prune çalışır mı?

Sürümleme açık bir bucket'ta silme işlemi bir silme işareti bırakır ve restic komutu tamamlanır. Ancak eski sürümler saklama süresi boyunca durduğu için alan hemen boşalmaz. Süre dolduktan sonra eski sürümleri temizleyen bir yaşam döngüsü kuralı tanımlayın.

Bu işi hazır yapmak isterseniz

Bucket oluşturma, erişim anahtarı, object lock ve restic ayarlarını sağlayıcıya özel değerlerle görmek isterseniz S3 yedekleme rehberimizde restic ve rclone için hazır yapılandırma adımlarını bulabilirsiniz. Kurulumda takıldığınız noktada destek ekibine de danışabilirsiniz.

Sonuç

Sağlam bir Windows sunucu yedekleme düzeni üç parçadan oluşur: yerelde hızlı bir kopya, şirket dışında şifreli ve sürümlü bir kopya, düzenli yapılan geri yükleme testi. İkinci parçayı restic, VSS ve Görev Zamanlayıcı ile ek lisans almadan kurabilirsiniz. Kurulumdan sonra ilk iş olarak parolanın sunucu dışında bir kopyasını alın. İkinci iş olarak da bir dosyayı ve bir .bak dosyasını gerçekten geri yükleyerek deneyin.