Backup Teil 7: Schlussfolgerungen

Dieser Hinweis schließt den Sicherungszyklus ab. Es wird über die logische Organisation eines dedizierten Servers (oder VPS) gesprochen, der für die Sicherung geeignet ist, und es wird auch die Möglichkeit geboten, einen Server im Falle eines Unfalls ohne Ausfallzeit schnell aus einer Sicherung wiederherzustellen.

Ausgangsdaten

Ein dedizierter Server verfügt meistens über mindestens zwei Festplatten, die zum Organisieren eines RAID-Arrays der ersten Ebene (Spiegelung) verwendet werden. Dies ist erforderlich, um den Server fortsetzen zu können, wenn ein Laufwerk ausfällt. Wenn es sich um einen normalen dedizierten Server handelt, kann auf SSDs ein separater Hardware-RAID-Controller mit aktiver Caching-Technologie vorhanden sein, sodass zusätzlich zu normalen Festplatten eine oder mehrere SSDs angeschlossen werden können. Manchmal werden dedizierte Server angeboten, auf denen nur SATADOM von lokalen Festplatten (kleine Festplatten, strukturell - ein an den SATA-Anschluss angeschlossenes USB-Flash-Laufwerk) oder sogar ein gewöhnliches kleines (8-16 GB) USB-Flash-Laufwerk, das an einen speziellen internen Anschluss angeschlossen ist, vorhanden ist und Daten aus dem Speichersystem entnommen werden über ein dediziertes Speichernetzwerk (Ethernet 10G, FC usw.) verbunden, und es gibt dedizierte Server, die direkt vom Speichersystem geladen werden. Ich werde solche Optionen nicht in Betracht ziehen, da in solchen Fällen die Aufgabe des reibungslosen Sicherns des Servers an den Spezialisten übergeht, der das Speichersystem wartet. In der Regel gibt es verschiedene proprietäre Technologien zum Erstellen von Status-Snapshots, integrierter Deduplizierung und anderen Freuden des Systemadministrators, die in den vorherigen Teilen dieser Serie erläutert wurden. Das Volumen des Festplattenarrays eines dedizierten Servers kann abhängig von der Anzahl und dem Volumen der mit dem Server verbundenen Festplatten mehrere zehn Terabyte erreichen. Im Fall von VPS sind die Volumes bescheidener: normalerweise nicht mehr als 100 GB (aber es gibt mehr), und die Tarife für solche VPS können leicht teurer sein als die billigsten dedizierten Server vom selben Hoster. VPS hat meistens ein Laufwerk, da sich darunter der Speicher befindet (oder etwas Hyperkonvergiertes). Manchmal hat VPS mehrere Festplatten mit unterschiedlichen Eigenschaften für unterschiedliche Zwecke:

• kleines System - um das Betriebssystem zu installieren;
• groß - Speicherung von Benutzerdaten.

Bei der Neuinstallation des Systems über das Bedienfeld wird die Festplatte mit den Benutzerdaten nicht überschrieben, sondern das System wird vollständig neu geladen. Im Fall von VPS kann der Host auch eine Schaltfläche anbieten, die eine Momentaufnahme des Status des VPS (oder der Festplatte) erstellt. Wenn Sie jedoch Ihr Betriebssystem installieren oder vergessen, den gewünschten Dienst innerhalb des VPS zu aktivieren, gehen möglicherweise noch einige Daten verloren. Zusätzlich zu der Schaltfläche wird normalerweise ein Datenspeicherungsdienst angeboten, der meist sehr eingeschränkt ist. Normalerweise ist dies ein Konto mit FTP- oder SFTP-Zugriff, manchmal zusammen mit SSH, mit einer abgeschnittenen Shell (z. B. rbash) oder einer Einschränkung beim Ausführen von Befehlen über autorisierte_Tasten (über ForcedCommand).

Ein dedizierter Server ist über zwei Ports mit einer Geschwindigkeit von 1 Gbit / s mit dem Netzwerk verbunden. Manchmal können es Karten mit einer Geschwindigkeit von 10 Gbit / s sein. VPS verfügt häufig über eine Netzwerkschnittstelle. In den meisten Fällen beschränken Rechenzentren nicht die Geschwindigkeit des Netzwerks innerhalb des Rechenzentrums, sondern die Geschwindigkeit des Internetzugangs.

Eine typische Last eines solchen dedizierten Servers oder VPS ist ein Webserver, eine Datenbank oder ein Anwendungsserver. Manchmal können verschiedene zusätzliche Supportdienste installiert werden, einschließlich für einen Webserver oder eine Datenbank: Suchmaschine, Mailsystem usw.

Ein speziell vorbereiteter Server dient als Speicherplatz für Sicherungskopien. Dies wird nachstehend ausführlicher beschrieben.

Organisation der logischen Festplatte

Wenn es einen RAID-Controller oder einen VPS mit einer Festplatte gibt und es auch keine besonderen Einstellungen für das Festplattensubsystem gibt (z. B. eine separate schnelle Festplatte für die Datenbank), wird der gesamte freie Speicherplatz wie folgt aufgeteilt: Eine Partition wird erstellt, eine Gruppe von LVM-Volumes wird darüber erstellt Es werden mehrere Volumes erstellt: 2 kleine Volumes derselben Größe, die als Root-Dateisystem verwendet werden (sie werden abwechselnd mit Updates geändert, um ein schnelles Rollback zu ermöglichen, die Idee wird von der Calculate Linux-Distribution ausspioniert), ein anderes ist für die Swap-Partition, der Rest ist kostenlos Dieser Bereich ist in kleine Volumes unterteilt, die als Root-Dateisystem für vollständige Container, Festplatten für virtuelle Maschinen, Dateisysteme für Konten in / home (jedes Konto verfügt über ein eigenes Dateisystem) und Dateisysteme für Anwendungscontainer verwendet werden.

Wichtiger Hinweis: Die Volumes müssen vollständig autark sein, d. H. sollte nicht sowohl voneinander als auch vom Root-Dateisystem abhängen. Bei virtuellen Maschinen oder Containern wird dieser Punkt automatisch eingehalten. Wenn es sich um Anwendungscontainer oder Home-Verzeichnisse handelt, sollten Sie darüber nachdenken, die Konfigurationsdateien des Webservers und anderer Dienste so zu trennen, dass die Abhängigkeiten der Volumes untereinander maximal entfernt werden. Beispielsweise wird jede Site auf einem eigenen Benutzer ausgeführt, die Konfigurationsdateien der Site befinden sich im Ausgangsverzeichnis des Benutzers. In den Webservereinstellungen sind die Konfigurationsdateien der Site nicht über /etc/nginx/conf.d/ .conf enthalten, sondern beispielsweise über / home / /configs/nginx/*.conf

Wenn mehrere Festplatten vorhanden sind, können Sie ein Software-RAID erstellen (und das Caching auf SSD konfigurieren, wenn Bedarf und Gelegenheit dazu bestehen), auf dem LVM gemäß den oben vorgeschlagenen Regeln zusammengestellt werden kann. Auch in diesem Fall können Sie ZFS oder BtrFS verwenden. Hier sollten Sie jedoch einige Male darüber nachdenken: Beide erfordern einen viel ernsthafteren Umgang mit Ressourcen. Außerdem wird ZFS nicht mit dem Linux-Kernel geliefert.

Unabhängig vom verwendeten Schema lohnt es sich immer, die ungefähre Geschwindigkeit des Schreibens von Änderungen auf Datenträgern im Voraus zu schätzen und dann die Größe des freien Speicherplatzes zu berechnen, der für die Erstellung von Bildern reserviert wird. Wenn unser Server beispielsweise Daten mit einer Geschwindigkeit von 10 Megabyte pro Sekunde schreibt und die Größe des gesamten Datenarrays 10 Terabyte beträgt, kann die Synchronisierungszeit bis zu einem Tag (22 Stunden - dieser Betrag wird über das Netzwerk mit 1 Gbit / s übertragen) - es lohnt sich, etwa zu reservieren 800 GB In Wirklichkeit ist die Anzahl geringer, Sie können sie sicher durch die Anzahl der logischen Volumes teilen.

Backup Storage Server-Gerät

Der Hauptunterschied zwischen dem Server zum Speichern von Backups besteht in großen, billigen und relativ langsamen Festplatten. Da moderne Festplatten die Grenze von 10 TB auf einer Festplatte bereits überschritten haben, müssen Dateisysteme oder RAID mit Prüfsummen verwendet werden, da die zweite Festplatte während des Wiederherstellens des Arrays oder der Wiederherstellung des Dateisystems (mehrere Tage!) Aufgrund einer erhöhten Auslastung ausfallen kann. Auf Festplatten mit einer Kapazität von bis zu 1 TB war dies nicht so empfindlich. Zur Vereinfachung der Beschreibung gehe ich davon aus, dass der Speicherplatz in zwei Teile von ungefähr derselben Größe unterteilt ist (wiederum beispielsweise mit LVM):

• Volumes, die den Servern entsprechen, die zum Speichern von Benutzerdaten verwendet werden (die zuletzt zur Überprüfung erstellte Sicherung wird für sie bereitgestellt);
• Volumes, die als BorgBackup-Repositorys verwendet werden (Daten für Backups werden direkt hier abgerufen).

Das Funktionsprinzip besteht darin, dass für jeden Server unter dem BorgBackup-Repository separate Volumes erstellt werden, auf denen die Daten von den Kampfservern gespeichert werden. Repositorys arbeiten im Nur-Hinzufügen-Modus, wodurch die Möglichkeit des absichtlichen Löschens von Daten und aufgrund der Deduplizierung und regelmäßigen Bereinigung von Repositorys aus alten Sicherungen ausgeschlossen wird (es gibt jährliche Kopien, monatlich für das letzte Jahr, wöchentlich für den letzten Monat, täglich für die letzte Woche, möglicherweise speziell Fälle - stündlich für den letzten Tag: insgesamt 24 + 7 + 4 + 12 + jährlich - ungefähr 50 Kopien für jeden Server).
In den BorgBackup-Repositorys ist nur der Add-Modus nicht aktiviert. Stattdessen wird ForcedCommand in .ssh / authorized_keys mit ungefähr dem folgenden Plan verwendet:

from=" ",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA....... 

Ein Skript-Wrapper wird über dem angegebenen Pfad über borg platziert, der zusätzlich zum Starten der Binärdatei mit den Parametern den Prozess der Wiederherstellung der Sicherung startet, nachdem die Daten entfernt wurden. Zu diesem Zweck erstellt das Wrapper-Skript eine Tag-Datei neben dem entsprechenden Repository. Die letzte Sicherung, die nach dem Hochladen der Daten durchgeführt wurde, wird automatisch auf dem entsprechenden logischen Volume wiederhergestellt.

Mit diesem Design können Sie unnötige Sicherungen regelmäßig bereinigen und Battle Server können auch nichts auf dem Sicherungsspeicherserver löschen.

Sicherungsprozess

Der Initiator der Sicherung ist der dedizierte Server selbst oder VPS, da ein solches Schema mehr Kontrolle über den Sicherungsprozess von diesem Server bietet. Zunächst wird eine Momentaufnahme des Status des aktiven Root-Dateisystems erstellt, die mithilfe von BorgBackup bereitgestellt und auf den Sicherungsspeicherserver hochgeladen wird. Nach Abschluss der Datenerfassung wird das Bild abgemeldet und gelöscht.

Wenn eine kleine Datenbank vorhanden ist (bis zu 1 GB für jeden Standort), wird ein Datenbankspeicherauszug erstellt, der auf dem entsprechenden logischen Datenträger gespeichert wird, auf dem sich die restlichen Daten desselben Standorts befinden, sodass der Speicherauszug jedoch nicht über den Webserver zugänglich ist. Wenn die Datenbanken groß sind, sollten Sie ein "heißes" Data Mining konfigurieren, z. B. mit xtrabackup für MySQL oder WAL mit archive_command in PostgreSQL. In diesem Fall wird die Datenbank getrennt von diesen Sites wiederhergestellt.

Wenn Container oder virtuelle Maschinen verwendet werden, sollten Sie qemu-guest-agent, CRIU oder andere erforderliche Technologien konfigurieren. In anderen Fällen werden zusätzliche Einstellungen meistens nicht benötigt. Erstellen Sie einfach Snapshots von logischen Volumes, die dann ähnlich wie ein Snapshot des Root-Dateisystems verarbeitet werden. Nach dem Aufnehmen der Daten werden die Bilder gelöscht.

Weitere Arbeiten werden am Backup-Speicherserver durchgeführt:

• Die letzte in jedem Repository durchgeführte Sicherung wird überprüft.
• sucht nach einer Tag-Datei, die angibt, dass der Datenerfassungsprozess abgeschlossen ist.
• Daten werden auf das entsprechende lokale Volume erweitert,
• Tag-Datei wird gelöscht

Serverwiederherstellungsprozess

Wenn der Hauptserver ausfällt, wird ein ähnlicher dedizierter Server gestartet, der von einem Standard-Image geladen wird. Der Download erfolgt höchstwahrscheinlich über das Netzwerk. Der Techniker des Rechenzentrums, der die Serverkonfiguration durchführt, kann dieses Standardabbild jedoch sofort auf eine der Festplatten kopieren. Das Herunterladen erfolgt im RAM. Danach beginnt der Wiederherstellungsprozess:

• Es wird angefordert, das Blockgerät über iscsi \ nbd oder ein anderes ähnliches Protokoll des logischen Volumes anzuschließen, das das Root-Dateisystem des toten Servers enthält. Da das Root-Dateisystem klein sein sollte, sollte dieser Schritt in wenigen Minuten abgeschlossen sein. Es wird auch eine Bootloader-Wiederherstellung durchgeführt.
• Die Struktur lokaler logischer Volumes wird neu erstellt, logische Volumes werden mithilfe des Kernelmoduls dm_clone vom Sicherungsserver angehängt: Die Datenwiederherstellung beginnt und Änderungen werden sofort auf lokale Datenträger geschrieben
• Ein Container wird mit allen verfügbaren physischen Festplatten gestartet. Der Server wird vollständig wiederhergestellt, jedoch mit verringerter Leistung.
• Nach Abschluss der Datensynchronisierung werden die logischen Volumes vom Sicherungsserver getrennt, der Container deaktiviert und der Server neu gestartet.

Nach dem Neustart verfügt der Server über alle Daten, die zum Zeitpunkt der Sicherung vorhanden waren, sowie über alle Änderungen, die während des Wiederherstellungsprozesses vorgenommen wurden.

Ich lade Sie ein, die vorgeschlagene Option in den Kommentaren zu diskutieren. Vielen Dank für Ihre Aufmerksamkeit!