– Ó, semmilyen menedék nem bírja ki egy meteorit becsapódását. De ne aggódjon, hiszen Önnek, mint mindenkinek, van tartaléka.
Stanislaw Lem, „A csendes Ijon naplói”
A biztonsági másolat készítése azt jelenti, hogy az adatokat egy másik helyen mentjük el, eltérően az eredeti tárolási helytől.
A biztonsági mentés fő célja az adatok visszaállítása veszteség után. Ennek kapcsán gyakran hallhatjuk, hogy ha van egy adatbázis másolat, akkor azzal mindig vissza lehet állítani az adatokat, így a biztonsági mentés nem szükséges. Valójában a biztonsági mentés minimum három feladatot képes megoldani, amelyeket nem lehet megoldani egy replikával, és a replikát sem lehet inicializálni biztonsági mentés nélkül.
Először is, a biztonsági másolat lehetővé teszi az adatok visszaállítását logikai hiba után. Például, ha a könyvelő törölt egy csoport könyvelési tételt, vagy az adatbázis-adminisztrátor megsemmisítette a táblázati térséget. Mindkét művelet teljesen legitim az adatbázis szempontjából, és a replikációs folyamat azokat reprodukálni fogja a replikált adatbázisban.
Másodszor, a mai modern DBMS-ek nagyon megbízható programok, de néha mégis előfordulhat az adatbázis belső struktúráinak sérülése, amely után az adatokhoz való hozzáférés megszűnik. Különösen bosszantó, hogy ilyen hiba általában magas terhelés alatt vagy valamilyen frissítés telepítésekor történik. De mind a magas terhelés, mind a rendszeres frissítések azt jelzik, hogy az adatbázis korántsem tesztelés alatt áll, és az abban tárolt adatok értékesek.
Végül a harmadik feladat, amelynek megoldásához biztonsági másolatra van szükség, az adatbázis klónozása, például tesztelési célokra.
Az adatbázisok biztonsági mentése valamilyen módon az alábbi két elv egyikén alapul:
- Adatminták készítése, majd elmentés egy tetszőleges formátumban;
- Az adatbázis fájlok állapotának pillanatfelvétele és a naplók elmentése.
Nézzük meg részletesebben ezeket az elveket és a hozzájuk kapcsolódó eszközöket.
Adatok exportálása
Bármely DBMS-hez mellékelt eszközkészletben megtalálhatók az adatok exportáló és importáló eszközök. Az adatok vagy szöveges formátumban, vagy az adott DBMS által meghatározott bináris formátumban kerülnek mentésre. Az alábbi táblázatban találhatóak ezek az eszközök:
Binaris formátum
Szöveges formátum
Oracle
DataPump Export/DataPump Import
Exportálás/Importálás
SQL*Plus/SQL*Loader
PostgreSQL
pg_dump, pg_dumpall/pg_restore
pg_dump, pg_dumpall/psql
Microsoft SQL Server
bcp
bcp
DB2
kitöltés/megadás
kitöltés/megadás
MySQL
mysqldump, mysqlpump/mysql, mysqlimport
MongoDB
mongodump/mongorestore
mongoexport/mongoimport
Cassandra
nodetool snapshot/sstableloader
cqlsh
A szöveges formátum előnye, hogy külső programokkal szerkeszthető vagy akár létrehozható, míg a bináris formátum gyorsabb adatkiadásra és betöltésre alkalmas a formátumok átkonvertálásához szükséges erőforrások megtakarítása miatt.
Bár az adatok kiadásának egyszerű és nyilvánvaló ötlete van, a terhelt ipari adatbázisok biztonsági másolatának készítésekor ezt a módszert ritkán alkalmazzák. Íme néhány ok, amiért az adatkiadás nem alkalmas teljes értékű biztonsági mentésre:
- A kiadási folyamat jelentős terhelést igényel a forrásszerveren;
- A kiadás sok időt vesz igénybe – a kiadás befejezésekor már elavult lesz;
- Magas terhelés mellett gyakorlatilag lehetetlen a teljes adatbázis következetes kiadása, mivel az adatbázis-kezelő rendszereknek a kiadás kezdeti pillanatában kell rögzíteniük az állapotuk snapshotját. Minél több tranzakció történt a kiadás kezdete óta, annál nagyobb lesz a snapshot mérete (elavult adatok másolatai PostgreSQL-ben, undo tér Oracle-ben, tempdb Microsoft SQL Serverben stb.);
- A kiadás megtartja az adatok logikai struktúráját, de nem őrzi meg a fizikai struktúrájukat – táblák fizikai tárolási paramétereit, indexeket és másokat.
Mindazonáltal, a kiadásnak is vannak előnyei:
- nagyfokú szelektivitás: egyedi táblák, mezők és akár egyedi sorok kiadása is lehetséges;
- A kiadott adatokat más verziójú adatbázisba lehet betölteni, és ha a kiadás szöveges formátumban történt, akkor akár más adatbázisba is.
Tehát a kiadást főként olyan feladatokra használják, mint például kis táblák (például szótárak) biztonsági másolatának készítése vagy adatállományok terjesztése az alkalmazás következő kiadásával.
A legelterjedtebb adatbázis-biztonsági mentési módszer a fájlok másolása.
A DB fájlok „hideg” mentése
Nyilvánvaló ötlet – leállítani az adatbázist és lemásolni az összes fájlját. Ez a biztonsági másolat „hideg” mentésnek nevezik. Módszer rendkívül megbízható és egyszerű, de két nyilvánvaló hátránya van:
- A "cold" backup can only restore the state of the database that existed at the moment of shutdown; transactions made after the database restart will not be included in the "cold" backup.
- Not every database has a technological window when it can be stopped.
If you are satisfied with "cold" backups, you need to remember that
- the "cold" copy sometimes must also include logs. The methods of determining which logs should be included in the "cold" copy are individual for each DBMS. For example, in Oracle, it is necessary to copy what are called online redo logs, that is, a fixed number of log files in a special directory, even when the database is stopped properly. In PostgreSQL, you need to save all logs starting from the log that contains the last checkpoint, the information about which is contained in the control file.
- the database directory may contain quite large temporary tablespace files, which do not necessarily need to be included in the backup. By the way, this remark also applies to "hot" backups.
"Hot" file saving
Most modern database backups are performed by copying database files without stopping the database. Several issues arise here:
- At the moment the copying starts, the content of the database may not match the content of the files, since part of the information is in the cache and has not yet been written to disk.
- The content of the database can change during copying. If mutable data structures are used, then the contents of the files change, and when immutable structures are used, the set of files changes: new files appear, and old ones are deleted.
- Since writing data to the database and reading DB files are not synchronized, the backup program may read an inconsistent page, where half will be from the old version of the page and the other half from the new one.
To ensure that the backup is consistent, there is a command in each DBMS that indicates that the backup process has started. Syntactically, this command can look different:
- in Oracle, it is a separate command ALTER DATABASE/TABLESPACE BEGIN BACKUP;
- in PostgreSQL – the function pg_start_backup();
- A Microsoft SQL Server és a DB2 esetében a biztonsági másolat készítéséhez való előkészítés implicit módon történik a BACKUP DATABASE parancs végrehajtása során.
- A MySQL Enterprise, Cassandra és MongoDB esetében az előkészítést külső segédeszköz végzi – mysqlbackup, OpsCenter és Ops Manager, ezek sorrendben.
A szintaktikai eltérések ellenére a biztonsági másolat készítésének előkészítési folyamata hasonlóan zajlik.
Így néz ki a biztonsági másolat készítésének előkészítése a változtatható lemezszerkezetű DBMS-ekben, azaz minden hagyományos lemezes relációs rendszerben:
- A biztonsági másolat készítésének kezdete rögzítésre kerül; a biztonsági másolatnak tartalmaznia kell az adatbázis naplóit a rögzítés pillanatától kezdve.
- Egy ellenőrzési pont jön létre, ami azt jelenti, hogy minden olyan módosítást, ami az adatoldalakban a rögzített pillanat előtt történt, kiírják a lemezre. Ez garantálja, hogy a biztonsági másolat kezdetéig a naplók visszaállítás esetén nem lesznek szükségesek.
- Bekapcsol egy különleges naplózási módot: ha egy adatlap változik először azután, hogy a lemezről betöltötték, akkor ahelyett, hogy a lap változását naplóznák, az adatbázis a teljes lapot rögzíti. A felkészítési folyamat során minden lapot kiírnak a lemezre, így az első változás során a blokk mindig teljes mértékben naplózva lesz. De ha a biztonsági másolat készítése során a lapot újra kiírják a lemezre, akkor a következő változás ismét a lap teljes másolatát fogja a naplóba írni. Ez garantálja, hogy ha a biztonsági másolat készítése során az adatfájl hibás lesz, a napló alkalmazása helyreállítja azt.
- Megakadályozza az adatfájl fejléceinek módosítását, azaz a fejlécek azon részének átalakítását, amelyek módosításai a naplókban nem tükröződnek. Ez biztosítja, hogy a fejléct pontosan másolják, majd a naplókat pontosan alkalmazzák az adatfájlra.
Miután az összes fenti eljárást elvégezték, az adathalászati fájlok másolása a működési rendszer eszközeivel – cp, rsync és mások – megkezdhető. A biztonsági mentési mód engedélyezése csökkenti az adatbázis teljesítményét: egyrészt nő a naplófájlok mérete, másrészt, ha a biztonsági mentés közben hiba történik, a helyreállítás hosszabb ideig tart, mivel az adathalászati fájlok fejlécét nem frissítik. Minél gyorsabban fejeződik be a biztonsági mentés, annál jobb az adatbázis számára, ezért itt célszerű olyan eszközök használata, mint a fájlrendszer pillanatfelvétele (snapshot) vagy a tükörvágás (BCV) a tárolórendszerben. Néhány DBMS (Oracle, PostgreSQL) lehetővé teszi az adminisztrátor számára a másolási módszer kiválasztását, míg mások (Microsoft SQL Server) interfészt biztosítanak a saját biztonsági mentőeszközeik integrálására a fájlrendszer vagy tárolószolgáltatások mechanizmusaival.
A biztonsági mentés befejeztével a adatbázist vissza kell állítani a normál állapotába. Az Oracle-ban ezt az ALTER DATABASE/TABLESPACE END BACKUP parancs végrehajtásával tehetjük meg, PostgreSQL esetében a pg_stop_backup() függvény meghívásával, más adatbázisokban pedig a megfelelő parancsok vagy külső szolgáltatások belső alprogramjaival.
Így néz ki a biztonsági mentési folyamat időbeli diagramja:
- A biztonsági mentés előkészítése (begin backup) időt vehet igénybe, néha jelentőset. Még ha tükörlemezeket vagy pillanatképes fájlrendszereket is használnak, a biztonsági mentési folyamat nem lesz azonnali.
- Az adathalászati fájlokkal együtt meg kell őrizni a naplókat a biztonsági mentés előkészítése pillanatától egészen addig, amíg az adatbázist vissza nem állítják a normál állapotába.
- Az ezt a biztonsági másolatot visszaállítani lehet az adatbázis normál állapotának visszaállítási pillanatára. Korábbi időpontra való helyreállítás nem lehetséges.
Azokkal az adatbázisokkal, amelyek nem módosítható adatszerkezetekkel dolgoznak (memóriakép pillanatfelvételek, LSM-fák), a helyzet egyszerűbb. A biztonsági mentés előkészítése a következő lépésekből áll:
- Az adatokat a memóriából a lemezekre ki kell írni.
- Rögzíteni kell azokat a fájlokat, amelyek a biztonsági mentésbe kerülnek. Addig, amíg a biztonsági mentési folyamat be nem fejeződik, az adatbázis nem törölheti ezeket a fájlokat, még akkor sem, ha már nem szükségesek.
A biztonsági mentés befejezése után az érinthetetlen struktúrákkal rendelkező adatbázis újra törölheti a felesleges fájlokat.
Visszaállítás pontra
A biztonsági mentés lehetővé teszi, hogy az adatbázis állapotát azon a ponton állítsuk vissza, amikor a visszatérési parancs a biztonsági mentés üzemmódjából befejeződött. Azonban bármikor bekövetkezhet egy katasztrófa, amely helyreállítást igényel. Az adatbázis állapotának adott időpontra történő helyreállítását "visszaállítás pontra" (point-in-time recovery) nevezzük.
E lehetőség biztosításához a biztonsági mentés befejezését követően folyamatosan kell tárolni az adatbázis naplóit, és a helyreállítás során folytatni kell a naplók alkalmazását a helyreállított másolatra. Miután az adatbázist a biztonsági mentésből a másolás befejezési pontján helyreállították, az adatbázis állapota (fájlok és gyorsítótárazott oldalak) garantáltan helyes, ezért különleges naplózási módra nincs szükség. A naplók adott időpontig történő alkalmazásával az adatbázis bármely időpontban állapotot kaphat.
Ha a biztonsági másolat helyreállításának sebességét csak a lemez sávszélessége korlátozza, akkor a naplók alkalmazásának sebességét általában a CPU teljesítménye határozza meg. Ha a fő adatbázisban párhuzamosan történnek a módosítások, akkor a helyreállítás során minden változtatást sorban hajtanak végre – a naplóból való olvasás sorrendjében. Így a helyreállítási idő lineárisan függ attól, hogy a helyreállítási pont mennyire messze van a biztonsági mentés végétől. Ezért viszonylag gyakran kell teljes biztonsági mentéseket készíteni – legalább hetente egyszer az alacsony tranzakciós terhelésű adatbázisok esetében, és napi biztonsági mentést a nagy terhelésű adatbázisok esetében.
Inkramentális biztonsági mentés
A helyreállítás gyorsítása érdekében jó lenne, ha a biztonsági mentéseket minél gyakrabban végezhetnénk, de úgy, hogy közben ne foglaljunk el felesleges helyet a lemezeken, és ne terheljük meg az adatbázist biztonsági mentési feladatokkal.
A feladat megoldása – az inkramentális biztonsági mentés, azaz csak azoknak az adatlaponk, amelyek a legutolsó biztonsági mentés óta megváltoztak.
Az inkrementális biztonsági mentés csak módosítható adatszerkezetet használó DBMS-ek esetén indokolt.
Az inkrementum számolható teljes biztonsági mentésből (kumulatív másolat) vagy bármilyen korábbi másolatból (differenciális másolat) is.
Sajnálatos módon egységes terminológia nem létezik, és különböző gyártók eltérő kifejezéseket használnak:
Differenciális
Kumulatív
Oracle
Differential
Cumulative
PostgresPro
Növekményes
—
Microsoft SQL Server
—
Differential
IBM DB2
Delta
Növekményes
Az inkrementális másolatok megléte esetén a visszaállítási folyamat a következőképpen néz ki:
- visszaáll a legutolsó teljes biztonsági mentés, amely a visszaállítás előtt készült;
- a teljes másolatra az inkrementális másolatok kerülnek visszaállításra;
- a naplók frissítve lesznek a biztonsági mentés kezdőpontjától a visszaállítási pontig.
A kumulatív másolat megléte felgyorsítja a visszaállítási folyamatot. Például egy állapot visszaállításához két inkrementális másolat szükséges a T3 és T4 közötti ponton, míg T4 utáni ponton csak egyre van szükség.
Nyilvánvaló, hogy egy kumulatív másolat mérete kisebb, mint több differentiális másolaté, mert egyes lapok többször megváltoztak, és minden inkrementális másolat a saját verzióját tartalmazza.
Három módszer létezik az inkrementális másolat készítésére:
- teljes másolat készítése és a korábbi teljes másolat eltéréseinek kiszámítása;
- naplók elemzése, megváltozott oldalak listájának létrehozása és az abban szereplő lapok biztonsági másolatának elkészítése;
- a megváltozott oldalak lekérdezése az adatbázisban.
Az első módszer megtakarítja a lemezterületet, de nem oldja meg az adatbázis terhelésének csökkentését. Sőt, ha van egy teljes biztonsági mentésünk, akkor annak inkrementálissá alakítása értelmetlen, mivel a teljes másolat visszaállítása gyorsabb, mint a korábbi teljes másolat és inkrementális másolat visszaállítása. A lemezterület megspórolásának feladatát inkább speciális komponensekre kell bízni, amelyek beépített deduplikálási mechanizmusokkal rendelkeznek. Ezek lehetnek speciális tárolórendszerek (EMC DataDomain, HPE StorageWorks VLS, a NetApp teljes termékcsaládja), valamint szoftvertermékek (ZFS, Veritas NetBackup PureFile, Windows Server Data Deduplication).
A második és a harmadik módszer a módosított oldalak listájának meghatározásában különbözik. A naplók elemzése erőforrás-igényesebb, és annak megvalósításához ismerni kell a naplófájlok struktúráját. A legegyszerűbb megkérdezni magát az adatbázist, hogy pontosan mely oldalak változtak, de ehhez az adatbázis-kezelő rendszer magjának rendelkeznie kell a módosított blokkok nyomon követési funkciójával (block change tracking).
Az inkrementális biztonsági mentés funkcionalitását először az Oracle Recovery Manager (RMAN) szoftverben hozták létre, amely az Oracle 8i kiadásával jelent meg. Az Oracle azonnal megvalósította a módosított blokkok nyomon követését, így már nincs szükség a naplók elemzésére.
A PostgreSQL nem követi nyomon a módosított blokkokat, ezért a pg_probackup eszköz, amelyet a Postgres Professional orosz vállalat fejlesztett, a napló elemzésével határozza meg a módosított oldalakat. Azonban a cég biztosítja a PostgresPro adatbázist is, amely tartalmazza a ptrack kiterjesztést, amely nyomon követi az oldalváltozásokat. A pg_probackup használata során a PostgresPro adatbázissal az eszköz az adatbázistól kéri le a módosított oldalakat – pontosan úgy, mint az RMAN.
A Microsoft SQL Server, akárcsak az Oracle, nyomon követi a módosított oldalakat, de a BACKUP parancs csak teljes és kumulatív biztonsági mentések készítését teszi lehetővé.
Az DB2 lehetőséget nyújt a módosított oldalak nyomon követésére, de alapértelmezés szerint ez ki van kapcsolva. A bekapcsolás után az DB2 lehetővé teszi a teljes, differenciális és kumulatív biztonsági mentések készítését.
A jelen szakaszban leírt eszközök (kivéve a pg_probackup) fontos különbsége a fájl alapú biztonsági mentési eszközökhöz képest, hogy az adatbázistól kérik az oldalképeket, nem pedig saját maguk olvassák ki az adatokat a lemezről. Ennek a megközelítésnek a hátránya a kis mértékű többletterhelés az adatbázison. Azonban ezt a hátrányt bőven kompenzálja az a tény, hogy az olvasott oldal mindig helyes, így nincs szükség különleges naplózási mód bekapcsolására a biztonsági mentés idejére.
Még egyszer hangsúlyozni kell, hogy az inkrementális másolatok megléte nem törli a naplók meglétére vonatkozó követelményeket, amelyek szükségesek egy tetszőleges időpontra való helyreállításhoz. Ezért az ipari adatbázisokban a naplókat folyamatosan kívülre rögzítik, míg a teljes és/vagy inkrementális biztonsági mentések ütemezés szerint készülnek.
A legjobb megvalósítása ma az inkrementális mentés ötletének az Oracle definíciója szerint a Zero Data Loss Recovery Appliance – egy speciális megoldás az Oracle-tól az adatbázisok mentésére. A rendszer egy klasztert képvisel szerverek nagy mennyiségű lemezzel, amelyen a Recovery Manager módosított verziója található, és képes működni más Oracle programozott-hardware komplexumokkal (Database Appliance, Exadata, SPARC Supercluster), valamint hagyományos infrastruktúrával rendelkező Oracle adatbázisokkal. A „hagyományos” RMAN-tól eltérően a ZDLRA implementálja a „végtelen inkrementálás” koncepciót. A rendszer egységes alkalommal készít el egy teljes másolatot az adatbázisról, majd csak inkrementális másolatokat készít. Az RMAN kiegészítő modulok lehetővé teszik a másolatok egyesítését, új teljes másolatok létrehozását az inkrementális másolatokból.
Az orosz fejlesztők dicsőségére meg kell említeni, hogy a pg_probackup is képes az inkrementális másolatok egyesítésére.
Sok hasonló kérdéstől eltérően a „melyik mentési módszer a legjobb” kérdésnek egyértelmű válasza van – a legjobb a használt DBMS natív segédprogramja, amely lehetővé teszi az inkrementális mentést.
Az adatbázis-adminisztrátor számára sokkal fontosabb kérdések a mentési stratégia kiválasztása és az adatbázisok mentési eszközeinek integrálása a vállalati infrastruktúrába. De ezek a kérdések túllépnek ennek a cikknek a keretein.
Forrás: habr.com
