Bacula ile Windows Active Directory ve Exchange Server Yedekleme Yapılandırması

Windows ortamlarında yedekleme yaparken en çok yapılan hata, “zaten bir şey olmaz” diye düşünüp Active Directory ve Exchange gibi kritik sistemleri standart dosya yedeklemesiyle geçiştirmektir. Ransomware saldırısı, donanım arızası veya yanlışlıkla silinen bir nesne söz konusu olduğunda bu yaklaşımın ne kadar tehlikeli olduğunu anlıyorsunuz. Bu yazıda Bacula ile Windows AD ve Exchange ortamlarını nasıl düzgün yedekleyeceğinizi, VSS entegrasyonunu nasıl yapılandıracağınızı ve gerçekten işe yarar bir felaket kurtarma planı nasıl oluşturacağınızı adım adım ele alacağız.

Mimari ve Ön Gereksinimler

Bacula, Windows yedeklemelerini Bacula File Daemon (bacula-fd) aracılığıyla gerçekleştirir. Bu daemon, Windows makinelere kurulur ve Bacula Director ile iletişim kurarak yedekleme işlemini yönetir. AD ve Exchange için kritik nokta, VSS (Volume Shadow Copy Service) desteğidir. Bacula bu servisi kullanarak açık dosyaları ve kilitli veritabanlarını tutarlı bir şekilde yedekleyebilir.

Ortamımızda şu bileşenler mevcut olacak:

  • Bacula Director: Linux sunucu üzerinde çalışıyor (Ubuntu 22.04 veya RHEL 9)
  • Bacula Storage Daemon: Yedeklerin tutulduğu depolama sunucusu
  • Bacula File Daemon: AD Domain Controller ve Exchange Server üzerinde kurulu (Windows Server 2019/2022)
  • Bacula Catalog: PostgreSQL veya MySQL veritabanı

Windows tarafında ihtiyacınız olanlar:

  • bacula-win64-*.exe kurulum paketi (en güncel sürümü bacula.org’dan indirin)
  • Windows Server 2019/2022 üzerinde yönetici hakları
  • AD ve Exchange için VSS Writer servislerin çalışıyor olması
  • Güvenlik duvarında 9102/TCP portunu açık tutmak (File Daemon portu)

Windows Üzerine Bacula File Daemon Kurulumu

Önce Linux tarafında gerekli paketlerin kurulu olduğunu doğrulayalım:

# Bacula Director ve Storage Daemon kontrolü
systemctl status bacula-director
systemctl status bacula-sd

# Bacula versiyonunu kontrol et
bacula-dir --version

Windows Server’da kurulum dosyasını çalıştırdıktan sonra servisin düzgün başladığını PowerShell ile doğrulayın:

# Bacula File Daemon servis durumu
Get-Service -Name "Bacula-fd" | Select-Object Name, Status, StartType

# VSS Writer listesini kontrol et - Exchange ve AD writerlar görünmeli
vssadmin list writers | Select-String "Writer name|State|Last error"

Çıktıda şunları görmelisiniz:

  • Active Directory Domain Services Writer – Stable
  • Microsoft Exchange Writer – Stable (Exchange kuruluysa)
  • Registry Writer – Stable
  • System Writer – Stable

Eğer Exchange Writer “Failed” durumundaysa servis yeniden başlatılmalı:

# Exchange Information Store servisini yeniden başlat
Restart-Service MSExchangeIS
# VSS Writer durumunu tekrar kontrol et
vssadmin list writers | findstr /i "exchange"

Windows File Daemon Yapılandırması

Windows makinede C:Program FilesBaculabacula-fd.conf dosyasını düzenleyin. Bu konfigürasyonun güvenlik açısından önemli detaylarına dikkat edin:

# Windows makinede bu dosya genellikle şu konumdadır:
# C:Program FilesBaculabacula-fd.conf
# Notepad++ veya uzaktan erişimle düzenlenebilir

Aşağıdaki yapılandırma Domain Controller için optimize edilmiştir:

FileDaemon {
  Name = dc01-fd
  FDport = 9102
  WorkingDirectory = "C:/ProgramData/Bacula"
  Pid Directory = "C:/ProgramData/Bacula"
  Maximum Concurrent Jobs = 10
  FDAddress = 192.168.10.10
}

Director {
  Name = bacula-dir
  Password = "GucluBirSifre_BuradaDegistirin"
}

Messages {
  Name = Standard
  director = bacula-dir = all, !skipped, !restored
}

FDAddress değerini mutlaka DC’nin gerçek IP adresiyle değiştirin. Director ile iletişimde kullanılan şifre her istemci için benzersiz olmalı, aynı şifreyi farklı sistemlerde kullanmayın.

Bacula Director Yapılandırması – Client Tanımları

Linux’taki Director konfigürasyonuna geçelim. /etc/bacula/bacula-dir.conf dosyasına yeni istemcileri ekleyin:

# Mevcut konfigürasyonu yedekle
cp /etc/bacula/bacula-dir.conf /etc/bacula/bacula-dir.conf.backup

# Konfigürasyon dosyasını düzenle
nano /etc/bacula/bacula-dir.conf

Domain Controller için Client tanımı:

Client {
  Name = dc01-fd
  Address = 192.168.10.10
  FDPort = 9102
  Catalog = MyCatalog
  Password = "GucluBirSifre_BuradaDegistirin"
  File Retention = 60 days
  Job Retention = 6 months
  AutoPrune = yes
  Maximum Concurrent Jobs = 1
}

Client {
  Name = exchange01-fd
  Address = 192.168.10.20
  FDPort = 9102
  Catalog = MyCatalog
  Password = "ExchangeIcinFarkliBirSifre"
  File Retention = 90 days
  Job Retention = 12 months
  AutoPrune = yes
  Maximum Concurrent Jobs = 1
}

Exchange için retention sürelerini daha uzun tuttum çünkü mail arşivleme gereksinimleri genellikle daha uzun süreleri gerektirir. Sektörel düzenlemeler (KVKK, ISO 27001 gibi) kapsamında bu süreleri organizasyonunuzun politikasına göre ayarlayın.

Active Directory Yedekleme Job’u Oluşturma

AD yedeklemesinde en kritik şey System State ve SYSVOL verilerini kapsamasıdır. FileSet tanımını dikkatli yapılandırın:

FileSet {
  Name = "WindowsAD-FileSet"
  Include {
    Options {
      Signature = MD5
      Compression = GZIP
      VSS = yes
      portable = no
      OneFS = no
    }
    # System State - AD veritabanı burada
    File = "C:/Windows/NTDS"
    # SYSVOL - Group Policy ve logon scriptleri
    File = "C:/Windows/SYSVOL"
    # System32 altındaki kritik dosyalar
    File = "C:/Windows/System32/config"
    # DNS zone dosyaları (AD integrated DNS için)
    File = "C:/Windows/System32/dns"
  }
  Exclude {
    File = "C:/Windows/NTDS/temp"
    File = "C:/Windows/Temp"
  }
}

VSS = yes direktifi burada hayati önem taşıyor. Bu olmadan ntds.dit dosyası kilitli olduğu için yedeklenemez. Ayrıca portable = no ayarı Windows’a özgü dosya izinlerinin ve ACL’lerin korunması için zorunludur.

AD yedekleme Job’unu tanımlayalım:

Job {
  Name = "Backup-ActiveDirectory"
  Type = Backup
  Client = dc01-fd
  FileSet = "WindowsAD-FileSet"
  Schedule = "WeeklyCycle"
  Storage = File-CHD
  Messages = Standard
  Pool = AD-Pool
  Priority = 10
  Write Bootstrap = "/var/lib/bacula/AD-%c.bsr"
  # Yedek başlamadan önce sistem durumunu logla
  Run Before Job = "/etc/bacula/scripts/ad-pre-backup.sh"
  Run After Job = "/etc/bacula/scripts/ad-post-backup.sh"
}

Pre ve post backup scriptleri işin kalitesini artırır. Şimdi bu scriptleri oluşturalım:

# /etc/bacula/scripts/ad-pre-backup.sh
#!/bin/bash
# AD yedekleme öncesi kontroller

LOG="/var/log/bacula/ad-backup-pre.log"
DATE=$(date '+%Y-%m-%d %H:%M:%S')

echo "[$DATE] AD yedekleme başlıyor..." >> $LOG

# DC erişilebilirliğini kontrol et
if ping -c 2 192.168.10.10 > /dev/null 2>&1; then
    echo "[$DATE] DC erişilebilir durumda" >> $LOG
else
    echo "[$DATE] HATA: DC erişilemiyor!" >> $LOG
    exit 1
fi

# Yeterli depolama alanı var mı kontrol et (en az 50GB)
AVAILABLE=$(df /backup | awk 'NR==2 {print $4}')
REQUIRED=52428800  # 50GB in KB

if [ "$AVAILABLE" -lt "$REQUIRED" ]; then
    echo "[$DATE] UYARI: Yetersiz disk alanı!" >> $LOG
    exit 1
fi

echo "[$DATE] Ön kontroller başarılı" >> $LOG
exit 0

Bu script basit görünse de production ortamında bu kontrollerin önemi büyük. Disk alanı doluyken başlayan bir yedekleme işlemi hem başarısız olur hem de mevcut yedekleri bozabilir.

Exchange Server Yedekleme Yapılandırması

Exchange yedeklemesi AD’ye göre daha karmaşıktır çünkü birden fazla mailbox database, transaction logları ve diğer bileşenler söz konusudur. Exchange için özel bir FileSet gereklidir:

FileSet {
  Name = "Exchange-FileSet"
  Include {
    Options {
      Signature = SHA1
      Compression = GZIP
      VSS = yes
      portable = no
      AclSupport = yes
    }
    # Exchange mailbox veritabanları
    File = "D:/Exchange/Mailbox"
    # Public folder veritabanları (varsa)
    File = "D:/Exchange/PublicFolders"
    # Exchange log dosyaları
    File = "E:/ExchangeLogs"
    # Exchange konfigürasyon dizini
    File = "C:/Program Files/Microsoft/Exchange Server/V15/Bin"
    # IIS metabase (OWA ve Exchange Web Services için)
    File = "C:/Windows/System32/inetsrv/MetaBase.xml"
  }
  Exclude {
    File = "D:/Exchange/Mailbox/temp"
    File = "*.tmp"
  }
}

Exchange için AclSupport = yes kritiktir. Bu olmadan restore sonrasında Exchange servislerinin dizinlere erişim izinleri bozulabilir. Gerçek bir senaryoda bu detayı atlayan birinin restore sonrası saatlerce izin sorunuyla uğraştığına tanıklık ettim.

Exchange Job tanımı için farklı schedule kullanın, AD ile aynı saatte çalışmasından kaçının:

Job {
  Name = "Backup-Exchange"
  Type = Backup
  Level = Incremental
  Client = exchange01-fd
  FileSet = "Exchange-FileSet"
  Schedule = "ExchangeSchedule"
  Storage = File-CHD
  Messages = Standard
  Pool = Exchange-Pool
  Priority = 15
  Write Bootstrap = "/var/lib/bacula/Exchange-%c.bsr"
  Max Run Time = 8 hours
  Incremental max wait time = 30 minutes
}

# Exchange için özel schedule - her gece 02:00, Pazar tam yedek
Schedule {
  Name = "ExchangeSchedule"
  Run = Full sun at 01:00
  Run = Incremental mon-sat at 02:00
}

Max Run Time = 8 hours ayarı önemli. Exchange veritabanları büyük olabilir ve gün boyu çalışan bir yedekleme işlemi iş saatlerini etkileyebilir. Bu süreyi ortamınızdaki veritabanı boyutuna göre ayarlayın.

Pool ve Storage Yapılandırması

AD ve Exchange için ayrı Pool’lar oluşturmak, yönetimi kolaylaştırır ve farklı retention politikaları uygulamanızı sağlar:

Pool {
  Name = AD-Pool
  Pool Type = Backup
  Recycle = yes
  AutoPrune = yes
  Volume Retention = 30 days
  Maximum Volume Bytes = 10G
  Maximum Volumes = 20
  Label Format = "AD-Vol-"
}

Pool {
  Name = Exchange-Pool
  Pool Type = Backup
  Recycle = yes
  AutoPrune = yes
  Volume Retention = 90 days
  Maximum Volume Bytes = 50G
  Maximum Volumes = 30
  Label Format = "Exchange-Vol-"
}

Exchange volume boyutunu daha büyük tutuyorum çünkü mailbox veritabanları tipik olarak çok daha büyük. Volume boyutunu depolama altyapınıza göre ayarlayın, özellikle tape kullanıyorsanız tape kapasitesini aşmayacak şekilde sınırlandırın.

Konfigürasyonu Test Etme ve Doğrulama

Tüm yapılandırmayı uyguladıktan sonra sırayla test edin:

# Director konfigürasyonunu test et
bacula-dir -tc /etc/bacula/bacula-dir.conf

# Director'ı yeniden başlat
systemctl restart bacula-director

# bconsole ile bağlan ve istemci bağlantısını test et
bconsole

bconsole içinde:

# bconsole komutları
*status client=dc01-fd
*status client=exchange01-fd

# Test yedeklemesi başlat
*run job=Backup-ActiveDirectory level=Full yes

# Job durumunu izle
*messages
*status dir

# Tamamlanan jobları listele
*list jobs

İlk çalıştırmada dikkat etmeniz gereken bconsole çıktısındaki FD Files Written ve SD Files Written değerlerinin eşit olmasıdır. Eğer farklıysa VSS problemi yaşıyor olabilirsiniz.

Restore Test Prosedürü

Yedekleme yapılandırmak yeterli değil, restore’un da çalıştığından emin olmanız gerekiyor. Bunu test ortamında periyodik olarak yapın. İzole bir test ortamına AD restore testi için:

# Belirli bir jobdan restore
bconsole

*restore
# Listeden client seçin: dc01-fd
# Restore modu: "Select the most recent backup for a client"
# Hedef klasör: "where=/mnt/restore-test"
# Seçimi onaylayın
*yes

Exchange için granüler restore (tek mailbox veya item restore) için Bacula’nın kendi araçları yeterli olmayabilir. Bu senaryoda restore edilen veritabanından Exchange Recovery Database (RDB) oluşturarak spesifik itemları geri alabilirsiniz. Bu, Exchange yöneticisiyle birlikte test edilmesi gereken bir prosedürdür.

Monitoring ve Alerting

Production ortamında yedekleme başarısızlıklarının anında bildirimi şart. Basit bir e-posta bildirimi için Bacula Messages konfigürasyonu:

# /etc/bacula/bacula-dir.conf içindeki Messages bloğu
Messages {
  Name = Standard
  mailcommand = "/usr/sbin/bsmtp -h mail.sirket.com -f "(Bacula) <%r>" -s "Bacula: %t %e of %c %l" %r"
  mail = [email protected] = all, !skipped
  operator = [email protected] = mount
  console = all, !skipped, !saved
  append = "/var/log/bacula/bacula.log" = all, !skipped
  catalog = all
}

Bacula’nın loglarını düzenli kontrol eden bir script yazın ve bunu cron’a ekleyin:

#!/bin/bash
# /etc/bacula/scripts/check-backup-status.sh

LOG_FILE="/var/log/bacula/bacula.log"
ALERT_MAIL="[email protected]"

# Son 24 saatte başarısız job var mı kontrol et
FAILED=$(grep "$(date -d 'yesterday' '+%Y-%m-%d')|$(date '+%Y-%m-%d')" $LOG_FILE | grep -c "Backup Error|Fatal error")

if [ "$FAILED" -gt 0 ]; then
    echo "KRITIK: Son 24 saatte $FAILED yedekleme hatası tespit edildi!" | 
    mail -s "[BACULA ALARM] Yedekleme Hatası" $ALERT_MAIL
    
    # Detayları da gönder
    grep "Backup Error|Fatal error" $LOG_FILE | tail -20 | 
    mail -s "[BACULA ALARM] Hata Detayları" $ALERT_MAIL
fi

# Cron'a eklemek için: 0 8 * * * /etc/bacula/scripts/check-backup-status.sh

Bu scripti her sabah 08:00’de çalıştırın, böylece gece gerçekleşen yedekleme sorunlarını iş gününün başında fark edersiniz.

Yaygın Sorunlar ve Çözümleri

VSS Snapshot Hatası: En sık karşılaşılan problem. Windows’da VSS servisini restart edin ve Volume Shadow Copy ile System Writer’ların çalıştığını doğrulayın. Antivirüs yazılımları bazen VSS operasyonlarını engeller, Bacula süreçlerini AV exclusion listesine ekleyin.

ntds.dit Yedeklenemiyor: Bu dosya kilitli olduğu için VSS zorunlu. FileSet’te VSS = yes direktifinin doğru konumda olduğunu kontrol edin. Options {} bloğu içinde olmalı, dışarıda değil.

Exchange Writer Stable Değil: net stop MSExchangeIS && net start MSExchangeIS komutunu çalıştırın. Sorun devam ederse Windows Event Log’da VSS hatalarını araştırın.

Yavaş Yedekleme: Exchange veritabanları büyükse bant genişliği sınırlaması yapın. Bacula Director’da Maximum Bandwidth = 50 mb/s ayarını Client bloğuna ekleyerek ağ yükünü kontrol altına alın.

Bağlantı Sorunları: Windows Firewall’da 9102/TCP’nin açık olduğunu PowerShell ile doğrulayın:

# Firewall kuralını kontrol et
Get-NetFirewallRule -DisplayName "*Bacula*" | Select-Object DisplayName, Enabled, Direction

# Kural yoksa ekle
New-NetFirewallRule -DisplayName "Bacula File Daemon" -Direction Inbound -Protocol TCP -LocalPort 9102 -Action Allow

Felaket Kurtarma Senaryosu

Bir DC tamamen çöktüğünde restore süreci şöyle işler: Önce aynı hostname ve IP ile Windows Server’ı fresh kurmanız, Bacula FD’yi kurmanız, ardından son System State ve NTDS yedeklerini Directory Services Restore Mode (DSRM) ile restore etmeniz gerekir. Bu sürecin her altı ayda bir test edilmesi şiddetle tavsiye edilir. Gerçek bir felaket anında hiç test edilmemiş prosedürleri çalıştırmak hem stresli hem de risklidir.

Exchange için BMR (Bare Metal Recovery) senaryosunda sıra önemlidir: Windows OS kurulum, Exchange kurulum (Recovery modda), mailbox database restore. Bu sırayı belgeleyin ve run book’unuza ekleyin.

Sonuç

Bacula ile AD ve Exchange yedeklemesi, doğru yapılandırıldığında son derece güvenilir bir koruma sağlar. Yapılandırmanın kritik noktalarını özetlemek gerekirse: VSS desteği kesinlikle etkin olmalı, AD ve Exchange için ayrı FileSet ve Pool tanımları kullanılmalı, retention süreleri organizasyonun politikasına uygun ayarlanmalı ve en önemlisi restore prosedürleri düzenli test edilmelidir. Yedekleme sistemi kurduğunuzda işin yarısını tamamladınız, asıl iş restore’un çalıştığını kanıtlamaktır. Bu yapılandırmayı kurduktan sonra ilk restore testini bir hafta içinde yapmanızı öneririm, bulacağınız küçük sorunları felaket olmadan çözersiniz.

Bir yanıt yazın

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