Kapasîteya Kapasîteyê (an wekî ku em jê re di hundurê Vim - captir de dibêjin) di rojên Veeam Backup and Replication 9.5 Update 4 de di bin navê Archive Tier de xuya bû. Fikra li pişt wê ev e ku meriv îmkanan bide paşvekişandina ku ji pencereya ku jê re jê re tê gotin vegerandina xebitandinê li hilanîna tiştan vediguhezîne. Vê yekê ji wan bikarhênerên ku hindik jê re hebûn re cîhê dîskê paqij kir. Û navê vê vebijêrkê Move Mode bû.

Ji bo pêkanîna vê çalakiya sade (wek ku xuya dike), bes bû ku du mercan bi cih bînin: hemî xalên ji paşvekêşana veguheztin divê li derveyî sînorên pencereya vegerandina xebitandinê ya jorîn be, ku bi eşkere di UI de hatî destnîşan kirin. Û ya duyemîn: zincîre divê bi navê "forma mohrkirî" be (zincîra paşvegirtinê ya mohrkirî an Zincîra Piştgiriya Neçalak). Ango bi demê re di vê zincîrê de ti guhertin çênabin.

Lê di VBR v10-ê de, têgeh bi fonksiyonên nû hate zêdekirin - Moda Kopîkirinê, Moda Girtî û tiştek bi navê dijwar-bilêvkirinê Immutability xuya bû.

Ev tiştên balkêş in ku em ê îro li ser biaxivin. Pêşîn, li ser ka ew çawa di VBR9.5u4 de xebitî, û dûv re jî li ser guhertinên di guhertoya dehemîn de.

Û bila şampiyonên zimanê pak li min biborin, lê gelek term hene ku nayên wergerandin.
Ji ber vê yekê dê li vir tonek Anglizîzmê hebe.
Û gelek gif.
Û wêne.

• Bê poşmaniyeke biçûk. Nivîskarê gotara.

Wekî ku bû

Welê, ka em bi analîzkirina pencereya vegerandina xebitandinê û paşvekêşana vegirtî (an jî wekî ku di belgeya Zencîreya Piştgiriya Neçalak de têne binav kirin) dest pê bikin. Bêyî têgihîştina wan, ravekirina bêtir ne gengaz e.

Wekî ku em di wêneyê de dibînin, me celebek zincîra paşvekişandinê ya bi blokên daneyê heye, ku li ser asta Performansê SOBR ya depoya ku Qada Kapasîteyê pê ve girêdayî ye cih digire. Pencereya paşvekêşana me ya xebitandinê sê roj e.

Li gorî vê yekê, .vbk-ya ku roja Duşemê hatî afirandin, zincîra berê, ku pencereya wê sê roj e, digire. Û ev tê vê wateyê ku hûn dikarin bi ewlehî dest bi veguheztina her tiştê ji van sê rojan kevintir berbi qada gulebaranê bikin.

Lê bi rastî mebesta zincîreyek mohrkirî çi bû û çi di nûvekirina 4-ê de dikare ji qada gulebaranê ya kapasîteyê re were şandin?

Pêşveçûna Zêdebûnê, nîşanek mohrkirina zincîrê çêkirina paşvekêşek tam a nû ye. Û ne girîng e ka ev paşvekêşana tam çawa tê wergirtin: hem paşpirtûkên tijî yên sentetîk hem jî yên çalak têne hesibandin.

Di doza Reverse de, ev hemî pelên ku nakevin pencereya xebitandinê ne.

Di mijara zêdekirina Pêş ve bi paşvekişandinê de, ev hemî paşveçûn in û .vbk in, heke di asta performansê de .vbkek din hebe.

Naha em vebijarka xebata bi zincîreyên Kopiya Backup-ê re bifikirin. Tenê tiştên ku di bin ragirtina GFS de ne li vir hatin veguhestin. Ji ber ku her tiştê ku di zincîreyên paşvekêşana nûtirîn de hatî hilanîn dikare bi rengek an din were guheztin.

Naha em li binê kulikê binêrin. Li wir, pêvajoyek bi navê dehydration diqewime - pelên paşvekêşanê yên vala li ser radeyê hiştin û blokan ji van pelan dikişîne ber qada gulebaranê. Ji bo xweşbînkirina vê pêvajoyê, bi navê index dehydration tê bikar anîn, ku dihêle hûn ji kopîkirina blokên ku berê li qada gulebarana kapasîteyê hatine kopî kirin dûr bixin.

Werin em bibînin ka ev bi mînakek çawa xuya dike: Em bibêjin ku me .vbk heye ku ji pencereya danûstendinê derketiye û aîdî zincîreke mohrkirî ye. Ev tê wê wateyê ku mafê me heye ku em wê biguhezînin qada gulebaranê ya kapasîteyê. Di dema barkirinê de, pelek metadata di kapasîteyê û blokên pelê veguhestî de tê afirandin. Pelê metadata-asta girêdanê diyar dike ku pelê me ji kîjan blokan pêk tê. Di rewşa di wêneyê de, pelê meya yekem ji blokên a, b, c pêk tê û metadata lînkên van blokan dihewîne. Dema ku pelek me ya duyemîn .vbk heye, amade ye ku hereket bike û ji blokên a, b û d pêk tê, em, bi analîzkirina nîşana dehydration, fam dikin ku tenê bloka d hewce ye ku were veguheztin. Û pelê metadata wê dê girêdanên du blokên berê û yek nû vehewîne.

Li gorî vê yekê, pêvajoya dagirtina van cihên vala paş bi daneyan re rehydration tê gotin. Ew jixwe pêveka xweya rehydration bikar tîne, li ser bingeha pelê herî kevn .vbk li ser asta performansa herêmî. Ango, heke bikarhêner bixwaze pelek ji qada gulebaranê ya kapasîteyê vegerîne, em pêşî navnîşek blokên paşgira tevahî ya herî kevn diafirînin û tenê blokên winda ji galeriya gulebarana kapasîteyê vediguhezînin. Di doza ku di wêneyê de hatî pêşkêş kirin de, ji bo ku em FullBackup1.vbk li gorî nîşana rehydrationê ji nû ve hîdro bikin, em tenê hewceyê bloka C-yê ne, ku em ji qada gulebaranê ya kapasîteyê digirin. Ger cewherek ewr a hilanînê wekî kapasîteya gulebaranê kar dike, ev dihêle hûn mîqdarên pir drav hilînin.

Li vir dibe ku xuya bibe ku ev teknolojî bi ya ku di WAN Accelerators de tê bikar anîn yek e, lê ew tenê wusa xuya dike. Di bilezkeran de, veqetandin gerdûnî ye; li vir, vekêşana herêmî di hundurê her pelê de bi rengek taybetî tête bikar anîn. Ev ji ber cûdahiya karên ku têne çareser kirin diqewime: Li vir pêdivî ye ku em pelên paşvekêşana mezin ên mezin kopî bikin, û li gorî lêkolîna me, tewra demek dirêj di navbera wan de derbas bibe jî, ev algorîtmaya veqetandinê encamek çêtirîn dide.

Lê ji bo xwedayê îndeksan bêtir îndeks! Ji bo vegerandina daneyan jî navnîşek heye! Dema ku em dest bi sererastkirina makîneyek ku di kapasîteyê de ye, em ê tenê blokên daneya yekta yên ku di tabloya performansê de ne bixwînin.

Çawa çêbû

Ew ji bo beşa destpêkê ye. Ew pir berfireh e, lê wekî ku li jor behs kir, bêyî van hûrguliyan dê nekare rave bike ka fonksiyonên nû çawa dixebitin. Ji ber vê yekê, bêyî hûrgulî, em biçin yekem.

Modeya kopî kirin

Ew bi piranî li ser teknolojiyên heyî ve girêdayî ye, lê mantiqek karanîna bi tevahî cûda hildigire. 

Armanca vê modê ew e ku pê ewle bibe ku hemî daneyên ku li ser asta herêmî ne kopiyek di kapasîteyê de heye.

Ger hûn modên Tevger û Kopî bi serê xwe bidin ber hev, ew ê weha xuya bike:

• Tenê zincîra morkirî dikare were guheztin. Di doza moda kopîkirinê de, bê guman her tişt tê veguheztin, bêyî ku di karê paşvekêşanê de çi diqewime.
• Dema ku pel ji sînorên pencereya hilanînê ya xebitandinê derbas dibin veguheztin dest pê dike, û gava ku pelê paşvekêşanê xuya bibe kopîkirin tê destpêkirin.
• Çavdêriya daneyên nû yên ji bo kopîkirinê bi domdarî pêk tê, û ji bo veguheztina wê her 4 demjimêran carekê hate destpêkirin.

Di nihêrîna moda nû de, ez pêşniyar dikim ku ji mînakên hêsan berbi yên tevlihev ve biçin.

Di rewşa herî gelemperî de, em tenê pelên nû yên bi zêdebûnê hene, û em wan bi tenê li qada gulebaranê ya kapasîteyê kopî dikin. Bêyî ku di karê hilanînê de kîjan mod tê bikar anîn, bêyî ku ew ji beşa zincîrê ya mohrkirî be an na, bêyî ku paceya xebitandina me qediyaye. Tenê ew girtin û kopî kirin.

Pêvajoya li pişt vê hîna jî dehydration e ku li jor hatî destnîşan kirin. Di moda kopîkirinê de, ew di heman demê de piştrast dike ku em blokên ku berê li ser hilanîna me ne kopî nakin. Cudahiya tenê ev e ku heke di moda fîlimê de me pelên rastîn bi pelên dummy veguherînin, li vir em bi tu awayî dest nadin wan û her tiştî wekî xwe dihêlin. Wekî din, ew tam heman nîşana dehydration e, ku bi baldarî hewl dide ku drav û wextê we xilas bike.

Pirs derdikeve holê - heke hûn li UI-yê mêze bikin, derfetek heye ku hûn di heman demê de herdu vebijarkan hilbijêrin. Dê modek wusa hevbeş çawa bixebite?

Ka em pê fêhm bikin.

Destpêk standard e: pelek hilanînê tê çêkirin û tavilê tê kopî kirin. Zêdebûnek jê re tê çêkirin û her weha tê kopî kirin. Ev diqewime heya dema ku em pê dihesin ku pel ji pencereya xebitandina me derketine û zincîrek mohrkirî xuya bûye. Di vê nuqteyê de em operasyonek dehydration pêk tînin û van pelan bi pelên dummy veguherînin. Bê guman, em dîsa tiştek li qada gulebaranê ya kapasîteyê kopî nakin.

Hemî ev mentiqê balkêş ji bo yek qutiyek kontrolê di navbeynê de berpirsiyar e: Heya ku têne çêkirin paşvekêşan li hilanîna tiştan kopî bikin.

Çima em hewceyê vê moda Kopîkirinê ne?

Hîn çêtir e ku meriv pirsê bi vî rengî ji nû ve bêje: em bi alîkariya wê ji kîjan xetereyan têne parastin? Kîjan pirsgirêk ji me re dibe alîkar ku em çareser bikin?

Bersiv eşkere ye: bê guman, ev vegerandina daneyê ye. Ger me kopiyek bêkêmasî ya daneyên herêmî yên li ser hilanînê tiştan hebe, wê hingê çi bi hilbera me re dibe bila bibe, em her gav dikarin daneyan ji pelên ku li Amazon-a şertûkirî ne vegerînin.

Ji ber vê yekê werin em senaryoyên gengaz derbas bibin, ji ya herî hêsan berbi tevlihevtir.

Bêbextiya herî hêsan a ku dikare bi ser serê me de bikeve negihîştina yek ji pelên di zincîra paşvekişînê de ye.

Çîrokek xemgîntir ew e ku yek ji depoya me ya SOBR têk çû.

Dema ku tevahiya depoya SOBR neçar dibe, lê qada gulebaranê ya kapasîteyê dixebite, hîn xirabtir dibe.
Û her tişt bi rastî xirab e - ev gava ku servera paşvekêşanê dimire û daxwaza weya yekem ev e ku hûn di deh hûrdeman de hewl bidin ku biçin sînorê Kanada.

Niha em li her rewşê cuda binêrin.

Gava ku me yek (û hetta çend) pelên paşvekişandinê winda kir, wê hingê ya ku divê em bikin ev e ku dest bi pêvajoya vegerandina depoyê bikin, û pelê winda dê bi pelek dummy were guheztin. Û bi karanîna pêvajoya rehydration (ya ku di destpêka gotarê de hate nîqaş kirin), bikarhêner dê bikaribe daneyên ji qada gulebaranê ya kapasîteyê dakêşîne hilanîna herêmî.

Niha rewş aloztir bûye. Ka em bihesibînin ku SOBR-a me ji du astên ku di moda Performansê de dixebitin pêk tê, ev tê vê wateyê ku .vbk û .vib-a me di qatek pir nehevdeng de li ser wan belav dibin. Û di demekê de, yek ji dereceyan nayê peyda kirin, û bikarhêner bi lez hewce dike ku makîneyê sererast bike, beşek ji daneya ku bi rastî li ser vê astê ye.

Bikarhêner sêrbazê vegerandinê dest pê dike, xala ku ew dixwaze sererast bike hildibijêre, û sêrbaz, dema ku dixebitî, têgihîşt ku hemî daneyên wî yên ku ji bo başbûnê li herêmî hewce ne hene û ji ber vê yekê pêdivî ye ku ji kapasîteya gulebaranê were dakêşandin. galerya. Di heman demê de, blokên ku li ser hilanîna herêmî dimînin dê ji ewr neyê dakêşandin. Rûmet ji navnîşa sererastkirinê re (erê, ew di destpêka gotarê de jî hate behs kirin).

Cûreyek vê dozê ev e ku tevahiya depoya SOBR neçar mabû. Di vê rewşê de, tiştek me tune ku em ji hilanîna herêmî kopî bikin, û hemî blokan ji ewr têne dakêşandin.

Û rewşa herî balkêş ev e ku servera hilanînê mir. Li vir du vebijark hene: admin mezin e û paşvekêşana veavakirinê çêkiriye, û rêveber bi xwe Pinocchioyek xirab e û paşvekêşana veavakirinê çênekiriye.

Di doza yekem de, ew ê bes be ku ew bi tenê sazkirinek paqij a VBR-ê li cîhek bicîh bike û databasa wê ji hilanînê bi karanîna amûrên standard vegerîne. Di dawiya vê pêvajoyê de, her tişt dê vegerin normalê. An jî ew ê li gorî yek ji senaryoyên jorîn were sererast kirin.

Lê heke admin an dijminê wî ye, an jî paşvekêşana mîhengê jî têkçûnek epîk dît, wê hingê li vir jî em ê wî nehêlin ber dilovaniya qederê. Ji bo vê rewşê, me pêvajoyek nû bi navê Import Object Storage destnîşan kir. Ew destûrê dide te ku hûn pêvajoya ji nû veavakirina depoyek SOBR bi destan bavêjin û bi paşvekêşana paşîn re kapasîteya gulebaranê bi wê ve girêbidin, û bi tenê tiştek hilanînê li navbeynkariya Vim zêde bikin û prosedûra Depoya Hilgirtina Import bimeşînin. Tişta ku dikare di navbera we û paşkêşên we de rê li ber bigire ev e ku daxwazek e ku hûn şîfreyek têkevin ger paşkêşên we hatine şîfre kirin.

Dibe ku ev hemî li ser Moda Kopîkirinê ye û em diçin

Moda mohrkirî

Fikra sereke ev e ku paşvekêşên nû nikarin li ser hêleya SOBR ya hilbijartî ya depoyê xuya bibin. Berî v10, me tenê Moda Maintenance hebû, dema ku her karek bi depoyê re bi tevahî qedexe bû. Cûreyek moda hişk a ji bo girtina hilanînê, ku tenê bişkoja Evacuate heye, ku yek carî paşvekêşan vediguhezîne deverek din.

Û moda Sealed celebek vebijarkek "nerm" e: em çêkirina paşkêşên nû qedexe dikin û hêdî hêdî yên kevn li gorî hilbijartî jêbirin, lê di vê pêvajoyê de em kapasîteya vegerandina ji xalên hilandî winda nakin. Tiştek pir bikêr gava ku me an perçeyek zencîreyê heye ku nêzîkê dawiya jiyana xwe ye û pêdivî ye ku em wê biguhezînin, an jî em tenê hewce ne ku wê ji bo tiştek girîngtir azad bikin, lê cîhek tune ku em wê bigirin û her tiştî bi yekcarî biguhezînin. An jî nayê jêbirin.

Li gorî vê yekê, prensîba xebitandinê pir hêsan e: pêdivî ye ku hemî operasyonên nivîsandinê (xuyana daneya nû), hiştina xwendinê (restorasyon) û jêbirinê (vegirtin) qedexe bikin.

Her du awayan dikarin bi hevdemî werin bikar anîn, lê ji bîr mekin ku Maintenance xwedan pêşînek bilindtir e.

Wek nimûne, SOBR-ê ku ji du astê pêk tê binirxînin. Em bihesibînin ku di çar rojên pêşîn de me di moda Pêşveçûn Herheyî Zêdebûnê de paşgir çêkirine, û dûv re em derecê mohr dikin. Ev dibe sedem ku em dest bi afirandina çalakiyek nû ya tevahî li ser asta duyemîn a berdest dikin. Ger ragirtina me çar be, wê hingê gava ku tevahiya zincîra ku li ser deverek mohrkirî ye ji sînorên xwe derbas dibe, bi wijdanek paqij tê jêbirin.

Rewşên ku jêbirin berê pêk tê hene. Mînakî, ev bi tijîkirina perîyodîk zêdebûnek Pêşverû ye. Ger me di du rojên pêşîn de paşgirek tam çêkir, û roja Pêncşemê jî em biryar didin ku depoyê mohr bikin, wê hingê roja Îniyê, dema ku paşgirek nû were çêkirin, pelê ji bo Duşemê dê were jêbirin ji ber ku ne girêdayî vê xalê hene. Û xal bi xwe jî ne girêdayî kesî ye. Dûv re em li bendê ne ku çar xal li ser dereceya berdest werin afirandin û sêyên mayî, yên ku ji hev serbixwe nayên jêbirin, jêbirin.

Tişt bi Reverse Incremental re hêsantir in. Di wê de, xalên herî kevn bi tiştek ve girêdayî ne û dikarin bi ewlehî werin jêbirin. Ji ber vê yekê, gava ku .vbkek nû li ser radeyek nû were afirandin, dê .vrbên kevn yek bi yek werin jêbirin.

Bi awayê, çima em her carê .vbkek nû diafirînin: heke me ew neafiranda, lê zincîra kevin a zêdebûnê bidomanda, wê hingê .vbk-ya kevn dê di her modê de demek bêsînor dicemidîne, û rê li jêbirina wê bigire. Ji ber vê yekê, biryar hate girtin ku bi qasî ku rade were mohrkirin, em li ser radeya belaş kopiyek tam çêbikin.

Tişt bi kapasîteya gulebaranê re tevlihevtir in.

Pêşîn, em li moda kopîkirinê binêrin. Ka em bihesibînin ku me çar rojan bi rengek çalak paşvekêşan diafirand, û dûv re qada gulebaranê ya kapasîteyê hate mohrkirin. Em tiştek jê nakin, lê bi dilnizmî ragirtinê radigirin, piştî ku em daneyan ji qada gulebaranê ya kapasîteyê jê dikin.

Nêzîkî heman tişt di moda tevgerê de diqewime - em li benda retûşê ne, ya kevin di hilana herêmî de jêbirin, û yê ku di hilanîna tiştan de hatî hilanîn jêbirin.

Nimûneyek balkêş bi Forever pêşdeçûnek zêde. Em ragirtinê li sê xalan saz dikin û roja Duşemê dest bi çêkirina paşgiran dikin, ku bi rêkûpêk li ewr têne kopî kirin. Piştî mohrkirina hilanînê, paşvekêşan berdewam têne afirandin, sê xalan diparêzin, lê daneyên ku di kapasîteyê de hatine hilanîn girêdayî dimîne û nayê jêbirin. Ji ber vê yekê, em li benda roja Pêncşemê ne, gava ku .vbk me ji ragirtinê derbas dibe, û tenê wê hingê em bi aramî zincîra rizgarkirî jêbirin.

Û nerazîbûnek piçûk: hemî nimûneyên li vir bi yek makîneyê têne destnîşan kirin. Ger çend ji wan di hilgirtina we de hebin, wê hingê retoşa wan li gorî ku Active Full hatî çêkirin an na cûda dibe.

Ew di bingeh de her tişt heye. Ji ber vê yekê em biçin taybetmendiya herî hişk -

Neguhêrbar

Mîna xalên berê, ya yekem ev e ku ev fonksiyon çi pirsgirêkê çareser dike. Hema ku em paşkêşên xwe li cîhek ji bo hilanînê bar dikin, daxwazek xurt heye ku em ewlehiya wan garantî bikin, ango, bi fizîkî jêbirina wan û her guhertinek di dema ragirtinek diyar de qedexe bikin. Di nav wan de rêveberan, di bin hesabên wan ên root de jî. Ev rê dide we ku hûn wan ji zirara qezayî an bi mebest biparêzin. Her kesê ku bi AWS-ê re dixebite dibe ku rastî taybetmendiyek wusa bi navê Object Lock hatibe.

Naha em li modê bi gelemperî binihêrin, û dûv re li hûrguliyan bigerin. Di mînaka me de, Immutability dê ji bo kapasîteya meya gulebaranê bi girtina çar rojan were çalak kirin. Û moda Kopîkirinê di hilanînê de çalak e.

Neguherbarî bi ti awayî bi ragirtina giştî re têkilî nake. Mînakî, ew xalên zêde an jî tiştek wusa zêde nake. Tenê ew e ku kesek nikare pelên hilanînê di nav çar rojan de jê bibe. Ger hûn roja Duşemê kopiyek çêbikin, hûn ê tenê roja Îniyê karibin pelê wê jêbikin.

Hemî têgehên berê yên ravekirî yên dehydration, index û metadata bi heman rengî berdewam dikin. Lê bi yek şertê - blok ne tenê ji bo daneyan, lê di heman demê de ji bo metadata jî tê danîn. Ev tê kirin heke êrîşkarek xapînok biryar bide ku databasa metadata me ji holê rake û pêşî li blokên daneyê bigire ku veguhere mûşeka binary ya bêkêr.

Naha demek girîng e ku em teknolojiya hilberîna bloka xwe rave bikin. An nifşê blokê. Ji bo vê yekê, rewşa ku bûye sedema xuyabûna wê bifikirin.

Werin em pîvanek demê ya şeş rojan bigirin û li jêr em ê dema bidawîbûna bendewariya neguhêrbariyê destnîşan bikin. Di roja yekem de em pelek ku ji bloka daneyê a û metadata wê pêk tê digirin û diafirînin. Ger neguhêrbarî sê rojan were danîn, mentiqî ye ku meriv texmîn bike ku di roja çaremîn de dê dane bêne vekirin û jêbirin. Di roja duyemîn de em ê pelek2 nû, ku ji blokek b bi heman mîhengan pêk tê, lê zêde bikin. Pêdivî ye ku bloka a hê jî di roja çaremîn de were rakirin. Lê roja sêyemîn tiştek tirsnak diqewime - pelek File3 tê afirandin, ku ji blokek nû d û girêdanek bi bloka kevn a pêk tê. Ev tê vê wateyê ku ji bo blokek û ala wê ya neguhêrbar divê ji nû ve were vegerandin, ku ew di roja şeşan de tê guheztin. Û li vir pirsgirêkek derdikeve - di paşkêşên rastîn de hejmareke mezin ji blokên weha hene. Û ji bo dirêjkirina heyama neguhêrbariya wan, hûn hewce ne ku her carê hejmareke mezin daxwaz bikin. Û bi rastî, ev ê bibe pêvajoyek rojane ya hema hema bêdawî, ji ber ku bi îhtimalek mezin em ê bi her kopiyekê re stûnên giran ên blokên jêhatî bibînin. Wateya hejmareke mezin a daxwazên ji pêşkêşkerên hilanîna tiştan çi ye? Rast! Di dawiya mehê de fatûreya mezin.

Û ji bo ku hûn xerîdarên xweyên bijare ji bo dravê girîng eşkere nekin, mekanîzmaya hilberîna blokê hate kifş kirin. Ev serdemek pêvek e ku em li serdema neguhêrbariya diyarkirî zêde dikin. Di nimûneya jêrîn de, ev dem du roj e. Lê ev tenê mînakek e. Di rastiyê de, ew formula xwe bikar tînin, ku bi qasî deh rojên din di dema girtina mehane de dide.

Ka em heman rewşê berdewam bikin, lê bi nifşa blokê. Di roja yekem de em pelê1 ji bloka a û metadata diafirînin. Em serdema nifş û neguhêrbariyê zêde dikin - ev tê vê wateyê ku fersenda jêbirina pelê dê di roja şeşemîn de be. Ger di roja duyemîn de em Pelê2, ku ji bloka b û girêdanek astengkirina a pêk tê biafirînin, wê hingê tiştek bi dîroka jêbirina çaverêkirî re çênabe. Ew wek roja şeşan rawesta. Û bi vî awayî em hewl didin ku drav li ser hejmara daxwazan teserif bikin. Rewşa yekane dema ku muhlet dikare were guheztin ev e ku heyama nifşê qediyaye. Ango, heke di roja sêyemîn de pelê3-a nû zencîreyek ji bo astengkirina a-yê dihewîne, wê hingê dê nifşê 2 were zêdekirin ji ber ku Gen1 jixwe qediyaye. Û tarîxa çaverêkirî ya jêbirina bloka a dê di roja heştemîn de biçe. Ev rê dide me ku em bi awayekî dramatîk hejmara daxwazan kêm bikin da ku emrê blokên jêhatî dirêj bikin, ku ji xerîdaran tonek drav xilas dike.

Teknolojî bixwe ji bikarhênerên hardware S3 û S3 re peyda dibe, ku çêkerên wan garantî dikin ku pêkanîna wan ji Amazon-ê cûda nabe. Ji ber vê yekê bersiva pirsa rewa çima çima Azure nayê piştgirî kirin - wan taybetmendiyek wusa heye, lê ew di asta konteyneran de dixebite, ne tiştên kesane. Bi awayê, Amazon bixwe di du awayan de girtina objektê heye: hevgirtin û rêveberî. Di bûyera duyemîn de, îhtîmalek heye ku rêvebirê herî mezin li jor admînan û root li jorê kok, tevî qefila objektê, dîsa jî daneyan jêbirin. Di doza lihevhatinê de, her tişt bi zexmî ve girêdayî ye û kes nikare paşkêşan jê bibe. Tewra rêvebirên Amazon jî (li gorî daxuyaniyên wan ên fermî). Ev moda ku em piştgirî dikin.

Û, wekî gelemperî, hin girêdanên kêrhatî:

• li ser Block Generation bi her hûrgulî.
• Hemî agahdarî li ser Veeam Backup & Replication 10 di baştirîn xwe de
• О Kapasîteya Tier bi hûrgulî

Source: www.habr.com