I Vi har berÀttat om de nya funktionerna i den nyligen slÀppta januariuppdateringen Update 4 för Veeam Backup & Replication 9.5 (VBR), dÀr vi medvetet inte nÀmnde sÀkerhetskopiering till magnetband. BerÀttelsen om detta omrÄde förtjÀnar en egen artikel, eftersom det faktiskt har funnits mÄnga nya funktioner.
â Killarna frĂ„n QA, ska ni skriva en artikel?
â Varför inte!
Magnetband i XXI Ă„rhundrade
Lagring av data pÄ magnetband (kassetter, "tape"", som vi kallar dem i R&D) begrÀnsas inte lÀngre av den utdöda datorn ZX-Spectrum, vars spel kunde laddas in i RAM-minnet pÄ 48 kb frÄn under flera minuter. Under en kvartsekel har hastighet och kapacitet för kassetter ökat med 6-7 storleksordningar. Detta Àr inte helt korrekt jÀmförelse, och enligt standarden LÄt mig komma in frÄn en annan vinkel. PÄ senare tid
har utpressningsvirus , nÀr företaget tvingades betala utpressarna. SÄ kallade air gap , det vill sÀga fysiskt isolerade sÀkerhetskopior frÄn infrastrukturen har i princip blivit den enda pÄlitliga rÀddningen frÄn sÄdana situationer. Magnetband Àr hÀr en av de tidlösa lösningarna.Men bara specifikationer och teknologiska nyheter frÄn ledande tillverkare (IBM, HPE, Oracle, Dell) Àr inte tillrÀckliga för att pÄlitligt skydda data, det krÀvs bra mjukvara. Vi har ett helt team pÄ Veeam som arbetar med bandbackuper, cirka 10 personer analyserar, planerar, forskar, utvecklar och testar dagligen. Resultaten av detta arbete har ni kunnat se i tidigare artiklar (
). Vad har gjorts under det senaste Ă„ret?, ). Vad har gjorts under det senaste Ă„ret?
Ordlista
Det uppstÄr ett val mellan friheter i förhÄllande till det egna sprÄket och byrÄkratiska uttryck som försvÄrar lÀsbarheten. Jag föredrar det första, dÀrför ber jag pÄ förhand om ursÀkt om vissa jargongord hÀr nedan kan störa nÄgon. Jag pÄminner hÀr kort om vad varje term betyder.
Experter pĂ„ VBR kan hoppa över denna del.Jobb â jobb â en backup-uppgift. Egentligen bygger hela VBR pĂ„ jobb. Förutom backup och replikering kan det ocksĂ„ vara kopiering till magnetband (backup to tape job, tape job). Jag vill nĂ€mna att Ă„terstĂ€llning frĂ„n backup (restore) ocksĂ„ Ă€r ett jobb, men i denna artikel kommer ordet att syfta pĂ„ just backup.
Lagring â lagring â en historiskt etablerad term. Det handlar om filer i förrĂ„det (repository â lagringsplats) som innehĂ„ller backup-kopior â fullstĂ€ndiga och inkrementella. I en lagringsplats kan det finnas en eller flera virtuella maskiner.
Kedja â kedja â en sekvens av relaterade lagringsplatser. För att Ă„terstĂ€lla data frĂ„n den n:te inkrementella lagringsplatsen behövs alla föregĂ„ende frĂ„n den (n-1):a till den första och den kompletta lagringsplats som den första inkrementella hĂ€nvisar till.
KĂ€lla, mĂ„l â source, target. KĂ€lla â den ursprungliga entitet som bearbetas av jobbet. I fallet med backup/replikats Ă€r det vanligtvis en virtuell maskin i hypervisorn. I fallet med tape-job Ă€r kĂ€llan sjĂ€lva backup-jobbet (eller filer i fallet med file to tape-job). MĂ„l för backup-jobbet Ă€r lagringsplatsen dĂ€r backuperna lagras. För tape-job Ă€r det dock mediepoolen.
Mediepool â â en samling informationsbĂ€rande medier, i vĂ„rt fall â kassettband. En logisk behĂ„llare, skapad av anvĂ€ndaren och innehĂ„llande kassetter frĂ„n en eller flera bibliotek. SĂ„ledes har en tape-job alltid en mediepool som mĂ„l, vilket innebĂ€r att data skrivs inte pĂ„ en specifik kassett och inte pĂ„ vilken kassett som helst i biblioteket, utan pĂ„ ett visst set av dem. Mediepoolen har en instĂ€llning för datalagringstid, efter vilken kassetten kan skrivas över. AnvĂ€ndaren kan skapa vanliga (standard) och . Varje typ kan nu dessutom vara WORM och icke-WORM, mer om detta nedan.
Medieset â â ett set med kassetter i mediebassĂ€ngen, pĂ„ vilka backups/filer kontinuerligt skrivs. För GFS-bassĂ€nger har mediesĂ€ten Ă€ven koppling till intervall (till exempel Ă„rligt â yearly), kassetterna roteras endast inom sitt eget intervall.
â element i en tape-bibliotek. Enheten lĂ€ser och spolar kassetten, vĂ€xlaren â det Ă€r en robot som flyttar kassetter mellan lagringsplatser, utladdningsplatser och enheten. Det finns Ă€ven st standalone-enheter (standalone â fristĂ„ende), dĂ€r rollen som vĂ€xlare utförs av en mĂ€nniska. För enheten krĂ€vs en korrekt installerad tillverkares drivrutin pĂ„ Windows-datorn dĂ€r biblioteket Ă€r anslutet; med vĂ€xlaren kan vi dock arbeta Ă€ven utan drivrutiner, via native SCSI.
Tenant till tape. Skyddad av leverantören â skyddat för kunder
SlÄ ut korten direkt. Den mest omfattande funktionen i vÄr uppdatering, avsedd för , som anvÀnder VBR i sin infrastruktur. Utvecklingen började för tvÄ Är sedan. Snart insÄg vi att vi inte skulle hinna med en sÄ stor uppgift till nÀsta release, vi tog en liten paus, och slutligen slÀppte vi funktionen i 9.5 Update 4.
Kort sagt, nu har leverantörerna möjlighet att kopiera backups av sina kunder till kassetter med hjĂ€lp av tape-jobb i GFS-bassĂ€ngen. Detta ger leverantörerna â och detta Ă€r verkligen stora, dyra killar för vĂ„rt hjĂ€rta och vĂ„r kommersiella avdelning â tvĂ„ möjligheter:
- att skydda sina kunder (tenants, tenant â hyresgĂ€st) frĂ„n dataförlust pĂ„ grund av oavsiktlig radering eller infrastrukturella problem ("översvĂ€mning i serverrummet");
- att erbjuda hyresgÀsterna en extra tjÀnst för datarÀddning frÄn en gammal backup, som lÀnge har tagits bort frÄn den molnbaserade lagringspolicyn, men som fortfarande finns kvar pÄ kassetterna.
Ur ett marknadsföringsperspektiv Ă€r funktionaliteten mycket "aptitretande", men ur vĂ„rt perspektiv â minst lika komplex att implementera.
Utveckling
Det huvudsakliga problemet som uppstod â datakryptering. De flesta molnbaserade backups Ă€r krypterade, statistiken visar pĂ„ â av det totala antalet. För oss var denna siffra en överraskning, vi trodde att nĂ€stan allt var krypterat, men nej â mĂ„nga kunder verkar ha fullstĂ€ndig tillit till sina leverantörer.
Paradigmen Àr enkel: en leverantör ska inte kunna dekryptera sina klienters data. Inom ramen för den nya funktionen krÀvs det att leverantören öppnar lagringsutrymmen med backup. Detta behövs för att flytta datablokker, t.ex. för att skapa . Det viktigaste Àr att detta mÄste göras oberoende av klienten, nÀr de nödvÀndiga nycklarna inte överförs till leverantörens sida under jobbets genomförande.
Lösningen pĂ„ detta problem, som Ă€ven anvĂ€ndes i en annan viktig funktion i den nya uppdateringen â â bestĂ„r i att lĂ€gga till en ytterligare krypteringsnyckel. Arkiveringsnyckeln (Archive key) lagras krypterad i leverantörens databas. Genom en smart metod kan den anvĂ€ndas av leverantören för att öppna lagringen, flytta och rekryptera datablock mellan lagringsutrymmen (eftersom var och en har sin egen nyckel), men sjĂ€lva datan kan inte dekrypteras.
Den smarta metoden (arbetsversionen)
Jag vill lÀgga till att alla ingenjörer inom R&D verkligen Àlskar kryptering i vÄr produkt, men ingen vet i detalj hur det fungerar. (Det fanns ett skÀmt om 'och varför det fungerar överhuvudtaget', men det slÀppte redaktörerna inte igenom.)
Testning
Till funktionen registrerades hundratals buggar. De mest komplexa omrĂ„dena â kryptering, anvĂ€ndargrĂ€nssnitt, problem vid Ă„terstĂ€llning.
Sett ur testperspektiv var svĂ„righeten stor variabilitet, 'kombinatorik' av typer och typer av klientjobb och förrĂ„d â jag syftar pĂ„ bĂ„de kĂ€llan och mĂ„let vid Ă„terstĂ€llning av backup till infrastrukturen. Allt detta Ă€r kopplat till logiken inom (inklusive den nya â parallellisering och dagliga medieset, mer om detta nedan), och generellt inom den ovanliga specifikationen för typer inom molnet. Glöm inte att krydda med kryptering. För att fortsĂ€tta metaforen, har vi verkligen överĂ€tit denna rĂ€tt â men ocksĂ„ smakat pĂ„ den frĂ„n alla sidor.
Fragment av testplanen
Som ett resultat
En detaljerad beskrivning finns i (Àn sÄ lÀnge pÄ engelska): , . Jag stannar vid de viktigaste punkterna.
NÀsta prioritet kan vara backup av enheternas konfigurationer. Oavsett vad Àr detta en mycket viktig punkt. Jag kommer inte att nÀmna de fall nÀr du kan förlora konfigurationen, det Àr bÀttre att regelbundet göra backup och inte tÀnka pÄ det. Dessutom kan regelbunden backup vara mycket vÀrdefullt vid förÀndringskontroll.
Leverantören lÀgger till klienter i typjobbet med GFS-poolen som mÄl. Om det finns en molnlicens Àr alternativet pÄ det andra steget av guiden tillgÀngligt TenantsDu kan lÀgga till alla tenants pÄ en gÄng eller en och en, och dessutom vÀlja endast en specifik kvot (men inte en subkvot) frÄn en separat tenant. Det gÄr inte att blanda tenant-backuper med vanliga lokala backuper i en och samma jobb.
De övriga instÀllningarna Àr nÀstan helt identiska med en vanlig jobb i GFS-poolen.
à terstÀllning av data kan göras bÄde frÄn leverantörens sida och frÄn tenantens egen sida.
à terstÀllning frÄn leverantörens sida
Utförs genom en ny wizard. HÀr kan du Àven gÄ ner till en specifik jobb, hela kedjan som fanns i arkivet vid en viss tidpunkt ÄterstÀlls.
Det finns tre alternativ för ÄterstÀllning:
- Till den ursprungliga platsen. I detta fall raderas den ursprungliga backupen, om den finns, och tenantens jobb omkonfigureras automatiskt till den ÄterstÀllda kedjan. Det förutsÀtts att en sÄdan ÄterstÀllning praktiskt taget Àr omÀrkt för kunden, endast under en kort tid kommer de att vara avstÀngda frÄn det molnbaserade arkivet.
- Till en ny kvot/arkiv. Leverantören kan, till exempel, skapa ett separat temporÀrt konto för detta ÀndamÄl, som senare tas bort. Backupen dyker upp i tenantens infrastruktur efter synkronisering med leverantörens databas.
- Direkt till disken pÄ en Linux- eller Windows-server som Àr registrerad i leverantörens infrastruktur. Denna kedja kan sedan kopieras till ett USB-minne och skickas till tenant.
à terstÀllning frÄn tenantens sida
Detta alternativ förutsÀtter att kunden har sin egen tape-infrastruktur och en stor mÀngd data för ÄterstÀllning. Bandet med inspelade backuper kan leverantören fysiskt skicka till kunden med en leveranstjÀnst, kunden katalogiserar det pÄ sin egen utrustning, avkodar banden och backuperna och arbetar med de reservkopiorna som om de sjÀlv hade spelat in dem pÄ bandet. En sÄdan livrÀddare för att slippa ladda ner terabyte över WAN.
Storskaliga förbÀttringar i GFS-poolen
-media-pooler introducerades i VBR för tvÄ Är sedan, i version 9.5. I den nyligen utfÀrdade uppdateringen, dels pÄ grund av funktionen Tenant to tape, men ocksÄ pÄ begÀran av anvÀndare, har vi verkligen förbÀttrat denna funktionalitet.
Dagliga medieset
Det har kommit en ny daglig (daily) medieset. Nu kan backups lagras i GFS-poolen varje dag, och inte bara fullstÀndiga, utan Àven inkrementella. De senaste tar betydligt mindre utrymme och detta görs för att spara bandbredd. Det antas att dessa kassettband alltid roteras i biblioteket och inte transporteras för lÄngtidslagring. För restaureringen behöver inkrementella punkter kassettband frÄn en av de Àldre medieseten (veckovis, mÄnadsvis, kvartalsvis eller Ärsvis). Det gÄr inte att aktivera det dagliga mediesetet utan att aktivera det veckovisa, för att i de flesta fall krÀvas veckokassetter för ÄterstÀllning frÄn en inkrementell kopia. Dessa finns antingen alltid i biblioteket eller lagras pÄ ett mindre avlÀgset lager.
Logiken bakom tape-jobbar i GFS-mediepul , tekniska skribenter skulle inte motsĂ€ga det. För att sammanfatta pĂ„ tvĂ„ ord, utan detaljer, kopieras endast fullstĂ€ndiga backups (inklusive virtuella fullstĂ€ndiga backups) i veckobanden och Ă€ldre medieset, ett för varje datum, medan i det dagliga â alla backups som finns i repositoryn för den aktuella dagen, eftersom backup-jobben kan köras oftare Ă€n en gĂ„ng om dagen.
Parallellism, starttid och vÀntetid i GFS-poolingarna
Nu Àr parallell inspelning av flera kedjor eller jobb pÄ flera enheter i biblioteket möjligt Àven i GFS-mediepuler (tidigare endast i vanliga). Detta slÄs pÄ i steg Options mediepul.
Viktig anmÀrkning: samma fil skrivs alltid i en trÄd, sÄ vid flera stora virtuella maskiner rekommenderas att aktivera , för att backupen ska bestÄ av flera kedjor.
Dessutom har det blivit möjligt att vĂ€lja starttiden för sjĂ€lva GFS-jobben. MĂ„nga anvĂ€ndare tyckte inte om att de startade vid midnatt och sedan fick vĂ€nta nĂ€stan en hel dag tills kĂ€lljobbet var klart. Nu kan man exempelvis stĂ€lla in denna tid för sent pĂ„ kvĂ€llen, nĂ€r det redan finns nĂ„got att kopiera till bandet. Dessutom, pĂ„ begĂ€ran av anvĂ€ndarna, har vi flyttat optionen till avancerade instĂ€llningar, som tidigare endast kunde aktiveras via ett registreringsnyckel. Det rĂ€cker att vĂ€lja Bearbeta den senaste Ă„terstĂ€llningspunkten istĂ€llet för att vĂ€nta â och det som finns i repositoryt vid starten av tape-jobbet kopieras till kassettbandet (punkten frĂ„n dagen innan, till exempel), det finns ingen vĂ€ntetid alls.
FörbÀttrad hantering av flera bibliotek
Vi kommer att prata om situationen nÀr fler Àn ett bibliotek har lagts till i en mediepool. Vi har haft stöd för detta tidigare, men ibland har kunder klagat pÄ oförutsÀgbart beteende.
Det var
Till exempel, en tape-jobb startades, den anvÀnde tvÄ enheter i det första biblioteket, men parallellinstÀllningarna tillÄter den att anvÀnda upp till 4 enheter. Ska detta jobb vÀxla till det andra biblioteket i mediepullen och anvÀnda det ocksÄ, eller kommer det att leda till överanvÀndning av resurser?
Ett annat exempel. Alternativet "inga tillgÀngliga kassett" Àr valt, i det första biblioteket finns det bara en kassett, men den kan potentiellt rymma all data. Men instÀllningarna tillÄter att skriva parallellt pÄ tvÄ kassettar. Ska det andra biblioteket anvÀndas i detta fall?
Vi har beslutat att ordna upp detta omrÄde genom att ge möjlighet att konfigurera beteendet tydligt.
Det blev
har fĂ„tt roller â aktiv och passiv. Och sjĂ€lva mediepullen har tvĂ„ lĂ€gen: redundanta, eller failover (failover) och parallellinspelning (paralleling). Nu kan mediepullen konfigureras olika beroende pĂ„ krav.
- Om du har flera jĂ€mbördiga bibliotek och behöver parallellisera inspelning i dem â aktivera parallellinspelning, för detta mĂ„ste alla bibliotek tilldelas aktiva roller. I detta fall kommer nya kassettar och enheter att anvĂ€ndas omedelbart, sĂ„ snart behovet uppstĂ„r, oavsett vilket bibliotek de finns i. Det finns Ă€ndĂ„ en prioritet â först kommer vi att försöka hitta resurser i det bibliotek som ligger högre upp pĂ„ listan.
- Men om det finns ett huvudbibliotek och en gammal eller stand-alone-enhet i reserv, aktivera failover-lÀget, sÀtt huvudbiblioteket högst upp pÄ listan och vÀlj passiv roll för reserv-enheterna. VÀxling till en sÄdan enhet kommer att ske endast nÀr det verkligen behövs, sÄ att jobbet kan fungera överhuvudtaget. En sÄdan situation kommer att betraktas som en nödsituation, och en avisering kommer att skickas via e-post.
Det finns en mer komplex situation som vi för nĂ€rvarande inte stöder â flera aktiva bibliotek vid nĂ€rvaro av passiva. Ă terkopplingen kommer att visa om det finns ett behov av sĂ„dana konfigurationer och om funktionen behöver "justeras" i framtiden. Standardpraxis.
Stöd för WORM
WORM â Write Once Read Many â kassett som inte kan raderas eller skrivas om , man kan endast skriva till. Deras obligatoriska anvĂ€ndning regleras av reglerna frĂ„n vissa organisationer, exempelvis de som arbetar inom medicin. Huvudproblemet med sĂ„dana kassetter tidigare var att VBR vid eller registrerade en rubrik som sedan inte kunde raderas, vilket orsakade att tape-jobb misslyckades vid ett sĂ„dant försök.
I 9.5 Update 4 har fullstÀndigt stöd för sÄdana kassetter implementerats. WORM-mediapooler har lagts till, bÄde vanliga och GFS, dit man endast kan placera kassetter av denna typ.
Nya kassetter har en blÄ, "fryst" ikon. Ur anvÀndarens synvinkel skiljer sig arbetet med WORM-kassetter inte frÄn arbetet med vanliga.
"Wormigheten" hos kassetter definieras ursprungligen av suffixet , om streckkoden Àr vanlig eller olÀslig ger drivrutinen information vid första insÀttning av kassetten. Det gÄr inte att placera WORM-kassetter i en vanlig mediapool och skriva till dem. Roligt nog har det redan funnits anvÀndare som klistrat WORM-streckkoder pÄ vanliga kassetter och blivit förvÄnade över förÀndringarna i sin infrastruktur efter uppdateringen.
Chip pÄ kassetten
Parallellt med införandet av icke-överskrivbara kassetter har vi börjat arbeta med . Standardattributen i chipet anvÀndes tidigare inte av oss, men nu skriver vi och lÀser i vissa av dem, men vi betraktar dem inte som den primÀra datakÀllan. Huvudfokuset Àr fortfarande rubriken pÄ kassetten. Denna lösning har visat sig vara korrekt: efter en mÄnads tid efter releasen ser vi hur anvÀndarnas "zoo" av hÄrdvara överraskar oss nÀr det gÀller att arbeta med chipet.
Backup av NDMP-volymer till band
Avslutningsvis â om den mest efterfrĂ„gade funktionen i detta uppdatering, baserat pĂ„ antalet Ă„terkopplingar. Backup av NDMP-volymer till kassetter har blivit tillgĂ€ngligt. I VBR-infrastrukturen mĂ„ste , efter vilket det i filtapjobbet blir möjligt att vĂ€lja volymer frĂ„n denna vĂ€rd. De lĂ€ggs pĂ„ kassett i form av filer med en speciell attribut för att skilja dem frĂ„n vanliga vid katalogisering.
I den första implementeringen finns det vissa begrĂ€nsningar: förlĂ€ngningar (extensions) stöds inte, plus backup och Ă„terstĂ€llning av endast hela volymer Ă€r möjlig, men inte av enskilda filer. Backup fungerar via (i fallet med NetApp â ), hĂ€r finns sina specifika egenskaper: maximala antalet inkrementella punkter Ă€r 9, efter vilket en fullstĂ€ndig sĂ€kerhetskopia tvingas.
Som en avslutning
Detta var bara de mest betydande nyheterna inom backup pĂ„ magnetband i VBR 9.5 Update 4. Ăvriga förĂ€ndringar listas:
- möjlighet att ange ordningen för kÀlljobb och filer i tape-jobb;
- en roll för Tape Operator har lagts till (anvĂ€ndaren kan göra allt utom Ă„terstĂ€llning frĂ„n band â pĂ„ detta finns Restore Operator);
- fullstÀndiga include/exclude-maskar har lagts till i filtapjobbet (förutom NDMP);
- Ă„terstĂ€llningen i filtapjobbet har förbĂ€ttrats (mappen Ă„terstĂ€lls med de filer som fanns dĂ€r vid backup-tillfĂ€llet, och inte med alla som nĂ„gonsin funnits dĂ€r under hela sin backup-historik â en mycket efterfrĂ„gad funktion, för övrigt);
- ÄterstÀllningshastigheten för ett mycket stort antal filer frÄn kassett har ökat;
- algoritmen för val av nÀsta kassett för skrivning har förbÀttrats, sÀrskilt nÀr andra faktorer Àr lika, tar vi hÀnsyn till mÀngden data som skrivits/lÀsts under hela dess livstid, vi tar den mest aktuella;
- produktens stabilitet har förbÀttrats.
Nyttiga lÀnkar
För att variera, hÀr Àr nÄgra lÀnkar till rysksprÄkiga resurser:
- Och vi har Ă„terigen lagt upp informationsvideor «Hur det fungerar» (Ă€ven om de fortfarande Ă€r pĂ„ engelska) â du kan kika pĂ„ . Det handlar om band pĂ„ sidorna 95 â 102.
KĂ€lla: habr.com
