Selles märkus arutatakse varundusvahendeid, mis teevad varukoopiaid arhiveerimise teel varundusserveris.
Nendest, mis vastavad nõuetele, on duplicit (millel on kena liides nimega deja dup) ja duplicati.
Teine tähelepanuväärne varundusvahend on dar, kuid kuna sellel on ulatuslik valik valikuid — testimise meetod katab vaevalt 10% sellest, milleks ta võimeline on — ei testi me seda praeguses tsüklis.
Oodatavad tulemused
Kuna mõlemad kandidaadid loovad niikuinii arhiive, on orientiiriks tavapärane tar.
Lisaks hindame, kui hästi optimeeritakse andmete säilitamist varukeskkonnas, luues varukoopiaid, mis sisaldavad ainult erinevust täiskoopiast ja praegusest failide seisundist või eelmiste ja praeguste arhiivide vahel (inkrementaalsed, dekrementaalsed jne).
Varukoopia loomise käitumine:
- Suhteliselt väike arv faile varukoopia serveris (võrdne varukoopiate arvu või andmete suurusega gb-des), kuid piisavalt suur nende mõõt (kümmekond-sada megabaiti).
- Ainura asendada ainult muudatused — koopiaid ei salvestata, seetõttu on repositooriumi suurus väiksem kui rsync-põhise tarkvara puhul.
- Oodatakse suurt koormust protsessorile, kui kasutatakse tihendamist ja/või krüptimist, samuti tõenäoliselt piisavalt suurt koormust võrku ja ketasüsteemi, kui arhiveerimise ja/või krüptimise protsess töötab varukoopiate salvestamise serveris.
Referentsväärtusena käivitame järgmise käsu:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Käivitamise tulemused olid järgmised:
Käideldud aeg 3m12s. Näha on, et kiirus on jäänud kinni varukoopiate salvestamise serveri ketasüsteemi, nagu eespool näidatud. . Ainult veidi kiiremini, kuna kirjutamine toimub ühte faili.
Samuti, et hinnata tihendamist, käivitame sama variandi, kuid lülitame sisse tihendamise varukoopiate salvestamise serveris:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Tulemused on sellised:
Käideldud aeg 10m11s. Tõenäoliselt on kitsaskohaks ühe lõimega tihendaja vastuvõtuperiood.
Sama käsk, kuid kompressiooni üleviimine serverisse, kus asuvad algandmed, et kontrollida hüpoteesi, et kitsaskoht on üheahelaline kompressor.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Tulemus oli selline:
Teostusaeg oli 9m37s. Selgelt on näha ühte tuuma koormust kompressoriga, kuna andmeedastuskiirus ja koormus allika kettasüsteemile on sarnased.
Krüpteerimise hindamiseks saab kasutada openssl'i või gpg'd, ühendades lisakäsku openssl või gpg pipe'is. Orientiirina 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 olid sellised:
Teostusaeg tuli 10m30s, kuna vastuvõtjal töötas 2 protsessi — kitsaskoht oli jälle üheahelaline kompressor, pluss väiksed kulud krüpteerimisele.
UPD: Kasutaja bliznezz palus, et lisaksin pigz testid. Kui kasutada ainult kompressorit — saadi 6m30s, kui lisada ka krüpteerimine — umbes 7m. Madal langus allosas graafikul — ketta vahemälu, mis ei ole tühjendatud:
Testimine duplicity
Duplicity — Pythonil põhinev varundustarkvara, mis loob šifreeritud arhiive tar formaadis.
Inkrementaalsete arhiivide puhul kasutatakse librsync'i, mistõttu on oodata käitumist, nagu on kirjeldatud .
Varukoopiad saadakse krüpteerimise ja allkirjastamise teel gnupg abil, mis on oluline, kui kasutatakse erinevaid teenusepakkujaid varukoopiate hoidmiseks (s3, backblaze, gdrive jne)
Vaadakem, millised tulemused on:
Siin on tulemused, mis saadud, kui krüpteerimine oli välja lülitatud
spoiler
Iga testkäivituse tööaeg:
Käivitamine 1
Käivitamine 2
Käivitamine 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Siin on tulemused, kui gnupg krüpteerimine on sisse lülitatud, võtme suurusega 2048 bitti:
Aeg töödelda sama andmete, koos krüpteerimisega:
Käivitamine 1
Käivitamine 2
Käivitamine 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Bloki suurus oli määratud — 512 megabaiti, mida on selgelt näha graafikutelt; protsessori kasutus püsis umbes 50% tasemel, mis tähendab, et programm kasutab maksimaalselt ühte protsessori tuuma.
Samuti on üsna hästi näha programmi tööpõhimõte: võeti andmepala, kompressiti see ja saadeti varukoopiate hoidmise serverisse, mis võib olla piisavalt aeglane.
Veel üks omadus — programmi tööaeg on ennustatav, sõltudes ainult muudetud andmete suurusest.
Krüptimise lubamine ei suurendanud programmi tööaega eriti, kuid see tõstis protsessori koormust umbes 10%, mis võib olla üsna hea boonus.
Kahjuks ei suutnud see programm õigesti tuvastada katalooge ümbernimetamise olukorda ning resultingi suurus osutus võrdseks muudatuste suurusega (st kõik 18 GB), kuid võimalus kasutada usaldamatut serverit varundamiseks ületab kindlasti sellise käitumise.
Duplicati testimine
See tarkvara on kirjutatud C#-s, käivitatakse Mono teegikomplekti kasutades. Saadaval on GUI ja ka CLI versioon.
Umbes peamiste funktsioonide loetelu on sarnane Duplicity'le, sealhulgas erinevad teenusepakkujad varukoopiate salvestamiseks, kuid erinevalt Duplicity'st on enamik funktsioone saadaval ilma kolmanda osapoole tööriistadeta. Kas see on pluss või miinus - sõltub konkreetsest olukorrast, kuid algajate jaoks on tõenäoliselt lihtsam have kohe silme ees nimekiri kõigist funktsioonidest, mitte installida lisapakette python'i jaoks, nagu Duplicity puhul.
Veel on väiksem nüanss — programm kirjutab aktiivselt lokaalse sqlite andmebaasi selle kasutaja nimel, kes käivitab varundamise, seega tuleb protsessi iga käivitamise puhul hoolikalt jälgida, et vajalik andmebaas oleks õigesti määratud, kasutades cli-d. Graafilise liidese või WEBGUI kaudu töötades on detailid kasutaja eest peidetud.
Vaatame, milliseid näitajaid see lahendus võib anda:
Kui krüpteerimine välja lülitada (kuigi WEBGUI ei soovita seda teha), on tulemused järgmised:
Töötamise aeg:
Käivitamine 1
Käivitamine 2
Käivitamine 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Krüpteerimisega sisselülitatud, kasutades aes, on tulemused sellised:
Töötamise aeg:
Käivitamine 1
Käivitamine 2
Käivitamine 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Ja kui kasutada välist programmi gnupg, on tulemused järgmised:
Käivitamine 1
Käivitamine 2
Käivitamine 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Nagu näha — programm suudab töötada mitmes niidis, kuid seetõttu ei ole see efektiivsem lahendus, ja krüpteerimise töötlemise võrdluses on välist programmi käivitamine
olnud kiirem kui Mono raamatukogu rakendamine. Võimalik, et see on seotud sellega, et väline programm on paremini optimeeritud.
Mugav on märkida, et allika suurus vastab täpselt muutunud andmete mahule, st duplicati tuvastas katalooge ümbernimetamise ja töötles seda olukorda õigesti. Seda saab näha teise testi käivitamisel.
Kokkuvõttes on mul programmist üsna positiivne mulje, sealhulgas piisav algajate sõbralikkus.
Tulemused
Mõlemad kandidaadid töötasid üsna rahulikult, kuid üldiselt on võrreldes tavalise tar-iga mingisugune edusamm, vähemalt duplicati puhul. Sellise edusamme hind on samuti arusaadav - märgatav koormus
protsessorile. Üldiselt ei esine tulemuste prognoosimisel mingeid erilisi kõrvalekaldeid.
Järeldused
Kui ei ole kuhugi kiirus, ja protsessori ressursid on piisavad — sobib ükskõik milline kaalutud lahendus, igal juhul on tehtud piisavalt suur töö, mida ei tasu korduda skriptide kirjutamisega tar-i peale. Krüpteeringu olemasolu on väga vajalik omadus, kui varukoopiate salvestamise serverit ei saa täielikult usaldada.
Kui võrrelda lahendusi, mis põhinevad — jõudlus võib olla mitu korda halvem, kuigi puhtal kujul töötas tar 20–30% kiiremini kui rsync.
Salvestusruumi kokkuhoid on olemas, kuid ainult duplicati puhul.
Teade
Varundamine, osa 3: Overv view ja testimine duplicity, duplicati, deja dup
Varundamine, osa 4: Zbackup, restic, borgbackup ülevaade ja testimine
Varundamine, osa 5: Bacula ja Veeam Backup for Linux testimine
Varundamine, osa 6: Varundamisvahendite võrdlus
Varundamine, osa 7: Järeldused
Autori publikatsioon: Pavel Demkovič
Allikas: habr.com
