Isasaalang-alang ng artikulong ito ang backup na software na, sa pamamagitan ng paghiwa-hiwalay ng stream ng data sa magkakahiwalay na bahagi (mga tipak), ay bumubuo ng isang repositoryo.
Ang mga bahagi ng repository ay maaaring higit pang i-compress at i-encrypt, at higit sa lahat - sa paulit-ulit na proseso ng pag-backup - muling magamit.
Ang isang backup na kopya sa naturang repository ay isang pinangalanang chain ng mga bahagi na konektado sa isa't isa, halimbawa, batay sa iba't ibang hash function.
Mayroong ilang mga katulad na solusyon, magtutuon ako sa 3: zbackup, borgbackup at restic.
Inaasahang Resulta
Dahil ang lahat ng mga aplikante ay nangangailangan ng paglikha ng isang imbakan sa isang paraan o iba pa, ang isa sa pinakamahalagang salik ay ang pagtatantya ng laki ng imbakan. Sa isip, ang laki nito ay dapat na hindi hihigit sa 13 GB ayon sa tinatanggap na pamamaraan, o mas kaunti pa - napapailalim sa mahusay na pag-optimize.
Lubhang kanais-nais din na makagawa ng mga backup na kopya ng mga file nang direkta, nang hindi gumagamit ng mga archiver tulad ng tar, pati na rin magtrabaho sa ssh/sftp nang walang karagdagang mga tool tulad ng rsync at sshfs.
Pag-uugali kapag gumagawa ng mga backup:
- Ang laki ng repository ay magiging katumbas ng laki ng mga pagbabago, o mas kaunti.
- Inaasahan ang mabigat na pag-load ng CPU kapag gumagamit ng compression at/o encryption, at malamang na mataas ang network at disk load kung tumatakbo ang proseso ng pag-archive at/o pag-encrypt sa isang backup na storage server.
- Kung nasira ang repository, malamang na may naantalang error sa paggawa ng mga bagong backup at kapag sinusubukang i-restore. Kinakailangang magplano ng mga karagdagang hakbang upang matiyak ang integridad ng repositoryo o gumamit ng mga built-in na tool para sa pagsuri sa integridad nito.
Ang pagtatrabaho sa tar ay kinuha bilang isang reference na halaga, tulad ng ipinakita sa isa sa mga nakaraang artikulo.
Sinusubukan ang zbackup
Ang pangkalahatang mekanismo ng zbackup ay ang programa ay nahahanap sa input data stream na mga lugar na naglalaman ng parehong data, pagkatapos ay opsyonal na i-compress at i-encrypt ang mga ito, na nagse-save sa bawat lugar nang isang beses lamang.
Gumagamit ang deduplication ng 64-bit ring hash function na may sliding window para tingnan kung may mga byte-by-byte na tugma laban sa mga umiiral nang data block (katulad ng kung paano ito ipinapatupad ng rsync).
Ang multi-threaded lzma at lzo ay ginagamit para sa compression, at aes para sa encryption. Ang mga pinakabagong bersyon ay may kakayahang magtanggal ng lumang data mula sa repositoryo sa hinaharap.
Ang programa ay nakasulat sa C++ na may kaunting dependencies. Ang may-akda ay tila inspirasyon ng unix-way, kaya ang programa ay tumatanggap ng data sa stdin kapag lumilikha ng mga backup, na gumagawa ng katulad na stream ng data sa stdout kapag nire-restore. Kaya, ang zbackup ay maaaring gamitin bilang isang napakahusay na "building block" kapag nagsusulat ng sarili mong mga backup na solusyon. Halimbawa, ginamit ng may-akda ng artikulo ang program na ito bilang pangunahing backup tool para sa mga home machine mula noong humigit-kumulang 2014.
Ang stream ng data ay magiging isang regular na tar maliban kung iba ang nakasaad.
Tingnan natin kung ano ang mga resulta:
Ang trabaho ay nasuri sa 2 mga pagpipilian:
- isang imbakan ay nilikha at ang zbackup ay inilunsad sa server na may pinagmumulan ng data, pagkatapos ang mga nilalaman ng imbakan ay ililipat sa backup na imbakan ng server.
- ang isang imbakan ay nilikha sa backup na imbakan ng server, ang zbackup ay inilunsad sa pamamagitan ng ssh sa backup na imbakan ng server, at ang data ay ipinadala dito sa pamamagitan ng pipe.
Ang mga resulta ng unang opsyon ay ang mga sumusunod: 43m11s - kapag gumagamit ng hindi naka-encrypt na repository at ang lzma compressor, 19m13s - kapag pinapalitan ang compressor ng lzo.
Ang pag-load sa server na may orihinal na data ay ang mga sumusunod (isang halimbawa na may lzma ay ipinapakita; sa lzo mayroong humigit-kumulang na parehong larawan, ngunit ang bahagi ng rsync ay humigit-kumulang isang-kapat ng oras):
Malinaw na ang ganitong proseso ng pag-backup ay angkop lamang para sa medyo bihira at maliliit na pagbabago. Lubos ding ipinapayong limitahan ang zbackup sa 1 thread, kung hindi, magkakaroon ng napakataas na load ng CPU, dahil Ang programa ay napakahusay sa pagtatrabaho sa maraming mga thread. Ang pag-load sa disk ay maliit, na sa pangkalahatan ay hindi mapapansin sa isang modernong ssd-based disk subsystem. Malinaw mo ring makikita ang simula ng proseso ng pag-synchronize ng data ng repository sa isang malayuang server; ang bilis ng operasyon ay maihahambing sa regular na rsync at depende sa pagganap ng disk subsystem ng backup na server ng imbakan. Ang kawalan ng diskarte na ito ay ang pag-iimbak ng isang lokal na imbakan at, bilang isang resulta, pagdoble ng data.
Ang mas kawili-wili at naaangkop sa pagsasanay ay ang pangalawang opsyon, ang pagpapatakbo ng zbackup nang direkta sa backup na storage server.
Una, susubukan namin ang operasyon nang hindi gumagamit ng pag-encrypt gamit ang lzma compressor:
Oras ng pagtakbo ng bawat pagsubok na pagtakbo:
Ilunsad 1
Ilunsad 2
Ilunsad 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Kung pinagana mo ang pag-encrypt gamit ang aes, ang mga resulta ay medyo malapit:
Oras ng pagpapatakbo sa parehong data, na may pag-encrypt:
Ilunsad 1
Ilunsad 2
Ilunsad 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Kung ang pag-encrypt ay pinagsama sa compression gamit ang lzo, ganito ang hitsura:
Mga Oras:
Ilunsad 1
Ilunsad 2
Ilunsad 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Ang laki ng nagresultang repository ay medyo pareho sa 13GB. Nangangahulugan ito na gumagana nang tama ang deduplication. Gayundin, sa naka-compress na data, ang paggamit ng lzo ay nagbibigay ng isang kapansin-pansing epekto; sa mga tuntunin ng kabuuang oras ng pagpapatakbo, ang zbackup ay malapit sa duplicity/duplicati, ngunit nahuhuli sa mga batay sa librsync ng 2-5 beses.
Ang mga pakinabang ay halata - nagse-save ng puwang sa disk sa backup na storage server. Tulad ng para sa mga tool sa pag-check ng repository, hindi ito ibinibigay ng may-akda ng zbackup; inirerekomendang gumamit ng fault-tolerant disk array o cloud provider.
Sa pangkalahatan, isang napakagandang impression, sa kabila ng katotohanan na ang proyekto ay nakatayo nang humigit-kumulang 3 taon (ang huling kahilingan sa tampok ay halos isang taon na ang nakalipas, ngunit walang tugon).
Sinusuri ang borgbackup
Ang Borgbackup ay isang tinidor ng attic, isa pang sistema na katulad ng zbackup. Nakasulat sa python, mayroon itong listahan ng mga kakayahan na katulad ng zbackup, ngunit maaari ding:
- I-mount ang mga backup sa pamamagitan ng fuse
- Suriin ang mga nilalaman ng imbakan
- Magtrabaho sa client-server mode
- Gumamit ng iba't ibang mga compressor para sa data, pati na rin ang heuristic na pagtukoy ng uri ng file kapag kino-compress ito.
- 2 opsyon sa pag-encrypt, aes at blake
- Built-in na tool para sa
mga pagsusuri sa pagganap
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Ang mga resulta ay ang mga sumusunod:
C-Z-BIG 96.51 MB/s (10 100.00 MB all-zero na mga file: 10.36s)
R-Z-BIG 57.22 MB/s (10 100.00 MB all-zero na mga file: 17.48s)
U-Z-BIG 253.63 MB/s (10 100.00 MB all-zero na mga file: 3.94s)
D-Z-BIG 351.06 MB/s (10 100.00 MB all-zero na mga file: 2.85s)
C-R-BIG 34.30 MB/s (10 100.00 MB na mga random na file: 29.15s)
R-R-BIG 60.69 MB/s (10 100.00 MB na mga random na file: 16.48s)
U-R-BIG 311.06 MB/s (10 100.00 MB na mga random na file: 3.21s)
D-R-BIG 72.63 MB/s (10 100.00 MB na mga random na file: 13.77s)
C-Z-MEDIUM 108.59 MB/s (1000 1.00 MB all-zero na mga file: 9.21s)
R-Z-MEDIUM 76.16 MB/s (1000 1.00 MB all-zero na mga file: 13.13s)
U-Z-MEDIUM 331.27 MB/s (1000 1.00 MB all-zero na mga file: 3.02s)
D-Z-MEDIUM 387.36 MB/s (1000 1.00 MB all-zero na mga file: 2.58s)
C-R-MEDIUM 37.80 MB/s (1000 1.00 MB na mga random na file: 26.45s)
R-R-MEDIUM 68.90 MB/s (1000 1.00 MB na mga random na file: 14.51s)
U-R-MEDIUM 347.24 MB/s (1000 1.00 MB na mga random na file: 2.88s)
D-R-MEDIUM 48.80 MB/s (1000 1.00 MB na mga random na file: 20.49s)
C-Z-SMALL 11.72 MB/s (10000 10.00 kB all-zero na mga file: 8.53s)
R-Z-SMALL 32.57 MB/s (10000 10.00 kB all-zero na mga file: 3.07s)
U-Z-SMALL 19.37 MB/s (10000 10.00 kB all-zero na mga file: 5.16s)
D-Z-SMALL 33.71 MB/s (10000 10.00 kB all-zero na mga file: 2.97s)
C-R-SMALL 6.85 MB/s (10000 10.00 kB random na mga file: 14.60s)
R-R-SMALL 31.27 MB/s (10000 10.00 kB random na mga file: 3.20s)
U-R-SMALL 12.28 MB/s (10000 10.00 kB random na mga file: 8.14s)
D-R-SMALL 18.78 MB/s (10000 10.00 kB random na mga file: 5.32s)
Kapag sinusubukan, ang compression heuristics ay gagamitin upang matukoy ang uri ng file (compression auto), at ang mga resulta ay ang mga sumusunod:
Una, suriin natin kung paano ito gumagana nang walang pag-encrypt:
Mga Oras:
Ilunsad 1
Ilunsad 2
Ilunsad 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Kung pinagana mo ang awtorisasyon sa repositoryo (authenticated mode), ang mga resulta ay malapit na:
Mga Oras:
Ilunsad 1
Ilunsad 2
Ilunsad 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Kapag ang aes encryption ay na-activate, ang mga resulta ay hindi masyadong lumala:
Ilunsad 1
Ilunsad 2
Ilunsad 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
At kung babaguhin mo ang aes sa blake, ganap na gaganda ang sitwasyon:
Mga Oras:
Ilunsad 1
Ilunsad 2
Ilunsad 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Tulad ng kaso ng zbackup, ang laki ng repository ay 13GB at mas kaunti pa, na karaniwang inaasahan. Tuwang-tuwa ako sa oras ng pagtakbo; ito ay maihahambing sa mga solusyon batay sa librsync, na nagbibigay ng mas malawak na kakayahan. Nasisiyahan din ako sa kakayahang magtakda ng iba't ibang mga parameter sa pamamagitan ng mga variable ng kapaligiran, na nagbibigay ng napakaseryosong kalamangan kapag gumagamit ng borgbackup sa awtomatikong mode. Nasisiyahan din ako sa pag-load sa panahon ng pag-backup: ayon sa pag-load ng processor, gumagana ang borgbackup sa 1 thread.
Walang mga partikular na disadvantages kapag ginagamit ito.
restic testing
Sa kabila ng katotohanan na ang restic ay isang medyo bagong solusyon (ang unang 2 kandidato ay kilala noong 2013 at mas matanda), mayroon itong magandang katangian. Nakasulat sa Go.
Kung ihahambing sa zbackup, nagbibigay din ito ng:
- Sinusuri ang integridad ng repositoryo (kabilang ang pagsuri sa mga bahagi).
- Isang malaking listahan ng mga sinusuportahang protocol at provider para sa pag-iimbak ng mga backup, pati na rin ang suporta para sa rclone - rsync para sa mga solusyon sa ulap.
- Paghahambing ng 2 backup sa bawat isa.
- Pag-mount ng repositoryo sa pamamagitan ng fuse.
Sa pangkalahatan, ang listahan ng mga feature ay medyo malapit sa borgbackup, sa ilang lugar ay mas marami, sa iba ay mas mababa. Ang isa sa mga tampok ay walang paraan upang hindi paganahin ang pag-encrypt, at samakatuwid ang mga backup na kopya ay palaging naka-encrypt. Tingnan natin sa pagsasanay kung ano ang maaaring maipit sa software na ito:
Ang mga resulta ay ang mga sumusunod:
Mga Oras:
Ilunsad 1
Ilunsad 2
Ilunsad 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Ang mga resulta ng pagganap ay maihahambing din sa mga solusyon na nakabatay sa rsync at, sa pangkalahatan, napakalapit sa borgbackup, ngunit ang pag-load ng CPU ay mas mataas (maramihang mga thread na tumatakbo) at sawtooth.
Malamang, ang programa ay limitado sa pamamagitan ng pagganap ng disk subsystem sa data storage server, tulad ng dati nang nangyari sa rsync. Ang laki ng repository ay 13GB, tulad ng zbackup o borgbackup, walang malinaw na disadvantages kapag ginagamit ang solusyon na ito.
Natuklasan
Sa katunayan, nakamit ng lahat ng kandidato ang magkatulad na resulta, ngunit sa magkaibang presyo. Pinakamahusay na gumanap ang Borgbackup sa lahat, medyo mas mabagal ang restic, malamang na hindi sulit na simulan ang zbackup,
at kung ito ay ginagamit na, subukang baguhin ito sa borgbackup o restic.
Natuklasan
Ang pinaka-maaasahan na solusyon ay tila hindi mapakali, dahil... siya ang may pinakamahusay na ratio ng mga kakayahan sa bilis ng pagpapatakbo, ngunit huwag magmadali sa mga pangkalahatang konklusyon sa ngayon.
Ang Borgbackup ay karaniwang hindi mas masahol pa, ngunit ang zbackup ay malamang na mas mahusay na palitan. Totoo, magagamit pa rin ang zbackup para matiyak na gumagana ang panuntunang 3-2-1. Halimbawa, bilang karagdagan sa (lib)rsync-based na backup na mga pasilidad.
Anunsyo
Backup Part 5: Pagsubok ng bacula at veeam backup para sa linux
Backup Part 6: Paghahambing ng Backup Tools
Backup Part 7: Mga Konklusyon
Nai-post ni: Pavel Demkovich
Pinagmulan: www.habr.com