Es gibt viele Backup-Systeme, aber was tun, wenn die bedienten Server über verschiedene Regionen und Clients verteilt sind und Sie sich mit dem Betriebssystem begnügen müssen?
Guten Tag, Es wird sein!
Ich heiße Natalia. Ich bin der Teamleiter der Anwendungsadministratorgruppe bei NPO Krista. Wir sind Ops für die Projektgruppe unseres Unternehmens. Wir haben eine ziemlich einzigartige Situation: Wir installieren und warten unsere Software sowohl auf den Servern unseres Unternehmens als auch auf Servern, die sich bei Kunden befinden. In diesem Fall ist es nicht erforderlich, den gesamten Server zu sichern. Wichtig sind nur die „wesentlichen Daten“: das DBMS und die einzelnen Dateisystemverzeichnisse. Natürlich haben Kunden ihre eigenen Backup-Vorschriften (oder auch nicht) und stellen oft eine Art externen Speicher zur Verfügung, um dort Backups zu speichern. In diesem Fall sorgen wir nach der Erstellung eines Backups für die Übermittlung an einen externen Speicher.
Eine Zeit lang haben wir uns zu Sicherungszwecken mit einem Bash-Skript begnügt, aber als die Konfigurationsmöglichkeiten zunahmen, wuchs auch die Komplexität dieses Skripts proportional, und irgendwann kamen wir zu der Notwendigkeit, „es bis auf die Grundmauern zu zerstören, und dann ...“.
Vorgefertigte Lösungen waren aus verschiedenen Gründen nicht geeignet: aufgrund der Notwendigkeit, Backups zu dezentralisieren, der Anforderung, Backups lokal beim Client zu speichern, Komplexität der Einrichtung, Importsubstitution, Zugriffsbeschränkungen.
Uns schien es einfacher, etwas Eigenes zu schreiben. Gleichzeitig wollte ich etwas bekommen, das für unsere Situation für die nächsten N Jahre ausreicht, aber mit der Möglichkeit einer möglichen Erweiterung des Anwendungsbereichs.
Die Bedingungen der Aufgabe waren wie folgt:
- Die grundlegende Backup-Instanz ist autonom und wird lokal ausgeführt
- Die Speicherung von Backups und Protokollen erfolgt immer im Netzwerk des Kunden
- Eine Instanz besteht aus Modulen – eine Art „Konstruktor“
- Kompatibilität mit aktuellen Linux-Distributionen ist erforderlich, auch mit veralteten, potenzielle Cross-Plattform ist wünschenswert
- Um mit der Instanz zu arbeiten, reicht ein Zugriff per SSH aus, das Öffnen zusätzlicher Ports ist nicht notwendig
- Maximale einfache Einrichtung und Bedienung
- Es ist möglich (aber nicht notwendig), eine separate Instanz zu haben, die es Ihnen ermöglicht, den Status von Backups von verschiedenen Servern zentral anzuzeigen
Was dabei herausgekommen ist, seht ihr hier:
Die Software ist in Python3 geschrieben; Funktioniert unter Debian, Ubuntu, CentOS, AstraLinux 1.6.
Die Dokumentation wird im docs-Verzeichnis des Repositorys veröffentlicht.
Grundkonzepte, nach denen das System funktioniert:
Aktion – eine Aktion, die eine atomare Operation implementiert (Datenbanksicherung, Verzeichnissicherung, Übertragung von Verzeichnis A nach Verzeichnis B usw.). Vorhandene Aktionen befinden sich im Verzeichnis core/actions
Aufgabe – Aufgabe, eine Reihe von Aktionen, die eine logische „Sicherungsaufgabe“ beschreiben.
Zeitplan – Zeitplan, eine Reihe von Aufgaben mit optionaler Angabe der Ausführungszeit der Aufgabe
Die Backup-Konfiguration wird in einer Yaml-Datei gespeichert; Allgemeine Konfigurationsstruktur:
- Allgemeine Einstellungen
- Abschnitt „Aktionen“: Beschreibung der auf diesem Server verwendeten Aktionen
- Abschnitt „Zeitplan“: Beschreibung aller Aufgaben (Aktionssätze) und Zeitplan für deren Start durch Cron, falls ein solcher Start erforderlich ist
Was die Anwendung derzeit kann:
- Die wichtigsten Operationen für uns werden unterstützt: PostgreSQL-Backup über pg_dump, Dateisystemverzeichnis-Backup über tar; Operationen mit externem Speicher; rsync zwischen Verzeichnissen; Backup-Rotation (Löschen alter Kopien)
- Aufruf eines externen Skripts
- manuelle Ausführung einer separaten Aufgabe
/opt/KristaBackup/KristaBackup.py run make_full_dump - Sie können eine einzelne Aufgabe oder den gesamten Zeitplan zur Crontab hinzufügen (oder entfernen).
/opt/KristaBackup/KristaBackup.py enable all - Generieren einer Triggerdatei basierend auf den Sicherungsergebnissen. Diese Funktion ist in Verbindung mit Zabbix zur Überwachung von Backups nützlich
- kann im Hintergrund im Webapi- oder Webmodus arbeiten
/opt/KristaBackup/KristaBackup.py web start [--api]
Der Unterschied zwischen den Modi: Webapi verfügt selbst über kein Webinterface, sondern die Anwendung antwortet auf Anfragen einer anderen Instanz. Für den Webmodus müssen Sie flask und mehrere zusätzliche Pakete installieren, was nicht überall akzeptabel ist, beispielsweise in zertifizierten AstraLinux SE.
Über die Weboberfläche können Sie den Status und die Protokolle von Backups verbundener Server einsehen: Die „Webinstanz“ fordert über die API Daten von den „Backup-Instanzen“ an. Für den Zugriff auf das Web ist eine Autorisierung erforderlich, für den Zugriff auf Webapi jedoch nicht.
Protokolle fehlerhafter Sicherungen werden farblich markiert: Warnung – gelb, Fehler – rot.
Wenn der Administrator keinen Spickzettel zu den Parametern benötigt und die Server-Betriebssysteme einheitlich sind, können Sie die Datei kompilieren und das fertige Paket verteilen.
Wir vertreiben dieses Dienstprogramm hauptsächlich über Ansible, indem wir es zuerst auf einigen der unwichtigsten Server und nach dem Testen auf allen anderen ausrollen.
Als Ergebnis erhielten wir ein kompaktes, eigenständiges Kopierdienstprogramm, das automatisiert werden kann und auch von unerfahrenen Administratoren verwendet werden kann. Es ist praktisch für uns – vielleicht ist es auch für Sie nützlich?
Source: habr.com