Bacula ile Bootstrap Dosyası: Felaket Kurtarma Rehberi

Tarafındankomut
0 Comments

Yedekleme sistemleri kurduğunuzda “her şey yolunda” dersiniz, ta ki gerçek bir felaket anına kadar. Sunucunuz çöktüğünde, RAID diziniz bozulduğunda ya da veri merkeziniz yanıp kül olduğunda, elinizdeki tek şey yedekleriniz ve o yedekleri geri yükleyebilme kapasitenizdir. İşte tam bu noktada Bacula’nın bootstrap dosyası kavramı hayat kurtarıcı bir rol üstlenir. Bu yazıda bootstrap dosyasının ne olduğunu, nasıl üretildiğini ve felaket kurtarma senaryolarında nasıl kullanıldığını gerçek dünya örnekleriyle ele alacağız.

Bootstrap Dosyası Nedir?

Bootstrap dosyası, Bacula’nın bir yedekleme işlemini tamamladıktan sonra ürettiği, yedeklenen verilerin tam olarak nerede bulunduğunu tanımlayan bir meta veri dosyasıdır. Bu dosya sayesinde Bacula Director veya Catalog veritabanına ihtiyaç duymadan, doğrudan bant ya da disk üzerindeki verilere erişebilirsiniz.

Peki neden bu kadar kritik? Düşünün: Bacula kurulumunuzda Director sunucunuz da dahil olmak üzere her şey çöktü. Catalog veritabanınız gitti. Ama bantlarınız elinizde. İşte bootstrap dosyası olmadan o bantlardaki veriyi bulmak, samanın içinde iğne aramak gibidir. Bootstrap dosyasıyla ise tam olarak hangi bantta, hangi konumda, hangi dosyaların olduğunu bilirsiniz.

Bir bootstrap dosyası şu bilgileri içerir:

  • Volume adı: Verinin yazıldığı teyp veya disk birimi
  • MediaType: Hangi tür medya olduğu
  • VolSessionId ve VolSessionTime: Oturumu benzersiz olarak tanımlayan değerler
  • VolFile ve VolBlock: Verinin medya üzerindeki konumu
  • FileIndex: Hangi dosyaların yedeklendiği

Bootstrap Dosyasının Üretilmesi

Bacula, her başarılı yedekleme işleminin ardından otomatik olarak bir bootstrap dosyası üretebilir. Bunun için Director konfigürasyonunda WriteBootstrap direktifini kullanmanız gerekir.

# /etc/bacula/bacula-dir.conf içinde Job tanımı
Job {
  Name = "BackupClientA"
  JobDefs = "DefaultJob"
  Client = clienta-fd
  FileSet = "Full Set"
  Pool = Default
  Storage = File1
  Messages = Standard
  Priority = 10
  WriteBootstrap = "/var/lib/bacula/bootstrap/%n.bsr"
}

Buradaki %n ifadesi job adını temsil eder. Bacula çeşitli format değişkenleri destekler:

  • %n: Job adı
  • %j: Job ID numarası
  • %c: İstemci adı
  • %d: Director adı
  • %t: Job türü (Backup, Restore vb.)
  • %l: Yedekleme seviyesi (Full, Incremental, Differential)

Daha dinamik bir isimlendirme için şöyle bir yapı kullanabilirsiniz:

WriteBootstrap = "/var/lib/bacula/bootstrap/%c-%l-%j.bsr"

Bu yapıyla “webserver01-Full-12345.bsr” gibi anlamlı dosya isimleri elde edersiniz.

Bootstrap Dosyasının İçeriği

Gerçek bir bootstrap dosyasının içeriğine bakalım:

# Örnek bootstrap dosyası içeriği
# /var/lib/bacula/bootstrap/BackupClientA.bsr

Volume="Vol-0001"
MediaType="File"
VolSessionId=1
VolSessionTime=1698765432
VolAddr=0-1023
FileIndex=1-156

Volume="Vol-0002"
MediaType="File"
VolSessionId=1
VolSessionTime=1698765432
VolAddr=0-512
FileIndex=157-289

Bu dosyayı incelediğinizde şunları görürsünüz: Yedek iki farklı volume’a yayılmış durumda. İlk volume’da 1’den 156’ya kadar olan dosyalar, ikinci volume’da 157’den 289’a kadar olan dosyalar bulunuyor. Restore işlemi sırasında Bacula tam olarak bu konumlara gidecek ve gereksiz yere bantı ileri geri sarmayacaktır. Bu hem zaman hem de bant ömrü açısından büyük tasarruf sağlar.

Bootstrap Dosyasını Güvenli Tutmak

Bootstrap dosyaları üretildiği sunucuda durmaz, durursa bir anlam ifade etmez. Çünkü o sunucu çöktüğünde dosyaya ulaşamazsınız. Bu yüzden bootstrap dosyalarını başka bir yere kopyalamanız şarttır.

Basit ama etkili bir yöntem, RunAfterJob direktifi ile bootstrap dosyasını uzak bir sunucuya göndermektir:

Job {
  Name = "BackupClientA"
  JobDefs = "DefaultJob"
  Client = clienta-fd
  FileSet = "Full Set"
  Pool = Default
  Storage = File1
  Messages = Standard
  Priority = 10
  WriteBootstrap = "/var/lib/bacula/bootstrap/%n.bsr"
  RunAfterJob = "/etc/bacula/scripts/send_bootstrap.sh %n"
}
#!/bin/bash
# /etc/bacula/scripts/send_bootstrap.sh
# Bootstrap dosyasını uzak sunucuya ve e-posta ile gönder

JOB_NAME=$1
BSR_FILE="/var/lib/bacula/bootstrap/${JOB_NAME}.bsr"
REMOTE_SERVER="backup-offsite.sirket.com"
REMOTE_PATH="/mnt/bootstrap_archive/"
ADMIN_EMAIL="[email protected]"

# Dosyanın var olduğunu kontrol et
if [ ! -f "$BSR_FILE" ]; then
    echo "HATA: Bootstrap dosyasi bulunamadi: $BSR_FILE"
    exit 1
fi

# SCP ile uzak sunucuya kopyala
scp -i /root/.ssh/bacula_key "$BSR_FILE" 
    "bacula@${REMOTE_SERVER}:${REMOTE_PATH}/${JOB_NAME}-$(date +%Y%m%d).bsr"

# E-posta ile gönder (küçük dosyalar için)
if [ $(stat -c%s "$BSR_FILE") -lt 1048576 ]; then
    mail -s "Bootstrap: ${JOB_NAME} - $(date +%Y-%m-%d)" 
         -a "$BSR_FILE" 
         "$ADMIN_EMAIL" < /dev/null
fi

echo "Bootstrap dosyasi basariyla gonderildi."
exit 0

Bu script’i cron’a da ekleyerek periyodik olarak tüm bootstrap dosyalarını yedekleyebilirsiniz. Ancak RunAfterJob ile otomatik çalıştırmak daha güvenilirdir.

Felaket Kurtarma Senaryosu: Director Çöktü

Şimdi gerçek bir felaket senaryosunu adım adım yaşayalım. Farz edelim ki Bacula Director sunucunuz tamamen çöktü, diskleri bozuldu ve Catalog veritabanı gitti. Elde sadece bootstrap dosyaları ve yedek volume’ları var.

1. Yeni Sisteme Bacula Kurulumu

# Debian/Ubuntu üzerinde
apt-get update
apt-get install -y bacula-director bacula-sd bacula-fd bacula-console

# RHEL/CentOS üzerinde
yum install -y bacula-director bacula-storage bacula-client bacula-console

2. Minimal Konfigürasyon

Catalog veritabanı olmadan da restore yapabilmek için minimal bir Director konfigürasyonu yeterlidir:

# /etc/bacula/bacula-dir.conf - Minimal felaket kurtarma konfigürasyonu
Director {
  Name = dr-director
  DIRport = 9101
  QueryFile = "/etc/bacula/query.sql"
  WorkingDirectory = "/var/lib/bacula"
  PidDirectory = "/var/run/bacula"
  Maximum Concurrent Jobs = 5
  Password = "guclu-bir-sifre-buraya"
  Messages = Daemon
}

Storage {
  Name = DR-Storage
  Address = localhost
  SDPort = 9103
  Password = "storage-sifre-buraya"
  Device = FileStorage
  MediaType = File
}

Client {
  Name = localhost-fd
  Address = localhost
  FDPort = 9102
  Catalog = MyCatalog
  Password = "fd-sifre-buraya"
}

Catalog {
  Name = MyCatalog
  dbname = "bacula"
  dbuser = "bacula"
  dbpassword = "db-sifre"
}

Messages {
  Name = Daemon
  mailcommand = "/usr/sbin/bsmtp ..."
  console = all, !skipped, !saved
  append = "/var/log/bacula/bacula.log" = all, !skipped
}

3. Bootstrap ile Restore İşlemi

Artık bextract komutu devreye giriyor. Bu araç, Director veya Catalog’a ihtiyaç duymadan doğrudan bootstrap dosyasıyla çalışır:

# bextract kullanımı - temel syntax
bextract -b /path/to/bootstrap.bsr -V VolumeName /dev/nst0 /restore/path

# Gerçek dünya örneği: Disk tabanlı yedekten restore
bextract 
  -b /mnt/usb/bootstrap/BackupClientA.bsr 
  -V "Vol-0001|Vol-0002" 
  /mnt/backup_storage 
  /mnt/restore_target

# Sadece belirli dosyaları restore etmek için
bextract 
  -b /mnt/usb/bootstrap/BackupClientA.bsr 
  -V "Vol-0001" 
  -w /tmp/bacula_work 
  /mnt/backup_storage 
  /mnt/restore_target

bextract komutunun parametreleri:

  • -b: Bootstrap dosyasının yolu
  • -V: Volume adı veya pipe ile ayrılmış volume listesi
  • -w: Çalışma dizini (büyük restore’lar için önemli)
  • -x: Mevcut dosyaların üzerine yazma
  • -d: Hata ayıklama seviyesi

4. Bant Sürücüsü ile Restore

Eğer teyp sürücünüz varsa ve bantlardan restore yapmanız gerekiyorsa süreç biraz farklı işler:

# Önce bantın konumunu sıfırla
mt -f /dev/nst0 rewind

# Bootstrap dosyasıyla bant üzerinden restore
bextract 
  -b /mnt/offsite/bootstrap/FullBackup-20231101.bsr 
  -V "Tape-001" 
  /dev/nst0 
  /mnt/restored_data

# İşlem takibi için verbose mod
bextract -v 
  -b /mnt/offsite/bootstrap/FullBackup-20231101.bsr 
  -V "Tape-001" 
  /dev/nst0 
  /mnt/restored_data 2>&1 | tee /var/log/dr_restore.log

bconsole ile Bootstrap Restore

Eğer Director hala çalışıyorsa ama sadece Catalog kaybedildiyse, bconsole üzerinden bootstrap ile restore yapabilirsiniz:

# bconsole'a bağlan
bconsole

# Restore komutunu bootstrap ile başlat
*restore bootstrap=/mnt/offsite/bootstrap/BackupClientA.bsr

# Hedef client ve dizini belirt
Run Restore job
Bootstrap:    /mnt/offsite/bootstrap/BackupClientA.bsr
Where:        /mnt/restore_target
Replace:      Always
FileSet:      Full Set
Backup Client: clienta-fd
Restore Client: clienta-fd
Storage:      File1
JobId:        *None*
When:         2023-11-15 02:00:00
Catalog:      MyCatalog
Priority:     10
Plugin Options: *None*
OK to run? (yes/mod/no): yes

Bootstrap Dosyalarının Otomatik Arşivlenmesi

Büyük ortamlarda onlarca, yüzlerce job çalışıyor olabilir. Her birinin bootstrap dosyasını manuel takip etmek imkansız hale gelir. İşte bu durumda merkezi bir bootstrap arşiv sistemi kurmanız gerekir:

#!/bin/bash
# /etc/bacula/scripts/bootstrap_archiver.sh
# Tüm bootstrap dosyalarını tarih bazlı arşivler ve uzak sunucuya gönderir

BOOTSTRAP_DIR="/var/lib/bacula/bootstrap"
ARCHIVE_DIR="/var/lib/bacula/bootstrap_archive"
REMOTE_SERVER="nas.sirket.com"
REMOTE_USER="bacula-archive"
REMOTE_PATH="/backup/bootstrap"
RETENTION_DAYS=90
LOG_FILE="/var/log/bacula/bootstrap_archiver.log"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" >> "$LOG_FILE"
}

log "Bootstrap arşivleme başlıyor..."

# Arşiv dizinini oluştur
mkdir -p "$ARCHIVE_DIR/$(date +%Y%m%d)"

# Bootstrap dosyalarını arşivle
for bsr_file in "$BOOTSTRAP_DIR"/*.bsr; do
    [ -f "$bsr_file" ] || continue
    base_name=$(basename "$bsr_file" .bsr)
    archive_name="${base_name}-$(date +%Y%m%d%H%M%S).bsr"
    
    # Arşive kopyala
    cp "$bsr_file" "$ARCHIVE_DIR/$(date +%Y%m%d)/$archive_name"
    
    # MD5 checksum oluştur
    md5sum "$bsr_file" > "$ARCHIVE_DIR/$(date +%Y%m%d)/${archive_name}.md5"
    
    log "Arşivlendi: $archive_name"
done

# Sıkıştır ve uzak sunucuya gönder
ARCHIVE_TARBALL="/tmp/bootstrap-$(date +%Y%m%d).tar.gz"
tar -czf "$ARCHIVE_TARBALL" -C "$ARCHIVE_DIR" "$(date +%Y%m%d)/"

rsync -az --progress 
    "$ARCHIVE_TARBALL" 
    "${REMOTE_USER}@${REMOTE_SERVER}:${REMOTE_PATH}/"

if [ $? -eq 0 ]; then
    log "Uzak sunucuya gönderim başarılı"
    rm -f "$ARCHIVE_TARBALL"
else
    log "HATA: Uzak sunucuya gönderilemedi!"
fi

# Eski arşivleri temizle
find "$ARCHIVE_DIR" -type d -mtime +$RETENTION_DAYS -exec rm -rf {} + 2>/dev/null

log "Bootstrap arşivleme tamamlandı."

Bu script’i cron’a ekleyin:

# crontab -e
# Her gece 03:00'da çalıştır
0 3 * * * /etc/bacula/scripts/bootstrap_archiver.sh

Bootstrap Dosyasını Doğrulama

Bir bootstrap dosyasını restore öncesinde doğrulamak için bls komutunu kullanabilirsiniz:

# Bootstrap dosyasıyla volume içeriğini listele
bls -b /mnt/offsite/bootstrap/BackupClientA.bsr 
    -V "Vol-0001" 
    /mnt/backup_storage

# Daha ayrıntılı çıktı için
bls -v -b /mnt/offsite/bootstrap/BackupClientA.bsr 
    -V "Vol-0001" 
    /mnt/backup_storage 2>&1 | head -50

# Sadece belirli dosya tiplerini listele
bls -b /mnt/offsite/bootstrap/BackupClientA.bsr 
    -V "Vol-0001" 
    -i "*.conf" 
    /mnt/backup_storage

bls çıktısı şuna benzer bir şey gösterir:

bls: butil.c:289-0 Using device: "/mnt/backup_storage" for reading.
23-Nov 10:15 bls JobId 0: Ready to read from volume "Vol-0001"...
-rw-r--r--   1 root     root         1234 2023-11-01 08:00:00  /etc/nginx/nginx.conf
-rw-r--r--   1 root     root         5678 2023-11-01 07:55:00  /etc/nginx/sites-enabled/default
drwxr-xr-x   2 www-data www-data     4096 2023-11-01 09:00:00  /var/www/html/
...

Sık Karşılaşılan Sorunlar ve Çözümleri

Bootstrap dosyasıyla çalışırken karşılaştığınız hataların büyük çoğunluğu birkaç kategoriye girer:

Volume bulunamıyor hatası: Bootstrap dosyasında yazılı volume adı ile fiziksel olarak elinizde bulunan volume adının birebir eşleşmesi gerekir. Büyük-küçük harf farkına bile dikkat edin.

Checksum uyuşmazlığı: Yedekleme sırasında volume’a yazılan veri ile bootstrap dosyasının üretildiği an arasında bir tutarsızlık var demektir. Bu genellikle donanım sorunu işaretidir.

“Cannot read volume label” hatası: Bantı rewind etmeyi unutmuş olabilirsiniz. mt -f /dev/nst0 rewind komutunu çalıştırın.

VolAddr aralığı dışında hata: Bootstrap dosyası güncel değil ya da farklı bir job’a ait olabilir. Doğru job ID’ye sahip bootstrap dosyasını kullandığınızdan emin olun.

DR Tatbikatı: Bootstrap ile Kısmi Sistem Kurtarma

İyi bir felaket kurtarma planı kağıt üzerinde güzel görünür ama asıl test tatbikattır. Her altı ayda bir şu tatbikatı yapmanızı öneririm:

Bir test sunucusu alın, üzerine temiz bir işletim sistemi kurun ve Bacula’nın hiçbir konfigürasyonu olmadan, sadece bootstrap dosyaları ve erişim sağlayabileceğiniz volume’larla kritik dizinleri restore edin. Bu süreçte tuttuğunuz notlar, gerçek bir felaket anında panik yerine sistemli hareket etmenizi sağlar.

Tatbikat sonrası şu kontrolleri yapın: Restore edilen dosyaların izinleri doğru mu? Sembolik linkler korunmuş mu? Büyük dosyalar tam geldi mi? Bu soruların yanıtları bootstrap sisteminin sağlıklı çalıştığını doğrular.

Sonuç

Bootstrap dosyası, Bacula dünyasında “sigorta poliçenizin sigorta poliçesi” gibidir. Catalog veritabanınız çöksün, Director sunucunuz yansın, her şey dağılıp gitsin; ama bootstrap dosyalarınız güvende olduğu sürece verilerinize geri dönebilirsiniz.

WriteBootstrap direktifini mutlaka aktif hale getirin. Üretilen dosyaları en az iki farklı coğrafi konumda saklayın. Biri bulut depolama, biri fiziksel olsun. Bootstrap dosyalarını sadece saklamakla kalmayın, periyodik olarak test edin. bls komutuyla volume içeriğini listeyebiliyor musunuz, bextract ile test restore yapabiliyor musunuz, bunları düzenli olarak doğrulayın.

Felaket kurtarma planlarında en sık yapılan hata, yedekleri test etmemektir. Testlenmemiş bir yedek, yoktan farksızdır. Bootstrap sisteminizi kurun, otomatize edin ve düzenli olarak tatbikat yapın. O zaman gece yarısı gelen “sunucu çöktü” aramasında eliniz ayağınız titremeez.

Bir yanıt yazın

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