Dit artikel sil backupsoftware beskôgje dy't, troch it brekken fan de gegevensstream yn aparte komponinten (brokken), in repository foarmet.
Repository-komponinten kinne fierder komprimearre en fersifere wurde, en it wichtichste - by werhelle backupprosessen - opnij brûkt.
In reservekopy yn sa'n repository is in neamde keatling fan komponinten dy't mei elkoar ferbûn binne, bygelyks basearre op ferskate hashfunksjes.
Der binne ferskate ferlykbere oplossings, Ik sil rjochtsje op 3: zbackup, borgbackup en restic.
Ferwachte útkomsten
Om't alle oanfregers it oanmeitsjen fan in repository op ien of oare manier fereaskje, sil ien fan 'e wichtichste faktoaren wêze om de grutte fan' e repository te skatten. Idealiter soe syn grutte net mear wêze moatte as 13 GB neffens de akseptearre metodyk, of noch minder - ûnder foarbehâld fan goede optimalisaasje.
It is ek heul winsklik om direkt reservekopyen fan bestannen te meitsjen, sûnder argiven lykas tar te brûken, en ek wurkje mei ssh/sftp sûnder ekstra ark lykas rsync en sshfs.
Gedrach by it meitsjen fan backups:
- De grutte fan it repository sil gelyk wêze oan de grutte fan 'e feroarings, of minder.
- Swiere CPU-lading wurdt ferwachte by it brûken fan kompresje en / of fersifering, en frij hege netwurk- en skiifbelêsting is wierskynlik as it argyf- en / of fersiferingsproses rint op in reservekopy-opslachtsjinner.
- As it repository skansearre is, is in fertrage flater wierskynlik sawol by it meitsjen fan nije backups as by it besykjen om te herstellen. It is needsaaklik om ekstra maatregels te planjen om de yntegriteit fan 'e repository te garandearjen of ynboude ark te brûken om de yntegriteit te kontrolearjen.
Wurkje mei tar wurdt as referinsjewearde nommen, lykas yn ien fan 'e foarige artikels te sjen is.
Zbackup testen
De algemiene meganisme fan zbackup is dat it programma fynt yn de ynfier gegevens stream gebieten dy't befetsje deselde gegevens, dan opsjoneel komprimearret en fersiferet se, saving elk gebiet mar ien kear.
Deduplikaasje brûkt in 64-bit ring-hash-funksje mei in sliding finster om te kontrolearjen op byte-by-byte-oerienkomsten tsjin besteande gegevensblokken (lykas hoe't rsync it ymplementearret).
Multi-threaded lzma en lzo wurde brûkt foar kompresje, en aes foar fersifering. De lêste ferzjes hawwe de mooglikheid om âlde gegevens út it repository yn 'e takomst te wiskjen.
It programma is skreaun yn C ++ mei minimale ôfhinklikens. De skriuwer waard blykber ynspirearre troch de unix-manier, dus it programma akseptearret gegevens op stdin by it meitsjen fan backups, en produsearret in ferlykbere gegevensstream op stdout by it weromsetten. Sa kin zbackup brûkt wurde as in tige goede "boublok" by it skriuwen fan jo eigen backup-oplossingen. Bygelyks, de skriuwer fan it artikel hat dit programma brûkt as de wichtichste reservekopy ark foar thús masines sûnt likernôch 2014.
De gegevensstream sil in gewoane tar wêze, útsein as oars oanjûn.
Litte wy sjen wat de resultaten binne:
It wurk waard kontrolearre yn 2 opsjes:
- in repository wurdt makke en zbackup wurdt lansearre op 'e tsjinner mei de boarne gegevens, dan wurdt de ynhâld fan' e repository oerbrocht nei de reservekopy opslach tsjinner.
- in repository wurdt makke op de reservekopy opslach tsjinner, zbackup wurdt lansearre fia ssh op de reservekopy opslach tsjinner, en gegevens wurde stjoerd nei it fia pipe.
De resultaten fan 'e earste opsje wiene as folget: 43m11s - by it brûken fan in net-fersifere repository en de lzma-kompressor, 19m13s - by it ferfangen fan de kompressor mei lzo.
De lading op de server mei de orizjinele gegevens wie as folget (in foarbyld mei lzma wurdt werjûn; mei lzo wie der sawat deselde ôfbylding, mar it oandiel fan rsync wie sawat in kwart fan 'e tiid):
It is dúdlik dat sa'n reservekopyproses allinich geskikt is foar relatyf seldsume en lytse feroaringen. It is ek tige oan te rieden om zbackup te beheinen ta 1 thread, oars sil d'r in heul hege CPU-belêsting wêze, om't It programma is heul goed om yn meardere threads te wurkjen. De lading op 'e skiif wie lyts, wat yn' t algemien net te merken soe wêze mei in moderne ssd-basearre skiifsubsysteem. Jo kinne ek dúdlik sjen it begjin fan it proses fan syngronisaasje repository gegevens nei in tsjinner op ôfstân; de snelheid fan operaasje is te fergelykjen mei reguliere rsync en hinget ôf fan de prestaasjes fan it skiif subsysteem fan de reservekopy opslach tsjinner. It neidiel fan dizze oanpak is de opslach fan in lokale repository en, as gefolch, duplikaasje fan gegevens.
Mear ynteressant en fan tapassing yn 'e praktyk is de twadde opsje, it útfieren fan zbackup direkt op' e backup-opslachtsjinner.
Earst sille wy de operaasje testen sûnder fersifering te brûken mei de lzma-kompressor:
Running tiid fan elke test run:
Start 1
Start 2
Start 3
39 m45s
40 m20s
40 m3s
7 m36s
8 m3s
7 m48s
15 m35s
15 m48s
15 m38s
As jo fersifering ynskeakelje mei aes, binne de resultaten frij tichtby:
Bedriuwstiid op deselde gegevens, mei fersifering:
Start 1
Start 2
Start 3
43 m40s
44 m12s
44 m3s
8 m3s
8 m15s
8 m12s
15 m0s
15 m40s
15 m25s
As fersifering wurdt kombinearre mei kompresje mei lzo, sjocht it der sa út:
Wurkstikken:
Start 1
Start 2
Start 3
18 m2s
18 m15s
18 m12s
5 m13s
5 m24s
5 m20s
8 m48s
9 m3s
8 m51s
De grutte fan it resultearjende repository wie relatyf itselde by 13GB. Dit betsjut dat deduplikaasje goed wurket. Ek op al komprimearre gegevens jout it brûken fan lzo in merkber effekt; yn termen fan totale wurktiid komt zbackup tichtby duplicity / duplicati, mar bliuwt efter dy basearre op librsync mei 2-5 kear.
De foardielen binne fanselssprekkend - it besparjen fan skiifromte op 'e backup-opslachtsjinner. Wat ark foar repository-kontrôle oanbelanget, leveret de auteur fan zbackup se net; it wurdt oanrikkemandearre om in flater-tolerante skiif-array of wolkprovider te brûken.
Oer it algemien in tige goede yndruk, nettsjinsteande it feit dat it projekt al sa'n 3 jier stilstiet (it lêste funksjefersyk wie sa'n jier lyn, mar sûnder reaksje).
Borgbackup testen
Borgbackup is in foarke fan attic, in oar systeem fergelykber mei zbackup. Skreaun yn python hat it in list mei mooglikheden fergelykber mei zbackup, mar kin ek:
- Mount backups fia fuse
- Kontrolearje de ynhâld fan repository
- Wurkje yn client-tsjinner modus
- Brûk ferskate kompresjers foar gegevens, lykas heuristyske bepaling fan it bestânstype by it komprimearjen.
- 2 fersifering opsjes, aes en blake
- Ynboude ark foar
prestaasje kontrôles
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
De resultaten wiene as folget:
CZ-BIG 96.51 MB/s (10 100.00 MB alle-nul triemmen: 10.36s)
RZ-BIG 57.22 MB/s (10 100.00 MB alle-nul triemmen: 17.48s)
UZ-BIG 253.63 MB/s (10 100.00 MB alle-nul triemmen: 3.94s)
DZ-BIG 351.06 MB/s (10 100.00 MB alle-nul triemmen: 2.85s)
CR-BIG 34.30 MB/s (10 100.00 MB willekeurige triemmen: 29.15s)
RR-BIG 60.69 MB/s (10 100.00 MB willekeurige triemmen: 16.48s)
UR-BIG 311.06 MB/s (10 100.00 MB willekeurige triemmen: 3.21s)
DR-BIG 72.63 MB/s (10 100.00 MB willekeurige triemmen: 13.77s)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB alle-nul triemmen: 9.21s)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB alle-nul triemmen: 13.13s)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB alle-nul triemmen: 3.02s)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB alle-nul triemmen: 2.58s)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB willekeurige triemmen: 26.45s)
RR-MEDIUM 68.90 MB/s (1000 1.00 MB willekeurige triemmen: 14.51s)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB willekeurige triemmen: 2.88s)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB willekeurige triemmen: 20.49s)
CZ-SMALL 11.72 MB/s (10000 10.00 kB alle-nul triemmen: 8.53s)
RZ-SMALL 32.57 MB/s (10000 10.00 kB alle-nul triemmen: 3.07s)
UZ-SMALL 19.37 MB/s (10000 10.00 kB alle-nul triemmen: 5.16s)
DZ-SMALL 33.71 MB/s (10000 10.00 kB alle-nul triemmen: 2.97s)
CR-SMALL 6.85 MB/s (10000 10.00 kB willekeurige triemmen: 14.60s)
RR-SMALL 31.27 MB/s (10000 10.00 kB willekeurige triemmen: 3.20s)
UR-SMALL 12.28 MB/s (10000 10.00 kB willekeurige triemmen: 8.14s)
DR-SMALL 18.78 MB/s (10000 10.00 kB willekeurige triemmen: 5.32s)
By it testen sil kompresjeheuristyk wurde brûkt om it bestânstype te bepalen (autokompresje), en de resultaten sille as folgjend wêze:
Litte wy earst kontrolearje hoe't it wurket sûnder fersifering:
Wurkstikken:
Start 1
Start 2
Start 3
4 m6s
4 m10s
4 m5s
56s
58s
54s
1 m26s
1 m34s
1 m30s
As jo repository autorisaasje ynskeakelje (ferifiearre modus), sille de resultaten ticht wêze:
Wurkstikken:
Start 1
Start 2
Start 3
4 m11s
4 m20s
4 m12s
1 m0s
1 m3s
1 m2s
1 m30s
1 m34s
1 m31s
Doe't aes-fersifering waard aktivearre, waarden de resultaten net folle minder:
Start 1
Start 2
Start 3
4 m55s
5 m2s
4 m58s
1 m0s
1 m2s
1 m0s
1 m49s
1 m50s
1 m50s
En as jo aes feroarje nei blake, sil de situaasje folslein ferbetterje:
Wurkstikken:
Start 1
Start 2
Start 3
4 m33s
4 m43s
4 m40s
59s
1 m0s
1 m0s
1 m38s
1 m43s
1 m40s
Lykas yn it gefal fan zbackup wie de repositorygrutte 13GB en sels in bytsje minder, wat algemien ferwachte wurdt. Ik wie tige tefreden mei de rinnende tiid; it is te fergelykjen mei oplossingen basearre op librsync, en biedt folle bredere mooglikheden. Ik wie ek bliid mei de mooglikheid om te setten ferskate parameters fia miljeu fariabelen, dat jout in hiel serieus foardiel by it brûken fan borgbackup yn automatyske modus. Ik wie ek bliid mei de lading by reservekopy: oardielje troch de prosessor load, borgbackup wurket yn 1 thread.
D'r wiene gjin bysûndere neidielen by it brûken fan it.
restyske testen
Nettsjinsteande it feit dat restic is in frij nije oplossing (de earste 2 kandidaten wiene bekend werom yn 2013 en âlder), it hat frij goede skaaimerken. Skreaun yn Go.
Yn fergeliking mei zbackup jout it ek:
- Kontrolearje de yntegriteit fan 'e repository (ynklusyf kontrôle yn dielen).
- In enoarme list mei stipe protokollen en oanbieders foar it opslaan fan backups, lykas ek stipe foar rclone - rsync foar wolkoplossingen.
- Fergelykje 2 backups mei elkoar.
- Montearje de repository fia fuse.
Yn 't algemien is de list mei funksjes frij ticht by borgbackup, op guon plakken mear, yn oaren minder. Ien fan 'e funksjes is dat d'r gjin manier is om fersifering út te skeakeljen, en dêrom sille reservekopyen altyd fersifere wurde. Litte wy yn 'e praktyk sjen wat jo út dizze software kinne drukke:
De resultaten wiene as folget:
Wurkstikken:
Start 1
Start 2
Start 3
5 m25s
5 m50s
5 m38s
35s
38s
36s
1 m54s
2 m2s
1 m58s
De prestaasjes resultaten binne ek te fergelykjen mei rsync-basearre oplossings en, yn it algemien, hiel ticht by borgbackup, mar de CPU load is heger (meardere triedden running) en sawtooth.
Meast wierskynlik wurdt it programma beheind troch de prestaasjes fan it skiifsubsysteem op 'e gegevensopslachtsjinner, lykas al it gefal wie mei rsync. De repositorygrutte wie 13GB, krekt as zbackup of borgbackup, d'r wiene gjin dúdlike neidielen by it brûken fan dizze oplossing.
Resultaten
Yn feite, alle kandidaten berikte ferlykbere resultaten, mar tsjin ferskillende prizen. Borgbackup prestearre it bêste fan alles, restic wie in bytsje stadiger, zbackup is wierskynlik net wurdich om te begjinnen te brûken,
en as it al yn gebrûk is, besykje it te feroarjen nei borgbackup of restic.
befinings
De meast kânsrike oplossing liket rêstich te wêzen, om't ... it is hy dy't de bêste ferhâlding fan mooglikheden hat ta operearjende snelheid, mar lit ús no net haastje nei algemiene konklúzjes.
Borgbackup is yn prinsipe net slimmer, mar zbackup is nei alle gedachten better ferfongen. Wier, zbackup kin noch brûkt wurde om te soargjen dat de 3-2-1-regel wurket. Bygelyks, neist (lib)rsync-basearre reservekopyfoarsjenningen.
Meidieling
Reservekopy, diel 5: Bacula en veeam-backup testen foar Linux
Reservekopy Diel 6: Fergeliking fan reservekopy-ark
Reservekopy Part 7: Konklúzjes
Pleatst troch: Pavel Demkovich
Boarne: www.habr.com