Esta nota cierra el ciclo sobre copias de seguridad. Se discutirá la organización lógica de un servidor dedicado (o VPS), conveniente para la copia de seguridad, y se propondrá una opción para la rápida recuperación del servidor a partir de una copia de seguridad sin tiempos de inactividad significativos en caso de una emergencia.
Datos de entrada
Un servidor dedicado generalmente tiene al menos dos discos duros, que sirven para organizar un arreglo RAID de primer nivel (espejo). Esto es necesario para poder continuar la operación del servidor si uno de los discos falla. Si se trata de un servidor dedicado normal, puede haber un controlador RAID de hardware independiente, con una tecnología de almacenamiento en caché activa en SSD, de modo que, además de los discos duros normales, se puede conectar uno o más SSD. A veces se ofrecen servidores dedicados en los que solo hay discos SATADOM (discos pequeños constructivamente similares a una memoria flash, conectados a un puerto SATA), o incluso una pequeña memoria USB (8-16 GB) conectada a un puerto interno especial, mientras que los datos se obtienen de un sistema de almacenamiento conectado a través de una red de almacenamiento dedicada (Ethernet 10G, FC, etc.), y hay servidores dedicados que arrancan directamente desde el sistema de almacenamiento. No consideraré tales opciones, ya que en estos casos la tarea de hacer copias de seguridad del servidor pasa al especialista que gestiona el sistema de almacenamiento; generalmente hay varias tecnologías patentadas para crear instantáneas, deduplicación incorporada y otras comodidades para administradores de sistemas, como se discutió en partes anteriores de este ciclo. La capacidad del arreglo de discos de un servidor dedicado puede alcanzar varios decenas de terabytes, dependiendo del número y la capacidad de los discos conectados al servidor. En el caso de VPS, las capacidades son más modestas: generalmente no más de 100 GB (aunque pueden ser mayores), y las tarifas para esos VPS pueden ser fácilmente más altas que las de los servidores dedicados más baratos del mismo proveedor. En los VPS, a menudo hay solo un disco, porque bajo él habrá un sistema de almacenamiento (o algo hiperconvergente). A veces, los VPS tienen varios discos con diferentes características, para diferentes propósitos:
- pequeño sistema - para la instalación del sistema operativo;
- grande - almacenamiento de datos del usuario.
Al reinstalar el sistema a través del panel de control, el disco con los datos del usuario no se borra, mientras que el sistema se reinstala por completo. Además, en el caso de un VPS, el proveedor puede ofrecer un botón que toma una instantánea del estado del VPS (o del disco); sin embargo, si se instala un sistema operativo personalizado o se olvida activar el servicio necesario dentro del VPS, parte de los datos puede aún perderse. Además del botón, normalmente se ofrece un servicio de almacenamiento de datos, que suele estar fuertemente limitado. Generalmente se trata de una cuenta con acceso a través del protocolo FTP o SFTP, a veces junto con SSH, con un shell restringido (por ejemplo, rbash) o restricciones en la ejecución de comandos a través de authorized_keys (mediante ForcedCommand).
Un servidor dedicado está conectado a la red a través de dos puertos a una velocidad de 1 Gbps; en ocasiones, pueden ser tarjetas con velocidad de 10 Gbps. Un VPS generalmente tiene una única interfaz de red. Por lo general, los centros de datos no limitan la velocidad dentro del centro de datos, pero sí restringen la velocidad de acceso a Internet.
La carga típica de un servidor dedicado o VPS incluye un servidor web, una base de datos y un servidor de aplicaciones. A veces pueden instalarse varios servicios auxiliares adicionales, incluyendo para el servidor web o la base de datos: motor de búsqueda, sistema de correo, etc.
El espacio para el almacenamiento de copias de seguridad se realiza en un servidor especialmente preparado, del cual se hablará más adelante.
Organización lógica del sistema de discos
Si hay un controlador RAID, o se trata de un VPS con un solo disco, y no hay preferencias particulares sobre el funcionamiento del subsistema de disco (por ejemplo, un disco rápido separado para la base de datos), todo el espacio libre se divide de la siguiente manera: se crea una partición, sobre la cual se crea un grupo de volúmenes LVM, en el que se crean varios volúmenes: 2 pequeños de igual tamaño, que se utilizan como sistema de archivos raíz (se alternan en las actualizaciones para permitir un retroceso rápido, idea tomada de la distribución Calculate Linux), otro - para la partición de intercambio, el resto del espacio libre se divide en pequeños volúmenes, que se utilizan como sistema de archivos raíz para contenedores completos, discos para máquinas virtuales, sistemas de archivos 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 autosuficientes, es decir, no deben depender ni entre sí ni del sistema de archivos raíz. En el caso de las máquinas virtuales o contenedores, este punto se cumple automáticamente. Sin embargo, si se trata de contenedores de aplicaciones o directorios de inicio, vale la pena considerar la separación de los archivos de configuración del servidor web y otros servicios de tal manera que se eliminen al máximo las dependencias entre los volúmenes. Por ejemplo, cada sitio opera con 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 se incluyen los archivos de configuración de los sitios no a través de /etc/nginx/conf.d/.conf, sino, por ejemplo, /home//configs/nginx/*.conf
Si hay varios discos, se puede crear un arreglo RAID por software (y configurarlo para que utilice caché en SSD, si hay necesidad y capacidad), sobre el cual se puede construir LVM siguiendo las reglas propuestas anteriormente. También en este caso se pueden utilizar ZFS o BtrFS, pero aquí hay que pensarlo varias veces: ambos requieren un enfoque mucho más serio hacia los recursos, además, ZFS no viene incluido con el núcleo de Linux.
Independientemente del esquema utilizado, siempre es recomendable estimar la velocidad de escritura de los cambios en los discos y luego calcular el tamaño del espacio libre que se reservará para la creación de instantáneas. Por ejemplo, si nuestro servidor escribe datos a una velocidad de 10 megabytes por segundo, y el tamaño total del conjunto de datos es de 10 terabytes, el tiempo de sincronización puede alcanzar un día (22 horas — ese es el tiempo que tomará transferir tal volumen a través de una red de 1 Gbps) — se debería reservar aproximadamente 800 GB. En realidad, esta cifra será menor; se puede dividir sin problemas entre el número de volúmenes lógicos.
Dispositivo del servidor de almacenamiento de copias de seguridad
La principal diferencia entre un servidor para almacenamiento de copias de seguridad son los discos grandes, económicos y relativamente lentos. Dado que los HDD modernos ya han superado los 10 TB en un solo disco, es esencial el uso de sistemas de archivos o RAID con sumas de verificación, porque durante el tiempo de reestructuración del conjunto o recuperación del sistema de archivos (¡varios días!) puede fallar el segundo disco por la carga adicional. En discos de hasta 1 TB, esto no era tan crítico. Para simplificar la descripción, supongo que el espacio en disco está dividido en dos partes aproximadamente iguales (de nuevo, por ejemplo, utilizando LVM):
- volúmenes que corresponden a los servidores utilizados para almacenar datos de usuarios (en ellos se desplegará la última copia de seguridad realizada para su verificación);
- volúmenes utilizados como repositorios de BorgBackup (aquí se almacenarán directamente los datos para copias de seguridad).
El principio de funcionamiento consiste en que se crean volúmenes separados para cada servidor como repositorios de BorgBackup, donde se almacenarán los datos de los servidores en producción. Los repositorios operan en modo de solo adición, lo que excluye la posibilidad de eliminación intencionada de datos, y gracias a la deduplicación y limpieza periódica de los repositorios de copias de seguridad antiguas (se mantienen copias anuales, mensuales del último año, semanales del último mes, diarias de la última semana, posiblemente — en casos especiales — horarias del último día: un total de 24 + 7 + 4 + 12 + anuales — aproximadamente 50 copias para cada servidor).
En los repositorios de BorgBackup no se activa el modo de solo adición, en su lugar se utiliza ForcedCommand en .ssh/authorized_keys de esta manera:
from="dirección del servidor",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/nombre_servidor/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......En la ruta indicada se encuentra un script envoltorio sobre borg, que, además de ejecutar el binario con parámetros, también inicia el proceso de restauración de la copia de seguridad tras la finalización de la extracción de datos. Para ello, el script envoltorio crea un archivo indicador junto al repositorio correspondiente. La última copia de seguridad realizada se restaura automáticamente en el volumen lógico correspondiente tras la finalización del proceso de carga de datos.
Esta construcción permite limpiar periódicamente las copias de seguridad innecesarias y evita que los servidores en producción eliminen algo en el servidor de almacenamiento de copias de seguridad.
Proceso de copia de seguridad
El iniciador de la copia de seguridad es el propio servidor dedicado o VPS, ya que este esquema proporciona un mayor control sobre el proceso de copia de seguridad desde ese servidor. Primero se toma una instantánea del estado del sistema de archivos raíz activo, que se monta y se carga con BorgBackup en el servidor de almacenamiento de copias de seguridad. Tras la finalización de la extracción de datos, la instantánea se desmonta y se elimina.
En caso de existir una base de datos pequeña (hasta 1 GB por cada sitio), se realiza un volcado de la base de datos, que se guarda en el volumen lógico correspondiente, donde se encuentran los demás datos de ese mismo sitio, pero de tal manera que el volcado no sea accesible a través del servidor web. Si las bases de datos son grandes, se debe configurar la extracción de datos "caliente", por ejemplo, mediante xtrabackup para MySQL, o utilizando el comando de archivo con WAL 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, se debe configurar qemu-guest-agent, CRIU u otras tecnologías necesarias. En otros casos, generalmente no se requerirán configuraciones adicionales: simplemente se crean instantáneas de los volúmenes lógicos, que luego se procesan de manera similar a la instantánea del estado del sistema de archivos raíz. Tras la extracción de datos, las instantáneas se eliminan.
El trabajo posterior se lleva a cabo en el servidor de almacenamiento de copias de seguridad:
- se comprueba la última copia de seguridad realizada en cada repositorio,
- se verifica la existencia de un archivo de etiqueta que indique que el proceso de recuperación de datos ha finalizado,
- se despliegan los datos en el volumen local correspondiente,
- se elimina el archivo de etiqueta
Proceso de recuperación de la operatividad del servidor
Si el servidor principal falla, se inicia un servidor dedicado equivalente que arranca desde una imagen estándar. Es probable que el arranque se realice a través de la red; sin embargo, el técnico del centro de datos que configura el servidor puede copiar inmediatamente esta imagen estándar en uno de los discos. La carga se realiza en la memoria RAM, y luego se inicia el proceso de recuperación:
- se envía una solicitud para conectar el dispositivo de bloques a través de iscsinbd u otro protocolo similar de volumen lógico que contenga el sistema de archivos raíz del servidor fallido; dado que el sistema de archivos raíz debe ser pequeño, esta etapa debe completarse en unos minutos. También se lleva a cabo la recuperación del cargador de arranque;
- se recrea la estructura de volúmenes lógicos locales, se adjuntan los volúmenes lógicos del servidor de copias de seguridad utilizando el módulo del núcleo dm_clone: comienza la recuperación de datos, y los cambios se registran de inmediato en los discos locales
- se inicia un contenedor con todos los discos físicos disponibles — se restaura completamente la operatividad del servidor, aunque con un rendimiento reducido;
- una vez finalizada la sincronización de datos, se desconectan los volúmenes lógicos del servidor de copias de seguridad, se apaga el contenedor y se reinicia el servidor;
Después del reinicio, el servidor tendrá todos los datos que existían en el momento de crear la copia de seguridad, además de incluir todos los cambios que se realizaron durante el proceso de recuperación.
Otros artículos del ciclo
Copia de seguridad, parte 7: Conclusiones
Invito a discutir la opción propuesta en los comentarios, gracias por su atención.
Fuente: habr.com
