Kommen wir zu den Speicherorten: Bareos unterscheidet zwischen Pools, Vol-umes und Labels. Ein Volume ist ein einzelnes physisches Band oder eine Datei, in die Bareos das Backup schreibt. Pools fassen mehrere Volumes zusammen, sodass eine Sicherung nicht auf die Länge eines einzelnen Volume (Bandes) beschränkt ist. In den Backupjobs sind also Pools definiert, und Bareos entscheidet dann selbstständig, welches Volume zum Einsatz kommt. Jedes Volume hat ein eindeutiges Label.
Für das Backup-Schema Always Incremental sind mindestens zwei Speicherorte erforderlich, besser drei, wenn Sie zusätzlich die Langzeitarchivierung einrichten. Im ersten Pool "ai-inc" definieren Sie unter anderem eine Aufbewahrungszeit, eine Maximalgröße, das automatische Recyclen und setzen ein Label (Listing 3). Beachten Sie die Direktive "Next Pool", die in diesem Fall den Pool für die Konsolidierung "ai-consolidated" angibt.
Listing 3: Erweitertes Backupschema
Pool { Name = ai-inc-<hostgroup> Pool Type = Backup Recycle = yes Auto Prune = yes Volume Retention = 90 days File Retention = 90 days Job Retention = 90 days Volume Use Duration = 23h Maximum Volume Bytes = 8G Label Format = ai-inc-<hostgroup> Storage = File Next Pool = ai-consolidated-<hostgroup> }
Dem Konzept Always Incremental fehlt in der Voreinstellung eine Möglichkeit, Daten für einen längeren Zeitraum zu sichern. Das maximale Alter der gespeicherten Backups definiert die Jobdirektive "Always Incremental Job Retention", die in der Konfigurationsdatei des dazugehörigen Jobs hinterlegt ist. Wer Sicherungen über einen längeren Zeitraum speichern möchte, kann dies in Bareos über zwei Wege erreichen: Copy Jobs oder Virtual Full Jobs.
Listing 4 zeigt drei Einrichtungsdateien für einen Copy Job, der ausgewählte Jobs aus dem Pool "ai-consolidated" in einen Langzeitpool "ai-longterm" kopiert. Beachten Sie, dass viele Jobeigenschaften, darunter der Name, der Typ, der Client und der Zeitplan, in der Datei "copy-to-longterm-jobdef.conf" im Verzeichnis "/etc/bareos/bareos-dir.d/jobdefs" definiert sind. Die JobDefs-Files können gleiche Jobkonfigurationen gruppieren, was in Umgebungen mit vielen Clients äußerst praktisch ist.
Listing 4: Einrichtungsdateien für Copy-Job
Job { Name = copy-to-longterm JobDefs = copy-to-longterm-jobdef Pool = ai-consolidated Messages = Standard Priority = 40 Selection Type = SQL Query Selection Pattern = "SELECT DISTINCT Job.JobId,Job.StartTime FROM Job,Pool WHERE Pool.Name = 'ai-consolidated' AND Pool.PoolId = Job.PoolId AND Job.Type = 'B' AND Job.JobStatus IN ('T','W') AND Job.Level = 'F' AND Job.jobBytes > 0 AND Job.JobId NOT IN (SELECT PriorJobId FROM Job WHERE Type IN ('B','C') AND Job.JobStatus IN ('T','W') AND PriorJobId != 0) ORDER by Job.StartTime;" } JobDefs { Name = copy-to-longterm-jobdef Type = Copy Level = Full Client = <clientname>.example.com Schedule = schedule-copy-to-longterm Maximum Concurrent Jobs = 2 } Schedule { Name = schedule-copy-to-longterm Run = 1st sun at 01:00 }
Interessant ist weiterhin das SQL-SELECT-Statement in der Konfigurationsdatei, das durch die Direktive "Selection Type = SQL Query" eingeleitet wird. Hinter "Selection Pattern" steht die eigentliche SQL-Abfrage, die aus dem Bareos-Katalog bestimmte Jobs herausfiltert. So werden aus dem Pool "ai-consolidated" nur Jobs vom Typ "Backup" und mit dem Level "Full" in den Longterm-Pool kopiert, die erfolgreich oder mit Warnungen gelaufen sind. Zusätzlich wird mithilfe von "jobBytes" geprüft, ob der zu kopierende Job überhaupt Daten enthält, da eine Kopie sonst überflüssig wäre. Die Unterabfrage, also das Subquery, ermittelt eine Liste bereits kopierter Jobs, die dann ausgeschlossen werden. Der Zeitplan sieht vor, dass der Copy Job immer am ersten Sonntag des Monats um 1 Uhr morgens läuft.
Die Alternative, ein sogenannter Virtual Full Job, erstellt eine virtuelle Vollsicherung und führt alle vorhandenen Backups zu einem neuen zusammen. Die bereits erwähnte Dokumentation zu Always Incremental [2] zeigt ein Beispiel für eine Konfigurationsdatei.