V Opowiedzieliśmy Wam o nowych funkcjach, które pojawiły się w styczniowej aktualizacji Update 4 dla Veeam Backup & Replication 9.5 (VBR), gdzie celowo nie wspomnieliśmy o kopiach zapasowych na taśmach magnetycznych. Opowieść na ten temat zasługuje na osobny artykuł, ponieważ nowych funkcji rzeczywiście było sporo.
– Chłopaki z QA, napiszecie artykuł?
– Czemu nie!
Koparki taśmowe w XXI wieku
Przechowywanie danych na taśmach magnetycznych (kasetach, „taśmach”, jak je nazywamy w R&D) nie ogranicza się do przeszłego komputera ZX-Spectrum, która mogła ładować jedną grę do pamięci operacyjnej 48 kb z przez kilka minut. Przez ćwierć wieku prędkości i pojemności kaset wzrosły o 6-7 rzędów wielkości. To niewłaściwe porównanie, i według standard nie nadąża. Niemniej nowoczesne technologie pozwalają na zapisanie na kilometrze taśmy jednej kasety 12 terabajtów danych (do 30 terabajtów w trybie kompresji), w ten sposób 160-dolarowy nośnik pozostawia konkurencję w tyle pod względem kosztów długoterminowego przechowywania dużych ilości danych, nawet uwzględniając inwestycje w sprzęt do nagrywania/odczytu. Dane na takich kasetach są bezpiecznie przechowywane przez 15-30 lat.
Sprawdzę to z innej strony. Ostatnio osiągnęły nowy poziom. Mogą czekać na swoją szansę w infrastrukturze dużej firmy przez tygodnie i miesiące, a z pojawieniem się kolejnej luki zero-day – zniszczyć (nie bez pomocy człowieka, bo stawka jest wysoka) nie tylko wszystkie dane, ale także wszystkie kopie zapasowe, do których można się dostać. Oto , kiedy firma musiała zapłacić rzezimieszkowi. Tak zwane air gap, czyli fizycznie izolowane od infrastruktury kopie zapasowe, stały się w zasadzie jedynym niezawodnym ratunkiem przed takimi historiami. Taśma magnetyczna jest tutaj jednym z rozwiązań, które nie wychodzą z użycia.
Ale sama specyfikacja i technologiczne nowinki żelazne i barytowo-ferrytowe od wiodących producentów (IBM, HPE, Oracle, Dell) nie wystarczą do niezawodnej ochrony danych, potrzebne jest także dobre oprogramowanie. W Veeam mamy cały zespół zajmujący się kopiami taśmowymi; około 10 osób codziennie analizuje, planuje, bada, opracowuje i testuje. Wyniki tej pracy mogliście zobaczyć w poprzednich artykułach (, ). Kaj je bilo narejeno v zadnjem letu?
Rečnik
Odločitev je med svoboščinami do maternega jezika in zapletenimi izrazi, ki otežujejo branje. Raje izbiram prvo možnost, zato se vnaprej opravičujem, če bo nekaterim žargon iz spodnjega seznama skakal v oči. Tu bom na kratko spomnil, kaj pomeni določen izraz.
Korefijem VBR lahko ta del preskočiteJob – job – naloga za varnostno kopiranje. V bistvu je celoten VBR zgrajen na jobih. Poleg varnostnega kopiranja in replikacije je lahko tudi kopiranje na magnetni trak (backup to tape job, tape job). Opozarjam, da je obnova iz varnostne kopije (restore) prav tako job, vendar bo v tem članku ta izraz pomenil prav varnostno kopiranje.
Shramba – storage – zgodovinsko poimenovanje. To so datoteke v repozitoriji (repository – skladišče), ki vsebujejo varnostne kopije – polne in inkrementalne. V eni shrambi je lahko ena ali več virtualnih strojev.
Veriga – chain – zaporedje med seboj povezanih shramb. Za obnovo podatkov iz n-te inkrementalne shramb potrebujemo vse predhodne od (n-1)-te do 1. in polno shrambo, na katero se sklicuje prva inkrementalna.
Vir, cilj – source, target. Vir – izvorni entitet, ki ga obdela job. V primeru varnostnih kopij/replic je to običajno virtualni stroj v hipervizorju. V primeru tape joba je vir sama job za varnostno kopiranje (ali datoteke v primeru file to tape joba). Cilj za job varnostnega kopiranja je skladišče, kjer so shranjene varnostne kopije. Pri tape jobu pa je to medijski bazen.
Medijski bazen – – bazen nosilcev informacij, v našem primeru – kaset. Logična posoda, ki jo ustvari uporabnik in ki vsebuje kasete ene ali več knjižnic. Tako ima tape job vedno medijski bazen kot cilj, to pomeni, da se podatki ne zapisujejo na katero koli posebno kaseto ali na katero koli kaseto v knjižnici, temveč na določen niz. Medijski bazen ima nastavitev časa hrambe podatkov, po kateri se lahko kaseta prepiše. Uporabnik lahko ustvari običajne (standard) in . Vsaka izmed teh vrst je lahko še WORM in ne-WORM, o tem kasneje.
Medijski set – – niz kaset v medijskih bazah, na katere se neprekinjeno zapisujejo varnostne kopije/datoteke. Za GFS-baze imajo medijski nizi prav tako povezavo z intervalom (npr. letnim – yearly), kasete se rotirajo samo znotraj svojega intervala.
– elementi trakovne knjižnice. Pogon prebere in previje kaseto, menjalnik – je robot, ki premika kasete med skladišči, skladišči za iztovarjanje in pogonom. Obstajajo tudi samostojni pogoni (standalone – samostojen), v tem primeru nalogo menjalnika opravi človek. Za pogon je obvezna pravilno nameščena gonilna programska oprema proizvajalca na Windows napravi, kamor je priključena knjižnica; z menjalnikom pa lahko delujemo tudi brez gonilnikov, po native SCSI.
Najemnik na trak. Zavarovane stranke – zaščiteni uporabniki.
Takoj na mizo. Največja funkcija našega posodobitve, namenjena , ki v svoji infrastrukturi uporabljajo VBR. Razvoj se je začel pred dvema letoma. Kmalu smo spoznali, da se s tako resnim izzivom do bližnjega izida ne moremo spoprijeti, vzeli smo kratek odmor in na koncu izdali funkcijo v 9.5 Update 4.
Na kratko, zdaj imajo ponudniki možnost kopirati varnostne kopije svojih strank na kasete z uporabo tap-oddelka v GFS-bazi. To daje ponudnikom – in to so zelo veliki, dragi ljudje našemu srcu in komercialnemu oddelku – dve možnosti:
- zaščititi svoje stranke (najemnike, najemnik – uporabnik) pred izgubo podatkov zaradi nenamernega brisanja ali infrastrukturnih težav («poplava v strežniški sobi»);
- zagotoviti najemnikom dodatno storitev za obnovitev podatkov iz stare varnostne kopije, ki je že dolgo izbrisana iz oblačnega repozitorija skladno s politiko hrambe podatkov, vendar na kasetah še vedno ostaja.
Z marketinškega vidika je funkcionalnost zelo privlačna, z naše strani pa nič manj zahtevna za implementacijo.
Razvoj
Glavna težava, ki se je pojavila – šifriranje podatkov. Večina oblačnih varnostnih kopij je šifriranih, statistika pravi, da je to ⅔ celotnega števila. Za nas je ta številka bila presenečenje, predvidevali smo, da je skoraj vse šifrirano, vendar ni – mnogi stranke se očitno nepreklicno zanašajo na svoje ponudnike.
Paradigma je preprosta: ponudnik ne sme biti sposoben dešifrirati podatkov svojih najemnikov. V okviru nove funkcije je potrebno na strani ponudnika odpreti shrambe z varnostnimi kopijami. To je potrebno za prenos podatkovnih blokov, na primer, za ustvarjanje . Ključno je, da to počnemo neodvisno od najemnika, ko nujni ključi med izvajanjem naloge niso preneseni na stran ponudnika.
Rešitev te težave, ki je bila vključena tudi v drugo pomembno funkcijo izdane nadgradnje – – je dodajanje dodatnega šifrirnega ključa. Arhivski ključ se shranjuje v bazi ponudnika v šifrirani obliki. S pomočjo kompleksne sheme ga lahko ponudnik uporablja za odpiranje šrambe, premikanje in prešifriranje blokov podatkov med shrambo (saj ima vsaka svoj ključ), vendar podatkov samih ni mogoče dešifrirati.
Zelo zapletena shema (delujoča različica)
Dodam, da vsi inženirji v R&D obožujejo šifriranje v našem izdelku, res je, da nihče ne pozna vseh podrobnosti o tem, kako deluje. (Tu je bila še šala 'in zakaj sploh deluje', vendar je ta ni prešla urednikom.)
Testiranje
Na funkcijo je bilo prijavljenih na stotine napak. Najbolj zapletene področja so – šifriranje, uporabniški vmesnik, težave pri obnovitvi.
Z vidika testiranja je bila težava velika variabilnost, 'kombinatorika' vrst in tipov najemniških nalog in repozitorijev – mislim tako na vir kot tudi na cilj pri obnovi varnostnih kopij v infrastrukturo. Vse to se povezuje z logiko v okviru (vključno z novim – paralelizem in dnevni medijski nizi, o tem spodaj), pa tudi na splošno na nenavadno oblaku specifiko tipov. Ne pozabite obilno začiniti s šifriranjem. Če nadaljujemo z metaforo, smo se dobro najedli te jedi – a smo jo tudi preizkusili z vseh strani.
Fragment testnega načrta
Kot rezultat
Podrobno opis lahko najdete v (zaenkrat v angleščini): , . Ustavim se pri glavnih točkah.
Varnostna kopija
Ponudnik doda najemnike v nalogo teipa z GFS-bazenom kot ciljem. V primeru, da je na voljo oblačna licenca, je v drugem koraku čarovnika na voljo možnost Tenants. Lahko dodate vse najemnike hkrati ali posamično, lahko pa izberete tudi samo določeno kvoto (vendar ne podkvoto) posameznega najemnika. V eni nalogi ni dovoljeno mešanjem varnostnih kopij najemnikov in običajnih lokalnih varnostnih kopij.
Ostale nastavitve so skoraj popolnoma enake običajni nalogi v GFS-pulu.
Obnova podatkov je mogoča tako na strani ponudnika kot tudi na strani samega najemnika.
Obnova na strani ponudnika
Izvaja se preko novega čarovnika. Tu se lahko spustite do posamezne naloge, obnavlja se celotna veriga, ki je bila v skladišču na določen dan.
Na voljo so trije načini obnove:
- Na izvorno lokacijo. V tem primeru se originalna varnostna kopija, če ta obstaja, izbriše; naloge najemnika se samodejno prilagodijo obnovljeni verigi. Predpostavlja se, da ta obnovitev ne bo opazna za stranko, le za kratek čas bo odklopljena od oblačnega skladišča.
- Na novo kvoto/skladišče. Ponudnik lahko na primer ustvari poseben začasni račun za ta namen, ki ga kasneje izbriše. Varnostna kopija se pojavi v infrastrukturi najemnika po sinhronizaciji z bazo ponudnika.
- Preprosto na disk Linux ali Windows strežnika, registriranega v infrastrukturi ponudnika. Ta veriga se lahko nato zapiše na USB ključek in pošlje najemniku.
Obnova na strani najemnika
Ta možnost predpostavlja, da ima stranka lastno tapeno infrastrukturo in veliko količino podatkov za obnovo. Kaso z zabeleženimi varnostnimi kopijami lahko ponudnik fizično pošlje stranki s kurirsko službo, ta jo katalogizira na svoji opremi, dešifrira kasete in deluje z varnostnimi kopijami, kot da jih je sama zapisala na trak. Takšen trik, da se izognete prenosu terabajtov preko WAN.
Obsežne izboljšave GFS-pula
-medijske rezerve so se pojavile v VBR pred dvema letoma, v različici 9.5. V ugledni posodobitvi, tako zaradi nastopa funkcije Najemnik na trak, kot na želje uporabnikov, smo dobro izboljšali to funkcionalnost.
Dnevni medijski nizi
Pojavil se je nov dnevni (daily) medijski set. Sada u GFS bazenu možete pohranjivati sigurnosne kopije za svaki dan, a ne samo potpune, već i inkrementalne. Potonje zauzimaju značajno manje prostora, i to je učinjeno u svrhu štednje trake. Podrazumijeva se da se te trake stalno rotiraju unutar biblioteke, a ne prevoze na udaljeno skladištenje. Za vraćanje iz inkrementalne točke bit će potrebne trake jednog od starijih medijskih setova (nedjeljnog, mjesečnog, kvartalnog ili godišnjeg). Uključiti dnevni medijski set bez uključivanja nedjeljnog nije moguće kako bi u većini slučajeva za vraćanje iz inkrementalne kopije bile potrebne upravo nedjeljne trake. One se ili također uvijek nalaze u biblioteci ili se čuvaju na ne tako udaljenom skladištu.
Logika rada tape-jobs u GFS medijskom bazenu , tehnički pisci će to potvrditi. Ukratko, bez detalja, u nedjeljne i starije medijske setove kopiraju se samo potpune sigurnosne kopije (uključujući virtualne pune sigurnosne kopije), po jedna za svaki datum, dok se u dnevni set – sve sigurnosne kopije prisutne u repozitoriju za trenutni dan, jer se backup-job može pokretati češće od jednom dnevno.
Paralelizam, vrijeme početka i čekanje u GFS bazenima
Sada je paralelno zapisivanje nekoliko lanaca ili poslova na nekoliko pogona biblioteke moguće i u GFS medijskim bazenima (ranije – samo u običnim). Uključuje se u koraku Options medijskog bazena.
Važno pojašnjenje: isti datoteka uvijek se zapisuje u jedan tok, stoga se u slučaju nekoliko velikih virtualnih strojeva preporučuje uključiti , kako bi backup bio sastavljen od nekoliko lanaca.
Osim toga, sada je moguće odabrati vrijeme pokretanja samog GFS posla. Mnogim korisnicima nije se svidio pokret u ponoć i kasnije čekanje tijekom gotovo cijelog dana dok se source-job ne završi. Sada se to vrijeme može, na primjer, postaviti na kasnu večer, kada već ima što kopirati na traku. Štoviše, na zahtjev korisnika dodali smo u napredne postavke opciju koju je ranije bilo moguće aktivirati samo pomoću registarskog ključa. Dovoljno je odabrati Obradite najnoviju točku vraćanja umjesto čekanja – in tape jobs, the content copied to the tape corresponds to the repository as of the job start time (the point from yesterday, for example), with no expectation at all.
Improved handling of multiple libraries
We will discuss the situation where more than one library has been added to a media pool. We used to support this before, but clients occasionally reported unpredictable behavior.
Was
For example, a tape job started, occupying two drives in the first library, but the parallelism settings allow it to use up to 4 drives at once. Should this job switch to the second library in the media pool and use it as well, or would that be wasteful of resources?
Another case. The option to switch based on the condition 'no available tapes' is selected, but there is only one tape in the first library, and all data potentially fits on it. However, the settings allow writing to two tapes simultaneously. Should the second library be engaged in this case?
We decided to bring this area into order by allowing the behavior to be configured explicitly.
Postalo je
now have roles – active in passive. And the media pool itself has two modes: fault-tolerant, or failover and parallel recording (paralleling). Now, depending on the requirements, the media pool can be configured differently.
- If you have several equal libraries and need to parallelize the recordings to them – enable the parallel recording mode, which requires all libraries to be assigned active roles. In this case, new tapes and drives will be utilized immediately as the need arises, regardless of which library they belong to. There is still a priority – we will first try to find resources in the library higher on the list.
- If you have one main library and one older or standalone drive as a backup, enable the failover mode by placing the main library at the top of the list and selecting a passive role for the backup devices. Switching to such a device will only happen when it is truly necessary for the job to proceed at all. Such a situation will be considered an emergency, and a notification will be sent by email.
Obstaja bolj zapletena situacija, ki je še ne podpiramo – več aktivnih knjižnic ob prisotnosti pasivnih. Povratne informacije bodo pokazale, ali obstaja potreba po takšnih konfiguracijah in ali je treba funkcijo v prihodnosti "dodelati". Standardna praksa.
Podpora WORM
WORM – Write Once Read Many – kasete, ki jih ni mogoče izbrisati ali prepisati , mogoče je le dodajanje podatkov. Njihova obvezna uporaba je regulirana s pravili nekaterih organizacij, na primer, delujočih na področju medicine. Glavni problem s takšnimi kasetami je bil prej v tem, da je VBR pri ili zapisal glavo, ki je kasneje ni bilo mogoče izbrisati, in naloge za trak so padle z napako pri poskusu.
V različici 9.5 Update 4 je bila implementirana polna podpora za takšne kasete. Dodani so WORM medijski bazeni, običajni in GFS, kamor je mogoče postaviti le kasete tega tipa.
Nove kasete imajo modro, "zamrznjeno" ikono. Z vidika uporabnika delo z WORM kasetami ne razlikuje od dela z običajnimi.
"Wormovitost" kaset se sprva določa po sufiksu , če pa ima črtna koda običajno ali neberljivo, informacije poda gonilnik ob prvem vstavljanju kasete. V običajno medijsko zbirko ni mogoče postaviti WORM kaset in na njih pisati. Zanimivo: že so se našli uporabniki, ki so lepljali WORM črtne kode na običajne kasete in so bili presenečeni nad spremembami v svoji infrastrukturi po nadgradnji.
Čip kasete
Ob tem, ko smo uvedli neprepisljive kasete, smo začeli delati tudi s Standardne lastnosti v čipu prej nismo uporabljali, zdaj nekaterim pišemo in beremo, vendar jih ne obravnavamo kot glavni vir podatkov. Glavni pokazatelj – ostaja naslov kasete. Ta rešitev se je izkazala za pravilno: po enem mesecu po izdaji vidimo, kako "živalski vrt" strojne opreme uporabnikov prinaša presenečenja glede dela s čipom.
Backup NDMP volumov na trak
Na koncu – o najbolj iskani funkciji po številu povratnih informacij v tej nadgradnji. Na voljo je backup NDMP volumov na kasete. V infrastrukturo VBR je treba , po čemer bo v datotečni trak-job mogoče izbrati volumne s tega gostitelja. Ti so shranjeni na kasetah v obliki datotek s posebnim atributom, da se razlikujejo od običajnih pri katalogizaciji.
V prvi različici obstajajo določene omejitve: razširitve (extensions) niso podprte, poleg tega je mogoče narediti varnostno kopijo in obnovo samo celotnega volumna, ne pa posameznih datotek. Varnostno kopiranje deluje preko (v primeru NetApp – ), tu so svoje posebnosti: največje število inkrementalnih točk – 9, po čemer se prisili polna varnostna kopija.
В качестве заключения
To so bili le najpomembnejši novosti na področju varnostnega kopiranja na magnetske trakove v VBR 9.5 Update 4. Preostale spremembe bom navedel v seznamu:
- možnost določanja vrste izvornih delov in datotek v trak-jobih;
- dodana vloga Tape Operator (uporabnik lahko dela vse razen obnove s traku – za to je Restore Operator);
- dodane popolne include/exclude-maske v datotečni trak-job (razen NDMP);
- izboljšana obnova v datotečnem trak-jobu (mapa se obnavlja s tistimi datotekami, ki so bile tam ob času varnostne kopije, ne pa z vsemi, ki so bile kadarkoli v njenem celotnem zgodovini varnostnih kopij – zelo iskana funkcija, mimogrede);
- povečana hitrost obnove zelo velikega števila datotek s kaset;
- izboljšan algoritem za izbiro naslednje kasete za zapis, zlasti ob enakih drugih pogojih upoštevamo obseg zapisnih/branih podatkov skozi celotno njeno življenje, izberemo najnovejšo;
- izboljšana stabilnost izdelka.
Koristne poveznice
Za popestritev navajam nekaj povezav tudi na rusko govoreče vire:
- In spet smo se vrnili na prejšnje mesto preglednih videov „Kako to deluje“ (res pa še v angleščini) – si jih lahko ogledate . O trakovih se govori na diapozitivih 95 – 102.
Izvor: habr.com
