Tässä artikkelissa tarkastellaan varmuuskopiointiohjelmistoa, joka jakamalla tietovirran erillisiin osiin (paloihin) muodostaa arkiston.
Arkiston komponentteja voidaan edelleen pakata ja salata, ja mikä tärkeintä - toistuvien varmuuskopiointiprosessien aikana - käyttää uudelleen.
Varmuuskopio tällaisessa arkistossa on nimetty ketju komponentteja, jotka on kytketty toisiinsa esimerkiksi erilaisten hash-funktioiden perusteella.
On olemassa useita samanlaisia ratkaisuja, keskityn kolmeen: zbackup, borgbackup ja restic.
Odotetut tulokset
Koska kaikki hakijat edellyttävät arkiston luomista tavalla tai toisella, yksi tärkeimmistä tekijöistä on arkiston koon arvioiminen. Ihannetapauksessa sen koon tulisi olla enintään 13 Gt hyväksytyn menetelmän mukaan tai jopa pienempi - hyvällä optimoinnilla.
On myös erittäin toivottavaa pystyä luomaan varmuuskopioita tiedostoista suoraan ilman arkistointiohjelmia, kuten tar, sekä työskennellä ssh/sftp:n kanssa ilman lisätyökaluja, kuten rsync ja sshfs.
Käyttäytyminen varmuuskopioita luotaessa:
- Arkiston koko on yhtä suuri kuin muutosten koko tai pienempi.
- Prosessorin raskasta kuormitusta on odotettavissa käytettäessä pakkausta ja/tai salausta, ja melko korkea verkon ja levyn kuormitus on todennäköistä, jos arkistointi- ja/tai salausprosessi on käynnissä varmuuskopiotallennuspalvelimella.
- Jos arkisto on vaurioitunut, viivästynyt virhe on todennäköinen sekä luotaessa uusia varmuuskopioita että yritettäessä palauttaa. On tarpeen suunnitella lisätoimenpiteitä arkiston eheyden varmistamiseksi tai käyttää sisäänrakennettuja työkaluja sen eheyden tarkistamiseen.
Tervan kanssa työskentelyä pidetään viitearvona, kuten eräässä aiemmassa artikkelissa osoitettiin.
Testataan zbackupia
Zbackupin yleinen mekanismi on, että ohjelma löytää syötetietovirrasta alueet, jotka sisältävät samaa dataa, sitten valinnaisesti pakkaa ja salaa ne ja tallentaa kunkin alueen vain kerran.
Deduplikointi käyttää 64-bittistä rengashajautusfunktiota liukuvalla ikkunalla tarkistaakseen tavu-tavuilta vastaavuuksia olemassa oleviin tietolohkoihin (samalla tavalla kuin rsync toteuttaa sen).
Monisäikeisiä lzma- ja lzo-koodeja käytetään pakkaamiseen ja aes salaukseen. Uusimmissa versioissa on mahdollisuus poistaa vanhat tiedot arkistosta tulevaisuudessa.
Ohjelma on kirjoitettu C++:lla minimaalisilla riippuvuuksilla. Kirjoittaja ilmeisesti sai inspiraationsa unix-tavasta, joten ohjelma hyväksyy stdin-tiedot varmuuskopioita luodessaan ja tuottaa samanlaisen tietovirran stdoutissa palauttaessaan. Siten zbackupia voidaan käyttää erittäin hyvänä "rakennuspalikkana" kirjoitettaessa omia varmuuskopioratkaisuja. Esimerkiksi artikkelin kirjoittaja on käyttänyt tätä ohjelmaa kotikoneiden päävarmuuskopiointityökaluna noin vuodesta 2014 lähtien.
Tietovirta on tavallinen terva, ellei toisin mainita.
Katsotaanpa, mitkä ovat tulokset:
Työ tarkistettiin kahdella vaihtoehdolla:
- luodaan arkisto ja palvelimelle käynnistetään zbackup lähdetiedoilla, jonka jälkeen arkiston sisältö siirretään varmuuskopion tallennuspalvelimelle.
- varmuuskopiotallennuspalvelimelle luodaan arkisto, zbackup käynnistetään ssh:n kautta varmuuskopiotallennuspalvelimella ja data lähetetään siihen putken kautta.
Ensimmäisen vaihtoehdon tulokset olivat seuraavat: 43m11s - käytettäessä salaamatonta arkistoa ja lzma-kompressoria, 19m13s - kun kompressori korvataan lzo:lla.
Palvelimen kuormitus alkuperäisillä tiedoilla oli seuraava (esimerkki lzma:lla näkyy; lzo:lla oli suunnilleen sama kuva, mutta rsyncin osuus oli noin neljännes ajasta):
On selvää, että tällainen varmuuskopiointiprosessi soveltuu vain suhteellisen harvinaisiin ja pieniin muutoksiin. On myös erittäin suositeltavaa rajoittaa zbackup yhteen säiettä, muuten prosessorin kuormitus on erittäin korkea, koska Ohjelma on erittäin hyvä työskentelemään useissa säikeissä. Levyn kuormitus oli pieni, mikä ei yleensä olisi havaittavissa nykyaikaisella ssd-pohjaisella levyalijärjestelmällä. Näet myös selkeästi arkiston tietojen synkronoinnin etäpalvelimeen alkamisen; toiminnan nopeus on verrattavissa tavalliseen rsynciin ja riippuu varmuuskopiotallennuspalvelimen levyalijärjestelmän suorituskyvystä. Tämän lähestymistavan haittana on paikallisen arkiston tallennus ja sen seurauksena tietojen päällekkäisyys.
Mielenkiintoisempi ja käytännössä soveltuvampi on toinen vaihtoehto, jossa zbackup suoritetaan suoraan varmuuskopion tallennuspalvelimella.
Ensin testaamme toiminnan ilman salausta lzma-kompressorilla:
Kunkin koeajon ajoaika:
Käynnistä 1
Käynnistä 2
Käynnistä 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Jos otat salauksen käyttöön aes:n avulla, tulokset ovat melko lähellä:
Käyttöaika samoilla tiedoilla, salauksella:
Käynnistä 1
Käynnistä 2
Käynnistä 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Jos salaus yhdistetään pakkaamiseen lzo:lla, se näyttää tältä:
Tunnit:
Käynnistä 1
Käynnistä 2
Käynnistä 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Tuloksena olevan arkiston koko oli suhteellisen sama 13 Gt. Tämä tarkoittaa, että kopioinnin poistaminen toimii oikein. Myös jo pakatuissa tiedoissa lzo:n käyttö antaa huomattavan vaikutuksen: kokonaiskäyttöajassa zbackup on lähellä duplicity/duplicatia, mutta jäljessä librsynciin perustuvista 2-5 kertaa.
Edut ovat ilmeisiä - levytilan säästäminen varmuuskopiointipalvelimella. Mitä tulee arkiston tarkistustyökaluihin, zbackupin kirjoittaja ei tarjoa niitä, vaan on suositeltavaa käyttää vikasietoista levyryhmää tai pilvipalveluntarjoajaa.
Kaiken kaikkiaan erittäin hyvä vaikutelma huolimatta siitä, että projekti on ollut paikallaan noin 3 vuotta (edellinen ominaisuuspyyntö oli noin vuosi sitten, mutta ilman vastausta).
Testataan borgbackupia
Borgbackup on ullakkohaarukka, toinen järjestelmä, joka muistuttaa zbackupia. Pythonilla kirjoitettuna siinä on luettelo ominaisuuksista, jotka ovat samanlaisia kuin zbackupissa, mutta lisäksi se voi:
- Asenna varmuuskopiot sulakkeella
- Tarkista arkiston sisältö
- Työskentele asiakas-palvelin-tilassa
- Käytä dataa varten erilaisia kompressoreita sekä tiedostotyypin heuristista määritystä pakatessasi sitä.
- 2 salausvaihtoehtoa, aes ja blake
- Sisäänrakennettu työkalu
suorituskykytarkastukset
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Tulokset olivat seuraavat:
CZ-BIG 96.51 Mt/s (10 100.00 Mt täysin nollatiedostot: 10.36 s)
RZ-BIG 57.22 Mt/s (10 100.00 Mt täysin nollatiedostot: 17.48 s)
UZ-BIG 253.63 Mt/s (10 100.00 Mt täysin nollatiedostot: 3.94 s)
DZ-BIG 351.06 Mt/s (10 100.00 Mt täysin nollatiedostot: 2.85 s)
CR-BIG 34.30 Mt/s (10 100.00 Mt satunnaisia tiedostoja: 29.15 s)
RR-BIG 60.69 Mt/s (10 100.00 Mt satunnaisia tiedostoja: 16.48 s)
UR-BIG 311.06 Mt/s (10 100.00 Mt satunnaisia tiedostoja: 3.21 s)
DR-BIG 72.63 Mt/s (10 100.00 Mt satunnaisia tiedostoja: 13.77 s)
CZ-MEDIUM 108.59 Mt/s (1000 1.00 Mt täysin nollatiedostot: 9.21 s)
RZ-MEDIUM 76.16 MB/s (1000 1.00 Mt täysin nollatiedostot: 13.13 s)
UZ-MEDIUM 331.27 Mt/s (1000 1.00 Mt täysin nollatiedostot: 3.02 s)
DZ-MEDIUM 387.36 Mt/s (1000 1.00 Mt täysin nollatiedostot: 2.58 s)
CR-MEDIUM 37.80 Mt/s (1000 1.00 Mt satunnaisia tiedostoja: 26.45 s)
RR-MEDIUM 68.90 Mt/s (1000 1.00 Mt satunnaisia tiedostoja: 14.51 s)
UR-MEDIUM 347.24 Mt/s (1000 1.00 Mt satunnaisia tiedostoja: 2.88 s)
DR-MEDIUM 48.80 Mt/s (1000 1.00 Mt satunnaisia tiedostoja: 20.49 s)
CZ-SMALL 11.72 MB/s (10000 XNUMX 10.00 kB täysin nollatiedostot: 8.53 s)
RZ-SMALL 32.57 MB/s (10000 XNUMX 10.00 kB täysin nollatiedostot: 3.07 s)
UZ-SMALL 19.37 MB/s (10000 XNUMX 10.00 kB täysin nollatiedostot: 5.16 s)
DZ-SMALL 33.71 MB/s (10000 XNUMX 10.00 kB täysin nollatiedostot: 2.97 s)
CR-SMALL 6.85 Mt/s (10000 10.00 kt satunnaiset tiedostot: 14.60 s)
RR-SMALL 31.27 MB/s (10000 XNUMX 10.00 kt satunnaiset tiedostot: 3.20 s)
UR-SMALL 12.28 Mt/s (10000 XNUMX 10.00 kt satunnaiset tiedostot: 8.14 s)
DR-SMALL 18.78 Mt/s (10000 10.00 kt satunnaiset tiedostot: 5.32 s)
Testattaessa käytetään pakkausheuristiikkaa tiedostotyypin määrittämiseen (automaattinen pakkaus), ja tulokset ovat seuraavat:
Tarkistamme ensin, kuinka se toimii ilman salausta:
Tunnit:
Käynnistä 1
Käynnistä 2
Käynnistä 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Jos otat käyttöön arkiston valtuutuksen (todennettu tila), tulokset ovat lähellä:
Tunnit:
Käynnistä 1
Käynnistä 2
Käynnistä 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Kun aes-salaus otettiin käyttöön, tulokset eivät juurikaan huonontuneet:
Käynnistä 1
Käynnistä 2
Käynnistä 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Ja jos vaihdat aesin blakeksi, tilanne paranee täysin:
Tunnit:
Käynnistä 1
Käynnistä 2
Käynnistä 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Kuten zbackupin tapauksessa, arkiston koko oli 13 Gt ja jopa hieman vähemmän, mitä yleensä odotetaan. Olin erittäin tyytyväinen ajoaikaan, se on verrattavissa librsynciin perustuviin ratkaisuihin, jotka tarjoavat paljon laajemmat ominaisuudet. Olin myös tyytyväinen mahdollisuuteen asettaa erilaisia parametreja ympäristömuuttujien kautta, mikä antaa erittäin vakavan edun käytettäessä borgbackupia automaattitilassa. Olin myös tyytyväinen kuormaan varmuuskopioinnin aikana: prosessorin kuormituksesta päätellen borgbackup toimii 1 säikeessä.
Sen käytössä ei ollut erityisiä haittoja.
restikaalinen testaus
Huolimatta siitä, että restic on melko uusi ratkaisu (kaksi ensimmäistä ehdokasta tunnettiin jo vuonna 2 ja sitä vanhemmat), sillä on melko hyvät ominaisuudet. Kirjoitettu Go.
Verrattuna zbackupiin se antaa lisäksi:
- Arkiston eheyden tarkistaminen (mukaan lukien osien tarkistus).
- Valtava luettelo tuetuista protokollista ja palveluntarjoajista varmuuskopioiden tallentamiseen sekä tuki rclone - rsyncille pilviratkaisuille.
- 2 varmuuskopion vertailu keskenään.
- Varaston asennus sulakkeella.
Yleisesti ottaen ominaisuuksien luettelo on melko lähellä borgbackupia, paikoin enemmän, toisissa vähemmän. Yksi ominaisuuksista on, että salausta ei voi poistaa käytöstä, ja siksi varmuuskopiot salataan aina. Katsotaan käytännössä, mitä tästä ohjelmistosta voidaan puristaa irti:
Tulokset olivat seuraavat:
Tunnit:
Käynnistä 1
Käynnistä 2
Käynnistä 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Suorituskykytulokset ovat myös verrattavissa rsync-pohjaisiin ratkaisuihin ja yleisesti ottaen hyvin lähellä borgbackupia, mutta suorittimen kuormitus on suurempi (useita säikeitä käynnissä) ja sahahampainen.
Todennäköisimmin ohjelmaa rajoittaa tallennuspalvelimen levyalijärjestelmän suorituskyky, kuten jo tapahtui rsyncin tapauksessa. Arkiston koko oli 13 Gt, aivan kuten zbackup tai borgbackup, tämän ratkaisun käytössä ei ollut ilmeisiä haittoja.
Tulokset
Itse asiassa kaikki ehdokkaat saavuttivat samanlaisia tuloksia, mutta eri hinnoilla. Borgbackup suoriutui parhaiten, restic oli hieman hitaampi, zbackupia ei ehkä kannata aloittaa,
ja jos se on jo käytössä, yritä muuttaa se borgbackup- tai restic-muotoon.
Tulokset
Lupaavimmalla ratkaisulla näyttää olevan hillitty, koska... Hänellä on paras kykyjen suhde toimintanopeuteen, mutta älkäämme toistaiseksi kiirehtikö yleisiin johtopäätöksiin.
Borgbackup ei ole periaatteessa huonompi, mutta zbackup on luultavasti parempi korvata. Totta, zbackupia voidaan silti käyttää varmistamaan, että 3-2-1-sääntö toimii. Esimerkiksi (lib)rsync-pohjaisten varmuuskopiointipalvelujen lisäksi.
ilmoitus
Varmuuskopiointi, osa 5: Bacula- ja veeam-varmuuskopioiden testaus Linuxille
Varmuuskopiointi Osa 6: Varmuuskopiointityökalujen vertailu
Varmuuskopio Osa 7: Päätelmät
Lähettänyt: Pavel Demkovich
Lähde: will.com