Pse keni nevojë të bëni kopje rezervë? Në fund të fundit, pajisjet janë shumë, shumë të besueshme, dhe përveç kësaj, ka "re" që janë më të besueshme se serverët fizikë: me konfigurimin e duhur, një server "cloud" mund t'i mbijetojë lehtësisht dështimit të një serveri fizik të infrastrukturës, dhe nga nga këndvështrimi i përdoruesve të shërbimit, do të ketë një kërcim të vogël, mezi të dukshëm në shërbimin në kohë. Përveç kësaj, dyfishimi i informacionit shpesh kërkon pagesën e kohës "shtesë" të procesorit, ngarkesës së diskut dhe trafikut të rrjetit.
Një program ideal funksionon shpejt, nuk rrjedh memorie, nuk ka vrima dhe nuk ekziston.
- E panjohur
Meqenëse programet shkruhen ende nga zhvilluesit e proteinave dhe shpesh nuk ka asnjë proces testimi, plus programet shpërndahen rrallë duke përdorur "praktikat më të mira" (të cilat në vetvete janë gjithashtu programe dhe për këtë arsye të papërsosura), administratorët e sistemit më së shpeshti duhet të zgjidhin probleme që tingëllojnë shkurtimisht, por shkurtimisht: "kthehu ashtu siç ishte", "sjelle bazën në funksionimin normal", "funksionon ngadalë - kthehu prapa", dhe gjithashtu i preferuari im "Nuk e di çfarë, por rregullojeni".
Përveç gabimeve logjike që lindin si rezultat i punës së pakujdesshme të zhvilluesve, ose një kombinim rrethanash, si dhe njohuri të paplota ose keqkuptim të veçorive të vogla të programeve të ndërtimit - duke përfshirë lidhjen dhe ato të sistemit, duke përfshirë sistemet operative, drejtuesit dhe firmware - ka edhe gabime të tjera. Për shembull, shumica e zhvilluesve mbështeten në kohën e ekzekutimit, duke harruar plotësisht ligjet fizike, të cilat janë ende të pamundura për t'u anashkaluar duke përdorur programe. Kjo përfshin besueshmërinë e pafund të nënsistemit të diskut dhe, në përgjithësi, çdo nënsistem të ruajtjes së të dhënave (duke përfshirë RAM-in dhe cache-in e procesorit!), dhe kohën zero të përpunimit në procesor dhe mungesën e gabimeve gjatë transmetimit në rrjet dhe gjatë përpunimit në procesori, dhe vonesa e rrjetit, e cila është e barabartë me 0. Nuk duhet të neglizhoni afatin famëkeq, sepse nëse nuk e përmbushni në kohë, do të ketë probleme më të këqija se nuancat e funksionimit të rrjetit dhe diskut.
Çfarë të bëni me problemet që rriten me forcë të plotë dhe varen mbi të dhëna të vlefshme? Nuk ka asgjë për të zëvendësuar zhvilluesit e gjallë dhe nuk është fakt se do të jetë e mundur në të ardhmen e afërt. Nga ana tjetër, vetëm disa projekte kanë arritur të dëshmojnë plotësisht se programi do të funksionojë siç synohet dhe nuk do të jetë domosdoshmërisht e mundur të merren dhe të zbatohen provat në projekte të tjera të ngjashme. Gjithashtu, dëshmi të tilla kërkojnë shumë kohë dhe kërkojnë aftësi dhe njohuri të veçanta dhe kjo praktikisht minimizon mundësinë e përdorimit të tyre duke marrë parasysh afatet. Përveç kësaj, ne nuk dimë ende se si të përdorim teknologjinë ultra të shpejtë, të lirë dhe pafundësisht të besueshme për ruajtjen, përpunimin dhe transmetimin e informacionit. Teknologji të tilla, nëse ekzistojnë, janë në formën e koncepteve, ose - më shpesh - vetëm në libra dhe filma fantashkencë.
Artistët e mirë kopjojnë, artistët e mëdhenj vjedhin.
- Pablo Picasso.
Zgjidhjet më të suksesshme dhe gjërat çuditërisht të thjeshta zakonisht ndodhin aty ku takohen konceptet, teknologjitë, njohuritë dhe fushat e shkencës që janë absolutisht të papajtueshme në shikim të parë.
Për shembull, zogjtë dhe aeroplanët kanë krahë, por pavarësisht nga ngjashmëria funksionale - parimi i funksionimit në disa mënyra është i njëjtë, dhe problemet teknike zgjidhen në mënyrë të ngjashme: kockat e zbrazëta, përdorimi i materialeve të forta dhe të lehta, etj. - rezultatet janë krejtësisht të ndryshme, edhe pse shumë të ngjashme. Shembujt më të mirë që shohim në teknologjinë tonë janë gjithashtu huazuar kryesisht nga natyra: ndarjet nën presion të anijeve dhe nëndetëseve janë një analogji e drejtpërdrejtë me anelidet; ndërtimi i grupeve të bastisjes dhe kontrollimi i integritetit të të dhënave - dublikimi i zinxhirit të ADN-së; si dhe organet e çiftëzuara, pavarësia e punës së organeve të ndryshme nga sistemi nervor qendror (automatizimi i zemrës) dhe reflekset - sistemet autonome në internet. Natyrisht, marrja dhe aplikimi i zgjidhjeve të gatshme “kokë më kokë” është i mbushur me probleme, por kush e di, ndoshta nuk ka zgjidhje të tjera.
Sikur ta dija se ku do të bije, do të kisha shtruar kashtë!
- Fjalë e urtë popullore bjelloruse
Kjo do të thotë që kopjet rezervë janë jetike për ata që duan të:
- Jini në gjendje të rivendosni funksionimin e sistemeve tuaja me kohë minimale joproduktive, ose edhe pa të fare
- Veproni me guxim, sepse në rast gabimi ekziston gjithmonë mundësia e një rikthimi
- Minimizoni pasojat e korrupsionit të qëllimshëm të të dhënave
Këtu është një teori e vogël
Çdo klasifikim është arbitrar. Natyra nuk klasifikon. Ne klasifikojmë sepse është më i përshtatshëm për ne. Dhe ne klasifikojmë sipas të dhënave që i marrim edhe në mënyrë arbitrare.
- Zhan Bruler
Pavarësisht nga metoda e ruajtjes fizike, ruajtja logjike e të dhënave mund të ndahet në dy mënyra për të aksesuar këto të dhëna: bllok dhe skedar. Kjo ndarje kohët e fundit ka qenë shumë e paqartë, sepse ruajtja logjike nuk ekziston vetëm në bllok, si dhe thjesht skedar. Megjithatë, për thjeshtësi, ne do të supozojmë se ato ekzistojnë.
Bllokimi i ruajtjes së të dhënave nënkupton që ekziston një pajisje fizike ku të dhënat shkruhen në pjesë të caktuara fikse, blloqe. Blloqet aksesohen në një adresë të caktuar; çdo bllok ka adresën e vet brenda pajisjes.
Një kopje rezervë zakonisht bëhet duke kopjuar blloqe të dhënash. Për të siguruar integritetin e të dhënave, regjistrimi i blloqeve të reja, si dhe ndryshimet në ato ekzistuese, pezullohen në momentin e kopjimit. Nëse marrim një analogji nga bota e zakonshme, gjëja më e afërt është një dollap me qeliza identike me numër.
Ruajtja e të dhënave të skedarëve bazuar në parimin logjik të pajisjes është afër ruajtjes së bllokut dhe shpesh organizohet në krye. Dallime të rëndësishme janë prania e një hierarkie të ruajtjes dhe emrave të lexueshëm nga njeriu. Një abstraksion ndahet në formën e një skedari - një zonë e emërtuar e të dhënave, si dhe një drejtori - një skedar i veçantë në të cilin ruhen përshkrimet dhe qasja në skedarë të tjerë. Skedarët mund të furnizohen me meta të dhëna shtesë: koha e krijimit, flamujt e aksesit, etj. Rezervimet zakonisht bëhen në këtë mënyrë: ata kërkojnë skedarë të ndryshuar, pastaj i kopjojnë në një ruajtje tjetër skedari me të njëjtën strukturë. Integriteti i të dhënave zakonisht zbatohet nga mungesa e skedarëve që shkruhen. Meta të dhënat e skedarit kopjohen në të njëjtën mënyrë. Analogjia më e afërt është një bibliotekë, e cila ka seksione me libra të ndryshëm, si dhe ka një katalog me emra të librave të lexueshëm nga njeriu.
Kohët e fundit, ndonjëherë përshkruhet një opsion tjetër, nga i cili, në parim, filloi ruajtja e të dhënave të skedarëve dhe që ka të njëjtat karakteristika arkaike: ruajtja e të dhënave të objektit.
Ai ndryshon nga ruajtja e skedarëve në atë që nuk ka më shumë se një fole (skema e sheshtë), dhe emrat e skedarëve, megjithëse të lexueshëm nga njeriu, janë akoma më të përshtatshëm për përpunim nga makinat. Kur kryeni kopje rezervë, ruajtja e objekteve më së shpeshti trajtohet në mënyrë të ngjashme me ruajtjen e skedarëve, por herë pas here ka opsione të tjera.
— Ekzistojnë dy lloje të administratorëve të sistemit, ata që nuk bëjnë kopje rezervë dhe ata që tashmë bëjnë.
- Në fakt, ekzistojnë tre lloje: ka edhe nga ata që kontrollojnë nëse kopjet rezervë mund të rikthehen.- E panjohur
Vlen gjithashtu të kuptohet se vetë procesi i rezervimit të të dhënave kryhet nga programet, kështu që ka të njëjtat disavantazhe si çdo program tjetër. Për të hequr (mos eliminuar!) varësinë nga faktori njerëzor, si dhe veçoritë - të cilat individualisht nuk kanë një efekt të fortë, por së bashku mund të japin një efekt të dukshëm - të ashtuquajturat. rregulli 3-2-1. Ka shumë opsione se si ta deshifrojmë atë, por më pëlqen më shumë interpretimi i mëposhtëm: 3 grupe të të njëjtave të dhëna duhet të ruhen, 2 grupe duhet të ruhen në formate të ndryshme dhe 1 grup duhet të ruhet në një ruajtje gjeografikisht të largët.
Formati i ruajtjes duhet të kuptohet si më poshtë:
- Nëse ka një varësi nga metoda e ruajtjes fizike, ne ndryshojmë metodën fizike.
- Nëse ka një varësi nga metoda logjike e ruajtjes, ne ndryshojmë metodën logjike.
Për të arritur efektin maksimal të rregullit 3-2-1, rekomandohet të ndryshoni formatin e ruajtjes në të dyja mënyrat.
Nga pikëpamja e gatishmërisë së një kopje rezervë për qëllimin e saj të synuar - rivendosjen e funksionalitetit - bëhet një dallim midis kopjeve rezervë "të nxehta" dhe "të ftohta". Të nxehtat ndryshojnë nga të ftohtit vetëm në një gjë: janë menjëherë gati për përdorim, ndërsa të ftohtit kërkojnë disa hapa shtesë për rikuperim: deshifrim, nxjerrje nga arkivi etj.
Mos ngatërroni kopjet e nxehta dhe të ftohta me kopjet online dhe offline, të cilat nënkuptojnë izolim fizik të të dhënave dhe, në fakt, janë një tjetër shenjë e klasifikimit të metodave rezervë. Pra, një kopje jashtë linje - jo e lidhur drejtpërdrejt me sistemin ku duhet të restaurohet - mund të jetë ose e nxehtë ose e ftohtë (përsa i përket gatishmërisë për rikuperim). Një kopje në internet mund të jetë e disponueshme drejtpërdrejt aty ku duhet të restaurohet, dhe më shpesh është e nxehtë, por ka edhe të ftohta.
Për më tepër, mos harroni se vetë procesi i krijimit të kopjeve rezervë zakonisht nuk përfundon me krijimin e një kopje rezervë, dhe mund të ketë një numër mjaft të madh kopjesh. Prandaj, është e nevojshme të bëhet dallimi midis kopjeve rezervë të plotë, d.m.th. ato që mund të restaurohen në mënyrë të pavarur nga kopjet rezervë të tjera, si dhe kopjet diferenciale (në rritje, diferenciale, zvogëluese, etj.) - ato që nuk mund të restaurohen në mënyrë të pavarur dhe kërkojnë restaurimin paraprak të një ose më shumë kopjeve rezervë të tjera.
Rezervimet diferenciale në rritje janë një përpjekje për të kursyer hapësirën e ruajtjes rezervë. Kështu, vetëm të dhënat e ndryshuara nga rezervimi i mëparshëm shkruhen në kopjen rezervë.
Ato diferenciale zvogëluese krijohen për të njëjtin qëllim, por në një mënyrë paksa të ndryshme: bëhet një kopje rezervë e plotë, por vetëm diferenca midis kopjes së freskët dhe asaj të mëparshme ruhet në të vërtetë.
Më vete, vlen të merret në konsideratë procesi i kopjimit mbi ruajtje, i cili mbështet mungesën e ruajtjes së kopjimeve. Kështu, nëse shkruani kopje rezervë të plotë mbi të, në të vërtetë do të shkruhen vetëm ndryshimet midis kopjeve rezervë, por procesi i rivendosjes së kopjeve rezervë do të jetë i ngjashëm me rikthimin nga një kopje e plotë dhe plotësisht transparent.
Quis custodiet ipsos custodes?
(Kush do t'i ruajë vetë rojet? - lat.)
Është shumë e pakëndshme kur nuk ka kopje rezervë, por është shumë më keq nëse duket se është bërë një kopje rezervë, por gjatë restaurimit rezulton se nuk mund të restaurohet sepse:
- Integriteti i të dhënave burimore është komprometuar.
- Hapësira rezervë është e dëmtuar.
- Rivendosja funksionon shumë ngadalë; nuk mund të përdorni të dhëna që janë rikuperuar pjesërisht.
Një proces rezervë i ndërtuar siç duhet duhet të marrë parasysh komente të tilla, veçanërisht dy të parat.
Integriteti i të dhënave burimore mund të garantohet në disa mënyra. Më të përdorurat janë këto: a) krijimi i fotografive të sistemit të skedarëve në nivel blloku, b) "ngrirja" e gjendjes së sistemit të skedarëve, c) një pajisje blloku speciale me ruajtje të versioneve, d) regjistrimi i njëpasnjëshëm i skedarëve ose blloqe. Shumat e kontrollit aplikohen gjithashtu për të siguruar që të dhënat të verifikohen gjatë rikuperimit.
Korrupsioni i ruajtjes mund të zbulohet gjithashtu duke përdorur kontrolle. Një metodë shtesë është përdorimi i pajisjeve të specializuara ose sistemeve të skedarëve në të cilat të dhënat e regjistruara tashmë nuk mund të ndryshohen, por mund të shtohen të reja.
Për të përshpejtuar rikuperimin, rikuperimi i të dhënave përdoret me procese të shumta për rikuperim - me kusht që të mos ketë pengesë në formën e një rrjeti të ngadaltë ose të një sistemi të ngadaltë të diskut. Për të kapërcyer situatën me të dhënat e rikuperuara pjesërisht, mund ta ndani procesin e rezervimit në nën-detyra relativisht të vogla, secila prej të cilave kryhet veçmas. Kështu, bëhet e mundur rikthimi i vazhdueshëm i performancës duke parashikuar kohën e rikuperimit. Ky problem më së shpeshti qëndron në planin organizativ (SLA), kështu që ne nuk do të ndalemi në këtë në detaje.
Një ekspert në erëza nuk është ai që i shton ato në çdo pjatë, por ai që nuk i shton kurrë asgjë shtesë.
-NË. Sinyavsky
Praktikat në lidhje me softuerin e përdorur nga administratorët e sistemit mund të ndryshojnë, por parimet e përgjithshme janë ende, në një mënyrë ose në një tjetër, të njëjta, në veçanti:
- Rekomandohet fuqimisht përdorimi i zgjidhjeve të gatshme.
- Programet duhet të funksionojnë në mënyrë të parashikueshme, d.m.th. Nuk duhet të ketë veçori ose pengesa të padokumentuara.
- Konfigurimi i çdo programi duhet të jetë aq i thjeshtë sa të mos keni nevojë të lexoni manualin ose fletën e mashtrimit çdo herë.
- Nëse është e mundur, zgjidhja duhet të jetë universale, sepse serverët mund të ndryshojnë shumë në karakteristikat e tyre harduerike.
Ekzistojnë programet e mëposhtme të zakonshme për marrjen e kopjeve rezervë nga pajisjet e bllokut:
- dd, e njohur për veteranët e administrimit të sistemit, kjo përfshin gjithashtu programe të ngjashme (për shembull, i njëjti dd_rescue).
- Shërbimet e integruara në disa sisteme skedarësh që krijojnë një hale të sistemit të skedarëve.
- Shërbime të gjithanshme; për shembull partclone.
- Vendimet vetanake, shpesh pronësore; për shembull, NortonGhost dhe më vonë.
Për sistemet e skedarëve, problemi i rezervimit zgjidhet pjesërisht duke përdorur metoda të zbatueshme për pajisjet e bllokut, por problemi mund të zgjidhet në mënyrë më efikase duke përdorur, për shembull:
- Rsync, një program dhe protokoll për qëllime të përgjithshme për sinkronizimin e gjendjes së sistemeve të skedarëve.
- Mjetet e integruara të arkivimit (ZFS).
- Mjetet e arkivimit të palëve të treta; përfaqësuesi më i njohur është katrani. Ka të tjerë, për shembull, dar - një zëvendësim për katranin që synon sistemet moderne.
Vlen të përmendet veçmas për mjetet softuerike për të siguruar qëndrueshmëri të të dhënave gjatë krijimit të kopjeve rezervë. Opsionet më të përdorura janë:
- Montimi i sistemit të skedarëve në modalitetin vetëm për lexim (ReadOnly), ose ngrirja e sistemit të skedarëve (ngrirje) - metoda është e zbatueshmërisë së kufizuar.
- Krijimi i fotografive të gjendjes së sistemeve të skedarëve ose pajisjeve të bllokut (LVM, ZFS).
- Përdorimi i mjeteve të palëve të treta për organizimin e përshtypjeve, edhe në rastet kur pikat e mëparshme nuk mund të sigurohen për ndonjë arsye (programe si kopjimi i nxehtë).
- Teknika e kopjimit në ndryshim (CopyOnWrite), megjithatë, më së shpeshti është e lidhur me sistemin e skedarëve të përdorur (BTRFS, ZFS).
Pra, për një server të vogël ju duhet të siguroni një skemë rezervë që plotëson kërkesat e mëposhtme:
- Lehtë për t'u përdorur - nuk kërkohen hapa të veçantë shtesë gjatë funksionimit, hapa minimalë për të krijuar dhe rivendosur kopje.
- Universal - funksionon si në serverë të mëdhenj ashtu edhe në të vegjël; kjo është e rëndësishme kur rritet numri i serverëve ose shkallëzohet.
- Instaluar nga një menaxher paketash, ose në një ose dy komanda si "shkarkoni dhe shpaketoni".
- E qëndrueshme - përdoret një format ruajtjeje standard ose i krijuar prej kohësh.
- Të shpejtë në punë.
Aplikantët nga ata që pak a shumë plotësojnë kërkesat:
- rdiff-backup
- rsnapshot
- gromësij
- dublikatë
- hipokrizi
- le dup
- por
- zbackup
- restiku
- borgbackup
Një makinë virtuale (e bazuar në XenServer) me karakteristikat e mëposhtme do të përdoret si një stol testimi:
- 4 bërthama 2.5 GHz,
- 16 GB RAM,
- 50 GB memorie hibride (sistemi i ruajtjes me caching në SSD 20% të madhësisë së diskut virtual) në formën e një disku virtual të veçantë pa ndarje,
- Kanal interneti 200 Mbps.
Pothuajse e njëjta makinë do të përdoret si një server marrës rezervë, vetëm me një hard disk 500 GB.
Sistemi operativ - Centos 7 x64: ndarje standarde, ndarje shtesë do të përdoret si burim të dhënash.
Si të dhëna fillestare, le të marrim një faqe WordPress me 40 GB skedarë mediash dhe një bazë të dhënash mysql. Meqenëse serverët virtualë ndryshojnë shumë në karakteristika, dhe gjithashtu për riprodhueshmëri më të mirë, këtu është
rezultatet e testimit të serverit duke përdorur sysbench.sysbench --threads=4 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.1.0-18a9f86 (duke përdorur LuaJIT 2.1.0-beta3 të paketuar)
Drejtimi i testit me opsionet e mëposhtme:
Numri i fijeve: 4
Inicializimi i gjeneratorit të numrave të rastësishëm nga koha aktuale
Kufiri i numrave kryesorë: 20000
Po inicializohen temat e punëtorëve…
Fillimet filluan!
Shpejtësia e CPU:
ngjarje në sekondë: 836.69
Xhiroja:
ngjarje/at (eps): 836.6908
koha e kaluar: 30.0039 sekonda
numri i përgjithshëm i ngjarjeve: 25104
Vonesa (ms):
min: 2.38
mesatare: 4.78
maksimumi: 22.39
Përqindja e 95-të: 10.46
shuma: 119923.64
Threads drejtësia:
ngjarjet (avg/stddev): 6276.0000/13.91
koha e ekzekutimit (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 running
sysbench 1.1.0-18a9f86 (duke përdorur LuaJIT 2.1.0-beta3 të paketuar)
Drejtimi i testit me opsionet e mëposhtme:
Numri i fijeve: 4
Inicializimi i gjeneratorit të numrave të rastësishëm nga koha aktuale
Ekzekutimi i testit të shpejtësisë së kujtesës me opsionet e mëposhtme:
Madhësia e bllokut: 1 KiB
Madhësia totale: 102400 MiB
operacion: lexo
fushëveprimi: global
Po inicializohen temat e punëtorëve…
Fillimet filluan!
Operacionet totale: 50900446 (1696677.10 për sekondë)
49707.47 MiB të transferuara (1656.91 MiB/sek)
Xhiroja:
ngjarje/at (eps): 1696677.1017
koha e kaluar: 30.0001 sekonda
numri i përgjithshëm i ngjarjeve: 50900446
Vonesa (ms):
min: 0.00
mesatare: 0.00
maksimumi: 24.01
Përqindja e 95-të: 0.00
shuma: 39106.74
Threads drejtësia:
ngjarjet (avg/stddev): 12725111.5000/137775.15
koha e ekzekutimit (avg/stddev): 9.7767/0.10
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=memory-block-size=XNUMXK
sysbench 1.1.0-18a9f86 (duke përdorur LuaJIT 2.1.0-beta3 të paketuar)
Drejtimi i testit me opsionet e mëposhtme:
Numri i fijeve: 4
Inicializimi i gjeneratorit të numrave të rastësishëm nga koha aktuale
Ekzekutimi i testit të shpejtësisë së kujtesës me opsionet e mëposhtme:
Madhësia e bllokut: 1 KiB
Madhësia totale: 102400 MiB
veprim: shkruaj
fushëveprimi: global
Po inicializohen temat e punëtorëve…
Fillimet filluan!
Operacionet totale: 35910413 (1197008.62 për sekondë)
35068.76 MiB të transferuara (1168.95 MiB/sek)
Xhiroja:
ngjarje/at (eps): 1197008.6179
koha e kaluar: 30.0001 sekonda
numri i përgjithshëm i ngjarjeve: 35910413
Vonesa (ms):
min: 0.00
mesatare: 0.00
maksimumi: 16.90
Përqindja e 95-të: 0.00
shuma: 43604.83
Threads drejtësia:
ngjarjet (avg/stddev): 8977603.2500/233905.84
koha e ekzekutimit (avg/stddev): 10.9012/0.41
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G ekzekutimi i skedarit
sysbench 1.1.0-18a9f86 (duke përdorur LuaJIT 2.1.0-beta3 të paketuar)
Drejtimi i testit me opsionet e mëposhtme:
Numri i fijeve: 4
Inicializimi i gjeneratorit të numrave të rastësishëm nga koha aktuale
Flamujt e hapur të skedarëve shtesë: (asnjë)
128 skedarë, 8 MiB secili
Madhësia totale e skedarit 1 GiB
Madhësia e bllokut 4 KiB
Numri i kërkesave të IO: 0
Raporti Lexo/Shkruaj për testin e kombinuar të rastësishëm IO: 1.50
FSYNC periodike është aktivizuar, duke thirrur fsync() çdo 100 kërkesa.
Thirrja e fsync() në fund të testit, Aktivizuar.
Përdorimi i modalitetit sinkron I/O
Bërja e testit r/w rastësor
Po inicializohen temat e punëtorëve…
Fillimet filluan!
Xhiroja:
lexo: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
shkruani: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98
Vonesa (ms):
min: 0.00
mesatare: 0.27
maksimumi: 18.01
Përqindja e 95-të: 1.08
shuma: 238469.45
Ky shënim fillon shumë
seri artikujsh rreth kopjimit
- Rezervimi, pjesa 1: Pse nevojitet një kopje rezervë, një pasqyrë e metodave, teknologjive
- Rezervimi Pjesa 2: Rishikimi dhe testimi i mjeteve rezervë të bazuara në rsync
- Rezervimi Pjesa 3: Rishikimi dhe testimi i dyfishimit, dyfishimit, deja dup
- Rezervimi Pjesa 4: Rishikimi dhe testimi i zbackup, restic, borgbackup
- Rezervimi Pjesa 5: Testimi i kopjes rezervë të bakulës dhe veeam për linux
- Rezervimi Pjesa 6: Krahasimi i mjeteve rezervë
- Pjesa rezervë 7: Përfundime
Burimi: www.habr.com