Varundamine, osa 3: Ülevaade ja testimine duplicity, duplicati

Selles märkuses vaadeldakse varundustööriistu, mis teostavad varundamist, luues arhiive reservserverisse.

Nendest, mis vastavad nõuetele, on duplicity (millel on meeldiv liides deja dup kujul) ja duplicati.

Veel üks tähelepanuväärne varundustööriist on dar, kuid kuna sellel on väga ulatuslik valik valikuid — testimismeetod katab vaevalt 10% sellest, milleks ta võimeline on, — ei teste me seda käesoleva tsükli raames.

Oodatavad tulemused

Kuna mõlemad kandidaadid loovad arhiive, saab orientiirina kasutada tavalist tar-i.

Lisaks hindame, kui hästi optimeeritakse andmete salvestamist salvestusserveris, luues varukoopiaid, mis sisaldavad ainult erinevusi täieliku koopia ja failide praeguse seisundi vahel või eelmiste ja praeguste arhiivide vahel (inkrementaalsed, dekrementaalsed jne).

Varundamise käitumine:

1. Suhteliselt väike arv faile varundusserveris ( võrreldes varukoopiate arvu või andmete suurusega gb-des), kuid nende suurus on piisavalt suur (kümmekond-sada megabaiti).
2. Repo suurus sisaldab ainult muudatusi — dubleerimist ei salvestata, seega on repo suurus väiksem kui rsynci põhjal töötava tarkvara puhul.
3. Oodatakse suurt protsessorikoormust, kui kasutusele võetakse pakkimine ja/või krüptimine, samuti tõenäoliselt märkimisväärne koormus võrgu- ja ketaspetsialiseeritud süsteemile, kui arhiivimise ja/või krüptimise protsess töötab varundusserveris.

Viidatakse väärtusele, käivitame järgmise käsu:

cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"

Teostuse tulemused on sellised:

Teostusaeg 3m12s. On näha, et kiirus on saanud piiranguks varundusserveri kettasüsteem, nagu ka näites rsync. Ainult natuke kiiremini, kuna kirjutamine toimub ühte faili.

Samuti hindamiseks käivitame sama variandi, kuid lülitame sisse pakkimise varundusserveri 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 ühesuunaline kompressioon vastuvõtupoolel.

Sama käsk, kuid koos andmete serverisse edastamisega, et kontrollida hüpoteesi, et kitsaskohaks on üherealine kompressor.

cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"

Tulenes järgmine tulemus:

Täitmise aeg oli 9m37s. Selgelt on näha ühte tuuma koormust kompressorilt, kuna ülekanne võrgu kaudu ja koormus allika ketasüsteemile on sarnased.

Krüptimise hindamiseks võib kasutada openssl või gpg, ühendades täiendava käsuga openssl või gpg pipeline'is. Orientatsiooni saamiseks on järgmine 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 järgmised:

Täitmise aeg tuli 10m30s, kuna vastuvõtva poolel oli töötatud 2 protsessi — kitsaskohaks jäi jälle üherealine kompressor, pluss väikesed kulud krüptimisele.

UPD: bliznezz'i palve peale lisan testid pigziga. Kui kasutada ainult kompressorit — tuli 6m30s, kui lisada veel ka krüptimine — umbes 7m. Allolev langus graafikul — mitte tühistatud ketta vahemälu:

Testimine duplicity

Duplicity on Pythonil põhinev tarkvara varundamiseks krüpteeritud arhiivide loomise kaudu tar-formaadis.

Inkrementaalsete arhiivide puhul rakendatakse librsync'i, seega võib oodata käitumist, mis on kirjeldatud eelnevas märkuses tsüklist.

Varukoopiad võivad olla krüpteeritud ja allkirjastatud gnupg abil, mis on oluline erinevate teenusepakkujate kasutamisel varundamise jaoks (s3, backblaze, gdrive jne).

Vaatame, millised on tulemused:

Sellised tulemused saadi käivitamisel ilma krüptimiseta

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 gnupg krüptimisega, 2048 bitise võtmega:

Tööaeg samadel andmetel krüptimisega:

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 graafikutelt selgelt näha; protsessori koormus püsis tegelikult 50% tasemel, mis tähendab, et programm kasutab mitte rohkem kui ühte protsessorituuma.

Samuti on piisavalt hästi näha programmi tööpõhimõte: võeti andmete tükk, pressiti see kokku ning saadeti varundusserverisse, mis võib olla piisavalt aeglane.
Veel another feature is the predictable runtime of the program, which depends only on the size of the changed data.

Enabling encryption didn't significantly increase the runtime of the program, but it raised CPU load by about 10%, which can be quite a nice bonus.

Unfortunately, this program was unable to correctly detect a directory rename situation, and the resulting repository size turned out to be equal to the size of the changes (i.e. all 18GB), but the ability to use an untrusted server for backups definitely outweighs such behavior.

Testing duplicati

This software is written in C#, and runs using a set of libraries from Mono. There is a GUI as well as a CLI version.

The approximate list of key features is similar to duplicity, including various providers for backup storage, however, unlike duplicity, most features are available without third-party tools. Whether this is a plus or minus depends on the specific case, but for beginners, it is likely easier to have an immediately visible list of all features, rather than having to install packages for Python like in the case with duplicity.

Another small nuance is that the program actively writes a local SQLite database on behalf of the user running the backup, so it is necessary to additionally ensure the correct specification of the required database with each CLI process execution. When using the GUI or WEBGUI, these details will be hidden from the user.

Let's look at what metrics this solution can provide:

If you turn off encryption (although WEBGUI does not recommend this), the results are as follows:

Runtime:

Käivitamine 1
Käivitamine 2
Käivitamine 3

20m43s
20m13s
20m28s

5m21s
5m40s
5m35s

7m36s
7m54s
7m49s

With encryption enabled, using AES, the results are:

Runtime:

Käivitamine 1
Käivitamine 2
Käivitamine 3

29m9s
30m1s
29m54s

5m29s
6m2s
5m54s

8m44s
9m12s
9m1s

And if you use the external program GnuPG, the results are as follows:

Käivitamine 1
Käivitamine 2
Käivitamine 3

26m6s
26m35s
26m17s

5m20s
5m48s
5m40s

8m12s
8m42s
8m15s

As can be seen, the program can work in multiple threads, but this does not make it a more efficient solution, and when comparing encryption performance - running an external program
turned out to be faster than using the library from the Mono set. This may be due to the fact that the external program is better optimized.

Meeldiv hetk oli ka see, et reposti suurus on täpselt nii suur, kui palju tõeliselt muudetud andmeid on, st duplicati tuvastas katalooge ümbernimetamise ja töötles seda olukorda õigesti. Seda võib näha teise testi käigus.

Kokkuvõttes on programmist jäänud üsna positiivne mulje, sealhulgas piisav sõbralikkus algajatele.

tulemused näitasid ainult nelja ebaolulise koodibloki kattuvust, mis olid tingitud POSIX ja ANSI C nõuetest.

Mõlemad kandidaadid töötasid piisavalt aeglaselt, kuid üldiselt on võrreldes tavalise tar-iga tõhusus paranenud, vähemalt duplicati puhul. Sellise edusammuga kaasnevat hinda on samuti lihtne mõista — märgatav koormus
protsessorile. Üldiselt ei ole tulemuste prognoosimisel mingeid erilisi kõrvalekaldeid.

Järeldused

Kui kuhugi kiirustama ei pea ja protsessori koormus on piisav — sobib ükskõik milline arutatud lahendus, igal juhul on tehtud piisavalt suur töö, mida ei tasu kordamiseks tar-i kohaleste skriptide kirjutamisega. Krüpteerimise olemasolu on väga vajalik omadus, kui varukoopiate salvestamiseks mõeldud server ei ole täielikult usaldusväärne.

Kui võrrelda lahendusi, mis põhinevad rsync — jõudlus võib olla paar korda halvem, ehkki puhtal kujul töötas tar 20-30% kiiremini kui rsync.
Reposti suuruse kokkuhoid on olemas, kuid ainult duplicati puhul.

Teade

Varundamine, osa 1: Miks on varundamine vajalik, meetodite ja tehnoloogiate ülevaade
Varundamine, osa 2: rsync-põhiste varundustööriistade ülevaade ja testimine
Varundamine, osa 3: Duplicity, duplicati, deja dup ülevaade ja testimine
Varundamine, osa 4: Zbackup, restic, borgbackup ülevaade ja testimine
Varundamine, osa 5: Bacula ja Veeam Backup for Linux testimine
Varundamine, osa 6: Varundamise tööriistade võrdlus
Varundamine, osa 7: Järeldused

Artikli autor: Pavel Demkovich

Allikas: habr.com