Aquesta nota completa el cicle sobre la còpia de seguretat. Es parlarà de l'organització lògica d'un servidor dedicat (o VPS), convenient per a la còpia de seguretat, i també oferirà una opció per restaurar ràpidament un servidor des d'una còpia de seguretat sense gaire temps d'inactivitat en cas d'un desastre.
Dades primeres
Un servidor dedicat sovint té almenys dos discs durs que serveixen per organitzar una matriu RAID de primer nivell (mirall). Això és necessari per poder continuar operant el servidor si falla un disc. Si es tracta d'un servidor dedicat normal, pot haver-hi un controlador RAID de maquinari independent amb tecnologia de memòria cau activa a SSD, de manera que, a més dels discs durs normals, es poden connectar un o més SSD. De vegades s'ofereixen servidors dedicats, en els quals els únics discs locals són SATADOM (discs petits, estructuralment una unitat flaix connectada a un port SATA), o fins i tot una petita unitat flaix normal (8-16 GB) connectada a un port intern especial, i el Les dades es prenen del sistema d'emmagatzematge, connectat mitjançant una xarxa d'emmagatzematge dedicada (Ethernet 10G, FC, etc.), i hi ha servidors dedicats que es carreguen directament des del sistema d'emmagatzematge. No consideraré aquestes opcions, ja que en aquests casos la tasca de fer una còpia de seguretat del servidor passa sense problemes a l'especialista que manté el sistema d'emmagatzematge; normalment hi ha diverses tecnologies propietàries per crear instantànies, deduplicació integrada i altres alegries de l'administrador del sistema. , comentat a les parts anteriors d'aquesta sèrie. El volum de la matriu de discs d'un servidor dedicat pot arribar a diverses desenes de terabytes, depenent del nombre i la mida dels discs connectats al servidor. En el cas de VPS, els volums són més modestos: normalment no superen els 100 GB (però també n'hi ha més), i les tarifes d'aquest VPS poden ser fàcilment més cares que els servidors dedicats més barats del mateix hoster. Un VPS sovint té un disc, perquè hi haurà un sistema d'emmagatzematge (o alguna cosa hiperconvergent) a sota. De vegades, un VPS té diversos discs amb diferents característiques, amb diferents finalitats:
- sistema petit - per instal·lar el sistema operatiu;
- gran - emmagatzemar dades d'usuari.
Quan torneu a instal·lar el sistema mitjançant el tauler de control, el disc amb les dades de l'usuari no se sobreescriu, però el disc del sistema s'omple completament. A més, en el cas d'un VPS, l'hoster pot oferir un botó que fa una instantània de l'estat del VPS (o disc), però si instal·leu el vostre propi sistema operatiu o oblideu activar el servei desitjat dins del VPS, alguns de les dades encara es poden perdre. A més del botó, se sol oferir un servei d'emmagatzematge de dades, la majoria de vegades molt limitat. Normalment es tracta d'un compte amb accés mitjançant FTP o SFTP, de vegades juntament amb SSH, amb un shell reduït (per exemple, rbash) o una restricció a l'execució d'ordres mitjançant les claus_autoritzades (mitjançant ForcedCommand).
Un servidor dedicat està connectat a la xarxa per dos ports amb una velocitat d'1 Gbps, de vegades poden ser targetes amb una velocitat de 10 Gbps. VPS sovint té una interfície de xarxa. Molt sovint, els centres de dades no limiten la velocitat de la xarxa dins del centre de dades, sinó que limiten la velocitat d'accés a Internet.
La càrrega típica d'un servidor dedicat o VPS és un servidor web, una base de dades i un servidor d'aplicacions. De vegades es poden instal·lar diversos serveis auxiliars addicionals, inclòs per a un servidor web o una base de dades: motor de cerca, sistema de correu, etc.
Un servidor especialment preparat actua com a espai per emmagatzemar còpies de seguretat; més endavant escriurem sobre això amb més detall.
Organització lògica del sistema de discs
Si teniu un controlador RAID o un VPS amb un disc i no hi ha preferències especials per al funcionament del subsistema de disc (per exemple, un disc ràpid separat per a la base de dades), tot l'espai lliure es divideix de la següent manera: una partició es crea, i es crea un grup de volums LVM a sobre, s'hi creen diversos volums: 2 petits de la mateixa mida, utilitzats com a sistema de fitxers arrel (canviat un per un durant les actualitzacions per a la possibilitat d'una recuperació ràpida, la idea es va recollir a la distribució Calculate Linux), una altra és per a la partició d'intercanvi, la resta de l'espai lliure es divideix en petits volums, utilitzat com a sistema de fitxers arrel per a contenidors complets, discs per a màquines virtuals, fitxers. sistemes per als comptes a /home (cada compte té el seu propi sistema de fitxers), sistemes de fitxers per als contenidors d'aplicacions.
Nota important: els volums han de ser completament autònoms, és a dir. no haurien de dependre els uns dels altres ni del sistema de fitxers arrel. En el cas de màquines virtuals o contenidors, aquest punt s'observa automàticament. Si es tracta de contenidors d'aplicacions o directoris d'inici, hauríeu de pensar en separar els fitxers de configuració del servidor web i d'altres serveis de manera que s'eliminin al màxim les dependències entre els volums. Per exemple, cada lloc s'executa des del seu propi usuari, els fitxers de configuració del lloc es troben al directori inicial de l'usuari, a la configuració del servidor web, els fitxers de configuració del lloc no s'inclouen a través de /etc/nginx/conf.d/.conf i, per exemple, /home//configs/nginx/*.conf
Si hi ha diversos discs, podeu crear una matriu RAID de programari (i configurar la seva memòria cau en un SSD, si hi ha una necessitat i oportunitat), a sobre de la qual podeu construir LVM segons les regles proposades anteriorment. També en aquest cas, podeu utilitzar ZFS o BtrFS, però hauríeu de pensar-ho dues vegades: tots dos requereixen un enfocament molt més seriós dels recursos i, a més, ZFS no està inclòs amb el nucli de Linux.
Independentment de l'esquema utilitzat, sempre val la pena estimar per endavant la velocitat aproximada d'escriptura dels canvis als discs i, a continuació, calcular la quantitat d'espai lliure que es reservarà per crear instantànies. Per exemple, si el nostre servidor escriu dades a una velocitat de 10 megabytes per segon i la mida de la matriu de dades sencera és de 10 terabytes, el temps de sincronització pot arribar a un dia (22 hores; aquesta és la quantitat que es transferirà aquest volum). a la xarxa 1 Gbps) - val la pena reservar uns 800 GB . En realitat, la xifra serà més petita; podeu dividir-la amb seguretat pel nombre de volums lògics.
Dispositiu de servidor d'emmagatzematge de còpia de seguretat
La principal diferència entre un servidor per emmagatzemar còpies de seguretat són els seus discs grans, barats i relativament lents. Com que els HDD moderns ja han travessat la barra de 10 TB en un disc, és necessari utilitzar sistemes de fitxers o RAID amb sumes de control, perquè durant la reconstrucció de la matriu o la restauració del sistema de fitxers (diversos dies!) el segon disc pot fallar a causa de per augmentar la càrrega. En discos amb una capacitat de fins a 1 TB, això no era tan sensible. Per simplificar la descripció, suposo que l'espai en disc es divideix en dues parts de mida aproximadament igual (de nou, per exemple, utilitzant LVM):
- volums corresponents als servidors utilitzats per emmagatzemar les dades dels usuaris (s'hi desplegarà l'última còpia de seguretat realitzada per a la seva verificació);
- volums utilitzats com a repositoris BorgBackup (les dades per a les còpies de seguretat aniran directament aquí).
El principi de funcionament és que es creen volums separats per a cada servidor per als repositoris BorgBackup, on aniran les dades dels servidors de combat. Els dipòsits funcionen en mode només adjuntar, que elimina la possibilitat d'esborrar dades intencionadament, i a causa de la desduplicació i neteja periòdica dels dipòsits de còpies de seguretat antigues (es queden còpies anuals, mensualment durant l'últim any, setmanalment durant l'últim mes, diàriament per al la setmana passada, possiblement en casos especials - per hora durant l'últim dia: total 24 + 7 + 4 + 12 + anual - aproximadament 50 còpies per a cada servidor).
Els repositoris de BorgBackup no habiliten el mode només d'afegir; en canvi, s'utilitza un ForcedCommand a .ssh/authorized_keys com això:
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.......El camí especificat conté un script d'embolcall a la part superior del borg, que, a més d'iniciar el binari amb paràmetres, també inicia el procés de restauració de la còpia de seguretat després d'eliminar les dades. Per fer-ho, l'script d'embolcall crea un fitxer d'etiquetes al costat del repositori corresponent. L'última còpia de seguretat realitzada es restaura automàticament al volum lògic corresponent un cop finalitzat el procés d'emplenament de dades.
Aquest disseny us permet netejar periòdicament les còpies de seguretat innecessàries i també evita que els servidors de combat suprimeixin qualsevol cosa al servidor d'emmagatzematge de còpies de seguretat.
Procés de còpia de seguretat
L'iniciador de la còpia de seguretat és el propi servidor dedicat o VPS, ja que aquest esquema dóna més control sobre el procés de còpia de seguretat per part d'aquest servidor. En primer lloc, es fa una instantània de l'estat del sistema de fitxers arrel actiu, que es munta i es carrega amb BorgBackup al servidor d'emmagatzematge de còpia de seguretat. Un cop finalitzada la captura de dades, la instantània es desmunta i s'elimina.
Si hi ha una base de dades petita (fins a 1 GB per a cada lloc), es fa un abocament de la base de dades, que es desa en el volum lògic adequat, on es troben la resta de dades del mateix lloc, però perquè l'abocament sigui no accessible a través del servidor web. Si les bases de dades són grans, hauríeu de configurar l'eliminació de dades "calenta", per exemple, utilitzant xtrabackup per a MySQL, o treballar amb WAL amb archive_command a PostgreSQL. En aquest cas, la base de dades es restaurarà per separat de les dades del lloc.
Si s'utilitzen contenidors o màquines virtuals, hauríeu de configurar qemu-guest-agent, CRIU o altres tecnologies necessàries. En altres casos, sovint no es necessiten paràmetres addicionals: simplement creem instantànies de volums lògics, que després es processen de la mateixa manera que una instantània de l'estat del sistema de fitxers arrel. Després de prendre les dades, les imatges s'esborren.
Es duu a terme més treballs al servidor d'emmagatzematge de seguretat:
- es comprova l'última còpia de seguretat feta a cada repositori,
- es comprova la presència d'un fitxer de marca, que indica que el procés de recollida de dades ha finalitzat,
- les dades s'amplien al volum local corresponent,
- s'elimina el fitxer d'etiquetes
Procés de recuperació del servidor
Si el servidor principal mor, s'inicia un servidor dedicat similar, que arrenca des d'alguna imatge estàndard. El més probable és que la descàrrega es faci a través de la xarxa, però el tècnic del centre de dades que configura el servidor pot copiar immediatament aquesta imatge estàndard en un dels discs. La descàrrega es produeix a la memòria RAM, després de la qual s'inicia el procés de recuperació:
- es fa una sol·licitud per connectar un dispositiu de bloc mitjançant iscsinbd o un altre protocol similar a un volum lògic que conté el sistema de fitxers arrel del servidor mort; Com que el sistema de fitxers arrel ha de ser petit, aquest pas s'hauria de completar en pocs minuts. El carregador d'arrencada també es restaura;
- es recrea l'estructura dels volums lògics locals, els volums lògics s'adjunten des del servidor de còpia de seguretat mitjançant el mòdul del nucli dm_clone: comença la recuperació de dades i els canvis s'escriuen immediatament als discs locals
- s'inicia un contenidor amb tots els discs físics disponibles: la funcionalitat del servidor es restaura completament, però amb un rendiment reduït;
- un cop finalitzada la sincronització de dades, els volums lògics del servidor de còpia de seguretat es desconnecten, el contenidor s'apaga i el servidor es reinicia;
Després d'un reinici, el servidor tindrà totes les dades que hi havia en el moment en què es va crear la còpia de seguretat, i també inclourà tots els canvis que es van fer durant el procés de restauració.
Altres articles de la sèrie
Còpia de seguretat Part 7: Conclusions
Us convido a comentar l'opció proposada als comentaris, gràcies per la vostra atenció!
Font: www.habr.com