I Vi har fortalt dig om de nye funktioner i januaropdateringen Update 4 til Veeam Backup & Replication 9.5 (VBR), hvor vi bevidst ikke nÊvnte backup pÄ magnetiske bÄnd. En beretning om dette omrÄde fortjener en egen artikel, da der faktisk var mange nye funktioner.
â Hej QA-folk, kunne I skrive en artikel?
â Hvorfor ikke!
BĂ„ndopbevaringslĂžsninger i det 21. Ă„rhundrede
Opbevaring af data pÄ magnetbÄnd (kassetter, "bÄnd", som vi i R&D kalder dem) er ikke begrÊnset til den forÊldede ZX-Spectrum computer, hvor et spil kunne indlÊses i RAM pÄ 48 kb fra i flere minutter. I lÞbet af et kvart Ärhundrede er hastigheden og kapaciteten af kassetter steget med 6-7 stÞrrelsesordener. Dette er ikke en helt korrekt sammenligning, og i henhold til standard kan det ikke fÞlge med. Alligevel gÞr moderne teknologi det muligt at registrere 12 terabyte data pÄ en kilometers lang tape (op til 30 terabyte i komprimeret tilstand), sÄledes at den 160-dollar lagerlÞsning overstiger konkurrenterne i omkostningerne til langvarig opbevaring af store datamÊngder selv under hensyntagen til investeringer i udstyr til optagelse/afspilning. Data pÄ disse kassetter opbevares sikkert i 15-30 Är.
Jeg vil tage et andet perspektiv. I den seneste tid blevet lĂžftet til et nyt niveau. De kan vente pĂ„ deres chance i en stor virksomheds infrastruktur i uger og mĂ„neder, og med fremkomsten af en ny nul-dages sĂ„rbarhed â ĂždelĂŠgge (ikke uden menneskelig hjĂŠlp, da der stĂ„r mange penge pĂ„ spil) ikke kun alle data, men ogsĂ„ alle backup-kopier, som det er muligt at fĂ„ fat i. Her , hvor virksomheden blev nĂždt til at betale til hackerne. SĂ„kaldte air gap, det vil sige fysisk isolerede backups fra infrastrukturen, er blevet i praksis den eneste pĂ„lidelige redning mod sĂ„danne situationer. MagnetbĂ„nd her er en af de tidlĂžse lĂžsninger.
Men en specifikation og teknologiske jern- og barium-ferritnyheder fra fÞrende producenter (IBM, HPE, Oracle, Dell) er ikke nok til pÄlidelig databeskyttelse; der er brug for god software. Hos Veeam har vi et helt team, der beskÊftiger sig med bÄnd-backups, omkring 10 personer analyserer, planlÊgger, forsker, udvikler og tester dagligt. Resultaterne af dette arbejde kunne I se i tidligere artikler (, ). Hvad er der blevet gjort det sidste Är?
Glossar
Der er et valg mellem friheder i forhold til sit modersmÄl og kompleksiteter, der besvÊrliggÞr lÊsningen. Jeg foretrÊkker det fÞrste, sÄ jeg beder pÄ forhÄnd om undskyldning, hvis nogen af de fagtermer, der fremgÄr af listen nedenfor, skulle irritere Þjet. Her vil jeg kort minde om, hvad hver termer betyder.
VBR-eksperter kan springe dette afsnit over.Job â job â en backup-opgave. Egentlig er hele VBR bygget op omkring jobs. Udover backup og replikering kan det ogsĂ„ vĂŠre kopiering til magnetbĂ„nd (backup to tape job, tape job). Jeg vil prĂŠcisere, at gendannelse fra en backup (restore) ogsĂ„ er et job, men i denne artikel vil dette ord specifikt referere til backup.
Lager â storage â et historisk navn. Det er filer i repository (repository â lager), der indeholder backupfiler â komplette og inkrementelle. I et lager kan der vĂŠre bĂ„de Ă©n og flere virtuelle maskiner.
KĂŠde â chain â en sekvens af relaterede lagerelementer. For at gendanne data fra det n-te inkrementelle lager skal alle tidligere fra (n-1)-te til 1. og det komplette lager, som det fĂžrste inkrementelle refererer til, bruges.
Kilde, mĂ„l â source, target. Kilden er den oprindelige enhed, som jobbet behandler. I tilfĂŠlde af backuper/replikeringer er dette normalt en virtuel maskine i hypervisoren. I tilfĂŠlde af en tape job er kilden selve backup-jobbet (eller filer i tilfĂŠldet af file to tape-job). MĂ„let for backup-jobbet er det repository, hvor backuperne opbevares. For tape-jobbet er det derimod medie-poolen.
Medie-pool â â en samlet pulje af informationsbĂŠrer, i vores tilfĂŠlde â kassetter. En logisk beholder, der oprettes af brugeren og indeholder kassetter fra Ă©n eller flere biblioteker. SĂ„ledes har en tape-job altid en medie-pool som mĂ„l, hvilket betyder, at data ikke skrives til en bestemt kassette eller til en vilkĂ„rlig kassette i biblioteket, men til et specifikt sĂŠt af dem. Medie-poolen har en indstilling for datalagringstid, hvorefter kassetten kan overskrives. Brugeren kan oprette bĂ„de almindelige (standard) og . Hver af disse typer kan nu ogsĂ„ vĂŠre WORM eller ikke-WORM, om dette nedenfor.
Medie-sĂŠt â â sĂŠt med kassetter i mediebunken, som kontinuerligt indeholder sikkerhedskopier/filer. For GFS-bunker har mediesĂŠt ogsĂ„ tilknytning til intervallet (for eksempel Ă„rlig â yearly), kassetterne roteres kun inden for deres eget interval.
â elementer af bĂ„ndbiblioteket. Drevet lĂŠser og spoler kassetten, diskchangeren â en robot, der flytter kassetter mellem opbevaringspladser, aflastningspladser og drevet. Der findes ogsĂ„ standalone-drev (standalone â fritstĂ„ende), hvor rolle som diskchanger udfĂžres af en person. For drevet er korrekt installerede produktoprindelige drivere pĂ„ Windows-maskinen, som biblioteket er tilsluttet, nĂždvendigt; med diskchanger kan vi dog arbejde uden drivere, via native SCSI.
Tenant to tape. Beskyttet leverandĂžr â beskyttede kunder
LÊg uglerne pÄ bordet. Den mest omfattende funktion i vores opdatering, designet til , der bruger VBR i deres infrastruktur. Udviklingen blev pÄbegyndt for to Är siden. Kort efter indsÄ vi, at vi ikke kunne klare en sÄ alvorlig opgave til den kommende udgivelse, tog en kort pause, og i sidste ende udsendte vi funktionen i 9.5 Update 4.
Kort sagt, har leverandĂžrer nu mulighed for at kopiere deres kunders sikkerhedskopier til kassetter ved hjĂŠlp af tape-job i GFS-bunken. Dette giver leverandĂžrerne â som er meget dyre for vores hjerter og salgsafdeling â to muligheder:
- at beskytte deres kunder (tenanter, tenant â lejer) mod datatab som fĂžlge af utilsigtet sletning eller infrastrukturelle problemer (âoversvĂžmmelse i serverrummetâ);
- at give tenanterne en ekstra tjeneste til datagendannelse fra en gammel sikkerhedskopi, der for lÊngst er slettet fra cloud-repositoriet i henhold til dataopbevaringspolitikken, men stadig er bevaret pÄ kassetter.
Fra et markedsfĂžringsmĂŠssigt synspunkt er funktionaliteten meget "tiltrĂŠkkende", men for os er den ikke mindre kompleks at implementere.
Udvikling
Det primĂŠre problem, vi stĂ„r over for, er datakryptering. De fleste cloud-sikkerhedskopier er krypteret, statistikken indikerer, at â af det samlede antal. For os var dette tal en overraskelse; vi antog, at nĂŠsten alt blev krypteret, men nej â mange kunder ser ud til ubetinget at stole pĂ„ deres leverandĂžrer.
Paradigmet er simpelt: udbyderen mÄ ikke kunne dekryptere sine lejeres data. I den forbindelse krÊves det, at udbyderen Äbner lagre med sikkerhedskopier. Dette er nÞdvendigt for at kunne flytte datablokke, for eksempel for at oprette . Det er vigtigt at gÞre dette uafhÊngigt af lejeren, nÄr de nÞdvendige nÞgler ikke overfÞres til udbyderen under udfÞrelsen af jobbet.
LĂžsningen pĂ„ dette problem, som ogsĂ„ blev anvendt i en anden vigtig funktion i det nyligt udgivne tillĂŠg â â bestĂ„r i at tilfĂžje en ekstra krypteringsnĂžgle. ArkivnĂžglen (Archive key) opbevares i udbyderens database i krypteret form. Ved hjĂŠlp af en smart ordning kan udbyderen Ă„bne lageret med denne nĂžgle, flytte og re-kryptere datablokke mellem lagrene (for hvert har sin egen nĂžgle), men kan ikke dekryptere selve dataene.
Den smarte ordning (arbejdsversion)
Jeg vil tilfÞje, at alle ingeniÞrer i R&D elsker kryptering i vores produkt, selvom ingen kender alle detaljerne om, hvordan det fungerer. (Der var ogsÄ en vittighed "og hvorfor det overhovedet fungerer", men den blev ikke godkendt af redaktÞrerne.)
Testning
Der blev registreret hundreder af fejl pÄ funktionen. De mest komplekse omrÄder var kryptering, brugergrÊnseflade og problemer ved gendannelse.
Fra et testningsperspektiv udgjorde den store variabilitet, 'kombinatorikken' af typer og slags lejerjobs og repositories en udfordring â jeg mener bĂ„de kilde og mĂ„l ved gendannelse af sikkerhedskopier til infrastrukturen. Alt dette hĂŠnger sammen med logikken inden for (herunder den nye â parallelisme og daglige mediesĂŠt, om dette nedenfor), samt den generelt uvante sky-specifikke karakter for typerne. Glem ikke at krydre det rigt med kryptering. Hvis vi fortsĂŠtter metaforen, har vi virkelig fĂ„et nok af denne ret â men ogsĂ„ smagt pĂ„ den fra alle sider.
Afsnit af testplanen
Som et resultat
En detaljeret beskrivelse kan findes i (indtil videre pÄ engelsk): , . Jeg vil fokusere pÄ de vÊsentlige punkter.
Backup
Udbyderen tilfÞjer lejere til type-jobbet med GFS-puljen som mÄl. NÄr der er en skylicens, er der pÄ det andet trin i wizard'en en tilgÊngelig indstilling LejereDu kan tilfÞje alle lejedommene pÄ én gang eller enkeltvis, og du kan ogsÄ vÊlge kun en separat kvote (men ikke underkvoten) fra en bestemt lejedom. Det er ikke muligt at blande lejedomsbackups og almindelige lokale backups i én job.
De Ăžvrige indstillinger er nĂŠsten helt identiske med en almindelig job i GFS-poolen.
Datarestaurering er mulig bÄde fra udbyderens side og fra lejedommens egen side.
Restaurering fra udbyderens side
UdfÞres via den nye wizard. Her kan man allerede ned pÄ en enkelt job, hvor hele kÊden, der befandt sig i arkivet pÄ et bestemt tidspunkt, bliver genoprettet.
Der er tre restaureringsmuligheder:
- Til den oprindelige placering. I dette tilfÊlde slettes den originale backup, hvis den findes; lejedommens job omkonfigureres automatisk til den genoprettede kÊde. Det antages, at en sÄdan restaurering overhovedet ikke vil vÊre mÊrkbar for kunden, kun i kort tid vil de vÊre frakoblet fra den cloud-arkiv.
- Til en ny kvote/repository. Udbyderen kan for eksempel oprette en separat midlertidig konto til dette formÄl, som derefter slettes. Backupen vises i lejedommens infrastruktur efter synkronisering med udbyderens database.
- Bare til disk pÄ en Linux- eller Windows-server registreret i udbyderens infrastruktur. Derefter kan denne kÊde skrives til en USB-nÞgle og sendes til lejedommen.
Restaurering fra lejedommens side
Denne mulighed forudsÊtter, at kunden har egen tape-infrastruktur og et stort datavolumen til restaurering. Kassette med optagede backups kan fysisk sendes til kunden via en fragtservice, som katalogiserer den pÄ sit udstyr, dekrypterer kassettebÄndene og backups, og arbejder med sikkerhedskopierne, som om kunden selv havde optaget dem pÄ bÄnd. En sÄdan livshack for ikke at downloade terabyte via WAN.
StĂžrre forbedringer i GFS-poolen
-media-pooler blev introduceret i VBR for to Är siden, i version 9.5. I den seneste opdatering, bÄde pÄ grund af introduktionen af funktionen Tenant to tape, og efter brugerhenvendelser, har vi vÊsentligt forbedret denne funktionalitet.
Daglige mediesĂŠt
Der er kommet en ny daglig (daily) mediesÊt. Nu kan der i GFS-poolen gemmes backup for hver dag, ikke kun fulde, men ogsÄ inkrementelle. SidstnÊvnte optager vÊsentligt mindre plads, og dette er gjort for at spare bÄnd. Det antages, at disse bÄnd konstant roteres i biblioteket og ikke transporteres til fjernopbevaring. For at gendanne fra en inkrementel kopi er det desuden nÞdvendigt at have bÄnd fra et af de Êldre mediesÊt (ugentligt, mÄnedligt, kvartalsvis eller Ärligt). Man kan ikke inkludere det daglige mediesÊt uden at inkludere det ugentlige, da der i de fleste tilfÊlde krÊves ugentlige bÄnd for at gendanne fra en inkrementel kopi. Disse bÄnd er altid enten i biblioteket eller opbevares pÄ et mindre fjerntlager.
Logikken bag tape-jobbene i GFS-mediepuljen , tekniske forfattere vil bekrÊfte dette. Kort fortalt, uden at gÄ i detaljer, sÄ kopieres der kun fulde backups (inklusive virtuelle fulde backups) til det ugentlige og Êldre mediesÊt, én for hver dato, mens det daglige indeholder alle backups i depotet for den aktuelle dag, da backup-jobbet kan kÞres oftere end én gang om dagen.
Parallellisme, starttidspunkt og ventetid i GFS-pooler
Nu er parallel skrivning af flere kÊder eller job pÄ flere drev i biblioteket muligt ogsÄ i GFS-mediepuljer (tidligere kun i almindelige). Det aktiveres pÄ trin Indstillinger medie-pulen.
Vigtigt prÊciseret: den samme fil skrives altid i én strÞm, sÄ i tilfÊlde af flere store virtuelle maskiner anbefales det at aktivere , sÄ backup bestÄr af flere kÊder.
Derudover er det blevet muligt at vĂŠlge starttidspunktet for selve GFS-jobbet. Mange brugere var ikke begejstrede for at starte ved midnat og derefter vente i nĂŠsten en hel dag, indtil kilde-jobbet var afsluttet. Nu kan dette tidspunkt eksempelvis sĂŠttes til sent pĂ„ aftenen, nĂ„r der allerede er noget at kopiere til bĂ„ndet. Desuden, efter brugerforespĂžrgsler, har vi flyttet til avancerede indstillinger en mulighed, der tidligere kun kunne aktiveres med en registreringsnĂžgle. Det er tilstrĂŠkkeligt at vĂŠlge Behandle det nyeste gendannelsespunkt i stedet for at vente â og der kopieres det der er i depotet pĂ„ tidspunktet for starten af tape-jobbet (punkt fra dagen fĂžr, for eksempel), der er slet ingen ventetid.
Forbedret arbejde med flere biblioteker
Vi vil tale om situationen, hvor der tilfĂžjes mere end Ă©t bibliotek til en medie-pool. Vi har stĂžttet dette fĂžr, men lejlighedsvis kom der kunder med klager over noget uforudsigeligt adfĂŠrd.
Var
For eksempel, hvis en tape-job starter, optager den to drev i det fÞrste bibliotek, men indstillingerne for parallelisme tillader, at den bruger op til 4 drev. Skal denne job skifte til det andet bibliotek i medie-poolen og bruge det ogsÄ, eller vil det vÊre en ressourceoverskridelse?
En anden situation. Valgmuligheden er valgt til at skifte ved betingelsen 'ingen tilgÊngelige bÄnd', hvor der kun er ét bÄnd i det fÞrste bibliotek, men alle data kan potentielt placeres auf dette. Men indstillingerne tillader, at der skrives parallelt pÄ to bÄnd. Skal det andet bibliotek inddrages i dette tilfÊlde?
Vi har besluttet at rydde op i dette omrÄde ved at give mulighed for at indstille adfÊrden eksplicit.
Er blevet
har fÄet roller - aktiv og passiv. Og selve medie-poolen har to tilstande: fejltolerance, eller failover (failover) og parallelt optagelse (paralleling). Nu, afhÊngigt af kravene, kan medie-poolen konfigureres pÄ forskellige mÄder.
- Hvis du har flere ligevÊrdige biblioteker, og det er nÞdvendigt at parallelisere optagelsen i dem - aktiverer du tilstand for parallelt optagelse, for dette skal alle biblioteker tildeles aktive roller. PÄ dette tidspunkt vil nye bÄnd og drev blive inddraget, sÄ snart behovet opstÄr, uanset hvilket bibliotek de befinder sig i. Prioritet er stadig til stede - fÞrst vil vi forsÞge at finde ressourcer i det bibliotek, der er placeret hÞjere pÄ listen.
- Hvis der derimod er ét primÊrt bibliotek og et gammelt eller standalone-drev i reserve, aktiverer du fejltolerance-tilstand ved at placere det primÊre bibliotek Þverst pÄ listen og vÊlge en passiv rolle for de reserverede enheder. Skift til en sÄdan enhed vil kun ske, nÄr det virkelig er nÞdvendigt, for at jobben kan fungere overhovedet. En sÄdan situation vil blive betragtet som en nÞdsituation, og der vil blive sendt en meddelelse til e-mail.
Der er en mere kompleks situation, som vi ikke understĂžtter endnu â flere aktive biblioteker, mens der er passive. Feedback vil vise, om der er behov for sĂ„danne konfigurationer, og om vi skal 'tilpasse' funktionen i fremtiden. Standardpraksis.
UnderstĂžttelse af WORM
WORM â Write Once Read Many â bĂ„nd, der ikke kan slettes eller overskrives , data kan kun tilfĂžjes. Deres obligatoriske brug reguleres af regler fra visse organisationer, for eksempel dem der arbejder inden for medicin. Det primĂŠre problem med sĂ„danne bĂ„nd tidligere var, at VBR ved eller skrev en overskrift, som ikke kunne slettes senere, og tape-jobber fejlede med en fejl ved et sĂ„dant forsĂžg.
I 9.5 Update 4 implementeres der fuld understÞttelse af sÄdanne bÄnd. Der er tilfÞjet WORM-medie-pools, bÄde almindelige og GFS, hvor kun denne type bÄnd kan placeres.
De nye bÄnd har et blÄt, 'frosset' ikon. Fra brugerens synspunkt er arbejdet med WORM-bÄnd ikke anderledes end arbejdet med almindelige.
WORM-status for bÄnd defineres oprindeligt af suffikset , hvis stregkoden er almindelig eller uleselig, giver driveren oplysninger ved fÞrste indsÊttelse af bÄndet. Det er ikke muligt at placere WORM-bÄnd i en almindelig medie-pool og skrive til dem. Sjovt nok har der allerede vÊret brugere, der har klistret WORM-stregkoder pÄ almindelige bÄnd og blevet overraskede over Êndringerne i deres infrastruktur efter opdateringen.
Chippen pÄ bÄndet
Samtidig med implementeringen af de ikke-overskrivbare bÄnd begyndte vi at arbejde med . De standardattributter, der tidligere ikke blev brugt i chippen, skriver og lÊser vi nu i nogle af dem, men opfatter dem ikke som den primÊre datakilde. Hovedorienteringen er stadig overskriften pÄ bÄndet. Denne lÞsning viste sig at vÊre korrekt: efter en mÄned efter udgivelsen ser vi, hvordan brugernes 'zoo' af hardware byder pÄ overraskelser i arbejdet med chippen.
Backup af NDMP-volume til bÄnd
Afslutningsvis â om den mest efterspurgte funktion ifĂžlge antal anmeldelser i denne opdatering. Backup af NDMP-volumener til bĂ„nd er blevet tilgĂŠngelig. Infrastruktur i VBR skal , hvorefter det i filbĂ„ndjobbet bliver muligt at vĂŠlge volumener fra denne vĂŠrt. De gemmes pĂ„ bĂ„nd som filer med en sĂŠrlig attribut, sĂ„ de kan skelnes fra almindelige under katalogisering.
I den fĂžrste implementering er der visse begrĂŠnsninger: udvidelser (extensions) understĂžttes ikke, og der er kun mulighed for backup og gendannelse af hele volumener, ikke enkelte filer. Backup fungerer via (i tilfĂŠlde af NetApp â ), her er der nogle sĂŠrlige forhold: det maksimale antal inkrementelle punkter er 9, hvorefter en fuld backup tvinges.
Som konklusion
Disse var blot de mest markante nyheder inden for bÄndbackup i VBR 9.5 Update 4. Andre Êndringer er som fÞlger:
- mulighed for at angive rÊkkefÞlgen for source-jobs og filer i bÄndjobbene;
- tilfĂžjet roller Tape Operator (brugeren kan gĂžre alt undtagen gendanne fra bĂ„nd â det er der en Restore Operator til);
- tilfÞjet fuldgyldige include/exclude-mekanismer i filbÄndjob (bortset fra NDMP);
- forbedret gendannelse i filbĂ„ndjob (mappen gendannes med de filer, der var der pĂ„ tidspunktet for backup, og ikke med dem, der nogensinde har vĂŠret der i hele dens backuphistorik â en meget efterspurgt funktion, for resten);
- Þget hastighed for gendannelse af meget store filer fra bÄnd;
- forbedret algoritme til valg af nÊste bÄnd til optagelse, isÊr nÄr der tages hensyn til mÊngden af data, der er skrevet/lÊst gennem hele dens liv, vi tager den nyeste;
- forbedret produktstabilitet.
Nyttige links
Til forskel vil jeg gerne nĂŠvne et par links til russisksprogede ressourcer:
- Og sĂ„ er vi tilbage pĂ„ det tidligere sted med oversigt over videoer "Hvordan det fungerer" (dog stadig pĂ„ engelsk) â man kan se det . Om bĂ„ndene tales der pĂ„ dias 95 â 102.
Kilde: habr.com
