Belajar Bacula - Multi-client & Multi-Director

#Pendahuluan

Hingga episode 14 kita mengelola satu client. Sekarang mari naik kelas: puluhan, ratusan, bahkan ribuan client. Pertanyaannya bukan lagi "bagaimana menambah client", melainkan "bagaimana menjaga sistem tetap tertata dan tetap hidup saat skalanya naik". Di episode 15 kita menjawab dua hal itu: skala horizontal (banyak client) dan ketersediaan (HA).

Pola yang akan kita bangun: satu Director mengelola banyak FD dan beberapa SD, konfigurasi diorganisir per-tenant dengan resource Client dan ACL, lalu opsi ketersediaan tinggi untuk Director dan Storage.

#Satu Director, Banyak Client

#Menambah Client dan Job

Tidak ada batas keras jumlah client per Director — batasannya adalah disiplin konfigurasi dan performa. Setiap client butuh resource Client + setidaknya satu Job:

Pola client + job

Client {
  Name = app-01-fd
  Address = 10.0.0.21
  FDPort = 9103
  Password = "pwd-app-01"
}
Job {
  Name = "Backup app-01"
  Type = Backup
  Client = app-01-fd
  FileSet = "Set Server"
  Schedule = WeeklyCycle
  Storage = FileStorage
  Pool = FilePool
}

Dengan ratusan client, pola ini menjadi berulang. Solusi nyata: generate konfigurasi dari inventory (Ansible template, script, atau CMDB) — bukan menulis manual. Konfigurasi yang digenerate juga lebih mudah diaudit.

Note

Beberapa resource Bacula mendukung definisi multiple resources dalam satu blok — tetapi untuk kejelasan audit, satu client = satu blok Client terpisah jauh lebih mudah dibaca dan di-debug daripada menggabungkan nama client dalam satu blok.

#Storage Daemon Ganda

Satu Director bisa memakai beberapa SD sekaligus — misal SD di dua lokasi geografis. Resource Storage di bacula-dir.conf menunjuk masing-masing SD, dan setiap job memilih Storage tujuan:

Dua SD berbeda

Storage {
  Name = StorageJakarta
  Address = 10.0.0.5
  SDPort = 9102
  Password = "rahasia-sd-jkt"
  Device = FileStorage
  MediaType = File
}
Storage {
  Name = StorageSurabaya
  Address = 10.0.0.15
  SDPort = 9102
  Password = "rahasia-sd-sby"
  Device = FileStorage
  MediaType = File
}

Pola ini membuka strategi: backup lokal ke SD terdekat, lalu job Copy/Migration memindahkan ke SD lokasi lain untuk DR.

#Konfigurasi Per-Tenant

#Resource Client dan Pool Terpisah

Untuk multi-tenant (beberapa departemen/klien menggunakan satu sistem Bacula), kunci isolasinya ada di tiga resource: Client (siapa), Pool (data ke mana), dan FileSet (apa yang boleh). Setiap tenant mendapat pool sendiri:

Pool per tenant

Pool {
  Name = PoolDepartemenA
  Pool Type = Backup
  Recycle = yes
  AutoPrune = yes
  Volume Retention = 30 days
}
Pool {
  Name = PoolDepartemenB
  Pool Type = Backup
  Recycle = yes
  AutoPrune = yes
  Volume Retention = 90 days
}

Volume dipisah per pool — tenant A tidak pernah menimpa volume tenant B, dan retention bisa berbeda sesuai kontrak.

#ACL (Access Control)

Bacula mendukung ACL di resource Console untuk membatasi perintah yang boleh dijalankan sebuah konsol. Contoh: konsol khusus yang hanya boleh menjalankan job tertentu:

Console dengan ACL job

Console {
  Name = operator-a
  Password = "pwd-operator-a"
  CommandACL = status, list
  JobACL = BackupDeptA-*
  ClientACL = dept-a-fd-*
  StorageACL = StorageJakarta
  PoolACL = PoolDepartemenA
  FileSetACL = "Set Dept A"
}

Dengan ACL, operator departemen A tidak bisa melihat job, client, atau pool departemen B — isolasi operasional yang dibutuhkan di lingkungan bersama. Ini adalah fitur yang membedakan Bacula dari tool backup sederhana.

Warning

ACL membatasi konsol, bukan daemon. Siapa pun yang punya akses root ke file konfigurasi atau ke database catalog bisa melewatinya. Untuk isolasi keamanan sejati antar tenant, gunakan beberapa Director terpisah — ACL adalah kontrol operasional, bukan kontrol keamanan keras.

#Ketersediaan Tinggi

#Director HA

Director adalah titik kegagalan tunggal: jika mati, semua backup terjadwal berhenti. Opsi HA:

Bacula Enterprise menyediakan Director HA dengan failover terkelola.
Community bisa memakai pola active/passive: dua server Director berbagi database catalog yang sama (misal PostgreSQL dengan replication), dan alamat IP virtual (keepalived) berpindah saat kegagalan.

Pola Director HA Community

+--------------------+
| VIP 10.0.0.50:9101 |
+--------------------+
    |          |
+--------+  +--------+
| Dir A  |  | Dir B  |
| (active)| |(passive)|
+--------+  +--------+
    \          /
   PostgreSQL (shared/replicated)

Yang kritis dalam pola ini: client dan SD harus mengarah ke VIP, bukan alamat IP host tertentu, dan catalog harus dibagikan dengan aman.

#SD Clustering

Storage Daemon bisa diskalakan dengan beberapa SD yang menangani device berbeda. Bacula Enterprise mendukung SD clustering dengan failover terkelola. Di Community, pola praktisnya:

Satu SD per lokasi/rack, device terpisah per grup client.
Monitor kesehatan tiap SD; jika satu SD mati, job yang mengarah ke SD tersebut gagal — jadi pastikan alert (episode 20) menangkapnya cepat.

Distribusi job antar SD

Job {
  Name = "Backup app-02"
  Type = Backup
  Client = app-02-fd
  FileSet = "Set Server"
  Storage = StorageSurabaya
  Pool = FilePool
}

Tip

Jangan jadikan SD sebagai tempat menyimpan catalog. Pisahkan database catalog di host/replika yang berdiri sendiri — jika SD mati, catalog tetap hidup dan restore masih mungkin dari SD lain; jika catalog mati, semuanya butuh recovery (episode 16).

#Penutup

Inti yang harus dibawa pulang:

Satu Director melayani ratusan client; generate konfigurasi dari inventory, bukan manual.
Beberapa SD memungkinkan distribusi storage dan strategi DR lintas lokasi.
Per-tenant: Client + Pool + FileSet terpisah, ditambah Console ACL untuk isolasi operasional.
ACL membatasi konsol; untuk isolasi keras gunakan Director terpisah.
Director HA via shared catalog + VIP; SD clustering via beberapa SD terpantau.

Di episode 16 selanjutnya kita akan troubleshooting dan debug — mode debug bacula-dir -d 100, log di /var/log/bacula/, status via bconsole, kasus-kasus umum (autentikasi gagal, tape penuh, catalog lock), serta pemulihan catalog dan restore dari tape. Inilah kemampuan yang menentukan reputasi kalian saat produksi bermasalah.