Dieser Hinweis schließt den Zyklus zum Thema Backup ab. Es wird die logische Organisation eines dedizierten Servers (oder VPS) besprochen, die sich für Backups eignet, und außerdem eine Option für die schnelle Wiederherstellung eines Servers aus einem Backup ohne große Ausfallzeiten im Katastrophenfall bieten.
Ausgangsdaten
Ein dedizierter Server verfügt meist über mindestens zwei Festplatten, die zur Organisation eines RAID-Arrays (Spiegel) der ersten Ebene dienen. Dies ist notwendig, um den Server auch bei Ausfall einer Festplatte weiter betreiben zu können. Wenn es sich um einen regulären dedizierten Server handelt, befindet sich möglicherweise ein separater Hardware-RAID-Controller mit aktiver Caching-Technologie auf der SSD, sodass neben regulären Festplatten auch eine oder mehrere SSDs angeschlossen werden können. Manchmal werden dedizierte Server angeboten, bei denen die einzigen lokalen Festplatten SATADOM (kleine Festplatten, strukturell ein Flash-Laufwerk, das an einen SATA-Port angeschlossen ist) oder sogar ein gewöhnliches kleines (8-16 GB) Flash-Laufwerk, das an einen speziellen internen Port angeschlossen ist, sind Die Daten werden aus dem Speichersystem entnommen, ü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 der Sicherung des Servers reibungslos auf den Spezialisten übergeht, der das Speichersystem wartet; normalerweise gibt es verschiedene proprietäre Technologien zum Erstellen von Snapshots, integrierte Deduplizierung und andere Freuden des Systemadministrators , besprochen in den vorherigen Teilen dieser Serie. Das Volumen des Festplatten-Arrays eines dedizierten Servers kann je nach Anzahl und Größe der an den Server angeschlossenen Festplatten mehrere zehn Terabyte erreichen. Bei VPS sind die Volumina bescheidener: in der Regel nicht mehr als 100 GB (es gibt aber auch mehr), und die Tarife für solche VPS können leicht teurer sein als die der günstigsten dedizierten Server desselben Hosters. Ein VPS verfügt meist über eine Festplatte, da sich darunter ein Speichersystem (oder etwas Hyperkonvergentes) befindet. Manchmal verfügt ein VPS über mehrere Festplatten mit unterschiedlichen Eigenschaften und für unterschiedliche Zwecke:
- kleines System – zur Installation des Betriebssystems;
- groß – Speicherung von Benutzerdaten.
Bei einer Neuinstallation des Systems über die Systemsteuerung wird der Datenträger mit den Benutzerdaten nicht überschrieben, sondern der Systemdatenträger vollständig neu gefüllt. Im Falle eines VPS bietet der Hoster möglicherweise auch eine Schaltfläche an, die einen Schnappschuss des Status des VPS (oder der Festplatte) erstellt. Wenn Sie jedoch Ihr eigenes Betriebssystem installieren oder vergessen, den gewünschten Dienst im VPS zu aktivieren, sind einige der Daten können dennoch verloren gehen. Zusätzlich zum Button wird in der Regel ein Datenspeicherdienst angeboten, der meist sehr eingeschränkt ist. In der Regel handelt es sich dabei um ein Konto mit Zugriff über FTP oder SFTP, manchmal zusammen mit SSH, mit einer abgespeckten Shell (z. B. rbash) oder einer Einschränkung beim Ausführen von Befehlen über autorisierte_Schlüssel (ü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 meistens über eine Netzwerkschnittstelle. In den meisten Fällen begrenzen Rechenzentren nicht die Netzwerkgeschwindigkeit innerhalb des Rechenzentrums, sondern begrenzen die Geschwindigkeit des Internetzugangs.
Die typische Last eines solchen dedizierten Servers oder VPS besteht aus einem Webserver, einer Datenbank und einem Anwendungsserver. Manchmal können verschiedene zusätzliche Hilfsdienste installiert werden, unter anderem für einen Webserver oder eine Datenbank: Suchmaschine, Mailsystem usw.
Als Speicherort für Sicherungskopien dient ein speziell vorbereiteter Server, über den wir später noch ausführlicher berichten werden.
Logische Organisation des Festplattensystems
Wenn Sie über einen RAID-Controller oder einen VPS mit einer Festplatte verfügen und keine besonderen Präferenzen für den Betrieb des Festplattensubsystems bestehen (z. B. eine separate schnelle Festplatte für die Datenbank), wird der gesamte freie Speicherplatz wie folgt aufgeteilt: eine Partition erstellt wird und darüber eine LVM-Volumengruppe erstellt wird, werden mehrere Volumes darin erstellt: 2 kleine Volumes derselben Größe, die als Root-Dateisystem verwendet werden (werden bei Updates einzeln geändert, um ein schnelles Rollback zu ermöglichen). (die Idee wurde von der Calculate-Linux-Distribution übernommen), eine andere ist für die Swap-Partition, der Rest des freien Speicherplatzes wird in kleine Volumes aufgeteilt, die als Root-Dateisystem für vollwertige Container, Festplatten für virtuelle Maschinen, Dateien verwendet werden Systeme für Konten in /home (jedes Konto hat sein eigenes Dateisystem), Dateisysteme für Anwendungscontainer.
Wichtiger Hinweis: Volumes müssen vollständig in sich geschlossen sein, d. h. sollten nicht voneinander oder vom Root-Dateisystem abhängen. Bei virtuellen Maschinen oder Containern wird dieser Punkt automatisch beachtet. 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 Abhängigkeiten zwischen den Volumes möglichst ausgeschlossen sind. Beispielsweise läuft jede Site von einem eigenen Benutzer aus, die Site-Konfigurationsdateien befinden sich im Home-Verzeichnis des Benutzers, in den Webserver-Einstellungen sind Site-Konfigurationsdateien nicht über /etc/nginx/conf.d/ eingebunden..conf und zum Beispiel /home//configs/nginx/*.conf
Wenn mehrere Festplatten vorhanden sind, können Sie ein Software-RAID-Array erstellen (und bei Bedarf und Gelegenheit dessen Caching auf einer SSD konfigurieren), auf dem Sie LVM gemäß den oben vorgeschlagenen Regeln aufbauen können. Auch in diesem Fall können Sie ZFS oder BtrFS verwenden, aber darüber sollten Sie zweimal nachdenken: Beide erfordern einen viel ernsthafteren Umgang mit Ressourcen und außerdem ist ZFS nicht im Linux-Kernel enthalten.
Unabhängig vom verwendeten Schema lohnt es sich immer, im Voraus die ungefähre Geschwindigkeit beim Schreiben von Änderungen auf Datenträger abzuschätzen und dann die Menge an freiem Speicherplatz zu berechnen, der für die Erstellung von Snapshots 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 einen Tag (22 Stunden) erreichen – so viel wird ein solches Volumen übertragen über das Netzwerk 1 Gbit/s) - es lohnt sich, etwa 800 GB zu reservieren. In Wirklichkeit wird die Zahl kleiner sein; Sie können sie getrost durch die Anzahl der logischen Volumes dividieren.
Backup-Speicherservergerät
Der Hauptunterschied zwischen einem Server zum Speichern von Sicherungskopien besteht in seinen großen, günstigen und relativ langsamen Festplatten. Da moderne Festplatten die 10-TB-Grenze bereits in einer Platte überschritten haben, ist es notwendig, Dateisysteme oder RAID mit Prüfsummen zu verwenden, da es beim Neuaufbau des Arrays oder der Wiederherstellung des Dateisystems (mehrere Tage!) zu einem Ausfall der zweiten Platte kommen kann zu erhöhter Belastung. Bei 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 ungefähr gleich große Teile aufgeteilt ist (wiederum beispielsweise unter Verwendung von LVM):
- Volumes, die den Servern entsprechen, die zum Speichern von Benutzerdaten verwendet werden (die zuletzt erstellte Sicherung wird zur Überprüfung auf ihnen bereitgestellt);
- Volumes, die als BorgBackup-Repositorys verwendet werden (Daten für Backups werden direkt hierher verschoben).
Das Funktionsprinzip besteht darin, dass für jeden Server separate Volumes für die BorgBackup-Repositorys erstellt werden, in denen die Daten der Kampfserver gespeichert werden. Die Repositorys arbeiten im Nur-Anhänge-Modus, wodurch die Möglichkeit des absichtlichen Löschens von Daten ausgeschlossen ist, und aufgrund der Deduplizierung und regelmäßigen Bereinigung der Repositorys von alten Backups (es bleiben jährliche Kopien übrig, monatlich für das letzte Jahr, wöchentlich für den letzten Monat, täglich für die letzte Woche, ggf. in Sonderfällen – stündlich für den letzten Tag: insgesamt 24 + 7 + 4 + 12 + jährlich – ca. 50 Kopien für jeden Server).
BorgBackup-Repositorys ermöglichen keinen Nur-Anhängen-Modus; stattdessen wird ein ForcedCommand in .ssh/authorized_keys verwendet, etwa so:
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.......Der angegebene Pfad enthält ein Wrapper-Skript über Borg, das zusätzlich zum Starten der Binärdatei mit Parametern zusätzlich den Prozess der Wiederherstellung der Sicherungskopie startet, nachdem die Daten entfernt wurden. Dazu erstellt das Wrapper-Skript eine Tag-Datei neben dem entsprechenden Repository. Das zuletzt erstellte Backup wird nach Abschluss des Datenfüllvorgangs automatisch auf dem entsprechenden logischen Volume wiederhergestellt.
Dieses Design ermöglicht es Ihnen, unnötige Backups regelmäßig zu bereinigen und verhindert außerdem, dass Kampfserver etwas auf dem Backup-Speicherserver löschen.
Backup-Prozess
Der Initiator des Backups ist der dedizierte Server oder VPS selbst, da dieses Schema mehr Kontrolle über den Backup-Prozess seitens dieses Servers gibt. Zunächst wird ein Snapshot des Zustands des aktiven Root-Dateisystems erstellt, der mithilfe von BorgBackup gemountet und auf den Backup-Speicherserver hochgeladen wird. Nachdem die Datenerfassung abgeschlossen ist, wird die Bereitstellung des Snapshots aufgehoben und gelöscht.
Wenn eine kleine Datenbank vorhanden ist (bis zu 1 GB für jede Site), wird ein Datenbank-Dump erstellt, der im entsprechenden logischen Volume gespeichert wird, wo sich die restlichen Daten für dieselbe Site befinden, jedoch so, dass der Dump vorhanden ist nicht über den Webserver erreichbar. Wenn die Datenbanken groß sind, sollten Sie die „Hot“-Datenentfernung konfigurieren, beispielsweise mit xtrabackup für MySQL, oder mit WAL mit archive_command in PostgreSQL arbeiten. In diesem Fall wird die Datenbank getrennt von den Site-Daten wiederhergestellt.
Wenn Container oder virtuelle Maschinen verwendet werden, sollten Sie qemu-guest-agent, CRIU oder andere notwendige Technologien konfigurieren. In anderen Fällen sind zusätzliche Einstellungen meist nicht erforderlich – wir erstellen einfach Snapshots logischer Volumes, die dann auf die gleiche Weise wie ein Snapshot des Status des Root-Dateisystems verarbeitet werden. Nach der Datenerfassung werden die Bilder gelöscht.
Weitere Arbeiten werden am Backup-Speicherserver durchgeführt:
- die letzte in jedem Repository erstellte Sicherung wird überprüft,
- das Vorhandensein einer Markierungsdatei wird überprüft, was anzeigt, dass der Datenerfassungsprozess abgeschlossen ist,
- die Daten werden auf das entsprechende lokale Volume erweitert,
- Die Tag-Datei wird gelöscht
Serverwiederherstellungsprozess
Wenn der Hauptserver ausfällt, wird ein ähnlicher dedizierter Server gestartet, der von einem Standard-Image startet. Höchstwahrscheinlich wird der Download über das Netzwerk erfolgen, aber der Techniker des Rechenzentrums, der den Server einrichtet, kann dieses Standard-Image sofort auf eine der Festplatten kopieren. Der Download erfolgt in den RAM, woraufhin der Wiederherstellungsprozess beginnt:
- Es wird eine Anfrage gestellt, ein Blockgerät über iscsinbd oder ein anderes ähnliches Protokoll an ein logisches Volume anzuschließen, das das Root-Dateisystem des verstorbenen Servers enthält. Da das Root-Dateisystem klein sein muss, sollte dieser Schritt in wenigen Minuten abgeschlossen sein. Der Bootloader wird ebenfalls wiederhergestellt;
- Die Struktur der lokalen logischen Volumes wird neu erstellt, logische Volumes werden vom Backup-Server mithilfe des Kernelmoduls dm_clone angehängt: Die Datenwiederherstellung beginnt und Änderungen werden sofort auf lokale Festplatten geschrieben
- ein Container wird mit allen verfügbaren physischen Festplatten gestartet – die Funktionalität des Servers wird vollständig wiederhergestellt, jedoch mit reduzierter Leistung;
- Nachdem die Datensynchronisierung abgeschlossen ist, werden die logischen Volumes vom Sicherungsserver getrennt, der Container ausgeschaltet und der Server neu gestartet.
Nach einem Neustart verfügt der Server über alle Daten, die zum Zeitpunkt der Erstellung des Backups vorhanden waren, sowie über alle Änderungen, die während des Wiederherstellungsvorgangs vorgenommen wurden.
Weitere Artikel der Serie
Backup Teil 7: Schlussfolgerungen
Ich lade Sie ein, die vorgeschlagene Option in den Kommentaren zu diskutieren, vielen Dank für Ihre Aufmerksamkeit!
Source: habr.com