Bacula Yedekleme Sistemi Nedir: Mimari ve Bileşenler

Tarafındankomut
0 Comments

Yedekleme sistemleri söz konusu olduğunda, çoğu sysadmin önce rsync veya basit bir tar scripti ile başlar. Sonra bir gün felaket gelir: disk patlar, silme komutu yanlış dizinde çalışır, ya da RAID array’in iki diski aynı anda biter. İşte o zaman “gerçek bir yedekleme sistemi kurmalıydım” diye düşünürsünüz. Bacula tam da bu ihtiyaç için tasarlanmış, kurumsal düzeyde, açık kaynaklı bir yedekleme çözümüdür. Bu yazıda Bacula’nın ne olduğunu, nasıl çalıştığını ve mimarisini detaylıca inceleyeceğiz.

Bacula Nedir?

Bacula, ağ üzerinden birden fazla istemcinin yedeğini merkezi olarak yönetebilen, açık kaynaklı bir yedekleme ve kurtarma sistemidir. 2000 yılında Kern Sibbald tarafından geliştirilen proje, bugün hala aktif olarak geliştirilmekte ve pek çok kurumsal ortamda kullanılmaktadır.

Bacula’yı diğer yedekleme araçlarından ayıran en önemli özellik, modüler mimarisidir. Sistem birden fazla bağımsız servisin birlikte çalışması üzerine kurulmuştur. Bu yaklaşım ilk bakışta karmaşık görünebilir, ama bir kez kurduğunuzda neden böyle tasarlandığını anlarsınız: her bileşen bağımsız olarak ölçeklenebilir, izlenebilir ve yönetilebilir.

Bacula’nın desteklediği yedekleme türleri şunlardır:

  • Full Backup: Tüm verilerin eksiksiz yedeği alınır
  • Incremental Backup: Son yedekten bu yana değişen dosyalar yedeklenir
  • Differential Backup: Son Full yedekten bu yana değişen tüm dosyalar yedeklenir

Bu üç yedekleme stratejisini birleştirerek hem depolama alanını optimize edebilir hem de kurtarma sürelerini minimumda tutabilirsiniz.

Bacula Mimarisi: Büyük Resim

Bacula’yı anlamanın en iyi yolu, sistemi bir bütün olarak görmekten geçer. Standart bir Bacula kurulumunda üç ana sunucu rolü ve bir konsol arayüzü bulunur.

Senaryo olarak şunu düşünelim: 20 sunucusu olan bir şirketsiniz. Bazıları fiziksel, bazıları sanal. Veritabanı sunucularınız var, web sunucularınız var, dosya sunucularınız var. Her birinin günlük yedeğini almak istiyorsunuz. Bacula bu senaryoyu merkezi bir noktadan yönetmenizi sağlar.

Temel bileşenler şunlardır:

  • Director (DIR): Merkezi yönetim servisi, tüm işlemleri koordine eder
  • Storage Daemon (SD): Yedek verilerini fiziksel medyaya yazar ve okur
  • File Daemon (FD): İstemci üzerinde çalışır, yedeklenecek dosyaları gönderir
  • Catalog: Yedek meta verilerini tutan veritabanı (genellikle PostgreSQL veya MySQL)
  • Console (bconsole): Yöneticinin sistemle iletişim kurduğu arayüz

Bu bileşenler aynı sunucuda çalışabileceği gibi, farklı sunuculara dağıtılmış olarak da çalışabilir. Küçük ortamlar için genellikle Director, Storage Daemon ve Catalog aynı sunucuda bulunur.

Director: Orkestranın Şefi

Bacula Director, tüm yedekleme operasyonlarının beynidir. Job zamanlama, istemci koordinasyonu, depolama yönetimi gibi tüm kararlar Director tarafından alınır. Director çalışmazsa hiçbir yedekleme işlemi başlatılamaz.

Director’ın yapılandırma dosyası genellikle /etc/bacula/bacula-dir.conf yolunda bulunur. Bu dosya oldukça kapsamlıdır çünkü tüm sistemi burada tanımlarsınız.

Örnek bir Director yapılandırmasının temel kısmı şöyle görünür:

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

Name: Director’ın sistem içindeki adıdır, diğer bileşenler bu isimle Director’ı tanır.

DIRport: Director’ın dinlediği port numarasıdır. Varsayılan 9101’dir.

Maximum Concurrent Jobs: Aynı anda kaç yedekleme işinin çalışabileceğini belirler. Bu değeri sunucunuzun kapasitesine göre ayarlayın.

Password: Konsol bağlantıları için kullanılan şifredir. Güçlü bir şifre seçin.

Director yapılandırmasında ayrıca Job tanımları, Schedule’lar, Pool tanımları ve FileSet tanımları da yer alır. Bunları ilerleyen bölümlerde ayrıntılı ele alacağız.

Storage Daemon: Veriyi Tutan Kısım

Storage Daemon, yedek verilerinin fiziksel olarak yazıldığı ve okunduğu bileşendir. Director bir yedekleme işi başlattığında, File Daemon dosyaları doğrudan Storage Daemon’a gönderir. Bant sürücüsü, disk havuzu veya NFS mount gibi farklı depolama ortamları Storage Daemon üzerinden yönetilir.

Storage Daemon yapılandırma dosyası genellikle /etc/bacula/bacula-sd.conf yolundadır:

Storage {
  Name = bacula-sd
  SDPort = 9103
  WorkingDirectory = "/var/lib/bacula"
  PidDirectory = "/run/bacula"
  Maximum Concurrent Jobs = 20
  SDAddress = 192.168.1.10
}

Device {
  Name = FileStorage
  Media Type = File
  Archive Device = /backup/bacula
  LabelMedia = yes
  Random Access = Yes
  AutomaticMount = yes
  RemovableMedia = no
  AlwaysOpen = no
  Maximum Concurrent Jobs = 5
}

SDPort: Storage Daemon’ın dinlediği port, varsayılan 9103’tür.

Archive Device: Yedeklerin fiziksel olarak yazılacağı dizin veya cihaz dosyasıdır.

LabelMedia: Yeni medya eklendiğinde otomatik olarak etiketlenip etiketlenmeyeceğini belirler.

Maximum Concurrent Jobs: Storage Daemon’ın aynı anda kaç iş yapabileceğini belirtir. Disk tabanlı depolamada bu değer daha yüksek tutulabilir.

Gerçek dünyada Storage Daemon için genellikle ayrı bir büyük disk alanına ihtiyaç duyarsınız. 50 sunucunun yedeğini alıyorsanız ve her sunucu ortalama 100 GB veri içeriyorsa, 30 günlük retention süresi için ciddi bir depolama hesabı yapmanız gerekir.

File Daemon: İstemci Tarafındaki Ajan

File Daemon (bazen Client veya FD olarak da adlandırılır), yedeklenecek her sistemde çalışan küçük bir ajandır. Görevleri şunlardır: Director’dan gelen komutları almak, dosya sistemini taramak, değişen dosyaları tespit etmek ve bunları Storage Daemon’a göndermek.

File Daemon’ın kurulumu oldukça basittir. Debian/Ubuntu tabanlı sistemlerde:

apt-get install bacula-client

# Servisi başlat
systemctl start bacula-fd
systemctl enable bacula-fd

# Servis durumunu kontrol et
systemctl status bacula-fd

Red Hat/CentOS tabanlı sistemlerde:

yum install bacula-client
# veya
dnf install bacula-client

systemctl start bacula-fd
systemctl enable bacula-fd

File Daemon yapılandırma dosyası /etc/bacula/bacula-fd.conf yolundadır:

FileDaemon {
  Name = webserver01-fd
  FDport = 9102
  WorkingDirectory = /var/lib/bacula
  PidDirectory = /run/bacula
  Maximum Concurrent Jobs = 3
  FDAddress = 192.168.1.50
}

Director {
  Name = bacula-dir
  Password = "IstemciSifresi456!"
}

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

Name: Bu istemcinin sistem içindeki adıdır. Director tarafındaki Client tanımıyla eşleşmesi gerekir.

FDport: File Daemon’ın dinlediği port, varsayılan 9102’dir.

Password: Director ile iletişim için kullanılan şifredir. Director tarafındaki Client tanımındaki şifreyle aynı olmalıdır.

Dikkat edilmesi gereken önemli bir nokta: File Daemon’ın şifresi, Director yapılandırmasındaki Client bloğunun şifresiyle birebir aynı olmalıdır. Bu şifre uyuşmazlıkları, sysadminlerin en çok zaman harcadığı sorunlardan biridir.

Catalog: Yedeklerin Kayıt Defteri

Catalog, Bacula’nın veritabanı bileşenidir. Hangi dosyanın ne zaman yedeklendiği, hangi Volume’da bulunduğu, job istatistikleri gibi tüm meta veriler burada saklanır. Bacula PostgreSQL, MySQL/MariaDB ve SQLite veritabanlarını destekler.

Üretim ortamları için PostgreSQL veya MySQL kullanmanızı kesinlikle öneririm. SQLite küçük test ortamları için uygun olsa da, binlerce dosyanın meta verisini yönetirken performans sorunları yaşayabilirsiniz.

Catalog’un önemi şuradan anlaşılır: Bir felaket senaryosunda “3 hafta önceki halini geri yükle” dediğinizde, Bacula Catalog’a bakarak o tarihteki yedeğin hangi Volume’da ve hangi pozisyonda olduğunu bulur. Catalog olmadan restore işlemi çok daha zorlaşır.

Director yapılandırmasında Catalog şöyle tanımlanır:

Catalog {
  Name = MyCatalog
  dbname = "bacula"
  dbuser = "bacula"
  dbpassword = "VeriTabanıSifresi789!"
  dbaddress = "localhost"
  dbport = 5432
}

Catalog veritabanını oluşturduktan sonra Bacula’nın kendi tablo yapısını oluşturması için şu scripti çalıştırmanız gerekir:

# PostgreSQL için
/usr/libexec/bacula/create_bacula_database
/usr/libexec/bacula/make_bacula_tables
/usr/libexec/bacula/grant_bacula_privileges

# Veritabanı bağlantısını test et
echo "select * from Version;" | /usr/libexec/bacula/bacula-dir -t

Catalog’un düzenli olarak temizlenmesi de önemlidir. Çok eski job kayıtları veritabanını şişirebilir. Director yapılandırmasında AutoPrune ve Volume Retention parametreleri bu temizliği otomatize eder.

Job, Schedule ve FileSet Kavramları

Bacula’da yedekleme işlerini tanımlamak için üç temel yapıya ihtiyaç duyarsınız: Job, Schedule ve FileSet.

FileSet, hangi dosya ve dizinlerin yedekleneceğini tanımlar:

FileSet {
  Name = "WebServer-FileSet"
  Include {
    Options {
      signature = MD5
      compression = GZIP
    }
    File = /var/www
    File = /etc/nginx
    File = /etc/ssl
  }
  Exclude {
    File = /var/www/cache
    File = /tmp
    File = /proc
    File = /sys
  }
}

signature = MD5 ile her dosyanın MD5 özeti hesaplanır, bu sayede veri bütünlüğü doğrulanabilir.

compression = GZIP ile veriler sıkıştırılarak depolama alanından tasarruf edilir.

Schedule, yedeklerin ne zaman alınacağını belirler:

Schedule {
  Name = "WeeklyCycle"
  Run = Full 1st sun at 23:05
  Run = Differential 2nd-5th sun at 23:05
  Run = Incremental mon-sat at 23:05
}

Bu schedule ile her ayın ilk Pazar günü full yedek, diğer Pazar günleri differential yedek ve hafta içi her gece incremental yedek alınır. Bu klasik ve etkili bir stratejidir.

Job, tüm bu parçaları bir araya getirir:

Job {
  Name = "WebServer-Backup"
  Type = Backup
  Client = webserver01-fd
  FileSet = "WebServer-FileSet"
  Schedule = "WeeklyCycle"
  Storage = bacula-sd
  Messages = Standard
  Pool = Default
  Priority = 10
  Write Bootstrap = "/var/lib/bacula/webserver01.bsr"
}

Priority: Birden fazla job aynı anda tetiklenirse, düşük priority değerine sahip olan önce çalışır.

Write Bootstrap: Bootstrap dosyası, Catalog olmadan da restore yapabilmek için gerekli bilgileri içerir. Bu dosyanın ayrı bir yerde yedeklenmesi iyi bir pratiktir.

Volume ve Pool Yönetimi

Volume, Bacula’da bir yedek birimi anlamına gelir. Fiziksel olarak bir bant kaseti veya bir disk dosyası olabilir. Pool ise birden fazla Volume’u mantıksal olarak gruplandırır.

Director yapılandırmasında bir Pool şöyle tanımlanır:

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

Volume Retention: Bir Volume’un kaç gün saklanacağını belirtir. Bu süre dolduktan sonra Volume yeniden kullanılabilir hale gelir.

Maximum Volume Bytes: Bir Volume dosyasının maksimum boyutunu belirler. 50G olarak ayarlandığında, her Volume dosyası en fazla 50 GB büyüklüğünde olur.

Label Format: Yeni Volume’lara otomatik olarak atanacak isim formatıdır. “Vol-” ile başlayan isimler Vol-0001, Vol-0002 şeklinde devam eder.

bconsole: Yönetim Arayüzü

bconsole, Bacula yöneticisinin sistemi yönettiği komut satırı arayüzüdür. Yedekleme durumunu izlemek, manuel job başlatmak, restore işlemi yapmak gibi tüm operasyonlar bconsole üzerinden gerçekleştirilir.

# bconsole'u başlat
bconsole

# Tüm job'ların durumunu göster
*status director

# Belirli bir client'ın durumunu göster
*status client=webserver01-fd

# Manuel olarak bir job başlat
*run job=WebServer-Backup

# Son job'ların listesi
*list jobs

# Belirli bir job'ın detayları
*list joblog jobid=123

# Restore işlemi başlat
*restore client=webserver01-fd

# Volume listesi
*list volumes

# bconsole'dan çık
*quit

Restore işlemi bconsole üzerinden oldukça interaktif bir şekilde yapılır. Dosya ağacında gezinerek hangi dosyaları geri yükleyeceğinizi seçebilirsiniz. Bu özellik, tek bir dosyayı geri yüklemek için bile tam bir sistemin restore edilmesini engelleyen, zaman kazandıran bir yetenektir.

Gerçek bir senaryoda şöyle bir durum yaşanabilir: Bir geliştirici yanlışlıkla production’daki bir konfigürasyon dosyasını silmiş. bconsole ile o dosyanın son yedekteki halini bulup sadece o dosyayı geri yükleyebilirsiniz. Tüm sistemi restore etmek zorunda kalmazsınız.

Güvenlik Mimarisi

Bacula bileşenleri arasındaki iletişim şifreli ve şifreye dayalı kimlik doğrulama ile korunur. Her bileşen çifti arasında ayrı bir şifre tanımlanmalıdır:

  • Director – Console arasında bir şifre
  • Director – Storage Daemon arasında bir şifre
  • Director – her File Daemon arasında ayrı birer şifre

Bu şifreler, Bacula’nın kendi basit challenge-response protokolüyle kullanılır. Üretim ortamlarında TLS şifrelemesini de aktive etmek iyi bir pratiktir:

# Director yapılandırmasına TLS eklemek
Director {
  Name = bacula-dir
  # ... diğer parametreler ...
  TLS Enable = yes
  TLS Require = yes
  TLS CA Certificate File = /etc/bacula/ssl/ca.pem
  TLS Certificate = /etc/bacula/ssl/director.pem
  TLS Key = /etc/bacula/ssl/director.key
}

Güvenlik duvarı tarafında açılması gereken portlar şunlardır:

  • 9101: Director’a bconsole bağlantıları için
  • 9102: File Daemon portları, Director’dan istemcilere bağlantı için
  • 9103: Storage Daemon portu, Director ve File Daemon’lardan gelen bağlantılar için

Bacula ve Bareos: Kısa Bir Karşılaştırma

Bacula araştırırken mutlaka Bareos ile karşılaşırsınız. Bareos, 2010 yılında Bacula’nın fork’u olarak ortaya çıkmıştır ve topluluk tarafından aktif olarak geliştirilmektedir.

Temel farklar şunlardır:

  • Lisans: Bareos tamamen AGPLv3 ile lisanslıdır. Bacula ise AGPLv3 ile birlikte ticari bileşenler de içerir.
  • Web Arayüzü: Bareos, WebUI ile birlikte gelir. Bacula’da Baculum gibi üçüncü parti çözümler kullanılır.
  • Paket Desteği: Bareos resmi paket depolarını daha aktif tutar.
  • Kompatibilite: İki sistem aynı protokolü kullandığı için bileşenler belirli ölçüde birlikte çalışabilir.

Eğer sıfırdan bir kurulum yapıyorsanız Bareos’u da değerlendirmenizi öneririm. Ancak mevcut bir Bacula kurulumunuz varsa veya Bacula’nın ekosistemi ile daha aşinaysanız, Bacula ile devam etmek mantıklıdır.

Tipik Deployment Senaryoları

Küçük Ortam (5-10 sunucu): Director, Storage Daemon ve Catalog aynı sunucuda çalışır. Her istemcide File Daemon kurulu olur. Depolama için büyük bir disk havuzu veya NAS yeterlidir.

Orta Ölçekli Ortam (10-50 sunucu): Director ve Catalog ayrı bir sunucuda, Storage Daemon ayrı bir depolama sunucusunda çalışır. Birden fazla Storage Daemon farklı lokasyonlara yedek alabilir.

Büyük Ortam (50+ sunucu): Birden fazla Director veya pasif Director konfigürasyonu düşünülür. Storage Daemon’lar farklı veri merkezlerinde çalışır. Catalog için yüksek erişilebilirlik konfigürasyonu uygulanır. Tape library entegrasyonu değerlendirilir.

Sonuç

Bacula’nın mimarisini anlamak, sistemi başarıyla kurmak ve yönetmek için kritik öneme sahiptir. Director, Storage Daemon, File Daemon ve Catalog’un her birinin ayrı rolleri vardır ve bu roller birbirini tamamlar. İlk kurulumda bu çok bileşenli yapı karmaşık gelebilir, ancak her bileşenin neden var olduğunu anladığınızda sistemin zarif tasarımını fark edersiniz.

En önemli çıkarım şudur: Bacula sadece bir yedekleme aracı değil, bir yedekleme altyapısıdır. Kurumsal ortamlarda onlarca, yüzlerce sunucunun yedeğini merkezi olarak yönetmek, schedule’ları koordine etmek ve restore işlemlerini hızlı yapmak için ihtiyaç duyduğunuz tüm araçları sunar.

Bir sonraki yazıda Bacula’nın adım adım kurulumunu, bileşenlerin yapılandırılmasını ve ilk yedekleme işinin nasıl çalıştırılacağını ele alacağız. O zamana kadar bu mimariyi aklınızda tutun, zira yapılandırma dosyalarındaki her satırın neye karşılık geldiğini anlamak büyük fark yaratacak.

Bir yanıt yazın

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