Existen muchos sistemas de respaldo, pero ¿qué hacer si los servidores administrados están dispersos en diferentes regiones y clientes, y se debe utilizar las herramientas del sistema operativo?
Buenas tardes, Habr!
Me llamo Natalia. Soy la líder del grupo de administradores de aplicaciones en NPO "Krista". Somos Ops para el grupo de proyectos de nuestra empresa. Nuestra situación es bastante singular: 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 hacer una copia de seguridad del servidor completo. Solo son importantes los "datos esenciales": la base de datos y ciertos directorios del sistema de archivos. Por supuesto, los clientes tienen (o no tienen) sus propios reglamentos de copias de seguridad y a menudo proporcionan algún almacenamiento externo para guardar las copias de seguridad. En este caso, después de crear la copia de seguridad, nos aseguramos de enviarla al almacenamiento externo.
Durante un tiempo, para los fines de la copia de seguridad, nos las arreglamos con un script en bash, pero a medida que aumentaban las opciones de configuración, también crecía la complejidad de este script, y en un momento dado llegamos a la necesidad de "destruirlo por completo y luego....".
Las soluciones listas no funcionaron por diversas razones: 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, las restricciones de acceso.
Nos pareció que sería más sencillo escribir algo por nuestra cuenta. Al mismo tiempo, queríamos algo que fuera suficiente para nuestra situación durante los próximos N años, pero con la posibilidad de expansión potencial en el futuro.
Las condiciones del problema fueron las siguientes:
- la instancia básica de la copia de seguridad es autónoma, funciona localmente
- el almacenamiento de copias de seguridad y registros siempre se encuentra dentro de la red del cliente
- la instancia consiste en módulos, una especie de "constructor"
- necesitamos compatibilidad con las distribuciones de Linux utilizadas, incluidas las obsoletas, se desea una potencial portabilidad entre plataformas
- para trabajar con la instancia, basta con acceso por ssh, no es necesario abrir puertos adicionales
- máxima simplicidad en la configuración y explotación
- es posible (pero no obligatorio) que exista una instancia separada que permita ver de forma centralizada el estado de las copias de seguridad desde diferentes servidores
Lo que conseguimos se puede ver aquí:
El software está escrito en python3; funciona en Debian, Ubuntu, CentOS, AstraLinux 1.6.
La documentación se encuentra en el directorio docs del repositorio.
Conceptos clave que maneja el sistema:
action – acción que realiza una operación atómica (respaldo de BD, respaldo de un directorio, transferencia del directorio A al directorio B, etc.). Las acciones existentes se encuentran en el directorio core/actions.
task – tarea, conjunto de acciones que describe una "tarea de respaldo" lógica.
schedule – programación, conjunto de tareas con la opción de indicar el tiempo de ejecución de la tarea.
La configuración del respaldo se almacena en un archivo yaml; la estructura general de la configuración:
- configuración general
- sección actions: descripción de las acciones utilizadas en este servidor.
- sección schedule: descripción de todas las tareas (conjuntos de acciones) y el cronograma de su ejecución mediante cron, si se requiere dicha ejecución.
Lo que la aplicación puede hacer en este momento:
- se admiten las operaciones básicas: respaldo de PostgreSQL a través de pg_dump, respaldo de un directorio del sistema de archivos a través de tar; operaciones con almacenamiento externo; rsync entre directorios; rotación de respaldos (eliminación de copias antiguas).
- invocación de un script externo.
- ejecución manual de una tarea individual.
/opt/KristaBackup/KristaBackup.py run make_full_dump - se puede agregar (o quitar) una tarea individual o todo el horario en el crontab.
/opt/KristaBackup/KristaBackup.py enable all - generación de un archivo de activación basado en los resultados del respaldo. Esta función es útil en combinación con Zabbix para el monitoreo de respaldos.
- puede funcionar en segundo plano en modo webapi o web.
/opt/KristaBackup/KristaBackup.py web start [--api]
La diferencia entre los modos: en webapi no hay interfaz web propia, pero la aplicación responde a las solicitudes de otra instancia. Para el modo web, se deben instalar flask y varios paquetes adicionales, lo cual no es aceptable en todas partes, por ejemplo, en AstraLinux SE certificado.
A través de la interfaz web se puede ver el estado y los registros de los respaldos de los servidores conectados: la 'instancia web' solicita datos de las 'instancias de respaldo' a través de la API. El acceso a la web requiere autenticación, el acceso a webapi no.
Los registros de respaldos que no se han completado correctamente se marcan con color: warning – amarillo, error – rojo.
Si el administrador no necesita una referencia sobre los parámetros y los sistemas operativos del servidor son homogéneos, se puede compilar el archivo y distribuir un paquete ya preparado.
Principalmente distribuimos esta utilidad a través de Ansible, implementándola primero en una parte de los servidores menos importantes, y después de probarla, en todos los demás.
Al final, obtuvimos una utilidad de copia compacta y autónoma, que se puede automatizar y es adecuada para ser utilizada incluso por administradores con poca experiencia. A nosotros nos resulta conveniente, ¿quizás a ustedes también les sirva?
Fuente: habr.com
