Backup und Wiederherstellung sind bei Dateien und binären Objekten wie Programmierbibliotheken relativ einfach. Sie kopieren das Objekt einfach in ein separates Speicher-Array, das sich normalerweise an einem anderen Ort befindet. Wenn Sie es wiederherstellen müssen, kopieren Sie es zurück. Bei Datenbanken gestaltet sich das Ganze weniger einfach. Bei einem Datenbank-Backup werden neben den Daten selbst auch komplexe, untereinander abhängige Systemelemente repliziert.
Wir haben schon so oft gehört, wie wichtig Daten für Unternehmen sind, dass wir vielleicht vergessen, dass all diese Daten an einem bestimmten Ort existieren müssen. Und obwohl nicht-relationale Datenbanken, Data Lakes und dergleichen in der Unternehmens-IT immer häufiger zum Einsatz kommen, sind heute noch immer die meisten regulären Unternehmensdaten in Standard-RDBMSs (Relational Database Management Systems) gespeichert. Dabei handelt es sich um Microsoft SQL Server, IBM DB2, Oracle und MongoDB.
Die Erstellung zuverlässiger Datenbank-Backups für diese RDBMSs ist für ein Unternehmen aus einer Vielzahl von Gründen absolut entscheidend. Zum einen werden die meisten Geschäftsvorgänge in einem RDBMS aufgezeichnet. Die Finanzdaten eines Unternehmens sowie Kundendaten und andere geschützte Geschäftsinformationen befinden sich unweigerlich in den Zeilen und Spalten eines RDBMS. Mit dem Verlust dieser Daten würde ein Unternehmen seine Finanzgeschichte verlieren. Buchhaltung und Finanzberichterstattung wären unmöglich. Jegliche Art von Datenanalyse, die heute als unverzichtbar für das Management gilt, wäre undenkbar.
Ein Unternehmen verliert auch seine Fähigkeit, kontinuierlich weiterzuarbeiten, wenn es nicht in der Lage ist, eine Datenbank in einem funktionsfähigen Zustand wiederherzustellen. Das liegt daran, dass Datenbanken in der Regel mit einem Transaktionssystem verbunden sind, z. B. mit einem System zur Verwaltung von Kundenaufträgen oder einer ERP-Lösung. Wenn die Datenbank nicht verfügbar ist, fällt auch das Transaktionssystem aus.
Ein Datenbank-Backup ist in der Regel eine Herausforderung, da es sich um einen dualen Prozess handelt. Beim Backup-Prozess müssen nicht nur die Daten, sondern auch die verschiedenen Konfigurationen, Einstellungen und anderen Metadaten gesichert werden, die innerhalb der Anwendung vorhanden, aber von der eigentlichen Datenbank getrennt sind. Das gesamte System muss sicher auf eine separate Infrastruktur kopiert werden. Dann besteht noch die Frage des Hosting-Standorts. Datenbanken können heute, vor allem in größeren Unternehmen, auf mehrere lokale Server sowie auf Cloud-basierte Instanzen verteilt sein.
Datenbanken sind außerdem immer mit mindestens einem anderen System integriert. Wenn Sie Cassandra oder No SQL nutzen, handelt es sich nicht um eigenständige Anwendungen. Sie laufen auf Servern wie Linux oder Windows Server. Die Konfiguration des zugrunde liegenden Servers ist für das ordnungsgemäße Funktionieren der Datenbank ausschlaggebend. Auch er muss vollständig und ordnungsgemäß gesichert werden. Andernfalls ist es nicht möglich, die Datenbank wiederherzustellen. Das RDBMS ist in der Regel auch mit einem operativen Geschäftssystem, beispielsweise ERP, verbunden. Bei der Sicherung der Datenbank müssen auch die Konfigurationen dieser Verbindung gesichert werden, da auch sie sonst bei der Wiederherstellung nicht wie erforderlich funktioniert.
Gleichzeitig sind die Backup-Zeitfenster klein und werden in der Regel immer kleiner. Je nach Unternehmen können Datenbank-Backups stündlich oder sogar alle paar Minuten erfolgen. In bestimmten Unternehmen, z. B. in Finanzdienstleistungsunternehmen, können RTO und RPO in Sekunden gemessen werden.
Best Practices für Datenbank-Backups umfassen die 3-2-1-Backup-Regel, bei der Sie drei Kopien Ihrer Daten unter Verwendung von zwei Speichermodi aufbewahren, von denen sich eine an einem externen Ort befindet. Die Best Practices gehen aber weit über diese Backup-Regel hinaus. Benutzerfreundlichkeit, regelmäßige Tests, guter Support durch den Anbieter usw. sind ebenfalls erforderlich. Um jedoch das Ziel eines zuverlässigen Datenbank-Backups zu erreichen – d. h. ein Backup des gesamten Systems und seiner Daten, damit es in jedem Fall funktioniert –, bedarf es einer weitaus umfassenderen Reihe von Best Practices. Insbesondere sollten Sie:
einen detaillierten Plan der Datenbank, einschließlich der Standorte und der Verbindungen zu anderen Systemen, erstellen und pflegen. Auf jede Änderung am Plan muss eine Änderung des Backup-Verfahrens folgen.
ein Inventar der Konfigurationen und Anpassungen erstellen und pflegen, die sich auf die Funktionsfähigkeit einer wiederhergestellten Version der Datenbank auswirken. Selbst die kleinste Fehlkonfiguration kann eine wiederhergestellte Datenbank unbrauchbar machen, zumindest bis das Problem erkannt wird.
Rubrik ermöglicht Datenbank-Backups mit nativen Konnektoren für alle branchenführenden RDBMSs. Wir vereinfachen den Datenbankschutz, indem wir die mühsame Skripterstellung und Jobplanung überflüssig machen. Datenbank-Backup-Administratoren können einfach die zu schützenden Datenbanken oder sogar Datenbankserver angeben. Rubrik passt sich durch seine robuste SLA-Policy-Engine automatisch an alle Topologie-Änderungen an. Sie können außerdem die komplexe Datenbank-Backup-Workload über eine einzige Oberfläche verwalten und so die Verwaltung von physischen, virtuellen und Cloud-Workloads dank einer einzigen UI-gesteuerten Oberfläche vereinfachen.
Erfahren Sie mehr darüber, wie Rubrik Ihnen helfen kann, Ihre Datenbanken mit Datenbank-Backup-Lösungen zu schützen.