Dieser Artikel schließt den Zyklus über Backup ab. Es wird um die logische Organisation eines dedizierten Servers (oder VPS) gehen, die für Backups geeignet ist, und es wird eine Möglichkeit zur schnellen Wiederherstellung des Servers aus einem Backup ohne nennenswerte Ausfallzeiten im Falle eines Ausfalls vorgestellt.
Rohdaten
Ein dedizierter Server verfügt in der Regel über mindestens zwei Festplatten, die zur Einrichtung eines RAID-1 Arrays (Spiegelung) verwendet werden. Dies ist wichtig, um den Betrieb des Servers auch dann fortsetzen zu können, wenn eine Festplatte ausfällt. Bei einem herkömmlichen dedizierten Server kann ein separater Hardware-RAID-Controller mit aktiver SSD-Caching-Technologie vorhanden sein, sodass neben den standardmäßigen Festplatten auch eine oder mehrere SSDs angeschlossen werden können. Manchmal werden dedizierte Server angeboten, bei denen nur SATADOMs (kleine Laufwerke, die strukturell wie ein USB-Stick sind und an einen SATA-Anschluss angeschlossen werden) oder sogar gewöhnliche kleine (8-16 GB) USB-Sticks, die in spezielle interne Anschlüsse eingesteckt werden, vorhanden sind. In solchen Fällen werden die Daten von einer SAN (Storage Area Network) abgerufen, die über ein dediziertes Speichernetzwerk (10G Ethernet, FC usw.) angeschlossen ist, und es gibt auch dedizierte Server, die direkt von der SAN gebootet werden. Diese Optionen werde ich nicht näher betrachten, da in solchen Fällen die Verantwortung für das Backup des Servers in der Regel auf den Spezialisten übergeht, der die SAN verwaltet. Hier gibt es oft unterschiedliche proprietäre Technologien zur Erstellung von Snapshots, integrierte Deduplication und andere Annehmlichkeiten, die bereits in vorherigen Teilen dieser Reihe behandelt wurden. Der Speicherplatz eines dedizierten Servers kann mehrere Dutzend Terabyte erreichen, abhängig von der Anzahl und Größe der an den Server angeschlossenen Festplatten. Bei VPS sind die Speichermengen bescheidener: üblicherweise nicht mehr als 100 GB (aber es gibt auch größere). Die Preise für solche VPS können jedoch leicht höher sein als die für die günstigsten dedizierten Server desselben Anbieters. Bei VPS ist der Speicher meist auf eine Festplatte beschränkt, da darunter typischerweise eine SAN (oder eine hyperkonvergente Lösung) liegt. Manchmal verfügen VPS jedoch über mehrere Festplatten mit unterschiedlichen Spezifikationen, die für verschiedene Zwecke genutzt werden.
- klein — für die Installation des Betriebssystems;
- groß — zur Speicherung von Benutzerdaten.
Bei der Neuinstallation des Systems über das Control Panel wird die Festplatte mit Benutzerdaten nicht überschrieben, während die Systemfestplatte vollständig neu installiert wird. Zudem kann der VPS-Anbieter eine Schaltfläche anbieten, die einen Snapshot des VPS-Zustands (oder der Festplatte) erstellt. Wenn jedoch ein eigenes Betriebssystem installiert oder der benötigte Dienst innerhalb des VPS vergessen wird zu aktivieren, können dennoch Daten verloren gehen. In Verbindung mit der Schaltfläche wird häufig ein Datenspeicherdienst angeboten, der meist stark eingeschränkt ist. Gewöhnlich handelt es sich um ein Konto mit Zugriff über FTP- oder SFTP-Protokolle, manchmal auch mit SSH und einem eingeschränkten Shell (z.B. rbash) oder einer Einschränkung beim Ausführen von Befehlen über authorized_keys (über ForcedCommand).
Der dedizierte Server ist über zwei Ports mit einer Geschwindigkeit von 1 Gbit/s mit dem Netzwerk verbunden, manchmal sind es auch Karten mit einer Geschwindigkeit von 10 Gbit/s. Bei VPS ist die Netzwerkverbindung meistens eine einzige. In der Regel schränken Rechenzentren die Geschwindigkeit innerhalb des Rechenzentrums nicht ein, sondern nur den Zugang zum Internet.
Die typische Last eines solchen dedizierten Servers oder VPS umfasst einen Webserver, eine Datenbank und einen Anwendungsserver. Gelegentlich können auch verschiedene zusätzliche unterstützende Dienste installiert werden, darunter für den Webserver oder die Datenbank: Suchmaschinen, E-Mail-Systeme usw.
Als Speicher für Backups dient ein speziell vorbereiteter Server, über den im Folgenden ausführlicher berichtet wird.
Logische Organisation des Dateisystems
Falls ein RAID-Controller vorhanden ist oder es sich um einen VPS mit einer Festplatte handelt und keine speziellen Anforderungen an das Speichersystem bestehen (z. B. eine separate schnelle Festplatte für die Datenbank) — wird der verfügbare Speicherplatz wie folgt verteilt: Es wird eine Partition erstellt, auf der eine LVM-Gruppe angelegt wird. Innerhalb dieser Gruppe entstehen mehrere Volumes: zwei kleine Volumes gleicher Größe, die als Wurzel-Dateisystem verwendet werden (sie werden abwechselnd bei Updates gewechselt, um einen schnellen Rollback zu ermöglichen, das Konzept stammt von der Distribution Calculate Linux), ein weiteres Volume dient als Swap-Partition, der restliche Speicherplatz wird auf kleine Volumes verteilt, die als Wurzel-Dateisystem für vollwertige Container, Festplatten für virtuelle Maschinen, Dateisysteme für Benutzerkonten in /home (jede Benutzerkonten bekommt ihr eigenes Dateisystem) sowie für Anwendungscontainer-Dateisysteme genutzt werden.
Wichtiger Hinweis: Die Volumes sollten vollständig unabhängig sein, d.h. sie sollten weder voneinander noch vom Root-Dateisystem abhängen. Bei virtuellen Maschinen oder Containern wird dies automatisch gewährleistet. Wenn es sich jedoch um Anwendungscontainer oder Home-Verzeichnisse handelt, sollte man in Erwägung ziehen, die Konfigurationsdateien des Webservers und anderer Dienste so zu trennen, dass die Abhängigkeiten zwischen den Volumes minimiert werden. Beispielsweise sollte jede Website von ihrem eigenen Benutzer betrieben werden, die Konfigurationsdateien der Website befinden sich im Home-Verzeichnis des Benutzers, während im Webserver die Konfigurationsdateien der Websites nicht über /etc/nginx/conf.d/.conf, sondern beispielsweise über /home/.conf, und zum Beispiel /home//configs/nginx/*.conf
Wenn mehrere Festplatten vorhanden sind, kann ein Software-RAID-Array erstellt werden (und dessen Cache auf SSD konfiguriert werden, wenn Bedarf und Möglichkeiten bestehen), über das dann LVM nach den oben vorgeschlagenen Regeln aufgebaut wird. In diesem Fall können auch ZFS oder BtrFS verwendet werden, wobei man hier allerdings mehrmals darüber nachdenken sollte: Beide erfordern einen deutlich ernsthafteren Ressourcenzugang, und ZFS ist zudem nicht im Linux-Kernel enthalten.
Unabhängig von der verwendeten Strategie ist es immer ratsam, im Voraus die ungefähre Geschwindigkeit zu schätzen, mit der Änderungen auf die Festplatten geschrieben werden, um den verfügbaren Speicherplatz für die Erstellung von Snapshots zu berechnen. Zum Beispiel, wenn unser Server Daten mit einer Geschwindigkeit von 10 Megabyte pro Sekunde schreibt und die gesamte Datenmenge 10 Terabyte beträgt – kann die Synchronisationszeit bis zu einem Tag betragen (22 Stunden – so lange würde es dauern, um dieses Volumen über ein 1 Gbit/s-Netzwerk zu übertragen) – sollten etwa 800 GB reserviert werden. In der Realität wird die Zahl geringer sein; sie kann ruhig durch die Anzahl der logischen Volumes geteilt werden.
Backup-Storage-Server
Der Hauptunterschied bei Backup-Servern liegt in der Verwendung von großen, kostengünstigen und relativ langsamen Festplatten. Angesichts der Tatsache, dass moderne HDDs bereits die 10-TB-Marke pro Festplatte überschritten haben, ist der Einsatz von Dateisystemen oder RAID mit Prüfziffern unerlässlich. Denn während der Neuauslegung des Arrays oder der Wiederherstellung des Dateisystems (was mehrere Tage dauern kann!) könnte die zweite Festplatte aufgrund der erhöhten Belastung ausfallen. Bei Festplatten mit einer Kapazität von bis zu 1 TB war dies nicht so spürbar. Zur Vereinfachung der Beschreibung gehe ich davon aus, dass der Speicherplatz in zwei ungefähr gleich große Teile (z. B. mithilfe von LVM) aufgeteilt ist:
- Volumes, die auf den Servern genutzt werden, um Benutzerdaten zu speichern (darauf wird das zuletzt angefertigte Backup zur Überprüfung wiederhergestellt);
- Volumes, die als Repositories für BorgBackup verwendet werden (hier gelangen die Daten für Backups direkt hin).
Das Prinzip besteht darin, dass für jeden Server separate Volumes für die BorgBackup-Repositories erstellt werden, in die die Daten von den produktiven Servern gelangen. Die Repositories arbeiten im Modus nur zum Hinzufügen, was eine absichtliche Datenlöschung ausschließt. Durch Deduplikation und regelmäßige Bereinigung der Repositories von alten Backups (es bleiben jährliche Kopien, monatliche der letzten Jahre, wöchentliche der letzten Monate, tägliche der letzten Woche und möglicherweise – in besonderen Fällen – stündliche der letzten Tage: insgesamt rund 50 Kopien für jeden Server) wird die Datenspeicherung optimiert.
In den BorgBackup-Repositories wird der Modus nur zum Hinzufügen nicht aktiviert; stattdessen wird ForcedCommand in der .ssh/authorized_keys verwendet, ungefähr so:
from="Serveradresse",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.......Am angegebenen Pfad befindet sich ein Wrapper-Skript für borg, das neben dem Starten des Binärprogramms mit Parametern zusätzlich den Wiederherstellungsprozess der Sicherung nach Abschluss der Datenaufnahme startet. Dazu erstellt das Wrapper-Skript eine Marker-Datei neben dem entsprechenden Repository. Die zuletzt erstellte Sicherung wird nach Abschluss des Datenuploads automatisch auf dem entsprechenden logischen Volume wiederhergestellt.
Diese Konstruktion ermöglicht es, unnötige Sicherungen regelmäßig zu bereinigen und verhindert zudem, dass produktive Server etwas auf dem Backup-Server löschen.
Der Sicherungsprozess
Der Initiator der Sicherung ist der dedizierte Server oder VPS selbst, da dieses Schema mehr Kontrolle über den Sicherungsprozess von diesem Server aus ermöglicht. Zunächst wird ein Snapshot des aktiven Root-Dateisystems erstellt, der mit BorgBackup auf den Backup-Server hochgeladen wird. Nach Abschluss der Datenaufnahme wird der Snapshot wieder demontiert und gelöscht.
Bei einer kleinen Datenbank (bis zu 1 GB für jede Webseite) wird ein Datenbank-Dump erstellt, der in dem entsprechenden logischen Volume gespeichert wird, wo auch die restlichen Daten dieser Webseite liegen, allerdings so, dass der Dump nicht über den Webserver zugänglich ist. Bei größeren Datenbanken sollte das "Hot Backup" eingerichtet werden, zum Beispiel mit xtrabackup für MySQL oder durch die Nutzung von WAL mit archive_command in PostgreSQL. In diesem Fall wird die Datenbank separat von den Daten der Webseiten wiederhergestellt.
Wenn Container oder virtuelle Maschinen verwendet werden, sollte der qemu-guest-agent, CRIU oder andere notwendige Technologien eingerichtet werden. In den meisten anderen Fällen sind keine zusätzlichen Einstellungen erforderlich – wir erstellen einfach Snapshots der logischen Volumes, die anschließend ähnlich wie der Snapshot des Root-Dateisystems bearbeitet werden. Nach der Datensicherung werden die Snapshots gelöscht.
Die weitere Arbeit erfolgt auf dem Backup-Server:
- die zuletzt erstellte Sicherung in jedem Repository wird überprüft,
- es wird überprüft, ob eine Markierungsdatei vorhanden ist, die anzeigt, dass der Sicherungsprozess abgeschlossen ist.
- Daten werden auf das entsprechende lokale Volume bereitgestellt,
- die Markierungsdatei wird gelöscht
Prozess der Wiederherstellung der Serverfunktionalität
Wenn der Hauptserver ausfällt, wird ein ähnlicher dedizierter Server gestartet, der von einem bestimmten Standard-Image bootet. Wahrscheinlich erfolgt der Bootvorgang über das Netzwerk, jedoch kann der Rechenzentrums-Techniker, der die Serverkonfiguration vornimmt, dieses Standard-Image sofort auf eine der Festplatten kopieren. Der Bootvorgang erfolgt im RAM, gefolgt von dem Wiederherstellungsprozess:
- eine Anfrage zur Verbindung eines Blockgerätes über iscsinbd oder ein ähnliches Protokoll für logische Volumes, das das Wurzel-Dateisystem des ausgefallenen Servers enthält, wird ausgeführt; da das Wurzel-Dateisystem klein sein sollte, sollte dieser Schritt in wenigen Minuten abgeschlossen sein. Auch der Bootloader wird wiederhergestellt;
- Die Struktur der lokalen logischen Volumes wird wiederhergestellt, die logischen Volumes vom Backup-Server über das Kernel-Modul dm_clone angeschlossen: die Datenwiederherstellung beginnt und die Änderungen werden sofort auf die lokalen Festplatten geschrieben.
- Ein Container mit allen verfügbaren physischen Festplatten wird gestartet – die Funktionsfähigkeit des Servers wird vollständig wiederhergestellt, jedoch mit verminderter Leistung.
- Nach Abschluss der Datensynchronisation werden die logischen Volumes vom Backup-Server getrennt, der Container wird heruntergefahren und der Server neu gestartet.
Nach dem Neustart wird der Server alle Daten enthalten, die zum Zeitpunkt der Erstellung des Backups vorhanden waren, sowie alle Änderungen, die während des Wiederherstellungsprozesses vorgenommen wurden.
Andere Artikel der Reihe
Backup, Teil 7: Fazit
Ich lade Sie ein, den vorgeschlagenen Vorschlag in den Kommentaren zu diskutieren, danke für Ihre Aufmerksamkeit!
Quelle: habr.com
