Roedd Haen Cynhwysedd (neu fel yr ydym yn ei alw y tu mewn i Vim - captir) yn ymddangos yn ôl yn nyddiau Veeam Backup and Replication 9.5 Diweddariad 4 o dan yr enw Archif Haen. Y syniad y tu ôl iddo yw ei gwneud hi'n bosibl symud copïau wrth gefn sydd wedi disgyn allan o'r ffenestr adfer weithredol fel y'i gelwir i storio gwrthrychau. Helpodd hyn i glirio lle ar ddisg i'r defnyddwyr hynny nad oedd ganddynt lawer ohono. A'r enw ar yr opsiwn hwn oedd Modd Symud.

Er mwyn cyflawni'r weithred syml hon (fel y mae'n ymddangos), roedd yn ddigon i fodloni dau amod: rhaid i bob pwynt o'r copi wrth gefn a symudwyd fod y tu allan i ffiniau'r ffenestr adfer weithredol uchod, sydd wedi'i gosod yn benodol yn yr UI. Ac yn ail: rhaid i'r gadwyn fod yn yr hyn a elwir yn “ffurf wedi'i selio” (cadwyn wrth gefn wedi'i selio neu Gadwyn Wrth Gefn Anweithredol). Hynny yw, nid oes unrhyw newidiadau yn digwydd yn y gadwyn hon dros amser.

Ond yn VBR v10, ychwanegwyd swyddogaethau newydd at y cysyniad - Modd Copi, Modd Wedi'i Selio a pheth gyda'r enw anodd ei ynganu Ymddangosodd Immutability.

Dyma'r pethau hynod ddiddorol y byddwn yn siarad amdanynt heddiw. Yn gyntaf, am sut y bu'n gweithio yn VBR9.5u4, ac yna am y newidiadau yn y degfed fersiwn.

A boed i bencampwyr iaith bur faddau i mi, ond mae gormod o dermau na ellir eu cyfieithu.
Felly bydd tunnell o Seisnigrwydd yma.
A llawer o gifs.
A lluniau.

• Heb y difaru lleiaf. Awdur yr erthygl.

Fel yr oedd

Wel, gadewch i ni ddechrau trwy ddadansoddi'r ffenestr adfer gweithredol a'r copi wrth gefn wedi'i selio (neu fel y'u gelwir yn y ddogfennaeth Cadwyn Wrth Gefn Anweithredol). Heb eu dealltwriaeth, ni fydd esboniad pellach yn bosibl.

Fel y gwelwn yn y llun, mae gennym fath o gadwyn wrth gefn gyda blociau data, sydd wedi'i lleoli ar haen Perfformiad SOBR yr ystorfa y mae'r Haen Cynhwysedd yn gysylltiedig â hi. Tri diwrnod yw ein ffenestr wrth gefn weithredol.

Yn unol â hynny, mae'r .vbk a grëwyd ddydd Llun yn selio'r gadwyn flaenorol, y mae ei ffenestr wedi'i gosod i dri diwrnod. Ac mae hynny'n golygu y gallwch chi ddechrau cludo popeth sy'n hŷn na'r tridiau hyn i'r maes saethu yn ddiogel.

Ond beth yn union a olygwyd gan gadwyn wedi'i selio a beth y gellid ei anfon at yr ystod saethu capasiti yn diweddariad 4?

Ar gyfer Forward Incremental, arwydd o selio'r gadwyn yw creu copi wrth gefn llawn newydd. Ac nid oes ots sut y ceir y copi wrth gefn llawn hwn: ystyrir copïau wrth gefn llawn synthetig a gweithredol.

Yn achos Reverse, mae'r rhain i gyd yn ffeiliau nad ydynt yn disgyn i'r ffenestr weithredu.

Yn achos cynyddran Forward gyda threigliadau, mae'r rhain i gyd yn dreigliadau a .vbk, os oes .vbk arall ar y graddau perfformiad

Nawr, gadewch i ni ystyried yr opsiwn o weithio gyda chadwyni Copi Wrth Gefn. Dim ond eitemau sy'n dod o dan gadw GFS a gludwyd yma. Oherwydd gall popeth sy'n cael ei storio mewn cadwyni copi wrth gefn mwy diweddar gael ei newid mewn un ffordd neu'r llall.

Nawr gadewch i ni edrych o dan y cwfl. Yno, mae proses o'r enw dadhydradu yn digwydd - gan adael ffeiliau wrth gefn gwag ar y graddau a llusgo blociau o'r ffeiliau hyn i'r ystod saethu gallu. Er mwyn gwneud y gorau o'r broses hon, defnyddir y mynegai dadhydradu fel y'i gelwir, sy'n eich galluogi i osgoi copïo blociau sydd eisoes wedi'u copïo i'r ystod saethu gallu.

Gadewch i ni weld sut olwg sydd ar hyn gydag enghraifft: Gadewch i ni ddweud bod gennym ni .vbk a ddaeth allan o'r ffenestr trafodiad ac sy'n perthyn i gadwyn wedi'i selio. Mae hyn yn golygu bod gennym bob hawl i'w symud i'r ystod saethu capasiti. Ar adeg symud, crëir ffeil metadata yn y llinell doriad cynhwysedd a blociau'r ffeil a drosglwyddwyd. Mae'r ffeil metadata lefel cyswllt yn disgrifio beth mae blociau ein ffeil yn ei gynnwys. Yn yr achos yn y llun, mae ein ffeil gyntaf yn cynnwys blociau a, b, c ac mae'r metadata yn cynnwys dolenni i'r blociau hyn. Pan fydd gennym ail ffeil .vbk, yn barod i'w symud ac yn cynnwys blociau a, b a d, rydym ni, wrth ddadansoddi'r mynegai dadhydradu, yn deall mai dim ond bloc d sydd angen ei drosglwyddo. A bydd ei ffeil metadata yn cynnwys dolenni i ddau floc blaenorol ac un newydd.

Yn unol â hynny, gelwir y broses o lenwi'r lleoedd gwag hyn yn ôl â data yn ailhydradu. Mae eisoes yn defnyddio ei fynegai ailhydradu ei hun, yn seiliedig ar y ffeil .vbk hynaf ar raddfa perfformiad lleol. Hynny yw, os yw'r defnyddiwr eisiau dychwelyd ffeil o'r ystod saethu gallu, rydym yn gyntaf yn creu mynegai o flociau'r copi wrth gefn llawn hynaf ac yn trosglwyddo'r blociau coll yn unig o'r oriel saethu gallu. Yn yr achos a gyflwynir yn y llun, er mwyn ailhydradu FullBackup1.vbk yn ôl y mynegai ailhydradu, dim ond bloc C sydd ei angen arnom, yr ydym yn ei gymryd o'r ystod saethu gallu. Os yw gwrthrych cwmwl storio yn gweithredu fel ystod saethu gallu, mae hyn yn caniatáu ichi arbed symiau enfawr o arian.

Yma efallai ei bod yn ymddangos bod y dechnoleg hon yn union yr un fath â'r un a ddefnyddir yn Cyflymyddion WAN, ond mae'n ymddangos felly. Mewn cyflymyddion, mae dad-ddyblygu yn fyd-eang; yma, defnyddir dad-ddyblygu lleol o fewn pob ffeil ar wrthbwyso penodol. Mae hyn yn digwydd oherwydd y gwahaniaeth yn y tasgau sy'n cael eu datrys: yma mae angen i ni gopïo ffeiliau wrth gefn llawn mawr, ac yn ôl ein hymchwil, hyd yn oed os yw cyfnod hir o amser yn mynd heibio rhyngddynt, mae'r algorithm dad-ddyblygu hwn yn rhoi'r canlyniad gorau.

Ond mwy o fynegeion i dduw y mynegeion! Mae yna hefyd fynegai ar gyfer adfer data! Pan fyddwn yn dechrau adfer peiriant sydd wedi'i leoli yn y llinell doriad capasiti, byddwn ond yn darllen blociau data unigryw nad ydynt yn y llinell doriad perfformiad.

Sut y digwyddodd?

Dyna i gyd ar gyfer y rhan ragarweiniol. Mae'n eithaf manwl, ond fel y crybwyllwyd uchod, heb y manylion hyn ni fydd yn bosibl esbonio sut mae'r swyddogaethau newydd yn gweithio. Felly, heb ragor o wybodaeth, gadewch inni symud ymlaen at y cyntaf.

Modd copïo

Mae'n seiliedig i raddau helaeth ar dechnolegau presennol, ond mae ganddo resymeg defnydd hollol wahanol. 

Pwrpas y modd hwn yw sicrhau bod gan yr holl ddata a leolir ar y raddfa leol gopi yn y llinell doriad capasiti.

Os cymharwch y moddau Symud a Chopio yn uniongyrchol, bydd yn edrych fel hyn:

• Dim ond y gadwyn wedi'i selio y gellir ei symud. Yn achos modd copi, mae popeth yn cael ei drosglwyddo, waeth beth sy'n digwydd yn y swydd wrth gefn.
• Mae symud yn cael ei sbarduno pan fydd y ffeiliau'n mynd y tu hwnt i ffiniau'r ffenestr wrth gefn weithredol, ac mae copïo'n cael ei sbarduno cyn gynted ag y bydd y ffeil wrth gefn yn ymddangos.
• Mae monitro data newydd ar gyfer copïo yn digwydd yn gyson, ac ar gyfer symud roedd yn cael ei sbarduno unwaith bob 4 awr.

Wrth ystyried y modd newydd, cynigiaf symud o enghreifftiau syml i rai cymhleth.

Yn yr achos mwyaf cyffredin, yn syml, mae gennym ffeiliau newydd gyda chynyddrannau, ac rydym yn eu copïo i'r ystod saethu gallu. Ni waeth pa fodd a ddefnyddir yn y swydd wrth gefn, ni waeth a yw'n perthyn i'r rhan o'r gadwyn wedi'i selio ai peidio, ni waeth a yw ein ffenestr weithredu wedi dod i ben. Fe wnaethon nhw ei gymryd a'i gopïo.

Y broses y tu ôl i hyn o hyd yw dadhydradu fel y disgrifir uchod. Yn y modd copi, mae hefyd yn sicrhau nad ydym yn copïo blociau sydd eisoes ar ein storfa. Yr unig wahaniaeth yw pe baem yn disodli ffeiliau go iawn gyda ffeiliau ffug, yma nid ydym yn eu cyffwrdd mewn unrhyw ffordd ac yn gadael popeth fel y mae. Fel arall, mae'n union yr un mynegai dadhydradu, sy'n ceisio arbed eich arian a'ch amser yn ofalus.

Mae'r cwestiwn yn codi - os edrychwch ar yr UI, mae cyfle i ddewis y ddau opsiwn ar yr un pryd. Sut bydd modd cyfun o'r fath yn gweithio?

Gadewch i ni ei gael yn iawn.

Mae'r dechrau yn safonol: mae ffeil wrth gefn yn cael ei chreu a'i chopïo ar unwaith. Mae cynyddran yn cael ei greu iddo a hefyd yn cael ei gopïo. Mae hyn yn digwydd tan yr eiliad pan sylweddolwn fod y ffeiliau wedi gadael ein ffenestr weithredu a bod cadwyn wedi'i selio wedi ymddangos. Ar y pwynt hwn rydym yn cyflawni gweithrediad dadhydradu ac yn disodli'r ffeiliau hyn â ffeiliau ffug. Wrth gwrs, nid ydym yn copïo unrhyw beth eto i'r ystod saethu gallu.

Mae'r holl resymeg hynod ddiddorol hon yn gyfrifol am un blwch gwirio yn y rhyngwyneb: Copïwch gopïau wrth gefn i storio gwrthrychau cyn gynted ag y cânt eu creu.

Pam mae angen y modd Copi hwn arnom?

Mae’n well byth aralleirio’r cwestiwn fel hyn: pa risgiau rydyn ni’n cael ein hamddiffyn rhagddynt gyda’i help? Pa broblem y mae'n ein helpu i'w datrys?

Mae'r ateb yn amlwg: wrth gwrs, adfer data yw hwn. Os oes gennym gopi cyflawn o ddata lleol ar storio gwrthrychau, yna ni waeth beth sy'n digwydd i'n cynnyrch, gallwn bob amser adfer data o ffeiliau sydd wedi'u lleoli yn yr Amazon amodol.

Felly gadewch i ni fynd drwy'r senarios posibl, o'r symlaf i'r mwyaf cymhleth.

Yr anffawd symlaf a all ddisgyn ar ein pennau yw anhygyrchedd un o'r ffeiliau yn y gadwyn wrth gefn.

Stori dristach yw bod un o raddau ein cadwrfa SOBR wedi torri.

Mae'n gwaethygu hyd yn oed pan fydd y storfa SOBR gyfan wedi dod yn anhygyrch, ond mae'r ystod saethu gallu yn gweithio.
Ac mae popeth yn ddrwg iawn - dyma pan fydd y gweinydd wrth gefn yn marw a'ch dymuniad cyntaf yw ceisio rhedeg i ffin Canada mewn deg munud.

Nawr, gadewch i ni edrych ar bob sefyllfa ar wahân.

Pan fyddwn wedi colli un (a hyd yn oed nifer) o ffeiliau wrth gefn, y cyfan sydd angen i ni ei wneud yw cychwyn y broses ailsganio ystorfa, a bydd ffeil ffug yn cael ei disodli gan y ffeil goll. A chan ddefnyddio'r broses ailhydradu (a drafodwyd ar ddechrau'r erthygl), bydd y defnyddiwr yn gallu lawrlwytho data o'r ystod saethu gallu i storio lleol.

Nawr mae'r sefyllfa'n fwy cymhleth. Gadewch i ni dybio bod ein SOBR yn cynnwys dwy raddfa yn rhedeg yn y modd Perfformiad, sy'n golygu bod ein .vbk a .vib wedi'u lledaenu drostynt mewn haen braidd yn anwastad. Ac ar ryw adeg, nid yw un o'r graddau ar gael, ac mae angen i'r defnyddiwr adfer y peiriant ar frys, y mae rhan o'r data ohono yn gorwedd yn union ar y graddau hyn.

Mae'r defnyddiwr yn lansio'r dewin adfer, yn dewis y pwynt y mae am ei adfer, ac mae'r dewin, wrth weithio, yn sylweddoli nad oes ganddo'r holl ddata angenrheidiol ar gyfer adferiad yn lleol ac felly mae angen ei lawrlwytho o'r saethu gallu. oriel. Ar yr un pryd, ni fydd blociau sy'n aros ar storfa leol yn cael eu lawrlwytho o'r cwmwl. Gogoniant i'r mynegai adfer (ie, fe'i crybwyllwyd hefyd ar ddechrau'r erthygl).

Is-fath o'r achos hwn yw bod y storfa SOBR gyfan wedi dod yn anhygyrch. Yn yr achos hwn, nid oes gennym unrhyw beth i'w gopïo o storfa leol, ac mae pob bloc yn cael ei lawrlwytho o'r cwmwl.

A'r sefyllfa fwyaf diddorol yw bod y gweinydd wrth gefn wedi marw. Mae dau opsiwn yma: mae'r gweinyddwr yn wych ac wedi gwneud copïau wrth gefn o ffurfweddu, ac mae'r gweinyddwr yn Pinocchio drwg ei hun ac ni wnaeth gopïau wrth gefn o'r ffurfwedd.

Yn yr achos cyntaf, bydd yn ddigon iddo ddefnyddio gosodiad glân o VBR yn rhywle ac adfer ei gronfa ddata o gopi wrth gefn gan ddefnyddio dulliau safonol. Ar ddiwedd y broses hon, bydd popeth yn dychwelyd i normal. Neu bydd yn cael ei adfer yn ôl un o'r senarios uchod.

Ond os yw'r gweinyddwr naill ai'n elyn iddo ei hun, neu os yw'r cyfluniad wrth gefn hefyd wedi dioddef methiant epig, yna hyd yn oed yma ni fyddwn yn ei adael i drugaredd tynged. Ar gyfer yr achos hwn, rydym wedi cyflwyno gweithdrefn newydd o'r enw Mewnforio Gwrthrych Storage. Mae'n caniatáu ichi hepgor y broses o ail-greu ystorfa SOBR â llaw ac atodi ystod saethu gallu iddo gyda'i ailsganio dilynol, ac ychwanegu gwrthrych storio i'r rhyngwyneb Vim a rhedeg y weithdrefn Storfa Mewnforio Storio. Yr unig beth a all sefyll yn y ffordd rhyngoch chi a'ch copïau wrth gefn yw cais i nodi cyfrinair os oedd eich copïau wrth gefn wedi'u hamgryptio.

Mae'n debyg bod hyn i gyd yn ymwneud â Modd Copi ac rydym yn symud ymlaen i

Modd Wedi'i Selio

Y prif syniad yw na all copïau wrth gefn newydd ymddangos ar ehangder SOBR dethol yr ystorfa. Cyn v10, dim ond Modd Cynnal a Chadw oedd gennym, pan oedd unrhyw waith gyda'r ystorfa wedi'i wahardd yn llwyr. Math o ddull craidd caled ar gyfer cau storfa, lle mai dim ond y botwm Gwacáu sydd ar gael, sy'n cludo copïau wrth gefn i raddau arall un-amser.

Ac mae modd Selio yn fath o opsiwn “meddal”: rydym yn gwahardd creu copïau wrth gefn newydd ac yn dileu hen rai yn raddol yn ôl y cadw a ddewiswyd, ond yn y broses nid ydym yn colli'r gallu i adfer o bwyntiau sydd wedi'u storio. Peth defnyddiol iawn pan fydd gennym naill ai ddarn o galedwedd yn agosáu at ddiwedd ei oes ac angen ei ddisodli, neu mae angen i ni ei ryddhau ar gyfer rhywbeth pwysicach, ond nid oes unman i'w gymryd a symud popeth ar unwaith. Neu ni ellir ei ddileu.

Yn unol â hynny, mae'r egwyddor o weithredu yn eithaf syml: mae angen gwahardd pob gweithrediad ysgrifennu (ymddangosiad data newydd), gadael darllen (adnewyddu) a dileu (cadw).

Gellir defnyddio'r ddau fodd ar yr un pryd, ond cofiwch fod gan Gynnal a Chadw flaenoriaeth uwch.

Fel enghraifft, ystyriwch SOBR sy'n cynnwys dwy raddfa. Gadewch i ni dybio ein bod am y pedwar diwrnod cyntaf wedi creu copïau wrth gefn yn y modd Forward Forever Incremental, ac yna rydym yn selio'r graddau.Mae hyn yn arwain at y ffaith ein bod yn cychwyn creu llawn gweithredol newydd ar yr ail faint sydd ar gael. Os yw ein cadw yn bedwar, yna pan fydd y gadwyn gyfan a leolir ar y graddau selio yn mynd y tu hwnt i'w derfynau, caiff ei ddileu gyda chydwybod glir.

Mae yna sefyllfaoedd pan fydd dileu yn digwydd yn gynharach. Er enghraifft, mae hwn yn Forward cynyddrannol gyda llawnau cyfnodol. Os gwnaethom greu copïau wrth gefn llawn am y ddau ddiwrnod cyntaf, a dydd Iau byddwn yn penderfynu selio'r ystorfa, yna ddydd Gwener, pan fydd copi wrth gefn newydd yn cael ei greu, bydd y ffeil ar gyfer dydd Llun yn cael ei ddileu oherwydd nid oes unrhyw ddibyniaethau i'r pwynt hwn. Ac nid yw'r pwynt ei hun yn dibynnu ar unrhyw un. Yna rydym yn aros nes bod pedwar pwynt yn cael eu creu ar y graddau sydd ar gael a dileu'r tri sy'n weddill, na ellir eu dileu yn annibynnol ar ei gilydd.

Mae pethau'n symlach gyda Reverse Incremental. Ynddo, nid yw'r pwyntiau hynaf yn dibynnu ar unrhyw beth a gellir eu dileu yn ddiogel. Felly, cyn gynted ag y bydd .vbk newydd yn cael ei greu ar raddfa newydd, bydd yr hen .vrbs yn cael ei ddileu fesul un.

Gyda llaw, pam yr ydym yn creu .vbk newydd bob tro: pe na baem yn ei greu, ond yn parhau â'r hen gadwyn o gynyddrannau, yna byddai'r hen .vbk yn rhewi am amser anfeidrol hir mewn unrhyw fodd, gan atal ei ddileu. Felly, penderfynwyd, cyn gynted ag y bydd y graddau wedi'u selio, ein bod yn creu copi wrth gefn llawn ar y graddau rhydd.

Mae pethau'n fwy cymhleth gyda'r ystod saethu gallu.

Yn gyntaf, gadewch i ni edrych ar y modd copi. Gadewch i ni dybio ein bod wrthi'n creu copïau wrth gefn am bedwar diwrnod, ac yna cafodd yr ystod saethu capasiti ei selio. Nid ydym yn dileu unrhyw beth, ond yn ostyngedig yn goddef y cadw, ac ar ôl hynny rydym yn dileu'r data o'r ystod saethu capasiti.

Mae tua'r un peth yn digwydd yn y modd symud - rydym yn aros am y retouch, yn dileu'r hen un yn y storfa leol, ac yn dileu'r un sydd wedi'i storio yn y storfa gwrthrychau.

Enghraifft ddiddorol gyda Forever forward incremental. Rydyn ni'n gosod cadw ar dri phwynt ac yn dechrau gwneud copïau wrth gefn ddydd Llun, sy'n cael eu copïo'n rheolaidd i'r cwmwl. Ar ôl selio'r storfa, mae copïau wrth gefn yn parhau i gael eu creu, gan gynnal tri phwynt, ond mae'r data a storir yn y llinell doriad cynhwysedd yn parhau i fod yn ddibynnol ac ni ellir ei ddileu. Felly, rydym yn aros tan ddydd Iau, pan fydd ein .vbk yn mynd y tu hwnt i'w gadw, a dim ond wedyn y byddwn yn dileu'r gadwyn gyfan a arbedwyd yn dawel.

Ac ymwadiad bychan : dangosir pob esiampl yma ag un peiriant. Os oes gennych chi nifer ohonynt yn eich copi wrth gefn, yna bydd eu hailgyffwrdd yn amrywio yn dibynnu a gafodd Active Full ei wneud ai peidio.

Yn y bôn, dyna'r cyfan sydd iddo. Felly gadewch i ni symud ymlaen at y nodwedd mwyaf craidd caled -

Digyfnewid

Fel gyda'r pwyntiau blaenorol, y peth cyntaf yw pa broblem y mae'r swyddogaeth hon yn ei datrys. Cyn gynted ag y byddwn yn uwchlwytho ein copïau wrth gefn yn rhywle i'w storio, mae awydd cryf i warantu eu diogelwch, hynny yw, i wahardd eu dileu yn gorfforol ac unrhyw addasiad yn ystod cyfnod cadw penodol. Gan gynnwys gweinyddwyr, gan gynnwys o dan eu cyfrifon gwraidd. Mae hyn yn caniatáu ichi eu hamddiffyn rhag difrod damweiniol neu fwriadol. Mae'n bosibl bod unrhyw un sy'n gweithio gydag AWS wedi dod ar draws nodwedd debyg o'r enw Object Lock.

Nawr, gadewch i ni edrych ar y modd yn gyffredinol, ac yna ymchwilio i'r manylion. Yn ein hesiampl, bydd Immutability yn cael ei alluogi ar gyfer ein hystod saethu gallu gyda chadwad o bedwar diwrnod. Ac mae'r modd Copi wedi'i alluogi yn y copi wrth gefn.

Nid yw immutability yn rhyngweithio â chadw cyffredinol mewn unrhyw ffordd. Er enghraifft, nid yw'n ychwanegu pwyntiau ychwanegol nac unrhyw beth felly. Dim ond na all person ddileu ffeiliau wrth gefn o fewn pedwar diwrnod. Os gwnewch gopi wrth gefn ddydd Llun, dim ond ddydd Gwener y byddwch yn gallu dileu ei ffeil.

Mae'r holl gysyniadau o ddadhydradu, mynegeion a metadata a eglurwyd yn flaenorol yn parhau i weithio'n union yr un fath. Ond gydag un amod - mae'r bloc wedi'i osod nid yn unig ar gyfer data, ond hefyd ar gyfer metadata. Gwneir hyn rhag ofn y bydd ymosodwr cyfrwys yn penderfynu dileu ein cronfa ddata metadata ac atal blociau data rhag troi'n mush deuaidd diwerth.

Mae nawr yn amser gwych i esbonio ein technoleg cynhyrchu bloc. Neu bloc cynhyrchu. I wneud hyn, ystyriwch y sefyllfa a arweiniodd at ei ymddangosiad.

Gadewch i ni gymryd graddfa amser o chwe diwrnod ac islaw byddwn yn nodi amser diwedd ansymudedd disgwyliedig. Ar y diwrnod cyntaf rydym yn cymryd ac yn creu ffeil sy'n cynnwys bloc data a a'i fetadata. Os yw ansymudedd wedi'i osod i dri diwrnod, mae'n rhesymegol tybio y bydd y data'n cael ei ddatgloi a'i ddileu ar y pedwerydd diwrnod. Ar yr ail ddiwrnod byddwn yn ychwanegu ffeil2 newydd, sy'n cynnwys bloc b gyda'r un gosodiadau. Mae angen tynnu bloc dal ar y pedwerydd diwrnod. Ond ar y trydydd diwrnod mae rhywbeth ofnadwy yn digwydd - mae ffeil File3 yn cael ei chreu, sy'n cynnwys bloc d newydd a dolen i'r hen floc a. Mae hyn yn golygu, ar gyfer bloc a bod yn rhaid ailosod ei faner immutability i ddyddiad newydd, sy'n cael ei symud i'r chweched diwrnod. Ac yma mae problem yn codi - mewn copïau wrth gefn go iawn mae yna nifer fawr o flociau o'r fath. Ac er mwyn ymestyn eu cyfnod ansymudedd, mae angen i chi wneud nifer fawr o geisiadau bob tro. Ac mewn gwirionedd, bydd hon yn broses ddyddiol bron yn ddiddiwedd, oherwydd gyda lefel uchel o debygolrwydd byddwn yn dod o hyd i bentyrrau mawr o flociau wedi'u dad-ddyblygu gyda phob copi. Beth mae nifer fawr o geisiadau gan ddarparwyr storio gwrthrychau yn ei olygu? Reit! Bil anferth ar ddiwedd y mis.

Ac er mwyn peidio â datgelu'ch hoff gleientiaid am arian sylweddol allan o'r glas, dyfeisiwyd y mecanwaith cynhyrchu bloc. Mae hwn yn gyfnod ychwanegol yr ydym yn ei ychwanegu at y cyfnod ansefydlogrwydd a osodwyd. Yn yr enghraifft isod, dau ddiwrnod yw'r cyfnod hwn. Ond dim ond enghraifft yw hon. Mewn gwirionedd, maent yn defnyddio eu fformiwla eu hunain, sy'n rhoi tua deg diwrnod ychwanegol yn ystod clo misol.

Gadewch i ni barhau i ystyried yr un sefyllfa, ond gyda chynhyrchu bloc. Ar y diwrnod cyntaf rydym yn creu ffeil 1 o bloc a a metadata. Rydym yn adio'r cyfnod cynhyrchu a'r ansymudedd - mae hyn yn golygu y bydd y cyfle i ddileu'r ffeil ar y chweched diwrnod. Os byddwn yn creu File2 ar yr ail ddiwrnod, sy'n cynnwys bloc b a dolen i bloc a, yna nid oes dim yn digwydd i'r dyddiad dileu disgwyliedig. Safodd fel y gwnaeth ar y chweched dydd. Ac felly rydym yn ceisio arbed arian ar nifer y ceisiadau. Yr unig sefyllfa pan ellir newid y dyddiad cau yw os yw'r cyfnod cynhyrchu wedi dod i ben. Hynny yw, os ar y trydydd diwrnod mae'r File3 newydd yn cynnwys dolen i rwystro a, yna bydd cenhedlaeth 2 yn cael ei hychwanegu gan fod Gen1 eisoes wedi dod i ben. Ac mae'r dyddiad disgwyliedig ar gyfer dileu bloc ewyllys yn symud i'r wythfed diwrnod. Mae hyn yn ein galluogi i leihau'n sylweddol nifer y ceisiadau i ymestyn oes blociau wedi'u dad-ddyblygu, sy'n arbed tunnell o arian i gleientiaid.

Mae'r dechnoleg ei hun ar gael i ddefnyddwyr caledwedd sy'n gydnaws â S3 a S3, y mae eu gweithgynhyrchwyr yn gwarantu nad yw eu gweithrediad yn wahanol i Amazon. Felly yr ateb i'r cwestiwn dilys pam nad yw Azure yn cael ei gefnogi - mae ganddyn nhw nodwedd debyg, ond mae'n gweithio ar lefel y cynwysyddion, nid gwrthrychau unigol. Gyda llaw, mae gan Amazon ei hun glo gwrthrych mewn dau fodd: cydymffurfio a llywodraethu. Yn yr ail achos, erys y posibilrwydd bod y gweinyddwr mwyaf uwchben gweinyddwyr a gwraidd uwchben gwreiddiau, er gwaethaf y clo gwrthrych, yn dal i ddileu'r data. Yn achos cydymffurfio, mae popeth wedi'i hoelio'n dynn ac ni all unrhyw un ddileu'r copïau wrth gefn. Hyd yn oed gweinyddwyr Amazon (yn ôl eu datganiadau swyddogol). Dyma'r modd rydyn ni'n ei gefnogi.

Ac, yn ôl yr arfer, rhai dolenni defnyddiol:

• Про Cynhyrchu Bloc ym mhob manylyn.
• Pob gwybodaeth am Veeam Backup & Replication 10 ar ei orau
• О Haen Cynhwysedd yn fanwl

Ffynhonnell: hab.com