Ein weiteres Backup – mehr als nur ein Skript, einfacher als ein System

Es gibt viele Backup-Systeme, aber was tun, wenn die verwalteten Server über verschiedene Regionen und Kunden verteilt sind und man auf die Betriebssystem-Tools angewiesen ist?

Guten Tag, Habr!
Ich heiße Natalia. Ich bin Teamleiterin der Gruppe für Anwendungsadministratoren bei NPO 'Krista'. Wir sind das Ops-Team für die Projekte unserer Firma. Unsere Situation ist ziemlich einzigartig: Wir installieren und warten unsere Software sowohl auf den Servern unseres Unternehmens als auch auf den Servern der Kunden. Dabei ist es nicht erforderlich, den Server vollständig zu sichern. Wichtig sind nur die 'wichtigsten Daten': die Datenbank und einzelne Verzeichnisse des Dateisystems. Natürlich haben die Kunden (oder haben nicht) ihre eigenen Backup-Vorgaben und bieten häufig einen externen Speicherort für die Ablage der Backups an. In diesem Fall stellen wir nach der Erstellung des Backups sicher, dass es in den externen Speicher gesendet wird.

Eine Zeit lang haben wir für Backup-Zwecke mit einem Bash-Skript gearbeitet, aber mit der Zunahme der Konfigurationsmöglichkeiten wuchs auch die Komplexität des Skripts, und eines schönen Tages kamen wir zu der Notwendigkeit, es 'von Grund auf zu zerstören und dann…'.

Fertige Lösungen waren aus verschiedenen Gründen nicht geeignet: wegen der Notwendigkeit zur Dezentralisierung der Backups, der Verpflichtung zur lokalen Speicherung der Backups beim Kunden, der Komplexität der Einrichtung, des Importersatzes und von Zugangsrestriktionen.

Es schien uns einfacher, etwas Eigenes zu schreiben. Dabei wollten wir etwas erhalten, das für unsere Situation in den kommenden N Jahren ausreicht, jedoch mit der Möglichkeit zur potenziellen Erweiterung des Anwendungsbereichs.

Die Anforderungen waren folgende:

1. die Basisinstanz des Backups ist autonom und arbeitet lokal
2. Die Sicherung von Backups und Protokollen erfolgt immer im Netzwerk des Kunden
3. Die Instanz besteht aus Modulen – eine Art 'Baukasten'
4. Kompatibilität mit den verwendeten Linux-Distributionen, einschließlich veralteter, sowie potenzielle plattformübergreifende Funktionalität sind wünschenswert
5. Für den Betrieb der Instanz ist SSH-Zugriff ausreichend, zusätzliche Ports müssen nicht geöffnet werden
6. Maximale Einfachheit bei der Einrichtung und Nutzung
7. Es kann (muss aber nicht) eine separate Instanz existieren, die es ermöglicht, den Status der Backups von verschiedenen Servern zentral zu überwachen

Was wir erreicht haben, kann hier angesehen werden: github.com/javister/krista-backup
Die Software ist in Python 3 geschrieben und läuft auf Debian, Ubuntu, CentOS, AstraLinux 1.6.

Die Dokumentation befindet sich im Verzeichnis docs des Repositories.

Die grundlegenden Konzepte, mit denen das System arbeitet:
action – eine Aktion, die eine atomare Operation realisiert (Datenbank-Backup, Backup eines Verzeichnisses, Verschieben von Verzeichnis A nach Verzeichnis B usw.). Vorhandene actions befinden sich im Verzeichnis core/actions.
task – eine Aufgabe, ein Satz von actions, der 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 (Aktionssets) und deren Zeitpläne zur Ausführung über Cron, falls eine solche Ausführung erforderlich ist.

Ein Beispiel für die Konfiguration kann hier angesehen werden.

Was die Anwendung derzeit kann:

• Die grundlegenden Operationen, die für uns wichtig sind, werden unterstützt: Backup von PostgreSQL über pg_dump, Backup von Verzeichnissen des Dateisystems über tar; Operationen mit externem Speicher; rsync zwischen Verzeichnissen; Rotation von Backups (Löschen älterer Kopien).
• Aufruf eines externen Skripts.
• Manuelle Ausführung einer einzelnen Aufgabe.

  /opt/KristaBackup/KristaBackup.py run make_full_dump

• Es kann eine einzelne Aufgabe oder der gesamte Zeitplan in der Crontab hinzugefügt (oder entfernt) werden.

  /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 Web-API- oder Web-Modus arbeiten.

  /opt/KristaBackup/KristaBackup.py web start [--api]

Der Unterschied zwischen den Modi: Im Web-API-Modus gibt es keine eigene Web-Oberfläche, aber die Anwendung antwortet auf Anfragen von einer anderen Instanz. Für den Web-Modus müssen Flask und mehrere zusätzliche Pakete installiert werden, was nicht überall akzeptabel ist, z. B. in der zertifizierten AstraLinux SE.

Über die Web-Oberfläche kann der Status und die Protokolle der Backups der verbundenen Server eingesehen werden: 'Web-Instanz' fragt Daten von 'Backup-Instanzen' über die API ab. Der Zugang zum Web erfordert eine Authentifizierung, der Zugang zur Web-API nicht.

Protokolle von fehlerhaft durchgeführten Backups werden farblich markiert: Warning – gelb, Error – rot.

Wenn der Administrator das Handbuch zu den Parametern nicht benötigt und die Server-Betriebssysteme homogen sind, kann die Datei kompiliert und bereits als fertiges Paket verbreitet werden.

Wir verbreiten dieses Tool hauptsächlich über Ansible, indem wir es zunächst auf einer Gruppe von weniger wichtigen Servern ausrollen und nach Tests auf alle anderen.

Letztendlich haben wir ein kompaktes, autonomes Kopie-Tool erhalten, das automatisierbar ist und selbst von unerfahrenen Administratoren genutzt werden kann. Es ist bequem für uns – vielleicht ist es auch für Sie nützlich?

Quelle: habr.com