В tidigare artikel Vi berättade om de nya funktionerna i Update 4 för Veeam Backup & Replication 9.5 (VBR) som släpptes i januari, där vi medvetet inte nämnde bandbackuper. Berättelsen om detta område förtjänar en separat artikel, för det fanns verkligen många nya funktioner.

– QA killar, kommer ni att skriva en artikel?
- Varför inte!

Bandenheter under 2000-talet

Lagra data på magnetband (kassetter, "teipah", som vi kallar dem i FoU) är inte begränsad till den förflutna ZX-Spectrum-datorn, ett spel för vilket kan laddas in i 48 kb RAM med tejpkassett i flera minuter. Under ett kvarts sekel har hastigheten och kapaciteten på kassetter ökat med 6-7 storleksordningar. Detta är inte en helt korrekt jämförelse, och Moores lag standard LTO kan inte hänga med. Men modern teknik gör det möjligt att spela in 12 terabyte data (upp till 30 terabyte i komprimeringsläge) på ett kilometerlångt band på en kassett, sålunda lämnar 160 dollar-enheten konkurrenter bakom sig när det gäller kostnaden för långtidslagring av stora mängder data, även om man tar hänsyn till investeringar i inspelnings-/läsutrustning. Data om sådana kassetter lagras tillförlitligt i 15-30 år.

Jag kommer från andra sidan. Förra gången ransomware-virus nått en ny nivå. De kan vänta på sitt ögonblick i ett stort företags infrastruktur i veckor och månader, och med uppkomsten av ytterligare en nolldagarssårbarhet kan de förstöra (inte utan mänsklig hjälp, eftersom stora pengar står på spel) inte bara all data, utan också alla säkerhetskopior som kan nås. Här färskt exempel, när företaget fick betala utpressare. Den så kallade lufthål, det vill säga säkerhetskopior som är fysiskt isolerade från infrastrukturen har faktiskt blivit den enda pålitliga räddningen från sådana berättelser. Magnettejp är en av de tidlösa lösningarna här.

Men specifikationer och tekniska innovationer inom järn och bariumferrit från ledande tillverkare (IBM, HPE, Oracle, Dell) räcker inte för att tillförlitligt skydda data; bra mjukvara behövs. På Veeam har vi ett helt team dedikerat till bandbackuper, cirka 10 personer som analyserar, planerar, forskar, utvecklar och testar varje dag. Du kan se resultatet av detta arbete i tidigare artiklar (tid, два). Vad har gjorts under det senaste året?

Ordlista

Valet uppstår mellan friheter med modersmålet och tjänstemän som försvårar läsbarheten. Jag föredrar det första, så jag ber om ursäkt på förhand om slangorden från listan nedan är tråkiga för någon. Här ska jag kort påminna dig om vad varje term betyder.

VBR-armaturer kan hoppa över denna delJoba – jobb – backupuppgift. Faktum är att hela VBR bygger på jobb. Förutom säkerhetskopiering och replikering kan detta även vara kopiering till magnetband (backup-till-band-jobb). Låt mig reservera att återställning från en säkerhetskopia (återställning) också är ett jobb, men i den här artikeln kommer detta ord att betyda en säkerhetskopia.

Lagring – lagring – ett historiskt etablerat namn. Det här är filerna i förråd (lager – lagring), som innehåller säkerhetskopior – full и inkrementell. En lagring kan innehålla en eller flera virtuella maskiner.

kedja – kedja – en sekvens av lagringar kopplade till varandra. För att återställa data från den n:e inkrementella lagringen behöver du alla tidigare från (n-1) till den 1:a och hela lagringen som refereras till av den första inkrementella lagringen.

Källa, mål – källa, mål. Källan är den ursprungliga entiteten som joban bearbetar. När det gäller säkerhetskopior/repliker är detta vanligtvis en virtuell maskin i en hypervisor. När det gäller ett bandjobb är källan själva säkerhetskopieringsjobbet (eller filer i fallet med ett fil till bandjobb). Målet för ett säkerhetskopieringsjobb är arkivet där säkerhetskopiorna lagras. För bandjobb är det en mediapool.

Mediapool - mediapool – en pool av informationsbärare, i vårt fall – kassetter. En logisk behållare skapad av användaren som innehåller kassetterna från ett eller flera bibliotek. Så, ett bandjobb har alltid en mediapool som mål, det vill säga data skrivs inte till ett specifikt band eller till något band i biblioteket, utan till en specifik uppsättning av dem. Mediapoolen har en inställning av datalagringstid, varefter bandet kan skrivas om. Användaren kan skapa standard och GFS pooler. Var och en av dessa typer kan nu också vara WORM och icke-WORM, mer om det nedan.

Media set - media set – en uppsättning kassetter i en mediapool som säkerhetskopior/filer kontinuerligt skrivs på. För GFS-pooler är mediauppsättningar också kopplade till ett intervall (till exempel årligen), och band roteras endast inom deras intervall.

Kör, växlare – element i bandbiblioteket. Enheten läser och spolar tillbaka bandet, växlaren är en robot som flyttar band mellan lagringsplatserna, utmatningsplatserna och enheten. Det finns också fristående enheter (fristående – separat stående), växlarens roll här utförs av en person. Enheten kräver en korrekt installerad tillverkarens drivrutin på den Windows-dator där biblioteket är anslutet; Vi kan arbeta med växlaren utan drivrutiner, via inbyggt SCSI.

Hyresgäst att tejpa. Skyddad leverantör - skyddade kunder

Lägg dina trumfkort på bordet direkt. Den viktigaste funktionen i vår uppdatering, designad för molnleverantörer, med hjälp av VBR i sin infrastruktur. Utvecklingen började för två år sedan. Vi insåg snart att vi inte skulle kunna hantera en så allvarlig uppgift vid nästa utgåva, så vi tog en kort paus och släppte så småningom funktionen i 9.5 Update 4.

Kort sagt, leverantörer har nu möjlighet att kopiera sina klienters säkerhetskopior till band med hjälp av bandjobb i en GFS-pool. Detta ger leverantörer – och dessa är mycket stora killar som ligger oss varmt om hjärtat och den kommersiella avdelningen – två alternativ:

• skydda dina kunder (hyresgäster, hyresgäst – hyresgäst) från dataförlust på grund av oavsiktlig radering eller infrastrukturproblem ("översvämning i serverrummet");
• ge hyresgästerna en tilläggstjänst för att återställa data från en gammal säkerhetskopia som sedan länge har raderats från molnförvaret enligt datalagringspolicyn, men som fortfarande finns kvar på banden.

Ur marknadsföringssynpunkt är funktionaliteten väldigt "god", men från vår sida är den inte mindre svår att implementera.

utformning

Det största problemet som uppstod var datakryptering. De flesta molnsäkerhetskopior är krypterade, statistiken säger ungefär ⅔ av det totala antalet. Denna siffra var en överraskning för oss, vi antog att nästan allt är krypterat, men nej – många kunder verkar ha absolut förtroende för sina leverantörer.

Paradigmet är enkelt: leverantören ska inte kunna dekryptera data från sina hyresgäster. Samtidigt kräver den nya funktionen öppning av lagring med säkerhetskopior på leverantörens sida. Detta är nödvändigt för att flytta datablock, till exempel för att skapa virtuell full backup. Huvudsaken är att detta måste göras oberoende av hyresgästen, när de nödvändiga nycklarna inte överförs till leverantörens sida under utförandet av jobbet.

Lösningen på detta problem, som också är inblandat i en annan viktig funktion i det släppta tillägget, är Kapacitetsnivå – består av att lägga till ytterligare en krypteringsnyckel. Arkivnyckeln lagras i leverantörens databas i krypterad form. Enligt ett smart schema på leverantörens sida kan den användas för att öppna lagring, flytta och omkryptera datablock mellan lagringar (var och en har trots allt sin egen nyckel), men den kan inte dekryptera själva datan.

Ett smart schema (fungerande version)

Jag ska tillägga att alla ingenjörer inom FoU verkligen gillar krypteringen i vår produkt, även om ingen vet i alla detaljer hur det fungerar. (Det var också ett skämt här om "varför fungerar det överhuvudtaget", men redaktionen släppte inte igenom det.)

testning

Hundratals buggar rapporterades för funktionen. De svåraste områdena är kryptering, användargränssnitt och problem med återställning.

Ur testsynpunkt var svårigheten den stora variationen, "kombinationen" av typer och typer av hyresgästjobb och förråd – jag menar både källan och målet vid återställning av säkerhetskopior till infrastrukturen. Allt detta är sammanfogat med logik inom ramen GFS-modeller (inklusive en ny – parallellitet och dagliga mediauppsättningar, mer om det nedan), och i allmänhet om molnspecifikationerna som är ovanliga för band. Glöm inte att strö i massor av kryptering. För att fortsätta metaforen åt vi oss mätta på den här rätten – men vi smakade också på den från alla håll.

Fragment av testplanen

Som ett resultat,

En detaljerad beskrivning finns i användarmanual (för nu på engelska): säkerhetskopiering, восстановление. Jag kommer att uppehålla mig vid huvudpunkterna.

Säkerhetskopiering

Leverantören lägger till hyresgäster till ett bandjobb med en GFS-pool som mål. Om du har en molnlicens är alternativet tillgängligt i det andra steget i guiden hyresgäster. Du kan lägga till alla hyresgäster på en gång eller individuellt, eller så kan du bara välja en specifik kvot (men inte en underkvot) för en specifik hyresgäst. Du kan inte blanda hyresgästsäkerhetskopior och vanliga lokala säkerhetskopior i ett jobb.

Resten av inställningarna är nästan helt identiska med den vanliga joban i GFS-poolen.

Dataåterställning är möjlig både på leverantörssidan och på hyresgästsidan.

Återhämtning på leverantörssidan

Det utförs genom en ny guide. Här kan du gå ner till ett separat jobb, hela kedjan som fanns i förvaret en viss dag är återställd.

Det finns tre restaurangalternativ:

1. Till den ursprungliga platsen. I det här fallet tas den ursprungliga säkerhetskopian, om någon, bort; Hyresgästjobb konfigureras automatiskt om till den återställda kedjan. Det antas att en sådan restaurang kommer att vara helt osynlig för klienten och endast kopplas bort från molnförrådet under en kort tid.
2. Till en ny kvot/lager. Leverantören kan t.ex. skapa ett separat tillfälligt konto för detta ändamål, som den sedan kommer att radera. Säkerhetskopieringen visas i hyresgästinfrastrukturen efter synkronisering med leverantörens databas.
3. Helt enkelt till disken på en Linux- eller Windows-server som är registrerad i leverantörens infrastruktur. Sedan kan denna kedja skrivas till en flash-enhet och skickas till hyresgästen.

Återhämtning på hyresgästsidan

Detta alternativ innebär att kunden har sin egen bandinfrastruktur och en stor mängd data för restaurangen. Leverantören kan fysiskt skicka ett band med inspelade säkerhetskopior till kunden via en leveranstjänst, som katalogiserar det på sin utrustning, dekrypterar banden och säkerhetskopiorna och arbetar med säkerhetskopiorna som om han själv hade spelat in dem på band. Här är ett life hack för att undvika att ladda ner terabyte via WAN.

Stora förbättringar av GFS-poolen

GFS-mediapooler dök upp i VBR för två år sedan, i version 9.5. I den släppta uppdateringen, både i samband med utseendet av Tenant to tape-funktionen och på begäran av användare, har vi förbättrat denna funktion avsevärt.

Dagliga mediauppsättningar

En ny har dykt upp dagligen (daglig) mediauppsättning. Nu kan GFS-poolen lagra säkerhetskopior för varje dag, och inte bara fulla utan även inkrementella. De senare tar upp betydligt mindre utrymme, och detta görs för att spara tejp. Det antas att dessa band ständigt roteras i biblioteket och inte tas till fjärrlagring. I det här fallet, för en restaurang från en inkrementell punkt, kommer du att behöva band från en av de högre mediauppsättningarna (veckovis, månadsvis, kvartalsvis eller årligen). Det är inte möjligt att aktivera den dagliga mediauppsättningen utan att aktivera den veckovisa, eftersom det i de flesta fall krävs veckoband för återställning från en inkrementell kopia. De finns antingen alltid på biblioteket eller förvaras på ett inte så avlägset lager.

Logik för bandjobboperation i GFS mediapool inte det lättaste, tekniska skribenter låter dig inte ljuga. I ett nötskal, om detaljer utelämnas, kopieras endast fullständiga säkerhetskopior (inklusive virtuella fullständiga säkerhetskopior) till vecko- och seniormedieuppsättningarna, en för varje datum, och alla säkerhetskopior för den aktuella dagen i förvaret kopieras till den dagliga uppsättningen, eftersom säkerhetskopieringsjobbet kan startas oftare än en gång om dagen.

Samtidighet, starttid och väntan i GFS-pooler

Nu är parallell inspelning av flera kedjor eller jobb på flera biblioteksenheter också möjlig i GFS-mediapooler (tidigare – endast i vanliga). Tänds vid steg Montering mediapool.

Viktigt förtydligande: samma fil skrivs alltid till en tråd, så vid flera stora virtuella maskiner rekommenderas det att aktivera konfigurera per virtuell dator på arkivetså att backupen består av flera kedjor.

Dessutom blev det möjligt att välja starttiden för själva GFS-jobbet. Många användare var inte nöjda med midnattslanseringen och fick sedan vänta nästan en hel dag på att källjobbet skulle slutföras. Nu kan den här tiden ställas in till exempel för sen kväll, när det redan finns något att kopiera till bandet. Dessutom har vi, på begäran av användare, lagt till ett alternativ till de avancerade inställningarna som tidigare bara kunde aktiveras med en registernyckel. Det räcker att välja Bearbeta den senaste återställningspunkten istället för att vänta – och det som finns i förvaret när bandjobbet startar kopieras till bandet (punkten för gårdagen, till exempel), det finns ingen väntan alls.

Förbättrad hantering av flera bibliotek

Vi kommer att prata om situationen när mer än ett bibliotek läggs till i en mediepool. Vi stöttade detta tidigare, men då och då kom klienter med klagomål om ett inte helt förutsägbart beteende.

det var

Till exempel, ett bandjobb startade, tog upp två enheter i det första biblioteket, men parallellitetsinställningarna tillåter det att använda 4 enheter samtidigt. Ska det här jobbet byta till det andra biblioteket i mediapoolen och använda det också, eller skulle det vara ett slöseri med resurser?

Ett annat fall. Alternativet att byta baserat på villkoret "inga tillgängliga kassetter" är valt; det första biblioteket har bara en kassett, men det innehåller potentiellt all data. Inställningarna gör dock att du kan skriva till två kassetter parallellt. Ska jag använda det andra biblioteket i det här fallet?

Vi bestämde oss för att rensa upp det här området genom att göra det möjligt att explicit konfigurera beteendet.

Har blivit

På biblioteken i mediapoolen roller dök upp - aktiv и passiv. Och själva mediapoolen har två lägen: felsäker eller failover (failover) och parallell inspelning (parallellt). Nu, beroende på dina krav, kan du konfigurera din mediapool på olika sätt.

• Om du har flera likadana bibliotek och behöver parallellisera inspelningen i dem, aktivera parallellinspelningsläget; för att göra detta måste alla bibliotek tilldelas aktiva roller. I det här fallet kommer nya band och enheter att användas så fort behovet uppstår, oavsett vilket bibliotek de finns i. Det finns fortfarande en prioritet – vi ska först försöka hitta resurser i biblioteket som ligger högre upp på listan.
• Om du har ett huvudbibliotek och en gammal eller fristående enhet i reserv, aktivera failover-läge genom att placera huvudbiblioteket högst upp i listan och välja en passiv roll för säkerhetskopieringsenheterna. Att byta till en sådan enhet kommer bara att ske när det verkligen är nödvändigt för att jobbet överhuvudtaget ska fungera. Denna situation kommer att betraktas som onormal och ett meddelande kommer att skickas via e-post.

Det finns en mer komplex situation som vi inte stöder ännu - flera aktiva bibliotek i närvaro av passiva. Feedback kommer att visa om det finns ett behov av sådana konfigurationer och om funktionen behöver "slutföras" i framtiden. Standardpraxis.

WORM stöd

MASK – Skriv en gång läst många – band som inte kan raderas eller skrivas om på järnnivå, kan du bara lägga till data. Deras obligatoriska användning regleras av reglerna för vissa organisationer, till exempel de som arbetar inom medicinområdet. Det största problemet med sådana kassetter brukade vara att VBR lager eller katalogisering skrev ner en titel som inte kunde raderas senare, och bandjobb kraschade med ett fel när de försökte göra det.

I 9.5 Update 4 har fullt stöd för sådana kassetter implementerats. Lade till WORM mediapooler, vanliga och GFS, där endast band av denna typ kan placeras.

Nya kassetter har en blå "frusen" ikon. Ur användarens synvinkel skiljer sig arbetet med WORM-kassetter inte från att arbeta med vanliga.

Kassetternas "maskighet" bestäms initialt av suffixet streckkod, men om streckkoden på dem är normal eller oläslig, ges informationen av enheten när kassetten sätts i första gången. Du kommer inte att kunna placera WORM-band i en vanlig mediapool och skriva till dem. Det som är roligt är att det redan har funnits användare som klistrat in WORM-streckkoder på vanliga kassetter och blivit överraskade av förändringarna i deras infrastruktur efter uppdateringen.

Kassettchip

Tillsammans med introduktionen av icke-omskrivbara kassetter började de arbeta med chips. Vi har inte använt standardattribut i chippet tidigare, nu skriver och läser vi in ​​några av dem, men vi uppfattar dem inte som huvudkällan till data. Huvudreferenspunkten är fortfarande bandets titel. Det här beslutet visade sig vara korrekt: en månad efter releasen ser vi hur "zoo" av användarhårdvara presenterar överraskningar när det gäller att arbeta med chipet.

Säkerhetskopiera NDMP-volymer till band

Sammanfattningsvis om den mest populära funktionen i denna uppdatering baserat på antalet recensioner. Säkerhetskopiering av NDMP-volymer till band är nu tillgänglig. VBR-infrastrukturen behöver lägg till NDMP-server, varefter det kommer att vara möjligt att välja volymer från denna värd i filbandsjobbet. De placeras på kassetter i form av filer med ett speciellt attribut för att skilja dem från vanliga under katalogisering.

Den första implementeringen har vissa begränsningar: tillägg stöds inte, plus säkerhetskopiering och återställning är endast möjlig för hela volymen, men inte för enskilda filer. Säkerhetskopieringen fungerar igenom dumpa (vid NetApp – ufsdump), det finns några särdrag här: det maximala antalet inkrementella poäng är 9, varefter en fullständig säkerhetskopia tvingas fram.

Som en slutsats

Detta var bara de viktigaste innovationerna inom bandsäkerhetskopiering i VBR 9.5 Update 4. Jag kommer att lista andra ändringar:

• möjligheten att ställa in ordningen på källjobb och filer i bandjobb;
• lade till rollen Bandoperatör (användaren kan göra allt förutom att återställa från band - det finns en återställningsoperatör för det);
• lagt till fullfjädrade inkludera/exkludera masker i filbandsjobbet (förutom NDMP);
• förbättrad återställning i ett filbandsjobb (mappen återställs med filerna som fanns där vid tidpunkten för säkerhetskopieringen, och inte med alla filer som fanns i den någon gång under hela historien för dess säkerhetskopior - en mycket populär funktion, förresten);
• hastigheten för återställning av ett mycket stort antal filer från band har ökat;
• Algoritmen för att välja nästa kassett för inspelning har förbättrats, i synnerhet tar vi, allt annat lika, hänsyn till volymen av inspelad/läst data under hela dess livslängd och tar den senaste;
• Förbättrad produktstabilitet.

Användbara länkar

För variation kommer jag att tillhandahålla flera länkar till ryskspråkiga resurser:

• Länk för att ladda ner gratis testversion av VBR 9.5 Update 4
• Artikel om Habr "Användbara tips för att arkivera Veeam-säkerhetskopior till magnetband"
• Artikel om Habr "7 användbara tips för att skydda säkerhetskopior från krypteringsvirus"
• Avsnitt i användarmanualen relaterat till band (på engelska)
• Tja, översiktsvideorna "Hur fungerar det" har återvänt till sin tidigare plats (dock på engelska för nu) – du kan se dem här. Band diskuteras på bild 95–102.

Källa: will.com