Bacula ile Yedekleme Performansı Optimizasyonu

Tarafındankomut
0 Comments

Yedekleme sisteminizi kurdunuz, çalışıyor, her gece job’lar tamamlanıyor. Güzel. Ama bir sabah fark ediyorsunuz ki full backup 6 saat sürüyor, incremental’lar bile 45 dakikayı buluyor ve tape veya disk üzerindeki alan hızla tükeniyor. İşte bu noktada “çalışıyor” ile “iyi çalışıyor” arasındaki fark ortaya çıkıyor. Bacula güçlü bir sistem ama kutudan çıktığı haliyle optimal performans sunmuyor. Bu yazıda gerçek dünya deneyimlerinden yola çıkarak Bacula performansını nasıl artıracağınızı, darboğazları nasıl tespit edeceğinizi ve production ortamında kanıtlanmış optimizasyon tekniklerini ele alacağız.

Darboğazı Tespit Etmeden Optimizasyon Yapılmaz

Körü körüne ayar değiştirmek zaman kaybıdır. Önce neyin yavaş olduğunu anlamak gerekiyor. Bacula’da performans sorunları genellikle dört noktadan birinde yaşanır: network, disk I/O, katalog veritabanı veya Bacula’nın kendi konfigürasyonu.

Önce mevcut job istatistiklerine bakın:

# bconsole ile son job'ların sürelerini ve hızlarını görün
bconsole << EOF
list jobs last=20
EOF

# Belirli bir job'ın detaylarını inceleyin
bconsole << EOF
list jobid=1234
EOF

Job çıktısında dikkat etmeniz gereken satır şu şekilde görünür:

SD Bytes Written:          125,432,891,392 (125.4 GB)
Rate:                          45,231 KB/s

Bu hız network veya disk limitinizin çok altındaysa sorun Bacula konfigürasyonundadır. Eğer limitlere yakınsa darboğaz altyapıdadır.

Network durumunu gerçek zamanlı izlemek için:

# SD sunucusunda network trafiğini izleyin
iftop -i eth0 -n

# Disk I/O durumunu kontrol edin
iostat -x 2 10

# Bacula Storage Daemon süreçlerinin kaynak kullanımı
ps aux | grep bacula
top -b -n 1 | grep bacula

Bacula Director Optimizasyonu

Job Concurrent Sayısını Artırmak

Varsayılan Bacula kurulumunda aynı anda çalışabilecek job sayısı oldukça düşük tutulmuştur. Özellikle birden fazla client’a sahip ortamlarda bu ciddi bir darboğaz oluşturur.

/etc/bacula/bacula-dir.conf dosyasında Director bölümünü düzenleyin:

Director {
  Name = bacula-dir
  DIRport = 9101
  QueryFile = "/etc/bacula/query.sql"
  WorkingDirectory = "/var/lib/bacula"
  PidDirectory = "/var/run/bacula"
  Maximum Concurrent Jobs = 20
  Password = "your-password-here"
  Messages = Daemon
}

Maximum Concurrent Jobs: Director seviyesinde aynı anda kaç job çalışabileceğini belirler. Varsayılan 1 veya 2’dir, production ortamında 10-20 arası makul bir değerdir.

Storage bölümünde de bu ayarı yapmanız gerekir:

Storage {
  Name = File1
  Address = storage-server
  SDPort = 9103
  Password = "your-storage-password"
  Device = FileChgr1
  Media Type = File
  Maximum Concurrent Jobs = 10
}

Client bazında da concurrent job sınırını kaldırmayı unutmayın. Özellikle güçlü sunuculara backup alırken bu önemlidir:

Client {
  Name = webserver01-fd
  Address = 192.168.1.10
  FDPort = 9102
  Catalog = MyCatalog
  Password = "client-password"
  File Retention = 60 days
  Job Retention = 6 months
  Maximum Concurrent Jobs = 4
  AutoPrune = yes
}

Pool ve Volume Ayarları

Volume boyutunu doğru ayarlamak hem performansı hem de yönetilebilirliği etkiler. Çok küçük volume’lar katalog işlemlerini artırır, çok büyük volume’lar ise restore sürelerini uzatır.

Pool {
  Name = Full-Pool
  Pool Type = Backup
  Recycle = yes
  AutoPrune = yes
  Volume Retention = 30 days
  Maximum Volume Bytes = 50G
  Maximum Volumes = 100
  Label Format = "Full-"
  Storage = File1
  # Volume başına maximum job sayısı
  Maximum Volume Jobs = 1
  # Aynı anda yazılabilecek maksimum volume
  Maximum Concurrent Jobs = 5
}

Maximum Volume Jobs = 1 ayarı full backup’lar için kritiktir. Her full backup kendi volume’una yazılır, bu restore işlemlerini dramatik şekilde hızlandırır.

Storage Daemon Optimizasyonu

Storage Daemon, Bacula’nın en fazla kaynak tüketen bileşenidir. Buradaki ayarlar doğrudan backup ve restore hızını etkiler.

/etc/bacula/bacula-sd.conf dosyasını düzenleyin:

Storage {
  Name = Storage-Daemon
  SDPort = 9103
  WorkingDirectory = "/var/lib/bacula"
  Pid Directory = "/var/run/bacula"
  Maximum Concurrent Jobs = 20
  # SD'nin kullanabileceği maksimum bant genişliği (0 = limitsiz)
  Maximum Network Buffer Size = 131072
  # Heartbeat intervali
  Heartbeat Interval = 300
}

Device {
  Name = FileStorage
  Media Type = File
  Archive Device = /backup/bacula
  LabelMedia = yes
  Random Access = yes
  AutomaticMount = yes
  RemovableMedia = no
  AlwaysOpen = no
  Maximum Concurrent Jobs = 10
  # Buffer boyutunu artır (varsayılan 65536)
  Maximum Block Size = 1048576
  Minimum Block Size = 65536
  # Sparse dosya desteği
  Sparse File = yes
  # Write bant genişliği limiti (0 = limitsiz)
  Maximum Changer Wait = 300
}

Maximum Block Size parametresi çok önemlidir. Varsayılan 65536 byte olan blok boyutunu 1MB’a çıkarmak, özellikle büyük dosyalar yedeklenirken ciddi performans artışı sağlar. Disk bazlı storage için bu değeri 262144 ile 1048576 arasında tutun.

Compression ve Deduplication Stratejisi

Sıkıştırma Ayarları

Sıkıştırma CPU kullanımını artırır ama ağ trafiğini ve disk kullanımını azaltır. Doğru dengeyi bulmak için önce ne tür veri yedeklediğinizi bilmeniz gerekir.

# FileSet konfigürasyonunda sıkıştırma
FileSet {
  Name = "LinuxFull"
  Include {
    Options {
      # lz4 en iyi hız/sıkıştırma dengesini sunar
      Compression = LZ4
      # Zaten sıkıştırılmış dosyaları tekrar sıkıştırmayı atla
      Drive Type = ext4
      Signature = MD5
      # Sparse dosyaları daha verimli yedekle
      Sparse = yes
    }
    File = /home
    File = /var/www
    File = /etc
  }
  Exclude {
    File = /proc
    File = /sys
    File = /dev
    File = /tmp
    File = /var/tmp
    File = /run
    # Zaten sıkıştırılmış dosyaları hariç tut veya farklı işle
    File = /backup/archives
  }
}

LZ4 vs GZIP karşılaştırması:

  • LZ4: Düşük CPU kullanımı, yüksek hız, orta sıkıştırma oranı. Güçlü CPU’ları olmayan sistemler veya SSD storage için ideal.
  • GZIP: Yüksek CPU kullanımı, düşük hız, yüksek sıkıştırma oranı. Bant genişliği kısıtlı ortamlar için tercih edilir.
  • LZO: LZ4’e benzer ama biraz daha eski. Eski sistemlerde LZ4 yoksa kullanılabilir.

Zaten sıkıştırılmış dosyalar için (jpg, mp4, zip, gz, bz2) sıkıştırmayı devre dışı bırakın:

FileSet {
  Name = "MediaFiles"
  Include {
    Options {
      # Medya dosyaları için sıkıştırma kapalı
      Compression = None
      Signature = SHA1
    }
    File = /var/media
  }
  Include {
    Options {
      Compression = LZ4
      Signature = SHA1
    }
    File = /var/www
    File = /home
  }
}

Katalog Veritabanı Optimizasyonu

Çok sayıda client ve uzun süredir çalışan Bacula kurulumlarında katalog veritabanı ciddi bir darboğaz haline gelebilir. Milyonlarca dosya kaydı olan bir katalog, job listesi sorgulamak bile dakikalar sürebilir.

PostgreSQL Optimizasyonu

Eğer katalog için PostgreSQL kullanıyorsanız (önerilen), postgresql.conf dosyasında şu ayarları yapın:

# /etc/postgresql/14/main/postgresql.conf

# Shared buffer'ı RAM'in %25'i olarak ayarlayın
shared_buffers = 4GB

# Effective cache size RAM'in %75'i
effective_cache_size = 12GB

# WAL buffer
wal_buffers = 64MB

# Checkpoint ayarları
checkpoint_completion_target = 0.9
checkpoint_timeout = 10min

# Paralel sorgu (PostgreSQL 9.6+)
max_parallel_workers_per_gather = 4

# Maintenance work memory (VACUUM, index rebuild için)
maintenance_work_mem = 1GB

# Autovacuum agresifliği
autovacuum_vacuum_scale_factor = 0.01
autovacuum_analyze_scale_factor = 0.005

Katalog üzerinde periyodik bakım yapmak şarttır:

#!/bin/bash
# /usr/local/sbin/bacula-catalog-maintenance.sh

# Katalog istatistiklerini güncelle
echo "Katalog istatistikleri güncelleniyor..."
psql -U bacula -d bacula -c "VACUUM ANALYZE;"

# Şişmiş indexleri yeniden oluştur
psql -U bacula -d bacula -c "REINDEX DATABASE bacula;"

# Eski job kayıtlarını temizle (bconsole üzerinden)
bconsole << EOF
prune jobs yes
prune files yes
prune stats yes
EOF

echo "Katalog bakımı tamamlandı: $(date)"

Bu scripti haftalık cron’a ekleyin:

# crontab -e
0 3 * * 0 /usr/local/sbin/bacula-catalog-maintenance.sh >> /var/log/bacula/catalog-maintenance.log 2>&1

Network Optimizasyonu

Bant Genişliği Kontrolü

Production saatlerinde backup trafiğinin network’ü doldurmasını engellemek için bant genişliği limitleri koyabilirsiniz:

Job {
  Name = "WebServer-Incremental"
  JobDefs = "DefaultJob"
  Client = webserver01-fd
  FileSet = "LinuxFull"
  Schedule = "WeeklyCycle"
  Storage = File1
  
  # Mesai saatlerinde bant genişliğini kısıtla (KB/s cinsinden)
  # Bu özellik Bacula 7.0+ gerektirir
  Maximum Bandwidth = 50000  # 50 MB/s
}

Eğer birden fazla client’tan aynı anda backup alıyorsanız ve network daralmaya başlıyorsa, Schedule’ı düzenleyerek job’ları dağıtın:

Schedule {
  Name = "StaggeredSchedule"
  Run = Full 1st sun at 01:00
  Run = Full 2nd sun at 01:30
  Run = Full 3rd sun at 02:00
  Run = Full 4th sun at 02:30
  Run = Incremental mon-sat at 03:00
  Run = Incremental mon-sat at 03:15 client=webserver02-fd
  Run = Incremental mon-sat at 03:30 client=dbserver01-fd
}

File Daemon Optimizasyonu

Client tarafında da bazı önemli ayarlar var. /etc/bacula/bacula-fd.conf dosyasında:

FileDaemon {
  Name = webserver01-fd
  FDport = 9102
  WorkingDirectory = /var/lib/bacula
  Pid Directory = /var/run/bacula
  Maximum Concurrent Jobs = 4
  # Heartbeat, uzun süren backup'larda bağlantının kopmamasını sağlar
  Heartbeat Interval = 300
  # FD'nin kullanabileceği maximum memory
  # Büyük FileSet'lerde bu değeri artırmak gerekebilir
  Maximum Network Buffer Size = 131072
}

Incremental ve Differential Backup Stratejisi

Performans optimizasyonunun en etkili yöntemlerinden biri doğru backup tipini doğru sıklıkta çalıştırmaktır.

# Kurumsal ortam için optimize edilmiş schedule örneği
Schedule {
  Name = "EnterpriseSchedule"
  
  # Ayın ilk pazarı: Full backup
  Run = Level=Full 1st mon at 22:00
  
  # Her pazar: Differential (full'dan bu yana değişenler)
  Run = Level=Differential sun at 22:00
  
  # Her gün: Incremental (son backup'tan bu yana değişenler)
  Run = Level=Incremental mon-sat at 02:00
}

# Her backup tipi için ayrı pool kullanın
Job {
  Name = "FileServer-Backup"
  Client = fileserver01-fd
  FileSet = "LinuxFull"
  Schedule = "EnterpriseSchedule"
  Storage = File1
  
  # Full backup için farklı pool
  Full Backup Pool = Full-Pool
  # Differential için ayrı pool
  Differential Backup Pool = Diff-Pool
  # Incremental için ayrı pool
  Incremental Backup Pool = Inc-Pool
  
  Write Bootstrap = "/var/lib/bacula/fileserver01.bsr"
  Priority = 10
}

Backup Performansını İzleme ve Raporlama

Optimizasyonun sürdürülebilir olması için düzenli izleme şarttır. Bir monitoring scripti hazırlayın:

#!/bin/bash
# /usr/local/sbin/bacula-performance-report.sh

REPORT_FILE="/var/log/bacula/performance-$(date +%Y%m%d).log"
THRESHOLD_SPEED=30000  # KB/s cinsinden minimum kabul edilebilir hız

echo "=== Bacula Performans Raporu ===" > $REPORT_FILE
echo "Tarih: $(date)" >> $REPORT_FILE
echo "" >> $REPORT_FILE

# Son 24 saatin job'larını listele ve yavaş olanları işaretle
bconsole << 'EOF' | grep -A5 "JobId" >> $REPORT_FILE
list jobs last=50
EOF

# Tamamlanan job'ların ortalama hızını hesapla
psql -U bacula -d bacula -t -c "
SELECT 
    Name,
    Level,
    ROUND(JobBytes / 1024.0 / NULLIF(JobTDate - SchedTime, 0), 2) as speed_kbs,
    JobBytes / 1024 / 1024 as size_mb,
    StartTime,
    EndTime
FROM Job 
WHERE JobStatus = 'T' 
AND StartTime > NOW() - INTERVAL '24 hours'
ORDER BY speed_kbs ASC;
" >> $REPORT_FILE

echo "" >> $REPORT_FILE
echo "=== Katalog Boyutu ===" >> $REPORT_FILE
psql -U bacula -d bacula -t -c "
SELECT 
    schemaname,
    tablename,
    pg_size_pretty(pg_total_relation_size(schemaname||'.'||tablename)) as size
FROM pg_tables 
WHERE schemaname = 'public'
ORDER BY pg_total_relation_size(schemaname||'.'||tablename) DESC
LIMIT 10;
" >> $REPORT_FILE

cat $REPORT_FILE | mail -s "Bacula Günlük Performans Raporu" [email protected]

Gerçek Dünya Senaryosu: 500GB Nightly Backup Optimizasyonu

Bir e-ticaret müşterisinde karşılaştığım senaryoyu paylaşayım. 15 sunucu, toplam 500GB günlük incremental backup, gece 02:00’de başlıyor ve sabah 07:30’da bitmesi gerekiyor. İlk kurulumda 10 saati aşıyordu.

Tespit edilen sorunlar:

  • Maximum Concurrent Jobs = 2 (varsayılan)
  • Block Size = 65536 (varsayılan)
  • GZIP compression (yüksek CPU, düşük hız)
  • Katalog üzerinde hiç bakım yapılmamış, 18 aylık veri birikmiş
  • Tüm job’lar aynı anda başlatılmış, network saturasyonu

Uygulanan çözümler:

# Director'da concurrent job limitini kaldır
# Maximum Concurrent Jobs = 20

# Storage block size artırımı
# Maximum Block Size = 524288

# Compression değişikliği
# Compression = LZ4 (GZIP'ten geçiş)

# Job'ları 10'ar dakika arayla başlat
# Schedule'da stagger uygula

# Katalog temizliği
bconsole << EOF
prune jobs yes
prune files yes
delete volume=OldVolume001 yes
EOF

# PostgreSQL VACUUM
psql -U bacula -d bacula -c "VACUUM FULL ANALYZE;"

Bu değişikliklerden sonra toplam süre 10 saatten 4.5 saate düştü. Compression değişikliği tek başına %40 hız artışı sağladı.

Tape Library Ortamında Ek Optimizasyonlar

Eğer hala tape kullanıyorsanız (büyük arşivler için hala mantıklı), birkaç ek ayar daha var:

Device {
  Name = TapeLibrary
  Media Type = LTO8
  Archive Device = /dev/nst0
  AutomaticMount = yes
  AlwaysOpen = yes
  RemovableMedia = yes
  RandomAccess = no
  
  # Tape için büyük blok boyutu kritik
  Maximum Block Size = 2097152   # 2MB
  Minimum Block Size = 65536
  
  # Hardware sıkıştırma varsa yazılım sıkıştırmayı kapat
  # Drive Crypto = yes
  
  # Tape dolmadan önce ne kadar alan bırakılacak
  Maximum Volume Files = 10000
  
  # Alert komutları
  Alert Command = "tapeinfo -f %c"
}

Tape ortamında altın kural: Hardware sıkıştırma destekleyen modern LTO sürücülerde yazılım sıkıştırması (GZIP, LZ4) kapatılmalıdır. İkili sıkıştırma hem CPU yiyor hem de veriyi genişletebiliyor.

Sonuç

Bacula performans optimizasyonu tek seferlik bir iş değil, sürekli izleme ve ayarlama gerektiren bir süreçtir. Özetlemek gerekirse, önce darboğazı tespit edin, sonra sırayla Director’daki concurrent job limitlerini artırın, Storage Daemon’da block size’ı yükseltin, compression algoritmasını iş yüküne göre seçin (çoğu durumda LZ4 kazanır), katalog veritabanını düzenli bakıma alın ve son olarak job’larınızı schedule üzerinde dağıtarak network satürasyonunu önleyin. Bu adımları uyguladıktan sonra çoğu ortamda %50 ile %70 arasında bir performans artışı görmek mümkün. Ölçmeden iyileştirme olmaz, bu yüzden her değişiklikten önce ve sonra job sürelerini kaydedin ve karşılaştırın.

Bir yanıt yazın

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