Nicht erst die stetigen Ransomware-Angriffe verdeutlichen den enormen Stellenwert von Backups im Unternehmen: Ein falscher Klick genügt und schon steht die ... (mehr)

Gut aufgehoben

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>
}

Langzeitarchivierung

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.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2020