Hallo allerseits!
Vor einiger Zeit tauchte ich in die Welt des "harten Unternehmertums" ein, und zwar in dem Bereich, der für das Speichern und Sichern von Daten verantwortlich ist. Genauer gesagt, am meisten darin. In dieser Zeit habe ich mehrere Regeln gesammelt, die ich beim Entwerfen oder Warten von Lösungen in diesem Bereich einzuhalten versuche. Einige haben ihre eigenen mit der Entwicklung der Technologie bereits überlebt, andere arbeiten recht gut. Und ich habe beschlossen, sie mit Ihnen zu teilen.
Es wird keine Regel 3-2-1 geben, die oft ohne mich erwähnt wird, sowie einige direkte Techniken für bestimmte Situationen und andere Dinge in der gleichen Richtung. Vielleicht sind dies für die meisten Leser die Grundlagen und Plattitüden. Dies ist nur meine bescheidene Erfahrung und ich hoffe, dass sie jemandem nützlich sein wird. Ich frage nach Katze.
Merkmale der lokalen "Dimensionierung"
Früher oder später müssen mehr Terabyte und / oder IOPS benötigt werden. Und dann beginnt die Dimensionierung. Oft bedeutungslos und gnadenlos. Weil es äußerst selten vorkommt, dass jemand RTO-Anforderungen für die Größenbestimmung festlegt, die normalerweise zur Sicherung vorgelegt werden. Obwohl es eine offensichtliche Voraussetzung für jeden Hardwarekomplex zu sein scheint. Das heißt, Bei der Dimensionierung und Erstellung von Anforderungen für neue Geräte werden aus irgendeinem Grund die Anforderungen des Backup-Systems, das dringend etwas an Ihrer Hardware wiederherstellt, nicht berücksichtigt. Manchmal ist etwas ziemlich groß. Im Allgemeinen wird ein gewisser Spielraum für Produktivität und Platz geschaffen, aber die allererste Datenwiederherstellung zeigt, dass dies für den für dieses Gerät definierten Lebenszyklus nicht ausreicht.
Im letzten Jahr habe ich bereits zweimal eine Situation gesehen, in der der Engpass während der Datenwiederherstellung das Festplattenarray war, auf dem die Wiederherstellung durchgeführt wurde. Sie passen in RTO, aber die Glocke war alarmierend.
Wir haben eine Lösung für den Cluster. Warum benötigen Sie ein Backup ?!
Es ist diese sehr „energetisch“ ausgesprochene Phrase, die ich bei der Kommunikation gehört habe
mit einem Entwickler einer sehr nützlichen Software für ein Unternehmen. Der Entwickler argumentierte, dass eine Sicherung für die Wiederherstellung nicht erforderlich ist, da die Lösung auf einem Cluster bereitgestellt wird. Wenn daher ein Knoten (oder ein Festplattenarray) auf den Standort fällt, wird der Cluster gespeichert. In diesen Fällen wird er zweifellos sparen. Dies ist im Allgemeinen hervorragend, wenn es einige Leute gibt, die bereits in der Entwicklungsphase über Fehlertoleranz nachdenken.
Datenverlust wird jedoch nicht nur durch den Ausfall von Geräten an einem Standort erreicht, und aus irgendeinem Grund wollte der Entwickler dies für einige Zeit nicht verstehen. Infolgedessen wurde die erste Version der Software auf dem Community-DBMS veröffentlicht, dessen Sicherungsmechanik weder die RTO / RPO-Anforderungen noch die SLA des Auftragnehmers erfüllte.
Im Allgemeinen höre ich diesen Satz ziemlich oft über einen Cluster.
Erst dann das!
Einer meiner größten Fehler war, Backup-Objekte als unabhängige Objekte zu betrachten. Hier ist das DBMS, hier ist die Software. Dies ist ein Backup wie dieses, und das ist so. Erst einer, dann noch einer. Und eines Tages konnten wir uns nicht erholen. Genauer gesagt könnten sie es, aber für die wenigen Tage, die für die Behebung von Fehlern in der Datenbank aufgewendet wurden. Und nicht ich habe sie beseitigt, wofür ich mich besonders schäme. Obwohl wir für dieses DBMS einen regulären Sicherungsmechanismus verwendet haben. Bereits auf anderen Systemen getestet.
Von diesem Moment an schiebe ich meine Nase und schüttle den Entwickler / Besitzer des Systems über das Thema, wie man richtig sichert und wiederherstellt. In einem Fall bestand die einzige Möglichkeit zum Erstellen einer funktionierenden Sicherung darin, die Dienste auf 5 Servern vollständig zu stoppen, eine Sicherung zu erstellen und die Dienste zu starten.
Alles wegwerfen?
Oft stoße ich auf Lösungen für DBMS wie MySQL und PostgreSQL. Und noch häufiger stoße ich auf eine Situation, in der der banale Speicherauszug der Datenbank in / tmp als Sicherungsmethode und dann auf einem anderen Medium verwendet wird. Gleichzeitig sind die Systeme, auf denen diese DBMS verwendet werden, für Ausfallzeiten im Falle eines Datenverlusts sehr kritisch und sehr ausgelastet. Ich schweige bereits über Bände.
Aus irgendeinem Grund lesen nur wenige Personen die Dokumentation zu diesen Produkten und wissen nicht, dass es alternative Methoden und Lösungen zum Erstellen von Sicherungen dieser DBMS gibt.
MySQL Enterprise Backup für MySQL und
pg_basebackup (
pg_start_backup, pg_stop_backup ) in PostgreSQL. Oder er weiß es, flog aber aus seinem Kopf. Obwohl diese Lösungen nicht viel komplizierter und schneller sind. Schnellere Sicherung, schnellere Wiederherstellung, schnellerer Test.
Bitte erschieße den Pianisten nicht.
Er gibt sein Bestes.
Oscar Fingal O'Flahertie Wills Wilde