Selles märkuses käsitletakse varundustööriistu, mis teevad varukoopiaid, luues varuserveris arhiive.
Nõuetele vastavate hulgas on duplicity (millel on kena liides deja dupi kujul) ja duplicati.
Teine väga tähelepanuväärne varundustööriist on dar, kuid kuna sellel on väga lai valik valikuid – testimismetoodika katab vaevalt 10% sellest, milleks see on võimeline –, me ei testi seda praeguse tsükli osana.
Oodatud tulemused
Kuna mõlemad kandidaadid loovad arhiive ühel või teisel viisil, võib juhendina kasutada tavalist tõrva.
Lisaks hindame, kui hästi on andmete salvestamine salvestusserveris optimeeritud, luues varukoopiad, mis sisaldavad ainult erinevust täieliku koopia ja failide praeguse oleku või eelmise ja praeguse arhiivi (kasvav, kahanev jne) vahel. .
Käitumine varukoopiate loomisel:
- Varundusmäluserveris suhteliselt väike arv faile (võrreldes varukoopiate arvu või andmete suurusega GB-des), kuid nende maht on üsna suur (kümned kuni sadu megabaite).
- Hoidla suurus hõlmab ainult muudatusi – duplikaate ei salvestata, seega on hoidla suurus väiksem kui rsync-põhise tarkvara puhul.
- Pakkimise ja/või krüptimise kasutamisel on oodata suurt protsessori koormust ning tõenäoliselt üsna suurt võrgu- ja kettakoormust, kui arhiveerimis- ja/või krüpteerimisprotsess töötab varusalvestusserveris.
Käivitame võrdlusväärtusena järgmise käsu:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Täitmise tulemused olid järgmised:
Teostusaeg 3m12s. On näha, et kiirust piirab varusalvestusserveri ketta alamsüsteem, nagu näites . Ainult veidi kiiremini, sest... salvestus läheb ühte faili.
Samuti käivitame tihendamise hindamiseks sama valiku, kuid lubame pakkimise varuserveri poolel:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Tulemused on järgmised:
Teostusaeg 10m11s. Tõenäoliselt on kitsaskohaks vastuvõtuotsas ühevooluline kompressor.
Sama käsk, kuid koos algandmetega serverisse edastatud pakkimisega, et testida hüpoteesi, et kitsaskohaks on ühe keermega kompressor.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"See osutus järgmiselt:
Teostusaeg oli 9m37s. Kompressori poolt ühe südamiku koormus on selgelt näha, sest Võrgu edastuskiirus ja lähteketta alamsüsteemi koormus on sarnased.
Krüptimise hindamiseks saate kasutada openssl-i või gpg-d, ühendades täiendava käsu openssl või gpg torus. Viitamiseks on selline käsk:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Tulemused tulid välja sellised:
Täitmisajaks osutus 10m30s, kuna vastuvõtupoolel töötas 2 protsessi - pudelikaelaks on jällegi ühe keermega kompressor, pluss väike krüpteerimiskulu.
UPD: Bliznezzi palvel lisan testid pigziga. Kui kasutada ainult kompressorit, siis kuluks 6m30s, kui lisada ka krüpteering, siis ca 7m. Alumise graafiku langus on puhastamata ketta vahemälu:
Dubleeritud testimine
Duplicity on pythoni tarkvara varundamiseks, luues tar-vormingus krüptitud arhiive.
Täiendavate arhiivide jaoks kasutatakse librsynci, nii et võite oodata artiklis kirjeldatud käitumist .
Varukoopiaid saab krüpteerida ja allkirjastada gnupg abil, mis on oluline erinevate pakkujate kasutamisel varukoopiate salvestamiseks (s3, backblaze, gdrive jne)
Vaatame, millised on tulemused:
Need on tulemused, mille saime krüptimata töötamisel
spoiler
Iga katsesõidu kestus:
Käivitage 1
Käivitage 2
Käivitage 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Ja siin on tulemused, kui gnupg-krüptimine on lubatud võtme suurusega 2048 bitti:
Tööaeg samadel andmetel krüptimisega:
Käivitage 1
Käivitage 2
Käivitage 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Märgiti ploki suurus - 512 megabaiti, mis on graafikutel selgelt näha; Protsessori koormus jäi tegelikult 50% juurde, mis tähendab, et programm ei kasuta rohkem kui ühte protsessorituuma.
Ka programmi tööpõhimõte on üsna selgelt nähtav: nad võtsid tüki andmeid, tihendasid need ja saatsid varusalvestusserverisse, mis võib olla üsna aeglane.
Teine omadus on programmi prognoositav tööaeg, mis sõltub ainult muudetud andmete suurusest.
Krüptimise lubamine programmi tööaega oluliselt ei suurendanud, küll aga suurendas protsessori koormust umbes 10%, mis võib olla päris kena boonus.
Kahjuks ei suutnud see programm kataloogi ümbernimetamise olukorda õigesti tuvastada ja sellest tulenev hoidla suurus osutus võrdseks muudatuste suurusega (st kõik 18 GB), kuid selgelt oli võimalus kasutada varundamiseks ebausaldusväärset serverit. katab seda käitumist.
Dubleeritud testimine
See tarkvara on kirjutatud C# keeles ja töötab Mono teekide komplekti kasutades. Olemas on nii GUI kui ka CLI versioon.
Peamiste funktsioonide ligikaudne loend sarnaneb kahepalgelisusega, sealhulgas erinevate varukoopiate salvestusruumi pakkujatega, kuid erinevalt kahepalgelisusest on enamik funktsioone saadaval ilma kolmandate osapoolte tööriistadeta. Kas see on pluss või miinus, sõltub konkreetsest juhtumist, kuid algajatel on tõenäoliselt lihtsam omada korraga kõigi funktsioonide loendit, selle asemel et installida pythoni jaoks lisapakette, nagu on juhtum kahepalgelisusega.
Veel üks väike nüanss - programm kirjutab aktiivselt kohalikku sqlite'i andmebaasi kasutaja nimel, kes varundamist alustab, nii et peate lisaks tagama, et iga kord, kui protsess cli abil käivitatakse, on vajalik andmebaas õigesti määratud. GUI või WEBGUI kaudu töötades peidetakse üksikasjad kasutaja eest.
Vaatame, milliseid näitajaid see lahendus võib anda:
Kui lülitate krüptimise välja (ja WEBGUI ei soovita seda teha), on tulemused järgmised:
tundi:
Käivitage 1
Käivitage 2
Käivitage 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Kui krüpteerimine on lubatud, näeb see välja järgmine:
tundi:
Käivitage 1
Käivitage 2
Käivitage 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Ja kui kasutate välist programmi gnupg, ilmuvad järgmised tulemused:
Käivitage 1
Käivitage 2
Käivitage 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Nagu näete, võib programm töötada mitmes lõimes, kuid see ei muuda seda produktiivsemaks lahenduseks ja kui krüpteerimistööd võrrelda, käivitab see välise programmi
osutus kiiremaks kui Mono komplekti raamatukogu kasutamine. See võib olla tingitud asjaolust, et väline programm on rohkem optimeeritud.
Tore asi oli ka asjaolu, et hoidla suurus võtab täpselt sama palju kui tegelik muutunud andmed, st. duplicati tuvastas kataloogi ümbernimetamise ja käsitles seda olukorda õigesti. Seda on näha teist testi tehes.
Üldiselt jäid programmist üsna positiivsed muljed, sealhulgas algajate suhtes üsna sõbralik olemine.
Järeldused
Mõlemad kandidaadid töötasid üsna aeglaselt, kuid üldiselt on tavalise tõrvaga võrreldes edusamme, vähemalt duplikaatide osas. Selge on ka sellise progressi hind – tuntav koorem
protsessor. Üldiselt tulemuste ennustamisel erilisi kõrvalekaldeid ei ole.
Järeldused
Kui pole vaja kuhugi tormata ja ka varuprotsessor on olemas, läheb igaks kaalutletud lahenduseks, igatahes on tehtud päris palju tööd, mida ei tohiks tõrva peale ümbrisskripte kirjutades korrata. . Krüptimise olemasolu on väga vajalik omadus, kui varukoopiate salvestamise serverit ei saa täielikult usaldada.
Võrreldes lahendustega - jõudlus võib olla mitu korda halvem, hoolimata asjaolust, et puhtal kujul töötas tõrv 20-30% kiiremini kui rsync.
Hoidla suuruselt saab kokku hoida, kuid ainult duplikaatidega.
Kuulutus
Varukoopia 3. osa: kahepalgelisuse ülevaatamine ja testimine, duplicati, deja dup
Varundamine 4. osa: zbackup, restic, borgbackup ülevaatamine ja testimine
Varukoopia 5. osa: bacula ja veeam varukoopia testimine Linuxi jaoks
Varundamine 6. osa: varundustööriistade võrdlemine
Varukoopia 7. osa: Järeldused
Postitas: Pavel Demkovitš
Allikas: www.habr.com