Exchange Server Yedekleme ve Geri Yükleme Stratejileri

Yazar:komut.io ekibi Exchange Server Kurulum ve Yönetimi
0 Yorum

Yıllarca Exchange yönetimi yapan herkes şunu bilir: disaster recovery tatbikatı yapmayan bir organizasyonun yedekleme stratejisi, kağıt üzerinde güzel görünen ama gerçekte işe yaramayan bir belgeden ibarettir. Bu yazıda teorik kılavuzları bir kenara bırakıp, sahadan öğrendiğim Exchange Server yedekleme ve geri yükleme stratejilerini paylaşacağım.

Exchange Yedeklemenin Temelleri: VSS ve Circular Logging

Exchange Server, Windows Volume Shadow Copy Service (VSS) mimarisini kullanır. Bu, Exchange’e özgü bir VSS writer aracılığıyla gerçekleşir. Yedekleme aracınızın Exchange VSS writer ile düzgün iletişim kurması, yedeklemenin tutarlı ve geri yüklenebilir olmasının ön koşuludur.

Birçok ekibin düştüğü ilk tuzak circular logging meselesidir. Circular logging açıkken transaction log’lar checkpoint geçtikten sonra silinir. Bu durumda sadece tam yedekten geri yükleyebilirsiniz, belirli bir zamana (point-in-time) dönemezsiniz. DAG (Database Availability Group) ortamlarında circular logging genellikle açık tutulur çünkü replika sayısının sağladığı koruma yeterli kabul edilir. Standalone sunucularda ise bu bir tercih değil, bilinçli bir risk kararı olmalıdır.

VSS writer durumunu kontrol etmek için:

vssadmin list writers

Çıktıda “Microsoft Exchange Writer” satırını arayın. State “Stable” ve Last Error “No error” olmalı. Herhangi bir hata görürseniz Exchange servisleri yeniden başlatmadan önce olayı loglayın, çünkü bu durum genellikle zaten var olan bir sorunun belirtisidir.

net stop MSExchangeIS
net start MSExchangeIS

Database Availability Group ve Yedekleme Stratejisi

DAG ortamında yedekleme yaparken hangi node’dan yedek alacağınız kritik bir karardır. Microsoft’un önerisi passive copy üzerinden yedek almaktır. Bu hem production üzerindeki yükü azaltır hem de active copy’nin performansını korur.

# DAG kopyalarının durumunu kontrol et
Get-MailboxDatabaseCopyStatus * | Select Name, Status, CopyQueueLength, ReplayQueueLength | Format-Table -AutoSize

# Hangi kopyaların healthy olduğunu filtrele
Get-MailboxDatabaseCopyStatus * | Where-Object {$_.Status -eq "Healthy"} | Select Name, ActiveCopy

Passive copy’den yedek alındığında şunu unutmayın: passive copy her zaman active copy ile birebir aynı veriyi içermeyebilir. Copy Queue Length ve Replay Queue Length değerlerine bakın. Copy Queue Length sıfır veya çok düşükse passive copy’den alınan yedek güvenilirdir.

Windows Server Backup ile Native Yedekleme

Üçüncü parti bir araç yoksa ve bütçe kısıtlıysa, Windows Server Backup + Exchange farkında eklenti kombinasyonu minimal ama işlevsel bir çözüm sunar. Ancak şunu baştan söyleyeyim: bu yöntem kurumsal ölçekte yeterli değildir, küçük ortamlar için geçici bir çözümdür.

# Windows Server Backup özelliğini yükle
Install-WindowsFeature Windows-Server-Backup

# Exchange veritabanı dizinini yedekleme kapsamına al
$policy = New-WBPolicy
$fileSpec = New-WBFileSpec -FileSpec "E:ExchangeDatabasesMailbox01"
Add-WBFileSpec -Policy $policy -FileSpec $fileSpec
Set-WBVssBackupOptions -Policy $policy -VssCopyBackup
$backupLocation = New-WBBackupTarget -VolumePath "F:"
Add-WBBackupTarget -Policy $policy -Target $backupLocation
Start-WBBackup -Policy $policy

Bu script yalnızca dosya tabanlı bir kopya alır, Exchange-aware değildir. Gerçek anlamda VSS tabanlı Exchange yedeklemesi için wbadmin komutunu doğrudan kullanmak daha sağlıklıdır:

wbadmin start backup -backupTarget:\fileserverExchangeBackups -include:E: -vssFull -quiet

PowerShell ile Veritabanı Durumu İzleme ve Yedekleme Öncesi Kontroller

Yedekleme başlamadan önce veritabanı sağlığını doğrulamak, başarısız bir yedek almaktan çok daha iyidir. Şu script’i yedekleme öncesi kontrol olarak çalıştırın:

# Yedekleme öncesi sağlık kontrol scripti
$databases = Get-MailboxDatabase -Status
foreach ($db in $databases) {
    $status = Get-MailboxDatabaseCopyStatus $db.Name
    
    Write-Host "Veritabani: $($db.Name)" -ForegroundColor Cyan
    Write-Host "  Mounted: $($db.Mounted)" -ForegroundColor $(if ($db.Mounted) {"Green"} else {"Red"})
    Write-Host "  Son Tam Yedek: $($db.LastFullBackup)" -ForegroundColor Yellow
    Write-Host "  Son Artan Yedek: $($db.LastIncrementalBackup)" -ForegroundColor Yellow
    
    # 24 saatten eski yedek uyarisi
    if ($db.LastFullBackup -lt (Get-Date).AddHours(-24)) {
        Write-Warning "  UYARI: $($db.Name) icin 24 saatten eski tam yedek!"
    }
}

Bu script’in çıktısını bir log dosyasına yönlendirin ve monitoring sisteminizle entegre edin. “LastFullBackup” alanı null geliyorsa veritabanı hiç yedeklenmemiş demektir, bu ciddi bir alarm durumudur.

Veeam Backup for Microsoft Exchange ile Profesyonel Yaklaşım

Kurumsal ortamlarda Veeam, Commvault veya Veritas NetBackup gibi araçlar tercih edilir. Veeam özelinde konuşacak olursam, Exchange plugin’i application-aware processing kapsamında çalışır ve VSS entegrasyonunu otomatik yönetir.

Veeam tarafında yapmanız gereken kritik yapılandırmalar:

  • Application-aware processing: Job ayarlarında mutlaka aktif edin
  • Guest OS credentials: Exchange sunucusunda local admin yetkili bir servis hesabı kullanın, domain admin kullanmaktan kaçının
  • Log truncation: Veeam başarılı backup sonrasında transaction log’ları truncate edebilir, bunu kasıtlı olarak yönetin
  • Backup repository: Exchange yedeklerini production storage’dan fiziksel olarak ayrı bir lokasyona alın

Veeam’ın Explorer for Microsoft Exchange özelliği, granüler geri yükleme (tek mailbox, tek öğe) için gerçekten çok işlevlidir. Kullanıcının “yanlışlıkla sildiğim maili geri getir” taleplerini production’a dokunmadan çözebilirsiniz.

Geri Yükleme Senaryoları ve Prosedürleri

Senaryo 1: Tek Veritabanını Geri Yükleme

Bu en sık karşılaşılan senaryo. Bir veritabanı corrupt olmuş veya mount edilemiyor.

# Once veritabanını dismount et
Dismount-Database -Identity "Mailbox01" -Confirm:$false

# Veritabani dosyalarini yedekten geri yukle (ornek: robocopy ile)
robocopy "\backupserverExchangeBackupMailbox01" "E:ExchangeDatabasesMailbox01" /E /R:3 /W:5 /LOG:C:restore_log.txt

# Veritabanini dirty shutdown durumundan temiz duruma getir
eseutil /r E0n /l "E:ExchangeDatabasesMailbox01E0n" /d "E:ExchangeDatabasesMailbox01"

# Mount et
Mount-Database -Identity "Mailbox01"

eseutil /r komutundaki log generation prefix (E0n kısmı) veritabanına özeldir. Doğru prefix’i bulmak için:

eseutil /mh "E:ExchangeDatabasesMailbox01Mailbox01.edb" | findstr "Log Required"

Senaryo 2: Recovery Database ile Granüler Geri Yükleme

Tüm veritabanını geri yüklemek yerine belirli bir mailbox’ı kurtarmak istiyorsanız Recovery Database (RDB) yöntemi kullanılır. Bu yöntem production’ı etkilemez.

# Recovery Database olustur
New-MailboxDatabase -Recovery -Name "RecoveryDB" -Server "EXCH01" -EdbFilePath "E:RecoveryDBRecoveryDB.edb" -LogFolderPath "E:RecoveryDBLogs"

# Yedekten geri yuklenen dosyayi RDB'ye bagla ve mount et
Mount-Database "RecoveryDB"

# RDB icindeki mailbox'lari listele
Get-MailboxStatistics -Database "RecoveryDB" | Select DisplayName, MailboxGuid

# Belirli bir mailbox'i production'a restore et
Restore-Mailbox -Identity "[email protected]" -RecoveryDatabase "RecoveryDB" -RecoveryMailbox "[email protected]" -TargetFolder "Kurtarilan_Veriler"

# RDB'yi temizle
Dismount-Database "RecoveryDB"
Remove-MailboxDatabase "RecoveryDB" -Confirm:$false

Bu yöntemi bir gerçek senaryoyla pekiştirelim: Muhasebe departmanından bir kullanıcı 3 yıllık mail arşivini yanlışlıkla silmiş ve soft-delete süresi de dolmuş. Yedek varsa RDB yöntemi hayat kurtarır. Yedek yoksa ya da RDB prosedürünü hiç prova etmemişseniz, o toplantı sizi çok zor anlar yaşatır.

Senaryo 3: Felaket Kurtarma – Sunucu Tamamen Çöktü

En kötü senaryo: Exchange sunucusu tamamen kullanılamaz durumda, donanım arızası veya ransomware. Bu durumda:

# Yeni sunucuya Exchange'i ayni isimle kur
# Setup.exe /Mode:RecoverServer /IAcceptExchangeServerLicenseTerms

# Yedekten veritabani dosyalarini geri yukle
# Sonra veritabanini repair modunda kontrol et
eseutil /p "E:ExchangeDatabasesMailbox01Mailbox01.edb"

# Integrity check
isinteg -s EXCH01 -fix -test alltests

# Veritabanini mount etmeyi dene
Mount-Database -Identity "Mailbox01"

eseutil /p bir repair işlemidir ve veri kaybına yol açabilir. Bu komutu son çare olarak kullanın. Önce mevcut dosyaların yedeğini alın:

robocopy "E:ExchangeDatabasesMailbox01" "F:Pre-Repair-Backup" /E /COPYALL

Yedekleme Doğrulama: En Çok Atlanan Adım

Yedekleme yapmak yetmez, o yedeğin çalıştığını kanıtlamanız gerekir. Her ay en az bir kez izole test ortamında geri yükleme testı yapın. Bu bir tatbikat değil, operasyonel bir gereklilik.

# Yedekleme basirisini dogrulayan basit kontrol scripti
$databases = Get-MailboxDatabase -Status

$report = @()
foreach ($db in $databases) {
    $saatFarki = if ($db.LastFullBackup) {
        [math]::Round(((Get-Date) - $db.LastFullBackup).TotalHours, 1)
    } else { 9999 }
    
    $durum = if ($saatFarki -le 24) {"OK"} elseif ($saatFarki -le 48) {"UYARI"} else {"KRITIK"}
    
    $report += [PSCustomObject]@{
        Veritabani = $db.Name
        SonYedek = $db.LastFullBackup
        SaatFarki = $saatFarki
        Durum = $durum
    }
}

$report | Export-Csv "C:YedekRaporu_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation -Encoding UTF8

# Kritik durumlar icin mail gonder
$kritikler = $report | Where-Object {$_.Durum -eq "KRITIK"}
if ($kritikler) {
    Send-MailMessage -To "[email protected]" -From "[email protected]" `
        -Subject "KRITIK: Exchange Yedekleme Sorunu!" `
        -Body ($kritikler | Out-String) `
        -SmtpServer "smtp.domain.com"
}

Bu script’i Task Scheduler’a ekleyin, her sabah 06:00’da çalışsın. Kritik uyarı geldiğinde mesai başlamadan önce müdahale edebilelim.

Transaction Log Yönetimi

Exchange transaction log’larının birikmesi disk dolmasına yol açar, disk dolması da veritabanının mount edilememesine. Bu domino etkisini durdurmak için log’ları yönetin.

Başarılı tam yedek sonrasında log’lar otomatik truncate edilmelidir. Eğer edilmiyorsa sorun yedeklemede demektir. Log birikimini izleyin:

# Log dizinlerinin boyutunu raporla
$databases = Get-MailboxDatabase
foreach ($db in $databases) {
    $logPath = $db.LogFolderPath
    $boyut = (Get-ChildItem $logPath -Filter "*.log" | Measure-Object -Property Length -Sum).Sum / 1GB
    Write-Host "$($db.Name) - Log Boyutu: $([math]::Round($boyut, 2)) GB" -ForegroundColor $(if ($boyut -gt 10) {"Red"} else {"Green"})
}

Log boyutu sürekli artıyorsa ve yedekleme başarılı görünüyorsa, VSS writer sorununu araştırın. Truncation gerçekleşmiyordur büyük ihtimalle.

3-2-1 Kuralını Exchange’e Uyarlamak

Klasik 3-2-1 yedekleme kuralı (3 kopya, 2 farklı medya, 1 offsite) Exchange ortamlarına şöyle uyarlanır:

  • Kopya 1: Yerel yedek sunucusu (hızlı erişim, son 7 günlük)
  • Kopya 2: NAS veya ikinci bir lokasyondaki depolama birimi (son 30 günlük)
  • Kopya 3: Cloud storage (Azure Blob, S3 uyumlu) veya tape (uzun dönem arşiv, 1 yıllık)

DAG kullanıyorsanız kopya sayınız zaten artıyor ama DAG bir yedekleme çözümü değil, bir yüksek erişilebilirlik çözümüdür. Ransomware her iki node’u da şifrelerse DAG sizi kurtarmaz. Offsite ve offline yedek şarttır.

Retention Policy ve Yasal Gereklilikler

Türkiye’deki organizasyonlar için mail retention konusunda dikkat edilmesi gereken noktalar var. KVKK kapsamında kişisel veri içeren mail’lerin gereksiz yere uzun süre saklanması sorun yaratabilir. Öte yandan bazı sektörlerde (bankacılık, sigortacılık) düzenleyici kurumlar belirli süreler boyunca kayıt tutmayı zorunlu kılıyor.

Exchange’de retention policy yapılandırması:

# Retention policy tag olustur (30 gun sonra sil)
New-RetentionPolicyTag "30-Gun-Sil" -Type All -RetentionEnabled $true -AgeLimitForRetention 30 -RetentionAction DeleteAndAllowRecovery

# Policy olustur
New-RetentionPolicy "Standart-Retention" -RetentionPolicyTagLinks "30-Gun-Sil"

# Kullaniciya uygula
Set-Mailbox -Identity "[email protected]" -RetentionPolicy "Standart-Retention"

Yedekleme ve retention birbirinden bağımsız kavramlardır. Retention, mailbox içeriğinin ne kadar süre tutulacağını yönetirken, yedekleme sistemin geri yüklenebilirliğini sağlar. İkisini karıştırmayın.

Sonuç

Exchange yedekleme stratejisi kurmak tek seferlik bir proje değil, sürekli bakım gerektiren bir disiplindir. Buraya kadar anlattıklarımdan çıkarmanızı istediğim pratik özet şu:

Önce VSS writer sağlığını ve circular logging durumunu gözden geçirin. Sonra yedekleme sıklığını ve saklama süresini iş gereksinimlerine göre belirleyin. Her yedek sonrasında “LastFullBackup” alanını kontrol eden bir otomasyon kurun. Ayda bir RDB ile granüler geri yükleme testı yapın ve bu testi belgelendirin. Offsite kopya olmadan hiçbir yedekleme stratejisi tam sayılmaz.

Exchange’i yıllarca yönetmiş biri olarak şunu söyleyebilirim: yedekleme sorunları her zaman en kötü zamanda, en kritik süreçte ortaya çıkar. Hazırlıklı olmanın tek yolu sistemi önceden test etmektir. Tatbikat yapmayan ekipler, gerçek felakette hem sistemi hem de itibarlarını kaybeder.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir