Hoekom moet jy rugsteun maak? Die toerusting is immers baie, baie betroubaar, en buitendien is daar "wolke" wat beter in betroubaarheid is as fisiese bedieners: met behoorlike opstelling kan 'n "wolk" bediener maklik die mislukking van 'n infrastruktuur fisiese bediener oorleef, en van die oogpunt van diensgebruikers, sal daar 'n klein, skaars merkbare sprong in tyd diens wees. Daarbenewens vereis duplisering van inligting dikwels dat betaal word vir "ekstra" verwerkertyd, skyflading en netwerkverkeer.
'n Ideale program loop vinnig, lek nie geheue nie, het geen gate nie en bestaan nie.
- Onbekend
Aangesien programme steeds deur proteïenontwikkelaars geskryf word, en daar dikwels geen toetsproses is nie, plus programme word selde gelewer deur gebruik te maak van "beste praktyke" (wat self ook programme is en dus onvolmaak), moet stelseladministrateurs meestal probleme oplos wat kortliks klink, maar bondig: “keer terug na hoe dit was”, “bring die basis na normale werking”, “werk stadig – rol terug”, en ook my gunsteling “Ek weet nie wat nie, maar maak dit reg”.
Benewens logiese foute wat ontstaan as gevolg van sorgelose werk van ontwikkelaars, of 'n kombinasie van omstandighede, sowel as onvolledige kennis of misverstand van klein kenmerke van die bou van programme - insluitend verbinding en stelsels, insluitend bedryfstelsels, drywers en firmware - daar is ook ander foute. Die meeste ontwikkelaars maak byvoorbeeld staat op looptyd, en vergeet heeltemal van fisiese wette, wat steeds onmoontlik is om met behulp van programme te omseil. Dit sluit in die oneindige betroubaarheid van die skyfsubstelsel en, in die algemeen, enige databergingsubstelsel (insluitend RAM en verwerkerkas!), en geen verwerkingstyd op die verwerker, en die afwesigheid van foute tydens transmissie oor die netwerk en tydens verwerking op die verwerker, en netwerkvertraging, wat gelyk is aan 0. Jy moet nie die berugte sperdatum verwaarloos nie, want as jy dit nie betyds haal nie, sal daar probleme wees wat erger is as die nuanses van netwerk- en skyfbedryf.
Wat om te doen met probleme wat in volle krag styg en oor waardevolle data hang? Daar is niks om lewende ontwikkelaars te vervang nie, en dit is nie 'n feit dat dit in die nabye toekoms moontlik sal wees nie. Aan die ander kant het slegs enkele projekte daarin geslaag om ten volle te bewys dat die program sal werk soos bedoel, en dit sal nie noodwendig moontlik wees om die bewyse op ander soortgelyke projekte te neem en toe te pas nie. Sulke bewyse neem ook baie tyd in beslag en vereis spesiale vaardighede en kennis, en dit verminder die moontlikheid van gebruik daarvan prakties met inagneming van spertye. Daarbenewens weet ons nog nie hoe om ultravinnige, goedkoop en oneindig betroubare tegnologie te gebruik vir die stoor, verwerking en oordrag van inligting nie. Sulke tegnologieë, as hulle bestaan, is in die vorm van konsepte, of - meestal - slegs in wetenskapfiksie-boeke en -films.
Goeie kunstenaars kopieer, groot kunstenaars steel.
— Pablo Picasso.
Die suksesvolste oplossings en verbasend eenvoudige dinge gebeur gewoonlik waar konsepte, tegnologieë, kennis en wetenskapsvelde wat met die eerste oogopslag absoluut onversoenbaar is, ontmoet.
Voëls en vliegtuie het byvoorbeeld vlerke, maar ten spyte van die funksionele ooreenkoms - die beginsel van werking in sommige modusse is dieselfde, en tegniese probleme word op soortgelyke wyse opgelos: hol bene, die gebruik van sterk en liggewig materiale, ens. - die resultate is heeltemal anders, hoewel baie soortgelyk. Die beste voorbeelde wat ons in ons tegnologie sien, is ook grootliks uit die natuur ontleen: die drukkompartemente van skepe en duikbote is 'n direkte analogie met annelide; bou aanvalskikkings en kontrolering van data-integriteit - duplisering van die DNS-ketting; sowel as gepaarde organe, onafhanklikheid van die werk van verskillende organe van die sentrale senuweestelsel (outomatisering van die hart) en reflekse - outonome stelsels op die internet. Natuurlik is die neem en toepas van klaargemaakte oplossings “kop-aan” belaai met probleme, maar wie weet, miskien is daar geen ander oplossings nie.
As ek maar geweet het waar jy sou val, sou ek strooitjies uitgelê het!
—Belo-Russiese volksspreekwoord
Dit beteken dat rugsteunkopieë noodsaaklik is vir diegene wat wil:
- In staat wees om die werking van jou stelsels te herstel met minimale stilstand, of selfs daarsonder
- Tree met vrymoedigheid op, want in die geval van 'n fout is daar altyd die moontlikheid van 'n terugrol
- Minimaliseer die gevolge van opsetlike datakorrupsie
Hier is 'n bietjie teorie
Enige klassifikasie is arbitrêr. Die natuur klassifiseer nie. Ons klassifiseer omdat dit vir ons geriefliker is. En ons klassifiseer volgens data wat ons ook arbitrêr neem.
—Jean Bruler
Ongeag die fisiese bergingsmetode, kan logiese databerging in twee maniere verdeel word om toegang tot hierdie data te verkry: blok en lêer. Hierdie verdeling is onlangs baie vaag, want suiwer blok, sowel as suiwer lêer, logiese berging bestaan nie. Vir eenvoud sal ons egter aanneem dat hulle bestaan.
Blokdataberging impliseer dat daar 'n fisiese toestel is waar data in sekere vaste gedeeltes, blokke, geskryf word. Blokke word by 'n sekere adres verkry; elke blok het sy eie adres binne die toestel.
'n Rugsteun word gewoonlik gemaak deur blokke data te kopieer. Om data-integriteit te verseker, word die opname van nuwe blokke, sowel as veranderinge aan bestaande, opgeskort ten tyde van kopiëring. As ons 'n analogie uit die gewone wêreld neem, is die naaste ding 'n kas met identiese genommerde selle.
Lêerdataberging gebaseer op die logiese toestelbeginsel is naby aan blokberging en word dikwels bo-op georganiseer. Belangrike verskille is die teenwoordigheid van 'n berginghiërargie en mens-leesbare name. 'n Abstraksie word toegeken in die vorm van 'n lêer - 'n benoemde data-area, sowel as 'n gids - 'n spesiale lêer waarin beskrywings en toegang tot ander lêers gestoor word. Lêers kan van addisionele metadata voorsien word: skeppingstyd, toegangsvlae, ens. Rugsteun word gewoonlik op hierdie manier gedoen: hulle soek veranderde lêers en kopieer dit dan na 'n ander lêerberging met dieselfde struktuur. Data-integriteit word gewoonlik geïmplementeer deur die afwesigheid van lêers waarna geskryf word. Lêermetadata word op dieselfde manier gerugsteun. Die naaste analogie is 'n biblioteek, wat afdelings met verskillende boeke het, en ook 'n katalogus met mens-leesbare name van die boeke het.
Onlangs word 'n ander opsie soms beskryf, waaruit in beginsel lêerdataberging begin het, en wat dieselfde argaïese kenmerke het: objekdataberging.
Dit verskil van lêerberging deurdat dit nie meer as een nes het nie (plat skema), en die lêername, hoewel mens-leesbaar, is steeds meer geskik vir verwerking deur masjiene. Wanneer rugsteune uitgevoer word, word objekberging meestal soortgelyk aan lêerberging behandel, maar soms is daar ander opsies.
— Daar is twee tipes stelseladministrateurs, dié wat nie rugsteun maak nie, en dié wat REEDS dit doen.
- Eintlik is daar drie tipes: daar is ook diegene wat kyk of rugsteun herstel kan word.- Onbekend
Dit is ook die moeite werd om te verstaan dat die data-rugsteunproses self deur programme uitgevoer word, so dit het dieselfde nadele as enige ander program. Om afhanklikheid van die menslike faktor te verwyder (nie uit te skakel nie!) asook kenmerke - wat individueel nie 'n sterk effek het nie, maar saam 'n merkbare effek kan gee - die sg. reël 3-2-1. Daar is baie opsies vir hoe om dit te ontsyfer, maar ek hou beter van die volgende interpretasie: 3 stelle van dieselfde data moet gestoor word, 2 stelle moet in verskillende formate gestoor word, en 1 stel moet in 'n geografies afgeleë berging gestoor word.
Die stoorformaat moet soos volg verstaan word:
- As daar 'n afhanklikheid van die fisiese bergingsmetode is, verander ons die fisiese metode.
- As daar 'n afhanklikheid van die logiese bergingsmetode is, verander ons die logiese metode.
Om die maksimum effek van die 3-2-1-reël te bereik, word dit aanbeveel om die stoorformaat op beide maniere te verander.
Uit die oogpunt van die gereedheid van 'n rugsteun vir sy beoogde doel - die herstel van funksionaliteit - word 'n onderskeid getref tussen "warm" en "koue" rugsteun. Warm kinders verskil net in een ding van koues: hulle is dadelik gereed vir gebruik, terwyl koues 'n paar bykomende stappe vir herstel vereis: dekripsie, onttrekking uit die argief, ens.
Moenie warm en koue kopieë met aanlyn- en aflynkopieë verwar nie, wat fisiese isolasie van data impliseer en in werklikheid nog 'n teken is van die klassifikasie van rugsteunmetodes. So 'n vanlyn kopie - nie direk gekoppel aan die stelsel waar dit herstel moet word nie - kan óf warm óf koud wees (in terme van gereedheid vir herstel). ’n Aanlynkopie kan direk beskikbaar wees waar dit gerestoureer moet word, en meestal is dit warm, maar daar is ook koues.
Daarbenewens, moenie vergeet dat die proses om rugsteunkopieë self te skep gewoonlik nie eindig met die skepping van een rugsteunkopie nie, en daar kan 'n redelike groot aantal kopieë wees. Daarom is dit nodig om te onderskei tussen volledige rugsteun, m.a.w. dié wat onafhanklik van ander rugsteun herstel kan word, sowel as differensiële (inkrementele, differensiële, dekrementele, ens.) kopieë - dié wat nie onafhanklik herstel kan word nie en die voorlopige herstel van een of meer ander rugsteun vereis.
Differensiële inkrementele rugsteun is 'n poging om rugsteunbergingspasie te bespaar. Slegs veranderde data van die vorige rugsteun word dus na die rugsteunkopie geskryf.
Differensiële dekrementele word vir dieselfde doel geskep, maar op 'n effens ander manier: 'n volledige rugsteunkopie word gemaak, maar slegs die verskil tussen die vars kopie en die vorige een word eintlik gestoor.
Afsonderlik is dit die moeite werd om die proses van rugsteun oor berging te oorweeg, wat die afwesigheid van berging van duplikate ondersteun. Dus, as jy volledige rugsteun bo-op dit skryf, sal slegs die verskille tussen die rugsteun eintlik geskryf word, maar die proses om die rugsteun te herstel sal soortgelyk wees aan die herstel van 'n volledige kopie en heeltemal deursigtig wees.
Is u ipsos-bewaringsbeamptes beskikbaar?
(Wie sal self die wagte bewaak? - lat.)
Dit is baie onaangenaam as daar geen rugsteunkopieë is nie, maar dit is veel erger as dit lyk of 'n rugsteunkopie gemaak is, maar wanneer dit herstel word, blyk dit dat dit nie herstel kan word nie, want:
- Die integriteit van die brondata is gekompromitteer.
- Die rugsteunberging is beskadig.
- Herstel werk baie stadig jy kan nie data gebruik wat gedeeltelik herwin is nie.
'n Behoorlik saamgestelde rugsteunproses moet sulke opmerkings in ag neem, veral die eerste twee.
Die integriteit van die brondata kan op verskeie maniere gewaarborg word. Die mees algemeen gebruikte is die volgende: a) die skep van foto's van die lêerstelsel op die blokvlak, b) die "vries" van die toestand van die lêerstelsel, c) 'n spesiale bloktoestel met weergaweberging, d) opeenvolgende opname van lêers of blokke. Kontrolesomme word ook toegepas om te verseker dat data tydens herstel geverifieer word.
Bergingkorrupsie kan ook opgespoor word deur kontrolesomme te gebruik. 'n Bykomende metode is die gebruik van gespesialiseerde toestelle of lêerstelsels waarin reeds aangetekende data nie verander kan word nie, maar nuwes bygevoeg kan word.
Om herstel te bespoedig, word dataherwinning met veelvuldige prosesse vir herstel gebruik – mits daar geen bottelnek in die vorm van 'n stadige netwerk of stadige skyfstelsel is nie. Om die situasie met gedeeltelik herstelde data te omseil, kan u die rugsteunproses in relatief klein subtake verdeel, wat elkeen afsonderlik uitgevoer word. Dit word dus moontlik om prestasie konsekwent te herstel terwyl die hersteltyd voorspel word. Hierdie probleem lê meestal in die organisatoriese vlak (SLA), so ons sal nie in detail hieroor stilstaan nie.
’n Kenner van speserye is nie die een wat dit by elke gereg voeg nie, maar die een wat nooit iets ekstra daarby voeg nie.
-IN. Sinjawski
Praktyke rakende die sagteware wat deur stelseladministrateurs gebruik word, kan verskil, maar die algemene beginsels is steeds, op een of ander manier, dieselfde, veral:
- Dit word sterk aanbeveel om klaargemaakte oplossings te gebruik.
- Programme moet voorspelbaar werk, m.a.w. Daar behoort geen ongedokumenteerde kenmerke of knelpunte te wees nie.
- Die opstel van elke program moet so eenvoudig wees dat jy nie elke keer die handleiding of cheat sheet hoef te lees nie.
- Indien moontlik, moet die oplossing universeel wees, want bedieners kan baie verskil in hul hardeware-eienskappe.
Daar is die volgende algemene programme om rugsteun vanaf bloktoestelle te neem:
- dd, bekend aan veterane van stelseladministrasie, bevat ook soortgelyke programme (dieselfde dd_rescue, byvoorbeeld).
- Hulpprogramme ingebou in sommige lêerstelsels wat 'n storting van die lêerstelsel skep.
- Omnivore nutsdienste; byvoorbeeld partclone.
- Eie, dikwels eie, besluite; byvoorbeeld NortonGhost en later.
Vir lêerstelsels word die rugsteunprobleem gedeeltelik opgelos deur metodes van toepassing op bloktoestelle, maar die probleem kan meer doeltreffend opgelos word deur byvoorbeeld:
- Rsync, 'n algemene program en protokol om die toestand van lêerstelsels te sinchroniseer.
- Ingeboude argiefinstrumente (ZFS).
- Derdeparty-argiveringsinstrumente; die gewildste verteenwoordiger is teer. Daar is ander, byvoorbeeld dar - 'n plaasvervanger vir teer wat op moderne stelsels gemik is.
Dit is die moeite werd om afsonderlik te noem oor sagteware-instrumente om datakonsekwentheid te verseker wanneer rugsteunkopieë geskep word. Die mees gebruikte opsies is:
- Monteer die lêerstelsel in leesalleen-modus (ReadOnly), of vries die lêerstelsel (vries) - die metode is van beperkte toepaslikheid.
- Skep momentopnames van die toestand van lêerstelsels of bloktoestelle (LVM, ZFS).
- Die gebruik van derdeparty-nutsgoed om indrukke te organiseer, selfs in gevalle waar die vorige punte om een of ander rede nie verskaf kan word nie (programme soos hotcopy).
- Die kopieer-op-verandering-tegniek (CopyOnWrite), is egter meestal gekoppel aan die lêerstelsel wat gebruik word (BTRFS, ZFS).
Dus, vir 'n klein bediener moet u 'n rugsteunskema verskaf wat aan die volgende vereistes voldoen:
- Maklik om te gebruik - geen spesiale bykomende stappe word benodig tydens operasie nie, minimale stappe om kopieë te skep en te herstel.
- Universeel - werk op beide groot en klein bedieners; dit is belangrik wanneer die aantal bedieners groei of skaal.
- Geïnstalleer deur 'n pakketbestuurder, of in een of twee opdragte soos "laai af en pak uit".
- Stabiel - 'n standaard of lang gevestigde stoorformaat word gebruik.
- Vinnig in die werk.
Aansoekers van diegene wat min of meer aan die vereistes voldoen:
- rdiff-rugsteun
- momentopname
- burp
- dupliseer
- valsheid
- laat dup
- maar
- zbackup
- rusties
- borgbackup
'n Virtuele masjien (gebaseer op XenServer) met die volgende kenmerke sal as 'n toetsbank gebruik word:
- 4 kerne 2.5 GHz,
- 16 GB RAM,
- 50 GB hibriede berging (bergingstelsel met kas op SSD 20% van die virtuele skyfgrootte) in die vorm van 'n aparte virtuele skyf sonder partisionering,
- 200 Mbps internetkanaal.
Amper dieselfde masjien sal as 'n rugsteunontvangerbediener gebruik word, net met 'n 500 GB hardeskyf.
Bedryfstelsel - Centos 7 x64: standaard partisie, addisionele partisie sal as 'n databron gebruik word.
As aanvanklike data, kom ons neem 'n WordPress-werf met 40 GB medialêers en 'n mysql-databasis. Aangesien virtuele bedieners baie verskil in eienskappe, en ook vir beter reproduceerbaarheid, hier is
bedienertoetsresultate met behulp van sysbench.sysbench --threads=4 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.1.0-18a9f86 (gebruik gebundelde LuaJIT 2.1.0-beta3)
Begin die toets met die volgende opsies:
Aantal drade: 4
Inisialiseer ewekansige getalgenerator vanaf huidige tyd
Priemgetallelimiet: 20000 XNUMX
Inisialiseer tans werkerdrade …
Drade begin!
SVE spoed:
gebeure per sekonde: 836.69
deurset:
gebeure/s (eps): 836.6908
tyd verloop: 30.0039s
totale aantal geleenthede: 25104
Latency (ms):
min: 2.38
gemiddeld: 4.78
maksimum: 22.39
95ste persentiel: 10.46
som: 119923.64
Threads billikheid:
gebeure (gem/stddev): 6276.0000/13.91
uitvoering tyd (gem/stddev): 29.9809/0.01
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=read memory run
sysbench 1.1.0-18a9f86 (gebruik gebundelde LuaJIT 2.1.0-beta3)
Begin die toets met die volgende opsies:
Aantal drade: 4
Inisialiseer ewekansige getalgenerator vanaf huidige tyd
Hardloop geheue spoed toets met die volgende opsies:
blok grootte: 1KiB
totale grootte: 102400MiB
werking: lees
omvang: wêreldwyd
Inisialiseer tans werkerdrade …
Drade begin!
Totale bewerkings: 50900446 (1696677.10 per sekonde)
49707.47 MiB oorgedra (1656.91 MiB/sek)
deurset:
gebeure/s (eps): 1696677.1017
tyd verloop: 30.0001s
totale aantal geleenthede: 50900446
Latency (ms):
min: 0.00
gemiddeld: 0.00
maksimum: 24.01
95ste persentiel: 0.00
som: 39106.74
Threads billikheid:
gebeure (gem/stddev): 12725111.5000/137775.15
uitvoering tyd (gem/stddev): 9.7767/0.10
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=skryf geheue hardloop
sysbench 1.1.0-18a9f86 (gebruik gebundelde LuaJIT 2.1.0-beta3)
Begin die toets met die volgende opsies:
Aantal drade: 4
Inisialiseer ewekansige getalgenerator vanaf huidige tyd
Hardloop geheue spoed toets met die volgende opsies:
blok grootte: 1KiB
totale grootte: 102400MiB
operasie: skryf
omvang: wêreldwyd
Inisialiseer tans werkerdrade …
Drade begin!
Totale bewerkings: 35910413 (1197008.62 per sekonde)
35068.76 MiB oorgedra (1168.95 MiB/sek)
deurset:
gebeure/s (eps): 1197008.6179
tyd verloop: 30.0001s
totale aantal geleenthede: 35910413
Latency (ms):
min: 0.00
gemiddeld: 0.00
maksimum: 16.90
95ste persentiel: 0.00
som: 43604.83
Threads billikheid:
gebeure (gem/stddev): 8977603.2500/233905.84
uitvoering tyd (gem/stddev): 10.9012/0.41
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.1.0-18a9f86 (gebruik gebundelde LuaJIT 2.1.0-beta3)
Begin die toets met die volgende opsies:
Aantal drade: 4
Inisialiseer ewekansige getalgenerator vanaf huidige tyd
Ekstra lêer oop vlae: (geen)
128 lêers, 8MiB elk
1GiB totale lêergrootte
Blokgrootte 4KiB
Aantal IO-versoeke: 0
Lees/skryf-verhouding vir gekombineerde ewekansige IO-toets: 1.50
Periodieke FSYNC geaktiveer, roep fsync() elke 100 versoeke.
Roep fsync() aan die einde van toets, geaktiveer.
Gebruik sinchroniese I/O-modus
Doen ewekansige r/w toets
Inisialiseer tans werkerdrade …
Drade begin!
deurset:
lees: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
skryf: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98
Latency (ms):
min: 0.00
gemiddeld: 0.27
maksimum: 18.01
95ste persentiel: 1.08
som: 238469.45
Hierdie noot begin 'n groot
reeks artikels oor rugsteun
- Rugsteun, deel 1: Waarom rugsteun nodig is, 'n oorsig van metodes, tegnologieë
- Rugsteun Deel 2: Hersiening en toetsing van rsync-gebaseerde rugsteunnutsgoed
- Rugsteun Deel 3: Hersiening en toetsing van duplisering, duplisering, deja dup
- Rugsteun Deel 4: Hersiening en toetsing van zbackup, restic, borgbackup
- Rugsteun Deel 5: Toets bacula en veeam rugsteun vir Linux
- Rugsteun Deel 6: Vergelyk Rugsteunnutsgoed
- Rugsteun Deel 7: Gevolgtrekkings
Bron: will.com