Il existe de nombreux systèmes de sauvegarde, mais que faire si les serveurs servis sont dispersés dans différentes régions et clients et que vous devez vous contenter du système d'exploitation ?
Bon après-midi, Charme!
Je m'appelle Natalia. Je suis le chef d'équipe du groupe des administrateurs d'applications chez NPO Krista. Nous sommes Ops pour le groupe de projet de notre entreprise. Nous sommes dans une situation assez unique : nous installons et maintenons nos logiciels aussi bien sur les serveurs de notre entreprise que 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 : les répertoires du SGBD et du système de fichiers individuel. Bien entendu, les clients ont (ou n'ont pas) leurs propres réglementations en matière de sauvegarde et fournissent souvent une sorte de stockage externe pour y stocker les 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 contentés d'un script bash, mais à mesure que les options de configuration augmentaient, la complexité de ce script augmentait proportionnellement, et à un moment donné, nous sommes arrivés à la nécessité de « le détruire complètement, puis …”
Les solutions toutes faites n'étaient pas adaptées pour diverses raisons : en raison de la nécessité de décentraliser les sauvegardes, de la nécessité de stocker les sauvegardes localement chez le client, de la complexité de la configuration, de la substitution des importations, des restrictions d'accès.
Il nous a semblé qu'il était plus facile d'écrire quelque chose par nous-mêmes. En même temps, je voulais obtenir quelque chose qui serait suffisant pour notre situation pour les N prochaines années, mais avec la possibilité d'élargir potentiellement la portée.
Les conditions de la tâche étaient les suivantes :
- l'instance de sauvegarde de base est autonome et s'exécute localement
- le stockage des sauvegardes et des journaux se fait toujours au sein du réseau du client
- une instance est constituée de modules - une sorte de « constructeur »
- la compatibilité avec les distributions Linux actuelles est requise, y compris les distributions obsolètes, un potentiel multiplateforme est souhaitable
- Pour travailler avec l'instance, l'accès via ssh est suffisant ; l'ouverture de ports supplémentaires n'est pas nécessaire
- facilité maximale de configuration et d'utilisation
- il est possible (mais pas nécessaire) d'avoir une instance distincte qui vous permet de visualiser de manière centralisée l'état des sauvegardes de différents serveurs
Vous pouvez voir ce que nous avons trouvé ici :
Le logiciel est écrit en python3 ; fonctionne sur Debian, Ubuntu, CentOS, AstraLinux 1.6.
La documentation est publiée dans le répertoire docs du référentiel.
Concepts de base sur lesquels le système fonctionne :
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 le répertoire core/actions
tâche – tâche, un ensemble d’actions décrivant une « tâche de sauvegarde » logique
planning – planning, un ensemble de tâches avec une indication facultative du temps d’exécution de la tâche
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
- section planning : description de toutes les tâches (ensembles d'actions) et planning de leur lancement par cron, si un tel lancement est requis
Ce que l'application peut actuellement faire :
- 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 tâche distincte
/opt/KristaBackup/KristaBackup.py run make_full_dump - vous pouvez ajouter (ou supprimer) une seule tâche ou l'ensemble du planning à la crontab
/opt/KristaBackup/KristaBackup.py enable all - générer un fichier déclencheur basé sur les résultats de la sauvegarde. Cette fonction est utile en conjonction avec Zabbix pour surveiller les sauvegardes
- peut travailler en arrière-plan en mode webapi ou web
/opt/KristaBackup/KristaBackup.py web start [--api]
La différence entre les modes : webapi n'a pas d'interface web elle-même, mais l'application répond aux requêtes d'une autre instance. Pour le mode Web, vous devez installer flask et plusieurs packages supplémentaires, et cela n'est pas acceptable partout, par exemple dans AstraLinux SE certifié.
Grâce à l'interface web, vous pouvez visualiser l'état et les journaux 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, ce qui n’est pas le cas de l’accès à Webapi.
Les journaux de sauvegardes incorrectes sont marqués en couleur : avertissement – jaune, erreur – rouge.
Si l'administrateur n'a pas besoin d'aide-mémoire sur les paramètres et que les systèmes d'exploitation des serveurs 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, puis après des tests sur tous les autres.
En conséquence, nous avons reçu un utilitaire de copie compact et autonome qui peut être automatisé et utilisé même par des administrateurs inexpérimentés. C'est pratique pour nous - peut-être que cela vous sera utile aussi ?
Source: habr.com