Hay muchos sistemas de respaldo, pero ¿qué hacer si los servidores atendidos están dispersos en diferentes regiones y clientes y usted necesita conformarse con el sistema operativo?
Buenos días, Hablar!
Mi nombre es Natalia. Soy el líder del equipo de administradores de aplicaciones en NPO Krista. Somos Ops para el grupo de proyectos de nuestra empresa. Tenemos una situación bastante única: instalamos y mantenemos nuestro software tanto en los servidores de nuestra empresa como en los servidores ubicados en los sitios de los clientes. En este caso, no es necesario realizar una copia de seguridad de todo el servidor. Sólo los "datos esenciales" son importantes: el DBMS y los directorios del sistema de archivos individuales. Por supuesto, los clientes tienen (o no tienen) sus propias regulaciones de copia de seguridad y, a menudo, proporcionan algún tipo de almacenamiento externo para almacenar las copias de seguridad allí. En este caso, luego de crear una copia de seguridad, nos aseguramos de enviarla a un almacenamiento externo.
Durante algún tiempo, para fines de respaldo, nos conformamos con un script bash, pero a medida que las opciones de configuración crecieron, la complejidad de este script creció proporcionalmente, y en un momento llegamos a la necesidad de "destruirlo hasta el suelo y luego ...”.
Las soluciones listas para usar no eran adecuadas por varias razones: debido a la necesidad de descentralizar las copias de seguridad, el requisito de almacenar las copias de seguridad localmente en el cliente, la complejidad de la configuración, la sustitución de importaciones, 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 ampliar potencialmente el alcance.
Las condiciones de la tarea fueron las siguientes:
- la instancia de copia de seguridad básica es autónoma y se ejecuta localmente
- El almacenamiento de copias de seguridad y registros siempre está dentro de la red del cliente.
- una instancia consta de módulos, una especie de "constructor"
- Se requiere compatibilidad con las distribuciones actuales de Linux, incluidas las obsoletas, es deseable una posible multiplataforma.
- Para trabajar con la instancia, el acceso vía ssh es suficiente, no es necesario abrir puertos adicionales
- Máxima facilidad de configuración y operación.
- Es posible (pero no necesario) tener una instancia separada que le permita ver de forma centralizada el estado de las copias de seguridad de diferentes servidores.
Puedes ver lo que se nos ocurrió aquí:
El software está escrito en python3; funciona en Debian, Ubuntu, CentOS, AstraLinux 1.6.
La documentación se publica en el directorio de documentos del repositorio.
Conceptos básicos que opera el sistema:
acción: una acción que implementa una operación atómica (copia de seguridad de base de datos, copia de seguridad de directorio, transferencia del directorio A al directorio B, etc.). Las acciones existentes se encuentran en el directorio core/actions.
tarea – tarea, un conjunto de acciones que describen una “tarea de respaldo” lógica
cronograma – cronograma, un conjunto de tareas con una indicación opcional del tiempo de ejecución de la tarea
La configuración de la copia de seguridad se almacena en un archivo yaml; estructura de configuración general:
- Configuración general
- sección de acciones: descripción de las acciones utilizadas en este servidor
- sección de programación: descripción de todas las tareas (conjuntos de acciones) y programación para su lanzamiento mediante cron, si dicho lanzamiento es necesario
Qué puede hacer la aplicación actualmente:
- Las principales operaciones para nosotros son compatibles: copia de seguridad de PostgreSQL mediante pg_dump, copia de seguridad del directorio del sistema de archivos mediante tar; operaciones con almacenamiento externo; rsync entre directorios; rotación de copias de seguridad (eliminación de copias antiguas)
- llamar a un script externo
- ejecución manual de una tarea separada
/opt/KristaBackup/KristaBackup.py run make_full_dump - puede agregar (o eliminar) una sola tarea o la programación completa al 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: webapi no tiene una interfaz web en sí, pero la aplicación responde a 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 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 incorrectas están marcados en color: advertencia – amarillo, error – rojo.
Si el administrador no necesita una hoja de referencia sobre los parámetros y los sistemas operativos del servidor son homogéneos, puede compilar el archivo y distribuir el paquete ya preparado.
Distribuimos esta utilidad principalmente a través de Ansible, implementándola primero en algunos de los servidores menos importantes y, después de probarla, en el resto.
Como resultado, obtuvimos una utilidad de copia compacta e independiente que puede automatizarse y que pueden utilizar incluso administradores sin experiencia. Es conveniente para nosotros, ¿quizás también le resulte útil a usted?
Fuente: habr.com