Es gibt viele Backup-Systeme, aber was tun, wenn die betreuten Server in verschiedenen Regionen und bei verschiedenen Kunden verteilt sind und man sich mit den Mitteln des Betriebssystems behelfen muss?
Guten Tag, Habr!
Mein Name ist Natalja. Ich bin Teamleiterin der Gruppe für Anwendungsadministratoren bei NPO «Krista». Wir sind die Ops-Gruppe für die Projekte unseres Unternehmens. Unsere Situation ist ziemlich ungewöhnlich: Wir installieren und betreuen unsere Software sowohl auf den Servern unseres Unternehmens als auch auf den Servern, die sich bei den Kunden befinden. Dabei ist es nicht nötig, den gesamten Server zu sichern. Nur die "wesentlichen Daten" sind wichtig: Datenbanken und einzelne Verzeichnisse des Dateisystems. Natürlich haben die Kunden ihre (oder auch keine) Backup-Vorgaben und stellen oft einen externen Speicher zur Verfügung, um die Backups dort abzulegen. In diesem Fall sorgen wir nach der Erstellung des Backups für die Übertragung in den externen Speicher.
Eine Zeit lang haben wir für Backup-Zwecke ein Bash-Skript verwendet, aber mit der Zunahme der Konfigurationsvarianten nahm auch die Komplexität dieses Skripts proportional zu und schließlich kamen wir zu dem Punkt, an dem wir es "bis auf die Grundmauern zerstören und dann..." mussten.
Fertige Lösungen waren aus verschiedenen Gründen nicht geeignet: wegen der Notwendigkeit der Dezentralisierung von Backups, der Verpflichtung zur Speicherung von Backups lokal beim Kunden, der Komplexität der Einrichtung, der Importsubstitution und der Zugangsbegrenzungen.
Wir haben gedacht, dass es einfacher wäre, etwas Eigenes zu schreiben. Dabei wollten wir etwas erhalten, das für unsere Situation in den nächsten N Jahren ausreicht, aber auch das Potenzial für eine zukünftige Erweiterung des Anwendungsbereichs bietet.
Die Aufgabenbedingungen waren wie folgt:
- Der Basis-Backup-Instanz ist autonom, funktioniert lokal.
- Die Speicherung von Sicherungskopien und Protokollen erfolgt stets innerhalb des Netzwerks des Kunden.
- Die Instanz besteht aus Modulen – eine Art „Baukasten“.
- Kompatibilität mit den verwendeten Linux-Distributionen, einschließlich veralteter Versionen, ist erforderlich; wünschenswert ist potenzielle Plattformunabhängigkeit.
- Für den Betrieb der Instanz reicht der SSH-Zugang aus; das Öffnen zusätzlicher Ports ist nicht erforderlich.
- Maximale Einfachheit in der Einrichtung und Bedienung.
- Es könnte (muss aber nicht) eine separate Instanz existieren, die es ermöglicht, den Zustand der Backups von verschiedenen Servern zentral zu überwachen.
Das, was wir erreicht haben, kann hier angesehen werden:
Die Software ist in Python 3 geschrieben und läuft auf Debian, Ubuntu, CentOS und AstraLinux 1.6.
Die Dokumentation befindet sich im docs-Verzeichnis des Repositories.
Wichtige Konzepte, mit denen das System arbeitet:
action – eine Aktion, die eine atomare Operation (Datenbank-Backup, Verzeichnis-Backup, Übertragung von Verzeichnis A nach Verzeichnis B usw.) realisiert. Vorhandene actions befinden sich im Verzeichnis core/actions.
task – eine Aufgabe, ein Set von actions, das eine logische "Backup-Aufgabe" beschreibt.
schedule – ein Zeitplan, eine Gruppe von tasks mit optionaler Angabe der Ausführungszeit der Aufgabe.
Die Backup-Konfiguration wird in einer YAML-Datei gespeichert; die allgemeine Struktur der Konfiguration:
- allgemeine Einstellungen
- Abschnitt actions: Beschreibung der auf diesem Server verwendeten Aktionen.
- Abschnitt schedule: Beschreibung aller Aufgaben (Sets von Aktionen) und deren Ausführungszeitplan über cron, falls eine solche Ausführung erforderlich ist.
Was die Anwendung derzeit kann:
- Die für uns wesentlichen Operationen werden unterstützt: PostgreSQL-Backup über pg_dump, Backup von Verzeichnissen über tar; Operationen mit externem Speicher; rsync zwischen Verzeichnissen; Backup-Rotation (Löschung alter Kopien).
- Aufruf eines externen Skripts.
- Manuelle Ausführung einer einzelnen Aufgabe.
/opt/KristaBackup/KristaBackup.py run make_full_dump - Es ist möglich, eine einzelne Aufgabe oder den gesamten Zeitplan in der Crontab hinzuzufügen (oder zu entfernen)
/opt/KristaBackup/KristaBackup.py enable all - Generierung einer Trigger-Datei basierend auf den Ergebnissen des Backups. Diese Funktion ist nützlich in Verbindung mit Zabbix zur Überwachung von Backups
- Kann im Hintergrund im WebAPI- oder Webmodus arbeiten
/opt/KristaBackup/KristaBackup.py web start [--api]
Der Unterschied zwischen den Modi: Im WebAPI gibt es kein eigenes Web-Interface, aber die Anwendung beantwortet die Anfragen einer anderen Instanz. Für den Webmodus müssen Flask und mehrere zusätzliche Pakete installiert werden, was nicht überall akzeptabel ist, zum Beispiel in der zertifizierten AstraLinux SE.
Über das Web-Interface kann der Status und die Logs der angeschlossenen Backup-Server eingesehen werden: 'Web-Instanz' fragt die Daten von 'Backup-Instanzen' über die API ab. Der Zugang zum Web erfordert eine Authentifizierung, der Zugang zum WebAPI nicht.
Die Protokolle fehlerhaft durchgeführter Backups sind farblich markiert: Warnung – gelb, Fehler – rot.
Falls der Administrator keinen Spickzettel für die Parameter benötigt und die Server-Betriebssysteme homogen sind, kann die Datei kompiliert und als bereits fertiges Paket verteilt werden.
Wir verbreiten dieses Tool hauptsächlich über Ansible, indem wir es zunächst auf einen Teil der am wenigsten wichtigen Server ausrollen und nach der Testphase auf alle anderen.
Am Ende haben wir ein kompaktes, autonomes Kopierwerkzeug erhalten, das sich automatisieren lässt und selbst von weniger erfahrenen Administratoren genutzt werden kann. Uns gefällt es – vielleicht ist es auch für Sie von Nutzen?
Quelle: habr.com
