Lerágott csont tudom, ransomware/betőrés/akaratlagos károkozás stb. Mind tudjuk, hogy ez itt bizony a valóság és tenni kell ellene. De mégis hogyan? Ha van egy működő rendszered, akkor hozzá mersz e nyúlni olyan mélyen, hogy az alapjaitól át tudd forgatni azt egy biztonságosabb működésre.
Szerecsére vannak olyan ügyfelek, akik ezt nem papírra leírt semmitmondó sorokkal oldják meg, hanem tevékenyen tesznek is érte. Nem mellesleg hallgatnak a szakemberekre, mikor arról van szó mit, hogyan és mire kell módosítani. Az alább egy nem kitalált ügyfél, nem fiktív projektje során szerzett tapasztalatokat összegzem.
CMO – current mode of operation
Elosztott Veeam Backup and Replication telepítés, tehát van több Backup Proxy és Backup Repository is. Minden komponense tartományi tagságú Microsoft Windows Server-en fut. Application aware, szalagos mentések és backup copy feladatok is üzemelnek.
FMO – future mode of operation
A Veeam Backup Server komponens átmozgatása egy új kiszolgálóra, egy olyan gépre, amely nem tagja a tartománynak. Az egyik Backup Repository átadása egy speciálisan erre épített – és a HPE referenciájában is szereplő kiszolgálóra – ráadásul a hardened repository mód használatával.
Átállási folyamat
Mielőtt belekezdek, arról megoszlanak a vélemények, hogy a Veeam Backup Server komponensnek kiszervezve egy virtuális gépben van-e a jobb helye vagy éppen ellenkezőleg, dedikált fizikai gépen jobb neki. Nyilvánvalóan mindkettőnek van előnye és hátránya, de ha a biztonságra törekszünk és nincs a menedzsment célokra dedikált és virtualizált – dedikált tárolóval, független tartománnyal – akkor jobb fizikai gépre tenni. Ha ilyen nincs, akkor véleményem szerint érdemesebb erre egy fizikai gépet szánni.
Veeam Backup and Replication Server átmozgatása
Van tehát egy jól működő Veeam rendszerünk és a legfontosabb részét szeretnénk migrálni egy másik kiszolgálóra. Sőt mi több, olyanra ami nem is tagja a tartománynak. És a neve is más.
A megoldás végtelenül egyszerű:
- az összes feladat megállítása – ha futnak éppen – és disabled-re állítása.
- konfiguráció mentése a forrás Veeam szerveren a VBR konzolból.
- a Veeam Backup & Replication telepítése az új szerveren.
- a mentett konfigurációból “visszaállítás”, ami Veeam felfogásában “Migrate”. Ha a konfiguráció mentésekor nem volt minden feladat “disabled”, akkor az alábbi ablakban a “Migrate” választása esetén azt észre is fogja venni és felteszi a kérdést, hogy biztos nem “Restore” ez inkább?
Ezzel el is készültünk. Mivel a konfigurációs mentés tartalmazza az elmentett felhasználó/jelszó párosokat, beállítani a feladatokban igazából semmit sem kell. Kozmetikai beavatkozásokra azonban szükség lehet. Tehát ha az új szerverünk neve más mint az amiről migráltunk, akkor a VBR rendszerben itt-ott a régi név köszön vissza. Nincs hatással a működésére, de előfordul az ilyen. Ekkor nem kell megrémülni, ha például Tape Server is így jelenik meg, akkor simán “remove” és hozzá kell adni újra. A media pool-ok, a katalógus, a mentési feladatok túlélik, sőt észre sem veszik.
Hardened repository
Egyelőre ilyen csak Linux alapon létezik – de rebesgetik, hogy hamarosan Windows-os is lesz – viszont azt viszonylag könnyű megépíteni. Egy ilyennek lényege, hogy a Veeam nincs birtokában a root jelszónak, igazából egy single use jogot kap. Nyilvánvalóan a komponensei telepítéséhez – és frissítéséhez!!! – kell neki emeltebb jog is.
Van pár megkötés, amit jó szem előtt tartani:
- a hardened repository nem lehet backup proxy
- reverse és forever forward incremental módozatokat nem lehet használni (nyilvánvaló, mivel ezek modosítják a már a repository-n lévő fájlokat is, amelyek viszont módosíthatatlanok).
- NAS backup, transaction mentések, RMAN/SAP HANA/SAP on Oracle integrált mentések szintén nem tudják használni.
A lenti képen látható módon felvett hardened repository-n a “Make recent backups immutable for X” be kell állítani. Ahogyan írja is, bármi aminek célja ez a repo, arra érvényes lesz ez az X nap. Viszont ha egy mentésnél vagy backup copy job-nál GFS-t állítunk be, akkor az ott beállítottakra szintén ez a repo szinten beállított érték érvényesül.
An immutability retention overrides a job retention: if the job retention period is shorter than the immutability period, Veeam Backup & Replication does not delete backup files when the retention period is over, but only when the immutability period expires.
Viszont a teljes láncolatot nézi, tehát ha van egy full mentésem, aztán napont inkrementális, akkor az utolsó inkrementálistól számolja rá a repository-n beállítottat.
Ha egy ilyen mentést Veeam irányból szeretnénk törölni, akkor nem sikerül. Azonos végeredményt kapunk a Linux alól is ha onnan távolítanánk el.
Veeam Backup Proxy
Sajnos a linux hardened repository nem tud egyben backup proxy is lenni, ezért mindenképpen kell valami ami a proxy funckiót el tudja látni. Hasonlóan van ez a Tape Server funkcióval is, arra kell egy fizikai gép, persze a kettő lehet azonos. Mount Server sem tud lenni, azt is egy másiknak kell biztosítania.
