Skillbyte Podcast #50: Kein Backup? Kein Mitleid!

Willkommen zum Skillbyte-Podcast! Skillbyte ist Ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Kein Backup? Kein Mitleid!

// Inhalt //
00:59 - Warum Backups (trotz Cloud) in jedem professionellen IT-Umfeld extrem wichtig sind!
03:08 - Die Cloud fängt Feuer - Der OVH Brand
06:18 - Desaster Recovery Konzepte sind essentiell
08:35 - Wie erstelle ich ein sinnvolles Recovery Konzept?
13:12 - Recoverystrategieen passend zum jeweiligen Budget
19:02 - Komplexität möglichst niedrig halten und testen
21:54 - Recovery Erfahrungen aus der Praxis
27:21 - Ein positives Beispiel und...
28:44 - ...zwei negative Beispiele.
34:14 - Cloud native Anwendungen sind resilienter gegeüber Ausfällen
35:15 - Haftungsfragen
37:40 - Auch große Webseiten wie Office365, Amazon und Stackoverflow fallen aus
41:10 - Weniger Hardware, mehr Software(wissen)
41:58 - Zusammenfassung

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

AUTOMATISCH ERZEUGTES TRANSKRIPT

Aber am Ende des Tages darf man nicht vergessen. Insbesondere der heutigen Klout wählt. Wir reden hier über IT-Infrastruktur und Server. Virtuelle Maschinen, Storylines, Netzwerk, alles das, was man halt braucht. Und das kann halt alles einfach ausfÃllen.

Herzlich Willkommen zur Skillbyte Podcast Episode Nr. 50. Kein Backup, kein Mitleid. Abonniert unseren Podcast für mehr spannende Themen aus dem Technologie Umfeld General, die Entscheider oder die Fachkraft seid wenn eine höhrer Frage habt, schickt uns gerne eine E-Mail an Podcast Skillbyte e und empfehlt unser Podcast an Freunde und Kollegen weiter, die sich für ähnliche Themen interessieren. Das ist uns ganz ganz wichtig. Heute bin ich hier mit dem Gründer und Geschäftsführer der Cloud Mates Maurice kuemmern.

Hallo Maurice, oh schöner Abend.

Das ist eine ganz ungewohnte Situation für mich als Maurice mit einem Maurice zu sprechen. Aber das haben wir ja schonmal gemacht und ich werde mich da so rein fuchsen. Backups sind ja nicht gerade ein sexy Thema, wenn man über IT Themen spricht. Das möchte keiner machen. Jeder hat ein schlechtes Gewissen. Jeder weiß okay, das muss man irgendwie machen. Und mit den Entwicklungen der letzten Jahre geht eher alles in die Cloud und die Cloud Provider geben sich reichlich Mühe zu sagen, dass die Daten dort immer sicher sind und rund um den Globus verteilt.

Aber auch da sind wir in jüngerer Vergangenheit eines Besseren belehrt worden.

Genau. Ja, das hat sich über die Zeit, ja glaube ich nicht verändert. Egal ob man früher im eigenen Rechenzentrum anbrennen, wie man heute sagt oder beim Hosting Provider oder auch neuerdings in der Cloud Back gab es immer so ein Etwas, ein leidiges Thema. Es hört sich immer so ein bisschen an, als wenn man da verspricht, als wäre man ein Versicherungsvertreter. Aber am Ende des Tages darf man nicht vergessen, insbesondere der heutigen Cloud Welt. Wir reden hier über IT-Infrastruktur und das heißt Server, virtuelle Maschinen, Story, Joe's Netzwerk, alles das, was man halt braucht.

Und das kann halt alles einfach ausfallen, egal welchen Aufwand ich treibe. Ich kann ein Rechenzentrum redundant auslegen. Wie auch immer, es kann dort brennen. Es kann die komplett ausfallen. Es kann die Bombe einfallen. Das sind schon so die ganz extrem Sachen. Derer bedarf es häufig gar nicht. Es reicht, wenn einfach ein Server Schrank ausfällt und dort ist meine ganze Struktur dran und schon läuft halt nichts mehr. Und da sind sagen wir mal Backups. Einer der wichtigen Maßnahmen im Rahmen von Notfall Management Business Continuity Management neben vielen aber natürlich sehr, sehr wichtig.

Und das darf einfach nicht Vergessenem und insbesondere heute in der Cloud werden.

Das ist ja so eine Sache. Du sagst, dann läuft was nicht mehr, wenn nur was nicht läuft, also das ein Server ausfällt und man mal umschalten muss. Ich denke die Situation kennt jeder. Aber dagegen schützt er ein Backup nicht. Ein Backup schützt er wirklich gegen Datenverlust. Also wenn wirklich entweder ein Hacker das System befällt und man es sofort abschalten muss und die Dateien schon verschlüsselt sind und jemand Bitcoin haben möchte, damit die wieder entschlüsselt werden oder ein wirklich Katastrophen Fehler auftritt und die Festplatte oder das Wahlsystem alle kaputt geschrieben werden.

Also defekte Hardware einfach die die Daten korrumpiert, sodass auch Prüfsumme nichts mehr nützen. Oder eben wie vor kurzem in den Medien der v.H. Brand also das ist ein französischer Cloud-Anbieter, der viele, viele 10 000 Kunden hat. Und ich glaube, er hatte vier Gebäude, in denen jeweils Server Infrastruktur untergebracht war und eines ist komplett abgebrannt. Und über 15 000 Kunden waren betroffen, unter anderem die französische staatliche Webseite mit den Informationen zur aktuellen Covert 19 Pandemie. Und da merkt man dann schon Oh, das trifft ja richtig ins Mark.

Das war natürlich direkt so ein Fall, wo er von einem Fall oder Desaster Recovery dann auch sprechen würden. Da sind einfach Infrastrukturen inklusive Daten komplett ausgefallen und nicht nur einfach ein Schrank, wo ich dann sagen na gut, dann nehme ich halt ne virtuelle Maschine auf unserem Server, der einem anderen Schwandt steht. Spiel da was ein, sondern es war komplett weg. Und jetzt musste ich mir halt überlegen Okay, hab ich im Backup? Wenn ja, wo spiele ich das ein?

Ich hab kein Backup, was mach ich dann überhaupt? Und da sind glaube ich viele einfach so ein bisschen der Einstellung aufgesessen. Naja, das ganze ist eine Cloud Umgebung, da wird schon alles irgendwie sicher sein. Das ist bestimmt mehrfach redundant. Wie auch immer. Mag sein. Ich weiß jetzt tatsächlich nicht, wie in dem Beispiel die Datenhaltung dort aussieht. Aber in aller Regel muss ich sagen, ist der Kunde dafür verantwortlich, das Backup zu machen oder in Auftrag zu geben.

Wenn das nicht passiert ist, dann ist das natürlich ein Problem.

Jetzt könnte ich mir vorstellen, bei v.H. Dieses Rechenzentrum etwas abgebrannt ist, war wirklich das Produkt. Was in diesem Rechenzentrum betrieben wurde ist so ne Private Cloud Umgebung gewesen für Firmenkunden. Und da wird ja auch das Falz System wird ja spottbillig sein. Und das ist ja auch so eine Art Backup, auf das sich Kunden verlassen, was natürlich beim gleichen Anbieter in einem anderen Server gemacht wird. So, und wenn das ganze Gebäude ausbrennt oder abbrennt, dann stirbt natürlich jedes System, jede Festplatte und alles in diesem Gebäude und das Backup stirbt gegebenenfalls direkt mit dem Production Server oder zeitgleich mit dem Production Server, was leider sehr hoch.

Und zwar einfach aus einem ganz kleinen Grund. Kunden möchten Kosten sparen und ein Backup. Ich brauch Software oder Services, die das für mich erledigen. Ich brauche Deutsch. Wo das hinkommt, idealerweise auch in ein. Zweiten Brand Abschnitt oder noch besser in ein zweites Rechenzentrum, das wo einfach in eine örtliche Distanz zwischen ist, der mitteilt, in solchen Katastrophenfällen zumindest meine Daten gesichert sind und schon mal da sind. Das ist schon mal ein ganz wichtiger Faktor. Aber natürlich ist es und da kann ich nur wieder den Vergleich zur Versicherung bringen.

Man zahlt halt ne ganze Menge dafür und brauch es in aller Regel nicht. Aber natürlich in solchen Fällen insbesondere Baumanns. Ganz klar.

Und ja, Backup, du hast es eben schon gesagt. Das hat immer sowas Spießbürgerliche. Ist also dieses ganze Thema. Das ist so ein bisschen wie ein Sicherheitsgurte ist lästig. Man muss sie nochmal anlegen, man muss sie nochmal ablegen und im Grunde braucht man ihn nicht, wenn alles gut geht. Aber wenn man ihn braucht, dann kann er lebensrettend sein bzw. geschäfts rettend. Jetzt in diesem Fall oder je nach Daten kann es natürlich auch lebensrettend sein. Dann ist man froh, wenn man ihn hat.

Und genauso ist es auch mit dem Backup meiner Ansicht nach.

Das lästige dabei ist gar nicht so das Backup zu erstellen. Ich glaube, die meisten Administratoren und IT Entscheider sind schon schnell dabei, sein Backup zu erstellen. Ein großes Manko ist immer Was machen wir denn, wenn wir es jetzt einspielen müssen? Wenn so ein Fall eintritt, habe ich die verschiedenen Risiko Szenarien durchgespielt und wie gehe ich dann vor? Also einen Plan zu haben, was mach ich damit? Es war total schön, wenn ich da mein Daten backup.

Aber wenn ich in der Risikoanalyse und in meinem bis sie einmal festgestellt habe naja, ich darf eigentlich maximal eine halbe Stunde ausfallen, sonst habe ich schon erhebliche Einbußen z.B. bei einem Webshop oder ähnlichem. Und wenn ich einen Tag ausfalle, dann ist es für mich zum Beispiel existenzbedrohend. Oder auch zwei Tage eine Zeit. T Dann muss ich natürlich Pläne haben, um das in so einem Fall auch wieder rechtzeitig einspielen zu können. Und das ist tatsächlich für viele die wirklich lästige Arbeit.

Das verstehe ich. Das heißt, das Backup selber ne Kopie zu ziehen, irgendwo hin in den Schrank zu legen. Früher machte man das mit Tapes, weil man einfach sehr viel Speicherkapazität auf diesen Tapes hat, die natürlich langsam sind. Also das Beckert wieder einzuspielen kann sehr lange dauern. Dann und dann kann man so mental ein Häkchen an Backup gemacht dransetzen. Aber da gehört natürlich noch viel mehr dazu, dass man eben Systeme doppelt vorhält oder einen Disaster Recovery Plan hat oder einen Data Recovery Plan.

Ich kann es selber aus eigener Erfahrung, also nicht ganz eigener Erfahrung. Aber ich kenne Unternehmen, die sind befallen worden von diesem Verschlüsselungen Trojaner. Und da war es so, dass auf jedem PC ein Netz Laufwerke mounten war, worüber dann eben Dateien ausgetauscht wurden. Firmen weit. Und das wurde eben komplett verschlüsselt, weil ein Rechner befallen war. Und die Daten waren quasi alle weg und mussten aus dem Backup wiederhergestellt werden, was in dem Fall Gott sei Dank geglücktes heutzutage leider auch ein zu bedenken.

Das Risiko ein gefahren Punkt, dass man halt ein Backup hat, was auch entsprechend weit zurückgeht. Also wo ich einfach meine Retention Zeitraum habe, der jetzt nicht nur die letzten 5 Tage abdeckt, weil ich sag mal diese Trojaner sind dann mal da. Die legen vielleicht nicht im ersten Moment los, indem dem sie auf das System befallen sind, baden vielleicht einfach mal 10 Tage und sind dann sozusagen mit in den Backups drin. Und hier ein längerfristiges Backup Szenario zu haben ist ganz gut, weil man kann dann sich wirklich Stück für Stück vorhanges und sagen Okay, jetzt bin ich Trojaner frei ist aber ein sehr spezielles Szenario.

Was würdest du denn Kunden raten, die vielleicht noch keine eigene Strategie haben? Die sagen Maurice hilf mir bitte. Ich weiß, das ist ein kritisches System. Wir können bis zu nehmen wir mal zwei Tage überstehen, wenn das System offline ist. Aber dann muss es auf jeden Fall wieder online sein und sogar das wäre schon eine Katastrophe. Wie würde ich sowas typischerweise angehen? Was brauche ich dazu?

Der wichtigsten Dinge hast du jetzt schon vorweggenommen. Das ist tatsächlich, sich Gedanken darüber zu machen, welche Risiken sind einfach da und welche Auswirkungen haben sie für mich und mein Unternehmen? Also wie viel Daten darf ich verlieren, ohne dass es für mich schädlich ist? Und wie schnell müssen Daten wieder zur Verfügung sein? Daten, aber halt auch die Datenverarbeitung, Systeme, die Infrastruktur. Das muss man sich vorher schon mal genau überlegen. Und das Wichtige hierbei Man tendiert häufig dazu, wenn man das das erste Mal macht, die die Einschätzung falsch zu machen.

Also hier sich wirklich auf jemanden reinzuholen, der das vielleicht schon paar hundert Mal gemacht hat und durch existiert hat und die kritischen Fragen halt dann stellt. Also das steht am Anfang, dass man tatsächlich so eine kleine Risikoanalyse macht. Man sagt so ja gut wie sehr das für mich aus. Und dann geht man halt Szenarien durch. Man kann auch hier nicht alle abdecken, aber man nimmt dann ein paar klassische Szenarien, bricht diese durch und da geht es dann von so einfachen Sachen.

Meine Datenbank ist irgendwie Korruptheit. Ich muss die Daten einspielen, weil das Deutsch da drunter ein Problem hatte. Im Rat ist ein sehr einfacher Fall. Das fällt in aller Regel auch sehr schnell auf. Das heißt, ich kann halt Daten einspielen und je nachdem wie mein Backup Szenarios hab ich halt sagen wir mal die Daten vom letzten Tag zur Verfügung. Und wenn man dann sagt na gut, jetzt hab ich dann vielleicht im Worst Case acht Stunden Daten verloren aus einem Business Tag.

Das kann ich noch aufarbeiten. Das ist für mich vertretbar. Ist natürlich immer mehr Aufwand, aber das kann ich einfach in Relation zu den Maßnahmen setzen. Bei einem Webshop. Es ist wohl das Klassische, weil man hier die Eins zu eins Abbildung auch zum Busens hat. Da kann das natürlich schon deutlich empfindlicher sein. Nehmen wir mal übertreiben ein bisschen. Wir nehmen mal Amazon als einen sicherlich der größten Shops, die wir so alle kennen. Die dürfen sich sicherlich nicht einfach lassen, eine Stunde auszufallen.

Der Umsatz, der allein in Deutschland dadurch flöten ginge, wäre sicherlich immens. An der Stelle und die werden dort sicherlich einen etwas aufwendigeren Plan entwerfen. Aber die wissen genau das und das kann ich mir an Auswahl erlauben. Das kann ich mir nicht erlauben. Und darauf werden dann die Konzepte gebracht und zwar erstmal die eigentliche Plattform. Also meine ganze Infrastruktur drauf auszulegen, dass ich auch hier Redundanzen habe, gegebenenfalls auch mit redundanter Datenhaltung, sei es in verschiedenen Brant Abschnitten, sei es über verschiedene Cloud Geo Station oder sogar verschiedene Cloud Provider, weil man darf ja auch nicht vergessen.

Es kann da auch ein systematischer Fehler sein bei einer hyper Skala. Und ja, da ist es einfach nichts mehr machbar. Es ist nichts mehr erreichbar und dann muss ich mein letztes Backup einfach woanders einspielen. Im Worst Case. Was aber auch schon wieder zeigt Ja, wo liegt denn mein Backup überhaupt? Lass ich das da, wo es gemacht habe oder schiebe ich das woanders hin? Die Verordnung des Ganzen ist ein sehr, sehr wichtiger Aspekt. Und das sind jetzt erst einmal triviale Themen.

Aber ich glaube schon. Aus diesem trivialen Themen zeigt sich Ah, da geht so ein bisschen der ganze Entscheidungs Baum auf. Wie setze ich das Konzept an?

Okay. Das heißt Gedanken machen. Welche Schäden oder wie teuer käme es mich zu stehen, wenn ich ausfalle? Und welchen Ausfall verkrafte ich maximal? Gibt es da Experten oder bin ich da bei den Cloud Mails? Richtig? Wenn ich sage helft mir mal bitte. Ich würde es gerne einschätzen oder von meiner Plattform meinen Use Case, mein Business abschätzen. Kann ich euch dann kontaktieren und fragen, ob ihr mir helft, Sohn Becker Plan zu erstellen.

Was gehört bei uns eigentlich immer mit dazu? Also wenn man Infrastrukturen plant, dann ist das ganze Back up Szenario und Betrachtung von Störungen, Notfällen, Katastrophenfällen gehört einfach mit zur Dienstleistung. Dazu wird dann erörtert. Aber auch für jemand, der sich noch gar nicht mit dem Thema beschäftigt hat und sagt Naja, ich würde das gerne jetzt mal standardisieren. Ich hab jetzt so Begriffe gehört wie Risiko, Notfall, Management, Business, Continuity Management. Das sind einfach Begriffe.

Diese jetzt sagen wir mal aus den ganzen Normen wie ISO Sinus hat sich 901 hat die Grundschule Innen Wirtschafts Normen einfach entstanden sind, wo es einfach ganz klare Vorgaben gibt, wie man verfahren soll, welche Maßnahmen man ergreifen sollte und in welcher Tiefe diese Maßnahmen gehen. Und wir hangeln uns letztendlich auch an diesen Standards entlang und geben Empfehlungen. Und der Kunde kann dann immer nochmal entscheiden. Naja, also hier an der Stelle vielleicht überlegen, was dort. Wir müssen nicht binnen einer Stunde wieder online sein.

Wir können es auch gar nicht leisten, weil wir haben nur ein ITler, sag ich mal. Dann ist das natürlich auch eine Überlegung wert. Oder man sagt Naja gut, eigentlich brauchen wir das binnen einer Stunde. Und ich hab nur einen Tile, also muss ich das outsourcen. Also das sind dann Über-Leben. Aber da hätten wir natürlich sehr gerne an der Stelle, das zu realisieren.

Und kannst du vielleicht mal so kleinen Einblick geben, was günstige Möglichkeiten sind? Also sehr einfache Beckert Möglichkeit und was es dann an mittlerer Komplexität, hoher Komplexität geben kann. Also was dann maximale Sicherheit verspricht. Also das ist ja so ein Spektrum auf der einen Seite günstig wäre wahrscheinlich im Prinzip blad einmal am Tag alle deine Daten auf eine externe Festplatte runter, die du für 100 Euro gekauft hast. Das wäre natürlich kaum ein Mehrgewinn an Sicherheit, aber sehr, sehr günstig.

Und nun? Auf der anderen Seite steht wahrscheinlich, die Infrastruktur dreimal vorzuhalten in drei unterschiedlichen Orten auf der Welt. Und die sind im Grunde alle online und werden dann einfach nur per DNS umgeschaltet oder so was gibt es dazwischen für Möglichkeiten.

Also es gibt natürlich die volle Bandbreite, aber um einfach mal ein paar Szenarien zu skizzieren häufig der erste Schritt überhaupt auch in die Cloud für Mittelstand zu unternehmen. Klein wie groß, wie viel noch selber machen. In eigenen Rechenzentren oder beim Hosting Provider ist einfach hinzugehen. Okay. Ich nehme jetzt einfach meine klassische Backup Struktur entweder direkt vom Storage Element back, also ich kann da durchaus Plug-Ins innerhalb des Dorische erinnern. Meddeb Oder in Dels Staubiges oder nehmet gibt eine ganze Menge schaffen und guck erstmal, dass ich diese Daten aus meinem eigenen Rechenzentrum raus bekomme, dass ich sie halbwegs sichere.

Auch da gibt's mehrere Möglichkeiten. Ich kann sozusagen eine Virtual Tape Library Anbindung. Kann sagen Ja, ich hab sowieso hier ein lokales Backup und jetzt? Meine Software ist dazu in der Lage, dass ich noch ein weiteres Medium anspreche. Da hab ich so eine Virtual Tape Library und die liegt zufällig in der Cloud und dann schiebe ich das darüber. Dann ist das einfach ein ganz klassisches Backup, das Feedback abfeiert, die man natürlich idealerweise verschlüsselt in die Cloud legt.

Das ist so die große Versicherung. Der Vorteil Ich muss mir keine Gedanken machen. Reichen die wie die Bänder aus? Die Datenbestände steigen ja doch eher exponentiell an. Ich mache mir da keinen Kopf drum. Ich kann auch hier, wenn ich jetzt sage, wir hatten eben den Fall mit dem Trojaner Schutz. Ich kann sagen, ich erschlage hier zwei Fliegen mit einer Klappe. Meine Freizeit soll einfach länger werden. Ich möchte einfach ein Vierteljahr Backups vorhalten, dann kann ich das dort auch Thrun.

Ich kann dann sagen ja, die aktuellen Sachen, die liegen auf einem schnelleren. Und die älteren Sachen gehen in so ein Dieb a KFV und da sind wir wieder bei Bändern. Also selbst die großen Provider, sowas wie AVS, sie schieben das auf Bänder. Hier ist dann das Recovery. Das dauert dann noch eine Zeit, das muss erst mal da wieder geholt werden. Das ist also nicht binnen Sekunden da. Aber naja, in K. Fall ist es in aller Regel hinreichend.

Das ist nur das einfachste Szenario. Dann hab ich wirklich nur die Daten weg gesichert und das sehr günstig, auch nur weil diese virtuell teil bleiben. Res Dreistes ja wahrscheinlich auch wirtschaftlich vertretbar. Ein Vierteljahr meiner ganzen Daten vorzuhalten, wenn ich 10 Minuten warten kann, bis ich das Pál wieder gemauerte habe oder darauf zugreifen kann und das dann erstmal nochmal wieder runterladen muss. Und das muss dann ja auch noch wieder eingespielt werden.

Es ist auf jeden Fall die günstigste Variante, weil ich halt tatsächlich nur Standarddeutsch miete und ich sag mal und man hat es noch im PC go. Also ich muss jetzt keine Kontingente oder sowas einkaufen, sondern letztendlich wächst es somit wie ich es brauche. Das ist also die einfachste Möglichkeit, wenn wir bei dem Szenario bleiben. Ich hab noch eigenes Rechenzentrum, man kann das ein bisschen aufpeppen. Das hat jetzt weniger mit dem eigentlichen Backup zu tun. Aber wenn ich jetzt davon ausgehe, dass meine Inning in der Infrastruktur weg ist, dann kann ich zwar argumentieren Naja, dann ist vielleicht auch meine Produktionshalle abgebrannt und wie auch immer, dann hab ich sowieso alle Zeit der Welt die Kapazitäten aufzubauen.

Aber ich habe vielleicht Systeme, die ich von Anfang an brauche, z.B. um meine Kunden zu informieren Adresse Stem oder ähnlichem gewähltem CRM System. Es wär vielleicht gar nicht so schlecht, zumindest eine Handvoll Systeme schnellstmöglich am Laufen zu haben und dann würde ich doch schauen, dass ich diese Prio 1 Systeme vielleicht dann auch einfach in der Cloud zur Verfügung stellen kann, dass ich das vorbereite. Da kommen natürlich Kosten für die Vorbereitung, aber das können schlafende Systeme sein. Also kalte Systeme, wie wir sagen Kolosses sind, die fahr ich erst hoch.

Wenn es wirklich soweit gekommen ist, dann kommt es mir nicht auf die Stunde an, aber ich will ja zeitnahe Dinge erledigen können. Also Kunden anrufen ähnlich. Das ist dann so ein erster Schritt hin. Naja, ich bin wieder Arbeitsfähige an der Stelle.

Und würdest du auch empfehlen, das von meinem anderen Cloud-Anbieter zu machen? Also Stichworte Multi Cloud ist man dieser OVA? Brant Das kommt jetzt natürlich nicht jeden Tag vor, aber ist natürlich. Stell dir vor, du bist jetzt eine Anwaltskanzlei, die verliert da alle ihre Daten. Das ist natürlich kritisch, wenn du da nicht mehr handlungsfähig bist vor Gericht. Also wie macht man das? Clever.

Jetzt gerade sind wir davon ausgegangen, dass der Kunde eine eigene Datenhaltung irgendwie hat und das dann schon nach extern schiebt, dass ich jetzt an beiden Stellen Notfall habe. Denkbar, aber relativ unwahrscheinlich kann das auf die Spitze treiben. Ich kann natürlich drei klappbar weiter nehmen. Alles noch da hinschieben. Ich glaube das ist für die meisten dann schon etwas viel Vodoo. Aber absolut rechtens ist, wenn ich sowieso schon bei einem Cloud Provider bin und dort meine Sachen haben immer mal ein Beispiel.

Ich habe alles bei Avesta, dann macht es durchaus Sinn darüber nachzudenken. A schiebt das vielleicht auch mal zu Google oder und Microsoft, die haben ähnliche Systematiken. Ich kann eigentlich relativ leicht auch hier Notfall Systeme aufbauen und dann habe ich einfach nochmal einen zweiten Standort. Viele glauben ja immer, dass insbesondere die Halper Scala und v.H. Die sind jetzt nicht grade die kleinsten Anbieter auf der Welt. Sind jetzt nicht vergleichbar mit einer AWS, aber sie gelten halt auch als Cloud Provider.

Und man sieht ja selbst bei so einer Firma, die so groß aufgestellt die Rechenzentrum in der ganzen Welt betreibt, die sicherlich Ahnung von dem Thema. Trotzdem es kann passieren, wie wir immer sagen shit happens. Und deswegen ist es durchaus sinnvoll hier so eine Multi Cloud Strategie zu fahren. Definitiv.

Was ich auch festgestellt habe ist, wir haben jetzt darüber gesprochen, wie man das Backup macht. Aber natürlich muss es auch im Fehlerfall oder im Desaster fallen. Muss es natürlich auch wieder eingespielt werden und dafür erstellt man halt zum Plan. Was muss wo zurück gesichert werden? Das ist natürlich nochmal weniger sexy als das Backup selber. Und meiner Erfahrung nach tendieren solche Pläne dazu, relativ komplex zu werden, was es noch viel schlimmer macht. Weil Komplexität killt dann einfach diese leichte Verständlichkeit, die man ja in dieser Stresssituation das muss man sich auch vor Augen halten, wenn man ein Desaster Recovery macht.

Ich hatte das bisher einmal bei einem Kunden, dass das toll gemacht wurde. Das war auch nicht angenehm, aber da ist man dankbar um jedes Script, was er schon vorbereitet ist, sodass jeder umfangreiche Dokumentation wo genau steht, wo jetzt was hingehe gesichert werden muss. In dem speziellen Fall, an den ich jetzt denke, da wurde dann noch im Handbuch geblättert, wie man das Backup wieder einspielt und so. Also hohe Komplexität beeinträchtigt auf jeden Fall auch die Wirkweise von einer Desaster Recovery oder von Backup Strategien negativ.

Insbesondere dann der Fall wie in im erst skizzierten Szenario, wenn ich wirklich nur mein Daten Backup irgendwo hin geschoben hat. Im Worst Case muss ich Infrastruktur wieder aufbauen und ich will noch nicht mal sagen alles. Aber wer schon mal sag jetzt mal Nevermann Oracle Datenbank die in sich sehr komplex sein kann oder Microsoft Excel Datenbank redundant aufgebaut. Das ganze Ding ist weg geschmiert. Ich muss alles von Scratch auf neu machen, wenn ich jetzt nicht gerade das in VMS laufen habe, was meistens aus Lizenz rechtlichen Gründen nicht gemacht wird, weil das dann doch zu teuer wird.

So, das heißt das ganze Recovery Disaster Recovery, das sollte man. Plan Man sollte es vor allen Dingen auch mal testen. Die Zeiten dabei stoppen. Und man sollte es auch regelmäßig machen, weil es kommt genau das, was du sagst. Es ist der Stress und es dauert auch seine Zeit. Also ich. Ich setze das System auf. Dann kommt das Configuration Management. Es muss noch durch konfiguriert werden und dann müssen die Daten eingespielt werden. Und das verbraucht wirklich Zeit.

Und ich glaub hier rechnen sich viele diese Zeiträume auch schön, weil in aller Regel, wenn man so einen Fall hat es kommt ja nicht gerade zu dem Zeitpunkt, wo man gerade nichts zu tun hatte, sondern es kommt genau dann, wenn man nämlich gar nicht vorbereitet ist. Sagen wir mal Sonntag nachts und Montag muss wieder alles laufen oder so und das sollte man tatsächlich machen und wir können nur empfehlen, das zu testen. Sei es war macht es selber oder man macht es auch mit dem Dienstleister zusammen, weil man ja auch gucken muss, wie es meine Personaldecke kann ich sowas im worst case machen?

Wie es mein Krankenstand? Hab ich vielleicht gerade Urlaubszeit? Denn sowas passiert ja. Also alles Dinge, die eigentlich negativ in die Bilanz dann sozusagen reingehen. Und je nach Risikoeinschätzung muss man mit diesen worst case Szenario hantieren. Auch wenn ich mich jetzt wieder wie ein Versicherungsvertreter anhöre, aber leider, leider zielt es ein bisschen in diese Richtung ist kann potenziell lebensrettend sein. Und man sollte natürlich jetzt auch nicht all seine Anstrengungen Richtung Backup sozusagen fokussieren, es sei denn, man hat halt wirklich wie Amazon oder andere große Provider super viel zu verlieren.

Dann gibt es dedizierte Teams, die nichts anderes machen als Desaster Recovery zu üben oder eben auch ständig die Backup Methodologie zu erweitern. Ich glaube das ist ganz wichtig. Du hast ja auch schon mal im Rechenzentrum betrieben. Wie seid ihr denn vorgegangen? Wie oft habt die Desaster Recovery geübt? Wie lief das ab? Ist vielleicht jemand rein gegangen und hat willkürlich irgendwelche Stecker rausgezogen, um zu gucken, ob es funktioniert? Das macht Netflix ja angeblich, um zu gucken, ob ihr System so resilient ist, dass es damit umgehen kann.

Wie seid ihr vorgegangen mit den Rechenzentren, die wir früher betrieben haben? Die waren halt nach dem STANDARD zertifiziert, nach dem alte Grundschuld vom BSI. Und hier gibt's halt einfach gewisse Vorgehensweisen. Und die haben wir einfach auf alle Kunden angewandt, egal ob sie jetzt diese spezielle Zertifizierung brauchen. Ja oder nein. Das war für uns der STANDARD und es geht halt so, dass wir letztendlich. Es gab ja auch unterschiedliche Arten von Backups und die mussten regelmäßig getestet werden.

Und wir sind dann hingegangen, entweder in Absprache mit dem Kunden, weil das ist ja eine Shared Responsibility. Egal ob man jetzt in der Cloud einem Rechenzentrum ist. Wir arbeiten für den Kunden. Der Kunde muss auch mitarbeiten, muss es gegebenenfalls kontrollieren. Die Geschichten des treten vielleicht Probleme auf, die nicht dokumentiert sind. So, und deswegen haben wir das mit den entsprechenden Kunden tatsächlich getestet werden. Und ach ja gut, wir simulieren jetzt mal ein Ausfall. Sowas passiert dann zu natürlich neben Bereichen in aller Regel oder in einer Freigabe Umgebung.

Die größeren Kunden haben halt speziell als Septen Systeme und dort konnten wir das dann sehr sehr gut testen und haben da null Covered. Wir haben da noch Zeiten mitgenommen, um einfach zu sagen Okay, wir sind in unseren Zeitfenstern aktiv. Das passt schon. Und haben dann letztendlich nochmal betrachtet. So was könnte denn jetzt noch schiefgehen. Weil das war natürlich ein Testens. Kein Live-CD. Carrillo Was könnte jetzt noch schiefgehen? Also was weiß ich. Man muss das mitten in der Nacht machen.

Man ist müde, man muss die Leute erst mal zusammenbekommen und und und und hat es dann bewertet. Also diese Bewertung ist nochmal wichtig, dass man die halt auch regelmäßig durchführt. Das Ganze ist ein Prozess. Ja, dass da IT-Manager halt immer sagt Ja, das so so gut es kann mit der Zeit sich ja was verändern. Ich hab vielleicht mal einen kleinen Webshop angefangen und hinterher bin ich Marktführer in meinem Segment. Plötzlich haben sich meine Ansprüche verändert. Passt das noch alles?

Das spricht schon immer für eine Regelmäßigkeit. Und ich will es hier nicht übertreiben. Also die meisten Systeme funktionieren gut und wie auch immer. Aber ich empfehle schon einmal im Jahr ist das absolute Minimum für ein Recovery Test und das sollte man machen, wenn überhaupt ein Risiko da ist. Natürlich, wenn ich kein Risiko hab, dann ist es egal. Da mache ich mir darüber keine Gedanken. Aber wenn ich Risiken identifiziert habe, dann sollte man es auch als solches testen.

Okay, einmal im Jahr und dann wirklich in. Du sagst in einer Akzeptanz Umgebung oder in einer Freigabe Umgebungen ausprobieren. Nicht das Produktionssystem direkt neben klar. Und dann die Abläufe auch einstudieren mit dem Team, welche das Backup dann im Notfall auch einspielen muss.

Bei dem Testing. Man kann da unterschiedlicher Ansicht sein. Man könnte so nenne es jetzt mal Blindtest. Ich informiere die Leute vielleicht gar nicht vorher. Als IT-Manager und versuche das so ein bisschen zu simulieren. Ähnlich wie man das zum Beispiel bei einem Feueralarm in den Firmen macht. Den kündigt man in aller Regel auch nicht an. Aber meines Erachtens ist das noch nicht mal zwingend nötig. Also das darf gerne organisiert sein. Die Leute dürfen vorbereitet sein. Wenn man dann hinterher hingeht und sagt Okay, das war jetzt sozusagen der Kopf vorbereitet, wie würdest du nennen oder nicht Kopfbereich so sehen.

Und deine Einschätzung zwackt. Ich glaube, das ist hinreichend für die meisten Fälle. Das mag nicht auf alles zutreffen, aber für die meisten passt das schon.

Im Grunde ist das so ein bisschen wie Piloten, die müssen ja auch regelmäßig in den Simulator und Mul Simulator werden. Auch natürlich Fehlerquelle. Oder Ausfälle simuliert? Was mache ich, wenn das Triebwerk brennt oder wenn ein Triebwerk ausfällt, muss ich natürlich auch noch mit einem dem verbleibenden Triebwerk das Flugzeug landen können. Die testen das ja auch. Und da ist es völlig klar, warum man das macht. Und das Backup ist immer so ein oder die Recovery Strategie ist sowas unsichtbares, was man hoffentlich nie braucht.

Und ich habe auch schon gehört, dass die Leute sagen hoffentlich braucht man das nur, wenn ich mal irgendwann weg bin oder fällt mich in meiner aktiven Zeit rein.

Maßnahmen sind häufig umgesetzt. Ich ich sag mal, ich hab eigentlich die Erfahrung gemacht im Unternehmen. Ich kenne keine, die nicht Maßnahmen, also sowas wie ein Backup oder Desaster Recovery Diana ein Produkt gekauft z.B. und sagen na gut, jetzt hab ich's ja so und das ist halt die falsche Sicherheit dabei. So einer das gar nicht macht, das ist wirklich sehr, sehr selten. Aber das, was ich am Anfang sagte, den Plan zu haben, für diesen Fall, für den störungsfreie oder für den Notfall, das ist das Wichtige dabei.

Und das ist auch tatsächlich das Lästige dabei. Aber da führt kein Weg dran vorbei.

Der Plan muss ja fortlaufend angepasst werden, wenn die Infrastruktur wächst oder sich Änderungen ergeben müssen in neues Rechenzentrum online. Oder ich hab den Plan gemacht, da hatte ich fünf VMs. Jetzt habe ich 15, weil die Anwendungen gewachsen ist. Da muss man immer dran denken. Erwird es muss dann entsprechend mitwachsen.

Es hat auch Auswirkungen auf Anreichen. Man nehme mal Sourcecode. Ja, wenn ich z.B. eigene Software entwickelt, auch im Unternehmen, was ja nicht so selten vorkommt, dass man eigenen Bigler Abteilungen hat. Im Mittelstand ja ist der Sourcecode gesichert und wo ist er gesichert? Es ist vielleicht mein Cherno Hof. Wenn ich mein eigenes Schutzsystem System oder eine eigene Plattform kreiert habe, dann kann ich das auch wieder herbeiführen. Das was häufig vergessen wird an der Stelle. Also das sind nicht nur immer die reinen Daten, sondern es ist tatsächlich auch Software.

Es können auch Konfigurationen sein im Rahmen. Ich habe Konfiguration Management Systeme. Das ist total toll. Ich habe alles zentral. Aber was ist, wenn mir diese Infos alle fehlen? Oder ich könnte gar nichts mehr aufsetzen. Da kommt das rein, was du eben Sackes. Es kann sehr schnell sehr komplex werden, wenn man dahinter. Naja, von daher kann ich das immer nur wieder betonen.

Denn in deiner langjährigen Erfahrung mal ein besonders positiver Fall aufgefallen, der dir jetzt direkt einfällt, also dass du sagst Okay, die haben das wirklich klasse gelöst und machen regelmäßig die Tests und das ist immer gut gegangen und da hätte ich überhaupt kein Bedenken wer die man Ausfall haben. Die sind in kürzester Zeit wieder online. Sobald die Hardware sozusagen wieder mit dem Internet verbunden ist und Strom hat.

Also wir haben einen Fall, da ist es zum Glück nie zu diesem Desaster Recovery gekommen. Aber der Plan an sich war halt sehr gut mit Ausfall, Rechenzentrum, gespiegelten Daten, potentiellen Einspielern, Mechanismen. Das war das kann man glaub ich an dieser Stelle auch sagen, das war der Bundesanzeiger, da wo alle die Unternehmen ihre Jahresabschlüsse in Report müssen. Das ist natürlich eine sehr wichtige Plattform an der Stelle und hier wurde ein sehr großer Aufwand getrieben. Da war das sehr wichtig und das hat sehr gut funktioniert.

Ansonsten hatten wir eigentlich gerade in den Zeiten des Rechenzentrums ich sag mal, da war das so, dass normale Kunde rief Anbauer, bei mir ist irgendwas kaputtgegangen, Festplatten ausgefallen, wie auch immer, die wurden getauscht, Backup eingespielt. Das war tatsächlich Alltag, das war STANDARD und von daher würde ich das gar nicht so hervorheben. Aber eigentlich, wenn es so ist, wenn es diesen STANDARD und diesen Status hat, dann hat man alles richtig gemacht. Wenn es wirklich ein STANDARD ist, wenn man keine Kopfschmerzen hat, wenn alles unaufgeregt abläuft, wenn jeder weiß, was zu tun ist, dann hat man es wirklich geschafft in dem Bereich.

Und hast du auch ein Negativbeispiel aus deiner Erfahrung? Also wurde das Board. Die haben das probiert. Das ist richtig in die Hose gegangen. Also ohne den Kunden natürlich zu nennen. Aber einfach das man mal vielleicht eine Warnung ausspricht, dass man das so nicht machen sollte.

In dem Fall war es halt so, dass ein sehr sehr großer Kunde auch mit einer sehr sehr großen Datenbank, die in sich redundant war, aber zwei Brand abschnitt. Also das hat man halt nicht gewollt. Und hier kam es zu einem Problem der Datenbank Hersteller hatte ein Problem, das hat die Daten Korruptheit. Das ist auch erst sehr spät aufgefallen. Bei den großen Datenbanksystem hab ich in aller Regel noch andere Mechanismen, diese Sachen sehr, sehr schnell wiederherzustellen, sodass wir komplett ins Backup gehen mussten.

Und hier hat sich herausgestellt, das Konzept hatte Lücken. Wir müssen das unbedingt mal testen. Aber das wurde aus Zeitdruck Gründen wurde das bei der Implementierung nicht gemacht, wurde immer vor sich hergeschoben und dieser Test fehlte halt einfach. Und wir haben dann letztendlich im Live Betrieb getestet und es gab vehemente Probleme, die allerdings muss man zugegebenermaßen auch sagen ein Stück weit an der Datenbank Software laden und man kann sich vorstellen Soldat Mann Griese bis der einen Patch für so einen Fall hat, selbst wenn man einer der wichtigsten Kunden ist.

Das dauert so seine Zeit. Und ja, wir hatten drei Wochen Ausfall war komplett Ausfall dannauch.

Ja, die Datenbank war weg. Also die Applikation, die diese Datenbank benötigen. Und es war eine nicht unwichtige Applikation für den Kunden, die waren drei Wochen lang weg.

Werker Das ist ja schon gar nicht gut.

Hier kamen zwei Dinge, zwei bis drei Dinge übereinander, wo alle immer sagen Ah ja, das ist ja schon sehr unwahrscheinlich. Aber das passiert einfach. Und hier kann ich wieder nur sagen Shit happens. Dann geht es los und es war eine sehr intensive Zeit. Ich war seinerzeit selber sehr stark eingebunden, weil mein Haupt Gebiet diese Datenbank Architektur war mit einem Kollegen. Wir haben halt auch über weite Strecken, bis wir auch nachgewiesen hatten, dass wir ja mehrere Probleme haben.

Haben wir halt einfach im Wechsel Betrieb 24/7 gearbeitet an „Das. Das war kein Spaß, das muss man ganz klar sagen und mit sehr viel Stress für alle Beteiligten. Also für den Kunden wie auch immer. Ja, man hatte dann natürlich hinterher nicht mehr so das Problem, sind Desaster, Tests und Plena und so weiter. Nochmal durchzugehen. Aber genau das will man ja vermeiden. Also das sind so Fälle, die will man wirklich überhaupt nicht haben.

Das heißt aber auch wenn ihr das vorher oder wenn der Kunde das hätte einmal testen wollen, dann wäre dieses Problem oder diese Probleme. Cascade schon früher aufgefallen.

Also das ist nicht so hundertprozentig klar. Das muss ich zur Ehrenrettung da sagen, weil wie gesagt, wir hatten auch ein Problem in der Datenbank an sich. Aber ich behaupte, weil es ein systematischer Fehler war. Es wäre aufgefallen, lässt sich drüber streiten, aber es bleibt einfach Bestand. Dadurch, dass es nicht getestet war es auch diese Unklarheit schon. Da er also der Kunde hatte auch nicht die Möglichkeit zu sagen Passt auf, lieber Dienstleister, wir haben das so getestet, wir haben ja Tests, Protokolle, die sind alle okay.

Wie konnte das passieren? Also dann hätten wir ja auch, sagen wir mal, vielleicht als Dienstleister den Fehler gemacht an der Stelle. Aber auch das war nicht da. Also letztendlich musste sich tatsächlich der Kunde das voll und ganz ankreiden. Und ja, was natürlich auch nicht angenehm ist, wenn man das auch noch seinen Vorgesetzten dann report muss umändern und dass man an der Stelle gespart hat. Ja, was soll ich sagen? Also das war wirklich der schlimmste Fall, der mir untergekommen ist.

Ich selber hatte man Fall, da hab ich eine Applikation migriert von einem in das andere Rechenzentrum und habe in dem anderen Rechenzentrum. Es war auch eine Datenbank von Oracle 11 Datenbank in eine Oracle 11 Datenbank. Also im zweiten Rechenzentrum habe ich quasi einfach das Backup der ersten Datenbank wieder eingespielt, aber die meiner Version hinten hat sich um ein paar Angaben unterschieden. Also es war nicht viel, aber sie hat sich unterschieden und ich konnte das Backup einspielen. Sah zuerst einmal gut aus und ich weiß auch nicht warum.

Also in der Datenbank waren unter anderem Bilder gespeichert und in den Bildern ist mir aufgefallen, dass da so eine Ecke eine andere Farbe hatte. Also total verrückt. Das Bild war drin, aber eine Ecke hatte man andere Farbe und das war bei allen Bildern so. Und dann hab ich geguckt und dann waren da JPEG Artefakte in dieser einen Ecke und dann hab ich die Bilder aus der Quelle Datenbank aus der Zil Datenbanken verglichen und am Anfang sind immer ein paar Bait 0 gewesen.

Also in der Datenbank nicht in der anderen Datenbank schon. Und so hab ich dann erst mal rausgefunden, dass ich die Quelle Datenbank erst mal auf die Version updaten muss, die die Datenbank auf der anderen Seite auch hat, damit sozusagen das Backup kompatibel war. Das war jetzt in dem Fall eine Migration und kein Backup. Wieder einspielen, aber beim Backup wieder einspielen, da das ja genauso passieren können. Ich mache mal schön Backups von meiner Datenbank, spiel irgendwann meine Update ein.

Die Datenbank crasht. Ich möchte jetzt mein Backup wieder einspielen und schon habe ich dieses Problem der Daten Corruption. Jetzt waren das Bild Dateien, da sieht man das Bild immer noch. Aber bei irgendwelchen komplexen Binär Dateien oder sowas kann es sein, dass die ganze Datei dadurch unleserlich wird und hab sofort ein Riesenproblem und das ist nur durch diesen Test aufgefallen, sonst wäre das niemandem aufgefallen.

Durchaus klassischer Fall, weil man natürlich und auch verständlicherweise eigentlich bei einem meiner ABDA beim Patch Level jetzt nicht davon ausgeht, dass das eine Auswirkung auf die Daten hat. Kann aber immer passieren und es ist auch immer der Zeitpunkt, wo ich nochmal ein Full Backup fahre. Ich hab das das Update gefahren, wie auch immer und ich muss dann nochmal vorbei. Gab's auf die neue Version haben, wenn ich dann Egemen Tele Backups hab und dann spiele ich was von vor 10 Tagen einer Soost antreten solche Aspekte halt leider auf.

Das wird zwar immer weggetan und naja, irgendwie hat es nie einer erlebt, aber ich sag jetzt mal wir beide sitzen zusammen und 50 prozent der Leute haben es minimum erlebt.

Ich glaube generell muss man schon sagen, dass Sistema Ausfall sicherer werden. Also zumindest was die Hardware angeht auf aufgrund diese Bewegung in die Cloud, weil man heute einfach damit rechnet, dass so ein Standart Server kaputt geht und dementsprechend auch schon die Anwendung entwickelt. Das hat man ja da. Vor 10, 15, 20 Jahren war das ja nicht unbedingt der Fall. Da hast du ja so implementiert, dass immer alles da ist. Netzwerk ist da, Festplatten Platz ist da und so weiter.

Und da ist man heute bei diesen cloud-native Anwendungen schon vorsichtiger, weil man weiß okay, entweder laufe ich auf 3 Servern oder auf 30. Es kann also immer mal sein, dass ein Server wegkommt, weggeht oder dazukommt. Da muss ich drauf vorbereitet sein und die Protokolle geben das vorher. Dennoch sind natürlich solche Beispiele wie dieser u.v.a. Brant, wo das ganze Rechenzentrum abbrennt, ein Extrembeispiel, keine Frage, auch wenn sie vorkommen. Es gibt ja diesen Spruch Absolute Sicherheit gibt es nicht.

Ich denke, das gilt auch für jedes Backup Konzept. Aber je nach Wichtigkeit der Daten und der Anwendung sollte man das natürlich anstreben.

Es gibt noch einen weiteren Aspekt dabei. Hier bin ich auch nicht ganz sattelfest, zugegeben. Maßen. Aber wenn man als IT Leiter oder auch als Geschäftsführer nicht das technisch mögliche und natürlich an die Situation Angepasste gemacht hat, es sich dann sogar auch die Auswahl Versicherungen oder sonstige Versicherung querstellen. Aber sagen Ja, im Moment habt ihr nicht das Minimum state of the art gemacht. Also das sollte man schon betrachten. Und ich kann's auch nur betonen. Claude Umgebung Man fühlt sich immer sehr sicher, weil das sind einfach riesige Verbünde und man sagt Naja, gut, die haben natürlich ein Interesse daran, dass alles immer läuft, wie auch immer.

Aber wir haben mitbekommen, bei Microsoft während des Office 3 fünfundsechzig ausfällt regional, also in Deutschland EMEA was auch immer. HWS hat schon gehabt, dass Zonen ausgefallen sind. Das waren jetzt eher technische Probleme, die dann schnell behoben worden sind und dann war man wieder erreichbar. Das hatte keine Datenverlust oder sowas zur Verfügung, aber auch eine nicht erreichbare Struktur. Wenn ich irgendwann sag, ich kann die Zeit jetzt nicht mehr einschätzen und ich muss jetzt online gehen, dann brauch ich im Zweifelsfall ein Backup, was ich woanders einspielen kann.

Das geht in der Cloud ja glücklicherweise, wenn ich gut vorbereitet bin, extrem schnell, dass ich in einer neuen Geo Location also wenn ich normalerweise sagen wir mal in Frankfurt poste und ich sag in Helm gut, dann spiele ich das halt jetzt in Dublin ein und dann geht das ja sehr schnell. Das ist ja das Schöne an Cloud ansetzen. Aber ich muss halt vorbereitet sein. Ich muss den Plan nahm. Ich muss alle technisch organisatorische Maßnahmen ergriffen haben, um genau das zu bewerkstelligen.

Man darf sich nicht sicher sein, denn und das ist ein Spruch. Ich weiß gar nicht, wo ich den her. Ich glaub von der Free Software Foundation. Ich sage mal eine Cloud Umgebung sind einfach nur andere Leuts Rechner. Und das macht es eigentlich so ein bisschen klar. Ich hab egal ob ich an Trambahn, egal ob ich beim Hosting Provider bin oder in der Cloud die Infrastruktur. Darunter sind im Zweifelsfall einfach Rechner, wo man sich viele Gedanken gemacht hat in sicheren Rechenzentren und und und und.

Aber auch hier kann immer etwas passiert und leider leider wir haben das Beispiel jetzt mehrfach gebracht, aber es ist nun mal leider auch das aktuelle Beispiel. Bei Overhead ist es passiert. Die meisten Kunden hatten glaub ich ein Backup und waren auch wieder relativ schnell für so'n Katastrophenfall online, weil Overhead alles gemacht hat, um Kapazitäten zur Verfügung zu stellen. Weil man kann sich vorstellen, ich weiß nicht wie man 10 000 Server was aber macht. Auch das fällt einem Großen auf dem Markt schwer, diese Kapazitäten ganz schnell zur Verfügung zu stellen.

Und dann gab es natürlich diejenigen, die tatsächlich keines hatten. Die hatten gedacht Ja klar, dorische, alles redundant. Ja, mag sein, aber Backup muss man trotzdem machen.

Und es ist ja auch so also die meisten Ausfälle von den Cloud Providern hast es eben angesprochen passieren durch irgendwelche Software-Updates der Cloud Provider spielten Softwareupdate ein. Auf einmal muteten Router falsch. Office 3 65 ist offline, Abstoß offline eine Stunde lang, bis das gemerkt wird. Ich weiß vor das jetzt bestimmt auch schon 3 4 Jahre her. Steeg Overflow war mal eine Zeitlang offline und die haben das in einem Blogpost sehr genau analysiert und irgendjemand hatte eine Rec Expression falsch geschrieben und und ein Zeichen wurde nicht terminiert und jemand hat diese Webseite geladen mit dieser Regular Expression und sofort war das ganze Rechenzentrum ausgelastet und die haben Wochen gebraucht, um rauszufinden, woran es liegt.

Angedacht zu werden angegriffen und das Korber nachlesen als Stack overflow regular expression offline. Wenn man 2017 und 2018.

Mich sogar noch da dran. Das ging ja ziemlich rum. Also ich sag mal den Leuten, mit denen wir so zu tun haben, da erfährt man das sofort.

Genau. Genau in den alten Kreisen ist das natürlich von Stack Overflow schon ausfällt, geht die Entwickler Produktivität auf der ganzen Welt deutlich nach unten. Und das heißt, jeder merkt das natürlich auch oder jeder Entwickler merkt es natürlich auch sofort und versteht natürlich dann auch den Blogpost. Werden die hinterher sagen Jo, da haben wir eine Regular Expression nicht richtig terminiert. Ich glaube, sie hatten keinen Datenverlust, aber sie hatten einen mehrtägigen kompletten System Ausfall, bis sie das Ding irgendwann gelöst bekommen haben.

Ich glaube Beispiele gibts da mannigfaltig und ich versuche mich halt immer gerade nicht als der Versicherungsträger Vertreter da aufzuführen. Natürlich arbeitet man mit diesen Worst-Case-Szenarien. Aber ja, kleine Ursachen können manchmal eine große Wirkung haben und man sollte sich zumindest die Gedanken drüber machen. Und man sollte es wenn Nida fassen. Und wenn ich z.B. der IT-Manager in einem Unternehmen bin, dann würde ich das verschriftlichen, wenn ich von oben gesagt gekommenes alles so teuer ähnlichem, was auch okay, so und so sieht es aus.

Damit meine ich im Falle eines Falles dann halt, da es sauber sei. Wir haben uns Gedanken gemacht, sie haben Vorschläge gemacht, wir haben ihnen was unterbreitet. Wir haben einen Plan. Der ist aber nicht so schnell. So und so ist das denn. Und das auch regelmäßig zu diskutieren in Meetings, in Jahres, Besprechungen, Quartals, Besprechung. Da das Ganze als Prozess anzusehen und wirklich genau anzugucken, wo an wir Nachbesserungsbedarf oder positiver was brauchen wir vielleicht auch gar nicht mehr an der Stelle.

Doch, das gibt's natürlich. Also das ist sicherlich nicht so schwierig als Prozess zu initiieren. Das sollte das Minimum sein und das man dann halt entsprechende Maßnahmen und Pläne aufstellt. Und das muss gar nicht so überkandidelt sein. Das ist auch richtig gesagt Keep it simpel. Es muss im Notfall funktionieren und ich muss mit Prioritäten arbeiten. Sich Bewusstsein. Was muss ich denn herstellen? Es war total schön, wenn die Applikation oh Meß, um jetzt mal trivial zu sprechen, aber die Datenbank noch zwei Tage braucht.

Also das muss einfach alles mal angefasst werden, durchdacht werden. Dann sind vor allem Plan aufzustellen. Dazu ist jeder in der IT. Weil jeder hat mit Backup in irgendeiner Form zu tun gehabt als eine der Maßnahmen in diesem ganzen Plan. Und dann ist man da schon einen deutlichen Schritt weiter. Es ist halt wie immer das Bewusstsein, dass man darüber nachdenkt und es auch regelmäßig wieder mal hervorholt. Und nicht nur denken, dass es jetzt ein bisschen böse gesagt, aber nicht hingeht und sagt Naja, ich hab doch da jetzt 20 000 Euro für Lizenzen bezahlt und dann hab ich mir noch teures Deutsch und Tape Libraries geholt.

So, jetzt bin ich sicher. Naja, na also. Ich glaub, ich muss keinem sagen, dass das der schlimmste Fehlschluss ist, den man da machen kann.

Backups werden konzeptionell also von dem, was man wissen muss, was man bedenken muss und wie viel Gehirnleistung man da rein stecken muss, schon anspruchsvoller. Aber Hardware seitig von den Kosten her werden sie viel, viel günstiger als das noch vor einigen Jahren der Fall war. Also ich kenne Großunternehmen, die haben im Keller noch diese On Priamos Tape Libraries. Ich will gar nicht wissen, was das alles kostet, das zu unterhalten. Da ist natürlich so eine Virtual Tape Library oder verschlüsselte riesige Images bei Amazon.

Ja, da in die Cloud zu legen, das ist natürlich viel günstiger, als da eigene Hardware vorzuhalten. Aber ich glaube, die Konzepte werden ausgefuchster und man muss auch mehr wissen, um dann eben zielgerichtet diese Backups wieder einspielen zu können. Aber wenn man das Wissen hat und das vorbereitet, dann kann das sehr schnell erfolgen.

Und weil dem so ist. Und damit komme ich zu dem Titel des heutigen Podcast, sag ich auch ganz klar kein Backup, kein Mitleid. Wer sich da nicht die Gedanken gemacht hat, weil das ist eigentlich wie in der IT Ausbildungen in Alman. Es ist eigentlich präsent. Es wird einem jedem aufgetischt. Es ist omnipräsent. Das Thema, wie gesagt ein sehr leidiges Thema. Es ist nicht besonders sexy ist. Es hat einen Rattenschwanz an an Tätigkeiten, aber es leider leider muss es gemacht werden.

Und jeder, der man so einer Situation war wir haben heute einige Beispiele genannt wird dankbar sein, wenn er diese Arbeit geleistet hat als Vorbereitung darauf.

Das ist das sprichwörtliche Gefühl, wenn man erfolgreich in der kritischen Situation Backup eingespielt hat. Das ist diese. Der Kelch ist an mir vorübergegangen. Gefühl.

Genau wenn ich. Ich hab da als Bild im Kopf. Ich hab die Füße oben, hatten Kaffee und sagt keine Nachfragen in fünf Minuten. Könnte weiterarbeiten. Wenn man in diesem Bild sich bewegt, dann hat man wirklich alles richtig gemacht. Dann passt es. Und ich glaube, so muss es auch sein. Denn du weißt selber Wir sprechen viel über Digitalisierung. Wir alles soll mehr. Mit Computern soll digital erledigt werden. Und dann muss ich mich halt auch um solche Dinge kümmern, denn ich sag mal, nichts ist schneller verschwunden wie ein Bit.

Ja, das kann ich ganz schnell verschwinden lassen. Zu Fax und Co. wollen wir auch nicht wieder zurück. Und deswegen müssen wir da einfach weiter lernen. Man muss am Ball bleiben. Das ist auch keine Raketenwissenschaft. Es muss halt gemacht werden.

Vielen Dank, Maurice. Wenn unsere Zuhörer Fragen haben oder Feedback zur Podcast Episode schickt uns gerne eine E-Mail an Podcast Skillbyte Erzählt auch euren Freunden und Kollegen von dieser und weiteren Episoden, wenn sie ebenfalls aktiv Fach und Führungskräfte sind und sich für die Themen interessieren. Wir freuen uns immer Bewertung des Podcasts und schaut auch auf Skillbyte Slash Blog vorbeifahre weitere spannende Themen, die wir besprechen. Maurice Es hat eine Menge Spaß gemacht, mit dir heute über das Thema Becker zu sprechen.

Vielen, vielen Dank, dass ich dich zu Gast haben durfte.

Vielen Dank für das angenehme Gespräch.