Miről is szólna ez a blog, mint arról amivel találkozom napi munkám során és nem esik titoktartás alá és még talán érdekes is. Nagyobb vállalatoknál elvétve látni olyat, hogy ne lenne valamilyen a mentés helyétől független második példány a fontos kópiákból. Ha nincs, akkor ott valakit jól meg kell kérdezni, hogy mi a terv arra az esetre ha leég/zárlatos/korrupt lesz stb az elsődleges kópia, akár az egész adatszobával együtt.
SMB-ben pedig szinte elhanyagolható azon előfordulások száma – tapasztalataim szerint – ahol ez megoldott. Itt nem a második példány formátumáról van szó, nem számít hogy egy második USB-s HDD vagy LTO8 szalag…az a lényeg, hogy legyen és mondjuk még offline is legyen helyezhető – vagy éppen azzal egyenértékűen le lehessen „választani”.
Ha valaki mondjuk Veeam Backup and Replication terméket használ vagy éppen most szerez be, akkor jó eséllyel Veeam Universal License-t fog venni (VUL). Ami ebben szerintem igen jó, hogy ezzel a VBR Enterprise Plus szintjét használhatja, ami a gyártó VBR termékének a csúcsa.
Ennél fogva rengeteg dolgot tud, amit a többi kiadás csak korlátozottan vagy egyáltalán nem, de most a cikkben releváns képesség a Scale Out Backup Repository (továbbiakban SOBR). A mentési feladatokban – backup, backup copy, agent – a mentés céljánál egy backup repository-t kell megadni, ami lehet igazából egy share, egy szerver meghajtója, egy dedup appliance stb. A lényeg, hogy egyetlen egy ilyet tudunk megadni, tehát annak mérete igen jól kell legyen kialakítva, hogy mindenféle migrációk nélkül tudja fogadni a mentési adatokat.
A Scale Out Backup Repository pont ennek feloldására – is – készült. Extent-ekből áll, nyilván legalább egy kell bele és ha abban elfogy(na) a hely, akkor adható hozzá másik extent, mindez a job-ok módosításának igénye nélkül.
Picit tovább szofisztikálva a dolgot, két tier különböztetett meg egy SOBR esetén:
- performance tier: rövid távú tárolás, amolyan landing zone.
- capacity tier: objektum alapú tároló, amivel a hosszabb távú és/vagy DR megoldott.
A legtöbb helyen ahol SOBR-t látok, ott nincs capacity tier. Több extent-ből álló performance tier van, amelyek között két policy mentén történik az elhelyezés.
Én az elsőt látom gyakrabban, tekintve hogy ha egy mentési céltárolója van az ügyfélnek – és általában egy van – akkor az hogy az inkrementumokat egy másikra is képes lenne tedni teljesen irrelevánssá válik a performancia szempontjából. Utóbbi hátránya pont az, amit ír is, hogy ha az inkremenumokat tartalmazó bármelyik extent elveszik, akkor maximum a full mentésből lehet visszaállítani majd bármit.
Na de ugorjunk vissza a capacity tier-hez! Object storage, na ide mit lehet beadni?
- S3-compatible object storage repository
- Amazon S3
- Microsoft Azure Blob Storage
- Microsoft Azure Data Box
- IBM Cloud Object Storage
Tehát ha van valami on prem ami S3 kompatibilis, akkor azt használni tudja. Ha nincs, akkor az Amazon S3 vagy az Azure elég könnyen használatba vehető a felhőben. Utóbbit mutatom be, mármint hogy a capacity tier hogy használható egy Azure Blob-ban. Az Azure oldali beállításokat nem tárgyalom, főleg mert körülbelül két adatra van szükség a blob beállításához.
Nem meglepő módon fel kell venni az blob-ot mint repository.
Majd bekéri a repository kívánt nevét.
Aztán az authentikációnál a storage account nevét és az access key-t kell beírni – mindkettő Azure portálról kinyerhető – majd a régiót kell megadni – hát jó eséllyel az első lesz a nyerő kb mindenkinek kis hazánk táján. Az alsó pont viszont érdekes, szóval ha több extent van és különböző kiszolgálókon vannak, akkor mindegyiknek el kell tudnia érni az internetet, hacsak egyet ki nem jelölünk erre és akkor ő egyedül fogja végezni a blob-ba fel és onnan lefelé induló forgalmakat.
Ha minden sikeres, akkor megjelenik a blob-ban létrehozott container és kiválaszthatóvá válik. Itt alább például én kettőt hoztam létre.
És ez Veeam-ben látszik is.
SOBR létrehozás
A SOBR lérehozása eléggé egyszerű és vezetett folyamat.
Fel kell venni legalább egy performance tier extent-et.
Megadni a korábban ismeretett placement policy-t.
Illetve a capacity tier részleteit. Itt kell kiválasztani, azt amit előbb hoztunk létre. Itt több beállítás is van:
- ablak, mikor a feltöltési forgalom engedélyezett
- mikor történjen a feltöltés. Azonnal, mikor egy új mentési fájl megjelenik a performance tier-ben és/vagy amikor az ott elhelyezett kópia meghaladja az beállított eltelt napok számát.
- titkosítás
Ezzel el is készültünk, nincs más mint egy feladat létrehozása, ami ezt az új SOBR-t használja célként.
Nézzük mi történik
A mentés futásakor igazából semmi olyanra utalót nem látunk, hogy itt valami csoda történne. Simán lefut a mentés és semmi extrát nem ír. Viszont mikor végzett, akkor a futó feladatoknál lelhető fel maga a feltöltési feladat, méghozzá a mentési feladat nevével és annak Offload kiegészítésével hívva.
És akkor most tegyük fel hogy szükségünk van az adatra, arra az adatra ami már a felhőben van. Két ilyen lehetőséget látok:
- már feltöltésre került a retention miatt.
- elveszett minden on prem és utolsó esélyként a felhőből állítanánk vissza mindent.
Az első esetben ha indítjuk a restore feladatot, akkor elkezdi letölteni a blob-ból a szükséges fájlokat, de nem mindet, csak amennyi éppen kell. Tehát ha pl VM file restore-t indítok, akkor így néz ki.
Íme a hálózatnál látszik, hogy bizony tölti a kért adatokat.
A második esetben létre kell hozni a SOBR-t és simán egy rescan-t nyomni rajta.
Ezek után pedig, ahogyan az első helyzetben, lehet a visszaállítással haladni.
Összefoglaló
Lehet nem kellene ezt írnom, de ehhez semmiféle szaktudás nem kell. Öt perc alatt beállítható és megnyugtató lehet, hogy van még egy második/harmadik/off site mentés is. Nem vagyok nagy Azure tudós de azért azt simán be lehet állítani, hogy ne lehessen eltörölni olyan könnyen ami a blob-ban van.
