Guten Tag, Habr !
Ich heiße Natalia. Ich bin der Teamleiter der Gruppe der Anwendungsadministratoren bei NPO Krista. Wir sind Ops für die Projektgruppe unseres Unternehmens. Wir haben eine ziemlich eigenartige Situation: Wir installieren und warten unsere Software sowohl auf den Servern unseres Unternehmens als auch auf den Servern beim Kunden. In diesem Fall muss nicht der gesamte Server gesichert werden. Wichtig sind nur die "wesentlichen Daten": das DBMS und einzelne Verzeichnisse des Dateisystems. Natürlich haben Kunden ihre eigenen Sicherungsbestimmungen (oder haben diese nicht) und stellen häufig eine Art externen Speicher zum Speichern von Sicherungen bereit. In diesem Fall senden wir nach dem Erstellen eines Backups das Senden an einen externen Speicher.
Für Sicherungszwecke kamen wir eine Weile mit einem Bash-Skript zurecht, aber als die Optionen zunahmen, wuchs die Komplexität dieses Skripts proportional, und irgendwann kamen wir zu der Notwendigkeit, "es zu Boden zu zerstören und dann ...".
Vorgefertigte Lösungen funktionierten aus verschiedenen Gründen nicht: Aufgrund der Notwendigkeit, Backups zu dezentralisieren, der Verpflichtung, Backups lokal auf dem Client zu speichern, der Komplexität des Setups, der Importsubstitution und der Zugriffsbeschränkungen.
Es schien uns einfacher zu sein, 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 Problembedingungen waren wie folgt:
- Die grundlegende Sicherungsinstanz ist autonom und arbeitet lokal
- Speicherung von Backups und Protokollen immer im Netzwerk des Clients
- – «»
- Linux, ,
- ssh,
- ( ) ,
Sie können sehen, was wir hier haben: github.com/javister/krista-backup Die
Software ist in Python3 geschrieben; funktioniert unter Debian, Ubuntu, CentOS, AstraLinux 1.6.
Die Dokumentation ist im Verzeichnis docs des Repositorys verfügbar.
Vom System verwendete Grundkonzepte:
Aktion - Eine Aktion, die eine atomare Operation implementiert (Datenbanksicherung, Verzeichnissicherung, Übertragung von Verzeichnis A nach Verzeichnis B usw.). Vorhandene Aktionen befinden sich in der
Task " Core / Actions Directory" - eine Aufgabe, eine Reihe von Aktionen, die einen logischen
Zeitplan für "Sicherungsaufgaben" beschreiben - einen Zeitplan, eine Aufgabengruppe mit einer optionalen Ausführungszeit für Aufgaben. Die
Sicherungskonfiguration wird in einer Yaml-Datei gespeichert. allgemeine Konfigurationsstruktur:
- Allgemeine Einstellungen
- Abschnitt "Aktionen": Eine Beschreibung der auf diesem Server verwendeten Aktionen
- Abschnitt Zeitplan: Eine Beschreibung aller Aufgaben (Aktionssätze) und der Zeitplan für deren Start durch die Krone, falls ein solcher Start erforderlich ist
Ein Beispiel für eine Konfiguration finden Sie hier.
Was die Anwendung derzeit tun kann:
- Die Hauptoperationen für uns werden unterstützt: PostgreSQL-Sicherung über pg_dump, Dateisystemverzeichnissicherung über tar; Operationen mit externem Speicher; rsync zwischen Verzeichnissen; Rotation von Backups (Löschen alter Kopien)
- Rufen Sie ein externes Skript auf
- manuelle Ausführung einer einzelnen Aufgabe
/opt/KristaBackup/KristaBackup.py run make_full_dump - Sie können eine separate Aufgabe oder den gesamten Zeitplan in der 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 Sicherungen nützlich
- kann im Hintergrund im Webapi oder Web-Modus arbeiten
/opt/KristaBackup/KristaBackup.py web start [--api]
Der Unterschied zwischen den Modi: Das Webapi verfügt nicht über eine ordnungsgemäße Weboberfläche, aber die Anwendung reagiert auf Anforderungen einer anderen Instanz. Für den Webmodus müssen Sie eine Flasche und mehrere zusätzliche Pakete installieren. Dies ist beispielsweise nicht überall akzeptabel, z. B. in einer zertifizierten AstraLinux SE.
Über die Weboberfläche können Sie den Status und die Protokolle von Sicherungen der verbundenen Server anzeigen: Die "Webinstanz" fordert über die API Daten von den "Sicherungsinstanzen" an. Der Zugriff auf das Web erfordert eine Autorisierung, der Zugriff auf das Webapi nicht.
Protokolle falsch übergebener Sicherungen sind mit der folgenden Farbe gekennzeichnet: Warnung - gelb, Fehler - rot.
Wenn der Administrator keinen Spickzettel für die Parameter benötigt und die Server-Betriebssysteme homogen sind, können Sie die Datei kompilieren und das fertige Paket verteilen.
Wir vertreiben dieses Dienstprogramm hauptsächlich über Ansible und rollen es zuerst auf einigen der am wenigsten wichtigen Server und nach dem Testen auf allen anderen aus.
Als Ergebnis haben wir ein kompaktes eigenständiges Kopierprogramm erhalten, das automatisiert werden kann und auch von unerfahrenen Administratoren für den Betrieb geeignet ist. Es ist bequem für uns - vielleicht ist es auch für Sie nützlich?