Dizze notysje foltôget de syklus oer reservekopy. It sil beprate de logyske organisaasje fan in tawijd tsjinner (of VPS), handich foar reservekopy, en sil ek biede in opsje foar fluch werstellen fan in tsjinner fan in reservekopy sûnder folle downtime yn it gefal fan in ramp.
Roald gegevens
In tawijd tsjinner hat meastentiids op syn minst twa hurde skiven dy't tsjinje om in RAID-array op earste nivo (spegel) te organisearjen. Dit is nedich om de tsjinner troch te kinnen as ien skiif mislearret. As dit in gewoane tawijd tsjinner is, kin d'r in aparte hardware RAID-controller wêze mei aktive cachingtechnology op SSD, sadat njonken gewoane hurde skiven ien of mear SSD's kinne wurde ferbûn. Soms wurde spesjale servers oanbean, wêryn de ienige lokale skiven SATADOM binne (lytse skiven, struktureel in flash-drive ferbûn oan in SATA-poarte), of sels in gewoane lyts (8-16GB) flash-drive ferbûn mei in spesjale ynterne poarte, en de gegevens wurdt nommen út de opslach systeem , ferbûn fia in tawijd opslach netwurk (Ethernet 10G, FC, ensfh), En der binne tawijd tsjinners dy't laden direkt út de opslach systeem. Ik sil sokke opsjes net beskôgje, om't yn sokke gefallen de taak fan in reservekopy fan 'e tsjinner soepel oergiet nei de spesjalist dy't it opslachsysteem ûnderhâldt; meastentiids binne d'r ferskate proprietêre technologyen foar it meitsjen fan snapshots, ynboude deduplikaasje en oare wille fan 'e systeembehearder , besprutsen yn 'e foarige dielen fan dizze rige. It folume fan in tawijd tsjinner syn skiif array kin berikke ferskate tsientallen terabytes, ôfhinklik fan it oantal en grutte fan skiven ferbûn oan de tsjinner. Yn it gefal fan VPS binne de folumes beskiedener: meastentiids net mear as 100GB (mar d'r binne ek mear), en de tariven foar sa'n VPS kinne maklik djoerder wêze as de goedkeapste dedicated servers fan deselde hoster. In VPS hat meastentiids ien skiif, om't d'r in opslachsysteem (of wat hyperkonvergeare) ûnder sil wêze. Soms hat in VPS ferskate skiven mei ferskate skaaimerken, foar ferskate doelen:
- lyts systeem - foar it ynstallearjen fan it bestjoeringssysteem;
- grut - it bewarjen fan brûkersgegevens.
As jo opnij ynstallearje it systeem mei help fan de kontrôle paniel, de skiif mei brûker gegevens wurdt net oerskreaun, mar it systeem skiif is folslein opnij. Ek, yn it gefal fan in VPS, kin de hoster in knop oanbiede dy't in momintopname nimt fan 'e steat fan' e VPS (of skiif), mar as jo jo eigen bestjoeringssysteem ynstallearje of ferjitte de winske tsjinst yn 'e VPS te aktivearjen, guon fan de gegevens kinne noch ferlern gean. Neist de knop wurdt normaal in gegevensopslachtsjinst oanbean, meastentiids tige beheind. Dit is normaal in akkount mei tagong fia FTP of SFTP, soms tegearre mei SSH, mei in stripped-down shell (bygelyks rbash), of in beheining op it útfieren fan kommando's fia authorized_keys (fia ForcedCommand).
In tawijd tsjinner is ferbûn mei it netwurk troch twa havens mei in snelheid fan 1 Gbps, soms dit kin wêze kaarten mei in snelheid fan 10 Gbps. VPS hat meastentiids ien netwurkynterface. Meastentiids beheine datasintra de netwurksnelheid net binnen it datasintrum, mar se beheine de snelheid fan ynternettagong.
De typyske lading fan sa'n tawijd tsjinner as VPS is in webserver, in databank en in applikaasjetsjinner. Soms kinne ferskate ekstra helptsjinsten ynstalleare wurde, ynklusyf foar in webserver of databank: sykmasine, e-postsysteem, ensfh.
In spesjaal taret server fungearret as romte foar it bewarjen fan reservekopyen; wy sille der letter yn mear detail oer skriuwe.
Logyske organisaasje fan it skiif systeem
As jo in RAID-controller, of in VPS mei ien skiif, en der binne gjin spesjale foarkarren foar de wurking fan de skiif subsysteem (bygelyks, in aparte flugge skiif foar in databank), alle frije romte wurdt ferdield as folget: ien partition wurdt oanmakke, en in LVM folume groep wurdt makke boppe op it, ferskate folumes wurde makke yn it: 2 lytse fan deselde grutte, brûkt as it root triem systeem (ien foar ien feroare tidens updates foar de mooglikheid fan flugge rollback, it idee waard oppakt út 'e Linux-distribúsje berekkenje), in oare is foar de ruilferdieling, de rest fan' e frije romte is ferdield yn lytse folumes, brûkt as it rootbestânsysteem foar folsleine konteners, skiven foar firtuele masines, bestân systemen foar akkounts yn /home (elk akkount hat in eigen bestânsysteem), bestânsystemen foar applikaasjekonteners.
Wichtige opmerking: bondels moatte folslein selsstannich wêze, d.w.s. moatte net ôfhinklik wêze fan elkoar of fan it rootbestânsysteem. Yn it gefal fan firtuele masines of konteners wurdt dit punt automatysk waarnommen. As dit applikaasjekonteners of thúsmappen binne, moatte jo tinke oan it skieden fan de konfiguraasjebestannen fan 'e webserver en oare tsjinsten op sa'n manier dat ôfhinklikens tusken de folumes safolle mooglik eliminearje. Bygelyks, elke side rint fan in eigen brûker, de side-konfiguraasjebestannen binne yn 'e thúsmap fan' e brûker, yn 'e webserverynstellingen binne sidekonfiguraasjebestannen net opnommen fia /etc/nginx/conf.d/.conf, en bygelyks /home//configs/nginx/*.conf
As d'r ferskate skiven binne, kinne jo in software RAID-array oanmeitsje (en har caching konfigurearje op in SSD, as d'r in need en kâns is), wêrop jo LVM kinne bouwe neffens de hjirboppe foarstelde regels. Ek yn dit gefal kinne jo ZFS of BtrFS brûke, mar jo moatte hjir twa kear oer tinke: beide hawwe in folle serieuzere oanpak fan boarnen nedich, en boppedat is ZFS net opnommen mei de Linux-kernel.
Nettsjinsteande it brûkte skema, is it altyd de muoite wurdich om fan tefoaren de ûngefear snelheid fan it skriuwen fan wizigingen nei skiven te skatten, en dan it bedrach fan 'e frije romte te berekkenjen dy't reservearre wurdt foar it meitsjen fan snapshots. Bygelyks, as ús tsjinner gegevens skriuwt mei in snelheid fan 10 megabytes per sekonde, en de grutte fan 'e folsleine gegevensarray is 10 terabytes - de syngronisaasjetiid kin in dei berikke (22 oeren - dit is hoefolle sa'n folume sil wurde oerdroegen oer it netwurk 1 Gbps) - it is it wurdich te reservearjen oer 800 GB . Yn 'e realiteit sil it figuer lytser wêze; jo kinne it feilich diele troch it oantal logyske folumes.
Reservekopy opslach tsjinner apparaat
It wichtichste ferskil tusken in server foar it bewarjen fan reservekopyen is syn grutte, goedkeape en relatyf stadige skiven. Om't moderne HDD's de 10TB-bar yn ien skiif al oerstutsen hawwe, is it nedich om bestânsystemen of RAID te brûken mei kontrôlesums, om't by de werbou fan 'e array of de restauraasje fan it bestânsysteem (ferskate dagen!) De twadde skiif kin mislearje fanwegen ta ferhege lading. Op skiven mei in kapasiteit fan oant 1TB wie dit net sa gefoelich. Foar ienfâld fan beskriuwing nim ik oan dat de skiifromte is ferdield yn twa dielen fan sawat like grutte (wer, bygelyks mei LVM):
- folumes dy't oerienkomme mei de servers dy't brûkt wurde om brûkersgegevens op te slaan (de lêste makke reservekopy sil op har wurde ynset foar ferifikaasje);
- folumes brûkt as BorgBackup-repositories (gegevens foar reservekopy sille hjir direkt gean).
It prinsipe fan wurking is dat foar elke server foar de BorgBackup-repositories aparte folumes makke wurde, wêr't gegevens fan 'e fjochtsservers sille gean. De repositories operearje yn allinich modus, wat de mooglikheid elimineert om gegevens opsetlik te wiskjen, en troch deduplikaasje en periodyk skjinmeitsjen fan repositories fan âlde backups (jierlikse kopyen bliuwe, moanliks foar it lêste jier, wykliks foar de lêste moanne, deistich foar de ferline wike, mooglik yn spesjale gefallen - oere foar de lêste dei: totaal 24 + 7 + 4 + 12 + jierlikse - likernôch 50 eksimplaren foar eltse tsjinner).
BorgBackup-repositories skeakelje de modus allinich taheakje net yn, ynstee wurdt in ForcedCommand yn .ssh/authorized_keys sa'n ding brûkt:
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.......It spesifisearre paad befettet in wrapperskript boppe op borg, dy't, neist it starten fan de binêr mei parameters, ek begjint it proses fan it werstellen fan de reservekopy nei't de gegevens fuortsmiten binne. Om dit te dwaan, makket it wrapperskript in tagbestân neist it oerienkommende repository. De lêste makke reservekopy wurdt automatysk weromset nei it oerienkommende logyske folume nei it foltôgjen fan it gegevensfollingproses.
Dit ûntwerp lit jo periodyk ûnnedige backups opromje, en foarkomt ek dat fjochtsservers alles wiskje op 'e backup-opslachtsjinner.
Reservekopy proses
De inisjatyfnimmer fan 'e reservekopy is de tawijd tsjinner as VPS sels, om't dit skema mear kontrôle jout oer it backupproses fan' e kant fan dizze tsjinner. Earst wurdt in momintopname nommen fan 'e tastân fan it aktive rootbestânsysteem, dat wurdt monteard en opladen mei BorgBackup nei de backup-opslachtsjinner. Neidat gegevensopfang is foltôge, wurdt de snapshot ûntslein en wiske.
As d'r in lytse databank is (oant 1 GB foar elke side), wurdt in databankdump makke, dy't bewarre wurdt yn it passende logyske folume, wêr't de rest fan 'e gegevens foar deselde side leit, mar sadat de dump is net tagonklik fia de webtsjinner. As de databases grut binne, moatte jo "hot" gegevensferwidering konfigurearje, bygelyks mei xtrabackup foar MySQL, of wurkje mei WAL mei archive_command yn PostgreSQL. Yn dit gefal sil de databank apart wurde hersteld fan 'e sidegegevens.
As konteners of firtuele masines wurde brûkt, moatte jo qemu-guest-agent, CRIU of oare nedige technologyen ynstelle. Yn oare gefallen binne ekstra ynstellingen meastentiids net nedich - wy meitsje gewoan snapshots fan logyske folumes, dy't dan wurde ferwurke op deselde wize as in momintopname fan 'e steat fan it rootbestânsysteem. Nei't de gegevens binne nommen, wurde de foto's wiske.
Fierder wurk wurdt útfierd op de reservekopy opslach tsjinner:
- de lêste reservekopy makke yn elke repository wurdt kontrolearre,
- de oanwêzigens fan in markebestân wurdt kontrolearre, wat oanjout dat it gegevenssammelingsproses foltôge is,
- de gegevens wurde útwreide nei it oerienkommende lokale folume,
- de tag triem wurdt wiske
Server herstel proses
As de haadtsjinner stjert, dan wurdt in ferlykbere tawijd tsjinner lansearre, dy't bootet fan in standertôfbylding. Meast wierskynlik sil de ynlaad plakfine oer it netwurk, mar de datacentertechnikus dy't de tsjinner ynstelle kin dizze standertôfbylding direkt nei ien fan 'e skiven kopiearje. De download bart yn RAM, wêrnei't it herstelproses begjint:
- in fersyk wurdt dien om in blokapparaat fia iscsinbd of in oar ferlykber protokol te heakjen oan in logysk folume dat it rootbestânsysteem fan 'e ferstoarne tsjinner befettet; Sûnt it root-bestânsysteem lyts wêze moat, moat dizze stap yn in pear minuten foltôge wurde. De bootloader wurdt ek restaurearre;
- de struktuer fan lokale logyske folumes wurdt opnij oanmakke, logyske folumes wurde taheakke fan 'e reservekopytsjinner mei de dm_clone kernel module: gegevensherstel begjint, en wizigingen wurde fuortendaliks skreaun nei lokale skiven
- in kontener wurdt lansearre mei alle beskikbere fysike skiven - de funksjonaliteit fan de tsjinner is folslein restaurearre, mar mei fermindere prestaasjes;
- neidat gegevenssyngronisaasje is foltôge, wurde de logyske folumes fan 'e reservekopytsjinner loskeppele, de kontener is útskeakele en de tsjinner wurdt opnij starte;
Nei in trochstart sil de tsjinner alle gegevens hawwe dy't der wiene op it momint dat de reservekopy waard makke, en sil ek alle wizigingen befetsje dy't makke binne tidens it weromsetteproses.
Oare artikels yn 'e rige
Reservekopy Part 7: Konklúzjes
Ik noegje jo út om de foarstelde opsje te besprekken yn 'e kommentaren, tank foar jo oandacht!
Boarne: www.habr.com