14.10.2016 (Do Storage)
4.4 von 5, (14 Bewertungen)

Datensicherung innerhalb einer Cloud

Leserfrage: Cloud-Backup wird viel umworben. Wobei ich es eigentlich oft eher als »Nutzung von Cloud-Storage für Backup-Daten« verstehe. Meine Frage richtet sich aber nun an die Durchführung von Backups innerhalb einer Cloud. Das heißt, Filesystem-, Applikationen- und Datenbanken-Backups, sowie die DR-Konzepte.

Aus der klassischen Welt kennen wir die typischen Client-Server-Backup-Architekturen, Storage- oder Filesystem-basierte Backup-Verfahren oder die Verfahren, die durch die Hypervisor-Architekturen zur Verfügung gestellt werden. Diese sind zumeist auch Enterprise-Lösungen. Mir scheint es, dass die bekannten Verfahren in der Diskussion rund um SDS, Object-Storage, Openstack, wie KVM-Hypervisor, Ceph oder Cinder abgehängt werden bzw. kaum noch anwendbar sind. Haben sie eine Vorstellung, wo das Backup und Recovery innerhalb einer Cloud-Architektur zukünftig seinen Platz finden wird?

Antwort Doc Storage:

Ja, die Vorstellung habe ich: Es dürfte sich in den vergangenen Jahren der Eindruck gefestigt haben, dass ich, was EDV angeht, ein relativ konservativer Knochen bin. Und so bin ich es auch und vor allem beim Thema Backup. Die meisten IT-Manager machen den Fehler und wählen die falsche Perspektive, wenn sie sich über die Zukunft ihrer Datensicherung Gedanken machen. Und das falsche Verfahren bei der Auswahl.

Aber fangen wir beim grundsätzlichen Einmaleins an. Was wollen Sie beim Thema Backup? Die meisten Firmen werden sagen »möglichst schnelle Datensicherung auf möglichst billigem Speicherplatz«. Darum geht es aber überhaupt nicht. Um beides nicht.

Im Zeitalter von Repliken ist die Dauer des Backups – selbst wenn es 24 Stunden überschreiten sollte, völlig irrelevant. Genauso werden diejenigen, die sich einmal möglichst preiswerten Speicher als Ziel für ihr Backup angeschafft haben, früher oder später ihr blaues Wunder erleben, sei es mit der Technik selbst, dem Kundendienst oder irgendeinem anderen Aspekt rund um ihren wichtigsten Speicher. Oh ja, dem wichtigsten Speicher – zumindest in dem einen Moment, wo die Produktivsysteme nicht mehr zur Verfügung stehen oder bestimmte Dateien in einer bestimmten Version von vor was-weiß-ich-wievielen Wochen gebraucht werden.

Damit kommen wir zum zweiten Punkt, der beim Thema Backup gern verkannt wird. Es geht nicht darum, möglichst schnell zu sichern. Nein, es geht im Gegenteil darum, möglichst schnell wieder aus dem Backup zurückzukommen. Ob nun vollständige Volumen oder nur einzelne Dateien, im Moment des Verlustes ist jede Sekunde kostbar. Deshalb sollten Sie jedes Verfahren nicht auf die Dauer des Backups, sondern auf die Dauer des Restores testen. Und nicht nur bei der Abnahme vor dem Kauf, sondern monatlich, wöchentlich, ja fast täglich. Weil nur ein trainierter Umgang mit den Systemen auch tatsächlich im Schaden- oder Verlustfall eine schnelle Wiederherstellung garantiert.

Ach ja – eines habe ich ganz vergessen, die eherne Grundlage der angewandten Informatik: Ockhams Rasiermesser. Die Empfehlung, nein, der Zwang, die zur Erreichung eines Zieles notwendigen Elemente auf ein Minimum zu reduzieren. Je weniger komplex die Verfahren sind, desto geringer ist die Wahrscheinlichkeit, dass diese an irgendeinem Punkt versagen. Das ist eine Binsenweisheit. Und gegen eben diese Binsenweisheit verstoßen immer mehr Rechenzentren, weil sie sich auf immer komplexere Prozesse mit immer mehr beteiligten Komponenten einlassen. Und warum? Wie beim Bergsteigen – weil sie da sind. Weil ihnen irgendwelche Experten weismachen wollen, dass sie hinten dran sind, wenn sie eben nicht diesen ganzen SDS-, Object-Storage, Openstack- und was-weiß-ich-noch für einen Unsinn in ihr Backup einbinden. Und damit jahrelang, jahrzehntelang bewährte und vor allem trainierte Prozesse gefährden.

Oft reicht es zur Optimierung, die ältlichen Bänder durch Plattensysteme zu ersetzen, diese vielleicht noch mit Deduplikation und Kompression auszustatten, wenn man das wirklich möchte, und zack – das Backup und vor allem der Restore beschleunigen sich um ein vielfaches. Ich weiß, ich weiß, die meisten Hersteller von Backup-Software haben bei der Einführung von Disk-Backup-Systemen Morgenluft gerochen und unverschämte Listenpreise aufgerufen. Aber die meisten haben sich inzwischen wieder beruhigt und sind vernünftig geworden.

Meine Meinung zum Thema »Cloud« rund ums Backup ist sehr simpel: nur, wenn es die eigene Cloud ist, im eigenen Haus. Und dann kann man sie auch gleich weglassen, da Backup ein eigener Dienst innerhalb der RZ-Infrastruktur ist – da lasse ich nicht mit mir diskutieren, und jetzt können gerne wieder alle Verfechter der Integration aus der Hecke springen. Backup gehört auf ein getrenntes Medium, in einen getrennten Prozess, im besten Falle in einen getrennten Abschnitt des Rechenzentrums. Damit diese Umgebung eben nicht von möglichen Fehlern oder Ausfällen im übrigen Betrieb betroffen ist. Und damit fällt eine Teilnahme an Cloud-Diensten aus. Dass ein ernstzunehmender RZ-Betrieb seine Backup-Daten nicht in fremde Hände und damit in eine außen gelegene Cloud gibt, diskutiere ich ebenso nicht.

Zum Schluss an alle »Finanzoptimierer« in den Ein- und Verkaufsabteilungen ein Satz, den ich schon oft geschrieben habe (ich weiß, ich nerve): es kommt nicht drauf an, was etwas im Einkauf kostet. Das interessiert nach ein paar Monaten sowieso niemanden mehr (außer den Einkäufer, der ja ach so viel Geld gespart hat, und den Verkäufer, der in die Karibik zum Presidents Club fahren darf). Es kommt drauf an, was es kostet, wenn das eingekaufte Gut einmal nicht funktioniert. Für Stunden, möglicherweise für Tage. Wenn keine Rechnungen geschrieben werden können, die Maschinen angehalten werden müssen, die Lkw der Lieferanten sich kilometerweit vor dem Tor stauen. Dann ist es schlichtweg egal, wie billig man das Verfahren mit einer Cloud, SDS oder anderen Kinkerlitzchen eingekauft hat, weil das Unternehmen nach kurzer Zeit nicht mehr existiert.

Man muss nicht jeden Blödsinn mitmachen, vor allem nicht in den Bereichen, in denen es ums Überleben geht. So, und jetzt dürfte ich, mal wieder, zum Abschuss freigegeben sein…

Gruß
Doc Storage

Kommentare (3)
14.10.2016 - LHL

Wenn ich die Leserfrage richtig verstanden habe, ging die Frage in die Richtung, wie man in der Cloud befindliche Server in der Cloud mit Backup/Recovery absichert. Meine Erfahrung aus den Gesprächen mit diversen Cloudanbietern dazu ist, das denen (Cloudanbietern) das Konzept des Backups/Recovery nicht wirklich bewusst ist. In der Regel verweist man auf Redundanzen entweder im selben Cloud-RZ oder auf Geo-Redundanz oder vielleicht auch noch auf die Möglichkeit von Snapshots, die dann aber immer noch auf den selben physischen Plattensystemen liegen bleiben. Angesichts dessen empfehle ich in der Cloud nur Server zu betreiben, auf die man im Ernstfall auch wirklich verzichten kann oder die sich anderweitig jederzeit wieder neu erstellen lassen (kurzlebige Wegwerf-Server ;) )

14.10.2016 - jan

Wunderschöne Dekonstruktion des Marketinggebluubers von Ferengi Verkäufern von Schlangenölbackuplösungen.
Im Bankingbereich wird bei Cloudlösungen teilweise bewusst auf klassisches Backup verzichtet.Die Daten werden redundant über drei Kontinent repliziert. (Eine für Normalsterbliche unbezahlbare - und hoch komplexe Aufgabe...).
Den Verzicht auf Tape-Libraries halte ich nur für angebracht, wenn das Diskbackup offsite ist. Ich möchte nicht versäumen, den Blitzschlag zu erwähnen, der bei einer benachbarten Firma - alle Drei Datenversionen (produktiv, Snapshot und Diskbackup) mit einem Schlag zu Knoll-Ontrack befördert hat....

14.10.2016 - joachim.stephan

Hach, schöner hätte ich es nicht schreiben können! Allerdings halte ich den Verzicht auf ein - von mir aus nachgelagertes - Backup auf Tape. Im Zeitalter von Ransomware sind Plattensystem zumindest gefährdet.


Mehr von Doc. tec. Storage 17.05.2019 NAS-Caching oder Tiering für VMs multiple Zugriffe?

In einer Lehrumgebung werden virtuellen Maschinen auf einem NAS mit 10GbE-Anbindung gespeichert. Nachdem eine Erweiterung mit NVMe-Flash ansteht, stellt sich die Frage, ob eine Caching- oder eine Tiering-Konfiguration die sinnvollere Wahl ist?


10.05.2019 Wird Flash nun auch zum Backup-Medium?

Flash wird zunehmend auch für Backup interessant. Der Geschwindigkeitsvorteil soll die Dauer der Sicherung wie auch der Wiederherstellung reduzieren. Macht dies in der Praxis bereits Sinn – auch aus Kostensicht?


03.05.2019 Unterschied zwischen Active/Active und Active/Passive

Beim Thema Hochverfügbarkeit unterscheidet man zwischen Konfigurationen, die Active/Active bzw. Active/Passive agieren. Was ist genau der Unterschied und für welche Szenarien empfehlen sich die beiden Möglichkeiten? Welche Cluster-Architektur bietet hinsichtlich Skalierbarkeit mehr Spielraum für zukünftigen Lastzunahmen?


26.04.2019 Dateisysteme für den PByte-Bereich

Datenberge jenseits des PByte-Bereichs, Cloud-Anbindungen und Analytics-Szenarien stellen Dateiysteme vor neue Herausforderungen. Der Markt bietet einige Optionen wie GPFS, Gluster FS, OneFS oder QF2. Worauf gilt es zu achten? Update zu CephFS und ZFS.


05.04.2019 Neuordnung des Storage-Tiering

Nachdem sich Flash und SSDs mittlerweile auch in mehrere Leistungsklassen unterteilen, steht die Technik nicht mehr nur für Tier 0. 15k-HDDs scheinen vor dem Aus zu stehen. Gilt dies auch für alle SAS-Platten? Wie sieht die Neuordnung des Storage-Tiering aktuell aus?


15.03.2019 30 Jahre World Wide Web: Was gibt es zu feiern?

Das World Wide Web feiert seinen 30. Geburtstag. Ohne dem Internet ist unser heutiges Leben nicht mehr vorstellbar. Für Doc Storage hat das Netz aber auch genug Schattenseiten. An Regulierungen bzw. an das vom Erfinder erhoffte bessere Internet, glaubt er nicht.

powered by
Boston Server & Storage Solutions Datacore Software
Itiso GmbH Seagate Technology
N-TEC GmbH FAST LTA AG
Fujitsu Technology Solutions GmbH Pure Storage