Vor allem in produktiven Umgebungen kommt der Administrator nicht mehr ohne eine valide Backupstrategie aus. In Zeiten, in denen viele Firmen ohne digitale Dienste schlicht nicht überleben können, kann der Verlust wichtiger Daten dem Unternehmen schnell den Garaus machen.

Sonderlich gerne befassen sich Admins mit der Thematik allerdings bis heute nicht. Das macht sich vorrangig durch Backupkonzepte bemerkbar, die zwar auch heute vielerorts noch in Nutzung sind, jedoch eher den technischen Stand von vor zehn Jahren repräsentieren. Das ist schade: Im Jahre 2021 ist es nämlich längst nicht mehr nötig, komplette Systeme als wiederherstellbares Backup auf ein Bandlaufwerk zu schreiben, um vor Ausfällen geschützt zu sein. Richtig eingesetzt greift Automatisierung dem Admin an vielen Stellen unter die Arme, wo früher noch eine typische Backupsoftware zum Einsatz gekommen wäre.

Was damit gemeint ist, zeigt das Beispiel einer Datenbank deutlich. Fast jedes Setup der modernen IT beinhaltet eine Datenbank. Oft ist das MySQL oder dessen Konkurrent MariaDB. Und weil Daten das Blut in den Adern moderner Anwendungen sind, bilden Datenbanken stets einen neuralgischen Punkt in der Infrastruktur. Gehen Daten verloren, hat das meist katastrophale Auswirkungen. Bei einem Backup geht es allerdings selten um das komplette Datenbanksystem: Meistens zählt nur der Inhalt selbst. Oftmals sind das nur wenige GByte. Dementgegen steht die Backuprealität in vielen Unternehmen: Für Datenbanksysteme werden in vielen Fällen Vollbackups erstellt. Das System lässt sich aus solchen zwar komplett wiederherstellen, doch fressen sie viel Platz auf den Sicherungsmedien. Und das ist nicht der einzige technische Nachteil.

Ist ein Rollback auf einen früheren Datenstand nötig, würde es viel zu lange dauern, die Datenbank selbst aus dem Vollbackup zu extrahieren. Zu allem Überfluss sichern Unternehmen heute deshalb häufig zusätzlich zum ganzen Datenbanksystem auch noch die Inhalte der Datenbank separat. Was umso schlimmer ist eingedenk der Tatsache, dass sich praktisch der gesamte Datenbankserver – mit Ausnahme der tatsächlichen Nutzdaten – ohnehin autom­atisiert wiederherstellen lässt. Denn praktisch ist ein Datenbankserver heute ja nicht viel mehr als eine Linux-Installation mit Datenbankpaketen.

Das beschriebene Beispiel legt den Wahnsinn vieler Backupstrategien offen. Unternehmen sichern wie wild ganze Systeme, obwohl sie diese in der Praxis nur sehr selten wiederherstellen müssen. Die eigentlich regelmäßig benötigten Backups kommen separat hinzu. In Summe verstopft der Sammelwahn die Backup-Medien und vergeudet so unnötig Platz. Die Lösung für das Problem liegt indes auf der Hand: Wer seine Automatisierung im Griff hat, kann sich das Sichern ganzer Systeme sparen – und gewinnt sogar beim Recovery der Datenbankdaten selbst viel Zeit. Die folgenden Schritte zeigen, wie eine sinnvolle Backup-Stragie auf Basis von Automation aussehen kann.

Wer sich schon mal mit den Themen Automation und Backups beschäftigt hat, dem ist vielleicht auch der Begriff "Immutable Environment" begegnet. Die Idee dahinter ist, Backups und Automatisierung so zu kombinieren, dass sich jedweder Workload schnell und ohne viel Bastelei sichern und wiederherstellen lässt. Der Weg zu einem funktionalen Immutable-Environment-Design führt stets über eine Bestandsaufnahme im ersten Schritt. Das heißt konkret: Bevor Sie automatisieren und Backups zusammenstreichen, erfassen Sie die Stellen, an denen Automation sinnvoll ist, und jene, wo Nutzdaten lokal zu sichern sind.

Die zu automatisierenden Systeme unterscheiden sich dabei je nach Umgebung erheblich. Haben Sie das Glück, eine eher homogene Serverumgebung zu betreuen, ist diese Aufgabe nicht sehr komplex. Sehen Sie sich einer heterogenen Umgebung aus Clients und Servern gegenüber, wird das Gespann aus Automatisierung und Backups jedenfalls komplexer in der Implementation – aber nicht unmöglich. Wir beziehen uns in diesem Beitrag bevorzugt auf Linux-Server. Am Ende folgt ein kurzer Exkurs für Clientsysteme, der auch das Thema Windows einschließt.

Ganz gleich, ob Workloads im produktiven Einsatz in Container verpackt sind oder direkt auf dem Blech laufen: Eine basale Linux-Distribution ist stets eine Grundvoraussetzung für die Nutzung eines Servers. Das gilt auch für virtuelle Instanzen, die ebenfalls Linux als Grundgerüst benötigen. Setzt eine Umgebung verstärkt auf Container, ist das Grundsystem vermutlich schlank, weil eine Container-Distribution zum Einsatz kommt. Und selbst wenn Sie hier auf Systeme wie Red Hat Enterprise Linux oder SUSE Linux Enterprise Server setzen, wird ein nur für den Betrieb von Containern vorbereiteter Host kein umfassend großes System werden.

Gerade weil ein funktionierendes Grundsystem die oberste Prämisse für die Nutzung jedes Servers ist, liegt bei der Automation-Strategie ein Hauptaugenmerk auf dem Prozess, der aus einem normalen Server von der Stange ein System der eigenen Umgebung macht. Folgerichtig ist der erste Schritt, die automatische Installation von Linux zu ermöglichen.

Was viele IT-Verantwortliche leider aus den Augen verlieren, ist, dass auch die Konfiguration der jeweiligen Systeme einen wichtigen Faktor darstellt. Ein installiertes, sehr basales RHEL oder SLES bietet Vorteile, ist aber ohne Anpassung an die Voraussetzungen vor Ort eher nutzlos. Klar: Über die automatische Installation per Kickstart, AutoYaST oder Preseeding lassen sich viele Parameter des Systems bestimmen. Ein Ersatz für echte Automatisierer wie Ansible ist das aber nicht.

Mancher Admin bearbeitet seine Systeme etwa noch während des Deployment-Vorgangs mit Skripten, die der jeweilige Installer während oder unmittelbar nach der Installation ausführt. Doch diese Mechanismen sind eigentlich nicht für die umfassende Systemkonfiguration gedacht, und mit einem echten Automatisierer wären die meisten Admis viel besser bedient. Denn nur so entsteht ein durchgehendes Lifecycle-Management: Im ersten Schritt installiert der Admin den Server per Netzwerkinstallation neu. Dann folgt die basale Konfiguration per Automatisierer. Abschließend wird der Datensatz der tatsächlichen Nutzdaten eingespielt.

Wer seine Systeme automatisiert unter Kontrolle hat, muss im letzten Arbeitsschritt Datensätze für spezifische Zielprogramme aus dem Backup zurückspielen. Diese Aufgabe ist kaum sinnvoll automatisierbar – es liegt auch in der Natur der Sache, dass das Einspielen von Backups üblicherweise eine Aufgabe ist, die der Admin sorgfältig von Hand durchführen will. Umso wichtiger ist es, die automatisierbaren Schritte der Arbeit tatsächlich zu automatisieren. Ihr Weg dorthin ist steinig oder leicht, je nach vorhandenem Setup.

Viele Admins haben das Thema Automatisierung auf die lange Bank geschoben. Das betrifft vielerorts vor allem die Ebene des Betriebssystems. Dabei beginnt hier die Erfolgsgeschichte der Automation einer Umgebung. Denn es ergibt auch in kleineren Setups aus Sicht des Admins kaum Sinn, sich mit der Installation eines Betriebssystems regelmäßig herumzuschlagen. Zumal diese Aufgabe wirklich mittlerweile gut automatisierbar ist. Die Protokolle für alle Teile des Setups – PXE, DHCP, TFTP & Co. – stehen seit Jahrzehnten bereit und funktionieren hervorragend.

Aus heutiger Sicht sieht das Soll-Szenario ungefähr so aus: Bekommt der Admin einen Server geliefert, packt er diesen aus, montiert den Server im Rack und verkabelt ihn passend. Idealerweise ist der Server ab Werk darauf konfiguriert, per PXE einen Netzwerkstart durchzuführen. Die meisten Anbieter konfigurieren ihre Systeme entweder gleich so vor oder bieten zumindest die Möglichkeit, den gewünschten Startmodus bei der Bestellung anzugeben. Per Netz startet der Server dann in ein Inventarisierungssystem, wo die vor Ort eingesetzte Lifecycle-Management-Software erstmals Notiz von ihm nimmt.

Danach weist der Admin dem System eine Rolle zu, aus der sich im Idealfall die Konfiguration des Servers automatisch ergibt. Der Rest ist dann reine Lappalie: Der Server bootet in den Installationsmechanismus für das Betriebssystem, bekommt dabei auch gleich seine Netzwerkkonfiguration und wird danach per Automatisierer auf den richtigen Stand gebracht. Wenn alle Räder dieses Mechanismus richtig ineinandergegriffen haben, läuft auf dem Zielsystem jetzt auch schon die benötigte Software – etwa MariaDB, falls es sich um einen Datenbankserver handelt.

Ihr primäres Ziel haben Sie als Administrator damit bereits erreicht – Sie sind in der Lage, in kürzester Zeit eine neue Datenbankinstanz aufs Blech oder virtuell aus dem Ärmel zu zaubern. Davon profitieren Sie, wenn Sie die bestehenden Datenbanken der Installation erweitern möchten, aber eben auch, wenn ein ausgefallenes System durch ein neues zu ersetzen ist. Das Backup des gesamten Datenbanksystems können Sie an dieser Stelle daher schon abschalten. Denn mit dem beschriebenen Automatismus stellen Sie ein System her, das einem zerstörten Vorgänger gleicht wie ein Ei dem anderen.

In aller Regel ist der Vorgang der automatisierten Neuinstallation zudem viel schneller als die komplette Wiederherstellung aus dem Backup. Denn das Lifecycle-Management, das auch Details zur Konfiguration der Systeme enthält, läuft im Normalfall permanent – es genügt für einen Server also, in die PXE-basierte Netzwerkinstallation zu booten, um sie zu verwenden.

Welches der auf dem Markt angebotenen Lifecycle-Management-Systeme sich für Ihr spezifisches Setup am besten eignet, hängt von verschiedenen Faktoren ab. Zwei Ansätze stehen sich diametral entgegen: Die eine Option besteht darin, die Werkzeuge des Herstellers zu verwenden, der auch ansonsten das Setup dominiert. Das funktioniert in homogenen Umgebungen sehr gut. Wer etwa ausschließlich auf Red Hat Enterprise Linux oder CentOS setzt, wird mit Red Hat Satellite [1] zufrieden sein. Wer ein typischer Ubuntu-Shop ist, kommt mit Landscape [2] (Bild 1) oder MAAS [3] gut zurecht, weil Ubuntu ideal an diese angepasst ist. Und für SUSE-Enthusiasten steht der SUSE Manager [4] zur Verfügung.

Haben Sie es mit einer heterogenen Umgebung zu tun, zahlt es sich vielleicht aus, das Lifecycle-System selbst zu bauen und nicht auf ein fertiges Produkt eines Anbieters zu setzen. Keine Sorge, auch dabei müssten Sie nicht bei Null anfangen: Foreman [5] etwa gilt als äußerst erprobtes, versatiles System für das Lifecycle-Management. Zusätzlich haben viele Automatisierer mittlerweile auch Lifecycle- Manager im Gepäck. Erheben Sie wie beschrieben im ersten Schritt Ihren Workload und lassen Sie sich in der weiteren Folge am besten die Angebote der verschiedenen Anbieter genau vorstellen – bedenken Sie dabei allerdings, dass das Lifecycle-Management Sie im Normalfall eine ganze Weile begleiten wird. Es schadet deshalb nicht, sich hier am Anfang eher kompromisslos zu geben.

Bis hierhin haben wir uns vorrangig mit der Notwendigkeit beschäftigt, Betriebssysteme nicht aus dem Backup zu ziehen, sondern automatisiert wiederherzustellen. Automation und Orchestrierung greifen dem Admin allerdings auch beim Restore von Datenbanken und anderen Diensten unter die Arme. Beispielsweise wenn es um die Rettung von Daten geht, die ein Nutzer versehentlich gelöscht hat oder die anderweitig korrumpiert wurden. Mit dem richtigen Konzept und der passenden Backupsoftware lässt sich nämlich auch der Wiederherstellungsprozess durch Automation und richtiges Anwendungsdesign deutlich schneller gestalten als in konventionellen Umgebungen.

Gegeben sei also erneut ein Server mit einer MariaDB-Datenbank. Ob das System auf Blech läuft oder virtualisiert, ist zunächst zweitrangig. Wichtig ist aber, dass der Admin ein sinnvolles Konzept für Backups des Datensatzes seiner Datenbank hat. Hier ergeben sich regelmäßig zwei Optionen: Die Sicherung des Datenträgers, auf dem die Datenbank beheimatet ist, oder das Erstellen eines Backups über die Datenbank selbst.

Beide Ansätze haben Vor- und Nachteile, mit denen der Administrator vertraut sein sollte. Und beide Methoden stehen nicht in jedem Szenario zur Verfügung. Backups über die Datenbank selbst bieten den Vorteil, mit hoher Wahrscheinlichkeit keine korrupten Backupdateien zu produzieren, weil die Datenbank aktiv am Prozess beteiligt ist – sie weiß also, dass sie gerade gesichert wird. Und das ist wichtig: Laufende Transaktionen kann die Datenbank beenden und das Starten neuer Transaktionen verzögern. Der Nachteil: Damit das funktioniert, muss die Datenbank selbst laufen. Stürzt der Datenbankprozess reproduzierbar ab, wird es auf diesem Weg nicht mehr möglich sein, an Backups zu kommen oder einen Restore durchzuführen.

Die Sicherung des Datenträgers mit den Datenbankdaten hat hingegen den Nachteil, dass ein solcher Prozess stets dafür sorgen muss, dass ein Write in die Datenbank nicht genau im Moment des Snapshot stattfindet. Ansonsten ist der Snapshot potenziell korrupt und dadurch natürlich unbrauchbar. Agenten, die die Datenbank während des Ziehens des Snapshot kurz anhalten, sollen bei vielen Backuplösungen dieses Problem umgehen (Bild 2).

Wie bereits erwähnt, gibt es für das Sichern von Workloads verschiedene Optionen. Welche Software und welchen Weg Sie für Ihr eigenes Setup nutzen, hängt stark von den jeweiligen Begebenheiten ab. Am Markt existieren durchaus potente Programme und All-in-one-Lösungen für das Sichern von Datenbanken wie MariaDB oder PostgreSQL.

Andererseits findet sich im Werkzeugkasten der Open-Source-Gemeinde für nahezu jede Anwendung auch Software, die spezifisch auf den Einsatzzweck hin optimiert ist. Von einer Empfehlung sehen wir an dieser Stelle daher ab – wir gehen jedoch im weiteren Verlauf davon aus, dass Sie eine intakte Sicherung der Daten besitzen, die Sie für den Restore-Prozess benötigen.

In einem Szenario, in dem Sie die Datenbank zurücksetzen müssen, ist ein entscheidendes Kriterium der Arbeitsaufwand und die Downtime der Umgebung. Denn der Rollback soll in aller Regel so schnell wie möglich geschehen. Wohl dem Admin, der seine Automation im Griff hat: In kürzester Zeit installiert dieser nämlich komplett automatisch eine zweite, parallel zur ersten Datenbank laufende Instanz. In diese spielt er anschließend den letzten funktionierenden Datensatz ein und schwenkt dann die IP-Adresse von der Instanz mit der alten Datenbank auf die Instanz mit der neuen – und fertig ist die Laube.

In virtualisierten Umgebungen spielt dieser Ansatz seine Vorteile freilich deutlicher aus als auf echtem Blech. Denn hier lässt sich sogar ad hoc ein neues Volume mit den Inhalten des Snapshot anlegen, das der Admin der neuen Datenbankinstanz von Anfang an mit auf den Weg gibt – oder im Rahmen einer kurzen Downtime der alten Datenbankinstanz unterjubelt. Aber auch auf physischen Servern ist der gesamte Vorgang mit deutlicher Zeitersparnis verbunden.

Der Beitrag befasst sich in erster Linie mit Linux-Servern im RZ – doch weiß jeder Administrator, dass die Wiederherstellung eines Windows-Systems aus einem Backup ebenfalls ein lästiger Vorgang ist. Die Idee, herkömmliche Backups durch Automation zu ersetzen, greift indes auch bei klassischen Clients nicht vollständig ins Leere. Hier kommt es freilich darauf an, wie das jeweilige System verwaltet wird.

Gerade in Firmenumgebungen finden sich Netzwerklaufwerke als Speicherort für Nutzerdaten. Diese sind mit dem Benutzer zusammen mobil. Meldet sich also der User an einem anderen Gerät als üblich an, findet er dort wie gewohnt sein Netzlaufwerk und seine Daten vor. Für den Client selbst heißt das, dass er austauschbar ist – und genau hier liegt das mögliche Fundament für eine umfassende Automationsstrategie.

Desktopbetriebssysteme wie Windows oder Linux lassen sich nämlich ebenso gut in ein Lifecycle-Management einbinden wie die Geräte aus dem Serverraum. Lediglich macOS ist hier eine Ausnahme, denn eine "unattended" Installation bietet Apple nicht an. Andere Anbieter einschlägiger Hardware stellen hier gar eigene Tools zur Verfügung, die aber freilich nur den Bestand der eigenen Marke abdecken.

Wer eine heterogene Clientlandschaft etwa aus HP-, Dell- und Microsoft-Geräten hat, wird mit diesen spezifischen Lösungen also nicht glücklich. Auch ohne kann es aber funktionieren. Windows etwa bietet das Preinstallation Environment (PE), aus dem heraus Windows sich automatisiert installieren lässt. Und der Start des WinPE aus einer PXE-Umgebung heraus ist seitens Microsoft ausdrücklich unterstützt. Ferner gibt es auch für Windows natürlich Automatisierer – zum Teil funktionieren gar die, die Admins schon von Linux her kennen. Wer also einmal die Zeit investiert, Lifecycle-Management für Windows-Clients zu bauen, automatisiert deren Installation bei Bedarf ebenso und schafft in Kombination mit Netzwerklaufwerken eine Art Immutable Environment, wie es auch im Serverraum möglich ist. Gerade für IT-Abteilungen, die regelmäßig große Mengen an Systemen neu ausrollen, kann das eine erhebliche Zeitersparnis sein.

Wer schlau automatisiert, verkürzt vor allem die Wiederanlaufzeit nach Ausfällen oder dem versehentlichen Löschen von Daten dramatisch. So ungern sich mancher Admin auch mit dem Backupthema befassen mag: Vollbackups kompletter Systeme sind im Jahr 2021 weder ökonomisch sinnvoll noch in irgendeiner Art und Weise State of the Art. Es ist schlicht nicht sinnvoll, sich seine Tapes mit Inhalten zuzukleistern, die bei Bedarf jederzeit wieder aus dem Internet zu beziehen sind.

Damit Automation und Restore Hand in Hand gehen, hat der IT-Verantwortliche allerdings ein paar Hausaufgaben zu erledigen. Doch keine Sorge: Diese lohnen sich nicht nur im Backupkontext, sondern erlauben dem Admin gleichzeitig sinnvolles Lifecycle-Management seiner Instanzen.