Bakit kailangan mong gumawa ng mga backup? Pagkatapos ng lahat, ang kagamitan ay napaka, napaka maaasahan, at bukod pa, may mga "ulap" na mas mahusay sa pagiging maaasahan kaysa sa mga pisikal na server: na may wastong pagsasaayos, ang isang "cloud" na server ay madaling makaligtas sa kabiguan ng isang pisikal na server ng imprastraktura, at mula sa sa punto ng view ng mga gumagamit ng serbisyo, magkakaroon ng isang maliit, bahagya na kapansin-pansin na pagtalon sa oras ng serbisyo. Bilang karagdagan, ang pagdoble ng impormasyon ay madalas na nangangailangan ng pagbabayad para sa "dagdag" na oras ng processor, pag-load ng disk, at trapiko sa network.
Ang isang perpektong programa ay tumatakbo nang mabilis, hindi tumagas ng memorya, walang mga butas, at wala.
-Hindi kilala
Dahil ang mga programa ay isinulat pa rin ng mga developer ng protina, at madalas na walang proseso ng pagsubok, at ang mga programa ay bihirang ihatid gamit ang "pinakamahusay na kagawian" (na ang kanilang mga sarili ay mga programa din at samakatuwid ay hindi perpekto), ang mga administrator ng system ay kadalasang kailangang lutasin ang mga problema na sa madaling sabi ngunit maikli: "bumalik sa kung paano ito ay", "dalhin ang base sa normal na operasyon", "mabagal na gumagana - gumulong", at ang paborito kong "Hindi ko alam kung ano, ngunit ayusin ito".
Bilang karagdagan sa mga lohikal na error na lumitaw bilang isang resulta ng walang ingat na gawain ng mga developer, o isang kumbinasyon ng mga pangyayari, pati na rin ang hindi kumpletong kaalaman o hindi pagkakaunawaan ng mga maliliit na tampok ng mga programa sa pagbuo - kabilang ang pagkonekta at mga system, kabilang ang mga operating system, driver at firmware - mayroon ding iba pang mga pagkakamali. Halimbawa, ang karamihan sa mga developer ay umaasa sa runtime, ganap na nakakalimutan ang tungkol sa mga pisikal na batas, na imposible pa ring iwasan ang paggamit ng mga programa. Kabilang dito ang walang katapusang pagiging maaasahan ng disk subsystem at, sa pangkalahatan, anumang data storage subsystem (kabilang ang RAM at processor cache!), at zero processing time sa processor, at ang kawalan ng mga error sa panahon ng paghahatid sa network at sa panahon ng pagproseso sa processor, at network latency, na katumbas ng 0. Hindi mo dapat pabayaan ang kilalang-kilala na deadline, dahil kung hindi mo ito matugunan sa oras, magkakaroon ng mga problema na mas malala kaysa sa mga nuances ng network at disk operation.
Ano ang gagawin sa mga problemang tumataas nang buo at nag-hang sa mahalagang data? Walang mapapalitan ang mga nabubuhay na developer, at hindi ito katotohanan na magiging posible ito sa malapit na hinaharap. Sa kabilang banda, iilan lamang sa mga proyekto ang nagtagumpay sa ganap na pagpapatunay na ang programa ay gagana ayon sa nilalayon, at hindi nangangahulugang posibleng kunin at ilapat ang ebidensya sa iba, katulad na mga proyekto. Gayundin, ang naturang ebidensya ay tumatagal ng maraming oras at nangangailangan ng mga espesyal na kasanayan at kaalaman, at halos pinapaliit nito ang posibilidad ng kanilang paggamit na isinasaalang-alang ang mga deadline. Bilang karagdagan, hindi pa namin alam kung paano gumamit ng ultra-mabilis, mura at walang katapusang maaasahang teknolohiya para sa pag-iimbak, pagproseso at pagpapadala ng impormasyon. Ang ganitong mga teknolohiya, kung mayroon man, ay nasa anyo ng mga konsepto, o - kadalasan - sa mga libro at pelikula lamang ng science fiction.
Ang mga magagaling na artista ay nangopya, ang mga magagaling na artista ay nagnanakaw.
-Pablo Picasso.
Ang pinakamatagumpay na solusyon at nakakagulat na mga simpleng bagay ay kadalasang nangyayari kung saan nagtatagpo ang mga konsepto, teknolohiya, kaalaman, at larangan ng agham na talagang hindi magkatugma sa unang tingin.
Halimbawa, ang mga ibon at eroplano ay may mga pakpak, ngunit sa kabila ng pagkakatulad ng pagganap - ang prinsipyo ng pagpapatakbo sa ilang mga mode ay pareho, at ang mga teknikal na problema ay nalutas sa katulad na paraan: mga guwang na buto, ang paggamit ng malakas at magaan na materyales, atbp. - ang mga resulta ay ganap na naiiba, bagaman halos magkatulad. Ang pinakamahusay na mga halimbawa na nakikita natin sa ating teknolohiya ay higit na hiniram sa kalikasan: ang mga may presyon na mga compartment ng mga barko at submarino ay direktang pagkakatulad sa mga annelids; pagbuo ng mga raid array at pagsuri sa integridad ng data - pagdodoble ng DNA chain; pati na rin ang mga nakapares na organo, pagsasarili ng gawain ng iba't ibang mga organo mula sa central nervous system (automation ng puso) at reflexes - mga autonomous system sa Internet. Siyempre, ang pagkuha at paglalapat ng mga handa na solusyon na "head-on" ay puno ng mga problema, ngunit sino ang nakakaalam, marahil ay walang iba pang mga solusyon.
Kung alam ko lang kung saan ka mahuhulog, naglatag na ako ng mga straw!
βKasabihang katutubong Belarusian
Nangangahulugan ito na ang mga backup na kopya ay mahalaga para sa mga gustong:
- Ma-restore ang pagpapatakbo ng iyong mga system nang may kaunting downtime, o kahit na wala ito
- Kumilos nang buong tapang, dahil sa kaso ng isang error ay palaging may posibilidad ng isang rollback
- I-minimize ang mga kahihinatnan ng sinadyang data corruption
Narito ang isang maliit na teorya
Anumang pag-uuri ay arbitrary. Ang kalikasan ay hindi nag-uuri. Kami ay nag-uuri dahil ito ay mas maginhawa para sa amin. At nag-uuri kami ayon sa data na kinukuha din namin nang arbitraryo.
βJean Bruler
Anuman ang pisikal na paraan ng pag-iimbak, ang lohikal na pag-iimbak ng data ay maaaring nahahati sa dalawang paraan ng pag-access sa data na ito: block at file. Ang dibisyon na ito ay kamakailan lamang ay napakalabo, dahil puro block, pati na rin puro file, lohikal na imbakan ay hindi umiiral. Gayunpaman, para sa pagiging simple, ipagpalagay natin na umiiral ang mga ito.
Ang pag-block ng imbakan ng data ay nagpapahiwatig na mayroong isang pisikal na aparato kung saan ang data ay nakasulat sa ilang mga nakapirming bahagi, mga bloke. Ang mga bloke ay ina-access sa isang tiyak na address; ang bawat bloke ay may sariling address sa loob ng device.
Ang isang backup ay karaniwang ginagawa sa pamamagitan ng pagkopya ng mga bloke ng data. Upang matiyak ang integridad ng data, ang pagtatala ng mga bagong bloke, pati na rin ang mga pagbabago sa mga umiiral na, ay sinuspinde sa oras ng pagkopya. Kung kukuha tayo ng pagkakatulad mula sa ordinaryong mundo, ang pinakamalapit na bagay ay isang aparador na may magkaparehong bilang na mga cell.
Ang storage ng data ng file batay sa lohikal na prinsipyo ng device ay malapit sa pag-block ng storage at kadalasang nakaayos sa itaas. Ang mahahalagang pagkakaiba ay ang pagkakaroon ng storage hierarchy at mga pangalan na nababasa ng tao. Ang isang abstraction ay inilalaan sa anyo ng isang file - isang pinangalanang lugar ng data, pati na rin ang isang direktoryo - isang espesyal na file kung saan ang mga paglalarawan at pag-access sa iba pang mga file ay naka-imbak. Maaaring ibigay ang mga file ng karagdagang metadata: oras ng paggawa, mga flag ng pag-access, atbp. Ang mga pag-backup ay karaniwang ginagawa sa ganitong paraan: naghahanap sila ng mga binagong file, pagkatapos ay kopyahin ang mga ito sa isa pang imbakan ng file na may parehong istraktura. Karaniwang ipinapatupad ang integridad ng data sa pamamagitan ng kawalan ng mga file na sinusulatan. Ang metadata ng file ay naka-back up sa parehong paraan. Ang pinakamalapit na pagkakatulad ay isang silid-aklatan, na may mga seksyon na may iba't ibang mga libro, at mayroon ding katalogo na may mga pangalan ng mga aklat na nababasa ng tao.
Kamakailan, ang isa pang pagpipilian ay minsan ay inilarawan, kung saan, sa prinsipyo, nagsimula ang pag-iimbak ng data ng file, at kung saan ay may parehong mga archaic na tampok: object data storage.
Naiiba ito sa imbakan ng file dahil wala itong higit sa isang nesting (flat scheme), at ang mga pangalan ng file, bagama't nababasa ng tao, ay mas angkop pa rin para sa pagproseso ng mga makina. Kapag nagsasagawa ng mga pag-backup, ang imbakan ng bagay ay kadalasang itinuturing na katulad ng imbakan ng file, ngunit paminsan-minsan ay may iba pang mga opsyon.
β Mayroong dalawang uri ng mga tagapangasiwa ng system, ang mga hindi gumagawa ng mga backup, at ang mga gumagawa na.
- Sa totoo lang, may tatlong uri: mayroon ding mga nagsusuri na ang mga backup ay maaaring maibalik.-Hindi kilala
Ito rin ay nagkakahalaga ng pag-unawa na ang proseso ng pag-backup ng data mismo ay isinasagawa ng mga programa, kaya mayroon itong lahat ng parehong mga disadvantages tulad ng anumang iba pang programa. Upang alisin (hindi alisin!) ang pag-asa sa kadahilanan ng tao, pati na rin ang mga tampok - na indibidwal ay walang malakas na epekto, ngunit magkasama ay maaaring magbigay ng isang kapansin-pansin na epekto - ang tinatawag na tuntunin 3-2-1. Mayroong maraming mga opsyon para sa kung paano i-decipher ito, ngunit mas gusto ko ang sumusunod na interpretasyon: 3 set ng parehong data ay dapat na naka-imbak, 2 set ay dapat na naka-imbak sa iba't ibang mga format, at 1 set ay dapat na naka-imbak sa isang geographically remote na imbakan.
Ang format ng imbakan ay dapat na maunawaan tulad ng sumusunod:
- Kung mayroong pag-asa sa pisikal na paraan ng pag-iimbak, binabago namin ang pisikal na paraan.
- Kung mayroong pag-asa sa lohikal na paraan ng imbakan, binabago namin ang lohikal na paraan.
Upang makamit ang maximum na epekto ng panuntunang 3-2-1, inirerekomendang baguhin ang format ng storage sa parehong paraan.
Mula sa punto ng view ng pagiging handa ng isang backup para sa nilalayon nitong layunin - pagpapanumbalik ng pag-andar - isang pagkakaiba ay ginawa sa pagitan ng "mainit" at "malamig" na mga backup. Ang mga mainit ay naiiba sa mga malamig sa isang bagay lamang: ang mga ito ay agad na handa para sa paggamit, habang ang mga malamig ay nangangailangan ng ilang karagdagang mga hakbang para sa pagbawi: decryption, pagkuha mula sa archive, atbp.
Huwag malito ang mainit at malamig na mga kopya sa mga online at offline na kopya, na nagpapahiwatig ng pisikal na paghihiwalay ng data at, sa katunayan, ay isa pang tanda ng pag-uuri ng mga backup na pamamaraan. Kaya ang isang offline na kopya - hindi direktang konektado sa system kung saan kailangan itong ibalik - ay maaaring maging mainit o malamig (sa mga tuntunin ng kahandaan para sa pagbawi). Ang isang online na kopya ay maaaring makuha nang direkta kung saan kailangan itong ibalik, at kadalasan ito ay mainit, ngunit mayroon ding mga malamig.
Bilang karagdagan, huwag kalimutan na ang proseso ng paglikha ng mga backup na kopya mismo ay karaniwang hindi nagtatapos sa paglikha ng isang backup na kopya, at maaaring mayroong isang medyo malaking bilang ng mga kopya. Samakatuwid, ito ay kinakailangan upang makilala sa pagitan ng buong backup, i.e. ang mga maaaring ibalik nang hiwalay sa iba pang mga backup, pati na rin ang mga pagkakaiba-iba (incremental, differential, decremental, atbp.) na mga kopya - ang mga hindi maaaring maibalik nang nakapag-iisa at nangangailangan ng paunang pagpapanumbalik ng isa o higit pang iba pang mga backup.
Ang mga differential incremental backup ay isang pagtatangka na i-save ang backup na espasyo sa storage. Kaya, ang binagong data lamang mula sa nakaraang backup ang isinulat sa backup na kopya.
Ang mga differential decremental ay nilikha para sa parehong layunin, ngunit sa isang bahagyang naiibang paraan: isang buong backup na kopya ay ginawa, ngunit ang pagkakaiba lamang sa pagitan ng bagong kopya at ang nauna ang aktwal na nakaimbak.
Hiwalay, ito ay nagkakahalaga ng pagsasaalang-alang sa proseso ng backup sa paglipas ng imbakan, na sumusuporta sa kawalan ng imbakan ng mga duplicate. Kaya, kung magsusulat ka ng buong backup sa ibabaw nito, ang mga pagkakaiba lang sa pagitan ng mga backup ang aktwal na isusulat, ngunit ang proseso ng pagpapanumbalik ng mga backup ay magiging katulad ng pagpapanumbalik mula sa isang buong kopya at ganap na transparent.
Quis custodiet ipsos custodes?
(Sino ang magbabantay sa mga bantay mismo? - lat.)
Lubhang hindi kanais-nais kapag walang mga backup na kopya, ngunit mas masahol pa kung ang isang backup na kopya ay tila ginawa, ngunit kapag ibinalik ay lumalabas na hindi ito maibabalik dahil:
- Nakompromiso ang integridad ng source data.
- Nasira ang backup na storage.
- Mabagal na gumagana ang pagpapanumbalik; hindi mo magagamit ang data na bahagyang na-recover.
Ang isang maayos na itinayong backup na proseso ay dapat isaalang-alang ang mga naturang komento, lalo na ang unang dalawa.
Ang integridad ng pinagmumulan ng data ay maaaring matiyak sa maraming paraan. Ang pinakakaraniwang ginagamit ay ang mga sumusunod: a) paglikha ng mga snapshot ng file system sa antas ng block, b) "nagyeyelo" ang estado ng file system, c) isang espesyal na block device na may imbakan ng bersyon, d) sequential recording ng mga file o mga bloke. Inilapat din ang mga checksum upang matiyak na na-verify ang data sa panahon ng pagbawi.
Ang katiwalian sa imbakan ay maaari ding matukoy gamit ang mga checksum. Ang isang karagdagang paraan ay ang paggamit ng mga espesyal na device o file system kung saan hindi na mababago ang naitalang data, ngunit maaaring magdagdag ng mga bago.
Upang mapabilis ang pagbawi, ginagamit ang pagbawi ng data sa maraming proseso para sa pagbawi - sa kondisyon na walang bottleneck sa anyo ng isang mabagal na network o mabagal na sistema ng disk. Upang makayanan ang sitwasyon na may bahagyang na-recover na data, maaari mong hatiin ang proseso ng pag-backup sa medyo maliit na mga subtask, na ang bawat isa ay isinasagawa nang hiwalay. Kaya, nagiging posible na patuloy na maibalik ang pagganap habang hinuhulaan ang oras ng pagbawi. Ang problemang ito ay kadalasang namamalagi sa organisasyonal na eroplano (SLA), kaya hindi namin ito tatalakayin nang detalyado.
Ang isang dalubhasa sa mga pampalasa ay hindi ang isa na nagdaragdag ng mga ito sa bawat ulam, ngunit ang isa na hindi kailanman nagdadagdag ng anumang dagdag dito.
-SA. Sinyavsky
Ang mga kasanayan tungkol sa software na ginagamit ng mga administrator ng system ay maaaring mag-iba, ngunit ang mga pangkalahatang prinsipyo ay pareho pa rin, sa isang paraan o iba pa, pareho, sa partikular:
- Lubos na inirerekomenda na gumamit ng mga handa na solusyon.
- Ang mga programa ay dapat gumana nang predictably, i.e. Dapat ay walang mga hindi dokumentadong feature o bottleneck.
- Ang pag-set up ng bawat programa ay dapat na napakasimple na hindi mo kailangang basahin ang manwal o cheat sheet sa bawat oras.
- Kung maaari, ang solusyon ay dapat na unibersal, dahil Ang mga server ay maaaring mag-iba nang malaki sa kanilang mga katangian ng hardware.
Mayroong mga sumusunod na karaniwang programa para sa pagkuha ng mga backup mula sa mga block device:
- dd, pamilyar sa mga beterano ng system administration, kasama rin dito ang mga katulad na programa (halimbawa, ang parehong dd_rescue).
- Mga utility na binuo sa ilang file system na gumagawa ng dump ng file system.
- Omnivorous na mga kagamitan; halimbawa partclone.
- Sariling, kadalasang pagmamay-ari, mga desisyon; halimbawa, NortonGhost at mas bago.
Para sa mga file system, ang backup na problema ay bahagyang nalutas gamit ang mga pamamaraan na naaangkop para sa mga block device, ngunit ang problema ay mas mahusay na malulutas gamit ang, halimbawa:
- Rsync, isang pangkalahatang layunin na programa at protocol para sa pag-synchronize ng estado ng mga file system.
- Mga built-in na tool sa pag-archive (ZFS).
- Mga tool sa pag-archive ng third party; ang pinakasikat na kinatawan ay tar. Mayroong iba pa, halimbawa, dar - isang kapalit para sa tar na naglalayong sa mga modernong sistema.
Ito ay nagkakahalaga ng hiwalay na pagbanggit tungkol sa mga tool sa software para sa pagtiyak ng pagkakapare-pareho ng data kapag lumilikha ng mga backup na kopya. Ang pinakakaraniwang ginagamit na mga opsyon ay:
- Pag-mount ng file system sa read-only mode (ReadOnly), o pagyeyelo ng file system (freeze) - ang paraan ay limitado ang applicability.
- Paglikha ng mga snapshot ng estado ng mga file system o block device (LVM, ZFS).
- Ang paggamit ng mga tool ng third-party para sa pag-aayos ng mga impression, kahit na sa mga kaso kung saan ang mga nakaraang punto ay hindi maibigay sa ilang kadahilanan (mga programa tulad ng hotcopy).
- Ang copy-on-change technique (CopyOnWrite), gayunpaman, ito ay kadalasang nakatali sa file system na ginamit (BTRFS, ZFS).
Kaya, para sa isang maliit na server kailangan mong magbigay ng backup na scheme na nakakatugon sa mga sumusunod na kinakailangan:
- Madaling gamitin - walang mga espesyal na karagdagang hakbang ang kinakailangan sa panahon ng operasyon, kaunting mga hakbang upang gumawa at mag-restore ng mga kopya.
- Universal - gumagana sa parehong malaki at maliit na mga server; ito ay mahalaga kapag lumalaki ang bilang ng mga server o scaling.
- Na-install ng isang manager ng package, o sa isa o dalawang command tulad ng "i-download at i-unpack".
- Stable - ginagamit ang isang standard o matagal nang naitatag na format ng storage.
- Mabilis sa trabaho.
Ang mga aplikante mula sa mas marami o mas kaunti ay nakakatugon sa mga kinakailangan:
- rdiff-backup
- rsnapshot
- dumighay
- Kopyahin
- pagdaraya
- hayaan mo si dup
- magbigay
- zbackup
- nagpahinga
- borgbackup
Ang isang virtual machine (batay sa XenServer) na may mga sumusunod na katangian ay gagamitin bilang isang test bench:
- 4 na core 2.5 GHz,
- 16 GB ng RAM,
- 50 GB hybrid na imbakan (sistema ng imbakan na may pag-cache sa SSD 20% ng laki ng virtual na disk) sa anyo ng isang hiwalay na virtual disk nang walang partitioning,
- 200 Mbps Internet channel.
Halos parehong makina ang gagamitin bilang backup na server ng receiver, na may 500 GB na hard drive lamang.
Operating system - Centos 7 x64: standard partition, karagdagang partition ang gagamitin bilang data source.
Bilang paunang data, kumuha tayo ng isang WordPress site na may 40 GB ng mga media file at isang mysql database. Dahil malaki ang pagkakaiba ng mga virtual server sa mga katangian, at para din sa mas mahusay na muling paggawa, narito
mga resulta ng pagsubok ng server gamit ang sysbench.sysbench --threads=4 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.1.0-18a9f86 (gamit ang naka-bundle na LuaJIT 2.1.0-beta3)
Pagpapatakbo ng pagsubok sa mga sumusunod na pagpipilian:
Bilang ng mga thread: 4
Sinisimulan ang random number generator mula sa kasalukuyang oras
Limitasyon ng mga pangunahing numero: 20000
Sinisimulan ang mga thread ng manggagawa...
Nagsimula ang mga thread!
Bilis ng CPU:
mga kaganapan sa bawat segundo: 836.69
Throughput:
mga kaganapan (eps): 836.6908
lumipas ang oras: 30.0039s
kabuuang bilang ng mga kaganapan: 25104
Latency (ms):
min: 2.38
avg: 4.78
max: 22.39
Ika-95 percentile: 10.46
kabuuan: 119923.64
Threads pagiging patas:
mga kaganapan (avg/stddev): 6276.0000/13.91
oras ng pagpapatupad (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 (gamit ang naka-bundle na LuaJIT 2.1.0-beta3)
Pagpapatakbo ng pagsubok sa mga sumusunod na pagpipilian:
Bilang ng mga thread: 4
Sinisimulan ang random number generator mula sa kasalukuyang oras
Pagpapatakbo ng memory speed test na may mga sumusunod na opsyon:
laki ng bloke: 1KiB
kabuuang laki: 102400MiB
operasyon: basahin
saklaw: global
Sinisimulan ang mga thread ng manggagawa...
Nagsimula ang mga thread!
Kabuuang mga operasyon: 50900446 (1696677.10 bawat segundo)
49707.47 MiB ang inilipat (1656.91 MiB/sec)
Throughput:
mga kaganapan (eps): 1696677.1017
lumipas ang oras: 30.0001s
kabuuang bilang ng mga kaganapan: 50900446
Latency (ms):
min: 0.00
avg: 0.00
max: 24.01
Ika-95 percentile: 0.00
kabuuan: 39106.74
Threads pagiging patas:
mga kaganapan (avg/stddev): 12725111.5000/137775.15
oras ng pagpapatupad (avg/stddev): 9.7767/0.10
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=write memory run
sysbench 1.1.0-18a9f86 (gamit ang naka-bundle na LuaJIT 2.1.0-beta3)
Pagpapatakbo ng pagsubok sa mga sumusunod na pagpipilian:
Bilang ng mga thread: 4
Sinisimulan ang random number generator mula sa kasalukuyang oras
Pagpapatakbo ng memory speed test na may mga sumusunod na opsyon:
laki ng bloke: 1KiB
kabuuang laki: 102400MiB
operasyon: sumulat
saklaw: global
Sinisimulan ang mga thread ng manggagawa...
Nagsimula ang mga thread!
Kabuuang mga operasyon: 35910413 (1197008.62 bawat segundo)
35068.76 MiB ang inilipat (1168.95 MiB/sec)
Throughput:
mga kaganapan (eps): 1197008.6179
lumipas ang oras: 30.0001s
kabuuang bilang ng mga kaganapan: 35910413
Latency (ms):
min: 0.00
avg: 0.00
max: 16.90
Ika-95 percentile: 0.00
kabuuan: 43604.83
Threads pagiging patas:
mga kaganapan (avg/stddev): 8977603.2500/233905.84
oras ng pagpapatupad (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 (gamit ang naka-bundle na LuaJIT 2.1.0-beta3)
Pagpapatakbo ng pagsubok sa mga sumusunod na pagpipilian:
Bilang ng mga thread: 4
Sinisimulan ang random number generator mula sa kasalukuyang oras
Karagdagang file na bukas na mga flag: (wala)
128 file, 8MiB bawat isa
1GiB kabuuang laki ng file
Laki ng block 4KiB
Bilang ng mga kahilingan sa IO: 0
Read/Write ratio para sa pinagsamang random na IO test: 1.50
Naka-enable ang pana-panahong FSYNC, tumatawag sa fsync() bawat 100 kahilingan.
Ang pagtawag sa fsync() sa pagtatapos ng pagsubok, Pinagana.
Gamit ang synchronous I/O mode
Gumagawa ng random r/w test
Sinisimulan ang mga thread ng manggagawa...
Nagsimula ang mga thread!
Throughput:
basahin: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
sumulat: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98
Latency (ms):
min: 0.00
avg: 0.27
max: 18.01
Ika-95 percentile: 1.08
kabuuan: 238469.45
Ang tala na ito ay nagsisimula ng malaki
serye ng mga artikulo tungkol sa backup
- Backup, bahagi 1: Bakit kailangan ang backup, isang pangkalahatang-ideya ng mga pamamaraan, mga teknolohiya
- Bahagi 2 ng Backup: Pagsusuri at pagsubok ng mga tool sa pag-backup na nakabatay sa rsync
- Bahagi 3 ng Backup: Pagsusuri at pagsubok ng duplicity, duplicity, deja dup
- Bahagi 4 ng Backup: Pagsusuri at pagsubok ng zbackup, restic, borgbackup
- Backup Part 5: Pagsubok ng bacula at veeam backup para sa linux
- Backup Part 6: Paghahambing ng Backup Tools
- Backup Part 7: Mga Konklusyon
Pinagmulan: www.habr.com