Startseite ›   Glossar  ›   Backup-Ziel

Was ist ein Backup-Ziel?

Ein Backup-Ziel ist das Speichersystem, das die von der Backup-Software erzeugten Daten aufnimmt und aufbewahrt. Anwendungen wie Veeam, Commvault oder Rubrik schreiben ihre Backup-Daten auf das Ziel und lesen sie bei einer Wiederherstellung wieder zurück. Kapazität, Leseleistung, Verfügbarkeit und Aufbewahrungskontrollen des Ziels bestimmen deshalb sowohl, wie viele Backup-Daten sich vorhalten lassen, als auch, wie schnell sie wiederhergestellt werden können.

Was macht ein Backup-Ziel eigentlich?

Ein Backup-Ziel steht auf der Speicherseite des Backup-Prozesses. Die Backup-Anwendung entscheidet, was geschützt wird, wann Jobs laufen und welche Wiederherstellungspunkte zur Verfügung stehen. Das Ziel ist dafür zuständig, die entstehenden Daten zu speichern und sie zurückzugeben, wenn eine Wiederherstellung angefordert wird.

Diese Unterscheidung wird im Ernstfall wichtig. Wenn ein Backup-Job innerhalb seines geplanten Fensters fertig wird, belegt das, dass das Ziel Daten in der erforderlichen Geschwindigkeit annimmt. Es belegt nicht, dass dasselbe System bei einer umfassenden Wiederherstellung große Datenmengen schnell genug zurückliefern kann.

Die Leseleistung kann sich je nach Speicherdesign deutlich von der Schreibleistung unterscheiden. Deduplizierung, Controller-Architektur, Netzwerkbandbreite, gleichzeitige Workloads und die Zahl der beteiligten Speicherknoten wirken sich alle auf den Wiederherstellungsdurchsatz aus.

Ein Backup-Ziel zu bewerten heißt deshalb, das Verhalten bei der Wiederherstellung genauso zu betrachten wie die Schreibleistung beim Backup.

Was sollten Sie bei einem Backup-Ziel bewerten?

Die Anforderungen unterscheiden sich je nach Umgebung, doch mehrere Eigenschaften wirken sich unmittelbar auf den Backup- und Wiederherstellungsbetrieb aus.

Wiederherstellungsdurchsatz

Der Wiederherstellungsdurchsatz misst, wie schnell geschützte Daten vom Backup-Ziel gelesen und an die Produktionssysteme zurückgegeben werden können.

Besonders wichtig wird das bei einer Wiederherstellung nach einem Ransomware-Vorfall oder einem größeren Infrastrukturausfall, wenn Dutzende oder Hunderte Workloads gleichzeitig zurückgeholt werden müssen. Ein Speichersystem, das im geplanten Backup-Betrieb ausreichend leistungsfähig ist, kann trotzdem zum Engpass der Wiederherstellung werden, wenn sein Lesepfad parallele Restores nicht trägt.

Tests sollten deshalb realistische Wiederherstellungsszenarien einschließen und sich nicht nur auf die Laufzeiten der Backup-Jobs stützen.

Gleichzeitige Zugriffe

Eine einzelne Wiederherstellung fordert ein modernes Speichersystem vergleichsweise wenig. Große Wiederherstellungsereignisse sind etwas anderes.

Mehrere Backup-Proxys oder Restore-Jobs können gleichzeitig Daten anfordern. Das Ziel braucht genügend Platten-, CPU- und Netzwerkressourcen, um diese Anfragen zu bedienen, ohne den Großteil der Last durch eine begrenzte Zahl von Controllern oder andere gemeinsam genutzte Komponenten zu leiten.

Wo diese Engpässe entstehen, hängt von der Architektur des Ziels ab.

Unveränderlichkeit und Durchsetzung der Aufbewahrung

Das Ziel kann außerdem unabhängig kontrollieren, ob aufbewahrte Backup-Daten verändert oder gelöscht werden können.

Bei S3 Object Lock etwa wird die Aufbewahrung vom Objektspeicher selbst durchgesetzt. Im Compliance-Modus lässt sich eine geschützte Objektversion vor Ablauf ihrer Aufbewahrungsfrist weder überschreiben noch löschen — auch nicht von einem Benutzer mit administrativen Speicher-Zugangsdaten.

Das unterscheidet sich von einer Aufbewahrungseinstellung, die nur in der Konfiguration der Backup-Anwendung existiert. Eine vom Speicher durchgesetzte Aufbewahrung bleibt mit dem geschützten Objekt verbunden, selbst wenn die Backup-Software kompromittiert wird.

Kapazitätswachstum

Backup-Repositorys sammeln Daten an, wenn Aufbewahrungsfristen länger werden, geschützte Datenbestände wachsen und weitere Workloads in die Backup-Umgebung aufgenommen werden.

Ein Ziel braucht deshalb einen praktikablen Weg, Kapazität zu ergänzen, ohne jedes Mal ein neues Repository anzulegen, wenn ein bestehendes System an seine Grenze stößt.

Auch das Wachstumsmodell wirkt sich auf die Leistung aus. Manche Systeme ergänzen im Wesentlichen nur Kapazität, während Scale-out-Designs zusätzlich Rechen- und Netzwerkressourcen mitbringen.

Verhalten im Fehlerfall

Backup-Ziele müssen auch danach beurteilt werden, was passiert, wenn Hardware ausfällt.

Der Ausfall einer Platte, eines Knotens oder eines Controllers kann Rebuild-Vorgänge auslösen, während Backup- und Restore-Jobs weiterlaufen. Die Zeit für den Wiederaufbau der geschützten Daten und die dabei verbrauchten Ressourcen können sowohl den Schutz als auch die Wiederherstellungsleistung beeinträchtigen.

Deshalb lohnt es sich, bei der Bewertung eines Backup-Ziels für größere Umgebungen auch im degradierten Zustand zu testen.

Beispiel: Wenn die Backup-Leistung einen Engpass bei der Wiederherstellung verdeckt

Nehmen wir ein Krankenhaus, das rund 400 virtuelle Maschinen mit Veeam schützt.

Die nächtlichen Backups werden auf eine Deduplizierungs-Appliance geschrieben, die um ein Controller-Paar herum aufgebaut ist. Die Jobs bleiben verlässlich in ihrem geplanten Fenster — im Alltag hat das Infrastrukturteam also wenig Anlass, die Leistung des Ziels zu hinterfragen.

Ein Ransomware-Vorfall erzeugt eine ganz andere Last. Sechzig virtuelle Maschinen müssen gleichzeitig wiederhergestellt werden.

Die Appliance muss nun große Mengen deduplizierter Daten lesen und rekonstruieren, während mehrere Restore-Jobs um dieselben Controller-Ressourcen konkurrieren. Manche Workloads sind schnell zurück, andere warten in der Schlange. Die Wiederherstellung zieht sich weit über das hinaus, was die gewohnte Backup-Leistung erwarten ließ.

Im Speichersystem ist dabei nicht zwangsläufig etwas ausgefallen. Die Last hat eine Grenze sichtbar gemacht, die der Backup-Routinebetrieb nicht zeigte: Das Ziel konnte Backup-Daten schneller annehmen, als es bei einer großen parallelen Wiederherstellung Daten zurückgeben konnte.

Deshalb sollten Tests eines Backup-Ziels den Durchsatz sowohl beim Schreiben als auch beim Wiederherstellen messen — und zwar bei der Parallelität, die im Ernstfall tatsächlich zu erwarten ist.

Backup-Ziel und Backup-Repository im Vergleich

Die Begriffe Backup-Ziel und Backup-Repository werden manchmal gleichbedeutend verwendet, können aber leicht Unterschiedliches bezeichnen.

Als Backup-Ziel gilt in der Regel das Speichersystem oder der Ort, der die Backup-Daten aufnimmt.

Ein Repository ist dagegen häufig die logische Speicherressource, die innerhalb der Backup-Anwendung konfiguriert wird. Je nach Produkt kann ein einzelnes physisches Speichersystem mehrere Repositorys, Buckets oder Speicher-Tiers bereitstellen.

Diese Unterscheidung im Blick zu behalten hilft bei der Suche nach Leistungsproblemen. Eine Repository-Konfiguration kann die Parallelität begrenzen, obwohl das darunterliegende Ziel noch Reserven hat, während eine physische Speichergrenze mehrere Repositorys zugleich betrifft.

Backup-Ziel und Backup-Software im Vergleich

Backup-Anwendung und Backup-Ziel haben getrennte Aufgaben.

Die Backup-Software steuert üblicherweise die Job-Planung, das Auffinden von Workloads, Backup-Richtlinien, Kataloge und die Orchestrierung von Wiederherstellungen. Das Backup-Ziel speichert die dabei entstehenden Daten.

Sicherheitskontrollen kann es auf beiden Ebenen geben. Die Backup-Software kann das Löschen über Rollen und Anwendungsberechtigungen einschränken, während das Ziel Kontrollen wie die Aufbewahrung auf Objektebene unabhängig von der Administrationsoberfläche der Software durchsetzen kann.

Ein tragfähiges Backup-Design berücksichtigt beide Ebenen, statt das Repository als bloße freie Speicherkapazität zu behandeln.

Wie Objektspeicher als Backup-Ziel funktioniert

Viele Enterprise-Backup-Produkte können direkt auf S3-kompatiblen Objektspeicher schreiben. Das aktuelle Kompatibilitätsportfolio von ARTESCA umfasst unter anderem Veeam, Commvault, Rubrik und Veritas.

Statt die Backup-Daten über eine klassische Dateisystemschnittstelle abzulegen, schreibt die Anwendung Objekte über die S3-API in Buckets.

Objektspeicher kann Kapazitätswachstum zudem mit verteilter Verarbeitung verbinden. In einem Scale-out-Deployment steuert jeder zusätzliche Knoten CPU, Arbeitsspeicher, Netzwerkbandbreite und Speicher bei, sodass der Gesamtdurchsatz mit dem Cluster wächst.

Das ist für Backup-Umgebungen nützlich, in denen sowohl die vorgehaltene Kapazität als auch die Zahl gleichzeitiger Backup- oder Restore-Streams im Lauf der Zeit zunimmt.

Wie ARTESCA als Backup-Ziel funktioniert

ARTESCA stellt S3-kompatiblen Objektspeicher bereit, der sich mit validierten Anwendungen — darunter Veeam, Commvault, Rubrik und Veritas — als Backup-Ziel nutzen lässt.

Backup-Daten lassen sich mit S3 Object Lock schützen. Bei korrekt konfigurierter Aufbewahrung im Compliance-Modus können gesperrte Objektversionen vor Ablauf ihres Aufbewahrungsdatums weder überschrieben noch gelöscht werden. Die Aufbewahrung wird damit von der Speicherebene durchgesetzt und hängt nicht allein an den Berechtigungen der Backup-Anwendung.

Für Veeam-Umgebungen ist ARTESCA derzeit als Veeam Ready Repository und Veeam Ready Object with Immutability zertifiziert dokumentiert. Es lässt sich als Performance Tier oder Capacity Tier einsetzen und unterstützt Veeams Smart Object Storage API (SOSAPI).

Über SOSAPI kann Veeam Speicherinformationen von ARTESCA abrufen, statt das S3-Ziel als undurchsichtigen Endpunkt zu behandeln. Die ARTESCA-Dokumentation weist darauf hin, dass die SOSAPI-Unterstützung Bucket-Metriken an Veeam ausgeben kann und automatisch aktiviert wird, wenn ein Bucket über den Veeam-VBR-Assistenten bereitgestellt wird.

Das Scale-out-Design von ARTESCA bedeutet außerdem, dass zusätzliche Knoten Speicher- und Rechenressourcen mitbringen, statt Kapazität hinter einem festen Controller-Paar zu erweitern. Das wird relevant, sobald Backup-Volumen und erforderlicher Wiederherstellungsdurchsatz zugleich wachsen.

Verwandte Begriffe