Bon après-midi, Habr !
Mon nom est Natalya. Je suis le chef d'équipe du groupe des administrateurs d'application chez NPO Krista. Nous sommes Ops pour un groupe de projets de notre entreprise. Nous avons une situation assez particulière: nous installons et maintenons nos logiciels à la fois sur les serveurs de notre entreprise et sur les serveurs situés chez les clients. Dans ce cas, il n'est pas nécessaire de sauvegarder l'intégralité du serveur. Seules les "données essentielles" sont importantes: le SGBD et les répertoires individuels du système de fichiers. Bien sûr, les clients ont (ou n'ont pas) leurs propres règles de sauvegarde et fournissent souvent une sorte de stockage externe pour y stocker des sauvegardes. Dans ce cas, après avoir créé une sauvegarde, nous assurons l'envoi vers un stockage externe.
Pendant un certain temps, à des fins de sauvegarde, nous nous sommes débrouillés avec un script bash, mais au fur et à mesure que les options se développaient, la complexité de ce script augmentait proportionnellement, et à un moment donné, nous en sommes venus à la nécessité de "le détruire au sol, puis ....".
Les solutions prêtes à l'emploi n'ont pas fonctionné pour diverses raisons: en raison de la nécessité de décentraliser les sauvegardes, de l'obligation de stocker les sauvegardes localement chez le client, de la complexité de la configuration, de la substitution d'importations et des restrictions d'accès.
Il nous a semblé qu'il était plus facile d'écrire quelque chose de notre cru. En même temps, je voulais obtenir quelque chose qui suffirait à notre situation pour les N prochaines années, mais avec la possibilité d'une extension potentielle du périmètre.
Les conditions du problème étaient les suivantes:
- l'instance de sauvegarde de base est autonome, fonctionne localement
- stockage des sauvegardes et des journaux toujours dans le réseau du client
- – «»
- Linux, ,
- ssh,
- ( ) ,
Vous pouvez voir ce que nous avons ici: github.com/javister/krista-backup Le
logiciel est écrit en python3; fonctionne sur Debian, Ubuntu, CentOS, AstraLinux 1.6.
La documentation est disponible dans le répertoire docs du référentiel.
Concepts de base utilisés par le système:
action - une action qui implémente une opération atomique (sauvegarde de base de données, sauvegarde de répertoire, transfert du répertoire A vers le répertoire B, etc.). Les actions existantes se trouvent dans la
tâche du répertoire core / actions - une tâche, un ensemble d'actions décrivant une
planification logique de "tâche de sauvegarde" - une planification, un ensemble de tâches avec une heure d'exécution de tâche facultative. La
configuration de sauvegarde est stockée dans un fichier yaml; structure de configuration générale:
- Réglages généraux
- section actions: description des actions utilisées sur ce serveur
- la section calendrier: une description de toutes les tâches (ensembles d'actions) et le calendrier de leur lancement par la couronne, si un tel lancement est requis
Un exemple de configuration peut être trouvé ici
Ce que l'application peut faire pour le moment:
- les principales opérations pour nous sont prises en charge: sauvegarde PostgreSQL via pg_dump, sauvegarde du répertoire du système de fichiers via tar; opérations avec stockage externe; rsync entre les répertoires; rotation des sauvegardes (suppression des anciennes copies)
- appeler un script externe
- exécution manuelle d'une seule tâche
/opt/KristaBackup/KristaBackup.py run make_full_dump - vous pouvez ajouter (ou supprimer) une tâche distincte ou la planification entière dans le crontab
/opt/KristaBackup/KristaBackup.py enable all - générer un fichier de déclenchement basé sur les résultats de la sauvegarde. Cette fonction est utile en conjonction avec Zabbix pour surveiller les sauvegardes
- peut fonctionner en arrière-plan en webapi ou en mode web
/opt/KristaBackup/KristaBackup.py web start [--api]
La différence entre les modes: la webapi ne dispose pas d'une interface Web appropriée, mais l'application répond aux demandes d'une autre instance. Pour le mode Web, vous devez installer flask et plusieurs packages supplémentaires, ce qui n'est pas acceptable partout, par exemple dans un AstraLinux SE certifié.
Via l'interface web, vous pouvez visualiser l'état et les logs des sauvegardes des serveurs connectés: "l'instance web" demande des données aux "instances de sauvegarde" via l'API. L'accès au Web nécessite une autorisation, mais pas l'accès à la webapi.
Les journaux des sauvegardes incorrectes sont indiqués en couleur: avertissement - jaune, erreur - rouge.
Si l'administrateur n'a pas besoin d'une aide-mémoire sur les paramètres et que les systèmes d'exploitation du serveur sont homogènes, vous pouvez compiler le fichier et distribuer le package prêt à l'emploi.
Nous distribuons cet utilitaire principalement via Ansible, en le déployant d'abord sur certains des serveurs les moins importants, et après avoir testé sur tous les autres.
En conséquence, nous avons obtenu un utilitaire de copie compact et autonome, pouvant être automatisé et pouvant être utilisé même par des administrateurs inexpérimentés. Cela nous convient - peut-être que cela vous sera utile aussi?