Welche Daten werden gesichert und in welcher Form passiert das?

Nutzdaten

Unter Nutzdaten verstehen wir die tatsächlichen Anwendungsdaten. Bei einer typischen Atlassian-Anwendung sind das beispielsweise die folgenden:

• Datenbank (PostgreSQL oder MySQL)
• Seitenanhänge in Confluence
• Ticketanhänge in Jira
• Repositories in Bitbucket

Wir betreiben ein "zweistufiges" Backup-Konzept. Einerseits gibt es Backups im Kundensystem direkt:

• Kundensysteme verwenden ZFS als Dateisystem. Hier werden stündlich Snapshots der Anwendungsdaten und der Datenbank auf Blockebene erzeugt.
• Standardmäßig werden diese Snapshots für die folgenden Zeiträume aufbewahrt:
  • 24-stündige Snapshots
  • 7-tägige Snapshots
  • 2-wöchige Snapshots
  • 1-monatige Snapshot
• Lokale Snapshots dieser Art helfen nicht bei einem Totalausfall des Systems, schützen aber gegen kurzfristige Korruption der Daten, die zum Beispiel durch menschliches Versagen entstehen könnte.

Darüberhinaus werden die Nutzdaten auch auf Backup-Server an einem anderen Standort (Anbieter Hetzner in Deutschland) gesichert:

• Es gibt ein tägliches Backup.
• Die Daten werden mittels rsync vom Kundensystem auf den Backup-Server kopiert.
• Gesichert werden hier die Anwendungsdaten und die Datenbank (Binärformat, kein Dump).
• Als Datenquelle dient ein lokaler ZFS-Snapshot des Kundensystems, sodass ein konsistentes Backup erzeugt wird (Datenbank und komplette Nutzdaten entsprechen alle exakt demselben Zeitpunkt). Zur Erzeugung dieses Snapshots wird die Datenbank vorübergehend heruntergefahren.
• Standardmäßig werden diese Backups für folgende Zeiträume aufbewahrt:
  • 7-tägige Backups
  • 4-wöchige Backups
  • 3-monatige Backups
• Bei einem Totalausfall des Systems können diese Backups wieder eingespielt werden.
• Die räumliche Trennung (Kundensysteme und Backup-Systeme laufen nicht im selben Rechenzentrum) sorgt für eine weitere Reduzierung von Risiken (zum Beispiel bei Naturkatastrophen), wobei jedoch weiterhin europäische Datenschutzrichtlinien befolgt werden.

Konfiguration der Kundensysteme

Die Konfigurationsdaten der Kundensysteme – also beispielsweise Einstellungen des Web-Servers – werden nicht von klassischen Backups erfasst. Stattdessen sind sie vom globalen Konfigurationsmanagement-System von //SEIBERT/MEDIA abgedeckt. Diese Daten liegen daher in einem Git-Repository, das in unserer eigenen Bitbucket-Instanz gespeichert ist. Sensible Zugangsdaten sind dort verschlüsselt und nur einem beschränkten Personenkreis zugänglich. Bitbucket selbst unterliegt wiederum denselben Sicherungsmechanismen wie den oben beschriebenen.

Backup-Server

Verschlüsselung

• Alle Daten werden verschlüsselt vom Kundensystem zum Backup-Server übertragen (SSH) und dort verschlüsselt abgelegt.
• Die Verschlüsselung erfolgt mittels LUKS auf dem Backup-Server.
• Der Key für die Verschlüsselung wird nie auf dem Backup-Server abgelegt, sondern nach einem Reboot durch die Administratoren manuell eingegeben.

Redundanz

• Die Backup-Server verfügen in der Regel über drei Festplatten.
• Es wird ZFS als Dateisystem mit RAIDZ (vergleichbar mit RAID5) verwendet. Fällt eine Festplatte aus, so kann diese ohne Datenverlust getauscht werden.

Trennung zwischen Kunden

• Die Backup-Spaces verschiedener Kunden sind auf Dateisystemebene voneinander getrennt.
• Backup-Clients haben außerdem strikt reglementierte Systemrechte, um Zugriffe auf fremde Backups zu verhindern.

Round-Robin-Backups an zwei verschiedene (oder mehr) Backup-Server

Unser Backup-System unterstützt mehrere Backup-Server als Targets, dieser Modus wird standardmäßig verwendet. Es wird das heutige Backup auf Server $A abgelegt, das morgige dann auf Server $B; anschließend geht es wieder bei Server $A weiter. Durch diese Streuung wird die Ausfallsicherheit weiter erhöht.

Sonderkonfigurationen

Anpassungen

Sowohl die lokalen ZFS-Snapshots als auch die regulären Backups sind konfigurierbar im Hinblick auf die Aufbewahrungszeiträume

View this page in English