Diese Notiz schließt den Zyklus über Backup ab. Es geht um die logische Organisation eines dedizierten Servers (oder VPS), die für Backups geeignet ist, sowie um einen Vorschlag für eine schnelle Wiederherstellung des Servers aus einem Backup ohne nennenswerte Ausfallzeiten im Falle eines Notfalls.
Stammdaten
Ein dedizierter Server hat in der Regel mindestens zwei Festplatten, die zur Organisation eines RAID-Arrays der ersten Stufe (Spiegelung) dienen. Dies ist notwendig, um den Betrieb des Servers fortzusetzen, falls eine Festplatte ausfällt. Bei einem gewöhnlichen dedizierten Server kann es einen separaten Hardware-RAID-Controller mit aktiver SSD-Caching-Technologie geben, sodass zusätzlich zu den herkömmlichen Festplatten eine oder mehrere SSDs angeschlossen werden können. Manchmal werden dedizierte Server angeboten, in denen nur lokale Festplatten wie SATADOM (kleine Platten, konstruktiv wie ein USB-Stick, der an einen SATA-Port angeschlossen wird) oder sogar ein gewöhnlicher kleiner (8-16 GB) USB-Stick, der an einen speziellen internen Anschluss angeschlossen wird, vorhanden sind, während die Daten von einer SAN, die über ein dediziertes Datenspeichernetzwerk (Ethernet 10G, FC usw.) angeschlossen ist, stammen. Es gibt auch dedizierte Server, die direkt von der SAN booten. Solche Optionen werde ich nicht betrachten, da in diesen Fällen die Aufgabe des Server-Backups nahtlos an den Spezialisten übergeht, der die SAN betreut. In der Regel gibt es dort verschiedene proprietäre Technologien zur Erstellung von Snapshots, integrierte Deduplizierung und andere Annehmlichkeiten für Systemadministratoren, die in den vorherigen Teilen dieses Zyklus behandelt wurden. Die Speicherkapazität des Festplattenspeichers eines dedizierten Servers kann je nach Anzahl und Größe der an den Server angeschlossenen Festplatten mehrere Dutzend Terabyte erreichen. Bei VPS sind die Volumina bescheidener: in der Regel nicht mehr als 100 GB (aber es gibt auch größere), und die Tarife für solche VPS können leicht teurer sein als die günstigsten dedizierten Server desselben Anbieters. Bei VPS gibt es normalerweise nur eine Festplatte, da darunter eine SAN (oder etwas hyperkonvergentes) liegt. Manchmal hat ein VPS mehrere Festplatten mit unterschiedlichen Eigenschaften, für verschiedene Zwecke:
- klein — für die Installation des Betriebssystems;
- groß — zum Speichern von Benutzerdaten.
Beim Neuinstallieren des Systems über die Systemsteuerung wird die Festplatte mit den Benutzerdaten nicht überschrieben, während das System vollständig neu installiert wird. Im Fall eines VPS kann der Hosting-Anbieter eine Schaltfläche anbieten, die einen Snapshot des VPS (oder der Festplatte) erstellt. Wenn jedoch das eigene Betriebssystem installiert oder der benötigte Dienst im VPS nicht aktiviert wird, können Teile der Daten trotzdem verloren gehen. Zusätzlich zur Schaltfläche wird in der Regel ein Datenspeicher-Service angeboten, der meist stark eingeschränkt ist. Dies ist normalerweise ein Konto mit Zugriff über das FTP- oder SFTP-Protokoll, manchmal zusammen mit SSH, mit einer 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 handelt es sich um Karten mit einer Geschwindigkeit von 10 Gbit/s. Bei VPS ist die Netzwerkschnittstelle meist nur eine. In der Regel schränken Datencenter die Netzgeschwindigkeit innerhalb des Rechenzentrums nicht ein, begrenzen jedoch die Geschwindigkeit des Internetzugangs.
Die typische Last eines solchen dedizierten Servers oder VPS besteht aus einem Webserver, einer Datenbank und einem Anwendungsserver. Es können auch verschiedene zusätzliche Hilfsdienste installiert werden, einschließlich solcher für den Webserver oder die Datenbank: Suchmaschine, E-Mail-System usw.
Als Speicherplatz für Sicherungskopien dient ein speziell vorbereiteter Server, über den später detaillierter berichtet wird.
Logische Organisation des Dateisystems
Wenn ein RAID-Controller vorhanden ist oder es sich um einen VPS mit einer Festplatte handelt und keine speziellen Anforderungen an das Laufwerkssystem bestehen (zum Beispiel eine separate schnelle Festplatte für die Datenbank), wird der gesamte freie Speicherplatz folgendermaßen aufgeteilt: Es wird eine Partition erstellt, darauf wird eine LVM-Gruppe geschaffen, in der mehrere Volumes erstellt werden: 2 kleine, gleich große Volumes, die als Root-Dateisystem verwendet werden (diese werden abwechselnd während der Updates geändert, um einen schnellen Rollback zu ermöglichen, die Idee wurde beim Distribution Calculate Linux entlehnt), eines für die Swap-Partition, der restliche freie Speicher wird in kleine Volumes aufgeteilt, die als Root-Dateisysteme für vollwertige Container, Festplatten für virtuelle Maschinen, Dateisysteme für Accounts im /home (jede Benutzerkonto hat ihr eigenes Dateisystem), Dateisysteme für Anwendungscontainer verwendet werden.
Wichtiger Hinweis: Die Volumes müssen vollständig autark sein, d. h. sie sollten weder voneinander noch vom Root-Dateisystem abhängig sein. Bei virtuellen Maschinen oder Containern wird dieser Punkt automatisch eingehalten. Wenn es sich jedoch um Anwendungscontainer oder Home-Verzeichnisse handelt, sollte man darüber nachdenken, die Konfigurationsdateien des Webservers und anderer Services so zu trennen, dass Abhängigkeiten zwischen den Volumes möglichst stark minimiert werden. Zum Beispiel funktioniert jede Website unter ihrem eigenen Benutzer, die Konfigurationsdateien der Website befinden sich im Home-Verzeichnis des Benutzers, in den Einstellungen des Webservers werden die Konfigurationsdateien der Websites nicht über /etc/nginx/conf.d/.conf, sondern beispielsweise über /home//configs/nginx/*.conf
Wenn mehrere Festplatten vorhanden sind, können Sie ein softwarebasiertes RAID-Array erstellen (und dessen Caching auf SSD einrichten, falls Bedarf und Möglichkeiten bestehen), auf dem dann LVM nach den oben vorgeschlagenen Regeln eingerichtet wird. In diesem Fall kann auch ZFS oder BtrFS verwendet werden, aber hierbei sollte man mehrmals nachdenken: Beide erfordern einen wesentlich ernsthafteren Ansatz in Bezug auf die Ressourcen, zudem ist ZFS nicht im Linux-Kernel enthalten.
Unabhängig von der verwendeten Konfiguration ist es immer ratsam, die ungefähre Schreibgeschwindigkeit der Änderungen auf die Festplatten im Voraus abzuschätzen, um die Größe des freien Speicherplatzes zu berechnen, der für die Erstellung von Snapshots reserviert werden soll. Zum Beispiel, wenn unser Server Daten mit einer Geschwindigkeit von 10 Megabyte pro Sekunde schreibt und die Größe des gesamten Datenspeichers 10 Terabyte beträgt – die Synchronisationszeit kann bis zu einem Tag (22 Stunden – so lange benötigt man, um dieses Volumen über ein 1 Gbit/s Netzwerk zu übertragen) betragen – es sollten etwa 800 GB reserviert werden. In der Realität wird die Zahl geringer ausfallen, man kann sie ruhig durch die Anzahl der logischen Volumen teilen.
Backup-Servergerät
Das Hauptmerkmal eines Backup-Servers sind große, kostengünstige und relativ langsame Festplatten. Da moderne HDDs bereits die Schwelle von 10 TB in einer Festplatte überschritten haben, ist die Verwendung von Dateisystemen oder RAID mit Prüfziffern unerlässlich, da während der Umstrukturierung des Speichers oder der Wiederherstellung des Dateisystems (einige Tage!) die zweite Festplatte aufgrund der erhöhten Belastung ausfallen kann. Bei Festplatten mit einer Kapazität von bis zu 1 TB war das nicht so empfindlich. Um es einfach zu halten, nehme ich an, dass der Speicherplatz in zwei annähernd gleich große Teile unterteilt ist (zum Beispiel mit Hilfe von LVM):
- Volumes, die auf den Servern verwendet werden, die für die Speicherung von Benutzerdaten vorgesehen sind (dort wird das zuletzt erstellte Backup zur Überprüfung bereitgestellt);
- Volumes, die als Repositories für BorgBackup verwendet werden (dort werden die Daten für die Backups direkt gespeichert).
Das Funktionsprinzip besteht darin, dass separate Volumes für jede Serverinstanz unter den BorgBackup-Repositories erstellt werden, in die die Daten von den Produktionsservern gelangen. Die Repositories arbeiten im Nur-Hinzufügen-Modus, was die absichtliche Löschung von Daten ausschließt, und durch Deduplizierung und regelmäßige Bereinigung der Repositories von alten Backups (es bleiben jährliche Kopien, monatliche Kopien des letzten Jahres, wöchentliche Kopien des letzten Monats, tägliche Kopien der letzten Woche, möglicherweise in besonderen Fällen stündliche Kopien des letzten Tages: insgesamt 24 + 7 + 4 + 12 + jährliche – ungefähr 50 Kopien für jeden Server) wird die Effizienz erhöht.
Im BorgBackup-Repository wird der Nur-Hinzufügungsmodus nicht aktiviert, stattdessen wird ForcedCommand in .ssh/authorized_keys verwendet, ungefähr in folgendem Format:
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 Speicherort befindet sich ein Wrapper-Skript über Borg, das, zusätzlich zum Starten des Binärprogramms mit Parametern, auch den Wiederherstellungsprozess nach Abschluss der Datenerfassung startet. Zu diesem Zweck erstellt das Wrapper-Skript eine Kennzeichendatei neben dem entsprechenden Repository. Das zuletzt erstellte Backup wird nach Abschluss des Daten-Uploads automatisch auf dem entsprechenden logischen Laufwerk wiederhergestellt.
Diese Konstruktion ermöglicht es, nicht benötigte Backups regelmäßig zu bereinigen und verhindert, dass Produktionsserver etwas auf dem Backup-Server löschen.
Der Backup-Prozess
Der Initiator des Backups ist der dedizierte Server oder VPS selbst, da dieses Schema mehr Kontrolle über den Backup-Prozess von diesem Server aus bietet. Zuerst wird ein Snapshot des Zustands des aktiven Root-Dateisystems erstellt, der mithilfe von BorgBackup auf dem Backup-Server eingehängt und hochgeladen wird. Nach Abschluss der Datenerfassung wird der Snapshot ausgehängt und gelöscht.
Bei einer kleinen Datenbank (bis zu 1 GB für jede Website) wird ein Datenbank-Dump erstellt, der im entsprechenden logischen Laufwerk gespeichert wird, dort, wo sich auch die anderen Daten dieser Website befinden, jedoch so, dass der Dump nicht über den Webserver zugänglich ist. Bei größeren Datenbanken sollte ein „hot backup“ eingerichtet werden, zum Beispiel mit xtrabackup für MySQL oder mithilfe von WAL mit archive_command in PostgreSQL. In diesem Fall wird die Datenbank separat von den Website-Daten wiederhergestellt.
Wenn Container oder virtuelle Maschinen verwendet werden, sollte qemu-guest-agent, CRIU oder andere erforderliche Technologien eingerichtet werden. In den meisten anderen Fällen sind keine zusätzlichen Einstellungen erforderlich — einfach Snapshots der logischen Laufwerke erstellen, die dann ähnlich wie der Snapshot des Root-Dateisystems verarbeitet werden. Nach der Datenerfassung werden die Snapshots gelöscht.
Die weitere Arbeit erfolgt auf dem Backup-Server:
- Die letzte erstellte Sicherungskopie wird in jedem Repository überprüft,
- Es wird überprüft, ob eine Markierungsdatei vorhanden ist, die angibt, dass der Datenextraktionsprozess abgeschlossen ist,
- Die Daten werden auf das entsprechende lokale Volume entpackt,
- Die Markierungsdatei wird gelöscht,
Der Wiederherstellungsprozess des Servers,
Wenn der Hauptserver ausfällt, wird ein ähnlicher dedizierter Server gestartet, der von einem bestimmten Standard-Image bootet. Höchstwahrscheinlich erfolgt der Bootvorgang über das Netzwerk, jedoch kann der Rechenzentrums-Techniker, der die Serverkonfiguration durchführt, dieses Standard-Image sofort auf eine der Festplatten kopieren. Der Bootvorgang erfolgt im Arbeitsspeicher, danach wird der Wiederherstellungsprozess gestartet:
- Es wird eine Anfrage zum Anbinden des Blockgeräts über iscsinbd oder ein anderes ähnliches Protokoll für logische Volumes gestellt, das das Wurzel-Dateisystem des ausgefallenen Servers enthält; da das Wurzel-Dateisystem klein sein muss, sollte dieser Schritt innerhalb weniger Minuten abgeschlossen sein. Außerdem wird der Bootloader wiederhergestellt;
- Die Struktur der lokalen logischen Volumes wird wiederhergestellt, und die logischen Volumes vom Sicherungsserver werden über das dm_clone-Kernelmodul angehängt: die Datenwiederherstellung beginnt und die Änderungen werden sofort auf die lokalen Festplatten geschrieben,
- Ein Container mit allen verfügbaren physischen Festplatten wird gestartet — die Betriebsfähigkeit des Servers wird vollständig wiederhergestellt, jedoch mit verringerter Leistung;
- Nach Abschluss der Datensynchronisierung werden die logischen Volumes vom Sicherungsserver abgetrennt, der Container wird heruntergefahren, der Server wird neu gestartet;
Nach dem Neustart wird der Server über alle Daten verfügen, die zum Zeitpunkt der Erstellung des Backups vorhanden waren, sowie alle Änderungen enthalten, die im Laufe der Wiederherstellung vorgenommen wurden.
Weitere Artikel der Reihe
Backup, Teil 7: Zusammenfassungen
Ich lade Sie ein, den vorgeschlagenen Vorschlag in den Kommentaren zu diskutieren, danke für Ihre Aufmerksamkeit!
Quelle: habr.com
