Copia de seguridad Parte 7: Conclusiones

Esta nota completa el ciclo de respaldo. Hablará sobre la organización lógica de un servidor dedicado (o VPS), conveniente para la copia de seguridad, y también ofrecerá la opción de restaurar rápidamente el servidor desde una copia de seguridad sin ningún tiempo de inactividad en caso de accidente.

Datos de origen

Un servidor dedicado a menudo tiene al menos dos discos duros que se utilizan para organizar una matriz RAID del primer nivel (espejo). Esto es necesario para poder continuar con el servidor si falla una unidad. Si se trata de un servidor dedicado ordinario, puede haber un controlador RAID de hardware separado con tecnología de almacenamiento en caché activa en los 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 solo SATADOM está presente desde discos locales (discos pequeños, estructuralmente, una unidad flash USB conectada al puerto SATA), o incluso una unidad flash USB pequeña (8-16 GB) común conectada a un puerto interno especial, y los datos se toman del sistema de almacenamiento conectado 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 hacer una copia de seguridad del servidor pasa sin problemas al especialista que da servicio al sistema de almacenamiento, por lo general, existen varias tecnologías patentadas para crear instantáneas de estado, deduplicación incorporada y otras alegrías del administrador del sistema discutidas 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 volumen de discos conectados al servidor. En el caso de VPS, los volúmenes son más modestos: generalmente no más de 100 GB (pero hay más), y las tarifas para tal VPS pueden ser fácilmente más caras que los servidores dedicados más baratos del mismo proveedor de alojamiento. El VPS a menudo tiene una unidad, porque debajo estará el almacenamiento (o algo hiperconvergente). A veces, VPS tiene varios discos con diferentes características, para diferentes propósitos:

• sistema pequeño: para instalar el sistema operativo;
• grande: almacenamiento de datos del usuario.

Al reinstalar el sistema utilizando el panel de control, el disco con los datos del usuario no se sobrescribe, pero el sistema se vuelve a cargar por completo. Además, en el caso de VPS, el host puede ofrecer un botón que tome una instantánea del estado del VPS (o disco), sin embargo, si instala su sistema operativo u olvida activar el servicio deseado dentro del VPS, algunos de los datos aún pueden perderse. Además del botón, generalmente se ofrece un servicio de almacenamiento de datos, muy a menudo muy limitado. Por lo general, esta es una cuenta con acceso FTP o SFTP, a veces junto con SSH, con un shell truncado (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 por dos puertos con una velocidad de 1 Gbit / s, a veces pueden ser tarjetas con una velocidad de 10 Gbit / s. VPS a menudo tiene una interfaz de red. Con mayor frecuencia, los centros de datos no limitan la velocidad de la red dentro del centro de datos, sino que limitan la velocidad del acceso a Internet.

Una carga típica de dicho servidor dedicado o VPS es un servidor web, base de datos, servidor de aplicaciones. A veces se pueden instalar varios servicios de soporte adicionales, incluso para un servidor web o una base de datos: motor de búsqueda, sistema de correo, etc.

Un servidor especialmente preparado actúa como un espacio para almacenar copias de seguridad, se describirá con más detalle a continuación.

Organización de disco lógico

Si hay un controlador RAID, o es un VPS con un disco, y tampoco hay preferencias particulares para el 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, se crea un grupo de volúmenes LVM encima. , crea varios volúmenes: 2 pequeños del mismo tamaño que se usan como sistema de archivos raíz (se cambian alternativamente con actualizaciones para permitir una reversión rápida, la idea se espió desde la distribución Calcular Linux), otra es para la partición de intercambio, el resto es gratis Este espacio 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 debe depender tanto el uno del otro como del sistema de archivos raíz. En el caso de máquinas virtuales o contenedores, este punto se observa automáticamente. 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 manera que se eliminen al máximo las dependencias de los volúmenes entre ellos. Por ejemplo, cada sitio se ejecuta 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, los archivos de configuración del sitio no se incluyen a través de /etc/nginx/conf.d/ .conf, sino, por ejemplo, / home / /configs/nginx/*.conf

Si hay varios discos, puede crear un RAID de software (y configurar su almacenamiento en caché en SSD, si es necesario y una oportunidad), además de los cuales se puede ensamblar LVM de acuerdo con las reglas sugeridas anteriormente. También en este caso, puede usar ZFS o BtrFS, pero aquí vale la pena considerarlo varias veces: ambos requieren un enfoque mucho más serio de los recursos, además, ZFS no viene con el kernel de Linux.

Independientemente del esquema utilizado, siempre vale la pena calcular de antemano la velocidad aproximada de escritura de cambios en los discos y luego calcular el tamaño del espacio libre que se reservará para crear imágenes. 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 ser de hasta un día (22 horas; esta cantidad se transmitirá a través de la red 1 gbit / s), vale la pena reservar aproximadamente 800 GB En realidad, el número será menor; puede dividirlo de manera segura por el número de volúmenes lógicos.

Dispositivo de servidor de almacenamiento de respaldo

La principal diferencia entre el servidor para almacenar copias de seguridad son los discos grandes, baratos y relativamente lentos. Dado que los discos duros modernos ya han superado la barra de 10 TB en un disco, es obligatorio usar 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 a una mayor carga. En discos con una capacidad de hasta 1 TB, esto no era tan sensible. Para simplificar la descripción, supongo que el espacio en disco se divide en dos partes de aproximadamente el mismo tamaño (de nuevo, por ejemplo, usando LVM):

• volúmenes correspondientes a los servidores utilizados para almacenar datos de usuario (se implementará la última copia de seguridad realizada para la verificación);
• volúmenes utilizados como repositorios de BorgBackup (los datos para las copias de seguridad llegarán directamente aquí).

El principio de funcionamiento es que se crean volúmenes separados para cada servidor en el repositorio BorgBackup, donde irán los datos de los servidores de batalla. Los repositorios funcionan en el modo de solo agregar, lo que elimina la posibilidad de eliminación intencional de datos y debido a la deduplicación y la limpieza periódica de los repositorios de las copias de seguridad antiguas (hay copias anuales, mensuales durante el último año, semanalmente durante el último mes, diariamente durante la última semana, posiblemente en especial casos - por hora para el último día: total 24 + 7 + 4 + 12 + anual - aproximadamente 50 copias para cada servidor).
En los repositorios de BorgBackup, solo el modo agregar no está activado; en cambio, ForcedCommand se usa en .ssh / Authorizedkeys de aproximadamente el siguiente plan:

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....... 

Se coloca un contenedor de secuencia de comandos encima de la ruta especificada encima de borg, que, además de iniciar el binario con los parámetros, también inicia el proceso de restaurar la copia de seguridad después de eliminar los datos. Para hacer esto, el script del contenedor crea un archivo de etiqueta al lado del repositorio correspondiente. La última copia de seguridad realizada después del proceso de carga de datos se restaura automáticamente al volumen lógico correspondiente.

Este diseño le permite limpiar periódicamente las copias de seguridad innecesarias, y tampoco permite que los servidores de batalla eliminen nada en el servidor de almacenamiento de copias de seguridad.

Proceso de respaldo

El iniciador de la copia de seguridad es el servidor dedicado en sí o VPS, ya que dicho esquema brinda más control sobre el proceso de copia de seguridad desde este servidor. En primer lugar, se toma una instantánea del estado del sistema de archivos raíz activo, que se monta y carga mediante BorgBackup en el servidor de almacenamiento de respaldo. Después de completar la captura de datos, la imagen se desmonta y se elimina.

Si hay una pequeña base de datos (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 encuentra el resto de los datos del mismo sitio, pero de modo que el volcado no sea accesible a través del servidor web. Si las bases de datos son grandes, debe configurar una minería de datos "activa", por ejemplo, utilizando xtrabackup para MySQL o WAL con archive_command en PostgreSQL. En este caso, la base de datos se restaurará por separado de estos sitios.

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: solo cree instantáneas de volúmenes lógicos, que luego se procesan de manera similar a una instantánea del estado del sistema de archivos raíz. Después de tomar los datos, las imágenes se eliminan.

Se realiza más trabajo en el servidor de almacenamiento de respaldo:

• Se verifica la última copia de seguridad realizada en cada repositorio.
• busca un archivo de etiqueta que indique que el proceso de captura de datos se ha completado,
• los datos se están expandiendo al volumen local correspondiente,
• el archivo de etiqueta se elimina

Proceso de recuperación del servidor

Si el servidor principal muere, se inicia un servidor dedicado similar, que se carga desde alguna imagen estándar. Lo más probable es que la descarga se realice a través de la red, sin embargo, el técnico del centro de datos que realiza la configuración del servidor puede copiar inmediatamente esta imagen estándar en uno de los discos. La descarga se realiza en la RAM, después de lo cual comienza el proceso de recuperación:

• se realiza una solicitud para conectar el dispositivo de bloque a través de iscsi \ nbd u otro protocolo similar del volumen lógico que contiene el sistema de archivos raíz del servidor muerto; Dado que el sistema de archivos raíz debe ser pequeño, este paso debe completarse en unos minutos. También se realiza la recuperación del cargador de arranque;
• se recrea la estructura de los volúmenes lógicos locales, los volúmenes lógicos se conectan desde el servidor de respaldo utilizando el módulo del núcleo 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: el servidor está completamente restaurado, 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 del reinicio, el servidor tendrá todos los datos que estaban en el momento de la copia de seguridad, y también incluirá todos los cambios que se realizaron durante el proceso de recuperación.

Los invito a discutir la opción propuesta en los comentarios, ¡gracias por su atención!