Allgemein

Datensicherung – Stand der Dinge – Teil 1

Das gute alte Thema Datensicherung. Auch da hat sich viel verändert in den letzten vier Jahren. Angefangen haben wir 2004 mit einem sehr einfachen Setup:
1 BASH Script, GnuPG und ein FTP Server
Lief auch einige Zeit wunderbar. Ist aber schlecht zu monitoren und zentral zu überwachen. Restore ist natürlich auch alles andere als schön. Im Laufe der Zeit haben wir dann BackupPC genutzt, war nett, zentral zu verwalten, aber wir hatten dann am Ende Performance Probleme bei Millionen von Dateien (ist Uralt, gibts nen alten Post hier zur Umstellung auf Bacula).
Bacula wurde dann irgendwann nur noch im Enterprise Bereich zuverlässig weiterentwickelt, was folgte war eine Migration auf den Fork Bareos.

Bareos
Bareos nutzten wir dann viele viele Jahre, das altertümliche Vorgehen von regelmäßigen Full, gefolgt von täglichen Inkrementellen Backups kam irgendwann an seine Grenzen, ein Fullbackup dauerte bei einigen Servern mit Millionen von Dateien einfach zu lange. Aber, Bareos konnte ja mittlerweile “Always Incremental” dieses Feature kannten wir schon von unserer Enterprise Software und dort ist es ein Traum. Leider ist die Konfiguration von Always Incremental in Bareos ein Alptraum, ja, es lief, aber viel Handarbeit und viel Gebastel. Mittlerweile fuhren wir eh Zweigleisig. Alle Linux Systeme sicherten wir mit Bareos, alle Windows Systeme mit Carbonite, Grund dafür waren entsprechende Agents für Exchange, MSSQL, Oracle etc, Vorgänger von Carbonite war hier Commvault Simpana, aber das ist nun wirklich eine ganz alte Geschichte. Generell lief die Integration von Bareos ganz gut, ein eigens gebautes CheckMK Plugin transportierte die Daten mittels Piggyback in die Ansichten der jeweiligen Hosts (hier als Plugin in unserem Github Repo: https://github.com/qmexnetworks/check_mk/tree/master/bareos_jobs). Das schlechte funktionieren von Always Incremental bei Bareos brachte uns dazu die Strategie noch einmal zu überdenken, es wäre doch toll eine zentrale Software zu haben, da wir zu 90% Gentoo einsetzen welches von Carbonite nicht unterstützt wird, war das bisher immer das Ausschlusskriterium.

Carbonite
Früher i386, dann Seagate Evault, mittlerweile Carbonite Server Backup. Wir nutzen dies seit 2014 für unser Produkt der Online Datensicherung (heute würde man Cloud sagen). Wir sichern die Daten der Kunden aus deren Standorten via Carbonite zu uns. Die Daten werden bereits mit einem von Kunden zu definierenden Passwort AES256 verschlüsselt und sind somit für uns nicht lesbar. Des Weiteren werden die Daten auch noch an einen zweiten Standort repliziert. Als weitere Option hat jeder Kunde die Möglichkeit noch einen lokalen “Backup Cache” zu verwenden der natürlich ganz besonders den Restore bei langsamem Internet beschleunigt.

– Fortsetung folgt –