Często w trakcie wdrażania backupów występuje potrzeba stworzenia dedykowanego klienta backupowego, który związany byłby z backupowaną aplikacją czy bazą danych. Związanie takie będzie szczególnie pomocne podczas konfigurowania backupów usług klastrowych czy często¹ migrujących aplikacji.

W takim wypadku pomocne będzie stworzenie wirtualnego klienta backupowego. Klient taki będzie przez oprogramowanie Bacula traktowane jak każdy inny klient, w szczególności pojawi się na liście klientów dla których wykonywane są backupy. Klienta takiego definiujemy tak samo jak każdego standardowego klienta, nadając mu unikalną nazwę ze wskazaniem adresu i hasła dostępu do już istniejącego (zainstalowanego i skonfigurowanego) klienta, np.

#
# Client (File Services)
#
#  (c) 2011 by Inteos Sp. z o.o.
#

Client {
  Name = "apps-fd"
  Address = 192.168.0.10
  FDPort = 9102
  Catalog = "Catalog"
  Password = "password"
  File Retention = 1 year
  Job Retention = 1 year
  AutoPrune = yes
  Maximum Concurrent Jobs = 2
}

W powyższym przypadku "oryginalny" klient związany jest z serwerem fizycznym, dla którego zdefiniowane są całkowicie inne parametry retencji czy poziomu równoległości (jak niżej).

#
# Client (File Services)
#
#  (c) 2011 by Inteos Sp. z o.o.
#

Client {
  Name = "bacula-fd"
  Address = 192.168.0.10
  FDPort = 9102
  Catalog = "Catalog"
  Password = "password"
  File Retention = 5 year
  Job Retention = 5 year
  AutoPrune = no
  Maximum Concurrent Jobs = 20
}

Teraz, jak tylko administrator będzie chciał dokonać migracji aplikacji z powyższego serwera na całkowicie inny to wystarczy, że zmieni adres/port usługi oraz hasło dostępu, a całość backupów będzie działała tak samo jak dotychczas, w szczególności zachowana będzie dotychczasowa historia.

¹ Często jest pojęciem względnym....