Tinatalakay ng tala na ito ang mga backup na tool na nagsasagawa ng mga backup sa pamamagitan ng paglikha ng mga archive sa isang backup na server.
Kabilang sa mga nakakatugon sa mga kinakailangan ay ang duplicity (na may magandang interface sa anyo ng deja dup) at duplicati.
Ang isa pang kapansin-pansing backup tool ay dar, ngunit dahil mayroon itong napakalawak na listahan ng mga opsyon - ang pamamaraan ng pagsubok ay sumasaklaw sa halos 10% ng kung ano ang kaya nito - hindi namin ito sinusubukan bilang bahagi ng kasalukuyang cycle.
Inaasahang Resulta
Dahil ang parehong mga kandidato ay gumagawa ng mga archive sa isang paraan o iba pa, ang regular na tar ay maaaring gamitin bilang gabay.
Bilang karagdagan, susuriin namin kung gaano kahusay ang pag-iimbak ng data sa storage server sa pamamagitan ng paglikha ng mga backup na kopya na naglalaman lamang ng pagkakaiba sa pagitan ng isang buong kopya at ang kasalukuyang estado ng mga file, o sa pagitan ng dati at kasalukuyang mga archive (incremental, decremental, atbp.) .
Pag-uugali kapag gumagawa ng mga backup:
- Ang isang medyo maliit na bilang ng mga file sa backup na server ng imbakan (maihahambing sa bilang ng mga backup na kopya o ang laki ng data sa GB), ngunit ang kanilang laki ay medyo malaki (sampu hanggang daan-daang megabytes).
- Ang laki ng imbakan ay magsasama lamang ng mga pagbabago - walang mga duplicate na maiimbak, kaya ang laki ng imbakan ay magiging mas maliit kaysa sa rsync-based na software.
- Asahan ang mabigat na pag-load ng CPU kapag gumagamit ng compression at/o encryption, at malamang na medyo mataas ang network at disk load kung ang proseso ng pag-archive at/o pag-encrypt ay tumatakbo sa isang backup na storage server.
Patakbuhin natin ang sumusunod na command bilang isang reference na halaga:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Ang mga resulta ng pagpapatupad ay ang mga sumusunod:
Oras ng pagpapatupad 3m12s. Ito ay makikita na ang bilis ay limitado sa pamamagitan ng disk subsystem ng backup na imbakan server, tulad ng sa halimbawa sa . Medyo mabilis lang kasi... ang pag-record ay napupunta sa isang file.
Gayundin, upang suriin ang compression, patakbuhin natin ang parehong opsyon, ngunit paganahin ang compression sa panig ng backup na server:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Ang mga resulta ay:
Oras ng pagpapatupad 10m11s. Malamang na ang bottleneck ay ang single-flow compressor sa receiving end.
Ang parehong command, ngunit may compression na inilipat sa server na may orihinal na data upang subukan ang hypothesis na ang bottleneck ay isang single-threaded compressor.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Ito ay naging ganito:
Ang oras ng pagpapatupad ay 9m37s. Ang pag-load sa isang core ng compressor ay malinaw na nakikita, dahil Ang bilis ng paglipat ng network at ang load sa source disk subsystem ay magkatulad.
Upang suriin ang pag-encrypt, maaari mong gamitin ang openssl o gpg sa pamamagitan ng pagkonekta ng karagdagang command openssl o gpg sa tubo. Para sa sanggunian magkakaroon ng isang utos na tulad nito:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Ang mga resulta ay lumabas tulad nito:
Ang oras ng pagpapatupad ay naging 10m30s, dahil 2 proseso ang tumatakbo sa receiving side - ang bottleneck ay muling isang single-threaded compressor, kasama ang maliit na encryption overhead.
UPS: Sa kahilingan ng bliznezz nagdaragdag ako ng mga pagsubok sa pigz. Kung compressor lang ang gagamitin mo, aabutin ng 6m30s, kung magdadagdag ka rin ng encryption, magiging mga 7m. Ang dip sa ibabang graph ay isang hindi na-flush na disk cache:
Dobleng pagsubok
Ang duplicity ay isang python software para sa backup sa pamamagitan ng paglikha ng mga naka-encrypt na archive sa tar format.
Para sa mga incremental na archive, ginagamit ang librsync, kaya maaari mong asahan ang pag-uugali na inilalarawan sa .
Maaaring i-encrypt at lagdaan ang mga backup gamit ang gnupg, na mahalaga kapag gumagamit ng iba't ibang provider para sa pag-iimbak ng mga backup (s3, backblaze, gdrive, atbp.)
Tingnan natin kung ano ang mga resulta:
Ito ang mga resulta na nakuha namin kapag tumatakbo nang walang pag-encrypt
spoiler
Oras ng pagtakbo ng bawat pagsubok na pagtakbo:
Ilunsad 1
Ilunsad 2
Ilunsad 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
At narito ang mga resulta kapag pinagana ang gnupg encryption, na may pangunahing sukat na 2048 bits:
Oras ng pagpapatakbo sa parehong data, na may pag-encrypt:
Ilunsad 1
Ilunsad 2
Ilunsad 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Ang laki ng block ay ipinahiwatig - 512 megabytes, na malinaw na nakikita sa mga graph; Ang pag-load ng processor ay talagang nanatili sa 50%, na nangangahulugan na ang programa ay gumagamit ng hindi hihigit sa isang processor core.
Ang prinsipyo ng pagpapatakbo ng programa ay malinaw din na nakikita: kumuha sila ng isang piraso ng data, na-compress ito, at ipinadala ito sa isang backup na server ng imbakan, na maaaring maging mabagal.
Ang isa pang tampok ay ang predictable na oras ng pagpapatakbo ng programa, na nakasalalay lamang sa laki ng binagong data.
Ang pagpapagana ng pag-encrypt ay hindi lubos na nagpapataas sa oras ng pagpapatakbo ng programa, ngunit pinataas nito ang pagkarga ng processor ng humigit-kumulang 10%, na maaaring maging isang magandang bonus.
Sa kasamaang palad, ang program na ito ay hindi natukoy nang tama ang sitwasyon sa pagpapalit ng pangalan ng direktoryo, at ang nagresultang laki ng imbakan ay naging katumbas ng laki ng mga pagbabago (ibig sabihin, lahat ng 18GB), ngunit ang kakayahang gumamit ng hindi pinagkakatiwalaang server para sa pag-backup nang malinaw. sumasaklaw sa pag-uugaling ito.
Dobleng pagsubok
Ang software na ito ay nakasulat sa C# at tumatakbo gamit ang isang hanay ng mga aklatan mula sa Mono. Mayroong isang GUI pati na rin isang bersyon ng CLI.
Ang tinatayang listahan ng mga pangunahing tampok ay katulad ng duplicity, kabilang ang iba't ibang mga backup na provider ng imbakan, gayunpaman, hindi katulad ng pagdodoble, karamihan sa mga tampok ay magagamit nang walang mga third-party na tool. Kung ito ay isang plus o isang minus ay depende sa partikular na kaso, ngunit para sa mga nagsisimula, malamang na mas madaling magkaroon ng isang listahan ng lahat ng mga tampok sa harap ng mga ito nang sabay-sabay, sa halip na mag-install ng mga karagdagang pakete para sa python, tulad ng kaso may duplicity.
Ang isa pang maliit na nuance - ang programa ay aktibong nagsusulat ng isang lokal na database ng sqlite sa ngalan ng gumagamit na nagsimula ng backup, kaya kailangan mong dagdagan na tiyakin na ang kinakailangang database ay wastong tinukoy sa bawat oras na ang proseso ay sinimulan gamit ang cli. Kapag nagtatrabaho sa pamamagitan ng GUI o WEBGUI, ang mga detalye ay itatago mula sa user.
Tingnan natin kung anong mga tagapagpahiwatig ang maaaring gawin ng solusyon na ito:
Kung i-off mo ang pag-encrypt (at hindi inirerekomenda ng WEBGUI na gawin ito), ang mga resulta ay ang mga sumusunod:
Mga Oras:
Ilunsad 1
Ilunsad 2
Ilunsad 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Kapag pinagana ang pag-encrypt, gamit ang aes, ganito ang hitsura:
Mga Oras:
Ilunsad 1
Ilunsad 2
Ilunsad 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
At kung gagamitin mo ang external na program gnupg, lalabas ang mga sumusunod na resulta:
Ilunsad 1
Ilunsad 2
Ilunsad 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Tulad ng nakikita mo, ang programa ay maaaring gumana sa maraming mga thread, ngunit hindi ito ginagawang isang mas produktibong solusyon, at kung ihahambing mo ang pag-encrypt, naglulunsad ito ng isang panlabas na programa.
naging mas mabilis kaysa sa paggamit ng library mula sa Mono set. Ito ay maaaring dahil sa ang katunayan na ang panlabas na programa ay mas na-optimize.
Ang isa pang magandang bagay ay ang katotohanan na ang laki ng repository ay tumatagal nang eksakto hangga't ang aktwal na binagong data, i.e. duplicati ay nakakita ng isang pagpapalit ng pangalan ng direktoryo at pinangangasiwaan ng tama ang sitwasyong ito. Ito ay makikita kapag nagpapatakbo ng pangalawang pagsubok.
Sa pangkalahatan, medyo positibong mga impression ng programa, kabilang ang pagiging medyo palakaibigan sa mga baguhan.
Natuklasan
Ang parehong mga kandidato ay nagtrabaho sa halip mabagal, ngunit sa pangkalahatan, kumpara sa regular na tar, mayroong pag-unlad, kahit na may duplicati. Ang presyo ng naturang pag-unlad ay malinaw din - isang kapansin-pansing pasanin
processor. Sa pangkalahatan, walang mga espesyal na paglihis sa paghula ng mga resulta.
Natuklasan
Kung hindi mo kailangang magmadali kahit saan, at mayroon ding ekstrang processor, magagawa ang alinman sa mga solusyong isinasaalang-alang, sa anumang kaso, napakaraming trabaho ang nagawa na hindi na dapat ulitin sa pamamagitan ng pagsulat ng mga script ng wrapper sa ibabaw ng tar . Ang pagkakaroon ng pag-encrypt ay isang napakahalagang pag-aari kung ang server para sa pag-iimbak ng mga backup na kopya ay hindi lubos na mapagkakatiwalaan.
Kumpara sa mga solusyon batay - Ang pagganap ay maaaring ilang beses na mas masahol pa, sa kabila ng katotohanan na sa dalisay nitong anyo ng tar ay nagtrabaho ng 20-30% na mas mabilis kaysa sa rsync.
May mga matitipid sa laki ng repositoryo, ngunit may duplicati lamang.
Anunsyo
Backup Part 3: Suriin at subukan ang duplicity, duplicati, 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
Nai-post ni: Pavel Demkovich
Pinagmulan: www.habr.com