Az adatbázis-adminisztrátorok fel vannak osztva azokra, akik biztonsági másolatot készítenek, és azokra, akik biztonsági másolatot készítenek.
Ez a cikk az IB 1C legáltalánosabb biztonsági mentését ismerteti MS-eszközök használatával SQL szerver 2008 R2, elmagyarázza, miért így kell csinálni, és miért nem másként, és eloszlat több mítoszt. A cikkben sok hivatkozás található az MS SQL dokumentációjához, ez a cikk inkább a biztonsági mentési mechanizmusok áttekintése, semmint átfogó útmutató. De azok számára, akik először szembesülnek ezzel a feladattal, egyszerű és lépésről lépésre szóló utasításokat kapnak, amelyek egyszerű helyzetekre vonatkoznak. A cikk nem az adminisztrációs guruknak szól, a guruk már tudják mindezt, de feltételezhető, hogy az olvasó képes maga telepíteni az MS SQL Server-t, és arra kényszeríti az ellenséges technológia csodáját, hogy hozzon létre egy adatbázist a gyomrában, ami viszont ő maga képes 1C adatok tárolására kényszeríteni.
Úgy gondolom, hogy a TSQL BACKUP DATABASE parancs (és testvére BACKUP LOG) az egyetlen biztonsági mentési eszköz az MS SQL Servert DBMS-ként használó 1C adatbázisokhoz. Miért? Nézzük, milyen módszereink vannak általában:
| Hogyan | Bírság | Rosszul | Teljes |
| Feltöltés ide: dt | Nagyon kompakt formátum. | Hosszú ideig tart a formázás, kizárólagos hozzáférést igényel, nem ment el néhány jelentéktelen adatot (például a korábbi verziók felhasználói beállításait), hosszú ideig tart a telepítés. | Ez nem annyira biztonsági mentési módszer, hanem az adatok egyik környezetből a másikba való átvitelének módja. Ideális keskeny csatornákhoz. |
| Mdf és ldf fájlok másolása | Nagyon világos módszer a kezdő rendszergazdák számára. | Megköveteli az adatbázis fájlok feloldását a zárból, és ez akkor lehetséges, ha az adatbázis le van tiltva ( offline parancs helyi menü), megszakadt (leválasztás), vagy éppen leállította a szervert. Nyilvánvaló, hogy a felhasználók jelenleg nem fognak tudni dolgozni. | Akkor és csak akkor van értelme ezt a módszert alkalmazni, ha már meghibásodás történt, hogy a visszaállítás során legalább vissza tudjunk térni ahhoz az opcióhoz, amelyből a visszaállítás elkezdődött. |
| Biztonsági mentés OS vagy hypervisor segítségével | Kényelmes módja a fejlesztési és tesztelési környezeteknek. | Nem mindig barátkozik az adatok integritásával. erőforrásigényes módon. | Korlátozottan alkalmazható fejlesztésre. Az élelmiszer-környezetben nincs gyakorlati jelentése. |
| Biztonsági mentés MS SQL használatával | Nem igényel leállást. Lehetővé teszi a konzisztens állapot visszaállítását egy tetszőleges pillanatra, ha előre gondoskodik róla. Tökéletesen automatizált. Időt és egyéb erőforrásokat takarít meg. | Nem túl kompakt. Nem mindenki tudja, hogyan kell ezt a módszert a szükséges mértékben használni. | Gyártási környezetekhez - a fő eszköz. |
A beépített MS SQL eszközökkel történő biztonsági mentés során a fő nehézségek a működési elvek alapvető félreértése miatt merülnek fel. Ezt részben a nagy lustaság magyarázza, részben az egyszerű és érthető magyarázat hiánya a "készreceptek" szintjén (hmm, mondjuk én nem láttam), sőt a helyzetet a mitológiai "under-guru" tanácsai a fórumokon. Nem tudok mit kezdeni a lustasággal, de megpróbálom elmagyarázni a biztonsági mentés alapjait.
Réges-régen, egy távoli galaxisban létezett egy olyan mérnöki és számviteli termék, mint az 1C: Enterprise 7.7. Nyilvánvalóan annak a ténynek köszönhető, hogy az 1C:Enterprise első verzióit a népszerű dbf fájlformátum használatára fejlesztették ki, az SQL verziója nem tárolt elegendő információt az adatbázisban ahhoz, hogy az MS SQL biztonsági mentését befejezettnek tekintse, és még a struktúra minden változása esetén sem, a teljes helyreállítási modell működési feltételeit, ezért különböző trükkökhöz kellett menni ahhoz, hogy a biztonsági mentési rendszer betöltse fő funkcióját. A 8-as verzió megjelenése óta azonban a DBA-k végre megnyugodhattak. A rendszeres biztonsági mentési eszközök lehetővé teszik a biztonsági mentések teljes és teljes rendszerének létrehozását. Csak a regisztrációs napló és néhány apróság, mint például az űrlapok pozíciójának beállítása (a régebbi verziókban) nem szerepel a biztonsági mentésben, de ezeknek az adatoknak az elvesztése nem befolyásolja a rendszer működését, bár ez mindenképpen helyes és hasznos készítsen biztonsági másolatot a regisztrációs naplóról.
Egyáltalán miért van szükségünk biztonsági mentésre? Hm. Első pillantásra ez egy furcsa kérdés. Nos, valószínűleg először is, hogy telepíteni lehessen a rendszer másolatát, másodszor pedig a rendszer visszaállítására hiba esetén? Az elsővel egyetértek, de a második találkozó az első tartalék mítosz.
A biztonsági mentés a rendszerintegritás utolsó védelmi vonala. Ha az adatbázis-adminisztrátornak biztonsági mentésekből kell visszaállítania a termékrendszert, az azt jelenti, hogy nagy valószínűséggel sok baklövést követtek el a munkaszervezésben. A biztonsági mentést nem lehet az adatok integritásának biztosításának fő módjaként kezelni, nem, ez inkább egy tűzoltó rendszer. Tűzoltó rendszerre van szükség. Be kell állítani, tesztelni és működőképes. De ha működött, akkor ez önmagában súlyos vészhelyzet, sok negatív következménnyel.
Annak érdekében, hogy a biztonsági mentés csak "békés" célokra használható legyen, használjon más eszközöket a teljesítmény biztosítására:
A rendszer rendelkezésre állási követelményeitől és az erre a célra elkülönített költségvetéstől függően nagyon is lehetséges olyan megoldásokat választani, amelyek 1-2 nagyságrenddel csökkentik az állásidőt és a katasztrófa utáni helyreállítást. Nem kell félni az akadálymentesítési technológiáktól: elég egyszerűek ahhoz, hogy az MS SQL alapismeretével néhány nap alatt megtanulják.
De mindennek ellenére biztonsági mentésre továbbra is szükség van. Ez ugyanaz a tartalék ejtőernyő, amelyet akkor használhat, ha minden más menekülési mód meghiúsul. De, mint egy igazi tartalék ejtőernyő, erre:
Az MS SQL-ben az adatokat általában adatfájlokban tárolják (a továbbiakban az FD nem egy általánosan használt rövidítés, ebben a cikkben lesz még néhány nem túl gyakori rövidítés), mdf vagy ndf kiterjesztéssel. Ezeken a fájlokon kívül vannak még tranzakciós naplók (LT), amelyek ldf kiterjesztésű fájlokban tárolódnak. Nem ritka, hogy a kezdő rendszergazdák felelőtlenek és rámenősek a VT-vel kapcsolatban, mind a teljesítmény, mind a tárolási megbízhatóság tekintetében. Ez egy nagyon durva hiba. Sőt, ellenkezőleg, ha van egy megbízhatóan működő biztonsági mentési rendszer, és sok idő fordítható a rendszer helyreállítására, akkor egy gyors, de rendkívül megbízhatatlan RAID-0-n tárolhatja az adatokat, de akkor a VT-t tárolni kell. egy külön megbízható és produktív erőforráson (bár RAID-1-en lenne). Miert van az? Nézzük meg közelebbről. Azonnal tegyen egy fenntartást, hogy az előadás kissé leegyszerűsített, de elegendő a kezdeti megértéshez.
Az FD 8 kilobyte-os oldalakon tárolja az adatokat (ezeket 64 kilobájt terjedelemben egyesítik, de ez nem lényeges). MS SQL nem garantálja hogy az adatok módosítására irányuló parancs végrehajtása után azonnal ezek a változtatások az FD-be esnek. Nem, csak arról van szó, hogy a memóriában lévő oldal "mentést igénylő"-ként van megjelölve. Ha a szervernek elegendő erőforrása van, akkor hamarosan ezek az adatok a lemezen lesznek. Ezen túlmenően a szerver "optimistán" működik, és ha ezek a változások egy tranzakció során bekövetkeznek, akkor a tranzakció véglegesítése előtt a lemezre kerülhetnek. Azaz általános esetben aktív munka Az FD elszórtan tartalmaz befejezetlen adatokat és olyan hiányos tranzakciókat, amelyekről nem tudni, hogy törlik-e vagy lekötik-e azokat. Van egy speciális "CHECKPOINT" parancs, amely arra utasítja a szervert, hogy "most" ürítse ki az összes nem mentett adatot a lemezre, de ennek a parancsnak a hatóköre meglehetősen specifikus. Elég, ha azt mondjuk, hogy az 1C nem használja (nem találkoztam vele), és megértjük, hogy működés közben az FD általában nincs konzisztens állapotban.
Ennek a káosznak a kezelésére csak VT-re van szükségünk. A következő események vannak ráírva:
Mindezek az információk meg vannak írva, jelezve annak a tranzakciónak az azonosítóját, amelyben megtörtént, és elegendő mennyiségben ahhoz, hogy megértsük, hogyan lehet a művelet előtti állapotból a művelet utáni állapotba lépni, és fordítva (a kivétel a tömegesen naplózott helyreállítási modell) .
Fontos, hogy ezeket az információkat azonnal lemezre írjuk. Amíg az információ nincs rögzítve a VT-ben, a parancs nem tekinthető végrehajtottnak. Normál helyzetben, amikor a VT mérete elegendő és nem nagyon töredezett, a rekordok egymás után kis rekordokban (nem feltétlenül a 8 kb többszörösei) íródnak rá. Csak a helyreállításhoz valóban szükséges adatok kerülnek a tranzakciós naplóba. Különösen Nem információk érkeznek arról, hogy milyen kérés szövege vezetett módosításokhoz, milyen végrehajtási terve volt a kérelemnek, melyik felhasználó indította el, és egyéb, a helyreállításhoz szükségtelen információk. A tranzakciós napló adatszerkezetéről a lekérdezés adhat némi elképzelést
Válasszon * from::fn_dblog(null,null)
Tekintettel arra, hogy a merevlemezek sokkal hatékonyabban működnek a szekvenciális írásokkal, mint az olvasási és írási parancsok kaotikus folyamával, és mivel az SQL-parancsok megvárják a VT-be való írás végét, a következő ajánlás merül fel:
Ha a legkisebb lehetőség is fennáll, akkor éles környezetben a VT-ket külön (minden mástól) fizikai adathordozón kell elhelyezni, lehetőleg minimális hozzáférési idővel a szekvenciális írásokhoz és maximális megbízhatósággal. Mert egyszerű rendszerek A RAID-1 jó.
Ha a tranzakció törlésre kerül, akkor a szerver az összes már végrehajtott változtatást visszaállítja az előző állapotba. Ezért
Egy tranzakció törlése az MS SQL Server rendszerben általában a tranzakció adatmódosítási műveleteinek teljes időtartamához hasonlítható. Próbáljon meg ne törölni tranzakciókat, vagy döntsön a lehető legkorábbi törlés mellett.
Ha a szerver valamilyen okból váratlanul leáll, akkor újraindításkor elemzi, hogy az FD-ben mely adatok nem felelnek meg egy konzisztens állapotnak (nem rögzített, de véglegesített tranzakciók és rögzített, de törölt tranzakciók), és ezeket az adatokat javítja. Ezért, ha például elkezdte egy nagy tábla indexeinek újraépítését, és újraindította a szervert, akkor az újraindításkor jelentős időbe telik a tranzakció visszaállítása, és nincs mód a folyamat megszakítására.
Mi történik, ha a JT eléri a fájl végét? Egyszerű - ha van szabad hely az elején, akkor elkezd írni a fájl elején lévő szabad helyre, amíg elfoglalt hely. Mint egy hurkos mágnesszalag. Ha az elején nincs hely, akkor a szerver általában megpróbálja kibővíteni a tranzakciós naplófájlt, míg a szerver számára az új lefoglalt darab egy új virtuális tranzakciós naplófájl, amely sok lehet a fizikai tranzakciós fájlban, de ez nem elég a biztonsági mentéshez. Ha a szerver nem tudja kibontani a fájlt (elfogy a lemezterület, vagy tilos a VT kiterjesztése a beállításokban), akkor az aktuális tranzakció 9002-es hibával törlődik.
Hoppá. És mit kell tenni, hogy mindig legyen hely a ZhT-ben? Itt jutunk el a biztonsági mentési rendszerhez és a helyreállítási modellekhez. A tranzakciók törléséhez és a szerver megfelelő állapotának visszaállításához hirtelen leállás esetén a rekordokat az LT-ben kell tárolni, a legkorábbi nyitott tranzakció kezdetétől. Ezt a minimumot a JT-ben írják és tárolják Szükségszerűen. Függetlenül az időjárástól, a szerver beállításaitól és az adminisztrátor kívánságától. A szerver nem engedheti meg, hogy ez az információ hiányzik. Ezért ha megnyit egy tranzakciót az egyik munkamenetben, és különböző műveleteket hajt végre a többiben, a tranzakciónapló váratlanul véget érhet. A legkorábbi tranzakció a DBCC OPENTRAN paranccsal azonosítható. De ez csak a szükséges minimális információ. Az, hogy ezután mi történik, attól függ helyreállítási modellek. Az SQL Serverben három van:
Számos mítosz kapcsolódik a helyreállítási modellekhez.
Az 1C adatbázisok tömegesen naplózott modelljét szinte értelmetlen használni, ezért nem foglalkozunk vele a továbbiakban. A Full és Simple közötti választást azonban a következő részben részletesebben tárgyaljuk.
Háromféle biztonsági mentés létezik a formáció típusától függően:
Ne keverje össze magát: a teljes helyreállítási modell és a teljes biztonsági mentés alapvetően különböző dolgok. Annak érdekében, hogy ne keverjük össze őket, az alábbiakban angol kifejezéseket használok a helyreállítási modellre, és orosz kifejezéseket a biztonsági mentések típusaira.
A teljes és a differenciált másolás ugyanúgy működik az egyszerű és a teljes másolásnál. A tranzakciónapló biztonsági mentése teljesen hiányzik a Simple-ből.
Lehetővé teszi az adatbázis állapotának visszaállítását egy bizonyos időpontra (a biztonsági mentés megkezdésének időpontjára). Ez az adatfájlok használt részének lapozott másolatából és a tranzakciós napló aktív részéből áll, a biztonsági mentés készítésének idejére.
Az utolsó teljes biztonsági mentés óta megváltozott adatok oldalait tárolja. A visszaállítás során először vissza kell állítania egy teljes biztonsági másolatot (NOREVERY módban az alábbiakban példákat mutatunk be), majd bármelyik későbbi differenciálmásolatot alkalmazhatja a kapott „üresre”, de természetesen csak azokat, amelyeket a következő előtt készítettek. teljes biztonsági mentés. Ez jelentősen csökkentheti a hangerőt lemez terület a biztonsági másolat tárolására.
Fontos pontok:
Tartalmazza a VT egy példányát egy bizonyos időszakra. Általában az utolsó RKZHT pillanatától a jelenlegi RKZHT megalakulásáig. Az RCRT lehetővé teszi az állapot visszaállítását bármely későbbi időpontban, amely beletartozik a visszaállított biztonsági másolat időközébe, a NORECOVERY módban visszaállított másolattól az RT visszaállított másolatának időszakába tartozó bármely időpontig. Normál paraméterekkel rendelkező biztonsági mentés létrehozásakor a tranzakciós naplófájlban lévő hely felszabadul (az utolsó nyitott tranzakció pillanatáig).
Nyilvánvaló, hogy az RKZhT-nek nincs értelme a Simple modellben (akkor a VT csak az utolsó lezáratlan tranzakció pillanatától tartalmaz információkat).
Az RKZHT használatakor egy fontos koncepció merül fel - folyamatos lánc RKZhT. Ezt a láncot megszakíthatja a lánc egyes biztonsági másolatainak elvesztése, vagy az adatbázis egyszerűre váltása és fordítva.
Figyelmeztetés: Az RCST-k halmaza lényegében használhatatlan, hacsak nem egy összefüggő láncról van szó, és az utolsó sikeres teljes vagy differenciális biztonsági mentés kezdő időpontjának belül ennek a láncnak az időszaka.
Gyakori tévhitek és mítoszok:
Legyen egy 1000 GB-os adatbázis. Az adatbázis minden nap 2 GB-tal nő, miközben 10 GB régi adatot módosít. Elkészítette a következő biztonsági mentéseket
Ezzel a készlettel február 1-től február 14-ig bármelyik napon 0:00-kor tudjuk visszaállítani az adatokat. Ehhez el kell készítenünk az F1 teljes példányát a február 1-7-ig tartó hétre, vagy az F2 teljes példányát február 8-14-re, vissza kell állítani NORECOVERY módban, majd alkalmazni kell a kívánt nap differenciált másolatát.
Tegyük fel, hogy ugyanaz a teljes és differenciális biztonsági mentés készletünk van, mint az előző példában. Ezen kívül vannak a következő RKZHT:
Jegyzet:
A legegyszerűbb esetben vissza kell állítani:
Először az F2-t állítják vissza, majd a D2.2-t, majd az RKZHT 6-ot február 10-én 13:13:13-ig. De a Full modell jelentős előnye, hogy választhatunk - a legújabb teljes vagy differenciális példányt használjuk, vagy NEM a legújabbat. Például, ha kiderül, hogy a D2.2 másolata sérült, és február 10-én 13:13:13 előtti pillanatra kell visszaállítanunk, akkor az egyszerű modell esetében ez azt jelentené, hogy csak a következőre tudjuk visszaállítani az adatokat. a pillanat D2.1. A Full - "DON" T PANIC) funkcióval a következő lehetőségeink vannak:
Amint látja, a teljes modell több választási lehetőséget biztosít számunkra.
Most képzeld el, hogy nagyon ravaszok vagyunk. És pár nappal a kudarc előtt (13:13:13 február 10.) tudjuk, hogy kudarc lesz. Az adatbázist a szomszédos kiszolgálón lévő teljes biztonsági másolatból állítjuk vissza, lehetővé téve a következő állapotok differenciális másolatokkal vagy RKZHT-val történő kiküldését, azaz NORECOVERY módban hagyva. És minden alkalommal közvetlenül az RKZhT megalakulása után alkalmazzuk erre a tartalékbázisra, és a NORECOVERY módban hagyjuk. Azta! Most már csak 10-15 percet vesz igénybe az adatbázis visszaállítása, ahelyett, hogy egy hatalmas adatbázist állítanánk vissza! Gratulálunk, újra feltaláltuk a rönkszállítási mechanizmust, amely az állásidő csökkentésének egyik módja. Ha nem egy periódusonként, hanem folyamatosan viszünk át ilyen módon adatokat, akkor a tükrözés kiderül, és ha a forrásbázis megvárja a tükörbázis frissítését, akkor ez szinkron tükrözés, ha nem vár, akkor aszinkron.
A magas rendelkezésre állású eszközökről a súgóban olvashat bővebben:
Ezt a részt nyugodtan kihagyhatja, ha unja az elméletet és a biztonsági mentési beállítások kipróbálását.
1C: A vállalat valójában nem tudja, hogyan kell dolgozni a fájlcsoportokkal. Egyetlen fájlcsoport van és ennyi. Valójában egy programozó vagy MS SQL adatbázis-adminisztrátor képes egyes táblákat, indexeket, vagy akár tábla- és indexrészeket külön fájlcsoportokba helyezni (a legegyszerűbb változatban egyedi fájlokat). Erre vagy annak érdekében van szükség, hogy felgyorsítsuk a hozzáférést bizonyos adatokhoz (nagyon gyors adathordozóra téve), vagy fordítva, a sebességet fel kell áldozni az olcsóbb adathordozókra (például a keveset használt, de terjedelmes adatokra). Fájlcsoportokkal végzett munka során lehetőség van róluk külön biztonsági másolatot készíteni, illetve külön-külön vissza is lehet őket állítani, de számolni kell azzal, hogy az RKZHT görgetésével minden fájlcsoportot egy pillanatra "fel kell fogni".
Ha egy személy szabályozza az adatok különböző fájlcsoportokban való elhelyezését, akkor amikor több fájl van a fájlcsoporton belül, akkor az MS SQL Server egymástól függetlenül tolja rájuk az adatokat (egyenlő mennyiségű fájl esetén egyenletesen próbálkozik). Alkalmazási szempontból ez az I/O műveletek párhuzamosítására szolgál. És ami a biztonsági mentést illeti, van még egy szempont. Az "SQL 2008 előtti" korszak nagyon nagy adatbázisainál tipikus probléma volt egy folyamatos ablak lefoglalása a teljes biztonsági mentéshez, és előfordulhat, hogy a biztonsági mentés céllemeze egyszerűen nem fér bele. a legtöbben egyszerű módon ebben az esetben minden fájlról (vagy fájlcsoportról) biztonsági másolatot kellett készíteni a saját ablakában. A biztonsági mentések tömörítésének aktív elterjedésével ez a probléma csökkent, de ez a technika továbbra is szem előtt tartható.
Az MS SQL Server 2008 szuper-mega-ultra funkcióval rendelkezik. Mostantól a mentések menet közben is tömöríthetők. Ez 5-10-szeresére csökkenti az 1C adatbázis biztonsági másolatának méretét. És tekintve, hogy általában a teljesítmény lemez alrendszer A DBMS szűk keresztmetszete, ez nem csak a tárolás költségeit csökkenti, hanem erőteljes mentési gyorsítást is biztosít (bár a processzorok terhelése nő, de általában a processzor teljesítménye elégséges a DBMS-kiszolgálón).
Ha a 2008-as verzióban ez a funkció csak az Enterprise kiadásban volt elérhető (ami nagyon drága), akkor 2008 R2-ben ezt a funkciót a Standard verzió kapta meg, ami nagyon tetszetős.
Az alábbi példák nem tárgyalják a tömörítési beállításokat, de erősen javaslom a biztonsági mentési tömörítés használatát, hacsak nincs konkrét oka annak kikapcsolására.
Valójában a biztonsági másolat nem csak egy fájl, hanem egy meglehetősen összetett tároló, amely számos biztonsági másolatot képes tárolni. Ennek a megközelítésnek nagyon régi története van (személyesen megfigyeltem a 6.5-ös verzió óta), de jelenleg nincs komoly ok arra, hogy a "szokásos" adatbázisok, különösen az 1C adatbázisok adminisztrátorai ne használják az "egy biztonsági másolat - egy fájl" kifejezést. megközelítés . Az általános fejlesztéshez hasznos lehet megvizsgálni, hogy egy fájlba több biztonsági másolatot is lehet tenni, de nagy valószínűséggel nem kell használnia (vagy ha kell, akkor egy leendő rendszergazda blokkolásai között válogatva, aki ezt a lehetőséget szakképzetlenül).
Az SQL Server egy másik nagyszerű funkcióval is rendelkezik. Lehetőség van több vevőkészülékhez párhuzamosan biztonsági másolat készítésére. Egyszerű példaként kiírhat egy másolatot a helyi lemezre, és egyidejűleg kiírhatja rá hálózati erőforrás. A helyi másolat kényelmes, mivel az abból való visszaállítás sokkal gyorsabb, míg a távoli másolat sokkal jobban átvészeli a fő adatbázis-kiszolgáló fizikai megsemmisülését.
Elég az elmélet. Ideje gyakorlattal bebizonyítani, hogy ez az egész konyha működik.
Ez a rész kész receptek formájában épül fel magyarázatokkal. Ez a rész a képek miatt nagyon unalmas és hosszú, szóval ki lehet hagyni.
Rögtön felmerül a kérdés, mi kell még? Úgy tűnik, hogy most mindent beállítottak, és minden működik, mint az óramű? Minek kínlódni mindenféle forgatókönyvvel? A szolgáltatási tervek nem teszik lehetővé:
A következő tipikus biztonsági mentési parancsok
Teljes biztonsági mentés a meglévő fájl felülírásával (ha van ilyen) és az oldalellenőrző összegek ellenőrzése írás előtt. A biztonsági mentés létrehozásakor az előrehaladás minden százaléka számít
ADATBÁZIS BIZTONSÁGI MENTÉSE LEMEZRE = N"C:\Backup\mydb.bak" AZ INIT, FORMAT, STATS = 1, ELLENŐRZŐ ÖSSZEGÉVEL
Hasonlóképpen - differenciálmásolat
ADATBÁZIS BIZTONSÁGI MENTÉSE LEMEZRE = N"C:\Backup\mydb.diff": DIFFERENCIÁLIS, INIT, FORMAT, STATS = 1, ELLENŐRZŐ SZUM
Tranzakciós napló biztonsági mentése
BIZTONSÁGI NAPLÓ A LEMEZRE = N"C:\Backup\mydb.trn" INIT, FORMAT
Gyakran célszerű nem egy biztonsági másolatot készíteni egyszerre, hanem kettőt. Például az egyik helyben feküdhet a szerveren (úgy, hogy kéznél legyen), a második pedig azonnal fizikailag távolivá alakul, és védve van a káros tárhelyekkel szemben:
ADATBÁZIS BIZTONSÁGA LEMEZRE = N"C:\Backup\mydb.bak", MIRROR TO DISK = N"\\safe-server\backup\mydb.bak" INIT, FORMAT
Egy fontos szempont, amelyet gyakran figyelmen kívül hagynak, hogy az MSSQL Server folyamatot elindító felhasználónak hozzá kell férnie a "\\safe-server\backup\" erőforráshoz, különben a másolás meghiúsul. Ha az MSSQL Server fut a rendszer nevében, akkor hozzáférést kell adni a "szerver_neve$" tartományfelhasználónak, de még mindig jobb, ha az MS SQL-t megfelelően konfigurálja úgy, hogy egy speciálisan létrehozott felhasználó nevében fusson.
Ha nem adjuk meg a MIRROR TO -t, akkor nem 2 tükörmásolat lesz, hanem egy másolat, 2 fájlra osztva, a csíkozási elv szerint. És mindegyik külön-külön haszontalan lesz.
Az adatbázis-szerverek az egyik legfontosabb szerverek minden szervezetben. Ők tárolják az információkat, és kérésre adnak kimenetet, és rendkívül fontos az adatbázis mentése minden helyzetben. Az alap disztribúció általában tartalmazza a szükséges segédprogramokat, de egy adatbázissal korábban nem találkozott adminisztrátornak még egy ideig meg kell küzdenie a munka sajátosságaival az automatizálás érdekében.
Először is nézzük meg, hogy általában mik a biztonsági mentések. Az adatbázisszerver nem egy szokványos asztali alkalmazás, és az összes ACID-tulajdonság (Atomic, Consistency, Isolated, Durable) megvalósítása érdekében számos technológiát alkalmaznak, ezért az adatbázis létrehozásának és visszaállításának archívumból megvan a maga sajátossága. saját jellemzőit. Három különböző megközelítés létezik az adatok biztonsági mentésére, mindegyiknek megvannak a maga előnyei és hátrányai.
Logikai vagy SQL biztonsági mentéssel (pg_dump, mysqldump, SQLCMD) azonnali pillanatkép készül az adatbázis tartalmáról, figyelembe véve a tranzakciós integritást, és SQL parancsokkal fájlként mentve (kiválaszthatja a teljes adatbázist vagy az egyes táblázatok), amellyel újra létrehozhatja az adatbázist egy másik szerveren. Időbe telik (különösen nagy adatbázisok esetén) a mentés és a visszaállítás, ezért nagyon gyakran ez a művelet nem hajtható végre, és minimális terhelés mellett (például éjszaka) hajtják végre. A visszaállítás során az adminisztrátornak le kell futnia néhány parancsot, hogy mindent előkészítsen (üres adatbázis létrehozása, Fiókok Stb).
Fizikai biztonsági mentés (szint fájlrendszer) - másolja azokat a fájlokat, amelyeket a DBMS az adatok tárolására használ az adatbázisban. Az egyszerű másolás azonban figyelmen kívül hagyja a zárolásokat és a tranzakciókat, amelyeket valószínűleg helytelenül tárolnak és feltörnek. Ha megpróbálja csatolni ezt a fájlt, az inkonzisztens állapotban lesz, és hibákat fog okozni. A naprakész biztonsági mentéshez le kell állítani az adatbázist (az rsync kétszeri használatával csökkentheti az állásidőt - először futón, majd leállítotton). Ennek a módszernek a hátránya nyilvánvaló - bizonyos adatokat nem lehet visszaállítani, csak a teljes adatbázist. Amikor elindít egy fájlrendszer-archívumból visszaállított adatbázist, ellenőriznie kell az integritást. Itt különféle segítő technológiákat alkalmaznak. Például a PostgreSQL-ben a WAL (Write Ahead Logs) naplózza és speciális funkció(Point in Time Recovery – PITR), amely lehetővé teszi az adatbázis egy adott állapotába való visszatérést. Segítségükkel könnyen megvalósítható a harmadik forgatókönyv, amikor a fájlrendszer szintű biztonsági mentést WAL-fájlmentéssel kombinálják. Először visszaállítjuk a fájlrendszer biztonsági mentési fájljait, majd a WAL segítségével az adatbázist frissítjük. Ez egy kicsit bonyolultabb megközelítés az adminisztrációhoz, de nincs probléma az adatbázis integritásával és az adatbázisok meghatározott időre való visszaállításával.
A logikai biztonsági mentést olyan esetekben használjuk, amikor az adatbázisról egyszeri teljes másolatot kell készíteni, vagy a mindennapi használat során nem vesz igénybe sok időt vagy helyet a másolat elkészítése. Ha az adatbázisok kirakodása sokáig tart, ügyeljen a fizikai archiválásra.
Engedély: GNU GPL
Támogatott DBMS: PostgreSQL
A PostgreSQL támogatja a fizikai és logikai biztonsági mentési képességeket egy újabb WAL-réteg hozzáadásával (lásd az oldalsávot), amelyet folyamatos biztonsági mentésnek nevezhetünk. De több szerver kezelése standard eszközökkel még egy tapasztalt rendszergazda számára sem túl kényelmes, és hiba esetén a számlálás másodpercekre megy.
A Barman (biztonsági mentési és helyreállítási menedzser) a 2ndQuadrant, egy PostgreSQL-en alapuló szolgáltatásokat nyújtó vállalat belső fejlesztése. Fizikai PostgreSQL biztonsági mentésre (logikai nem támogatja), WAL archiválásra és gyors helyreállításütközések után. Támogatja a távoli biztonsági mentést és több szerver visszaállítását, a pont-időben történő helyreállítást (PITR), a WAL-kezelést. Az SSH-t a parancsok távoli gazdagépre másolására és kiadására használják, az rsync használatával végzett szinkronizálás és biztonsági mentés pedig lehetővé teszi a forgalom csökkentését. Barman is integrálódik szabványos közművek bzip2, gzip, tar és hasonlók. Elvileg bármilyen tömörítő és archiváló programot használhatsz, az integráció nem fog sok időt igénybe venni. Különféle szerviz- és diagnosztikai funkciókat valósított meg, amelyek lehetővé teszik a szolgáltatások állapotának figyelését és a sávszélesség beállítását. A Pre/Post szkriptek támogatottak.
A Barman Python nyelven íródott, és a biztonsági mentési házirendek kezelése a barátságos barman.conf INI fájl segítségével történik, amely az /etc könyvtárban vagy a felhasználó saját könyvtárában található. A szállítás egy kész sablont tartalmaz részletes megjegyzésekkel. Csak *nix rendszereken működik. Az RHEL, CentOS és Scientific Linux rendszerekre történő telepítéshez csatlakoznia kell az EPEL-hez - egy olyan tárolóhoz, amely további csomagokat tartalmaz. A Debian/Ubuntu felhasználók rendelkezésére áll a hivatalos adattár:
$ sudo apt-get install barman
Nem mindig az adattárban legújabb verzió, telepítéséhez hivatkoznia kell a forrásszövegekre. Kevés függőség létezik, és a folyamat könnyen kitalálható.
Engedély: BSD
Támogatott DBMS: MySQL
A MySQL mellett a mysqldump és a mysqlhotcopy segédprogramok is megtalálhatók, amelyek segítségével egyszerűen hozhat létre adatbázis-kiíratást, jól dokumentáltak, és rengeteg kész példát és frontendet találhatunk az interneten. Ez utóbbi lehetővé teszi a kezdő számára, hogy gyorsan munkába álljon. A Sypex Dumper egy PHP-szkript, amely lehetővé teszi az adatbázis másolatának egyszerű létrehozását és visszaállítását MySQL adatok. Nagy adatbázisokkal való együttműködésre tervezték, nagyon gyors, áttekinthető és könnyen használható. Tudja, hogyan kell dolgozni MySQL objektumokkal – nézetek, eljárások, függvények, triggerek és események.
Egy másik előny, ellentétben más eszközökkel, amelyek exportáláskor UTF-8-ra konvertálnak, az, hogy a Dumper natív kódolással exportál. Az eredményül kapott fájl kevesebb helyet foglal, és maga a folyamat gyorsabb. Egy dump különböző kódolású objektumokat tartalmazhat. Sőt, több lépcsőben is könnyen importálható/exportálható, leállítva a folyamatot a terhelés alatt. Újraindításkor az eljárás onnan indul, ahol abbahagyta. Négy lehetőség van a helyreállításra:
Támogatja a másolás tömörítését (gzip vagy bzip2), a régi biztonsági másolatok automatikus törlését, a dump fájl tartalmának megtekintését, csak a táblák szerkezetének visszaállítását. Az adatbázis kezelésére szolgáló szolgáltatási funkciók is rendelkezésre állnak (létrehozás, törlés, ellenőrzés, adatbázis visszaállítása, optimalizálás, táblák tisztítása, indexekkel való munka stb.), valamint egy fájlkezelő, amely lehetővé teszi a fájlok szerverre másolását.
A kezelés webböngészővel történik, az AJAX interfész a dobozból honosított, és olyan benyomást kelt, mintha egy asztali alkalmazással dolgozna. Lehetőség van feladatok futtatására a konzolról és ütemezetten (a cron segítségével).
A Dumper működéséhez szükség lesz egy klasszikus L|WAMP szerverre, a telepítés minden PHP-ben írt alkalmazásnál közös (fájlok másolása és engedélyek beállítása), és még egy kezdőnek sem lesz nehéz. A projekt részletes dokumentációt és oktatóvideókat tartalmaz, amelyek bemutatják, hogyan kell dolgozni a Sypex Dumperrel.
Két kiadás létezik: Sypex Dumper (ingyenes) és Pro (10 USD). A második több funkcióval rendelkezik, az összes különbség megtalálható az oldalon.
Engedély:
Támogatott DBMS: MS SQL Server
Az MS SQL Server az egyik legnépszerűbb megoldás, ezért meglehetősen gyakori. A biztonsági mentési feladat az SQL Server Management Studio, maga a Transact-SQL és az SQL PowerShell modul parancsmagjai (Backup-SqlDatabase) használatával jön létre. Az MS webhelyén hatalmas mennyiségű dokumentációt találhat, amely lehetővé teszi a folyamat megértését. A dokumentáció, bár teljes, nagyon konkrét, és az interneten található információk gyakran ellentmondanak egymásnak. Egy kezdőnek valóban először gyakorolnia kell, „meg kell töltenie a kezét”, ezért az elmondottak ellenére a külső fejlesztőknek van helyük megfordulni. kívül ingyenes verzió Az SQL Server Express nem büszkélkedhet beépített biztonsági mentési eszközökkel. Többért korai változatai Az MS SQL-ben (2008 előtt) találhatunk ingyenes segédprogramokat, mint például az SQL Server backup , de ezeknek a projekteknek a nagy része már kereskedelmi forgalomba került, bár gyakran szimbolikus összegért kínálják az összes funkcionalitást.
Például az SQL Backup And FTP és az One-Click SQL Restore fejlesztése a set-and-forget elvet követi. Nagyon egyszerű és intuitív kezelőfelületükkel másolatokat készíthet az MS SQL Server (beleértve az Expresszt is) és az Azure adatbázisokról, mentheti a titkosított és tömörített fájlokat FTP-re és felhő szolgáltatások(Dropbox, Box, Google Drive, MS SkyDrive vagy Amazon S3), az eredmény azonnal megtekinthető. Lehetőség van manuálisan és ütemezetten is elindítani a folyamatot, e-mailben üzenetet küldeni a feladat eredményéről, felhasználói szkripteket futtatni.
Minden biztonsági mentési lehetőség támogatott: teljes, differenciál, tranzakciós napló, mappa másolása fájlokkal és még sok más. A régi biztonsági másolatok automatikusan törlődnek. A virtuális gazdagéphez való csatlakozáshoz az SQL Management Studiot használják, bár ez árnyalt lehet, és nem működik minden ilyen konfigurációban. Öt verziót kínálnak letöltésre - innen Ingyenes a díszes Prof Lifetime-nak (az írás idején mindössze 149 dollár). Az ingyenes funkcionalitás elég kis hálózatok, amelyben egy vagy két SQL szerver van telepítve, minden alapvető funkció aktív. A biztonsági mentési adatbázisok száma, a fájlok Google Drive-ba és SkyDrive-ba küldésének lehetősége, valamint a fájltitkosítás korlátozott. A felület, bár nem lokalizált, nagyon egyszerű és érthető még egy kezdő számára is. Csak csatlakoznia kell az SQL szerverhez, amely után megjelenik az adatbázisok listája, jelölje be a szükségeseket, konfigurálja a távoli erőforrásokhoz való hozzáférést, és adja meg a feladat befejezésének idejét. És mindez egy ablakban.
De van egy "de". Maga a program nem az archívumok visszaállítására szolgál. Ehhez egy külön ingyenes One-Click SQL Restore segédprogramot kínálnak, amely a BACKUP DATABASE parancs által létrehozott formátumot is megérti. Az adminisztrátornak csak meg kell adnia az archívumot és a szervert, amelyre visszaállítja az adatokat, és meg kell nyomnia egy gombot. Bonyolultabb forgatókönyvek esetén azonban a RESTORE parancsot kell használnia.
A biztonsági másolat készítésének és a DBMS visszaállításának megvannak a maga különbségei, amelyeket figyelembe kell venni, különösen az archívum másik kiszolgálóra való átvitelekor. Például elemezzük az MS SQL Server néhány árnyalatát. A Transact-SQL használatával történő archiváláshoz használja a BACKUP DATABASE parancsot (van egy delta DIFFERENTIAL parancs is) és a BACKUP LOG tranzakciós naplót.
Ha a biztonsági másolatot egy másik kiszolgálóra telepítette, akkor meg kell győződnie arról, hogy ugyanazok a logikai meghajtók vannak jelen. Alternatív megoldásként manuálisan is beállíthatja az adatbázisfájlok helyes elérési útját a RESTORE DATABASE parancs WITH MOVE opciójával.
Egy egyszerű helyzet az adatbázisok biztonsági mentése és átvitele az SQL Server más verzióiba. Ez a művelet támogatott, de SQL Server esetén akkor működik, ha a kiszolgáló verziója, amelyen a másolatot telepítette, megegyezik vagy újabb, mint amelyen létrehozták. És van egy korlátozás: legfeljebb két verzióval újabb. A visszaállítás után az adatbázis kompatibilitási módba kerül azzal a verzióval, amelyről az átállás történt, vagyis új funkciók nem lesznek elérhetők. Ez könnyen javítható a COMPATIBILITY_LEVEL módosításával. Meg lehet ezt csinálni GUI segítség vagy SQL.
ALTER DATABASE MyDB SET KOMPATIBILITÁSI_SZINT = 110;
Az archív fájl fejlécének megtekintésével meghatározhatja, hogy a másolat melyik verzión készült. Annak érdekében, hogy ne kísérletezzen, amikor vált új verzió Az SQL Servernek az ingyenes Microsoft Upgrade Advisor segédprogramot kell futtatnia.
Engedély: kereskedelmi, van egy ingyenes verzió
Támogatott DBMS: Oracle 9-11, XE, MySQL, MariaDB, PostgreSQL és MS SQL Server
Ha többféle DBMS-t kell kezelnie, a kombinálások nélkülözhetetlenek. A választék nagy. Például az Iperius egy könnyű, nagyon könnyen használható, mégis hatékony fájlmentő program, amely képes megszakítás vagy blokkolás nélkül melegíteni az adatbázisokat. Teljes vagy növekményes biztonsági mentést biztosít. Teljes lemezképeket hozhat létre a teljes rendszer automatikus újratelepítéséhez. Támogatja a biztonsági mentést NAS-ra, USB-eszközökre, streamerre, FTP/FTPS-re, Google Drive-ra, Dropboxra és SkyDrive-ra. Támogatja a fájlméret-korlátozás nélküli zip-tömörítést és az AES256 titkosítást, külső szkriptek és programok futtatását. Tartalmaz egy nagyon funkcionális feladatütemezőt, több feladat párhuzamos vagy egymás utáni végrehajtására is van lehetőség, az eredményt e-mailben küldjük el. Számos szűrő, változó az útvonalak és beállítások személyre szabásához támogatott.
Az FTP-feltöltési képesség megkönnyíti az információk frissítését több webhelyen. Nyissa meg a Fájlokat VSS technológiával (Volume Shadow Copy) készülnek biztonsági mentésük, amely lehetővé teszi nemcsak a DBMS-fájlok, hanem más alkalmazások gyors mentését is. Az Oracle esetében az RMAN (Recovery Manager) biztonsági mentési és helyreállítási eszköz is használatos. A csatorna túlterhelésének elkerülése érdekében lehetőség van a sávszélesség beállítására. A biztonsági mentés és visszaállítás kezelése a helyi és webes konzolon keresztül történik. Minden funkció jól látható, így egy feladat beállításához csak a folyamat megértése szükséges, még a dokumentációba sem kell belenézni. Csak kövesse a varázsló utasításait. Megjegyezheti a fiókkezelőt is, ami nagyon kényelmes számos rendszerrel.
Az alapfunkciók ingyenesek, de az adatbázis redundancia lehetősége csak az Advanced DB és a Full verziókban szerepel. Támogatja a telepítést XP-ről Windows Server 2012.
Engedély: egy reklám
Támogatott DBMS: Oracle, MySQL, IBM DB2 (7–9.5) és MS SQL Server
Az egyik legerősebb relációs adatbázis-kezelő rendszer az IBM DB2, amely egyedi méretezhetőségi jellemzőkkel rendelkezik, és számos platformot támogat. Több kiadásban szállítják, amelyek ugyanarra az alapra épülnek, és funkcionálisan különböznek egymástól. A DB2 adatbázis-architektúra szinte minden adattípus kezelését teszi lehetővé: dokumentumok, XML, médiafájlok stb. Az ingyenes DB2 Express-C különösen népszerű. A biztonsági mentés nagyon egyszerű:
db2 biztonsági másolat db minta
Vagy egy pillanatfelvétel az Advanced Copy Services (ACS) funkcióval:
db2 backup db mintahasználati pillanatkép
De emlékeznünk kell arra, hogy pillanatképek esetén nem tudjuk visszaállítani (db2 recovery db) az egyes táblákat. Lehetőségek vannak automatikus biztonsági mentésre és még sok másra. A termékek jól dokumentáltak, bár a kézikönyvek ritkák az orosz nyelvű interneten. Ezenkívül nem minden speciális megoldás talál támogatást a DB2-hez.
Például, Handy Backup lehetővé teszi többféle adatbázis-kiszolgáló biztonsági mentését és fájlok mentését szinte bármilyen adathordozóra ( HDD, CD/DVD, felhő és hálózati tárolás, FTP/S, WebDAV és mások). Lehetőség van az adatbázisok biztonsági mentésére ODBC-n keresztül (csak táblák). Ez azon kevés megoldások egyike, amely támogatja a DB2-t, és a „Ready for IBM DB2 Data Server Software” logót is viseli. Az egész eljárást egy hagyományos varázsló segítségével hajtják végre, amelyben csak ki kell választania a kívánt elemet, és létre kell hoznia egy feladatot. Maga a beállítási folyamat olyan egyszerű, hogy még egy kezdő is rájön. Több feladatot is létrehozhat, amelyek ütemezetten futnak. Az eredményt naplózza és e-mailben elküldi. A feladat futása közben nem szükséges leállítani a szolgáltatást. Az archívum automatikusan tömörítésre és titkosításra kerül, ami garantálja a biztonságát.
A DB2-vel való munkát a Handy Backup két verziója támogatja – Office Expert (helyi) és Server Network (hálózat). Win8/7/Vista/XP vagy 2012/2008/2003 operációs rendszert futtató számítógépeken működik. Maga a telepítési folyamat egyetlen rendszergazdának sem nehéz.
Továbbra is a biztonsági mentésről beszélünk, és ma megtanuljuk hozzon létre egy archívumot Microsoft bázisok SQL Server 2008. A grafikus felület és az SQL lekérdezés használatával példákkal mindent a megszokott módon fogunk figyelembe venni, és beállítjuk az automatikus biztonsági másolat készítése kötegfájl segítségével.
Az adatbázis-mentés fontosságára nem térünk vissza, hiszen ezt a témát már többször felvetettük, például az anyagokban:
Az utolsó cikkben pedig azt mondtam, hogy megfontoljuk az archívum létrehozásának lehetőségét az MS SQL Server 2008 DBMS-en, ezért most ezt fogjuk tenni.
És mivel már rengeteg elmélet volt, azonnal térjünk át a gyakorlatra, mégpedig a tartalékbázis létrehozására.
Jegyzet! Amint a cikk címéből kiderül, az archívumot a Microsoft SQL 2008 DBMS-en készítjük el a Management Studio segítségével. A szerver helyben található. OS Windows 7.
Döntsük el, hogy egy "teszt" nevű tesztadatbázisból archívumot készítünk. A kezdetektől egészen GUI, és ennek során írunk egy scriptet, hogy a jövőben egyszerűen lefuttathassuk, és többé ne vonjuk el a figyelmünket mindenféle paraméter megadása.
Nyissa meg a Management Studio-t, bontsa ki « Adatbázis» , válassza ki a kívánt alapot, kattintson Jobb klikk vigye rá az egeret, válassza ki Feladatok-> Biztonsági mentés
Meglátod az ablakot" Adatbázis biztonsági mentése”, ahol beállíthatja az archiválási paramétereket. csak nevet adtam Biztonsági készlet", és megváltoztatta az archívum nevét és az elérési utat is, mivel alapértelmezés szerint a Program Files mappában jön létre, nekem például az alapértelmezett elérési út volt
C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\
Például megváltoztattam C:\temp\-re, és elneveztem az archívumot test_arh.bak
Akkor is, ha a lapra lép « Lehetőségek», akkor beállíthatod, hogy az összes adathalmazt felülírja a beállítás, most elmagyarázom, hogy mi ez. Ha mindent úgy hagysz, ahogy van, pl. hozzáad egy meglévő adatkészlethez, akkor egy biztonsági mentési fájlja lesz, de az adatkészletek több példányával, pl. visszaállításkor egyszerűen kiválasztja a szükséges készletet. És ha felteszed" Az összes meglévő biztonsági mentési készlet felülírása”, akkor a készlet mindig ugyanaz lesz, akkor ebben az esetben archívumokat (mondjuk napi) kell létrehozni különböző néven. Felülírásra állítottam be, mert mondjuk a jövőben minden napra tervezek archívumot létrehozni a dátummal ezen archívumok nevében, hogy szükség esetén gyorsan átmásolhassam az adott dátumhoz szükséges mentést bárhová .
És egyébként ezen a ponton, az összes paraméter megadása után, létrehozhat egy szkriptet, hogy rögzítse és később felhasználja. Ehhez egyszerűen kattintson a tetejére Forgatókönyv».
És ennek a műveletnek az eredményeként megnyílik egy lekérdező ablak, amelyben lesz egy kód ehhez a szkripthez. Kicsit később visszatérünk rá, de egyelőre kattintson az "OK" gombra, és a művelet befejezése után megjelenik egy ablak, amelyben megjelenik a biztonsági mentés eredménye, ha minden rendben van, akkor a következő üzenet megjelenik
Ha mindent megtett a fentiek szerint azok. rákattintott a "Script" gombra), akkor megnyitott egy lekérdező ablakot, ami tulajdonképpen magát az archívum létrehozási kérelmet tartalmazza, de egy kicsit megismételjük, mivel azt mondtam, hogy minden nap tervezzük futtatni, hogy a név megfelelő legyen, akkor ezt írjuk. SQL utasítás.
DECLARE @path AS VARCHAR(200) SET @path = N"C:\temp\test_arh_" + CONVERT(varchar(10), getdate(), 104) + ".bak" BIZTONSÁGI ADATBÁZIS LEMEZRE = @elérési út NOFORMÁTUmmal, INIT, NÉV = N"Adatbázis teszt", SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO
És most, ha futtatjuk, akkor létrehozunk egy adatbázis-mentést teszt_arh_ néven Az aktuális dátum.bak
Erre a célra az MS SQL 2008 rendelkezik különleges lehetőség címmel " Szolgáltatási tervek”, ahol egyszerűen beállíthat egy ütemezést az adatbázis biztonsági mentésének létrehozásához, de javaslom, hogy használjon bat fájlt erre a célra, hogy beállítsa az ütemezőben, és minden nap futtasson, és készítsen biztonsági másolatot az adatbázisról.
Ehhez másolja SQL utasítás, amelyet fent áttekintettünk, és illessze be a jegyzettömbbe ( Ajánlom a Notepad++-t), majd mentse kiterjesztéssel .sql azok. ez a szkript az MS Sql 2008-on fog futni. Ezután egy kötegfájlt kell írnunk, hogy az csatlakozzon az SQL szerverhez és végrehajtsa a szkriptünket. Jegyzettömbbe is írd be:
SET cur_date=%dátum:~6.4%%dátum:~3.2%%dátum:~0.2% osql -S localhost -i C:\temp\test.sql -o C:\temp\%cur_date %_log_sql.log -E
ahol létrehoztam egy cur_date változót az aktuális dátum tárolására, majd csatlakozom helyi szerver, a segédprogramon keresztül osql, amely ODBC-t használ és végrehajtja a szkriptünket ( Test.sql-nek hívtam), és írj egy naplót is, ahol és éppen szükségünk volt a változónkra, ennyi, mentsd el a kiterjesztéssel .denevér, létrehozunk egy feladatot az ütemezőben, és elmondhatjuk, hogy elfelejtjük az adatbázis archiválásának folyamatát, nos, csak időszakonként ellenőrizzük, hogy az archívum létrejött-e vagy sem.
Az alapokhoz ez is bőven elég, most már tudja, hogyan készíthet biztonsági másolatot az adatbázisokról egy 2008-as SQL szerveren, a következő cikkben megnézzük, hogyan lehet adatbázist visszaállítani MS SQL Server 2008-on. Addig is ennyi ! Sok szerencsét!
És még: SQL biztonsági mentés, 1C biztonsági mentés.
Az 1C szerver adatokat tartalmaz az adatbázisban, amely az SQL szerveren található. Ma az MS SQL 2005/2008-at vizsgáljuk.
Annak érdekében, hogy az adatok ne vesszenek el a szerverlemez leégése vagy más vis maior helyzetek esetén, a kezdetektől biztonsági mentést kell készíteni.
Természetesen senki sem akar minden nap tollat készíteni. SQL adatbázis biztonsági mentése 1C. Erre vannak automatikus eszközök. Ismerkedjünk meg velük.
A BackupSQL konfigurálása
A Backup SQL beállítása egy 1C adatbázishoz nem különbözik bármely más adatbázis biztonsági mentésének beállításától.
A beállításhoz futtassa az MS SQL Management Studio programot. Ez a program az MS SQL programcsoportban található.
1C SQL adatbázis biztonsági mentési feladat hozzáadása
Az SQL-adatbázisok automatikus biztonsági mentésének feladatai a Kezelési/karbantartási tervek ágban találhatók.
Új biztonsági mentési feladat hozzáadásához kattintson a jobb gombbal a Karbantartási tervek csoportra, és válassza az Új karbantartási terv lehetőséget.
Írja be a feladat nevét. A név csak neked számít. Minden esetre jobb angol karaktereket használni.
1C SQL adatbázis biztonsági mentési feladat beállítása
Megnyílik az Állásszerkesztő. Kérjük, vegye figyelembe, hogy a jobok különféle műveleteket végezhetnek az adatbázissal, nem csak biztonsági mentéseket.
A műveletek opcióinak listája a bal alsó sarokban jelenik meg. Válassza az Adatbázis-feladat biztonsági mentése lehetőséget dupla kattintással, vagy egyszerűen húzza jobbra.
Figyelje meg a nyilat. Több különböző vagy azonos műveletet is áthúzhat és nyilakkal összekapcsolhat. Ezután egyszerre több feladat is végrehajtódik az Ön által megadott sorrendben.
A beállítások ablakban válassza ki a szükséges SQL 1C adatbázisokat (egyszerre több vagy egy is lehet).
Válassza ki az SQL 1C adatbázis biztonsági másolatának mentési helyét. Fizikailag eltérő merevlemezt kell választania. Szervezetileg bejelölheti az "Almappák létrehozása" négyzetet.
Most állítsuk be a biztonsági mentés ütemezését. Az alapértelmezett biztonsági mentés ütemezése magától lett hozzáadva. De több ütemezést is hozzáadhat (például egy napi, egy heti stb.). Kattintson a biztonsági mentés ütemezésének beállításai gombra.
A képernyőkép egy napi 1C biztonsági mentési SQL-adatbázisra mutat példát hajnali 3-kor.
Annak érdekében, hogy a listában szereplő biztonsági mentés ütemezése szép és érthető legyen, módosíthatja.
1C SQL adatbázis biztonsági mentési feladat mentése
Kattintson az Égés gombra. A feladat megjelenik a lista bal oldalán.
Fontos! Ellenőrizze, hogy az SQL-adatbázis biztonsági mentése feladat megfelelően lett létrehozva. Ehhez kattintson a jobb gombbal a feladatra, és válassza a Végrehajtás lehetőséget.
Ennek eredményeként egy biztonsági mentési fájlnak kell megjelennie a megadott elérési úton. Ha valami nem stimmel, törölje a feladatot (Del), és kezdje elölről.
Nézzünk egy nemkívánatos helyzetet. Mégpedig: valamiért meghibásodott az adatbázis. mi van nálunk? Teljes másolat, differenciálmásolat tegnapra, de van mára adat is, tényleg óránként kellett differenciálmásolást csinálni? - Nem! Eszik Tranzakciós napló.
A tranzakciós napló egy napló, amely rögzíti az összes tranzakciót és az egyes tranzakciók által végrehajtott adatbázis-módosításokat. Azok. Az adatbázissal végzett minden művelet lépésről lépésre rögzítésre kerül a naplóban. A DBMS minden rekordot megjelöl a tranzakció befejezésére vonatkozóan, akár befejeződött, akár nem. Segítségével nem csak hiba után, hanem előre nem látható adatokkal kapcsolatos műveletek esetén is visszaállíthatja az adatbázis állapotát. Visszaállítás egy bizonyos ideig. Az adatbázishoz hasonlóan a tranzakciós naplóról is biztonsági másolatot kell készíteni, teljes, differenciális, növekményes. A tranzakciós napló egy részének visszaállításához a biztonsági mentések közötti hiba után biztonsági másolatot kell készítenie a napló utolsó részéről, amely valójában a biztonsági mentés véglegesítési pontja. Baleset után végrehajtva, visszaszámlálási pontként.
Tehát az adatbázis meghibásodás utáni visszaállításához szükségünk van az adatbázis naprakész teljes másolatára, az adatbázis egy eltérő másolatára és a tranzakciós napló másolatára.
Magához az adatbázishoz 3 helyreállítási modell létezik – egyszerű, teljes és tömegesen naplózott. Fontolgat:
Nézzük a legfontosabb biztonsági mentési láncot: Teljes biztonsági mentés - hetente egyszer, Differenciált biztonsági mentés - naponta egyszer, Tranzakciós napló mentése - óránként egyszer.
A biztonsági mentések készítésére több lehetőség is van:
Tekintsük az első lehetőséget a leginkább használhatónak. Ehhez a Windows Server 2008 R2 Enterprise és az MS SQL Server 2008 Eng használatos.
Tegyük fel, hogy van egy TECH adatbázisunk:
Térjünk át a Munkahely-létrehozó eszközre:
Három jobb egérgomb, és hívja a Mester munkát:
Bejelöljük a "Minden feladat külön végrehajtása" jelölőnégyzetet, csak egy műveletet hajtunk végre
A mester turbán nélkül van, de a lényeg nem a turbán mérete)) Kiválasztjuk a vágy típusát, esetünkben - teljes fenntartás:
Jóba mester, mint kiderült, egy kicsit zsidó, ezért ismét megkérdezi:
"Megéri további lehetőségeket választani, ó, fiatal paddawan!":
itt kiválasztjuk az adatbázist, a mentési tárolási időszakot, a címet (szalag vagy lemez), a mentési útvonalat és ami a legfontosabb, a feladatütemezőt!
"Ne feledkezzen meg az adatbázisról, amikor kiválasztja a sajátját. Összpontosítsa erejét, és válassza ki az adatbázist":
"Túl gyorsan siet a feladat létrehozásával, kattintson az alábbi gombra Ütemezés - Meghatározás" néven.
Sobsno, feladatütemező, ahol kiválasztjuk a típust (ismétlés, egyszer stb.), napot, időt, kezdési típust:
Ennyi, létrejött. Joba mester hűvös és zöld. A karbantartási tervekben megnézzük az állapotot:
A paranoiásnak ne féljen bevallani a tükörbe, érdemes belenézni az SQL Server Agent lelkébe – Job Activity Monitor, a Job Master mindent részletesen megmutat:
Most, ha a megadott feltételek teljesülnek, létre kell hoznia teljes biztonsági mentés DB. Ugyanezen elv alapján létrejön egy differenciális biztonsági mentés és egy tranzakciós napló biztonsági mentése (ezek az alpontok a „Teljes biztonsági mentés” alatt találhatók a munkaválasztási listában).
Tetszés szerint csavarja a fülét MSSQL-lel, ne csavarja ki
A következő cikk a Transact-SQL-lel való létrehozást és néhány példát tárgyalja.
