Buenas tardes, Habr !
Mi nombre es Natalya. Soy el líder de equipo del grupo de administradores de aplicaciones en NPO Krista. Somos Ops para un grupo de proyectos de nuestra empresa. Tenemos una situación bastante peculiar: instalamos y mantenemos nuestro software tanto en los servidores de nuestra empresa como en los servidores ubicados en las instalaciones de los clientes. En este caso, no es necesario realizar una copia de seguridad de todo el servidor. Solo los "datos esenciales" son importantes: el DBMS y los directorios individuales del sistema de archivos. Por supuesto, los clientes tienen (o no tienen) sus propias regulaciones de respaldo y, a menudo, brindan algún tipo de almacenamiento externo para almacenar los respaldos allí. En este caso, después de crear una copia de seguridad, proporcionamos el envío al almacenamiento externo.
Por un tiempo, para propósitos de respaldo, nos las arreglamos con un script bash, pero a medida que las opciones crecían, la complejidad de este script crecía proporcionalmente, y en un momento llegamos a la necesidad de "destruirlo por completo y luego ...".
Las soluciones listas para usar no funcionaron por varias razones: debido a la necesidad de descentralizar las copias de seguridad, la obligación de almacenar las copias de seguridad localmente en el cliente, la complejidad de la configuración, la sustitución de importaciones y las restricciones de acceso.
Nos pareció que era más fácil escribir algo propio. Al mismo tiempo, quería conseguir algo que fuera suficiente para nuestra situación durante los próximos N años, pero con la posibilidad de una posible expansión del alcance.
Las condiciones del problema fueron las siguientes:
- la instancia de respaldo básica es autónoma, funciona localmente
- almacenamiento de copias de seguridad y registros siempre dentro de la red del cliente
- – «»
- Linux, ,
- ssh,
- ( ) ,
Puedes ver lo que tenemos aquí: github.com/javister/krista-backup El
software está escrito en python3; funciona en Debian, Ubuntu, CentOS, AstraLinux 1.6.
La documentación está disponible en el directorio de documentos del repositorio.
Conceptos básicos utilizados por el sistema:
acción: una acción que implementa una operación atómica (respaldo de la base de datos, respaldo del directorio, transferencia del directorio A al directorio B, etc.). Las acciones existentes se encuentran en la
tarea del directorio core / actions - una tarea, un conjunto de acciones que describen una programación lógica de "tarea de respaldo"
- un programa, un conjunto de tareas con un tiempo de ejecución de tareas opcional.La
configuración de respaldo se almacena en un archivo yaml; estructura de configuración general:
- Configuración general
- acciones de la sección: descripción de las acciones utilizadas en este servidor
- la sección de programación: una descripción de todas las tareas (conjuntos de acciones) y la programación para su lanzamiento por parte de la corona, si tal lanzamiento es necesario
Puede encontrar un ejemplo de una configuración aquí
Lo que la aplicación puede hacer en este momento:
- las operaciones principales para nosotros son compatibles: copia de seguridad de PostgreSQL a través de pg_dump, copia de seguridad del directorio del sistema de archivos a través de tar; operaciones con almacenamiento externo; rsync entre directorios; rotación de copias de seguridad (eliminar copias antiguas)
- llamar script externo
- ejecución manual de una sola tarea
/opt/KristaBackup/KristaBackup.py run make_full_dump - puede agregar (o eliminar) una tarea separada o el programa completo en el crontab
/opt/KristaBackup/KristaBackup.py enable all - generar un archivo de activación basado en los resultados de la copia de seguridad. Esta función es útil junto con Zabbix para monitorear copias de seguridad
- puede funcionar en segundo plano en modo webapi o web
/opt/KristaBackup/KristaBackup.py web start [--api]
La diferencia entre los modos: el webapi no tiene una interfaz web adecuada, pero la aplicación responde a las solicitudes de otra instancia. Para el modo web, necesita instalar flask y varios paquetes adicionales, y esto no es aceptable en todas partes, por ejemplo, en un AstraLinux SE certificado.
A través de la interfaz web, puede ver el estado y los registros de las copias de seguridad de los servidores conectados: la "instancia web" solicita datos de las "instancias de copia de seguridad" a través de la API. El acceso a la web requiere autorización, el acceso a webapi no.
Los registros de copias de seguridad pasadas incorrectamente están marcados con color: advertencia - amarillo, error - rojo.
Si el administrador no necesita una hoja de trucos sobre los parámetros y los sistemas operativos del servidor son homogéneos, puede compilar el archivo y distribuir el paquete listo para usar.
Distribuimos esta utilidad principalmente a través de Ansible, lanzándola primero a algunos de los servidores menos importantes y después de probarla a todos los demás.
Como resultado, obtuvimos una utilidad de copia compacta e independiente, apta para la automatización y adecuada para su funcionamiento incluso por administradores sin experiencia. Es conveniente para nosotros, ¿quizás también sea útil para usted?