Esta nota completa o ciclo sobre a copia de seguridade. Analizarase a organización lóxica dun servidor dedicado (ou VPS), conveniente para a copia de seguridade, e tamén ofrecerá unha opción para restaurar rapidamente un servidor desde unha copia de seguridade sen moito tempo de inactividade en caso de desastre.
Datos iniciais
Un servidor dedicado ten a maioría das veces polo menos dous discos duros que serven para organizar unha matriz RAID de primeiro nivel (espello). Isto é necesario para poder seguir operando o servidor se falla un disco. Se se trata dun servidor dedicado normal, pode haber un controlador RAID de hardware separado con tecnoloxía de caché activa en SSD, de xeito que ademais dos discos duros normais, se poden conectar un ou máis SSD. Ás veces ofrécense servidores dedicados, nos que os únicos discos locais son SATADOM (discos pequenos, estruturalmente unha unidade flash conectada a un porto SATA), ou incluso unha pequena unidade flash común (8-16 GB) conectada a un porto interno especial e o os datos tómanse do sistema de almacenamento, conectado a través dunha rede de almacenamento dedicada (Ethernet 10G, FC, etc.), e hai servidores dedicados que se cargan directamente desde o sistema de almacenamento. Non vou considerar tales opcións, xa que nestes casos a tarefa de facer unha copia de seguranza do servidor pasa sen problemas ao especialista que mantén o sistema de almacenamento; normalmente hai varias tecnoloxías propietarias para crear instantáneas, deduplicación integrada e outras alegrías do administrador do sistema. , comentado nas partes anteriores desta serie. O volume da matriz de discos dun servidor dedicado pode alcanzar varias decenas de terabytes, dependendo do número e tamaño dos discos conectados ao servidor. No caso de VPS, os volumes son máis modestos: normalmente non máis de 100 GB (pero tamén hai máis) e as tarifas deste VPS poden ser facilmente máis caras que os servidores dedicados máis baratos do mesmo servidor. Un VPS ten a maioría das veces un disco, porque haberá un sistema de almacenamento (ou algo hiperconverxente) debaixo del. Ás veces, un VPS ten varios discos con diferentes características, para diferentes fins:
- sistema pequeno - para instalar o sistema operativo;
- grande - almacena os datos do usuario.
Cando reinstala o sistema mediante o panel de control, o disco cos datos do usuario non se sobrescribe, pero o disco do sistema enchese completamente. Ademais, no caso dun VPS, o host pode ofrecer un botón que toma unha instantánea do estado do VPS (ou disco), pero se instala o seu propio sistema operativo ou esquece activar o servizo desexado dentro do VPS, algúns dos datos aínda se poden perder. Ademais do botón, adoita ofrecerse un servizo de almacenamento de datos, a maioría das veces moi limitado. Normalmente esta é unha conta con acceso a través de FTP ou SFTP, ás veces xunto con SSH, cun shell reducido (por exemplo, rbash) ou unha restrición para executar comandos a través de authorized_keys (a través de ForcedCommand).
Un servidor dedicado está conectado á rede por dous portos cunha velocidade de 1 Gbps, ás veces poden ser tarxetas cunha velocidade de 10 Gbps. VPS ten a maioría das veces unha interface de rede. Na maioría das veces, os centros de datos non limitan a velocidade da rede dentro do centro de datos, pero limitan a velocidade de acceso a Internet.
A carga típica de tal servidor dedicado ou VPS é un servidor web, unha base de datos e un servidor de aplicacións. Ás veces pódense instalar varios servizos auxiliares adicionais, incluído para un servidor web ou base de datos: buscador, sistema de correo, etc.
Un servidor especialmente preparado actúa como un espazo para almacenar copias de seguridade; máis adiante escribirémolo con máis detalle.
Organización lóxica do sistema de discos
Se tes un controlador RAID ou un VPS cun disco e non hai preferencias especiais para o funcionamento do subsistema de disco (por exemplo, un disco rápido separado para a base de datos), todo o espazo libre divídese do seguinte xeito: unha partición créase e enriba créase un grupo de volumes LVM , nel créanse varios volumes: 2 pequenos do mesmo tamaño, usados como sistema de ficheiros raíz (cambiados un por un durante as actualizacións para a posibilidade de retroceder rapidamente, a idea foi recollida da distribución Calculate Linux), outra é para a partición de intercambio, o resto do espazo libre está dividido en pequenos volumes , usado como sistema de ficheiros raíz para contedores completos, discos para máquinas virtuais, ficheiros. sistemas para contas en /home (cada conta ten o seu propio sistema de ficheiros), sistemas de ficheiros para contedores de aplicacións.
Nota importante: os volumes deben ser completamente autónomos, é dicir. non deben depender uns dos outros nin do sistema de ficheiros raíz. No caso de máquinas virtuais ou contedores, este punto obsérvase automaticamente. Se se trata de contedores de aplicacións ou directorios de inicio, debes pensar en separar os ficheiros de configuración do servidor web e outros servizos de forma que se eliminen ao máximo as dependencias entre os volumes. Por exemplo, cada sitio funciona desde o seu propio usuario, os ficheiros de configuración do sitio están no directorio de inicio do usuario, na configuración do servidor web, os ficheiros de configuración do sitio non están incluídos a través de /etc/nginx/conf.d/.conf e, por exemplo, /home//configs/nginx/*.conf
Se hai varios discos, pode crear unha matriz RAID de software (e configurar a súa caché nun SSD, se hai necesidade e oportunidade), enriba da cal pode construír LVM segundo as regras propostas anteriormente. Tamén neste caso, podes usar ZFS ou BtrFS, pero deberías pensalo dúas veces: ambos requiren un enfoque moito máis serio dos recursos e, ademais, ZFS non está incluído no núcleo de Linux.
Independentemente do esquema empregado, sempre paga a pena estimar con antelación a velocidade aproximada de escritura de cambios nos discos e, a continuación, calcular a cantidade de espazo libre que se reservará para crear instantáneas. Por exemplo, se o noso servidor escribe datos a unha velocidade de 10 megabytes por segundo e o tamaño de toda a matriz de datos é de 10 terabytes - o tempo de sincronización pode chegar a un día (22 horas - é a cantidade de tal volume transferido). pola rede 1 Gbps) - paga a pena reservar uns 800 GB . En realidade, a cifra será menor; pode dividila con seguridade polo número de volumes lóxicos.
Dispositivo de servidor de almacenamento de copia de seguranza
A principal diferenza entre un servidor para almacenar copias de seguridade son os seus discos grandes, baratos e relativamente lentos. Dado que os HDD modernos xa cruzaron a barra de 10 TB nun disco, é necesario utilizar sistemas de ficheiros ou RAID con sumas de verificación, porque durante a reconstrución da matriz ou a restauración do sistema de ficheiros (varios días!) o segundo disco pode fallar debido ao aumento da carga. En discos cunha capacidade de ata 1 TB isto non era tan sensible. Para simplificar a descrición, supoño que o espazo en disco está dividido en dúas partes de tamaño aproximadamente igual (de novo, por exemplo, usando LVM):
- volumes correspondentes aos servidores utilizados para almacenar os datos dos usuarios (a última copia de seguridade realizada despregarase neles para a súa verificación);
- volumes usados como repositorios BorgBackup (os datos para copias de seguridade irán directamente aquí).
O principio de funcionamento é que se crean volumes separados para cada servidor para os repositorios de BorgBackup, onde irán os datos dos servidores de combate. Os repositorios funcionan en modo de só anexo, o que elimina a posibilidade de eliminar datos intencionadamente, e debido á deduplicación e limpeza periódica dos repositorios das copias de seguridade antigas (quedan as copias anuais, mensualmente durante o último ano, semanalmente durante o último mes, diariamente para o último mes). a semana pasada, posiblemente en casos especiais - por hora para o último día: total 24 + 7 + 4 + 12 + anual - aproximadamente 50 copias para cada servidor).
Os repositorios de BorgBackup non activan o modo de só anexo; en cambio, úsase un ForcedCommand en .ssh/authorized_keys algo así:
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.......O camiño especificado contén un script de envoltura enriba do borg, que, ademais de iniciar o binario con parámetros, tamén inicia o proceso de restauración da copia de seguranza despois de eliminar os datos. Para iso, o script wrapper crea un ficheiro de etiqueta xunto ao repositorio correspondente. A última copia de seguridade realizada restablecerase automaticamente ao volume lóxico correspondente despois de que se complete o proceso de recheo de datos.
Este deseño permítelle limpar periodicamente as copias de seguridade innecesarias e tamén evita que os servidores de combate eliminen calquera cousa do servidor de almacenamento de copia de seguridade.
Proceso de copia de seguridade
O iniciador da copia de seguridade é o propio servidor dedicado ou VPS, xa que este esquema dá máis control sobre o proceso de copia de seguridade por parte deste servidor. En primeiro lugar, tómase unha instantánea do estado do sistema de ficheiros raíz activo, que se monta e carga mediante BorgBackup ao servidor de almacenamento de copia de seguridade. Despois de completar a captura de datos, a instantánea desmontase e elimínase.
Se hai unha pequena base de datos (ata 1 GB para cada sitio), realízase un volcado de base de datos, que se garda no volume lóxico adecuado, onde se atopa o resto dos datos do mesmo sitio, pero para que o volcado sexa non accesible a través do servidor web. Se as bases de datos son grandes, debes configurar a eliminación de datos "quente", por exemplo, usando xtrabackup para MySQL, ou traballar con WAL con archive_command en PostgreSQL. Neste caso, a base de datos restaurarase por separado dos datos do sitio.
Se se usan contedores ou máquinas virtuais, debe configurar qemu-guest-agent, CRIU ou outras tecnoloxías necesarias. Noutros casos, a maioría das veces non se necesitan configuracións adicionais: simplemente creamos instantáneas de volumes lóxicos, que despois se procesan do mesmo xeito que unha instantánea do estado do sistema de ficheiros raíz. Despois de tomar os datos, elimínanse as imaxes.
Realízase máis traballo no servidor de almacenamento de copia de seguridade:
- compróbase a última copia de seguridade realizada en cada repositorio,
- compróbase a presenza dun ficheiro de marca, que indica que o proceso de recollida de datos está rematado,
- os datos amplíanse ao volume local correspondente,
- elimínase o ficheiro de etiqueta
Proceso de recuperación do servidor
Se o servidor principal morre, lánzase un servidor dedicado similar, que se inicia desde algunha imaxe estándar. O máis probable é que a descarga teña lugar a través da rede, pero o técnico do centro de datos que configura o servidor pode copiar inmediatamente esta imaxe estándar nun dos discos. A descarga prodúcese na memoria RAM, despois de que comeza o proceso de recuperación:
- realízase unha solicitude para conectar un dispositivo de bloque mediante iscsinbd ou outro protocolo similar a un volume lóxico que contén o sistema de ficheiros raíz do servidor falecido; Dado que o sistema de ficheiros raíz debe ser pequeno, este paso debería completarse nuns minutos. Tamén se restaura o cargador de arranque;
- recréase a estrutura dos volumes lóxicos locais, os volumes lóxicos anxúntanse desde o servidor de copia de seguridade mediante o módulo do núcleo dm_clone: comeza a recuperación de datos e os cambios escríbense inmediatamente nos discos locais.
- lánzase un contedor con todos os discos físicos dispoñibles: a funcionalidade do servidor está totalmente restaurada, pero cun rendemento reducido;
- despois de completar a sincronización de datos, desconéctanse os volumes lóxicos do servidor de copia de seguranza, desactívase o contedor e reinicia o servidor;
Despois dun reinicio, o servidor terá todos os datos que estaban alí no momento en que se creou a copia de seguranza e tamén incluirá todos os cambios que se fixeron durante o proceso de restauración.
Outros artigos da serie
Copia de seguridade Parte 7: Conclusións
Invítoche a comentar a opción proposta nos comentarios, grazas pola túa atención!
Fonte: www.habr.com