Wêrom moatte jo backups meitsje? De apparatuer is ommers heul, heul betrouber, en boppedat binne d'r "wolken" dy't better binne yn betrouberens as fysike tsjinners: mei juste konfiguraasje kin in "wolk" tsjinner maklik it mislearjen fan in ynfrastruktuer fysike tsjinner oerlibje, en fanút it eachpunt fan tsjinst brûkers, der sil in lytse, amper merkber sprong yn de tiid tsjinst. Dêrnjonken fereasket duplikaasje fan ynformaasje faak beteljen foar "ekstra" prosessortiid, skiifladen en netwurkferkear.
In ideaal programma rint fluch, lekt gjin ûnthâld, hat gjin gatten en bestiet net.
-Ûnbekend
Om't programma's noch altyd skreaun wurde troch proteïne-ûntwikkelders, en d'r faaks gjin testproses is, plus programma's wurde komselden levere mei "best practices" (dy't sels ek programma's binne en dus ûnfolslein), moatte systeembehearders meastentiids problemen oplosse dy't koart klinke, mar koart: "werom nei hoe't it wie", "bring de basis nei normale wurking", "wurket stadich - rôlje werom", en ek myn favorite "Ik wit net wat, mar reparearje it".
Neist logyske flaters dy't ûntsteane as gefolch fan achteleas wurk fan ûntwikkelders, as in kombinaasje fan omstannichheden, lykas ûnfolsleine kennis of misferstân fan lytse funksjes fan bouprogramma's - ynklusyf ferbining en systeem, ynklusyf bestjoeringssystemen, bestjoerders en firmware - der binne ek oare flaters. Bygelyks, de measte ûntwikkelders fertrouwe op runtime, folslein ferjitte oer fysike wetten, dy't noch ûnmooglik binne om te omgean mei programma's. Dit omfettet de ûneinige betrouberens fan it skiif subsysteem en, yn it algemien, alle gegevens opslach subsysteem (ynklusyf RAM en prosessor cache!), En nul ferwurkjen tiid op 'e prosessor, en it ûntbrekken fan flaters by oerdracht oer it netwurk en ûnder ferwurkjen op de prosessor. prosessor, en netwurk latency, dat is gelyk oan 0. Jo moatte net negearje de beruchte deadline, want as jo net foldwaan oan it yn 'e tiid, der sil wêze slimmer problemen as de nuânses fan netwurk en skiif operaasje.
Wat te dwaan mei problemen dy't yn folle krêft opkomme en hingje oer weardefolle gegevens? Der is neat te ferfangen libbene ûntwikkelders, en it is net in feit dat it sil mooglik wêze yn de heine takomst. Oan 'e oare kant binne mar in pear projekten der yn slagge om folslein te bewizen dat it programma wurket lykas bedoeld, en it sil net needsaaklikerwize mooglik wêze om it bewiis te nimmen en ta te passen op oare, ferlykbere projekten. Ek, sa'n bewiis nimt in protte tiid en fereasket spesjale feardichheden en kennis, en dit minimearret de mooglikheid fan har gebrûk praktysk mei rekken fan deadlines. Dêrnjonken witte wy noch net hoe't wy ultrasnelle, goedkeape en ûneinich betroubere technology kinne brûke foar it opslaan, ferwurkjen en oerdragen fan ynformaasje. Sokke technologyen, as se bestean, binne yn 'e foarm fan begripen, of - meast - allinich yn science fiction-boeken en films.
Goede artysten kopiearje, grutte artysten stelle.
- Pablo Picasso.
De meast súksesfolle oplossingen en ferrassend ienfâldige dingen barre gewoanlik wêr't konsepten, technologyen, kennis en wittenskiplike gebieten dy't op it earste each absolút ynkompatibel binne gearkomme.
Bygelyks, fûgels en fleantugen hawwe wjukken, mar nettsjinsteande de funksjonele oerienkomst - it prinsipe fan wurking yn guon modi is itselde, en technyske problemen wurde oplost op in fergelykbere manier: holle bonken, it brûken fan sterke en lichtgewicht materialen, ensfh - de resultaten binne folslein oars, hoewol tige ferlykber. De bêste foarbylden dy't wy yn ús technology sjogge, binne ek foar in grut part ûntliend oan 'e natuer: de komprimearre kompartementen fan skippen en ûnderseeboaten binne in direkte analogy mei anneliden; it bouwen fan raid-arrays en kontrolearjen fan gegevensintegriteit - duplikaasje fan 'e DNA-ketting; lykas keppele organen, ûnôfhinklikens fan it wurk fan ferskate organen fan it sintrale senuwstelsel (automatisearring fan it hert) en refleksen - autonome systemen op it ynternet. Fansels is it nimmen en tapassen fan klearebare oplossingen "head-on" fol problemen, mar wa wit, miskien binne der gjin oare oplossingen.
As ik mar wist wêr't jo falle soene, dan hie ik strie útlein!
- Wyt-Russysk folkswurd
Dit betsjut dat reservekopyen essensjeel binne foar dyjingen dy't wolle:
- Kin de wurking fan jo systemen weromsette mei minimale downtime, of sels hielendal sûnder
- Akte frijmoedich, want yn gefal fan in flater is d'r altyd de mooglikheid fan in rollback
- Minimalisearje de gefolgen fan opsetlike datakorrupsje
Hjir is in lytse teory
Elke klassifikaasje is willekeurich. De natuer klassifisearret net. Wy klassifisearje omdat it is handiger foar ús. En wy klassifisearje neffens gegevens dy't wy ek willekeurich nimme.
—Jean Bruler
Nettsjinsteande de fysike opslachmetoade kin logyske gegevensopslach ferdield wurde yn twa manieren om tagong te krijen ta dizze gegevens: blok en bestân. Dizze divyzje is koartlyn heul wazig west, om't puur blok, lykas allinich bestân, logyske opslach net bestiet. Lykwols, foar de ienfâld, wy sille oannimme dat se bestean.
Blokkearje gegevens opslach ymplisearret dat der in fysyk apparaat dêr't gegevens wurde skreaun yn bepaalde fêste dielen, blokken. Blokken wurde tagong op in bepaald adres elk blok hat in eigen adres binnen it apparaat.
In reservekopy wurdt normaal makke troch it kopiearjen fan blokken fan gegevens. Om de yntegriteit fan gegevens te garandearjen, wurde de opname fan nije blokken, lykas feroaringen oan besteande, ophâlden op it momint fan kopiearjen. As wy in analogy fan 'e gewoane wrâld nimme, is it tichtste in kast mei identike nûmere sellen.
Opslach fan triemgegevens basearre op it logyske apparaatprinsipe is tichtby blokopslach en wurdt faaks boppe-oan organisearre. Wichtige ferskillen binne de oanwêzigens fan in opslachhierarchy en minsklik lêsbere nammen. Abstraksje wurdt tawiisd yn 'e foarm fan in bestân - in neamd gegevensgebiet, lykas in map - in spesjale triem wêryn beskriuwingen en tagong ta oare bestannen wurde opslein. Bestannen kinne wurde levere mei ekstra metadata: tiid oanmeitsjen, tagongsflaggen, ensfh. Reservekopyen wurde meastentiids op dizze manier dien: se sykje nei feroare bestannen, kopiearje se dan nei in oare bestannen opslach mei deselde struktuer. Gegevensintegriteit wurdt normaal ymplementearre troch it ûntbrekken fan bestannen nei skreaun. Bestânmetadata wurdt op deselde wize reservekopy makke. De neiste analogy is in bibleteek, dy't seksjes hat mei ferskate boeken, en ek in katalogus hat mei nammen fan 'e boeken dy't troch de minske lêsber binne.
Koartlyn wurdt soms in oare opsje beskreaun, wêrfan, yn prinsipe, de opslach fan triemgegevens begon, en dy't deselde archayske skaaimerken hat: opslach fan objektgegevens.
It ferskilt fan triem opslach yn dat it hat net mear as ien nêst (plat skema), en de triemnammen, hoewol't minsken lêsber, binne noch mear geskikt foar ferwurking troch masines. By it útfieren fan backups wurdt opslach fan objekten meastentiids fergelykber behannele mei bestânopslach, mar soms binne d'r oare opsjes.
- D'r binne twa soarten systeembehearders, dejingen dy't gjin backups meitsje, en dejingen dy't it ALLE dogge.
- Eins binne d'r trije soarten: d'r binne ek dyjingen dy't kontrolearje dat backups kinne wurde werombrocht.-Ûnbekend
It is ek de muoite wurdich om te begripen dat it proses foar reservekopy fan gegevens sels wurdt útfierd troch programma's, dus it hat allegear deselde neidielen as alle oare programma's. Om ôfhinklikens fan 'e minsklike faktor te ferwiderjen (net te eliminearjen!) en ek funksjes - dy't yndividueel gjin sterk effekt hawwe, mar tegearre in merkber effekt jaan kinne - de saneamde regel 3-2-1. D'r binne in protte opsjes foar hoe't jo it ûntsiferje, mar ik fyn de folgjende ynterpretaasje better: 3 sets fan deselde gegevens moatte wurde opslein, 2 sets moatte wurde opslein yn ferskate formaten, en 1 set moat wurde opslein yn in geografysk opslach op ôfstân.
It opslachformaat moat as folget wurde begrepen:
- As der in ôfhinklikheid fan de fysike opslach metoade, wy feroarje de fysike metoade.
- As der in ôfhinklikheid fan de logyske opslach metoade, wy feroarje de logyske metoade.
Om it maksimale effekt fan 'e 3-2-1-regel te berikken, wurdt it oanrikkemandearre om it opslachformaat op beide manieren te feroarjen.
Ut it eachpunt fan 'e reewilligens fan in reservekopy foar it beëage doel - werstellen fan funksjonaliteit - wurdt in ûnderskied makke tusken "hot" en "kâld" backups. Hotte ferskille yn mar ien ding fan kâlde: se binne direkt klear foar gebrûk, wylst kâlde wat ekstra stappen nedich binne foar herstel: ûntsiferje, ekstrahearje út it argyf, ensfh.
Net betize waarme en kâlde kopyen mei online en offline kopyen, dy't ymplisearret fysike isolaasje fan gegevens en, yn feite, binne in oar teken fan de klassifikaasje fan reservekopy metoaden. Dus in offline kopy - net direkt ferbûn mei it systeem wêr't it moat wurde restaurearre - kin hjit of kâld wêze (yn termen fan reewilligens foar herstel). In online kopy kin direkt beskikber wêze wêr't it moat wurde restaurearre, en meastal is it hyt, mar der binne ek kâld.
Dêrneist ferjit net dat it proses fan it meitsjen fan reservekopyen sels gewoanlik net einiget mei it meitsjen fan ien reservekopy, en d'r kin in frij grut oantal kopyen wêze. Dêrom is it nedich om te ûnderskieden tusken folsleine backups, d.w.s. dyjingen dy't ûnôfhinklik fan oare reservekopyen weromset wurde kinne, en ek differinsjaal (ynkrementeel, differinsjaal, dekrementeel, ensfh.) kopyen - dyjingen dy't net selsstannich weromset wurde kinne en de foarriedige restauraasje fan ien of mear oare reservekopyen fereaskje.
Differinsjaal inkrementele backups binne in besykjen om backup opslachromte te bewarjen. Sa wurde allinich feroare gegevens fan 'e foarige reservekopy skreaun nei de reservekopy.
Differinsjaal dekrementele wurde makke foar itselde doel, mar op in wat oare manier: in folsleine reservekopy wurdt makke, mar allinich it ferskil tusken de frisse kopy en de foarige wurdt feitlik bewarre.
Apart is it wurdich te beskôgjen it proses fan reservekopy oer opslach, dy't it ûntbrekken fan opslach fan duplikaten stipet. Sa, as jo skriuwe folsleine backups boppe op it, allinne de ferskillen tusken de backups sille eins wurde skreaun, mar it proses fan it weromsette fan de backups sil wêze gelyk oan weromsette fan in folsleine kopy en folslein transparant.
Quis custodiet ipsos custodes?
(Wa sil de wachters sels bewarje? - lat.)
It is heul onaangenaam as d'r gjin reservekopyen binne, mar it is folle slimmer as in reservekopy liket te wêzen makke, mar by it weromsetten docht bliken dat it net weromset wurde kin omdat:
- De yntegriteit fan 'e boarnegegevens is kompromittearre.
- De reservekopy opslach is skansearre.
- Restauraasje wurket heul stadich, jo kinne gjin gegevens brûke dy't foar in part hersteld binne.
In goed konstruearre backupproses moat rekken hâlde mei sokke opmerkingen, benammen de earste twa.
De yntegriteit fan 'e boarnegegevens kin op ferskate manieren garandearre wurde. De meast brûkte binne de folgjende: a) it meitsjen fan snapshots fan it bestânsysteem op bloknivo, b) "befrieze" de steat fan it bestânsysteem, c) in spesjaal blokapparaat mei ferzje opslach, d) opfolgjende opname fan bestannen of blokken. Kontrolsums wurde ek tapast om te soargjen dat gegevens wurde ferifiearre tidens herstel.
Opslachkorrupsje kin ek wurde ûntdutsen mei kontrôlesummen. In ekstra metoade is it brûken fan spesjalisearre apparaten of bestânssystemen wêryn al opnommen gegevens net feroare wurde kinne, mar nije kinne wurde tafoege.
Om herstel te rapperjen, wurdt gegevensherstel brûkt mei meardere prosessen foar herstel - op betingst dat d'r gjin knelpunt is yn 'e foarm fan in traach netwurk of traach skiifsysteem. Om de situaasje mei foar in part weromhelle gegevens te krijen, kinne jo it backupproses brekke yn relatyf lytse subtaken, elk fan dy wurdt apart útfierd. Sa wurdt it mooglik om konsekwint prestaasjes te herstellen by it foarsizzen fan de hersteltiid. Dit probleem leit meastentiids yn it organisatoarysk fleantúch (SLA), dus wy sille hjir net yn detail oer dwaen.
In ekspert op it mêd fan krûden is net dejinge dy't se oan elk skûtel taheakket, mar dejinge dy't der noait wat ekstra oan tafoeget.
-YN. Sinyavsky
Praktyken oangeande de software brûkt troch systeembehearders kinne ferskille, mar de algemiene prinsipes binne noch altyd, op ien of oare manier, itselde, yn it bysûnder:
- It is sterk oan te rieden om klearmakke oplossingen te brûken.
- Programma's moatte foarsisber wurkje, d.w.s. D'r moatte gjin net-dokumintearre funksjes of knyppunten wêze.
- It ynstellen fan elk programma moat sa ienfâldich wêze dat jo net elke kear de hantlieding of cheatblêd hoege te lêzen.
- As it mooglik is, moat de oplossing universeel wêze, om't tsjinners kinne ferskille sterk yn harren hardware skaaimerken.
D'r binne de folgjende mienskiplike programma's foar it nimmen fan backups fan blokapparaten:
- dd, bekend foar systeem administraasje feteranen, dit omfettet ek ferlykbere programma (deselde dd_rescue, bygelyks).
- Utilities ynboud yn guon bestânsystemen dy't in dump meitsje fan it bestânsysteem.
- Omnivorous nutsbedriuwen; bygelyks partclone.
- Eigen, faaks eigen, besluten; bygelyks, NortonGhost en letter.
Foar bestânssystemen wurdt it backupprobleem foar in part oplost mei metoaden dy't tapast wurde foar blokapparaten, mar it probleem kin effisjinter oplost wurde mei bygelyks:
- Rsync, in algemien-doel programma en protokol foar syngronisaasje fan de steat fan triem systemen.
- Ynboude ark foar argivearjen (ZFS).
- Argyf ark fan tredden; de meast populêre fertsjintwurdiger is tar. Der binne oaren, bygelyks, dar - in ferfanging foar tar rjochte op moderne systemen.
It is it wurdich om apart te neamen oer software-ark om konsistinsje fan gegevens te garandearjen by it meitsjen fan reservekopyen. De meast brûkte opsjes binne:
- Montearje it bestânsysteem yn allinich-lêsmodus (ReadOnly), of befrieze it bestânsysteem (freeze) - de metoade is fan beheinde tapasberens.
- Snapshots meitsje fan 'e steat fan bestânsystemen as blokapparaten (LVM, ZFS).
- It gebrûk fan ark fan tredden foar it organisearjen fan yndrukken, sels yn gefallen wêr't de foarige punten om ien of oare reden net kinne wurde levere (programma's lykas hotcopy).
- De technyk foar kopiearje-op-feroaring (CopyOnWrite), lykwols, is it meast bûn oan it brûkte bestânsysteem (BTRFS, ZFS).
Dat, foar in lytse server moatte jo in reservekopyskema leverje dat foldocht oan de folgjende easken:
- Maklik te brûken - gjin spesjale ekstra stappen binne nedich by operaasje, minimale stappen om kopyen te meitsjen en te herstellen.
- Universele - wurket op sawol grutte as lytse servers; dit is wichtich by it groeien fan it oantal tsjinners of skaalfergrutting.
- Ynstallearre troch in pakketbehearder, of yn ien of twa kommando's lykas "downloade en útpakke".
- Stabyl - in standert as lang fêstige opslachformaat wurdt brûkt.
- Snel yn it wurk.
Oanfregers fan dyjingen dy't min of mear foldogge oan de easken:
- rdiff-backup
- rsnapshot
- burp
- duplikaat
- dûbeldens
- lit dup
- smel
- zbackup
- restic
- borgbackup
In firtuele masine (basearre op XenServer) mei de folgjende skaaimerken sil brûkt wurde as testbank:
- 4 kearnen 2.5 GHz,
- 16 GB RAM,
- 50 GB hybride opslach (opslachsysteem mei caching op SSD 20% fan 'e firtuele skiifgrutte) yn' e foarm fan in aparte firtuele skiif sûnder partitionearring,
- 200 Mbits ynternetkanaal.
Hast deselde masine sil brûkt wurde as in reservekopy ûntfanger tsjinner, allinnich mei in 500 GB hurde skiif.
Bestjoeringssysteem - Centos 7 x64: standert partysje, ekstra partysje sil brûkt wurde as gegevensboarne.
As earste gegevens, litte wy in WordPress-side nimme mei 40 GB oan mediabestannen en in mysql-database. Sûnt firtuele tsjinners fariearje sterk yn skaaimerken, en ek foar bettere reproducibility, hjir is
tsjinner testresultaten mei sysbench.sysbench --threads=4 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.1.0-18a9f86 (gebrûk fan bondele LuaJIT 2.1.0-beta3)
De test útfiere mei folgjende opsjes:
Oantal triedden: 4
Inisjalisearjen fan willekeurige getallengenerator fan aktuele tiid
Prime getallen limyt: 20000
Worker threads inisjalisearje ...
Diskusjes begûnen!
CPU snelheid:
events per sekonde: 836.69
Trochslach:
events / s (eps): 836.6908
tiid ferlyn: 30.0039s
totaal oantal eveneminten: 25104
Wachttiid (ms):
myn: 2.38
gem: 4.78
maksimum: 22.39
95e percentiel: 10.46
som: 119923.64
Diskusje earlikens:
events (avg / stddev): 6276.0000 / 13.91
útfiering tiid (avg / 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 (gebrûk fan bondele LuaJIT 2.1.0-beta3)
De test útfiere mei folgjende opsjes:
Oantal triedden: 4
Inisjalisearjen fan willekeurige getallengenerator fan aktuele tiid
It útfieren fan ûnthâldsnelheidstest mei de folgjende opsjes:
block grutte: 1KiB
totale grutte: 102400MiB
operaasje: lêzen
omfang: globaal
Worker threads inisjalisearje ...
Diskusjes begûnen!
Totale operaasjes: 50900446 (1696677.10 per sekonde)
49707.47 MiB oerdroegen (1656.91 MiB/sek)
Trochslach:
events / s (eps): 1696677.1017
tiid ferlyn: 30.0001s
totaal oantal eveneminten: 50900446
Wachttiid (ms):
myn: 0.00
gem: 0.00
maksimum: 24.01
95e percentiel: 0.00
som: 39106.74
Diskusje earlikens:
events (avg / stddev): 12725111.5000 / 137775.15
útfiering tiid (avg / stddev): 9.7767 / 0.10
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=skriuw ûnthâld run
sysbench 1.1.0-18a9f86 (gebrûk fan bondele LuaJIT 2.1.0-beta3)
De test útfiere mei folgjende opsjes:
Oantal triedden: 4
Inisjalisearjen fan willekeurige getallengenerator fan aktuele tiid
It útfieren fan ûnthâldsnelheidstest mei de folgjende opsjes:
block grutte: 1KiB
totale grutte: 102400MiB
operaasje: skriuwe
omfang: globaal
Worker threads inisjalisearje ...
Diskusjes begûnen!
Totale operaasjes: 35910413 (1197008.62 per sekonde)
35068.76 MiB oerdroegen (1168.95 MiB/sek)
Trochslach:
events / s (eps): 1197008.6179
tiid ferlyn: 30.0001s
totaal oantal eveneminten: 35910413
Wachttiid (ms):
myn: 0.00
gem: 0.00
maksimum: 16.90
95e percentiel: 0.00
som: 43604.83
Diskusje earlikens:
events (avg / stddev): 8977603.2500 / 233905.84
útfiering tiid (avg / 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 (gebrûk fan bondele LuaJIT 2.1.0-beta3)
De test útfiere mei folgjende opsjes:
Oantal triedden: 4
Inisjalisearjen fan willekeurige getallengenerator fan aktuele tiid
Ekstra bestân iepen flaggen: (gjin)
128 triemmen, 8MiB elk
1GiB totale triemgrutte
Blokgrutte 4KiB
Oantal IO-oanfragen: 0
Lês- / skriuwferhâlding foar kombineare willekeurige IO-test: 1.50
Periodyk FSYNC ynskeakele, calling fsync () elk 100 fersiken.
Calling fsync () oan 'e ein fan test, Ynskeakele.
Mei help fan syngroane I / O modus
Doing willekeurige r / w test
Worker threads inisjalisearje ...
Diskusjes begûnen!
Trochslach:
lês: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
skriuwe: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98
Wachttiid (ms):
myn: 0.00
gem: 0.27
maksimum: 18.01
95e percentiel: 1.08
som: 238469.45
Dizze notysje begjint in grutte
rige artikels oer backup
- Reservekopy, diel 1: Wêrom reservekopy nedich is, resinsje fan metoaden, technologyen
- Reservekopy, diel 2: Besjoch en testen fan rsync-basearre backup-ark
- Reservekopy Diel 3: Review en Testing duplicity, duplicatety, deja dup
- Reservekopy Part 4: Zbackup, restic, borgbackup resinsje en testen
- Reservekopy, diel 5: Bacula en veeam-backup testen foar Linux
- Reservekopy Diel 6: Fergeliking fan reservekopy-ark
- Reservekopy Part 7: Konklúzjes
Boarne: www.habr.com