Kapacitnivelo (aŭ kiel ni nomas ĝin ene de Vim - captir) aperis reen en la tagoj de Veeam Backup and Replication 9.5 Ĝisdatigo 4 sub la nomo Archive Tier. La ideo malantaŭ ĝi estas ebligi movi sekurkopiojn kiuj falis el la tiel nomata funkcia restariga fenestro al objektostokado. Ĉi tio helpis liberigi diskospacon por tiuj uzantoj, kiuj havis malmulte da ĝi. Kaj ĉi tiu opcio estis nomita Move Mode.

Por plenumi ĉi tiun simplan (kiel ŝajnas) agon, sufiĉis plenumi du kondiĉojn: ĉiuj punktoj de la movita sekurkopio devas esti ekster la limoj de la supre menciita funkcia restaŭra fenestro, kiu estas fiksita eksplicite en la UI. Kaj due: la ĉeno devas esti en la tiel nomata "fermita formo" (fermita rezerva ĉeno aŭ Neaktiva Rezerva Ĉeno). Tio estas, neniuj ŝanĝoj okazas en ĉi tiu ĉeno laŭlonge de la tempo.

Sed en VBR v10, la koncepto estis kompletigita per novaj funkcioj - Kopi-Reĝimo, Sigelita Reĝimo kaj aperis afero kun la malfacile prononcebla nomo Immutability.

Ĉi tiuj estas la fascinaj aferoj, pri kiuj ni parolos hodiaŭ. Unue, pri kiel ĝi funkciis en VBR9.5u4, kaj poste pri la ŝanĝoj en la deka versio.

Kaj la ĉampionoj de pura lingvo pardonu min, sed estas tro da terminoj ne tradukeblaj.
Do ĉi tie estos multe da anglismoj.
Kaj multe da gifoj.
Kaj bildoj.

• Sen la plej eta bedaŭro. Aŭtoro de la artikolo.

Kiel ĝi estis

Nu, ni komencu analizante la funkcian restarigan fenestron kaj sigelitan sekurkopion (aŭ kiel ili estas nomataj en la dokumentado pri Neaktiva Rezerva Ĉeno). Sen ilia kompreno, plua klarigo ne eblos.

Kiel ni vidas en la bildo, ni havas specon de rezerva ĉeno kun datumblokoj, kiu situas sur la Performance-nivelo SOBR de la deponejo al kiu la Kapacita Tier estas konektita. Nia funkcia rezerva fenestro estas tri tagoj.

Sekve, la .vbk kreita lundon sigelas la antaŭan ĉenon, kies fenestro estas agordita al tri tagoj. Kaj tio signifas, ke vi povas sekure komenci transporti ĉion pli malnovan ol ĉi tiuj tri tagoj al la pafejo.

Sed kion precize signifis sigelita ĉeno kaj kio povus esti sendita al la kapacita pafado en ĝisdatigo 4?

Por Forward Incremental, signo de sigelo de la ĉeno estas la kreado de nova plena sekurkopio. Kaj ne gravas kiel ĉi tiu plena sekurkopio estas akirita: ambaŭ sintezaj plenaj kaj aktivaj plenaj sekurkopioj estas konsiderataj.

En la kazo de Reverse, ĉi tiuj estas ĉiuj dosieroj, kiuj ne falas en la operaciumon.

En la kazo de Antaŭen-pliigo kun retrovojoj, ĉi tiuj estas ĉiuj retrovojoj kaj .vbk, se ekzistas alia .vbk sur la amplekso de rendimento.

Nun ni konsideru la opcion labori kun Rezervkopiaj ĉenoj. Nur eroj subtenantaj GFS estis transportitaj ĉi tien. Ĉar ĉio konservita en pli lastatempaj sekurkopiaj ĉenoj povas esti ŝanĝita laŭ unu maniero aŭ alia.

Nun ni rigardu sub la kapuĉo. Tie, procezo nomita dehidratiĝo okazas - lasante malplenajn rezervajn dosierojn sur la amplekso kaj trenante blokojn de ĉi tiuj dosieroj al la kapacita pafejo. Por optimumigi ĉi tiun procezon, oni uzas la tiel nomatan dehidratan indicon, kiu ebligas al vi eviti kopii blokojn, kiuj jam estis kopiitaj al la kapacita pafado.

Ni vidu kiel tio aspektas kun ekzemplo: Ni diru, ke ni havas .vbk, kiu eliris el la transakcia fenestro kaj apartenas al sigelita ĉeno. Ĉi tio signifas, ke ni rajtas movi ĝin al la kapacita pafejo. En la momento de translokiĝo, metadatuma dosiero estas kreita en la kapacita streko kaj blokoj de la translokigita dosiero. La ligilo-nivela metadatuma dosiero priskribas el kiuj blokoj konsistas nia dosiero. En la kazo en la bildo, nia unua dosiero konsistas el blokoj a, b, c kaj la metadatenoj enhavas ligilojn al ĉi tiuj blokoj. Kiam ni havas duan .vbk-dosieron, pretan movi kaj konsistantan el blokoj a, b kaj d, ni, analizante la dehidratiĝo-indekson, komprenas, ke nur bloko d bezonas esti translokigita. Kaj ĝia metadatuma dosiero enhavos ligilojn al du antaŭaj blokoj kaj unu nova.

Sekve, la procezo plenigi ĉi tiujn malplenajn spacojn reen kun datumoj nomiĝas rehidratigo. Ĝi jam uzas sian propran rehidratigan indicon, bazitan sur la plej malnova .vbk-dosiero pri la loka amplekso. Tio estas, se la uzanto volas resendi dosieron el la kapacita pafado, ni unue kreas indekson de la blokoj de la plej malnova plena sekurkopio kaj transdonas nur la mankantajn blokojn de la kapacita pafadgalerio. En la kazo prezentita en la bildo, por rehidratigi FullBackup1.vbk laŭ la rehidratiga indico, ni bezonas nur blokon C, kiun ni prenas el la kapacita pafado. Se stoka nuba objekto funkcias kiel kapacita pafado, tio ebligas al vi ŝpari grandegajn monsumojn.

Ĉi tie povas ŝajni, ke ĉi tiu teknologio estas identa al tiu uzata en WAN-akceliloj, sed ŝajnas nur tiel. En akceliloj, deduplikado estas tutmonda; ĉi tie, loka deduplikado estas uzata ene de ĉiu dosiero ĉe specifa ofseto. Ĉi tio okazas pro la diferenco en la solvitaj taskoj: ĉi tie ni devas kopii grandajn plenajn rezervajn dosierojn, kaj laŭ nia esplorado, eĉ se longa tempo pasas inter ili, ĉi tiu deduplika algoritmo donas la plej bonan rezulton.

Sed pli da indeksoj por la dio de indeksoj! Estas ankaŭ indekso por reakiro de datumoj! Kiam ni komencas restarigi maŝinon situantan en la kapacita streko, ni legos nur unikajn datumblokojn, kiuj ne estas en la agado-streko.

Kiel ĝi okazis

Jen ĉio por la enkonduka parto. Ĝi estas sufiĉe detala, sed kiel menciite supre, sen ĉi tiuj detaloj ne eblos klarigi kiel funkcias la novaj funkcioj. Sekve, sen pliaj proklamoj, ni transiru al la unua.

Kopiu reĝimo

Ĝi estas plejparte bazita sur ekzistantaj teknologioj, sed portas tute alian logikon de uzo. 

La celo de ĉi tiu reĝimo estas certigi, ke ĉiuj datumoj situantaj sur la loka amplekso havas kopion en la kapacita streko.

Se vi komparas la Movu kaj Kopii-reĝimojn fronte, ĝi aspektos jene:

• Nur la sigelita ĉeno povas esti movita. En la kazo de kopia reĝimo, absolute ĉio estas translokigita, sendepende de tio, kio okazas en la rezerva laboro.
• Movado estas ekigita kiam la dosieroj preterpasas la limojn de la funkcia rezerva fenestro, kaj kopiado estas ekigita tuj kiam la rezerva dosiero aperas.
• Monitorado de novaj datumoj por kopiado okazas konstante, kaj por movo ĝi estis ekigita unufoje ĉiujn 4 horojn.

Konsiderante la novan reĝimon, mi proponas transiri de simplaj ekzemploj al kompleksaj.

En la plej ofta kazo, ni simple havas novajn dosierojn kun pliigoj, kaj ni simple kopias ilin al la kapacita pafado. Sendepende de kia reĝimo estas uzata en la rezerva laboro, sendepende de ĉu ĝi apartenas al la sigelita parto de la ĉeno aŭ ne, sendepende de ĉu nia operaciumo eksvalidiĝis. Ili nur prenis ĝin kaj kopiis ĝin.

La procezo malantaŭ ĉi tio ankoraŭ estas dehidratiĝo kiel priskribite supre. En kopireĝimo, ĝi ankaŭ certigas, ke ni ne kopias blokojn kiuj jam estas en nia stokado. La nura diferenco estas, ke se en filmreĝimo ni anstataŭigis verajn dosierojn per imitaj dosieroj, ĉi tie ni neniel tuŝas ilin kaj lasas ĉion tia. Alie, ĝi estas ĝuste la sama dehidratiĝo-indico, kiu zorge provas ŝpari vian monon kaj tempon.

La demando ŝprucas - se vi rigardas la UI, estas ŝanco elekti ambaŭ opciojn samtempe. Kiel funkcios tia kombinita reĝimo?

Ni eltrovu ĝin.

La komenco estas norma: rezerva dosiero estas kreita kaj kopiita tuj. Pliigo estas kreita al ĝi kaj ankaŭ kopiita. Ĉi tio okazas ĝis la momento, kiam ni rimarkas, ke la dosieroj forlasis nian operacian fenestron kaj aperis sigelita ĉeno. Je ĉi tiu punkto ni faras malhidratan operacion kaj anstataŭigas ĉi tiujn dosierojn per simulaj dosieroj. Kompreneble, ni ne kopias ion denove al la kapacita pafejo.

Ĉio ĉi tiu fascina logiko respondecas pri nur unu markobutono en la interfaco: Kopiu sekurkopiojn al objektostokado tuj kiam ili estas kreitaj.

Kial ni bezonas ĉi tiun Kopi-reĝimon?

Eĉ pli bone estas reformi la demandon jene: kontraŭ kiaj riskoj ni estas protektataj per ĝia helpo? Kiun problemon ĝi helpas nin solvi?

La respondo estas evidenta: kompreneble ĉi tio estas reakiro de datumoj. Se ni havas kompletan kopion de lokaj datumoj pri la objektostokado, tiam ne gravas kio okazas al nia produkto, ni ĉiam povas restarigi datumojn de dosieroj situantaj en la kondiĉa Amazono.

Do ni trairu la eblajn scenarojn, de la plej simpla ĝis la pli kompleksa.

La plej simpla malfeliĉo, kiu povas fali sur niajn kapojn, estas la nealirebleco de unu el la dosieroj en la rezerva ĉeno.

Pli malĝoja rakonto estas, ke unu el la etendaĵoj de nia SOBR-deponejo rompiĝis.

Ĝi eĉ plimalboniĝas kiam la tuta SOBR-deponejo fariĝis nealirebla, sed la kapacita pafado funkcias.
Kaj ĉio estas vere malbona - jen kiam la rezerva servilo mortas kaj via unua deziro estas provi kuri al la kanada limo post dek minutoj.

Nun ni rigardu ĉiun situacion aparte.

Kiam ni perdis unu (kaj eĉ plurajn) rezervajn dosierojn, tiam ĉio, kion ni devas fari, estas komenci la deponejan resanan procezon, kaj la perdita dosiero estos anstataŭigita per falsa dosiero. Kaj uzante la rehidratigprocezon (kiu estis diskutita komence de la artikolo), la uzanto povos elŝuti datumojn de la kapablo de pafado al loka stokado.

Nun la situacio estas pli komplika. Ni supozu, ke nia SOBR konsistas el du etendaĵoj kurantaj en Performance-reĝimo, kio signifas, ke niaj .vbk kaj .vib estas disvastigitaj super ili en sufiĉe malebena tavolo. Kaj en iu momento, unu el la etendaĵoj fariĝas neatingebla, kaj la uzanto urĝe bezonas restarigi la maŝinon, parto de kies datumoj ĝuste sur ĉi tiu amplekso.

La uzanto lanĉas la reakiran sorĉiston, elektas la punkton al kiu li volas restarigi, kaj la sorĉisto, laborante, ekkomprenas, ke li ne havas ĉiujn necesajn datumojn por reakiro loke kaj tial necesas elŝuti el la kapablo pafado. galerio. Samtempe, blokoj kiuj restas sur loka stokado ne estos elŝutitaj el la nubo. Gloro al la restariga indekso (jes, ĝi ankaŭ estis menciita komence de la artikolo).

Subtipo de ĉi tiu kazo estas ke la tuta SOBR-deponejo iĝis nealirebla. En ĉi tiu kazo, ni havas nenion por kopii de loka stokado, kaj ĉiuj blokoj estas elŝutitaj el la nubo.

Kaj la plej interesa situacio estas, ke la rezerva servilo mortis. Estas du ebloj ĉi tie: la administranto estas bonega kaj faris agordajn sekurkopiojn, kaj la administranto estas malbona Pinokjo mem kaj ne faris agordajn sekurkopiojn.

En la unua kazo, sufiĉos por li simple disfaldi puran instaladon de VBR ie kaj restarigi ĝian datumbazon de sekurkopio per normaj rimedoj. Ĉe la fino de ĉi tiu procezo, ĉio revenos al normalo. Aŭ ĝi estos restarigita laŭ unu el la supraj scenaroj.

Sed se la administranto estas aŭ sia propra malamiko, aŭ la agorda sekurkopio ankaŭ suferis eposan fiaskon, tiam eĉ ĉi tie ni ne lasos lin al la kompato de la sorto. Por ĉi tiu kazo, ni enkondukis novan proceduron nomitan Import Object Storage. Ĝi ebligas al vi preterpasi la procezon permane rekrei SOBR-deponejon kaj alkroĉi al ĝi kapacitan pafkampon per posta reskanado, kaj simple aldoni stokan objekton al la Vim-interfaco kaj ruli la proceduron Import Storage Depository. La sola afero, kiu povas malhelpi inter vi kaj viaj sekurkopioj, estas peto enigi pasvorton se viaj sekurkopioj estis ĉifritaj.

Ĉi tio verŝajne temas pri Kopi-Reĝimo kaj ni pluiras al

Sigelita Reĝimo

La ĉefa ideo estas, ke novaj sekurkopioj ne povas aperi sur la elektita SOBR-amplekso de la deponejo. Antaŭ v10, ni nur havis Prizorgan Reĝimon, kiam ajna laboro kun la deponejo estis tute malpermesita. Speco de ĝisosta reĝimo por fermi stokadon, kie nur la Evakui butonon disponeblas, kiu transportas sekurkopiojn al alia mezuro unufoja.

Kaj Sigelita reĝimo estas speco de "mola" opcio: ni malpermesas la kreadon de novaj sekurkopioj kaj iom post iom forigas malnovajn laŭ la elektita reteno, sed en la procezo ni ne perdas la kapablon restarigi de stokitaj punktoj. Tre utila afero kiam ni aŭ havas pecon da aparataro proksimiĝanta al la fino de ĝia vivo kaj bezonas anstataŭigi ĝin, aŭ ni nur bezonas liberigi ĝin por io pli grava, sed estas nenie por preni ĝin kaj movi ĉion samtempe. Aŭ ĝi ne povas esti forigita.

Sekve, la principo de funkciado estas sufiĉe simpla: necesas malpermesi ĉiujn skribajn operaciojn (apero de novaj datumoj), lasante legi (restarigo) kaj forigi (reteno).

Ambaŭ reĝimoj povas esti uzataj samtempe, sed memoru, ke Bontenado havas pli altan prioritaton.

Ekzemple, konsideru SOBR konsistantan el du etendaĵoj. Ni supozu, ke dum la unuaj kvar tagoj ni kreis sekurkopiojn en la Forward Forever Incremental-reĝimo, kaj tiam ni sigelas la amplekson. Ĉi tio kondukas al la fakto, ke ni komencas la kreadon de nova aktiva pleno sur la dua disponebla amplekso. Se nia reteno estas kvar, tiam kiam la tuta ĉeno situanta sur la sigelita amplekso preterpasas siajn limojn, ĝi estas forigita kun pura konscienco.

Estas situacioj kiam forigo okazas pli frue. Ekzemple, ĉi tio estas Antaŭen pliiga kun periodaj plenigoj. Se ni kreis plenajn sekurkopiojn dum la unuaj du tagoj, kaj ĵaŭdon ni decidas sigeli la deponejon, tiam vendrede, kiam nova sekurkopio estas kreita, la dosiero por lundo estos forigita ĉar ne ekzistas dependecoj ĝis ĉi tiu punkto. Kaj la punkto mem ne dependas de iu ajn. Tiam ni atendas ĝis kvar punktoj estas kreitaj sur la disponebla amplekso kaj forigas la ceterajn tri, kiuj ne povas esti forigitaj sendepende unu de la alia.

Aferoj estas pli simplaj kun Reverse Incremental. En ĝi, la plej malnovaj punktoj dependas de io ajn kaj povas esti sekure forigitaj. Tial, tuj kiam nova .vbk estas kreita sur nova amplekso, la malnovaj .vbs estos forigitaj unu post alia.

Cetere, kial ni kreas novan .vbk ĉiufoje: se ni ne kreus ĝin, sed daŭrigus la malnovan ĉenon de pliigoj, tiam la malnova .vbk frostiĝus senlime longa en iu ajn reĝimo, malhelpante ĝian forigon. Tial, estis decidite, ke tuj kiam la amplekso estas sigelita, ni kreas plenan sekurkopion sur la libera amplekso.

Aferoj estas pli komplikaj kun la kapacita pafado.

Ni rigardu unue kopireĝimon. Ni supozu, ke ni aktive kreis sekurkopiojn dum kvar tagoj, kaj tiam la kapacita pafejo estis sigelita. Ni forigas nenion, sed humile eltenas la retenon, post kio ni forigas la datumojn el la kapacita pafado.

Proksimume la sama afero okazas en mova reĝimo - ni atendas la retuŝon, forigas la malnovan en la loka stokado, kaj forigas tiun konservitan en la objektostokado.

Interesa ekzemplo kun Forever antaŭen pliiga. Ni instalas retenon ĉe tri punktoj kaj komencas fari sekurkopiojn lundon, kiuj estas regule kopiitaj al la nubo. Post sigelo de la stokado, sekurkopioj daŭre estas kreitaj, konservante tri poentojn, sed la datumoj stokitaj en la kapacita streko restas dependaj kaj ne povas esti forigitaj. Tial ni atendas ĝis ĵaŭdo, kiam nia .vbk preterpasas retenadon, kaj nur tiam ni trankvile forigas la tutan konservitan ĉenon.

Kaj malgranda malgarantio: ĉiuj ekzemploj ĉi tie estas montritaj per unu maŝino. Se vi havas plurajn el ili en via sekurkopio, tiam ilia retuŝo malsamas depende de ĉu Active Full estis farita aŭ ne.

Tio estas esence ĉio estas al ĝi. Do ni transiru al la plej malmola trajto -

Neŝanĝebleco

Kiel ĉe la antaŭaj punktoj, la unua afero estas kian problemon ĉi tiu funkcio solvas. Tuj kiam ni alŝutas niajn sekurkopiojn ien por stokado, estas forta deziro garantii ilian sekurecon, tio estas, fizike malpermesi ilian forigon kaj ajnan modifon dum difinita konservado. Inkluzive de administrantoj, inkluzive sub iliaj radikaj kontoj. Ĉi tio permesas vin protekti ilin kontraŭ hazarda aŭ intenca damaĝo. Ĉiu, kiu laboras kun AWS, eble trovis similan funkcion nomatan Objekta Ŝlosilo.

Nun ni rigardu la reĝimon ĝenerale, kaj poste enprofundiĝu en la detalojn. En nia ekzemplo, Neŝanĝebleco estos ebligita por nia kapacita pafejo kun reteno de kvar tagoj. Kaj la Kopi-reĝimo estas ebligita en la sekurkopio.

Neŝanĝebleco neniel interagas kun ĝenerala reteno. Ekzemple, ĝi ne aldonas kromajn poentojn aŭ ion similan. Estas nur, ke persono ne povas forigi rezervajn dosierojn ene de kvar tagoj. Se vi faras sekurkopion lundon, vi nur povos forigi ĝian dosieron vendrede.

Ĉiuj antaŭe klarigitaj konceptoj pri dehidratiĝo, indeksoj kaj metadatenoj daŭre funkcias ekzakte same. Sed kun unu kondiĉo - la bloko estas agordita ne nur por datumoj, sed ankaŭ por metadatumoj. Ĉi tio estas farita se ruza atakanto decidas forigi nian metadatuman datumbazon kaj malhelpi datumblokojn iĝi senutila binara kaĉo.

Nun estas bonega tempo por klarigi nian blokgeneracian teknologion. Aŭ blokgenerado. Por fari tion, konsideru la situacion, kiu kaŭzis ĝian aperon.

Ni prenu temposkalon de ses tagoj kaj sube ni markos la tempon de la atendata eksvalidiĝo de neŝanĝebleco. En la unua tago ni prenas kaj kreas dosieron konsistantan el datumbloko a kaj ĝiaj metadatenoj. Se neŝanĝebleco estas agordita al tri tagoj, estas logike supozi, ke en la kvara tago la datumoj estos malŝlositaj kaj forigitaj. En la dua tago ni aldonos novan dosieron2, konsistantan el bloko b kun la samaj agordoj. Bloko ankoraŭ devas esti forigita en la kvara tago. Sed en la tria tago okazas io terura - estas kreita Dosiero3-dosiero, konsistanta el nova bloko d kaj ligilo al la malnova bloko a. Ĉi tio signifas, ke por bloko kaj ĝia neŝanĝebla flago devas esti rekomencigita al nova dato, kiu estas ŝanĝita al la sesa tago. Kaj ĉi tie aperas problemo - en realaj sekurkopioj estas grandega nombro da tiaj blokoj. Kaj por plilongigi ilian neŝanĝeblan periodon, vi devas fari grandegan nombron da petoj ĉiufoje. Kaj fakte, ĉi tio estos preskaŭ senfina ĉiutaga procezo, ĉar kun alta grado de probableco ni trovos grandajn stakojn da deduplikataj blokoj kun ĉiu kopio. Kion signifas granda nombro da petoj de objektaj stokadprovizantoj? Ĝuste! Grandega fakturo fine de la monato.

Kaj por ne senprokraste elmontri viajn plej ŝatatajn klientojn por granda mono, la blok-genera mekanismo estis inventita. Ĉi tio estas plia periodo, kiun ni aldonas al la fiksita neŝanĝebla periodo. En la suba ekzemplo, ĉi tiu periodo estas du tagoj. Sed ĉi tio estas nur ekzemplo. En realeco, ili uzas sian propran formulon, kiu donas proksimume dek pliajn tagojn dum monata seruro.

Ni daŭre konsideru la saman situacion, sed kun blokgenerado. En la unua tago ni kreas dosieron1 el bloko a kaj metadatenoj. Ni aldonas la generacian periodon kaj neŝanĝeblecon - tio signifas, ke la ŝanco forigi la dosieron estos en la sesa tago. Se en la dua tago ni kreas Dosiero2, konsistantan el bloko b kaj ligilo por bloki a, tiam nenio okazas al la atendata foriga dato. Ŝi staris kiel en la sesa tago. Kaj tiel ni provas ŝpari monon sur la nombro da petoj. La nura situacio, kiam la limdato povas esti ŝanĝita, estas se la generacia periodo eksvalidiĝis. Tio estas, se en la tria tago la nova Dosiero3 enhavas ligilon por bloki a, tiam la generacio 2 estos aldonita ĉar Gen1 jam eksvalidiĝis. Kaj la atendata dato por forigo de bloko a ŝanĝiĝos al la oka tago. Ĉi tio permesas al ni draste redukti la nombron da petoj por plilongigi la vivdaŭron de deduplikataj blokoj, kio ŝparas klientojn multan monon.

La teknologio mem estas disponebla por uzantoj de S3 kaj S3-kongrua aparataro, kies fabrikantoj garantias, ke ilia efektivigo ne diferencas de Amazon. Tial la respondo al la legitima demando kial Azure ne estas subtenata - ili havas similan funkcion, sed ĝi funkcias je la nivelo de ujoj, ne individuaj objektoj. Cetere, Amazon mem havas objektan seruron en du manieroj: plenumado kaj regado. En la dua kazo, restas la ebleco, ke la plej granda administranto super administrantoj kaj radiko super radikoj, malgraŭ la objekta seruro, ankoraŭ forigas la datumojn. En la kazo de plenumo, ĉio estas firme najlita kaj neniu povas forigi la sekurkopiojn. Eĉ Amazon-administrantoj (laŭ iliaj oficialaj deklaroj). Ĉi tiu estas la reĝimo, kiun ni subtenas.

Kaj, kiel kutime, kelkaj utilaj ligiloj:

• pri Bloka Generacio en ĉiu detalo.
• Ĉiuj informoj pri Sekurkopio kaj Reproduktado de Veeam 10 plej bone
• О Kapacito Tier en detaloj

fonto: www.habr.com