Ev gotar dê nermalava hilanînê binirxîne ku, bi şkandina herikîna daneyê li pêkhateyên cihê (çiçikan), depoyek çêdike.
Parçeyên depoyê dikarin bêtir werin pêçandin û şîfrekirin, û ya herî girîng - di dema pêvajoyên paşvegirtinê yên dubare de - ji nû ve werin bikar anîn.
Kopiyek paşvekêşanê di depoyek wusa de zincîreyek binavkirî ya pêkhateyan e ku bi hevûdu ve girêdayî ye, mînakî, li ser bingeha fonksiyonên haş ên cihêreng.
Gelek çareseriyên wekhev hene, ez ê li ser 3 bisekinim: zbackup, borgbackup û restic.
Encamên hêvîdar
Ji ber ku hemî serlêder bi rengekî an rêyek din hewceyê çêkirina depoyek hewce dikin, yek ji faktorên herî girîng dê texmînkirina mezinahiya depoyê be. Bi îdeal, mezinahiya wê divê li gorî metodolojiya pejirandî ji 13 GB zêdetir nebe, an jî kêmtir be - bi xweşbîniyek baş ve girêdayî ye.
Di heman demê de pir tê xwestin ku meriv rasterast bêyî karanîna arşîvên mîna tar, û her weha bêyî amûrên zêde yên wekî rsync û sshfs bi ssh/sftp-ê re bixebite, kopiyên hilanînê yên pelan rasterast biafirîne.
Tevger dema çêkirina paşgiran:
- Mezinahiya depoyê dê bi mezinahiya guhertinan re, an kêmtir be.
- Dema ku berhevkirin û/an şîfrekirinê tê bikar anîn barkirina CPU-ya giran tê çaverê kirin, û heke pêvajoya arşîvkirin û/an şîfrekirinê li ser serverek hilanînê ya paşvekişandinê dimeşîne, barkirina torê û dîskê pir zêde dibe.
- Ger depo xera bibe, hem dema çêkirina paşvekêşên nû û hem jî dema ku hewl didin vegerandin xeletiyek dereng dibe. Pêdivî ye ku tedbîrên zêde were plansaz kirin da ku yekdestiya depoyê piştrast bike an jî amûrên çêkirî yên ji bo kontrolkirina yekdestiya wê bikar bînin.
Karkirina bi tar wekî nirxek referansê tête girtin, wekî ku di yek ji gotarên berê de hate destnîşan kirin.
Testkirina zbackup
Mekanîzmaya giştî ya zbackupê ev e ku bername di nav deverên herikîna daneya têketinê de ku heman daneyan tê de peyda dike, dûv re vebijarkî wan berhev dike û şîfre dike, her deverê tenê carekê tomar dike.
Deduplication fonksiyonek zengilê ya 64-bit bi pencereyek xêzkirî bikar tîne da ku lihevhatinên byte-bi-byte li hember blokên daneya heyî kontrol bike (wek çawa rsync wê bicîh tîne).
lzma û lzo-ya pir-têlkirî ji bo pêgirtinê, û aes ji bo şîfrekirinê têne bikar anîn. Guhertoyên herî dawî xwedî kapasîteya ku di pêşerojê de daneyên kevn ji depoyê jêbirin.
Bername di C++ de bi girêdayiyên hindiktirîn ve hatî nivîsandin. Xuya ye ku nivîskar ji riya unix-ê îlham girtiye, ji ber vê yekê bername dema ku paşvekêşan diafirîne daneya stdin-ê qebûl dike, di stdout-ê de dema nûvekirinê danûstendinek daneya wekhev çêdike. Ji ber vê yekê, zbackup dikare wekî "bloka avahîsaziyê" pir baş were bikar anîn dema ku çareseriyên paşvekêşana xwe dinivîse. Mînakî, nivîskarê gotarê ji 2014-an vir ve vê bernameyê wekî amûra bingehîn a paşîn ji bo makîneyên malê bikar aniye.
Heya ku wekî din neyê gotin dê herikîna daneyê tariyek birêkûpêk be.
Ka em bibînin ka encam çi ne:
Kar di 2 vebijarkan de hate kontrol kirin:
- depoyek tê çêkirin û zbackup bi daneyên çavkaniyê li ser serverê tê destpêkirin, dûv re naveroka depoyê vediguhezîne servera hilanînê ya hilanînê.
- depoyek li ser servera hilanînê ya hilanînê tê çêkirin, zbackup bi ssh-ê li ser servera hilanînê ya hilanînê tê destpêkirin, û daneyên bi boriyê jê re têne şandin.
Encamên vebijarka yekem wiha bûn: 43m11s - dema ku depoyek neşîfrekirî û kompresorê lzma bikar tînin, 19m13s - dema ku kompresor bi lzo veguherînin.
Barkirina serverê bi daneya orîjînal re wiha bû (mînakek bi lzma tê xuyang kirin; bi lzo re hema hema heman wêne hebû, lê parvekirina rsync hema hema çaryek bû):
Eşkere ye ku pêvajoyek hilanînê ya weha tenê ji bo guhertinên kêm kêm û piçûk maqûl e. Di heman demê de pir tê pêşniyar kirin ku zbackup bi 1 mijarê ve were sînorkirin, wekî din dê barek CPU-ya pir zêde hebe, ji ber ku Bername di xebata di gelek mijaran de pir baş e. Barkirina li ser dîskê piçûk bû, ku bi gelemperî bi bine-pergala dîskê-based ssd-ya nûjen nayê dîtin. Her weha hûn dikarin bi zelalî destpêkirina pêvajoya hevdengkirina daneya depoyê bi serverek dûr re bibînin; Leza xebitandinê bi rsync-a birêkûpêk re tête berhev kirin û bi performansa binepergala dîskê ya servera hilanînê ya hilanînê ve girêdayî ye. Kêmasiya vê nêzîkbûnê hilanîna depoyek herêmî ye û, wekî encam, dubarekirina daneyan e.
Di pratîkê de balkêştir û bikêrhatîtir vebijarka duyemîn e, ku zbackup rasterast li ser servera hilanîna hilanînê dimeşîne.
Pêşîn, em ê operasyonê bêyî karanîna şîfrekirinê bi kompresora lzma biceribînin:
Dema xebitandina her ceribandinê:
Destpêkirin 1
Destpêkirin 2
Destpêkirin 3
39 m45s
40 m20s
40 m3s
7 m36s
8 m3s
7 m48s
15 m35s
15 m48s
15 m38s
Ger hûn şîfrekirinê bi karanîna aes çalak bikin, encam pir nêzîk in:
Dema xebitandinê li ser heman daneyê, bi şîfrekirinê:
Destpêkirin 1
Destpêkirin 2
Destpêkirin 3
43 m40s
44 m12s
44 m3s
8 m3s
8 m15s
8 m12s
15 m0s
15 m40s
15 m25s
Ger şîfrekirin bi lzo-ê re bi pêvekirinê re were hev kirin, wusa xuya dike:
Karên xebatê
Destpêkirin 1
Destpêkirin 2
Destpêkirin 3
18 m2s
18 m15s
18 m12s
5 m13s
5 m24s
5 m20s
8 m48s
9 m3s
8 m51s
Mezinahiya depoya encam bi 13 GB re bi heman rengî bû. Ev tê vê wateyê ku deduplication rast dixebite. Di heman demê de, li ser daneyên ku ji berê ve hatine pêçandî, karanîna lzo bandorek berbiçav dide; di warê dema xebitandinê ya tevahî de, zbackup nêzîkê dubendî / ducarî dibe, lê 2-5 carî li pişt wan ên ku li ser librsync-ê têne damezrandin XNUMX-XNUMX carî paşde dimîne.
Feydeyên diyar in - tomarkirina cîhê dîskê li ser servera hilanînê ya hilanînê. Wekî ku ji bo amûrên kontrolkirina depoyê, nivîskarê zbackup wan peyda nake; tê pêşniyar kirin ku meriv komek dîskê an pêşkêşkerek ewr a toleransê bikar bîne.
Bi tevayî, bandorek pir baş, tevî vê yekê ku proje nêzî 3 sal in sekinî ye (daxwaza taybetmendiya paşîn nêzî salek berê bû, lê bê bersiv).
Testkirina borgbackup
Borgbackup perçek ji attic e, pergalek din a mîna zbackup. Di python de hatî nivîsandin, navnîşek jêhatîbûnên mîna zbackup-ê heye, lê di heman demê de dikare:
- Piştgiran bi sîgorteyê ve girêdin
- Naveroka depoyê kontrol bikin
- Di moda xerîdar-server de bixebitin
- Ji bo daneyan kompresorên cihêreng bikar bînin, û hem jî dema berhevkirina pelê wê diyar bikin.
- 2 vebijarkên şîfrekirinê, aes û blake
- Amûrek çêkirî ji bo
kontrolên performansê
pîvana borgbackup crud ssh://backup_server/repo/path local_dir
Encam wiha bûn:
CZ-BIG 96.51 MB/s (10 100.00 MB pelên hemî-sifir: 10.36s)
RZ-BIG 57.22 MB/s (10 100.00 MB pelên hemî-sifir: 17.48s)
UZ-BIG 253.63 MB/s (10 100.00 MB pelên hemî-sifir: 3.94s)
DZ-BIG 351.06 MB/s (10 100.00 MB pelên hemî-sifir: 2.85s)
CR-BIG 34.30 MB/s (10 100.00 MB pelên tesadufî: 29.15s)
RR-BIG 60.69 MB/s (10 100.00 MB pelên tesadufî: 16.48s)
UR-BIG 311.06 MB/s (10 100.00 MB pelên tesadufî: 3.21s)
DR-BIG 72.63 MB/s (10 100.00 MB pelên tesadufî: 13.77s)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB pelên hemî-sifir: 9.21s)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB pelên hemî-sifir: 13.13s)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB pelên hemî-sifir: 3.02s)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB pelên hemî-sifir: 2.58s)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB pelên tesadufî: 26.45s)
RR-MEDIUM 68.90 MB/s (1000 1.00 MB pelên tesadufî: 14.51s)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB pelên tesadufî: 2.88s)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB pelên tesadufî: 20.49s)
CZ-BIÇÛK 11.72 MB/s (10000 10.00 kB pelên hemî-sifir: 8.53s)
RZ-BIÇÛK 32.57 MB/s (10000 10.00 kB pelên hemî-sifir: 3.07s)
UZ-BIÇÛK 19.37 MB/s (10000 10.00 kB pelên hemî-sifir: 5.16s)
DZ-BIÇÛK 33.71 MB/s (10000 10.00 kB pelên hemî-sifir: 2.97s)
CR-BIÇÛK 6.85 MB/s (10000 10.00 kB pelên tesadufî: 14.60s)
RR-BIÇÛK 31.27 MB/s (10000 10.00 kB pelên tesadufî: 3.20s)
UR-BIÇÛK 12.28 MB/s (10000 10.00 kB pelên tesadufî: 8.14s)
DR-BIÇÛK 18.78 MB/s (10000 10.00 kB pelên tesadufî: 5.32s)
Dema ceribandinê, heurîstîkên kompresyonê dê ji bo destnîşankirina celebê pelê (otokompression) were bikar anîn, û encam dê wiha bin:
Pêşîn, bila em kontrol bikin ka ew bêyî şîfrekirinê çawa dixebite:
Karên xebatê
Destpêkirin 1
Destpêkirin 2
Destpêkirin 3
4 m6s
4 m10s
4 m5s
56s
58s
54s
1 m26s
1 m34s
1 m30s
Ger hûn destûra depoyê çalak bikin (moda pejirandî), encam dê nêzîk bin:
Karên xebatê
Destpêkirin 1
Destpêkirin 2
Destpêkirin 3
4 m11s
4 m20s
4 m12s
1 m0s
1 m3s
1 m2s
1 m30s
1 m34s
1 m31s
Dema ku şîfrekirina aes hate çalak kirin, encam pir xirab nebûn:
Destpêkirin 1
Destpêkirin 2
Destpêkirin 3
4 m55s
5 m2s
4 m58s
1 m0s
1 m2s
1 m0s
1 m49s
1 m50s
1 m50s
Û heke hûn aes bi blake biguherînin, rewş dê bi tevahî baştir bibe:
Karên xebatê
Destpêkirin 1
Destpêkirin 2
Destpêkirin 3
4 m33s
4 m43s
4 m40s
59s
1 m0s
1 m0s
1 m38s
1 m43s
1 m40s
Mîna ku di doza zbackup de, mezinahiya depoyê 13 GB û hetta piçek kêmtir bû, ku bi gelemperî tê hêvî kirin. Ez ji dema xebitandinê pir kêfxweş bûm; ew bi çareseriyên li ser bingeha librsync-ê ve têne berhev kirin, kapasîteyên pir berfireh peyda dike. Di heman demê de ez ji şiyana danîna pîvanên cihêreng bi navgîniya guhêrbarên hawîrdorê jî kêfxweş bûm, ku dema ku borgbackup-ê di moda otomatîk de bikar tîne feydeyek pir ciddî dide. Di dema hilanînê de ez ji barkirinê jî kêfxweş bûm: li gorî barkirina pêvajoyê dadbar kirin, borgbackup di 1 mijarê de dixebite.
Di dema karanîna wê de kêmasiyên taybetî tune bûn.
testkirina restîk
Tevî vê rastiyê ku restic çareseriyek pir nû ye (2 berendamên yekem di sala 2013-an de û kevntir hatin nas kirin), ew xwedan taybetmendiyên pir baş e. Di Go de hatî nivîsandin.
Dema ku bi zbackupê re tê berhev kirin, ew pêve jî dide:
- Kontrolkirina yekrêziya depoyê (tevî kontrolkirina parçeyan).
- Navnîşek mezin a protokol û pêşkêşkerên piştgirîkirî yên ji bo hilanîna paşgiran, û her weha piştgirî ji bo rclone - rsync ji bo çareseriyên ewr.
- Berhevdana 2 paşkêşan bi hev re.
- Mountkirina depoyê bi sîgorteyê.
Bi gelemperî, navnîşa taybetmendiyan pir nêzîkê borgbackup e, li hin deveran pirtir, li yên din kêmtir e. Yek ji wan taybetmendiyan ev e ku rêyek tune ku şîfrekirinê neçalak bike, û ji ber vê yekê kopiyên hilanînê dê her gav werin şîfre kirin. Ka em di pratîkê de bibînin ka çi dikare ji vê nermalavê were derxistin:
Encam wiha bûn:
Karên xebatê
Destpêkirin 1
Destpêkirin 2
Destpêkirin 3
5 m25s
5 m50s
5 m38s
35s
38s
36s
1 m54s
2 m2s
1 m58s
Encamên performansê di heman demê de bi çareseriyên bingehîn ên rsync-ê re û, bi gelemperî, pir nêzikî borgbackup-ê jî têne berhev kirin, lê barkirina CPU-yê bilindtir e (gelek kêşan dimeşin) û diranan.
Bi îhtîmalek mezin, bername ji hêla performansa binepergala dîskê ya li ser servera hilanîna daneyê ve, wekî ku berê bi rsync-ê re bû, sînordar e. Mezinahiya depoyê 13 GB bû, mîna zbackup an borgbackup, di dema karanîna vê çareseriyê de dezawantajên diyar tune.
Encam
Bi rastî, hemî berendaman encamên wekhev, lê bi bihayên cûda bi dest xistin. Borgbackup ji her tiştî çêtirîn pêk anî, restix hinekî hêdîtir bû, zbackup belkî ne hêja ye ku meriv dest bi karanîna xwe bike,
û heke ew jixwe tê bikar anîn, biceribînin ku wê biguhezînin borgbackup an restic.
vebiguherin
Çareseriya herî sozdar xuya dike ku mayînde ye, ji ber ku ... ew e ku xwedan rêjeya çêtirîn kapasîteyên bi leza xebitandinê ye, lê em ji bo naha lez nekin encamên gelemperî.
Borgbackup di bingeh de ne xirabtir e, lê zbackup dibe ku çêtir were guheztin. Rast e, zbackup hîn jî dikare were bikar anîn da ku qaîdeya 3-2-1 bixebite. Mînakî, ji bilî (lib)rsync-based tesîsên hilanînê.
Daxûyanî
Backup, beş 5: Ceribandina bacula û veeam vegerandina ji bo linux
Backup Part 6: Berawirdkirina Amûrên Piştgiriyê
Backup Part 7: Encam
Ji hêla: Pavel Demkovich
Source: www.habr.com