Esta nota completa el ciclo sobre la copia de seguridad. Se discutirá la organización lógica de un servidor dedicado (o VPS), conveniente para realizar copias de seguridad, y también se ofrecerá una opción para restaurar rápidamente un servidor desde una copia de seguridad sin mucho tiempo de inactividad en caso de un desastre.
Datos iniciales
Un servidor dedicado suele tener al menos dos discos duros que sirven para organizar una matriz RAID de primer nivel (espejo). Esto es necesario para poder continuar operando el servidor si falla un disco. Si se trata de un servidor dedicado normal, puede haber un controlador RAID de hardware independiente con tecnología de almacenamiento en caché activa en SSD, de modo que, además de los discos duros normales, se puedan conectar uno o más SSD. A veces se ofrecen servidores dedicados, en los que los únicos discos locales son SATADOM (discos pequeños, estructuralmente una unidad flash conectada a un puerto SATA), o incluso una unidad flash pequeña normal (8-16 GB) conectada a un puerto interno especial, y la los datos se toman del sistema de almacenamiento, se conectan a través de una red de almacenamiento dedicada (Ethernet 10G, FC, etc.) y hay servidores dedicados que se cargan directamente desde el sistema de almacenamiento. No consideraré tales opciones, ya que en tales casos la tarea de realizar una copia de seguridad del servidor pasa sin problemas al especialista que mantiene el sistema de almacenamiento, generalmente existen varias tecnologías patentadas para crear instantáneas, deduplicación integrada y otras alegrías del administrador del sistema. , discutido en las partes anteriores de esta serie. El volumen de la matriz de discos de un servidor dedicado puede alcanzar varias decenas de terabytes, dependiendo de la cantidad y el tamaño de los discos conectados al servidor. En el caso de los VPS, los volúmenes son más modestos: normalmente no superan los 100 GB (pero también hay más), y las tarifas de dichos VPS pueden ser fácilmente más caras que las de los servidores dedicados más baratos del mismo proveedor de alojamiento. Un VPS suele tener un disco, porque debajo habrá un sistema de almacenamiento (o algo hiperconvergente). En ocasiones un VPS dispone de varios discos con diferentes características, para distintos fines:
- sistema pequeño: para instalar el sistema operativo;
- grande: almacenar datos del usuario.
Cuando reinstala el sistema usando el panel de control, el disco con los datos del usuario no se sobrescribe, pero el disco del sistema se rellena por completo. Además, en el caso de un VPS, el proveedor de alojamiento puede ofrecer un botón que toma una instantánea del estado del VPS (o disco), pero si instala su propio sistema operativo u olvida activar el servicio deseado dentro del VPS, algunos Es posible que aún se pierdan algunos de los datos. Además del botón, normalmente se ofrece un servicio de almacenamiento de datos, la mayoría de las veces de forma muy limitada. Normalmente, se trata de una cuenta con acceso a través de FTP o SFTP, a veces junto con SSH, con un shell simplificado (por ejemplo, rbash) o una restricción en la ejecución de comandos a través de claves_autorizadas (a través de ForcedCommand).
Un servidor dedicado está conectado a la red mediante dos puertos con una velocidad de 1 Gbps, en ocasiones pueden ser tarjetas con una velocidad de 10 Gbps. VPS suele tener una interfaz de red. La mayoría de las veces, los centros de datos no limitan la velocidad de la red dentro del centro de datos, pero limitan la velocidad de acceso a Internet.
La carga típica de un servidor dedicado o VPS es un servidor web, una base de datos y un servidor de aplicaciones. En ocasiones se pueden instalar varios servicios auxiliares adicionales, incluso para un servidor web o base de datos: motor de búsqueda, sistema de correo, etc.
Un servidor especialmente preparado actúa como espacio para almacenar copias de seguridad, hablaremos de ello con más detalle más adelante.
Organización lógica del sistema de discos.
Si tiene un controlador RAID o un VPS con un disco y no hay preferencias especiales para el funcionamiento del subsistema de disco (por ejemplo, un disco rápido separado para una base de datos), todo el espacio libre se divide de la siguiente manera: una partición se crea, y se crea un grupo de volúmenes LVM encima de él, se crean varios volúmenes en él: 2 pequeños del mismo tamaño, utilizados como sistema de archivos raíz (cambiados uno por uno durante las actualizaciones para la posibilidad de una reversión rápida, la idea fue tomada de la distribución Calculate Linux), otra es para la partición de intercambio, el resto del espacio libre se divide en pequeños volúmenes, utilizados como sistema de archivos raíz para contenedores completos, discos para máquinas virtuales, archivos sistemas para cuentas en /home (cada cuenta tiene su propio sistema de archivos), sistemas de archivos para contenedores de aplicaciones.
Nota importante: los volúmenes deben ser completamente autónomos, es decir. no deben depender entre sí ni del sistema de archivos raíz. En el caso de máquinas virtuales o contenedores, este punto se observa de forma automática. Si se trata de contenedores de aplicaciones o directorios de inicio, debería pensar en separar los archivos de configuración del servidor web y otros servicios de forma que se eliminen al máximo las dependencias entre los volúmenes. Por ejemplo, cada sitio se ejecuta desde su propio usuario, los archivos de configuración del sitio están en el directorio de inicio del usuario, en la configuración del servidor web, los archivos de configuración del sitio no se incluyen a través de /etc/nginx/conf.d/.conf y, por ejemplo, /home//configs/nginx/*.conf
Si hay varios discos, puede crear una matriz RAID de software (y configurar su almacenamiento en caché en un SSD, si es necesario y posible), sobre la cual puede construir LVM de acuerdo con las reglas propuestas anteriormente. También en este caso, puede usar ZFS o BtrFS, pero debería pensarlo dos veces: ambos requieren un enfoque mucho más serio en cuanto a los recursos y, además, ZFS no está incluido en el kernel de Linux.
Independientemente del esquema utilizado, siempre vale la pena estimar de antemano la velocidad aproximada de escritura de los cambios en los discos y luego calcular la cantidad de espacio libre que se reservará para crear instantáneas. Por ejemplo, si nuestro servidor escribe datos a una velocidad de 10 megabytes por segundo y el tamaño de toda la matriz de datos es de 10 terabytes, el tiempo de sincronización puede alcanzar un día (22 horas; esta es la cantidad que se transferirá dicho volumen). a través de la red 1 Gbps) - vale la pena reservar unos 800 GB . En realidad, la cifra será menor, puedes dividirla con seguridad por el número de volúmenes lógicos.
Dispositivo servidor de almacenamiento de respaldo
La principal diferencia entre un servidor para almacenar copias de seguridad son sus discos grandes, económicos y relativamente lentos. Dado que los HDD modernos ya han superado la barra de 10 TB en un disco, es necesario utilizar sistemas de archivos o RAID con sumas de verificación, porque durante la reconstrucción de la matriz o la restauración del sistema de archivos (¡varios días!) el segundo disco puede fallar debido al aumento de carga. En discos con una capacidad de hasta 1 TB esto no era tan sensible. Para simplificar la descripción, asumo que el espacio en disco se divide en dos partes de aproximadamente el mismo tamaño (nuevamente, por ejemplo, usando LVM):
- volúmenes correspondientes a los servidores utilizados para almacenar los datos de los usuarios (en ellos se desplegará la última copia de seguridad realizada para su verificación);
- volúmenes utilizados como repositorios de BorgBackup (los datos para las copias de seguridad irán directamente aquí).
El principio de funcionamiento es que se crean volúmenes separados para cada servidor para los repositorios de BorgBackup, donde irán los datos de los servidores de combate. Los repositorios funcionan en modo de solo agregar, lo que elimina la posibilidad de eliminar datos intencionalmente, y debido a la deduplicación y limpieza periódica de los repositorios de copias de seguridad antiguas (quedan copias anuales, mensuales durante el último año, semanales durante el último mes, diarias durante el la semana pasada, posiblemente en casos especiales - cada hora para el último día: total 24 + 7 + 4 + 12 + anual - aproximadamente 50 copias para cada servidor).
Los repositorios de BorgBackup no habilitan el modo de solo agregar; en su lugar, se usa un ForcedCommand en .ssh/authorized_keys, algo como esto:
from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......La ruta especificada contiene un script contenedor encima de borg, que, además de iniciar el binario con parámetros, también inicia el proceso de restauración de la copia de seguridad después de que se eliminan los datos. Para hacer esto, el script contenedor crea un archivo de etiquetas al lado del repositorio correspondiente. La última copia de seguridad realizada se restaura automáticamente en el volumen lógico correspondiente una vez completado el proceso de llenado de datos.
Este diseño le permite limpiar periódicamente copias de seguridad innecesarias y también evita que los servidores de combate eliminen cualquier cosa en el servidor de almacenamiento de copias de seguridad.
Proceso de copia de seguridad
El iniciador de la copia de seguridad es el servidor dedicado o el propio VPS, ya que este esquema da más control sobre el proceso de copia de seguridad por parte de este servidor. Primero, se toma una instantánea del estado del sistema de archivos raíz activo, que se monta y se carga usando BorgBackup en el servidor de almacenamiento de respaldo. Una vez completada la captura de datos, la instantánea se desmonta y se elimina.
Si hay una base de datos pequeña (hasta 1 GB para cada sitio), se realiza un volcado de la base de datos, que se guarda en el volumen lógico correspondiente, donde se ubica el resto de los datos del mismo sitio, pero para que el volcado sea no accesible a través del servidor web. Si las bases de datos son grandes, debe configurar la eliminación de datos "en caliente", por ejemplo, usando xtrabackup para MySQL, o trabajar con WAL con archive_command en PostgreSQL. En este caso, la base de datos se restaurará por separado de los datos del sitio.
Si se utilizan contenedores o máquinas virtuales, debe configurar qemu-guest-agent, CRIU u otras tecnologías necesarias. En otros casos, la mayoría de las veces no se necesitan configuraciones adicionales: simplemente creamos instantáneas de volúmenes lógicos, que luego se procesan de la misma manera que una instantánea del estado del sistema de archivos raíz. Una vez tomados los datos, las imágenes se eliminan.
Se realizan más trabajos en el servidor de almacenamiento de respaldo:
- se comprueba la última copia de seguridad realizada en cada repositorio,
- se comprueba la presencia de un archivo de marcas, que indica que el proceso de recopilación de datos se ha completado,
- los datos se expanden al volumen local correspondiente,
- el archivo de etiquetas se elimina
Proceso de recuperación del servidor
Si el servidor principal muere, se inicia un servidor dedicado similar, que arranca desde alguna imagen estándar. Lo más probable es que la descarga se realice a través de la red, pero el técnico del centro de datos que configura el servidor puede copiar inmediatamente esta imagen estándar a uno de los discos. La descarga se produce en la RAM, después de lo cual comienza el proceso de recuperación:
- se realiza una solicitud para adjuntar un dispositivo de bloque mediante iscsinbd u otro protocolo similar a un volumen lógico que contiene el sistema de archivos raíz del servidor fallecido; Dado que el sistema de archivos raíz debe ser pequeño, este paso debería completarse en unos minutos. El gestor de arranque también se restaura;
- se recrea la estructura de los volúmenes lógicos locales, los volúmenes lógicos se adjuntan desde el servidor de respaldo mediante el módulo del kernel dm_clone: comienza la recuperación de datos y los cambios se escriben inmediatamente en los discos locales
- se inicia un contenedor con todos los discos físicos disponibles: la funcionalidad del servidor se restablece por completo, pero con un rendimiento reducido;
- una vez completada la sincronización de datos, los volúmenes lógicos del servidor de respaldo se desconectan, el contenedor se apaga y el servidor se reinicia;
Después de reiniciar, el servidor tendrá todos los datos que estaban allí en el momento en que se creó la copia de seguridad y también incluirá todos los cambios que se realizaron durante el proceso de restauración.
Otros artículos de la serie.
Copia de seguridad Parte 7: Conclusiones
Los invito a discutir la opción propuesta en los comentarios, ¡gracias por su atención!
Fuente: habr.com