Sta nota compie u ciclu di salvezza. Discuterà l'urganizazione logica di un servitore dedicatu (o VPS), cunvene per a copia di salvezza, è offre ancu una opzione per restaurà rapidamente un servitore da una copia di salvezza senza assai downtime in casu di un disastru.
Dati iniziali
Un servitore dedicatu a maiò spessu hà almenu dui discu duru chì serve per urganizà un array RAID di primu livellu (specchiu). Questu hè necessariu per esse capace di cuntinuà à uperà u servitore se un discu falla. S'ellu hè un servitore dedicatu regularmente, pò esse un controller RAID hardware separatu cù a tecnulugia di caching attiva nantu à SSD, per quessa, in più di i discu duru regulare, ponu esse cunnessi unu o più SSD. A volte sò pruposti servitori dedicati, in quale l'unichi dischi lucali sò SATADOM (dischi chjuchi, strutturalmente un flash drive cunnessu à un portu SATA), o ancu un picculu unità flash ordinariu (8-16GB) cunnessu à un portu internu speciale, è I dati sò pigliati da u sistema di almacenamento, cunnessu via una reta di almacenamentu dedicatu (Ethernet 10G, FC, etc.), è ci sò servitori dedicati chì sò caricati direttamente da u sistema di almacenamentu. Ùn cunsiderà micca tali opzioni, postu chì in tali casi u compitu di a copia di salvezza di u servitore passa in modu fluidu à u specialista chì mantene u sistema di almacenamento; di solitu ci sò diverse tecnulugia proprietaria per creà snapshots, deduplicazione integrata è altre gioie di l'amministratore di u sistema. , discutitu in e parti precedente di sta serie. U voluminu di l'array di discu di un servitore dedicatu pò ghjunghje à parechje decine di terabytes, secondu u numeru è a dimensione di dischi cunnessi à u servitore. In u casu di VPS, i volumi sò più modesti: di solitu micca più di 100GB (ma ci sò ancu più), è i tariffi per tali VPS ponu esse facilmente più caru chì i servitori dedicati più prezzu da u stessu hoster. Un VPS a maiò spessu hà un discu, perchè ci sarà un sistema di almacenamiento (o qualcosa hyperconverged) sottu. A volte un VPS hà parechji dischi cù caratteristiche diffirenti, per scopi diversi:
- sistema chjucu - per installà u sistema operatore;
- grande - almacenà dati di l'utilizatori.
Quandu reinstallate u sistema utilizendu u pannellu di cuntrollu, u discu cù e dati di l'utilizatori ùn hè micca sovrascrittu, ma u discu di u sistema hè cumpletamente riempitu. Inoltre, in u casu di un VPS, l'ospitu pò offre un buttone chì piglia una foto di u statu di u VPS (o discu), ma se installate u vostru propiu sistema operatore o scurdate di attivà u serviziu desideratu in u VPS, alcuni di i dati pò ancu esse persu. In più di u buttone, un serviziu di almacenamentu di dati hè generalmente prupostu, più spessu assai limitatu. Di genere, questu hè un cuntu cù accessu via FTP o SFTP, à volte cù SSH, cù una shell spogliata (per esempiu, rbash), o una restrizione à l'esecuzione di cumandamenti attraversu authorized_keys (via ForcedCommand).
Un servitore dedicatu hè cunnessu à a reta da dui porti cù una velocità di 1 Gbps, à volte questi ponu esse carte cù una velocità di 10 Gbps. VPS a maiò spessu hà una interfaccia di rete. A maiò spessu, i centri di dati ùn limitanu micca a velocità di a rete in u centru di dati, ma limitanu a velocità di l'accessu à Internet.
A carica tipica di un servitore tali dedicatu o VPS hè un servitore web, una basa di dati è un servitore d'applicazione. Calchì volta diversi servizii ausiliarii addiziunali ponu esse stallati, cumpresu per un servitore web o basa di dati: mutore di ricerca, sistema di mail, etc.
Un servitore preparatu apposta agisce cum'è un spaziu per almacenà e copie di salvezza; scriveremu nantu à questu in più dettagliu dopu.
L'urganizazione logica di u sistema di discu
Se tenete un controller RAID, o un VPS cù un discu, è ùn ci sò micca preferenze spiciali per u funziunamentu di u subsistema di discu (per esempiu, un discu veloce separatu per a basa di dati), tuttu u spaziu liberu hè spartutu cusì: una partizione. hè creatu, è un gruppu di volumi LVM hè creatu nantu à questu, parechji volumi sò creati in questu: 2 chjuchi di a listessa dimensione, utilizati cum'è u sistema di fugliale radicali (cambiatu unu per unu durante l'aghjurnamenti per a pussibilità di un rollback rapidu, l'idea hè stata pigliata da a distribuzione Calculate Linux), un altru hè per a partizione swap, u restu di u spaziu liberu hè divisu in picculi volumi , utilizatu cum'è u sistema di fugliale radicali per cuntenituri cumpleti, dischi per macchine virtuali, file. sistemi per i cunti in /home (ogni contu hà u so propiu sistema di fugliale), sistemi di schedari per i cuntenituri di l'applicazioni.
Nota impurtante: i volumi deve esse cumplettamente autonomi, i.e. ùn deve micca dipende di l'altri o di u sistema di fugliale radicali. In u casu di macchine virtuali o cuntenituri, stu puntu hè osservatu automaticamente. Sì questi sò cuntenituri d'applicazioni o cartulari di casa, avete da pensà à separà i schedarii di cunfigurazione di u servitore web è altri servizii in modu di eliminà e dependenzii trà i volumi quant'è pussibule. Per esempiu, ogni situ corre da u so propiu utilizatore, i schedarii di cunfigurazione di u situ sò in u cartulare di casa di l'utilizatori, in i paràmetri di u servitore web, i schedarii di cunfigurazione di u situ ùn sò micca inclusi via /etc/nginx/conf.d/.conf, è, per esempiu, /home//configs/nginx/*.conf
Se ci sò parechji dischi, pudete creà un array RAID di software (è cunfigurà u so caching in un SSD, se ci hè bisognu è opportunità), in cima di quale pudete custruisce LVM secondu e regule pruposte sopra. Ancu in questu casu, pudete aduprà ZFS o BtrFS, ma duvete pensà duie volte à questu: i dui necessitanu un accostu assai più seriu à e risorse, è in più, ZFS ùn hè micca inclusu cù u kernel Linux.
Indipendentemente da u schema utilizatu, hè sempre degne di stima in anticipu a velocità apprussimativa di i cambiamenti di scrittura à i dischi, è poi calculà a quantità di spaziu liberu chì serà riservatu per creà snapshots. Per esempiu, se u nostru servitore scrive dati à una velocità di 10 megabytes per seconda, è a dimensione di l'array di dati sanu hè 10 terabytes - u tempu di sincronizazione pò ghjunghje à un ghjornu (22 ore - questu hè quantu un tali voluminu serà trasferitu). nantu à a reta 1 Gbps) - vale a pena riservà circa 800 GB . In rialità, a figura serà più chjuca; pudete dividisce in modu sicuru da u numeru di volumi lògichi.
Dispositivu di u servitore di salvezza di salvezza
A principal diferenza trà un servitore per almacenà e copie di salvezza hè i so dischi grandi, economici è relativamente lenti. Siccomu i HDD muderni anu digià attraversatu a barra 10TB in un discu, hè necessariu d'utilizà sistemi di fugliale o RAID cù checksums, perchè durante a ricustruzione di l'array o a risturazione di u sistema di schedari (parechji ghjorni!) U secondu discu pò fallu per via. a carica aumentata. In i dischi cù una capacità di finu à 1TB ùn era micca cusì sensibile. Per a simplicità di a descrizzione, assume chì u spaziu di discu hè divisu in duie parti di dimensioni apprussimatamente uguali (di novu, per esempiu, usendu LVM):
- volumi currispondenti à i servitori utilizati per almacenà e dati di l'utilizatori (l'ultima copia di salvezza fatta serà implementata nantu à elli per a verificazione);
- volumi usati cum'è repository BorgBackup (dati per i backup andaranu direttamente quì).
U principiu di funziunamentu hè chì i volumi separati sò creati per ogni servitore per i repositori BorgBackup, induve i dati da i servitori di cummattimentu andaranu. I repositori operanu in modu append-only, chì elimina a pussibilità di sguassà intenzionalmente i dati, è per via di a deduplicazione è di a pulizia periodica di i repositori da i vechji backups (copie annuali restanu, mensili per l'ultimu annu, settimanale per l'ultimu mese, ogni ghjornu per a settimana passata, possibbilmente in casi speciali - ogni ora per l'ultimu ghjornu: tutale 24 + 7 + 4 + 12 + annuale - circa 50 copie per ogni servitore).
I repositori BorgBackup ùn permettenu micca u modu di append-only, invece, un ForcedCommand in .ssh/authorized_keys hè utilizatu qualcosa cusì:
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.......U percorsu specificatu cuntene un script wrapper in cima di borg, chì, in più di lancià u binariu cù parametri, in più principia u prucessu di restaurà a copia di salvezza dopu chì i dati sò eliminati. Per fà questu, u script wrapper crea un schedariu tag vicinu à u repository currispundente. L'ultima copia di salvezza fatta hè automaticamente restaurata à u voluminu logicu currispundente dopu chì u prucessu di riempimentu di dati hè cumpletu.
Stu disignu permette di pulizziari periodicamente backups innecessarii, è ancu impedisce à i servitori di cummattimentu di sguassà qualcosa in u servitore di salvezza di salvezza.
Prucessu di salvezza
L'iniziatore di a copia di salvezza hè u servitore dedicatu o VPS stessu, postu chì stu schema dà più cuntrollu di u prucessu di salvezza da parte di stu servitore. Prima, hè pigliatu un snapshot di u statu di u sistema di schedariu radicali attivu, chì hè muntatu è caricatu cù BorgBackup à u servitore di salvezza di salvezza. Dopu chì i dati sò catturati, a snapshot hè smontata è sguassata.
Se ci hè una piccula basa di dati (finu à 1 GB per ogni situ), hè fatta un dump di basa di dati, chì hè salvatu in u voluminu logicu appropritatu, induve u restu di e dati per u stessu situ hè situatu, ma cusì chì u dump hè. micca accessìbule attraversu u servitore web. Se e basa di dati sò grande, duvete cunfigurà a rimozione di dati "calda", per esempiu, utilizendu xtrabackup per MySQL, o travaglià cù WAL cù archive_command in PostgreSQL. In questu casu, a basa di dati serà restaurata separatamente da i dati di u situ.
Se cuntenituri o macchine virtuali sò utilizati, duvete cunfigurà qemu-guest-agent, CRIU o altre tecnulugia necessarie. In altri casi, i paràmetri supplementarii più spessu ùn sò micca necessarii - simpricimenti creamu snapshots di volumi lògichi, chì sò poi processati in u listessu modu cum'è una snapshot di u statu di u sistema di fugliale radicali. Dopu à piglià i dati, i ritratti sò sguassati.
Ulteriore travagliu hè realizatu nantu à u servitore di salvezza di salvezza:
- l'ultima copia di salvezza fatta in ogni repository hè verificata,
- a prisenza di un schedariu di marca hè verificatu, chì indica chì u prucessu di cullizzioni di dati hè finitu,
- i dati sò allargati à u voluminu lucale currispundente,
- u schedariu tag hè sguassatu
Prucessu di ricuperazione di u servitore
Se u servitore principalu mori, allora un servitore dedicatu simili hè lanciatu, chì stivali da qualchì imagine standard. Hè assai prubabile chì a scaricazione si farà nantu à a reta, ma u tecnicu di u centru di dati chì hà stallatu u servitore pò immediatamente copià sta maghjina standard in unu di i dischi. U scaricamentu hè in RAM, dopu chì u prucessu di ricuperazione principia:
- una dumanda hè fatta per attaccà un dispositivu di bloccu via iscsinbd o un altru protokollu simili à un voluminu lògicu chì cuntene u sistema di fugliale radicali di u servitore mortu; Siccomu u sistema di schedariu radicali deve esse chjucu, stu passu deve esse cumpletu in pochi minuti. U bootloader hè ancu restauratu;
- a struttura di volumi lògichi lucali hè ricreata, volumi lògichi sò attaccati da u servitore di salvezza utilizendu u modulu di kernel dm_clone: a ricuperazione di dati principia, è i cambiamenti sò scritti immediatamente à i dischi lucali.
- un cuntinuu hè lanciatu cù tutti i dischi fisichi dispunibili - a funziunalità di u servitore hè cumplettamente restaurata, ma cù un rendimentu ridutta;
- dopu chì a sincronizazione di dati hè cumpletata, i volumi lògichi da u servitore di salvezza sò disconnected, u cuntinuu hè disattivatu, è u servitore hè riavviatu;
Dopu un reboot, u servitore avarà tutte e dati chì era quì à u mumentu chì a copia di salvezza hè stata creata, è includerà ancu tutti i cambiamenti chì sò stati fatti durante u prucessu di restaurazione.
Altri articuli in a serie
Backup Part 7: Conclusioni
Vi invitu à discutiri l'opzione pruposta in i cumenti, grazie per a vostra attenzione!
Source: www.habr.com