{"id":36393,"date":"2019-10-31T22:11:24","date_gmt":"2019-10-31T19:11:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/failover-nas-gubit-perfektsionizm-i-len\/"},"modified":"2019-10-31T22:11:24","modified_gmt":"2019-10-31T19:11:24","slug":"failover-nas-gubit-perfektsionizm-i-len","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","title":{"rendered":"Failover: Perfektionismus und... Faulheit bringen uns um.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Im Sommer sinken traditionell sowohl die Kundenaktivit\u00e4t als auch die Intensit\u00e4t der Ver\u00e4nderungen in der Infrastruktur von Webprojekten, sagt uns Kapit\u00e4n Offensichtlich. Das liegt einfach daran, dass selbst ITler gelegentlich in Urlaub gehen. Und CTOs ebenfalls. Das macht die Situation f\u00fcr diejenigen, die an ihrem Posten bleiben, schwieriger, aber darum geht es hier nicht: Vielleicht ist genau deshalb der Sommer die beste Zeit, um in Ruhe \u00fcber das bestehende Backup-System nachzudenken und einen Plan zur Verbesserung aufzustellen. Dabei kann Ihnen die Erfahrung von Egor Andreev aus AdminDivision<\/a><\/noindex>, die er auf der Konferenz erz\u00e4hlt hat, hilfreich sein. Uptime day<\/a><\/noindex>.<\/i><\/p>\n

Beim Bau von Backup-Standorten und der Implementierung von Reservesystemen gibt es verschiedene Fallen, in die man tappen kann. Und es ist absolut unerl\u00e4sslich, diese zu meiden. Perfektionismus und\u2026 Faulheit verderben uns dabei, wie in vielen anderen Bereichen auch. Wir versuchen, alles perfekt zu machen, aber das ist nicht notwendig! Es gen\u00fcgt, bestimmte Dinge gut zu machen und sie bis zur Vollendung zu bringen, damit sie ordnungsgem\u00e4\u00df funktionieren. <\/p>\n

Failover ist kein Spa\u00df oder ein Gimmick; es ist ein ernstes Werkzeug, das eine einzige Aufgabe hat \u2013 die Ausfallzeiten zu minimieren, damit der Service und das Unternehmen weniger Geld verlieren. Bei allen Backup-Methoden sollten wir im folgenden Kontext denken: Wo stecken die Kosten?<\/p>\n

\"Failover:
\n<\/a><\/noindex>
\nDie erste Falle<\/b>: Wenn wir gro\u00dfe, zuverl\u00e4ssige Systeme aufbauen und Backups implementieren, verringern wir die Zahl der Ausf\u00e4lle. Das ist ein gef\u00e4hrlicher Irrglaube. Tats\u00e4chlich erh\u00f6ht sich wahrscheinlich die Anzahl der Ausf\u00e4lle, wenn wir Backup-Strategien implementieren. Wenn wir alles richtig machen, reduzieren wir insgesamt die Ausfallzeiten. Es wird zwar mehr Ausf\u00e4lle geben, aber sie treten mit geringeren Kosten auf. Was bedeutet Backup? \u2013 Es ist eine Komplexit\u00e4tssteigerung des Systems. Jede Komplexit\u00e4t ist problematisch: Wir haben mehr Schrauben, mehr Zahnr\u00e4der, einfach mehr Bestandteile \u2013 und damit steigt die Wahrscheinlichkeit eines Ausfalls. Und sie werden tats\u00e4chlich ausfallen. Und die Ausf\u00e4lle werden h\u00e4ufiger vorkommen. Ein einfaches Beispiel: Angenommen, wir haben eine Website mit PHP und MySQL. Und wir m\u00fcssen sie dringend absichern. <\/p>\n

Nun, wir nehmen die zweite Plattform und bauen ein identisches System auf. Die Komplexit\u00e4t verdoppelt sich \u2013 wir haben nun zwei Entit\u00e4ten. Dar\u00fcber hinaus f\u00fcgen wir eine bestimmte Logik f\u00fcr den Datentransfer von einer Plattform zur anderen hinzu \u2013 das hei\u00dft, Datenreplikation, Kopieren von statischen Inhalten und so weiter. Diese Replikationslogik ist in der Regel sehr komplex, sodass die Gesamtsystemkomplexit\u00e4t nicht nur das Zwei- sondern sogar das Drei-, F\u00fcnf- oder Zehnfache betragen kann. <\/p>\n

Die zweite Falle<\/b>: Wenn wir wirklich gro\u00dfe, komplexe Systeme bauen, tr\u00e4umen wir davon, was wir am Ende haben wollen. Voil\u00e0: Wir streben nach einem superzuverl\u00e4ssigen System, das ohne Ausfallzeiten arbeitet, innerhalb von einer halben Sekunde (oder besser noch instantan) umschaltet, und beginnen, diese Tr\u00e4ume in die Realit\u00e4t umzusetzen. Aber hier gibt es einen Haken: Je geringer die gew\u00fcnschte Umschaltzeit, desto komplizierter wird die Logik des Systems. Je komplexer wir diese Logik gestalten m\u00fcssen, desto h\u00e4ufiger wird das System ausfallen. Und man k\u00f6nnte in eine sehr unangenehme Situation geraten: Wir versuchen mit aller Macht, die Ausfallzeiten zu reduzieren, w\u00e4hrend wir tats\u00e4chlich alles komplizierter machen, und wenn etwas schiefgeht, sind die Ausfallzeiten am Ende l\u00e4nger. Oft kommt man dann zu dem Gedanken: Ach... es w\u00e4re besser gewesen, keinen redundanten Aufbau zu haben. Es w\u00e4re besser, wenn eins funktionierte und mit bekannten Ausfallzeiten. <\/p>\n

Wie kann man dem begegnen? Man muss aufh\u00f6ren, sich selbst zu bel\u00fcgen, aufh\u00f6ren, sich einzureden, dass wir hier ein Raumschiff bauen werden, und stattdessen realistisch einsch\u00e4tzen, wie lange das Projekt in Anspruch nehmen kann. Und f\u00fcr diese maximale Zeit werden wir bestimmen, welche Methoden wir tats\u00e4chlich nutzen, um die Zuverl\u00e4ssigkeit unseres Systems zu erh\u00f6hen. <\/p>\n

\"Failover:
\n
\nEs ist h\u00f6chste Zeit f\u00fcr Geschichten aus dem Leben... <\/p>\n

Beispiel Nummer eins<\/h4>\n

\nStellen Sie sich eine Visitenkarte f\u00fcr das Rohrleitungswerk Nr. 1 in der Stadt N vor. Dort steht in gro\u00dfen Buchstaben \u2013 ROHRLEITUNGSWERK Nr. 1. Darunter ein Slogan: \u201eUnsere Rohre sind die rundesten Rohre in N\u201c. Und darunter die Telefonnummer des Gesch\u00e4ftsf\u00fchrers und sein Name. Wir verstehen, dass wir reservieren m\u00fcssen \u2013 das ist eine sehr wichtige Angelegenheit! Wir beginnen herauszufinden, aus was es besteht. HTML-Static \u2013 das hei\u00dft, ein paar Bilder, wo der Gesch\u00e4ftsf\u00fchrer am Tisch in der Sauna mit seinem Partner irgendein Gesch\u00e4ft bespricht. Wir beginnen \u00fcber die Ausfallzeit nachzudenken. Mir kommt in den Sinn: Man braucht nicht l\u00e4nger als f\u00fcnf Minuten dort zu liegen. Und hier stellt sich die Frage: Wie viele Verk\u00e4ufe gab es \u00fcberhaupt \u00fcber unsere Website? Wie viele? Was hei\u00dft \u201enull\u201c? Es bedeutet vielleicht: denn alle vier Gesch\u00e4fte im letzten Jahr hat der Gesch\u00e4ftsf\u00fchrer am gleichen Tisch, mit denselben Menschen gemacht, mit denen sie in die Sauna gehen und am Tisch sitzen. Und wir verstehen, dass es nichts Schlimmes sein wird, selbst wenn die Website einen Tag lang ruhig bleibt. <\/p>\n

Basierend auf den Vorgaben haben wir einen Tag Zeit, um diese Geschichte umzusetzen. Wir fangen an, \u00fcber das Sicherungssystem nachzudenken. Dabei w\u00e4hlen wir das ideale Backup-Schema f\u00fcr dieses Beispiel aus: In unserem Fall verwenden wir keine Sicherung. Ein erfahrener Administrator kann dieses ganze System in einer halben Stunde mit ein paar Pausen aufsetzen. Einen Webserver installieren, Dateien bereitstellen \u2013 das ist alles. Es wird funktionieren. Es gibt nichts, was \u00fcberwacht werden muss, und nichts, dem besondere Aufmerksamkeit geschenkt werden muss. Die Schlussfolgerung aus dem ersten Beispiel ist daher recht offensichtlich: Dienste, f\u00fcr die keine Sicherung erforderlich ist, brauchen auch keine Backup-L\u00f6sungen.<\/p>\n

\"Failover:
\n<\/p>\n

Beispiel Nummer zwei<\/h4>\n

\nUnternehmensblog: Hier schreiben speziell geschulte Mitarbeiter Neuigkeiten, zum Beispiel \u00fcber unsere Teilnahme an einer bestimmten Messe oder die Einf\u00fchrung eines neuen Produkts. Nehmen wir an, es handelt sich um ein Standard-PHP mit WordPress, einer kleinen Datenbank und ein wenig Statischer Seite. Nat\u00fcrlich kommt einem wieder der Gedanke, dass man auf keinen Fall unt\u00e4tig bleiben sollte \u2013 \u2018nicht l\u00e4nger als f\u00fcnf Minuten!\u2019, und solche Dinge. Doch lassen Sie uns weiterdenken. Was macht dieser Blog? Er erh\u00e4lt Traffic von Yandex und Google aus verschiedenen Suchanfragen, organisch. Toll. Aber wie sind die Verk\u00e4ufe damit verbunden? Die Erkenntnis: nicht wirklich. Der Werbetraffic geht auf die Hauptwebsite, die auf einem anderen Server l\u00e4uft. Jetzt \u00fcberlegen wir, wie wir die Blog-Verf\u00fcgbarkeit sicherstellen k\u00f6nnen. Idealerweise sollte man ihn innerhalb von ein paar Stunden wieder hochfahren k\u00f6nnen, und es w\u00e4re gut, darauf vorbereitet zu sein. Es w\u00e4re sinnvoll, in einem anderen Rechenzentrum einen Server zu bekommen, die Umgebung zusammenzustellen, also Webserver, PHP, WordPress, MySQL, und ihn als schlummernd bereit zu halten. In dem Moment, in dem wir erkennen, dass etwas kaputt ist, m\u00fcssen wir zwei Dinge tun \u2013 ein MySQL-Dump von 50 MB zur\u00fcckspielen, das dauert nur eine Minute, und dann einige Bilder aus dem Backup wiederherstellen. Das ist auch nicht besonders aufwendig. Auf diese Weise ist die gesamte L\u00f6sung in einer halben Stunde wieder einsatzbereit. Keine Replikationen oder, Gott bewahre, automatischer Failover. Fazit: Was wir schnell aus dem Backup wiederherstellen k\u00f6nnen, muss nicht reserviert werden. <\/p>\n

\"Failover:
\n<\/p>\n

Beispiel Nummer drei, etwas komplexer<\/h4>\n

\nOnline-Shop. Ein leicht modifiziertes PHP mit Open Heart, MySQL mit einer soliden Datenbasis. Relativ viel Statische (schlie\u00dflich hat der Online-Shop sch\u00f6ne HD-Bilder und all das), Redis f\u00fcr Sessions und Elasticsearch f\u00fcr die Suche. Wir beginnen, \u00fcber Ausfallzeiten nachzudenken. Und hier ist es nat\u00fcrlich klar, dass ein Tag ohne Internet-Shop nicht schmerzlos vergehen kann. Denn je l\u00e4nger er offline ist, desto mehr Geld verlieren wir. Wir m\u00fcssen uns beeilen. Aber wie viel? Ich denke, wenn wir eine Stunde offline sind, wird es niemand verr\u00fcckt machen. Ja, wir verlieren etwas, aber wenn wir uns anstrengen, wird es nur schlimmer. Lassen Sie uns den Zeitrahmen f\u00fcr den akzeptablen Ausfall definieren, der pro Stunde zul\u00e4ssig ist.<\/p>\n

Wie kann man das alles reservieren? Eine Maschine ist in jedem Fall erforderlich: Eine Stunde ist ziemlich wenig. MySQL: Hier ist eine Replikation notwendig, eine Live-Replikation, da 100 GB in einer Stunde wahrscheinlich nicht in den Dump passen. Statische Dateien, Bilder: Auch hier k\u00f6nnen 500 GB in einer Stunde m\u00f6glicherweise nicht \u00fcbertragen werden. Daher ist es besser, die Bilder sofort zu kopieren. Redis: Hier wird es interessanter. In Redis liegen die Sitzungen \u2014 einfach so l\u00f6schen k\u00f6nnen wir ihn nicht. Denn das w\u00e4re nicht ideal: Alle Benutzer w\u00e4ren abgemeldet, ihre Warenk\u00f6rbe w\u00e4ren leer, und so weiter. Die Leute m\u00fcssten ihren Benutzernamen und ihr Passwort erneut eingeben, und viele k\u00f6nnten abspringen und ihren Kauf nicht abschlie\u00dfen. Auch hier w\u00fcrde die Conversion sinken. Andererseits ist Redis genau aktuell, mit den zuletzt angemeldeten Benutzern, wahrscheinlich auch nicht erforderlich. Ein guter Kompromiss w\u00e4re, Redis zu nehmen und aus einem Backup wiederherzustellen, das von gestern oder, wenn es st\u00fcndlich gemacht wird, eine Stunde alt ist. Gl\u00fccklicherweise ist die Wiederherstellung aus dem Backup nur das Kopieren einer Datei. Die interessanteste Geschichte ist Elasticsearch. Wer hat jemals die MySQL-Replikation eingerichtet? Wer hat jemals die Elasticsearch-Replikation eingerichtet? Und bei wem hat sie danach normal funktioniert? Ich wollte darauf hinaus: Wir sehen in unserem System eine gewisse Entit\u00e4t. Sie scheint n\u00fctzlich zu sein \u2014 aber sie ist komplex.
\nEs ist kompliziert, weil unsere Ingenieure keine Erfahrung damit haben. Entweder gibt es negative Erfahrungen oder wir erkennen, dass dies eine recht neue Technologie mit ihren Eigenheiten oder Unzul\u00e4nglichkeiten ist. Dann denken wir... Na ja, Elasticsearch ist auch gro\u00df, die Wiederherstellung aus dem Backup dauert ebenfalls lange, was tun? Wir verstehen, dass Elasticsearch in unserem Fall f\u00fcr die Suche verwendet wird. Und wie verkauft unser Online-Shop? Wir gehen zu den Marketingspezialisten und fragen, woher die Leute kommen. Sie antworten: '90% kommen direkt von Yandex.Markt zur Produktseite.' Und entweder kaufen sie oder nicht. Folglich ben\u00f6tigt nur 10% der Nutzer die Suche. Und die Replikation von Elasticsearch aufrechtzuerhalten, vor allem zwischen verschiedenen Rechenzentren in unterschiedlichen Regionen, hat wirklich viele Details. Was ist der Ausweg? Wir nehmen Elasticsearch auf einer reservierten Plattform und machen nichts damit. Wenn es l\u00e4nger dauert, k\u00f6nnten wir es irgendwann sp\u00e4ter aktivieren, aber das ist ungewiss. Tats\u00e4chlich bleibt die Schlussfolgerung im Gro\u00dfen und Ganzen wie zuvor: Dienste, die keinen Einfluss auf die Ums\u00e4tze haben, reservieren wir erneut nicht. Damit das System einfacher bleibt.<\/p>\n

\"Failover:
\n<\/p>\n

Beispiel Nummer vier, noch komplexer.<\/h4>\n

\nIntegrator: Blumenverkauf, Taxi-Bestellungen, Warenverkauf \u2013 kurz gesagt, alles M\u00f6gliche. Eine ernsthafte Angelegenheit, die 24\/7 f\u00fcr eine gro\u00dfe Anzahl von Nutzern verf\u00fcgbar ist. Mit einem vollst\u00e4ndigen und interessanten Technologie-Stack, der spannende Datenbanken, L\u00f6sungen und hohe Belastungen umfasst. Und vor allem sollte es nicht l\u00e4nger als f\u00fcnf Minuten liegen, denn das ist problematisch. Es liegt nicht nur daran, dass die Leute nicht kaufen, sondern weil sie sehen, dass das System nicht funktioniert, frustriert sind und m\u00f6glicherweise beim n\u00e4chsten Mal nicht zur\u00fcckkommen. <\/p>\n

Okay. F\u00fcnf Minuten. Was machen wir damit? In diesem Fall bauen wir ernsthaft, mit vollem Einsatz, eine echte Backup-Plattform auf, mit der Replikation von allem und jedem, und vielleicht automatisieren wir auch so viel wie m\u00f6glich, um auf diese Plattform zu wechseln. Und zus\u00e4tzlich dazu d\u00fcrfen wir eine wichtige Sache nicht vergessen: tats\u00e4chlich ein Regelwerk f\u00fcr den Wechsel zu schreiben. Das Regelwerk kann sehr einfach sein, auch wenn alles automatisiert ist. Etwas in der Art von: \u201eDieses Ansible-Szenario ausf\u00fchren\u201c, \u201eIn Route 53 die entsprechende Option aktivieren\u201c und so weiter \u2013 es sollte jedoch eine pr\u00e4zise Liste von Ma\u00dfnahmen sein. <\/p>\n

Eigentlich ist alles klar. Die Umstellung der Replikation ist eine triviale Aufgabe, oder sie geschieht automatisch. Das Umstellen des Domainnamens im DNS geh\u00f6rt ebenfalls dazu. Das Problem ist, dass bei einem Ausfall eines solchen Projekts Panik ausbricht, und selbst die erfahrensten Administratoren k\u00f6nnen davon betroffen sein. Ohne eine klare Anleitung wie \"\u00d6ffnen Sie das Terminal, gehen Sie hierher, die Adresse unseres Servers ist nach wie vor so und so\" ist es schwierig, innerhalb von f\u00fcnf Minuten eine Wiederbelebung durchzuf\u00fchren. Zudem ist es einfach, \u00c4nderungen in der Infrastruktur zu dokumentieren, wenn wir diese Richtlinie nutzen, beispielsweise um entsprechende Anpassungen an der Regel vorzunehmen.
\nWenn jedoch das Backup-System sehr komplex ist und wir in einem bestimmten Moment einen Fehler gemacht haben, k\u00f6nnten wir auch unsere Backup-Plattform au\u00dfer Betrieb setzen und die Daten auf beiden Plattformen verlieren \u2013 das w\u00e4re wirklich traurig. <\/p>\n

\"Failover:
\n<\/p>\n

Beispiel Nummer f\u00fcnf, v\u00f6lliger Hardcore.<\/h4>\n

\nEin internationaler Service mit Hunderten von Millionen Nutzern weltweit. Alle Zeitzonen, die es gibt, Highload auf maximalem Niveau \u2013 Ausfallzeiten sind einfach keine Option. Eine Minute und schon ist die Stimmung im Keller. Was tun? Volle Reservierung ist die Antwort. Wir haben alles umgesetzt, was im vorherigen Beispiel angesprochen wurde, und sogar noch ein bisschen mehr. Eine ideale Welt, und unsere Infrastruktur entspricht in allen Aspekten dem DevOps-Prinzip IaaC. Das bedeutet, alles ist in Git und man muss nur den Knopf dr\u00fccken. <\/p>\n

Was fehlt? Nur eines \u2013 Schulungen. Ohne die geht es nicht. Es scheint, als w\u00e4re alles perfekt bei uns, wir haben wirklich alles im Griff. Wir dr\u00fccken den Knopf, alles geschieht. Selbst wenn es so w\u00e4re \u2013 was wir verstehen, dass es so nicht ist \u2013 interagiert unser System mit anderen Systemen. Zum Beispiel DNS von Route 53, S3-Speicher, Integration mit verschiedenen APIs. Alles in diesem theoretischen Experiment vorherzusehen, ist unm\u00f6glich. Und solange wir den Schalter nicht bewusst umlegen, werden wir nicht wissen, ob es funktioniert oder nicht. <\/p>\n

\"Failover:
\n
\nDas w\u00e4re es wahrscheinlich. Seien Sie nicht nachl\u00e4ssig, aber \u00fcbertreiben Sie es auch nicht. M\u00f6ge die Verf\u00fcgbarkeit mit Ihnen sein!
\n
Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041b\u0435\u0442\u043e\u043c \u0442\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u0441\u043d\u0438\u0436\u0430\u0435\u0442\u0441\u044f \u0438 \u043f\u043e\u043a\u0443\u043f\u0430\u0442\u0435\u043b\u044c\u0441\u043a\u0430\u044f \u0430\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u044c, \u0438 \u0438\u043d\u0442\u0435\u043d\u0441\u0438\u0432\u043d\u043e\u0441\u0442\u044c \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b \u0432\u0435\u0431-\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u0433\u043e\u0432\u043e\u0440\u0438\u0442 \u043d\u0430\u043c \u041a\u0430\u043f\u0438\u0442\u0430\u043d \u041e\u0447\u0435\u0432\u0438\u0434\u043d\u043e\u0441\u0442\u044c. \u041f\u0440\u043e\u0441\u0442\u043e \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u0434\u0430\u0436\u0435 \u0430\u0439\u0442\u0438\u0448\u043d\u0438\u043a\u0438, \u0441\u043b\u0443\u0447\u0430\u0435\u0442\u0441\u044f, \u0445\u043e\u0434\u044f\u0442 \u0432 \u043e\u0442\u043f\u0443\u0441\u043a. \u0418 C\u0422\u041e \u0442\u043e\u0436\u0435. \u0422\u0435\u043c \u0442\u044f\u0436\u0435\u043b\u0435\u0435 \u0442\u0435\u043c, \u043a\u0442\u043e \u043e\u0441\u0442\u0430\u0451\u0442\u0441\u044f \u043d\u0430 \u043f\u043e\u0441\u0442\u0443, \u043d\u043e \u0441\u0435\u0439\u0447\u0430\u0441 \u043d\u0435 \u043e\u0431 \u044d\u0442\u043e\u043c: \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e, \u0438\u043c\u0435\u043d\u043d\u043e \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u043b\u0435\u0442\u043e \u2014 \u043b\u0443\u0447\u0448\u0438\u0439 \u043f\u0435\u0440\u0438\u043e\u0434 \u0434\u043b\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u043d\u0435 \u0442\u043e\u0440\u043e\u043f\u044f\u0441\u044c \u043e\u0431\u0434\u0443\u043c\u0430\u0442\u044c \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0443\u044e \u0441\u0445\u0435\u043c\u0443 \u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27235,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36393","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Failover: Perfektionismus und\u2026 Faulheit bringen uns um | ProHoster","description":"Im Sommer sinken traditionell sowohl die Kaufaktivit\u00e4t als auch die Intensit\u00e4t der Ver\u00e4nderung in der Infrastruktur von Webprojekten, erkl\u00e4rt uns Kapit\u00e4n Offensichtlich. Das liegt einfach daran, dass selbst IT-Profis, hin und wieder, Urlaub nehmen. Und das gilt auch f\u00fcr CTOs. Umso schwieriger wird es f\u00fcr die, die an ihrem Posten bleiben, aber darum geht es jetzt nicht: Vielleicht ist genau deshalb der Sommer die beste Zeit, um in Ruhe \u00fcber die bestehende Backup-Strategie nachzudenken.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Failover: \u043d\u0430\u0441 \u0433\u0443\u0431\u0438\u0442 \u043f\u0435\u0440\u0444\u0435\u043a\u0446\u0438\u043e\u043d\u0438\u0437\u043c \u0438\u2026 \u043b\u0435\u043d\u044c | ProHoster","og:description":"\u041b\u0435\u0442\u043e\u043c \u0442\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u0441\u043d\u0438\u0436\u0430\u0435\u0442\u0441\u044f \u0438 \u043f\u043e\u043a\u0443\u043f\u0430\u0442\u0435\u043b\u044c\u0441\u043a\u0430\u044f \u0430\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u044c, \u0438 \u0438\u043d\u0442\u0435\u043d\u0441\u0438\u0432\u043d\u043e\u0441\u0442\u044c \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b \u0432\u0435\u0431-\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u0433\u043e\u0432\u043e\u0440\u0438\u0442 \u043d\u0430\u043c \u041a\u0430\u043f\u0438\u0442\u0430\u043d \u041e\u0447\u0435\u0432\u0438\u0434\u043d\u043e\u0441\u0442\u044c. \u041f\u0440\u043e\u0441\u0442\u043e \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u0434\u0430\u0436\u0435 \u0430\u0439\u0442\u0438\u0448\u043d\u0438\u043a\u0438, \u0441\u043b\u0443\u0447\u0430\u0435\u0442\u0441\u044f, \u0445\u043e\u0434\u044f\u0442 \u0432 \u043e\u0442\u043f\u0443\u0441\u043a. \u0418 C\u0422\u041e \u0442\u043e\u0436\u0435. \u0422\u0435\u043c \u0442\u044f\u0436\u0435\u043b\u0435\u0435 \u0442\u0435\u043c, \u043a\u0442\u043e \u043e\u0441\u0442\u0430\u0451\u0442\u0441\u044f \u043d\u0430 \u043f\u043e\u0441\u0442\u0443, \u043d\u043e \u0441\u0435\u0439\u0447\u0430\u0441 \u043d\u0435 \u043e\u0431 \u044d\u0442\u043e\u043c: \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e, \u0438\u043c\u0435\u043d\u043d\u043e \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u043b\u0435\u0442\u043e \u2014 \u043b\u0443\u0447\u0448\u0438\u0439 \u043f\u0435\u0440\u0438\u043e\u0434 \u0434\u043b\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u043d\u0435 \u0442\u043e\u0440\u043e\u043f\u044f\u0441\u044c \u043e\u0431\u0434\u0443\u043c\u0430\u0442\u044c \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0443\u044e \u0441\u0445\u0435\u043c\u0443 \u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:11:24+00:00","article:modified_time":"2019-10-31T19:11:24+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36393","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 03:07:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:45:36","updated":"2026-01-22 03:07:19"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/36393","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=36393"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/36393\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/27235"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=36393"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=36393"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=36393"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}