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 11.10.2019 Tape: Auferstanden von den Toten?

Tape scheint nicht nur von den Toten auferstanden zu sein, sondern ist in größeren Archiven bzw. bei größeren Datenmengen die einzig sinnvolle Alternative. Dies muss sogar Doc Storage zugeben…


27.09.2019 DSGVO für KMUs: Machen, nicht diskutieren

Einige KMUs sehen die DSGVO gerne als Gefahr für ihr Geschäft. Deswegen fordert der Bitkom auch noch mehr Erleichterungen. Doc Storage hält diese Forderung allerdings für nicht gerechtfertigt, obwohl er als bekennender Kritiker der DSGVO gilt. Die Verordnung ist nun mal da, daher machen, nicht diskutieren.


13.09.2019 Kann man Daten auf Festplatten erneuern?

Mehrere externe Festplatten wurden vor über zehn Jahren beschrieben und stromlos eingelagert. Kann bzw. sollte man die gespeicherten Daten erneuern, beispielsweise in dem die Daten an die gleiche Stelle zurückgeschrieben werden?


06.09.2019 Verschlüsselung von Festplatten in Servern

Warum sollten einzelner Ordner oder ganze Festplatten im Server-Bereich verschlüsselt werden? Ein Server im Betrieb muss die Daten entschlüsseln, weil sonst kein Zugriff möglich wäre. Generiert dies nicht nur Kosten? Welche Bedrohungen sehen sich Server ausgesetzt und welchen Maßnahmen empfehlen sich?


30.08.2019 Stress – die Perspektive aus dem Doppelboden

Stress ist vielen IT-Abteilungen Gang und Gäbe. Zu wenig Personal und zu enge Zeitrahmen, sind IT-Beauftragten nur allzu gut bekannt. Doc Storage antwortet in seiner Kolumne auf unseren Beitrag in der Rubrik Faktor Mensch und schildert zum Thema Stress seine Perspektive aus dem »Doppelboden«.


23.08.2019 Was ist Computational-Storage?

In Verbindung mit einer schnelleren Datenverarbeitung fällt wiederholt der Begriff Computational-Storage. Angeblich soll es sich um eine spannende Zukunftstechnologien handeln, wie sehen Sie das und welchen Stand hat die Technik bisher?

powered by
Boston Server & Storage Solutions Itiso GmbH
Fujitsu Technology Solutions GmbH Infortrend
N-TEC GmbH FAST LTA AG
Datacore Software Seagate Technology
Folgen Sie speicherguide.de auch auf unseren Social-Media-Kanälen
Folgen Sie und auf Facebook Folgen Sie und auf YouTube Folgen Sie und auf Twitter