Ang artikulong ito ay maghahambing ng mga tool sa pag-backup, ngunit dapat mo munang malaman kung gaano kabilis at mahusay ang mga ito sa pagpapanumbalik ng data mula sa mga backup.
Para sa kadalian ng paghahambing, isasaalang-alang namin ang pagpapanumbalik mula sa isang buong backup, lalo na dahil sinusuportahan ng lahat ng kandidato ang mode na ito ng operasyon. Para sa pagiging simple, ang mga numero ay na-average na (ang arithmetic mean ng ilang run). Ang mga resulta ay ibubuod sa isang talahanayan, na naglalaman din ng impormasyon tungkol sa mga kakayahan: ang pagkakaroon ng isang web interface, kadalian ng pag-setup at pagpapatakbo, ang kakayahang mag-automate, ang pagkakaroon ng iba't ibang mga karagdagang tampok (halimbawa, pagsuri sa integridad ng data) , atbp. Ipapakita ng mga graph ang pagkarga sa server kung saan gagamitin ang data (hindi ang server para sa pag-iimbak ng mga backup na kopya).
Pagbawi ng data
rsync at tar ay gagamitin bilang isang reference point mula noon mga simpleng script para sa paggawa ng mga backup na kopya.
Rsync nakayanan ang set ng data ng pagsubok sa loob ng 4 na minuto at 28 segundo, na nagpapakita
ganyang load
Ang proseso ng pagbawi ay tumama sa limitasyon ng disk subsystem ng backup na storage server (sawtooth graphs). Maaari mo ring malinaw na makita ang paglo-load ng isang kernel nang walang anumang mga problema (mababa ang iowait at softirq - walang mga problema sa disk at network, ayon sa pagkakabanggit). Dahil ang iba pang dalawang programa, katulad ng rdiff-backup at rsnapshot, ay nakabatay sa rsync at nag-aalok din ng regular na rsync bilang tool sa pagbawi, magkakaroon sila ng humigit-kumulang sa parehong load profile at backup recovery time.
Tar naisagawa ito nang mas mabilis
2 minuto at 43 segundo:
Ang kabuuang load ng system ay mas mataas sa average ng 20% ββdahil sa tumaas na softirq - ang mga gastos sa overhead sa panahon ng pagpapatakbo ng network subsystem ay tumaas.
Kung ang archive ay mas na-compress, ang oras ng pagbawi ay tataas sa 3 minuto 19 segundo.
na may ganitong pagkarga sa pangunahing server (pag-unpack sa gilid ng pangunahing server):
Ang proseso ng decompression ay tumatagal ng parehong mga core ng processor dahil mayroong dalawang proseso na tumatakbo. Sa pangkalahatan, ito ang inaasahang resulta. Gayundin, ang isang maihahambing na resulta (3 minuto at 20 segundo) ay nakuha kapag nagpapatakbo ng gzip sa gilid ng server na may mga backup; ang profile ng pag-load sa pangunahing server ay halos kapareho sa pagpapatakbo ng tar nang walang gzip compressor (tingnan ang nakaraang graph).
Π rdiff-backup maaari mong i-synchronize ang huling backup na ginawa mo gamit ang regular na rsync (magkakatulad ang mga resulta), ngunit kailangan pa ring i-restore ang mga lumang backup gamit ang rdiff-backup program, na nakumpleto ang restoration sa loob ng 17 minuto at 17 segundo, na nagpapakita
ang load na ito:
Marahil ito ay inilaan, hindi bababa sa upang limitahan ang bilis ng mga may-akda . Ang proseso ng pagpapanumbalik ng isang backup na kopya mismo ay tumatagal ng kaunti sa kalahati ng isang core, na may proporsyonal na maihahambing na pagganap (ibig sabihin, 2-5 beses na mas mabagal) sa disk at network na may rsync.
Rsnapshot Para sa pagbawi, iminumungkahi nito ang paggamit ng regular na rsync, kaya ang mga resulta nito ay magiging katulad. Sa pangkalahatan, ganito ang nangyari.
Basura Nakumpleto ko ang gawain ng pagpapanumbalik ng backup sa loob ng 7 minuto at 2 segundo gamit ang
kasama ang load na ito:
Mabilis itong gumana, at hindi bababa sa mas maginhawa kaysa sa purong rsync: hindi mo kailangang matandaan ang anumang mga flag, isang simple at intuitive na cli interface, built-in na suporta para sa maraming kopya - kahit na ito ay dalawang beses na mas mabagal. Kung kailangan mong ibalik ang data mula sa huling backup na ginawa mo, maaari mong gamitin ang rsync, na may ilang mga caveat.
Ang programa ay nagpakita ng humigit-kumulang sa parehong bilis at pagkarga BackupPC kapag pinapagana ang rsync transfer mode, i-deploy ang backup para sa
7 minuto at 42 segundo:
Ngunit sa data transfer mode, ang BackupPC ay nakayanan ang tar nang mas mabagal: sa loob ng 12 minuto at 15 segundo, ang pagkarga ng processor ay karaniwang mas mababa.
isa't kalahating beses:
Panlilinlang nang walang pag-encrypt ay nagpakita ng bahagyang mas mahusay na mga resulta, na nagpapanumbalik ng backup sa loob ng 10 minuto at 58 segundo. Kung i-activate mo ang pag-encrypt gamit ang gpg, tataas ang oras ng pagbawi sa 15 minuto at 3 segundo. Gayundin, kapag gumagawa ng repository para sa pag-iimbak ng mga kopya, maaari mong tukuyin ang laki ng archive na gagamitin kapag hinahati ang papasok na stream ng data. Sa pangkalahatan, sa maginoo na hard drive, dahil din sa single-threaded operating mode, walang gaanong pagkakaiba. Maaaring lumitaw ito sa iba't ibang laki ng block kapag ginamit ang hybrid na storage. Ang pag-load sa pangunahing server sa panahon ng pagbawi ay ang mga sumusunod:
walang encryption
may encryption
Kopyahin nagpakita ng maihahambing na rate ng pagbawi, na nakumpleto ito sa loob ng 13 minuto at 45 segundo. Tumagal ng humigit-kumulang 5 minuto upang suriin ang kawastuhan ng na-recover na data (kabuuan ng mga 19 minuto). Ang load noon
medyo mataas:
Kapag internal na pinagana ang aes encryption, ang oras ng pagbawi ay 21 minuto 40 segundo, na may pinakamataas na paggamit ng CPU (parehong mga core!) sa panahon ng pagbawi; Kapag sinusuri ang data, isang thread lamang ang aktibo, na sumasakop sa isang core ng processor. Ang pagsuri sa data pagkatapos ng pagbawi ay tumagal ng parehong 5 minuto (halos 27 minuto sa kabuuan).
Resulta
duplicati ay medyo mas mabilis sa pagbawi kapag gumagamit ng panlabas na gpg program para sa pag-encrypt, ngunit sa pangkalahatan ang mga pagkakaiba mula sa nakaraang mode ay minimal. Ang oras ng pagpapatakbo ay 16 minuto 30 segundo, na may pag-verify ng data sa loob ng 6 na minuto. Ang load noon
ganito:
Amanda, gamit ang tar, nakumpleto ito sa loob ng 2 minuto 49 segundo, na, sa prinsipyo, ay napakalapit sa regular na tar. Mag-load sa system sa prinsipyo
pareho:
Kapag nagpapanumbalik ng backup gamit ang zbackup ang mga sumusunod na resulta ay nakuha:
pag-encrypt, lzma compression
Oras ng pagtakbo 11 minuto at 8 segundo
AES encryption, lzma compression
Oras ng pagpapatakbo 14 minuto
AES encryption, lzo compression
Oras ng pagtakbo 6 minuto, 19 segundo
Sa pangkalahatan, hindi masama. Ang lahat ay nakasalalay sa bilis ng processor sa backup server, na malinaw na makikita mula sa oras ng pagpapatakbo ng programa na may iba't ibang mga compressor. Sa panig ng backup na server, isang regular na tar ang inilunsad, kaya kung ihahambing mo ito dito, ang pagbawi ay 3 beses na mas mabagal. Maaaring sulit na suriin ang operasyon sa multi-threaded mode, na may higit sa dalawang thread.
BorgBackup sa hindi naka-encrypt na mode ito ay medyo mas mabagal kaysa sa tar, sa loob ng 2 minuto 45 segundo, gayunpaman, hindi tulad ng tar, naging posible na i-deduplicate ang repositoryo. Ang load pala
ang mga sumusunod:
Kung pinagana mo ang pag-encrypt na nakabatay sa blake, ang bilis ng backup na pagbawi ay bahagyang mas mabagal. Ang oras ng pagbawi sa mode na ito ay 3 minuto 19 segundo, at nawala ang pagkarga
ganito:
Ang pag-encrypt ng AES ay bahagyang mas mabagal, ang oras ng pagbawi ay 3 minuto 23 segundo, lalo na ang pagkarga
ay hindi nagbago:
Dahil ang Borg ay maaaring gumana sa multi-threaded mode, ang pag-load ng processor ay maximum, at kapag ang mga karagdagang function ay isinaaktibo, ang oras ng pagpapatakbo ay tataas lamang. Tila, ito ay nagkakahalaga ng paggalugad ng multithreading sa katulad na paraan sa zbackup.
Nagpahinga nakayanan ang pagbawi nang medyo mas mabagal, ang oras ng pagpapatakbo ay 4 minuto 28 segundo. Parang ang load
ganito:
Tila ang proseso ng pagbawi ay gumagana sa ilang mga thread, ngunit ang kahusayan ay hindi kasing taas ng BorgBackup, ngunit maihahambing sa oras sa regular na rsync.
May urBackup Posibleng ibalik ang data sa loob ng 8 minuto at 19 segundo, ang pag-load ay
ganito:
Hindi pa rin masyadong mataas ang load, mas mababa pa sa tar. Sa ilang mga lugar ay may mga pagsabog, ngunit hindi hihigit sa pagkarga ng isang core.
Pagpili at pagbibigay-katwiran ng pamantayan para sa paghahambing
Gaya ng nakasaad sa isa sa mga nakaraang artikulo, ang backup system ay dapat matugunan ang mga sumusunod na pamantayan:
- Dali ng paggamit
- masaklaw na karunungan
- Katatagan
- Kabilisan
Ito ay nagkakahalaga ng pagsasaalang-alang sa bawat punto nang hiwalay nang mas detalyado.
Dali ng operasyon
Pinakamainam kapag mayroong isang pindutan na "Gawin nang maayos ang lahat," ngunit kung babalik ka sa mga tunay na programa, ang pinaka-maginhawang bagay ay ang ilang pamilyar at karaniwang prinsipyo ng pagpapatakbo.
Karamihan sa mga user ay malamang na mas mahusay kung hindi nila kailangang matandaan ang isang bungkos ng mga key para sa cli, i-configure ang isang grupo ng iba't ibang, kadalasang nakakubli na mga opsyon sa pamamagitan ng web o tui, o mag-set up ng mga notification tungkol sa hindi matagumpay na operasyon. Kasama rin dito ang kakayahang madaling "magkasya" ng backup na solusyon sa umiiral na imprastraktura, pati na rin ang automation ng proseso ng pag-backup. Mayroon ding posibilidad ng pag-install gamit ang isang manager ng package, o sa isa o dalawang utos tulad ng "i-download at i-unpack". curl ΡΡΡΠ»ΠΊΠ° | sudo bash - isang kumplikadong pamamaraan, dahil kailangan mong suriin kung ano ang dumating sa pamamagitan ng link.
Halimbawa, sa mga kandidatong isinasaalang-alang, ang isang simpleng solusyon ay burp, rdiff-backup at restic, na may mga mnemonic key para sa iba't ibang operating mode. Bahagyang mas kumplikado ang borg at duplicity. Ang pinakamahirap ay si AMANDA. Ang natitira ay nasa isang lugar sa gitna sa mga tuntunin ng kadalian ng paggamit. Sa anumang kaso, kung kailangan mo ng higit sa 30 segundo upang basahin ang manwal ng gumagamit, o kailangan mong pumunta sa Google o isa pang search engine, at mag-scroll din sa isang mahabang sheet ng tulong, ang desisyon ay mahirap, isang paraan o iba pa.
Ang ilan sa mga kandidatong isinasaalang-alang ay maaaring awtomatikong magpadala ng mensahe sa pamamagitan ng e-mailjabber, habang ang iba ay umaasa sa mga naka-configure na alerto sa system. Bukod dito, kadalasan ang mga kumplikadong solusyon ay walang ganap na halatang mga setting ng alerto. Sa anumang kaso, kung ang backup na programa ay gumagawa ng isang non-zero return code, na mauunawaan nang tama ng serbisyo ng system para sa mga pana-panahong gawain (isang mensahe ay ipapadala sa administrator ng system o direkta sa pagsubaybay) - ang sitwasyon ay simple. Ngunit kung ang backup system, na hindi tumatakbo sa isang backup na server, ay hindi mai-configure, ang malinaw na paraan upang sabihin ang tungkol sa problema ay ang pagiging kumplikado ay sobra-sobra na. Sa anumang kaso, ang pagbibigay ng mga babala at iba pang mga mensahe lamang sa web interface o sa log ay isang masamang kasanayan, dahil kadalasan ay hindi papansinin ang mga ito.
Tulad ng para sa automation, maaaring basahin ng isang simpleng programa ang mga variable ng kapaligiran na nagtatakda ng operating mode nito, o mayroon itong binuo na cli na maaaring ganap na ma-duplicate ang pag-uugali kapag nagtatrabaho sa pamamagitan ng isang web interface, halimbawa. Kasama rin dito ang posibilidad ng tuluy-tuloy na operasyon, ang pagkakaroon ng mga pagkakataon sa pagpapalawak, atbp.
masaklaw na karunungan
Bahagyang umaalingawngaw sa nakaraang subsection tungkol sa automation, hindi dapat maging partikular na problema ang "magkasya" sa proseso ng backup sa umiiral na imprastraktura.
Kapansin-pansin na ang paggamit ng mga hindi pamantayang port (mabuti, maliban sa web interface) para sa trabaho, ang pagpapatupad ng pag-encrypt sa isang hindi karaniwang paraan, ang pagpapalitan ng data gamit ang isang hindi pamantayang protocol ay mga palatandaan ng isang hindi -pangkalahatang solusyon. Para sa karamihan, ang lahat ng mga kandidato ay mayroon ng mga ito sa isang paraan o iba pa para sa maliwanag na dahilan: ang pagiging simple at kagalingan ay karaniwang hindi nagsasama. Bilang isang pagbubukod - burp, may iba pa.
Bilang tanda - ang kakayahang magtrabaho gamit ang regular na ssh.
Ang bilis ng trabaho
Ang pinakakontrobersyal at kontrobersyal na punto. Sa isang banda, inilunsad namin ang proseso, gumana ito nang mabilis hangga't maaari at hindi nakagambala sa mga pangunahing gawain. Sa kabilang banda, may surge sa trapiko at pag-load ng processor sa panahon ng backup. Kapansin-pansin din na ang pinakamabilis na programa para sa paggawa ng mga kopya ay karaniwang pinakamahirap sa mga tuntunin ng mga pag-andar na mahalaga sa mga gumagamit. Muli: kung upang makakuha ng isang kapus-palad na text file ng ilang sampu-sampung byte ang laki na may isang password, at dahil dito ang buong gastos ng serbisyo (oo, oo, naiintindihan ko na ang proseso ng pag-backup ay kadalasang hindi dapat sisihin dito), at kailangan mong muling basahin nang sunud-sunod ang lahat ng mga file sa repositoryo o palawakin ang buong archive - ang backup system ay hindi kailanman mabilis. Ang isa pang punto na madalas na nagiging hadlang ay ang bilis ng pag-deploy ng backup mula sa isang archive. Mayroong isang malinaw na kalamangan dito para sa mga maaaring kopyahin o ilipat ang mga file sa nais na lokasyon nang walang labis na pagmamanipula (rsync, halimbawa), ngunit kadalasan ang problema ay dapat na malutas sa isang organisasyonal na paraan, sa empirically: sa pamamagitan ng pagsukat ng backup na oras ng pagbawi at lantarang nagpapaalam sa mga user tungkol dito.
Katatagan
Dapat itong maunawaan sa ganitong paraan: sa isang banda, dapat na posible na i-deploy ang backup na kopya pabalik sa anumang paraan, sa kabilang banda, dapat itong lumalaban sa iba't ibang mga problema: pagkagambala sa network, pagkabigo sa disk, pagtanggal ng bahagi ng imbakan.
Paghahambing ng mga backup na tool
Kopyahin ang oras ng paglikha
Kopyahin ang oras ng pagbawi
Madaling pagkabit
Madaling pag-setup
Simpleng paggamit
Simpleng automation
Kailangan mo ba ng client server?
Sinusuri ang integridad ng repositoryo
Differential na mga kopya
Nagtatrabaho sa pamamagitan ng pipe
masaklaw na karunungan
Kalayaan
Transparency ng repositoryo
Pag-encrypt
Compression
Deduplikasyon
Web interface
Pagpuno sa ulap
Suporta sa Windows
Kalidad
Rsync
4m15s
4m28s
oo
hindi
hindi
hindi
oo
hindi
hindi
oo
hindi
oo
oo
hindi
hindi
hindi
hindi
hindi
oo
6
Tar
dalisay
3m12s
2m43s
oo
hindi
hindi
hindi
hindi
hindi
oo
oo
hindi
oo
hindi
hindi
hindi
hindi
hindi
hindi
oo
8,5
gzip
9m37s
3m19s
oo
Rdiff-backup
16m26s
17m17s
oo
oo
oo
oo
oo
hindi
oo
hindi
oo
hindi
oo
hindi
oo
oo
oo
hindi
oo
11
Rsnapshot
4m19s
4m28s
oo
oo
oo
oo
hindi
hindi
oo
hindi
oo
hindi
oo
hindi
hindi
oo
oo
hindi
oo
12,5
Basura
11m9s
7m2s
oo
hindi
oo
oo
oo
oo
oo
hindi
oo
oo
hindi
hindi
oo
hindi
oo
hindi
oo
10,5
Panlilinlang
walang encryption
16m48s
10m58s
oo
oo
hindi
oo
hindi
oo
oo
hindi
hindi
oo
hindi
oo
oo
hindi
oo
hindi
oo
11
gpg
17m27s
15m3s
Kopyahin
walang encryption
20m28s
13m45s
hindi
oo
hindi
hindi
hindi
oo
oo
hindi
hindi
oo
hindi
oo
oo
oo
oo
oo
oo
11
aes
29m41s
21m40s
gpg
26m19s
16m30s
zbackup
walang encryption
40m3s
11m8s
oo
oo
hindi
hindi
hindi
oo
oo
oo
hindi
oo
hindi
oo
oo
oo
hindi
hindi
hindi
10
aes
42m0s
14m1s
aes+lzo
18m9s
6m19s
BorgBackup
walang encryption
4m7s
2m45s
oo
oo
oo
oo
oo
oo
oo
oo
oo
oo
hindi
oo
oo
oo
oo
hindi
oo
16
aes
4m58s
3m23s
blake2
4m39s
3m19s
Nagpahinga
5m38s
4m28s
oo
oo
oo
oo
hindi
oo
oo
oo
oo
oo
hindi
oo
hindi
oo
hindi
oo
oo
15,5
urBackup
8m21s
8m19s
oo
oo
oo
hindi
oo
hindi
oo
hindi
oo
oo
hindi
oo
oo
oo
oo
hindi
oo
12
Amanda
9m3s
2m49s
oo
hindi
hindi
oo
oo
oo
oo
hindi
oo
oo
oo
oo
oo
hindi
oo
oo
oo
13
BackupPC
rsync
12m22s
7m42s
oo
hindi
oo
oo
oo
oo
oo
hindi
oo
hindi
hindi
oo
oo
hindi
oo
hindi
oo
10,5
alkitran
12m34s
12m15s
Alamat ng talahanayan:
- Berde, oras ng pagpapatakbo na wala pang limang minuto, o sagutin ang "Oo" (maliban sa column na "Need a client server?"), 1 point
- Dilaw, oras ng pagpapatakbo ng lima hanggang sampung minuto, 0.5 puntos
- Pula, ang oras ng trabaho ay higit sa sampung minuto, o ang sagot ay "Hindi" (maliban sa column na "Kailangan mo ba ng client server?"), 0 puntos
Ayon sa talahanayan sa itaas, ang pinakasimple, pinakamabilis, at sa parehong oras na maginhawa at makapangyarihang backup na tool ay BorgBackup. Nakuha ni Restic ang pangalawang puwesto, ang natitira sa mga itinuturing na kandidato ay inilagay nang humigit-kumulang pantay na may spread na isa o dalawang puntos sa dulo.
Nagpapasalamat ako sa lahat ng nagbabasa ng serye hanggang sa dulo, inaanyayahan ko kayong talakayin ang mga opsyon at mag-alok ng sarili mo, kung mayroon man. Habang nagpapatuloy ang talakayan, maaaring palawakin ang talahanayan.
Ang resulta ng serye ay ang pangwakas na artikulo, kung saan magkakaroon ng pagtatangka na bumuo ng isang perpekto, mabilis at mapapamahalaang backup na tool na nagbibigay-daan sa iyong mag-deploy ng isang kopya pabalik sa pinakamaikling posibleng oras at sa parehong oras ay maginhawa at madali. upang i-configure at mapanatili.
Anunsyo
Backup Part 6: Paghahambing ng Backup Tools
Backup Part 7: Mga Konklusyon
Pinagmulan: www.habr.com