Kapasiteettitaso (tai kuten kutsumme sitä Vimin sisällä - captir) ilmestyi Veeam Backup and Replication 9.5 Update 4:n päivinä nimellä Archive Tier. Sen ideana on mahdollistaa ns. toiminnan palautusikkunasta pudonneiden varmuuskopioiden siirtäminen objektivarastoon. Tämä auttoi vapauttamaan levytilaa käyttäjille, joilla oli vähän sitä. Ja tätä vaihtoehtoa kutsuttiin Move Modeksi.

Tämän yksinkertaisen (kuten näyttää) toiminnon suorittamiseksi riitti kahden ehdon täyttäminen: kaikkien siirretyn varmuuskopion pisteiden on oltava edellä mainitun käyttöliittymässä nimenomaisesti määritetyn toiminnallisen palautusikkunan rajojen ulkopuolella. Ja toiseksi: ketjun on oltava niin sanotussa "suljetussa muodossa" (suljetussa varaketjussa tai Inactive Backup Chainissa). Eli tässä ketjussa ei tapahdu muutoksia ajan myötä.

Mutta VBR v10:ssä konseptia täydennettiin uusilla toiminnoilla - Copy Mode, Sealed Mode ja asia, jonka nimi on vaikea lausua Immutability, ilmestyi.

Nämä ovat kiehtovia asioita, joista puhumme tänään. Ensin siitä, kuinka se toimi VBR9.5u4:ssä, ja sitten muutoksista kymmenennessä versiossa.

Ja antakoot puhtaan kielen mestarit minulle anteeksi, mutta on liian monia termejä, joita ei voida kääntää.
Joten täällä tulee olemaan paljon anglismeja.
Ja paljon gifiä.
Ja kuvia.

• Ilman pienintäkään katumusta. Artikkelin kirjoittaja.

Kuten oli

No, aloitetaan analysoimalla toiminnallinen palautusikkuna ja sinetöity varmuuskopio (tai kuten niitä kutsutaan Inactive Backup Chain -dokumentaatiossa). Ilman heidän ymmärrystään lisäselvitykset eivät ole mahdollisia.

Kuten kuvasta näemme, meillä on eräänlainen tietolohkoineen varmuuskopioketju, joka sijaitsee sen arkiston Performance-tasolla SOBR, johon kapasiteettitaso on kytketty. Toiminnallinen varmuuskopiointiaikamme on kolme päivää.

Vastaavasti maanantaina luotu .vbk sulkee edellisen ketjun, jonka ikkuna on asetettu kolmeksi päiväksi. Ja tämä tarkoittaa, että voit turvallisesti aloittaa kaiken tätä kolmea päivää vanhemman kuljettamisen ampumaradalle.

Mutta mitä tiivistetyllä ketjulla tarkalleen ottaen tarkoitettiin ja mitä voitiin lähettää kapasiteetin ampumaradalle päivityksessä 4?

Forward Incrementalissa merkki ketjun sulkemisesta on uuden täyden varmuuskopion luominen. Ja sillä ei ole väliä, kuinka tämä täysi varmuuskopio saadaan: sekä synteettiset täydet että aktiiviset täydet varmuuskopiot otetaan huomioon.

Reverse:n tapauksessa nämä ovat kaikki tiedostoja, jotka eivät kuulu käyttöikkunaan.

Eteenpäin lisäyksen ja palautusten tapauksessa nämä ovat kaikki palautukset ja .vbk, jos suorituskyvyn laajuudessa on toinen .vbk

Harkitse nyt vaihtoehtoa työskennellä varmuuskopiointiketjujen kanssa. Tänne kuljetettiin vain GFS-säilytyksen piiriin kuuluvat tavarat. Koska kaikkea uudempiin varmuuskopioketjuihin tallennettua voidaan muuttaa tavalla tai toisella.

Katsotaan nyt konepellin alle. Siellä tapahtuu prosessi nimeltä dehydraatio - tyhjien varmuuskopiotiedostojen jättäminen laajuuteen ja lohkojen vetäminen näistä tiedostoista kapasiteetin ampumaradalle. Tämän prosessin optimoimiseksi käytetään ns. dehydraatioindeksiä, jonka avulla voit välttää jo kopioitujen lohkojen kopioimisen kapasiteetin ampumaradalle.

Katsotaanpa, miltä tämä näyttää esimerkin avulla: Oletetaan, että meillä on .vbk, joka tuli ulos tapahtumaikkunasta ja kuuluu suljettuun ketjuun. Tämä tarkoittaa, että meillä on täysi oikeus siirtää se kapasiteetin ampumaradalle. Siirron yhteydessä siirretyn tiedoston kapasiteettiviivaan ja lohkoihin luodaan metatietotiedosto. Linkkitason metatietotiedosto kuvaa, mistä lohkoista tiedostomme koostuu. Kuvan tapauksessa ensimmäinen tiedostomme koostuu lohkoista a, b, c ja metatiedot sisältävät linkkejä näihin lohkoihin. Kun meillä on toinen .vbk-tiedosto, joka on valmis siirrettäväksi ja koostuu lohkoista a, b ja d, dehydraatioindeksiä analysoimalla ymmärrämme, että vain lohko d on siirrettävä. Ja sen metatietotiedosto sisältää linkkejä kahteen edelliseen lohkoon ja yhteen uuteen.

Vastaavasti näiden tyhjien tilojen täyttämistä tiedoilla kutsutaan nesteytykseksi. Se käyttää jo omaa nesteytysindeksiään, joka perustuu vanhimpaan .vbk-tiedostoon paikallisen suorituskyvyn laajuudesta. Eli jos käyttäjä haluaa palauttaa tiedoston kapasiteetin ampumaradalta, luomme ensin hakemiston vanhimman täyden varmuuskopion lohkoista ja siirrämme vain puuttuvat lohkot kapasiteetin ampumagalleriasta. Kuvassa esitetyssä tapauksessa FullBackup1.vbk:n rehydratointiin nesteytysindeksin mukaan tarvitsemme vain lohkon C, jonka otamme kapasiteetin ampumaradalta. Jos tallennuspilviobjekti toimii kapasiteetin ampumaradana, voit säästää valtavia summia rahaa.

Tässä saattaa vaikuttaa siltä, ​​että tämä tekniikka on identtinen WAN-kiihdyttimissä käytetyn kanssa, mutta siltä se vain näyttää. Kiihdyttimissä duplikoinnin poistaminen on globaalia; tässä paikallista duplikointia käytetään kussakin tiedostossa tietyllä siirrolla. Tämä johtuu ratkaistavissa olevien tehtävien eroista: täällä meidän on kopioitava suuria täydellisiä varmuuskopiotiedostoja, ja tutkimuksemme mukaan, vaikka niiden välillä kuluisi pitkä aika, tämä duplikointialgoritmi antaa parhaan tuloksen.

Mutta lisää indeksejä indeksien jumalalle! Tietojen palauttamiseen on myös hakemisto! Kun aloitamme kapasiteettiviivassa sijaitsevan koneen palauttamisen, luemme vain yksilölliset tietolohkot, jotka eivät ole suorituskykyviivassa.

Miten siitä tuli

Siinä kaikki johdanto-osaan. Se on melko yksityiskohtainen, mutta kuten edellä mainittiin, ilman näitä yksityiskohtia ei ole mahdollista selittää kuinka uudet toiminnot toimivat. Sen vuoksi, ilman pitkiä puheita, siirrytään ensimmäiseen.

Kopiointitila

Se perustuu suurelta osin olemassa oleviin teknologioihin, mutta sen käyttölogiikka on täysin erilainen. 

Tämän tilan tarkoituksena on varmistaa, että kaikista paikallisesti sijaitsevista tiedoista on kopio kapasiteettiviivassa.

Jos vertaat siirto- ja kopiointitiloja suoraan, se näyttää tältä:

• Vain suljettua ketjua voidaan siirtää. Kopiointitilassa kaikki siirretään riippumatta siitä, mitä varmuuskopiointityössä tapahtuu.
• Siirto käynnistyy, kun tiedostot ylittävät operatiivisen varmuuskopiointiikkunan rajat, ja kopiointi käynnistyy heti, kun varmuuskopiotiedosto tulee näkyviin.
• Uuden tiedon seurantaa kopioimista varten tapahtuu jatkuvasti, ja siirtämistä varten se laukaistiin 4 tunnin välein.

Uutta tilaa harkitessani ehdotan siirtymistä yksinkertaisista esimerkeistä monimutkaisiin.

Yleisimmässä tapauksessa meillä on yksinkertaisesti uusia tiedostoja, joissa on lisäyksiä, ja kopioimme ne yksinkertaisesti kapasiteetin ampumaradalle. Riippumatta siitä, mitä tilaa varmuuskopiointityössä käytetään, riippumatta siitä kuuluuko se ketjun sinetöityyn osaan vai ei, riippumatta siitä, onko toimintaikkunamme vanhentunut. He vain ottivat sen ja kopioivat sen.

Tämän takana oleva prosessi on edelleen kuivuminen, kuten yllä on kuvattu. Kopiointitilassa se myös varmistaa, että emme kopioi lohkoja, jotka ovat jo tallessamme. Ainoa ero on, että jos elokuvatilassa korvasimme oikeat tiedostot valetiedostoilla, emme kosketa niitä millään tavalla ja jätämme kaiken ennalleen. Muuten se on täsmälleen sama dehydraatioindeksi, joka yrittää huolellisesti säästää rahaa ja aikaa.

Herää kysymys - jos katsot käyttöliittymää, on mahdollisuus valita molemmat vaihtoehdot samanaikaisesti. Miten tällainen yhdistetty tila toimii?

Selvitä se.

Alku on vakio: varmuuskopiotiedosto luodaan ja kopioidaan välittömästi. Siihen luodaan lisäys ja myös kopioidaan. Tätä tapahtuu siihen asti, kunnes huomaamme, että tiedostot ovat poistuneet käyttöikkunastamme ja sinetöity ketju on ilmestynyt. Tässä vaiheessa suoritamme dehydratointitoimenpiteen ja korvaamme nämä tiedostot valetiedostoilla. Emme tietenkään kopioi mitään uudelleen kapasiteetin ampumaradalle.

Kaikki tämä kiehtova logiikka on vastuussa vain yhdestä käyttöliittymän valintaruudusta: Kopioi varmuuskopiot objektimuistiin heti, kun ne on luotu.

Miksi tarvitsemme tätä kopiointitilaa?

Vielä parempi on muotoilla kysymys uudelleen näin: miltä riskeiltä suojaudumme sen avulla? Minkä ongelman se auttaa meitä ratkaisemaan?

Vastaus on ilmeinen: tietysti tämä on tietojen palautus. Jos meillä on täydellinen kopio paikallisista tiedoista objektitallennustilassa, riippumatta siitä, mitä tuotteellemme tapahtuu, voimme aina palauttaa tiedot ehdollisessa Amazonissa sijaitsevista tiedostoista.

Käydään siis läpi mahdolliset skenaariot yksinkertaisimmasta monimutkaisempiin.

Yksinkertaisin onnettomuus, joka voi pudota päähimme, on yhden varmuuskopioketjun tiedostojen saavuttamattomuus.

Surullisempi tarina on, että yksi SOBR-tietovarastomme laajuuksista meni rikki.

Tilanne pahenee entisestään, kun koko SOBR-arkistoon ei ole pääsyä, mutta kapasiteetin ampumarata toimii.
Ja kaikki on todella huonosti - silloin varmuuskopiopalvelin kuolee ja ensimmäinen halusi on yrittää juosta Kanadan rajalle kymmenessä minuutissa.

Katsotaan nyt jokaista tilannetta erikseen.

Kun olemme kadottaneet yhden (ja jopa useamman) varmuuskopiotiedoston, meidän tarvitsee vain käynnistää arkiston uudelleentarkistus ja kadonnut tiedosto korvataan valetiedostolla. Ja käyttämällä nesteytysprosessia (josta keskusteltiin artikkelin alussa) käyttäjä voi ladata tietoja kapasiteetin ampumaradalta paikalliseen tallennustilaan.

Nyt tilanne on monimutkaisempi. Oletetaan, että SOBR koostuu kahdesta Performance-tilassa käynnissä olevasta laajuudesta, mikä tarkoittaa, että .vbk ja .vib ovat jakautuneet niiden päälle melko epätasaisella kerroksella. Ja jossain vaiheessa yksi laajuuksista ei ole käytettävissä, ja käyttäjän on pikaisesti palautettava kone, jonka tiedoista osa on juuri tässä laajuudessa.

Käyttäjä käynnistää ohjatun palautustoiminnon, valitsee pisteen, johon hän haluaa palauttaa, ja ohjattu toiminto työskennellessään tajuaa, että hänellä ei ole kaikkia palautumiseen tarvittavia tietoja paikallisesti ja siksi ne on ladattava kapasiteetin mittauksesta. galleria. Samaan aikaan paikalliseen tallennustilaan jääviä lohkoja ei ladata pilvestä. Kunnia palautusindeksille (kyllä, se mainittiin myös artikkelin alussa).

Tämän tapauksen alatyyppi on se, että koko SOBR-tietovarasto ei ole käytettävissä. Tässä tapauksessa meillä ei ole mitään kopioitavaa paikallisesta tallennustilasta, ja kaikki lohkot ladataan pilvestä.

Ja mielenkiintoisin tilanne on, että varapalvelin kuoli. Tässä on kaksi vaihtoehtoa: järjestelmänvalvoja on loistava ja teki asetusten varmuuskopiot, ja järjestelmänvalvoja on itse paha Pinocchio eikä tehnyt asetusten varmuuskopioita.

Ensimmäisessä tapauksessa riittää, että hän yksinkertaisesti ottaa käyttöön VBR:n puhtaan asennuksen jonnekin ja palauttaa sen tietokanta varmuuskopiosta tavallisilla keinoilla. Tämän prosessin lopussa kaikki palautuu normaaliksi. Tai se palautetaan jonkin yllä olevista skenaarioista.

Mutta jos järjestelmänvalvoja on joko oma vihollisensa tai myös asetusten varmuuskopiointi kärsi eeppisen epäonnistumisen, emme myöskään jätä häntä kohtalon armoille. Tässä tapauksessa olemme ottaneet käyttöön uuden menettelyn nimeltä Import Object Storage. Sen avulla voit ohittaa SOBR-arkiston manuaalisen uudelleenluomisen ja kapasiteetin ampumaradan liittämisen siihen myöhempää uudelleenskannausta varten. Voit yksinkertaisesti lisätä tallennusobjektin Vim-liittymään ja suorittaa Import Storage Repository -menettelyn. Ainoa asia, joka voi olla tiellä sinun ja varmuuskopioidesi välillä, on salasanan pyyntö, jos varmuuskopiosi on salattu.

Tämä koskee luultavasti kopiointitilaa ja siirrymme siihen

Suljettu tila

Pääajatuksena on, että uusia varmuuskopioita ei voi ilmestyä arkiston valitulle SOBR-laajuudelle. Ennen v10:tä meillä oli vain ylläpitotila, jolloin kaikki työ arkiston kanssa oli kokonaan kielletty. Eräänlainen hardcore-tila tallennustilan sulkemiseen, jossa on käytettävissä vain Evacuate-painike, joka siirtää varmuuskopiot toiseen laajuuteen kertaluonteisesti.

Ja suljettu tila on eräänlainen "pehmeä" vaihtoehto: kiellämme uusien varmuuskopioiden luomisen ja poistamme asteittain vanhat valitun säilytyksen mukaan, mutta prosessissa emme menetä kykyä palauttaa tallennetuista pisteistä. Erittäin hyödyllinen asia, kun meillä on joko laitteiston osa lähestymässä käyttöikänsä loppua ja se on vaihdettava tai se on vain vapautettava johonkin tärkeämpään, mutta sitä ei ole paikasta viedä ja siirtää kaikkea kerralla. Tai sitä ei voi poistaa.

Vastaavasti toimintaperiaate on melko yksinkertainen: kaikki kirjoitustoiminnot (uusien tietojen ilmestyminen), lukemisen jättäminen (palautukset) ja poistaminen (säilytys) on kiellettävä.

Molempia tiloja voidaan käyttää samanaikaisesti, mutta muista, että ylläpidolla on korkeampi prioriteetti.

Esimerkkinä voidaan harkita SOBR:ää, joka koostuu kahdesta laajuudesta. Oletetaan, että ensimmäiset neljä päivää loimme varmuuskopiot Forward Forever Incremental -tilassa ja sitten sinetöimme laajuuden, mikä johtaa siihen, että aloitamme uuden aktiivisen täyden luomisen toisella käytettävissä olevalla laajuudella. Jos pidätysmäärämme on neljä, niin kun koko suljetulla alueella sijaitseva ketju ylittää rajansa, se poistetaan puhtaalla omallatunnolla.

On tilanteita, joissa poisto tapahtuu aikaisemmin. Tämä on esimerkiksi Forward inkrementaalinen jaksollisilla täytöillä. Jos loimme täydet varmuuskopiot kahdeksi ensimmäiseksi päiväksi ja torstaina päätämme sinetöidä arkiston, niin perjantaina, kun uusi varmuuskopio luodaan, maanantain tiedosto poistetaan, koska tässä vaiheessa ei ole riippuvuuksia. Eikä itse pointti ole kenestäkään riippuvainen. Sitten odotellaan, kunnes käytettävissä olevalle laajuudelle luodaan neljä pistettä ja poistetaan loput kolme, joita ei voida poistaa toisistaan ​​riippumatta.

Asiat ovat yksinkertaisempia Reverse Incremental -toiminnolla. Siinä vanhimmat pisteet eivät riipu mistään ja ne voidaan turvallisesti poistaa. Siksi heti kun uusi .vbk luodaan uudessa laajuudessa, vanhat .vrb:t poistetaan yksitellen.

Muuten, miksi luomme uuden .vbk:n joka kerta: jos emme luoneet sitä, vaan jatkamme vanhaa lisäysketjua, niin vanha .vbk jäätyisi äärettömän pitkäksi ajaksi missä tahansa tilassa estäen sen poistamisen. Siksi päätettiin, että heti kun laajuus on sinetöity, luomme ilmaisesta laajuudesta täyden varmuuskopion.

Asiat ovat monimutkaisempia kapasiteetin ampumaradalla.

Katsotaanpa ensin kopiointitilaa. Oletetaan, että teimme aktiivisesti varmuuskopioita neljä päivää, ja sitten kapasiteetin ampumarata sinetöitiin. Emme poista mitään, vaan kestämme nöyrästi säilytyksen, jonka jälkeen poistamme tiedot kapasiteetin ampumaradalta.

Suunnilleen sama asia tapahtuu siirtotilassa - odotamme retusointia, poistamme vanhan paikallisesta tallennustilasta ja poistamme objektimuistiin tallennetun.

Mielenkiintoinen esimerkki Foreverin eteenpäin inkrementaalista. Asennamme säilytyksen kolmeen pisteeseen ja aloitamme maanantaina varmuuskopioiden tekemisen, jotka kopioidaan säännöllisesti pilveen. Tallennustilan sulkemisen jälkeen varmuuskopioiden luomista jatketaan säilyttäen kolme pistettä, mutta kapasiteettiviivaan tallennetut tiedot ovat riippuvaisia, eikä niitä voi poistaa. Siksi odotamme torstaihin, jolloin .vbk-tiedostomme ylittää säilytyksen, ja vasta sitten poistamme rauhallisesti koko tallennetun ketjun.

Ja pieni vastuuvapauslauseke: kaikki esimerkit tässä näytetään yhdellä koneella. Jos varmuuskopiossasi on niitä useita, niiden retusointi vaihtelee sen mukaan, tehtiinkö Active Full vai ei.

Siinä on periaatteessa kaikki. Joten siirrytään kaikkein vakavimpaan ominaisuuteen -

muuttumattomuudesta

Kuten edellisissä kohdissa, ensimmäinen asia on se, minkä ongelman tämä toiminto ratkaisee. Heti kun lataamme varmuuskopiomme jonnekin säilytystä varten, on vahva halu taata niiden turvallisuus eli fyysisesti estää niiden poistaminen ja muuttaminen tietyn säilytyksen aikana. Mukaan lukien järjestelmänvalvojat, mukaan lukien heidän juuritilinsä. Näin voit suojata niitä vahingossa tai tahallisilta vaurioilta. Jokainen, joka työskentelee AWS:n kanssa, on voinut tavata samanlaisen ominaisuuden nimeltä Object Lock.

Katsotaanpa nyt tilaa yleisellä tasolla ja sitten syvennytään yksityiskohtiin. Esimerkissämme muuttumattomuus otetaan käyttöön kapasiteetin ampumaradallamme neljän päivän säilytysajalla. Ja kopiointitila on käytössä varmuuskopiossa.

Muuttumattomuus ei ole vuorovaikutuksessa yleisen säilyttämisen kanssa millään tavalla. Se ei esimerkiksi lisää lisäpisteitä tai muuta vastaavaa. Se on vain, että henkilö ei voi poistaa varmuuskopiotiedostoja neljän päivän kuluessa. Jos teet varmuuskopion maanantaina, voit poistaa sen tiedoston vasta perjantaina.

Kaikki aiemmin selitetyt kuivumisen, indeksien ja metatietojen käsitteet toimivat edelleen täsmälleen samoin. Mutta yhdellä ehdolla - lohko ei ole asetettu vain tiedoille, vaan myös metatiedoille. Tämä tehdään siinä tapauksessa, että ovela hyökkääjä päättää tyhjentää metatietotietokantamme ja estää tietolohkojen muuttumisen hyödyttömäksi binäärisoseksi.

Nyt on hyvä aika selittää lohkojen sukupolviteknologiaamme. Tai lohkon sukupolvi. Tätä varten harkitse tilannetta, joka johti sen ilmestymiseen.

Otetaan kuuden päivän aika-asteikko ja alle merkitään muuttumattomuuden odotetun vanhenemisen aika. Ensimmäisenä päivänä otamme ja luomme tiedoston, joka koostuu tietolohkosta a ja sen metatiedoista. Jos muuttumattomuus on asetettu kolmeksi päiväksi, on loogista olettaa, että neljäntenä päivänä tiedot avataan ja poistetaan. Toisena päivänä lisäämme uuden tiedoston2, joka koostuu lohkosta b samoilla asetuksilla. Estä still on poistettava neljäntenä päivänä. Mutta kolmantena päivänä tapahtuu jotain kauheaa - luodaan File3-tiedosto, joka koostuu uudesta lohkosta d ja linkistä vanhaan lohkoon a. Tämä tarkoittaa, että lohkon ja sen muuttumattomuuden lippu on asetettava uuteen päivämäärään, joka siirretään kuudenteen päivään. Ja tässä syntyy ongelma - todellisissa varmuuskopioissa on valtava määrä tällaisia ​​lohkoja. Ja niiden muuttumattomuuden ajanjakson pidentämiseksi sinun on tehtävä valtava määrä pyyntöjä joka kerta. Ja itse asiassa tämä tulee olemaan lähes loputon päivittäinen prosessi, koska suurella todennäköisyydellä löydämme joka kopiosta suuria pinoja kopioituja lohkoja. Mitä objektitallennuspalvelujen tarjoajien suuri määrä pyyntöjä tarkoittaa? Oikein! Valtava lasku kuun lopussa.

Ja jotta suosikkiasiakkaasi ei kertakaikkiaan paljastaisi huomattavia rahoja vastaan, keksittiin lohkon luomismekanismi. Tämä on lisäaika, jonka lisäämme asetettuun muuttumattomuusjaksoon. Alla olevassa esimerkissä tämä ajanjakso on kaksi päivää. Mutta tämä on vain esimerkki. Todellisuudessa he käyttävät omaa kaavaansa, joka antaa kuukausilukon aikana noin kymmenen lisäpäivää.

Jatketaan saman tilanteen tarkastelua, mutta lohkon generoinnilla. Ensimmäisenä päivänä luomme tiedosto1 lohkosta a ja metatiedoista. Laskemme yhteen sukupolven jakson ja muuttumattomuuden - tämä tarkoittaa, että mahdollisuus poistaa tiedosto on kuudentena päivänä. Jos toisena päivänä luomme Tiedosto2:n, joka koostuu lohkosta b ja linkistä lohkoon a, niin odotetulle poistopäivämäärälle ei tapahdu mitään. Hän seisoi samoin kuin kuudentena päivänä. Ja näin yritämme säästää rahaa pyyntöjen määrässä. Ainoa tilanne, jossa määräaikaa voidaan siirtää, on, jos sukupolvijakso on umpeutunut. Eli jos kolmantena päivänä uusi File3 sisältää linkin estämään a, sukupolvi 2 lisätään, koska Gen1 on jo vanhentunut. Ja odotettu päivämäärä lohkon a poistamiselle siirtyy kahdeksanteen päivään. Tämä antaa meille mahdollisuuden vähentää dramaattisesti pyyntöjen määrää pidentää duplikoitujen lohkojen käyttöikää, mikä säästää asiakkailta tonnin rahaa.

Itse tekniikka on S3- ja S3-yhteensopivien laitteiden käyttäjien saatavilla, joiden valmistajat takaavat, että niiden toteutus ei poikkea Amazonin toteutuksesta. Siten vastaus oikeutettuun kysymykseen, miksi Azurea ei tueta - niillä on samanlainen ominaisuus, mutta se toimii säilöjen tasolla, ei yksittäisten objektien tasolla. Muuten, Amazonilla itsellään on objektilukko kahdessa tilassa: vaatimustenmukaisuus ja hallinto. Toisessa tapauksessa on olemassa mahdollisuus, että suurin ylläpitäjä järjestelmänvalvojien yläpuolella ja pääkäyttäjä juurien yläpuolella, objektilukosta huolimatta, silti poistaa tiedot. Vaatimustenmukaisuuden tapauksessa kaikki on naulattu tiukasti eikä kukaan voi poistaa varmuuskopioita. Jopa Amazon-järjestelmänvalvojat (heidän virallisten lausuntojensa mukaan). Tätä tilaa tuemme.

Ja kuten tavallista, hyödyllisiä linkkejä:

• Про Estä sukupolvi jokaisessa yksityiskohdassa.
• Kaikki tiedot aiheesta Veeam Backup & Replication 10 parhaimmillaan
• О Kapasiteettitaso yksityiskohtaisesti

Lähde: will.com