7 Die meisten Speicherbewertungen für Veeam laufen rückwärts. Teams dimensionieren danach, wie schnell Daten hineingehen, und stellen dann während eines Vorfalls fest, dass es darauf ankam, wie schnell sie wieder herauskommen – und ob die Kopie überhaupt noch da war. Der beste Speicher für Veeam ist nicht das Ziel mit der höchsten Ingest-Rate oder dem niedrigsten Preis pro Terabyte. Es ist das Ziel, das noch eine wiederherstellbare Kopie hält, nachdem ein Angreifer zwei Wochen lang mit Domain-Admin-Rechten in Ihrer Umgebung unterwegs war. Das sind unterschiedliche Designziele, und sie führen zu unterschiedlichen Shortlists. Die kurze Antwort Als Profil statt als Produkt beschrieben: Der beste Speicher für Veeam ist ein S3-kompatibles Ziel mit aktueller Qualifizierung als „Veeam Ready – Object with Immutability“, das S3 Object Lock im Compliance-Modus durchsetzt, die Veeam Smart Object Storage API unterstützt, unter paralleler Last schnell wiederherstellt und hinter einer so kleinen Angriffsfläche liegt, dass eine Kompromittierung des Backup-Servers es nicht erreicht. Scality ARTESCA ist genau auf dieses Profil ausgelegt – und dies ist unsere Website, betrachten Sie das also als Offenlegung. Wenden Sie die acht Kriterien unten auf ARTESCA an. Und wenden Sie sie auf alles andere an, was Sie prüfen. Die vier Architekturoptionen Teams, die Veeam-Workloads schützen, landen in der Regel bei einem von vier Ansätzen – und jeder scheitert auf andere Weise. Gehärtetes Linux-Repository. Starke Unveränderlichkeit auf lokalen Festplatten, geringer Platzbedarf, keine zusätzliche Plattform im Betrieb. Stößt bei Skalierung und standortübergreifenden Kopien tendenziell an Grenzen. Objektspeicher in der Public Cloud, etwa Amazon S3 oder Azure Blob. Beseitigt die Kapazitätsgrenze und den Hardware-Refresh. Das Kostenprofil kehrt sich bei der Wiederherstellung um, wenn der Egress auf einen Schlag anfällt. S3-Objektspeicher On-Premises. Hält Daten und Wiederherstellungspfad lokal, mit Skalierung nach Cloud-Vorbild und Unveränderlichkeit per Object Lock. Eine Plattform, die Ihnen gehört, ist eine Plattform, die Sie betreiben. Integrierte Appliance. Backup-Software und Objektspeicher auf einem Host – das verkleinert die betriebliche Angriffsfläche und den Netzwerkpfad zwischen beiden. Der Preis ist eine engere Kopplung. Die meisten ausgereiften Umgebungen betreiben mehr als eine Option, weil die 3-2-1-1-0-Regel mehr als eine Kopie verlangt. Die folgenden Kriterien gelten für die Option, die die Kopie hält, auf die Sie sich verlassen. 1. Unveränderlichkeit, die Ihr eigener Backup-Admin nicht aufheben kann Unveränderlichkeit ist die am häufigsten beanspruchte und am seltensten hinterfragte Fähigkeit in dieser Kategorie. Die Unterschiede liegen eine Ebene tiefer. S3 Object Lock unterstützt zwei Aufbewahrungsmodi. Im Governance-Modus kann ein Benutzer mit den passenden Berechtigungen eine Aufbewahrungseinstellung verkürzen oder entfernen. Im Compliance-Modus kann das niemand – auch nicht der Kontoinhaber –, bis die Aufbewahrungsfrist abgelaufen ist. Moderne Ransomware-Akteure kämpfen nicht gegen die Sperre. Sie suchen die Identität, die sie abschalten kann. Die sinnvolle Frage lautet also nicht: „Unterstützt es Object Lock?“ Sondern: Welche Identitäten können eine Aufbewahrungsfrist verkürzen, und erbt ein Angreifer eine davon, wenn er den Backup-Server kompromittiert? Bitten Sie den Anbieter, den Löschpfad gemeinsam mit Ihnen durchzugehen. Wenn die Antwort ein Support-Ticket statt eines API-Aufrufs beinhaltet, ist das ein gutes Zeichen. 2. Veeam-Ready-Qualifizierung – und zwar welche Stufe Veeam betreibt ein formelles Qualifizierungsprogramm, und Objektplattformen können auf mehr als einer Stufe erscheinen. „Veeam Ready – Object“ bedeutet, dass die Plattform die Funktionstests als Objektziel bestanden hat. „Veeam Ready – Object with Immutability“ bedeutet, dass sie zusätzlich die Tests zur Unveränderlichkeit bestanden hat. Die Lücke zwischen diesen beiden Abzeichen ist genau die Lücke, die bei einem Ransomware-Vorfall zählt. Anbieter sind nicht immer präzise darin, welches sie haben. Prüfen Sie daher die Veeam-Ready-Liste statt der Marketingseite. Stellen Sie außerdem sicher, dass sie die Version abdeckt, die Sie einsetzen: Qualifizierungen gelten versionsbezogen, und eine Plattform, die vor mehreren Releases validiert wurde, ist nicht zwangsläufig erneut getestet worden. 3. SOSAPI-Unterstützung – folgenreicher, als es klingt Die Veeam Smart Object Storage API (auf Englisch), kurz SOSAPI, ermöglicht es einer S3-kompatiblen Plattform, sich gegenüber Veeam selbst zu beschreiben. Der Mechanismus ist bewusst schlicht: Der Speicher legt kleine XML-Dokumente an einem versteckten Ort im Bucket ab, und Veeam liest sie über gewöhnliche S3-Aufrufe. Kein Agent, kein zusätzlicher Port. Interessant ist, was diese Dokumente enthalten. Eines meldet Fähigkeiten. Ein anderes meldet die tatsächliche Kapazität, die Veeam in kurzen Abständen aktualisiert. Ohne diese Angabe zeigt Veeam einen On-Premises-Bucket als praktisch unbegrenzt an, weil S3 keine Standardmethode kennt, um den verbleibenden Platz abzufragen – und Aufbewahrungsentscheidungen werden auf Basis einer Zahl getroffen, die es nicht gibt. Andere Teile der API ermöglichen es einer Plattform mit mehreren Knoten, Backup-Streams an bestimmte Knoten zu leiten, und dem Speicher, zu signalisieren, dass er vorübergehend keine Schreibvorgänge annehmen kann. Nichts davon ist glamourös. Alles davon zeigt sich in weniger Überraschungen um zwei Uhr nachts. 4. Wiederherstellungsdurchsatz – getrennt vom Backup-Durchsatz gemessen Ein Backup ist ein streamender Schreibvorgang großer sequenzieller Blöcke. Die Wiederherstellung – insbesondere Instant Recovery und Wiederherstellung auf Dateiebene – folgt einem anderen Zugriffsmuster: kleinere Lesevorgänge, weniger vorhersehbar, oft parallel über viele Jobs, weil alle gleichzeitig wiederherstellen. Eine Plattform kann beim Ersten hervorragend und beim Zweiten mittelmäßig sein, und veröffentlichte Benchmarks betonen meist den Ingest. Testen Sie Wiederherstellungen. Und testen Sie sie dann, während ein Backup-Job läuft, denn genau in diesem Zustand wird sich Ihre Umgebung befinden. 5. Explosionsradius zwischen Backup-Server und Speicher Dieser Punkt wird oft übersprungen, weil er eine Frage der Architektur ist und keine Funktion, die man abhaken kann. In einer herkömmlichen Bereitstellung sind Backup-Server und Speicherplattform getrennte Systeme in einem gemeinsamen Netzwerk, die sich mit Zugangsdaten authentifizieren, die irgendwo gespeichert sind. Jedes dieser Elemente ist eine Angriffsfläche. Zugangsdaten können abgegriffen werden. Der Netzwerkpfad kann durchquert werden. Verwaltungsoberflächen sind meist aus demselben Subnetz erreichbar wie alles andere. Designs, die das reduzieren, sind unterschiedlich. Manche legen Backup und Speicher auf einen Host zusammen, sodass der Datenverkehr zwischen ihnen kein allgemeines Netzwerk durchquert. Manche setzen ein gehärtetes Repository-Modell mit abgeschottetem Betriebssystem und Einmal-Zugangsdaten durch. Manche tun beides. Die Frage ist einfach zu stellen und aufschlussreich in der Antwort: Wenn der Backup-Server vollständig kompromittiert ist, was kann der Angreifer erreichen – und was ist durch die Konstruktion und nicht nur durch Richtlinien außer Reichweite? 6. Verifizierung, die die Produktion nicht berührt Die letzte Ziffer der 3-2-1-1-0-Regel (auf Englisch) steht für null Fehler bei der Wiederherstellungsprüfung. Sie wird am häufigsten als bloßes Ideal behandelt, weil eine ordentliche Prüfung bedeutet, Backups hochzufahren – und dafür muss man entweder Produktionskapazität abzweigen oder ein Labor finanzieren, das niemand eingeplant hat. Neuere Veeam-Releases haben das günstiger gemacht: Ein zweiter Backup-Server kann sich im Nur-Lese-Modus an unveränderlichen Objektspeicher anbinden – für Wiederherstellungstests, forensische Untersuchungen und Validierung –, ohne die Daten zu übernehmen oder Produktionsjobs zu stören. Mehr dazu im Beitrag Veeam 13.1: what’s new for object storage. Wenn eine Plattform unabhängige Verifizierung günstig macht, findet Verifizierung tatsächlich statt. Das ist mehr wert als die meisten Leistungsunterschiede. 7. Wachstum ohne Neugestaltung Backup-Kapazität wächst nicht gleichmäßig. Sie wächst in Sprüngen – wenn sich eine Aufbewahrungsrichtlinie ändert, wenn eine Compliance-Anforderung hinzukommt, wenn ein neuer Workload ankommt. Manche Architekturen fangen diese Sprünge durch zusätzliche Knoten auf. Andere stoßen an eine Obergrenze, die eine Migration erzwingt – unangenehm, weil die Datenmenge groß ist, Aufbewahrungssperren noch laufen und die Kette intakt bleiben muss. Fragen Sie, wo die Obergrenze für die Konfiguration liegt, die Sie kaufen, nicht für die Produktfamilie. 8. Kosten über das gesamte Aufbewahrungsfenster Der Preis pro Terabyte ist die am einfachsten zu vergleichende Zahl und für sich genommen eine der am wenigsten nützlichen. Backup-Daten liegen jahrelang, und über diesen Zeitraum summieren sich: Egress, wenn das Ziel die Public Cloud ist, Gebühren für API-Anfragen beim Transaktionsvolumen, das Backup-Software erzeugt, Strom und Rackfläche bei On-Premises-Betrieb sowie die Zeit, die nötig ist, um zwei Plattformen gepatcht und synchron zu halten. Modellieren Sie den gesamten Aufbewahrungszeitraum, und nehmen Sie eine Wiederherstellung von nennenswertem Umfang in das Modell auf. Wo Scality ARTESCA passt ARTESCA ist der S3-kompatible Objektspeicher von Scality, speziell als Backup-Ziel entwickelt. Hier die Zuordnung zu den obigen Kriterien – so formuliert, dass Sie sie überprüfen können. Zu den Kriterien eins und zwei: ARTESCA wurde als „Veeam Ready – Object with Immutability“ zertifiziert und für nachfolgende Veeam-Releases validiert, einschließlich S3 Object Lock und SOSAPI. Unser Framework CORE5 beschreibt die Schutzebenen oberhalb der Sperre, von API, Daten und Speicher bis zu geografischen und architektonischen Ebenen. Eine einzelne Kontrolle ist ein einzelnes Hindernis, das sich überwinden lässt. Zu Kriterium fünf: ARTESCA+ Veeam betreibt Veeam Backup & Replication und ARTESCA auf demselben Host, sodass der Datenverkehr zwischen Backup-Anwendung und Speicher intern bleibt, statt ein allgemeines Netzwerk zu durchqueren. 2026 folgte eine Hochverfügbarkeitskonfiguration mit mehreren Knoten, die Resilienz auf Anwendungs-, Datenbank- und Speicherebene verbindet. Zu Kriterium sieben: Die Software skaliert auf Standard-x86-Servern von einigen Dutzend Terabyte bis in den Petabyte-Bereich, sodass Wachstum durch zusätzliche Knoten erfolgen soll und nicht durch einen Plattformwechsel. Zu Dimensionierung, Lizenzierung und den Unterschieden zwischen Appliance-Modell und einer Bereitstellung mit zwei Plattformen liefert die ARTESCA + Veeam FAQ die betrieblichen Details. Nichts davon macht es überall zur richtigen Antwort. Ein Betrieb mit einem etablierten gehärteten Linux-Repository und einer funktionierenden Bandrotation erfüllt die Kriterien eins, fünf und sechs womöglich bereits. Die Kriterien sind der beständige Teil. Ein Produkt ist eine Möglichkeit, sie zu erfüllen. Das Wichtigste in Kürze Bewerten Sie die Wiederherstellung, nicht das Backup. Der Ingest ist die Zahl, die Anbieter veröffentlichen, und die Zahl, die bei einem Vorfall am wenigsten zählt. Testen Sie Wiederherstellungen unter paralleler Last, bevor Sie etwas unterschreiben. Verfolgen Sie den Löschpfad, nicht das Versprechen der Unveränderlichkeit. Object Lock unterstützt jeder. Was Ziele unterscheidet, ist, welche Identitäten die Aufbewahrung verkürzen können und ob ein Angreifer sie zusammen mit dem Backup-Server erbt. Behandeln Sie Integrationstiefe als Resilienzmerkmal. Kapazitätsmeldungen per SOSAPI und Nur-Lese-Zugriff für die Verifizierung klingen nach Komfortfunktionen. Sie sorgen dafür, dass Aufbewahrungsentscheidungen stimmen und Wiederherstellungstests günstig genug sind, um tatsächlich durchgeführt zu werden. Der rote Faden ist kurz: Backup-Speicher existiert für einen Tag, der noch nicht gekommen ist, und an diesem Tag zählt, ob die Kopie überlebt hat und wie schnell sie zurückkommt. Unveränderlichkeit, die ein Angreifer nicht aufheben kann, entscheidet das Erste. Das Wiederherstellungsverhalten unter Last entscheidet das Zweite. Alles andere ist ein unterstützendes Argument. Häufig gestellte Fragen Was ist der beste Speicher für Veeam-Backups? Die stärksten Kandidaten haben ein gemeinsames Profil: Unveränderlichkeit, die ein kompromittierter Backup-Administrator nicht aufheben kann, eine aktuelle Qualifizierung als „Veeam Ready – Object with Immutability“, SOSAPI-Unterstützung, unter paralleler Last validierte Wiederherstellungsleistung und eine kleine Angriffsfläche zwischen Backup-Server und Speicher. Scality ARTESCA ist für On-Premises-Bereitstellungen auf dieses Profil ausgelegt. Bewerten Sie jeden Kandidaten anhand dieser Kriterien, nicht anhand einer einzelnen Durchsatz- oder Preisangabe. Ist Objektspeicher für Veeam besser als ein gehärtetes Linux-Repository? Beide lösen sich überschneidende Probleme auf unterschiedliche Weise, und viele Umgebungen betreiben beides. Ein gehärtetes Repository bietet starke Unveränderlichkeit auf lokalen Festplatten bei geringem Betriebsaufwand. Objektspeicher skaliert in der Regel weiter, bewältigt standortübergreifende Kopien natürlicher und integriert sich über SOSAPI. Da die 3-2-1-1-0-Regel mehr als eine Kopie verlangt, lautet die eigentliche Frage, welches System welche Kopie hält. Erfordert Veeam S3 Object Lock im Compliance-Modus? Veeam arbeitet grundsätzlich mit Object Lock, doch der Aufbewahrungsmodus bestimmt, wie viel Schutz Sie erhalten. Der Governance-Modus erlaubt einer ausreichend privilegierten Identität, die Aufbewahrung zu ändern. Der Compliance-Modus erlaubt das nicht, bis die Frist abgelaufen ist. Wenn Sie sich nach einer Kompromittierung von Zugangsdaten auf genau diese Kopie verlassen, passt der Compliance-Modus zur Bedrohung. Ist Scality ARTESCA Veeam Ready? Ja. ARTESCA wurde als „Veeam Ready – Object with Immutability“ zertifiziert und für nachfolgende Veeam-Releases validiert, einschließlich der Unterstützung von S3 Object Lock und SOSAPI. Es ist als Software-Appliance, als Hardware-Appliance und als ARTESCA+ Veeam erhältlich, das Veeam Backup & Replication und ARTESCA auf demselben Host betreibt. Wie sollte ich ein Backup-Ziel vor dem Kauf testen? Stellen Sie einen realistisch dimensionierten Workload wieder her und wiederholen Sie dies, während ein Backup-Job läuft. Versuchen Sie außerdem, ein gesperrtes Objekt mit allen Zugangsdaten der Umgebung zu löschen – auch mit den am höchsten privilegierten – und dokumentieren Sie, was Sie daran hindert. Weiterführende Lektüre: Veeam 13.1: what’s new for object storage, ARTESCA + Veeam backup FAQ sowie die Veeam-eigene SOSAPI-Dokumentation (auf Englisch).
