SQL Server biztonsági mentési programok. Rendszeres biztonsági mentési MS SQL Server adatbázis konfigurálása. Állítsa vissza az adatbázis biztonsági mentését

Számos módja van az asztal másolására az MS SQL Server adatbázisban. Számos lehetőséget kínálok a táblázatok másolatának létrehozásához. Melyik választani - függ az asztal szerkezetétől, az indexek jelenlétét, kiváltja, stb, valamint a vágy, hogy tegyen valamit a kezükkel.

1. A táblázatszerkezet másolásának kézi módszere

A Micrisoft SQL Management Studio, válassza ki az adatbázist, válassza ki a táblázatban kattintson jobb gombbal, és válassza ki a „Script asztalra” -\u003e „Create a” -\u003e „Új lekérdezés szerkesztő ablak”. A lekérdezés ablak megnyitja az asztal létrehozásához. Meg kell adnia azt a bázis nevét, amelyben az asztal másolatát kell készítenie, és az új név, ha az alap nem változik. A meglévő táblázat szerkezetének létrehozásának módosítása az alábbi ábrán látható.

Ezzel a módszerrel létrejön a táblázat indexei, de a triggerek nem másolódnak. Ugyanúgy kell másolni.

Adatok másolása a már létrehozott táblázatba, akkor ilyen SQL lekérdezést kell használnia:

Beillesztés a ..tmp_tbl_deps kiválasztása * .tbl_deps

2. Másolás Sql asztal vizsgálat

Készítsen egy példányt a szerkezeti táblázat és az adatok egy bázison belül:

Válassza a * tmp_tbl_dep-t a tmp_tbl_dep-ből a tbl_deps-től

Másolja a táblázat szerkezetét és adatait egy adatbázisból a másikba:

Válasszon * a ..tmp_tbl_deps-tól .tbl_deps

Az ilyen megoldás mínusz nem másolt indexek.

Fontolja meg, hogyan szervezze meg a két leggyakrabban tapasztalt adminisztrációs feladatokat SQL Server:

• Automatikus adatbázis-mentés;
• A régi biztonsági másolatok eltávolítása.

Biztonsági adatbázisok tervezése

• Nyissa meg az SQL Management Studio programot, és csatlakozzon a kívánt adatbázishoz. Győződjön meg róla, hogy működik az SQL Server Agent;
• Bővítse a menedzsment-karbantartási csomópontot (ehhez a "sysadmin" szerepe) - kattintson a jobb egérgombbal, és válassza az "Új karbantartási terv" lehetőséget;
• Adja meg az új szolgáltatási terv nevét;
• Kattintson a jobb oldali naptár ikonra az egyetlen sorban. A megnyíló ablakban állítsa be a feladat végrehajtási idejét. Válasszon ki egy időt, amikor az adatbázis kevésbé betöltött;
• Az Eszköztár részből húzza a biztonsági másolat adatbázis feladatát a fő területre;
• Kattintson duplán a Backup adatbázis feladatra - A Feladatbeállítások ablak megnyílik. foglalkoztatási másolat - Állítsa be a kívánt beállításokat;
• Kattintson az OK gombra - most a biztonsági mentések a tervezett idő szerint kerülnek létrehozásra;

A régi biztonsági mentések eltávolítása

Mivel a biztonsági mentési fájlok gyakran jönnek létre, akkor hamarosan szabad helyet kap a merevlemezen. Ezért törölnie kell az elavult biztonsági mentési fájlokat. Továbbra is konfiguráljuk a szolgáltatási tervet:

• Az Eszköztár panelből húzza a karbantartási tisztítási feladat feladatának fő területét;
• Kattintson duplán a karbantartási tisztító feladatra a Tulajdonságok ablak megnyitásához. Benne meg kell határoznia a biztonsági mentések elrendezését, bővítését és meghatározni a törölni kívánt fájlok korát. A bevált gyakorlat az, hogy egy hónapig tárolja a biztonsági mentéseket;
• Kattintson az OK gombra, és mentse el a szolgáltatási tervet;
• Továbbá várhatja a következő szolgáltatási tervet, hogy végrehajtson egy szolgáltatási tervet, vagy futtassam manuálisan (jobb egérgombbal kattintson az objektum-felfedező szolgáltatási tervére).

A BD adminisztrátorok azoknak vannak osztva, akik biztonsági másolatot készítenek, és azok, akik biztonsági másolatot készítenek.

Bevezetés

Ez a cikk az IB 1C leggyakoribb biztonsági másolatát írja le az SQL Server 2008 R2 Eszközök használatával, magyarázta, hogy miért kell pontosan megcsinálni, és másképp nem, több mítosz eloszlatott. A cikknek sok hivatkozása van az MS SQL dokumentációjára, ez a cikk nagyobb valószínűséggel felülvizsgálja a biztonsági mentési mechanizmusokat, mint egy átfogó kézikönyv. De azok számára, akik először szembesülnek ezzel a feladattal, egyszerűek és egyszerűek lépésről lépésre utasításokamelyek az egyszerű helyzetekre vonatkoznak. A cikket nem az adminisztrációs guru, a guru, és így mindez tudják, de feltételezzük, hogy az olvasó képes telepíteni az MS SQL Server-ot, és ezt az ellenséges technikák csodáját hozza létre a mélységben, Fordulhat, képes az 1C-k adatait elvégezni.

Úgy vélem, hogy a TSQL Backup adatbázis parancs (és a bátyja biztonsági mentési naplója) lényegében az egyetlen eszköz az 1C adatbázisok biztonsági mentési módját az MS SQL Server DBMS-ként. Miért? Nézzük meg, mi a módjaink:

hogyan	oké	rossz	TELJES
Kirakodás a DT-hez.	Nagyon kompakt formátum.	Hosszú ideig monopol hozzáférést igényel, nem mentheti el a jelentéktelen adatok részét (például a korábbi verziókban), hosszú extraher.	Ez nem annyira a biztonsági másolat, mennyit az adatok átadása az egyik környezetről a másikra. Ideális a keskeny csatornákhoz.
MDF és LDF fájlok másolása	Nagyon világos módja a kezdő adminisztrátoroknak.	Ez megköveteli a blokkoló adatbázis-fájlok felszabadulását, és ez lehetséges, ha a bázis le van tiltva (a kontextus menü offline parancsát) leválasztják (leválasztás), vagy egyszerűen leállították a kiszolgálót. Nyilvánvaló, hogy a felhasználók ebben az időben nem fognak működni.	Ennek a módszernek van értelme, hogy alkalmazza, ha és csak akkor, ha a baleset már megtörtént, úgy, hogy ha megpróbálja visszaállítani, legalábbis visszatérhet az opcióhoz, ahonnan a helyreállítás megkezdődött.
Biztonsági mentés az operációs rendszerrel vagy a hypervisorral	Kényelmes módszer a fejlesztési és tesztelési környezetekhez.	Nem mindig barátságos az adatok integritásával. Erőforrás módszer.	Ez korlátozható a fejlődésre. A termék közepes gyakorlatában nincs értelme.
MS SQL Backup	Nem igényel leállást. Lehetővé teszi, hogy önkényes pillanatban helyreálljon egy holisztikus állapot, ha előzetesen zavarod. Kiváló automatizált. Gazdasági és egyéb erőforrások.	Nem nagyon kompakt formátum. Nem mindenki használhatja ezt az utat, hogy szükséges legyen.	A termék média - a fő eszköz.

A fő nehézséget ha mentéseket beágyazott MS SQL lehetőség adódhat, hogy az elemi félreértés az elvek a munka. Ezt a nagy lustaság részét képezi, részben az egyszerű és érthető magyarázat hiánya a "kész receptek" szintjén (HMM, mondjuk, nem találtam meg), és a helyzetet is súlyosbítja a foszforaimat A fórumok. Mi a teendő a lustasággal, nem tudom, de megpróbálom megmagyarázni a biztonsági mentés alapjait.

Mi és miért mentse el?

Régen egy távoli galaxisban volt ilyen mérnöki és számviteli gondolat, mint az 1c: Enterprise 7.7. Nyilvánvalóan annak köszönhető, hogy az 1C első verziói: a vállalkozások népszerű formátum használatához készültek dBF fájlokAz SQL verziója nem tárolta elegendő információt az adatbázisban az MS SQL MS SQL biztonsági mentés elolvasásához, és még az egyes szerkezeti változásoknál is megsértették a teljes helyreállítási modell működési feltételeit, így különböző trükkökre kellett mennem kényszerítse a biztonsági mentési rendszert a fő funkció végrehajtásához. De mivel a 8. verzió, az adatbázis-adminisztrátorok végre pihenhetnek. A biztonsági mentés személyzete lehetővé teszi, hogy készítsen egy teljes és holisztikus biztonsági rendszert. A biztonsági mentésben nem szerepel. Csak a regisztrációs napló és néhány tiulus típusú formák beállításai (régebbi verziókban), de ez az adatok elvesztése a rendszerfunkcionalitásban nem érinti, bár a regisztrációs napló biztosan biztonsági mentése helyesen és hasznos.

Miért kell mindannyiunknak biztonsági mentésre van szüksége? Hmm Első pillantásra furcsa kérdés. Nos, valószínűleg először, hogy képes legyen telepíteni a rendszer másolatát, és másodszor visszaállítja a rendszert, miközben sikertelen? Az első rovására egyetértek, de a második cél az első mentési mítosz.

A biztonsági mentés az utolsó határ, hogy biztosítsa a rendszer biztonságát. Ha az adatbázis-adminisztrátornak vissza kell állítania a termékrendszert a biztonsági másolatokból, akkor azt jelenti, hogy sok durva hiba történt a munka szervezésében nagy valószínűséggel. Lehetetlen utalnak, hogy hát, mint a fő módja annak, hogy biztosítsa az adatok integritását, nem, ez inkább közelebb áll a tűzoltó rendszer. Tűzoltó rendszer szükséges. Be kell konfigurálni, ellenőrizni és működni. De ha dolgozott, akkor önmagában komoly vészhelyzet, amelynek negatív következményei vannak.

Annak érdekében, hogy a biztonsági mentés csak "békés" célokra használják, a hatékonyság és egyéb eszközök biztosítása érdekében használja:

• A szerverek fizikai biztonságát biztosítja: tüzek, áradások, rossz tápegység, tisztítószerek, építők, meteoritok és vadállatok - mindannyian csak a sarkon várnak, hogy elpusztítsa a szerverét.
• Felelősségteljesen az információbiztonság fenyegetéseihez tartozik.
• A kvalifikáció módosítja a rendszert, és győződjön meg róla, hogy ezek a változások nem vezetnek a romláshoz. A változás terv mellett tanácsos egy terv ", hogy mit tegyünk, ha minden rosszul megy."
• Aktívan használja a technológiát, hogy növelje a rendszer elérhetőségét és megbízhatóságát a balesetek következményeinek versenyzése helyett. Az SQL MS SQL esetében a következő lehetőségeket kell fizetnie:
  • Az SQL klaszterek használata (bár őszintén, azt hiszem, ez az egyik legdrágább és haszontalan módja annak, hogy az adatbázis adminisztrátora azokat a rendszereknek, amelyek nem igényelnek 24x7-et)
  • Tükrözési adatbázis (szinkronban és aszinkron mód A hozzáférhetőség, a teljesítmény és a költség követelményeitől függően)
  • Tranzakciós naplók szállítása
  • Replikáció segítségével 1c (elosztott adatbázisok)

A rendszer rendelkezésre állásától és az e célokra kiosztott költségvetésből származó követelményektől függően lehetséges olyan megoldásokat választani, amelyek lehetővé teszik az 1-2-es értéket, hogy csökkentsék az állásidőt és a visszanyerést a hibák során. Nem kell félnie az akadálymentesítési technológiáktól: elég egyszerűek ahhoz, hogy néhány nap alatt tanulmányozzák őket az SQL alapvető ismereteivel.

De nem számít, mi a biztonsági mentés még mindig szükséges. Ez ugyanaz a tartalék ejtőernyő, amelyet használhat, ha az összes üdvösség más eszköze megtagadja. De, mint egy igazi tartalék ejtőernyő, erre:

• ez a rendszernek előre kell állnia és képzett,
• a rendszer által élvezetes szakembernek elméleti és gyakorlati készségeinek kell lennie annak használatáról (rendszeresen támogatott),
• a rendszernek a legmegbízhatóbb és egyszerű összetevőkből kell állnia (ez az utolsó reményünk).

Alapvető információk a tárolásról és az adatfeldolgozásról MS SQL

Az SQL adatai általában adatfájlokban vannak tárolva (a továbbiakban: PD - nem vágási hatás, ez a cikknek több nem nagyon gyakori rövidítése) MDF-vel vagy NDF kiterjesztésekkel rendelkezik. Ezen fájlok mellett még mindig vannak tranzakciós naplók (ZHT), amelyeket az LDF kiterjesztésű fájlokban tárolnak. Gyakran előfordul, hogy a kezdő adminisztrátorok felelőtlenek és enyhén kapcsolódnak a vasúthoz, mind a termelékenység szempontjából, mind a tárolás megbízhatóságával kapcsolatban. Ez egy nagyon durva hiba. Valójában inkább éppen ellenkezőleg, ha megbízhatóan működőképes biztonsági rendszer, és hosszú idő áll rendelkezésre a rendszer helyreállításához, az adatokat a gyors, de rendkívül megbízhatatlan RAID-0-on tárolhatja, de aztán a külön megbízható és produktív erőforrás (bár ha RAID-1). Miért van az, hogy? Tekintsük részletesebben. Azonnal kell foglalni, hogy a prezentáció kissé egyszerűsített, de elég a kezdeti megértéshez.

A PD-ben ezeket a 8 kilobájt oldalakat tárolják (amelyek 64 kilobájtban vannak kombinálva, de ez nem lényeges). MS SQL. nem garantáljaEz közvetlenül az adatcsere parancs végrehajtása után ezek a változások pd-be fognak esni. Nem, csak egy memóriaoldalt jelölnek "megtakarításra". Ha a kiszolgálónak elegendő erőforrása van, hamarosan ezek az adatok a lemezen lesznek. Ezenkívül a kiszolgáló "optimista" és ha ezek a változások a tranzakcióban fordulnak elő, akkor a tranzakció rögzítése előtt jól eshetnek a lemezre. Ez általában az FD aktív munkájával rendelkezik, különféle diszkrét adatokat és befejezetlen tranzakciókat tartalmaz, amelyekre nem ismert, hogy törlik-e vagy rögzítve. Van egy speciális parancs "ellenőrzőpont", amely azt jelzi, hogy a kiszolgáló, amelyre szüksége van, hogy "most", hogy visszaállítsa a lemezen lévő összes beérlen adatot, de a parancs hatóköre meglehetősen specifikus. Elég, hogy azt mondja, hogy az 1c nem használja (nem találkoztam), és megértettem, hogy működés közben a PD általában nem holisztikus állapotban van.

Ahhoz, hogy megbirkózzon ezzel a káoszkal, csak szükségünk van. A következő események írnak rá:

• A tranzakció kezdetét és az azonosítóját.
• Információ a tranzakció rögzítésének vagy törlésének tényéről.
• Információ a PD összes adatváltozásáról (nagyjából beszélve, amely és mi történt).
• Információk az FD-k vagy az adatbázis-struktúra megváltoztatásáról (növelve a fájlok, a fájlok csökkentése, az oldalak kiemelése és a táblázatok létrehozása és törlése)

Mindezek az információ a tranzakció azonosítójának jelzésével van feltüntetve, amelyben bekövetkezett, és elegendő mennyiségben meg kell érteni, hogy az állam e művelethez forduljon, menjen az államhoz a művelet után, és fordítva (a kizárás egy hiányos protokoll-helyreállítási modell) .

Fontos, hogy ezt az információt azonnal írják a lemezre. Eddig az információ nem kerül rögzítésre a vasúton, a csapat nem tekinthető végrehajtásra. Normál helyzetben, ha elegendő mennyiségű mérete elegendő, és ha nem túlságosan széttagolt, a rekordokat folyamatosan kis rekordokkal (nem feltétlenül 8 kb) írják. A tranzakciós naplóban az adatok csak a helyreállításhoz szükségesek. Különösen nem Információk, amelyekről a lekérdezési szöveg módosításhoz vezetett, amely a kérelem végrehajtási tervét, amely a felhasználó által elindított és más felesleges információ az információk helyreállításához. A tranzakciós napló adatszerkezetének ötlete lehet

Válassza a * from :: fn_dblog (NULL, NULL)

Abban az a ténynek köszönhetően, hogy a merevlemezek sokkal hatékonyabban dolgoznak egy következetes rekorddal, mint az olvasáshoz és íráshoz szükséges parancsok kaotikus áramlása miatt, és annak köszönhetően, hogy az SQL parancsok várják a BEVEZETÉS VÉGE A WTT-ben, a következő ajánlás következik be :

Ha legalább a legkisebb lehetőség van, akkor a termék közegben az egyéni (a többi) fizikai médián kell elhelyezkednie, előnyösen minimális hozzáférési idővel egy szekvenciális felvételhez és maximális megbízhatósággal. Az egyszerű rendszerekhez a RAID-1 meglehetősen alkalmas.

Ha a tranzakció törlődik, az összes már beírt módosítás a kiszolgáló visszatér az előző állapotba. Ezért

A tranzakció törlése az MS SQL Server rendszerben általában a tranzakció teljes időtartamához hasonlítható. Próbálja meg, hogy ne törölje a tranzakciót, vagy a lehető leghamarabb döntést hozzon a lemondásról.

Ha a kiszolgáló valamilyen oknál fogva váratlanul leállítja a munkát, akkor az ismételt megkezdésekor elemezhető, hogy az FD-ben szereplő adatok nem felelnek meg a teljes államnak (nem megfelelő, de rögzített tranzakcióknak és rögzített, de törölt tranzakcióknak), és ez az adat lesz korrigált. Ezért, ha például egy nagy asztal indexei újjáépítését indította el, és újraindította a kiszolgálót, akkor az újraindításkor jelentős időt vesz igénybe, hogy visszaszorítsa ezt a tranzakciót, és nincs lehetőség a folyamat megszakítására.

Mi történik, amikor elérte a fájl végét? Minden egyszerű - ha elején felszabadult hely van, akkor a fájl elején egy szabad helyen elkezdi elkezdeni az elején. Mint egy pelyhes mágneses szalag. Ha nincs helye az elején, akkor a kiszolgáló általában megpróbálja bővíteni a tranzakció naplófájlját, míg a kiválasztott új darab egy új virtuális tranzakciós naplófájl, amely sokat lehet a fizikai tranzakciós fájlban, de ez nem elég A mentéshez. Ha a kiszolgáló nem bővíti a fájlt (a hely a lemezen van, vagy tilos a beállítások, hogy kibővítse, akkor az aktuális tranzakció megszünteti a 9002-es hibát.

Hoppá. És mit kell tenni a helyszínen Zht, mindig volt? Itt jöttünk a biztonsági rendszerhez és a helyreállítási modellekhez. A tranzakciók visszavonása és a kiszolgáló helyes állapotának visszaállítása, hirtelen leállítás esetén ZHT rekordban kell tárolni, a legkorábbi nyílt tranzakciók kezdetétől kezdve. Ezt a minimumot a ZHT-ben írják és tárolják előtt. Függetlenül attól, hogy az időjárás, a kiszolgáló beállításai és az admin vágya. A szerver nem engedélyezheti ezt az információt. Ezért, ha egy ügyletet nyit meg egy munkamenetben, és másokban különböző műveletek végrehajtására, a tranzakciós napló váratlanul véget érhet. A legkorábbi tranzakció a DBCC OpenRAN parancs által kiderülhet. De ez csak a szükséges minimális információ. Továbbá függ helyreállítási modellek. Az SQL szerveren három közülük:

• Egyszerű (egyszerű) - Csak az öv sín többi részére tárolják.
• Teljes (teljes) - az utolsó biztonsági mentés pillanatában tárolódik tranzakciós magazin. Megjegyzés, nem a teljes mentés óta!
• Tömegnaplózva (hiányos naplózással) - A rész (nagyon kicsi, általában a rész) műveletek nagyon kompakt formában vannak írva (valójában csak a rekord az, hogy az adatfájl oldal megváltozik). Ellenkező esetben a teljes megegyezik.

Több mítosz társul a helyreállítási modellekhez.

• Egyszerű lehetővé teszi a lemez alrendszerének terhelését. Ez nem igaz. Pontosan annyit írt, mint a naplózott ömlesztett, csak szabadon minél régebben tekinthető.
• Az ömlesztett naplózott lehetővé teszi a lemez alrendszerének terhelését. Az 1C-re szinte rossz. Lényegében az egyik olyan kevés művelet, amely minimális naplózásnak van kitéve további táncok nélkül - Adatok betöltése a DT formátumban és a szerkezetátalakítási táblázatokban.
• Ha az ömlesztett naplózott modellt használja, egyes műveletek nem esnek a tranzakciós napló biztonsági mentése, és nem engedi, hogy visszaállítsa az államot ebben az időben biztonsági mentés . Ez nem egészen így van. Ha a művelet a minimálisan logóra utal, akkor a mentés tartalmazza az aktuális adatokat az adatokkal, és lehet, hogy "elveszíti" a tranzakciós tranzakciók naplóját a végére (bár lehetetlen az önkényes időpontban, ha minimálisan vannak logó műveletek).

Az 1C alapú ömlesztett naplózott modell szinte értelmetlen, ezért nem tekintjük tovább. De a teljes és egyszerű választás részletesebben figyelembe veszi a következő részben.

• Képzési napló tranzakció
• • Helyreállítási modellek és a tranzakciós magazin kezelése
  • Tranzakciós naplómenedzsment
• Használja a tranzakciós naplók biztonsági másolatát

Alapelv A hálózat működése egyszerű és teljes helyreállítási modellekben

A formáció típusával a biztonsági másolatok három faj:

• TELJES (Teljes)
• Differenciális (Differenciál, különbség)
• Napló. (A tranzakciós naplók biztonsági mentése, a megadott, milyen gyakran használják ezt a kifejezést, az RCCT-re csökkentünk)

Szükséges, hogy ne zavarja itt: A teljes helyreállítási modell és a teljes mentés lényegében más dolog. Annak érdekében, hogy ne zavarja őket, az alábbiakban angolul fogok használni a helyreállítási modell és az orosz nyelvű biztonsági másolatokat.

A teljes és a differenciális másolási munka ugyanolyan egyszerű és teljes. A tranzakciós naplók biztonsági másolata teljesen hiányzik az egyszerűen.

Teljes mentés

Lehetővé teszi, hogy visszaállítsa az adatbázis állapotát egy ideig (az a, amelyben a biztonsági mentés kialakulása indult). Ez az adatfájlok egy részét és az aktív tranzakciós naplót tartalmazó oldal másolatából áll a biztonsági mentés során.

Különböző biztonsági mentés

Tárolja azokat az adatlapokat, amelyek az utolsó teljes mentés óta megváltozott. A helyreállításkor először vissza kell állítania a teljes biztonsági mentést (Norecovery módban, a példák az alábbiakban láthatóak), majd a következő különbség másolatát alkalmazhatják az ebből eredő "Billet" -re, de természetesen csak azok, amelyek a következő teljes mentés előtt. Ennek következtében jelentősen csökkentheti a lemezterület mennyiségét a mentés tárolásához.

Fontos pillanatok:

• Az előző teljes mentés nélkül a különbség másolatát haszontalan. Ezért kívánatos, hogy valahol egymás mellé tárolják őket.
• Minden további különbség másolat tárolja az előző különbségekben szereplő összes oldalt, amelyet az előző teljes (bár talán más tartalommal) tárolnak. Ezért minden következő különbség másolat több, mint korábbi, míg nem egy teljesen másolat (ha megszakad, csak a tömörítési algoritmusok miatt)
• A helyreállításhoz valamilyen pontban legújabb Teljes biztonsági mentés ebben a pillanatban és legújabb Ebben a pillanatban a különbség másolat. A helyreállítási közbenső példányok nem szükségesek (bár szükségesek a helyreállítási nyomaték kiválasztásához)

Rkjt

Egy bizonyos időszakra tartalmaz egy példányt. Általában az utolsó RCCT pillanatától kezdve az aktuális RCCT kialakulása. Az RCCT lehetővé teszi a másolatok helyreállítását a Norecovery módban a helyreállítási időszak alatt bármikor, visszaállítja az állapotot bármely későbbi pontra a biztonsági mentés behajtható másolatának időtartamának beírásában. A standard paraméterekkel való biztonsági mentés kialakításakor a tranzakciós naplófájlban található hely (az utolsó nyitott tranzakcióig).

Nyilvánvaló, hogy az RCHT nem értelme az egyszerű modellben (akkor az FP csak az utolsó nyitott tranzakció óta tartalmazza).

Az RCCT használatakor fontos koncepció történik - folyamatos ragi lánc.. Ez a lánc megszakíthatja a lánc egyes biztonsági másolatának elvesztését, vagy az adatbázist egyszerű és hátra továbbítja.

FIGYELMEZTETÉS: Az RCCT egy sora lényegében haszontalan, ha nem folyamatos lánc, és az utolsó sikeres teljes vagy különbség elejének kezdete kell lennie belüla lánc időtartama.

Gyakori tévhitek és mítoszok:

• "Az RCCT tranzakciós naplóadatokat tartalmaz az előző teljes vagy különbség biztonsági mentés pillanatából." Nem, ez nem. Az RCCT első pillantásra, haszontalan adatok az előző RCCT és az azt követő teljes mentés között.
• "A teljes vagy a különbség a biztonsági mentésnek a tranzakciós napló belsejében kell lennie."Nem, ez nem. A teljes és a különbség biztonsági mentés Ne érintse meg az RCCT láncot.
• A ZHT-t kézzel kell elvégezni, csökkenteni, csökkenteni, zsugorítani.Nem, nem szükséges, és még ellenkezőleg is, nem kívánatos. Ha felszabadítjuk az RKJT-t, akkor az RCCT lánc károsodott, ami a helyreállításhoz szükséges. És a fájl állandó csökkentése / bővítése a fizikai és logikai fragmentációhoz vezet.

Hogyan működik egyszerű

Legyen 1000 GB adatbázis. Minden nap az alap 2 GB-ot és 10 GB-os régi adatváltozást eredményez. A következő biztonsági mentéseket tette

• FULL COPY F1 0:00 február 1-jén (1000 GB térfogat, ne vegye figyelembe az egyszerűség tömörítését)
  • Különbség másolat d1.1 0:00 február 2-tól (12 GB)
  • Különbség D1.2 Copy D1.2 0:00 február 3-án (19 GB térfogat)
  • A D1.3 különbség D1.3-tól 0: 00-tól február 4-ig (25 GB térfogat)
  • Különbség D1.4 másolat 0: 00-tól február 5-ig (térfogat 31 GB)
  • Különbség D1.5 másolat 0: 00-tól február 6-ig (térfogat 36 GB)
  • D1.6 különbség D1.6-tól február 7-ig 0:00 (40 GB térfogat)
• FULL COPY F2 0:00 február 8-án (kötet 1014 GB)
  • A D2.1 különbség a február 9-én 0:00 -ig (12 GB térfogat)
  • A D2.2 különbség másolata 0:00 február 10-ig (19 GB térfogat)
  • A D2.3 különbség 0: 00-tól február 11-ig (25 GB térfogat)
  • A D2.4 különbség 0: 00-tól február 12-ig (térfogat 31 GB)
  • Digal Copy D2.5 0:00 február 13-án (térfogat 36 GB)
  • A D2.6 különbség 0: 00-tól február 14-ig (40 GB térfogat)

Ezzel a készletkel visszaállíthatjuk az adatokat a február 1-től 14-ig minden nap 0:00 óráig. Ehhez az F1 teljes példányát február 1-7-én vagy az F2 teljes példányát február 8-14-re kell vinni, a Norecovery módban állítsa vissza, majd alkalmazza a megfelelő nap különbség másolatát.

Hogyan működik teljes egészében

Ugyanazok a biztonsági mentés teljes és különbségcsomagolása van, mint az előző példában. Ezenkívül a következő RCCT:

• RKJT 1 A február 2-án január 31-től 12: 00-ig 12:00 óráig (kb. 30 GB)
• RKJT 2 Az időszakra 12:00 február 2-12: 00 február 4-én (kb. 30 GB)
• RKJT 3 Az időszakra 12:00 február 4-12: 00 február 6-ig (kb. 30 GB)
• RKJT 4 Az időszakra 12:00 február 6-12: 00 február 7-én (kb. 30 GB)
• RKJT 5 Az időszak 12:00 február 8-12: 00 február 10-ig (kb. 30 GB)
• RKJT 6 Az időszakra 12:00 február 10-12: 00 február 12-ig (kb. 30 GB)
• RKJT 7 Az időszakra 12:00 február 12-12: 00 február 14-ig (kb. 30 GB)
• RKJT 8 Az időszakra 12:00 február 14-12: 00 február 16-ig (kb. 30 GB)

Jegyzet:

1. Az RCCT mérete megközelítőleg állandó lesz.
2. Tartalék másolatokat, amelyeket kevésbé lehetünk, mint a különbség, vagy teljes, és gyakran képesek és gyakrabban, akkor kevesebb méretűek lesznek.
3. Most már 0:00 február 1-jén 0:00 -ig visszaállíthatjuk, amikor február 16-án a legkorábbi teljes másolatunk van.

A legegyszerűbb esetben vissza kell állítanunk:

1. Utolsó teljes másolat a helyreállításig
2. Az utolsó különbség másolása a helyreállítás előtt
3. Minden RCCT, az utolsó különbség másolásától a helyreállítás előtt

• Teljes másolat F2 0:00 február 8-tól
• A D2.2 különbség másolata 0: 00-tól február 10-ig
• RKJT 6 Az időszakra 12:00 január 10-től 12:00 február 12-ig

Először az F2 visszaáll, majd a D2.2, majd az RKT 6 a 13:13:13 február 10-ig. De a teljes modell lényeges előnye, hogy van választásunk - használja a legújabb teljes vagy különbség másolatot, vagy sem az utolsó. Például, ha azt találtuk, hogy egy példányt D2.2 volt kényeztetve, és meg kell, hogy visszaszerezze idején, amíg 13:13:13 február 10, akkor az egyszerű modell azt jelentené, hogy meg tudjuk visszaállítani az adatokat csak A D2.1 idő. Teljesen - "Don" T pánik ", a következő jellemzők vannak:

1. Az F2 visszaállítása, majd később D2.1, majd az RKJT 5, majd az RCS 6 a 13:13:13 február 10-ig.
2. Az F2 visszaállítása, majd az RCCT 4, majd az RKJT 5, majd a későbbi RKLC 6 pillanatig 13:13:13 február 10.
3. Vagy akár visszaállítja az F1-et, és hajtsa végre az összes RCCT-t az RCCT 6-ig 13:13:13 február 10-ig.

Amint láthatja, a teljes modell nagyobb választást kínál.

És most képzeljük el, hogy nagyon ravasz vagyunk. És néhány nappal a kudarc előtt (13:13:13 február 10.) Tudjuk, hogy a hiba lesz. Visszaállítottuk az adatbázist a teljes biztonsági mentésről a következő kiszolgálón, így lehetőséget kapunk arra, hogy a következő állapotokat különbség másolatokkal vagy RCCT-rel, azaz a Norecovery módban hagyjuk. És minden alkalommal, amikor az RCCT kialakulása után azonnal használjuk ezt a biztonsági másolatot, a Norecovery módban hagyva. Azta! Miért, az adatbázis helyreállításánál most csak 10-15 percet fogunk menni, ahelyett, hogy helyreállna egy hatalmas bázist! Gratulálunk, megerősítettük a folyóirat kézbesítési mechanizmust, az egyik módja az állásidő csökkentésének egyik módja. Ha az időtartamban több mint egyszer lehet továbbítani az adatokat, de folyamatosan, akkor már tükrözi, és ha az alapforrás várja az alaptükényt, akkor ez a szinkron tükrözés, ha nem vár, akkor az aszinkron.

További információ a magas rendelkezésre állásról Súgóban olvasható:

• Nagy rendelkezésre állás (adatbázis-motor komponens)
  • Általános információk a magas rendelkezésre állású megoldásokról
  • Magas rendelkezésre állás. Interakció és együttműködés

A biztonsági mentés egyéb aspektusai

Ez a rész biztonságosan kihagyható, ha az elmélet és a kezek unatkoznak veled, hogy teszteljék a biztonsági mentési beállításokat.

Fájlcsoportok

1c: A vállalat lényegében képes dolgozni a fájlcsoportokkal. Van egy fájlcsoport, és ez az. Tény, hogy a programozó vagy rendszergazda a MS SQL adatbázis képes néhány táblák, indexek vagy akár darab táblák és indexek, hogy külön file-csoportok (a legegyszerűbb változata - a különálló fájlok). Szükség van annak érdekében, hogy felgyorsítsa a hozzáférést bizonyos adatokhoz (nagyon gyors média), vagy fordítva, feláldozza az olcsóbb médiákra (például alacsonyan alkalmazott, de voluminadatokat). A fájlcsoportokkal való munkavégzés során lehetőség nyílik arra, hogy külön-külön készítsenek biztonsági másolatot, külön-külön helyreállíthatjuk, de figyelembe kell vennie, hogy az összes fájlcsoportnak egy pillanatra "felzárkóznia kell", hogy RCCT gördüljön.

Adat fájlok

Ha egy személy ellenőrzi az adatokat az adatokba különböző fájlcsoportokká, akkor akkor, ha a fájlcsoporton belül több fájl van, akkor az adatok az SQL Server MS SQL-kiszolgálótól függetlenül süllyednek (egyenlő fájlvonalakkal - egyenletesen próbálkoznak). Alkalmazott szempontból ezt az I / O műveletek párhuzamosítására használják. És a biztonsági másolat szemszögéből van egy másik pillanat. Nagyon nagy adatbázisok esetében az EPOCH "SQL 2008-ra" volt tipikus probléma Válasszon egy folyamatos ablakot a teljes mentéshez, és a vevőegység a biztonsági mentéshez egyszerűen nem fogadhatja el. A legtöbb. egyszerű út Ebben az esetben minden fájl (vagy fájlcsoport) biztonsági mentése az ablakra. Most, a biztonsági mentési tömörítés aktív eloszlásával ez a probléma kevésbé vált, de ez a technika viselhető.

Mentési tömörítés

Az MS SQL Server 2008 Super Mega-Ultra funkcióval rendelkezik. Mostantól, örökké, a biztonsági másolatok tömöríthetők a repülés során. Ez csökkenti a BD 1C 5-10-szeres biztonsági mentés méretét. És figyelembe véve, hogy általában a teljesítményt a lemez alrendszer egy szűk DBMS, ez ad nemcsak csökken a tárolási költségeket, hanem egy hatékony biztonsági gyorsulás (bár a terhelés processzorok növekszik, de általában a processzor teljesítménye is elegendő a DBMS szerveren).

Ha a 2008-as verzióban ez a funkció csak az Enterprise Edition (ami nagyon drága) volt, akkor 2008-ban R2 Ez a szolgáltatás a szabványos verzió, amely nagyon elégedett.

Az alábbiakban, a példák elemzésénél a tömörítési beállításokat nem veszik figyelembe, de erősen javaslom a biztonsági másolatok használatával, ha nincs különösebb ok a letiltásra.

Egy biztonsági másolat - sok szakmai gyakorlat

Valójában a biztonsági mentés nem csak fájl, hanem egy meglehetősen bonyolult tartály, amelyben számos biztonsági másolat tárolható. Ez a megközelítés nagyon régi történet (én személy megfigyelni azt változat 6,5), de abban a pillanatban az adminisztrátorok a „szokványos” adatbázisok, különösen 1C adatbázisok, nincs komoly oka az „egy backup - egy fájl”. Az általános fejlődéshez hasznos, hogy több biztonsági másolat egy fájlba való felvételét is feltárja, de a legvalószínűbb, hogy nem használja (vagy ha használnia kell, akkor szétszerelte a Gauge-adminisztrátori dudorokat képzetlen).

Több tükör másolat

Az SQL Servernek másik csodálatos lehetősége van. A biztonsági mentést több vevővel párhuzamosan alkothatja. hogyan a legegyszerűbb példa, egy példányt bocsáthat be helyi lemez És ugyanabban az időben hajtogathatja a hálózati erőforrást. A helyi másolat kényelmes, mivel a visszanyerés jelentősen gyorsabb, a távoli másolat sokkal jobb, ha elhalasztja a fő adatbázis-kiszolgáló fizikai megsemmisítését.

Példák a biztonsági mentési rendszerekre

Szép elméletek. Itt az ideje, hogy gyakorolhassa ezt a konyhát.

Tipikus szerver biztonsági mentés konfigurálása a szolgáltatási tervek (karbantartásPLAN) segítségével

Ez a szakasz készen állt receptek, magyarázatokkal. Ez a rész nagyon unalmas és hosszú a képek miatt, így kihagyhatja.

A mester létrehozási terv szolgáltatást használjuk

A kiszolgáló biztonsági mentése TSQL parancsfájlok konfigurálása, bizonyos funkciók példái

Azonnal felmerül a kérdés, és miért még mindig? Úgy tűnik, hogy csak konfigurálva van, és minden úgy működik, mint egy óra? Miért kezdődik mindenféle szkript? A szolgáltatási tervek nem engedélyezik:

• Használjon tükörfoglalást
• Használja a kompressziós beállításokat a kiszolgáló beállításai kivételével
• Nem engedi, hogy rugalmasan reagáljon a feltörekvő helyzetekre (nincs hibaelhárítási lehetőségek)
• Nem teszi lehetővé a rugalmas biztonsági beállításokat
• A szolgáltatási tervek nagyon kényelmetlenek (és fenntartják ugyanazt) nagy mennyiségű Szerverek (akár talán már 3-4)

Az alábbiakban a tipikus biztonsági mentési parancsok vannak.

Teljes mentés

A teljes mentés egy meglévő fájl megerősítésével (ha van ilyen), és a felvétel előtt ellenőrzi az oldalak ellenőrzését. A mentési másolat kialakításakor az előrehaladás minden százalékát ütemezik

Backup adatbázis lemez \u003d n "c: Backup \\ mydb.bak" init, formátum, stats \u003d 1, checksum

Különböző biztonsági mentés

Hasonlóképpen - a különbség másolat

Mentési adatbázis lemezre \u003d n "C: Backup \\ mydb.diff" Differenciális, Init, formátum, stats \u003d 1, ellenőrző összeg

Rkjt

A tranzakciós napló biztonsági mentése

Backup Relence lemezre \u003d n "C: Backup \\ mydb.trn" init, formátum

Tükörfoglalás

Gyakran kényelmes, hogy egy nem-egy biztonsági másolatot azonnal, de kettő. Például, lehet fekszenek lokálisan a szerveren (a kéznél), és a második közvetlenül formák fizikailag távoli és védett a kedvezőtlen tárolási tárolási:

Mentési adatbázis lemezre \u003d n "C: Backup \\ mydb.bak", Tükörre. Lemez \u003d n "\\\\ biztonságos kiszolgáló \\ backup \\ mydb.bak" init, formátum

Fontos pont, amelyet gyakran figyelmen kívül hagynak: a felhasználó, amelynek nevében az MSSQL szerver folyamat megkezdődik, hozzáférést kell biztosítania a "\\\\ biztonságos kiszolgáló \\ backup \\" erőforráshoz, különben a másolás hibával érkezik. Ha az MSSQL Server a rendszer nevében fut, akkor a User_Name Group domainhez való hozzáférést kell megadni, de jobb, ha helyesen állítsa be az MS SQL indítást egy speciálisan létrehozott felhasználó nevében.

Ha nem adja meg a tükörre, akkor nem lesz 2 tükör másolat, de egy példány, 2 fájlba törve, a váltakozás elvének megfelelően. És mindegyikük egyénileg haszontalan.

Az adatbázis-kiszolgálók bármely szervezet kulcsfontosságúak. Ez az, akik tájékoztatást és kiadást kérnek kérésre, és rendkívül fontos, hogy az adatbázist bármilyen helyzetben tartsa. Alapvető szállítás általában tartalmazza a szükséges eszközöket, de a administant, ne álljon az adatbázisban, akkor kell foglalkozni egy kis időt a jellemzői a munka, az automatizálás.

Az adatbázis-mentések típusai

Kezdjük, foglalkozunk azzal, hogy vannak mentések. Az adatbázis-kiszolgáló nem rendes asztali alkalmazás, és biztosítja, hogy minden sav tulajdonságot végrehajtsák (atom, konzisztencia, izolált, tartós), számos technológiát használnak, ezért a BD létrehozása és helyreállítása az archívumból van saját jellemzői. A mentési adatok három különböző megközelítése van, amelyek mindegyike rendelkezik előnyeivel és hátrányaival.

Logikai vagy SQL, Backup (PG_DUMP, MYSQLDUMP, SQLCMD), a tartalomtartalom azonnali képe a tranzakciós integritás alapján jön létre, és az SQL parancsokkal rendelkező fájlként kerül mentésre (kiválaszthatja az egész bázist vagy az egyes táblákat), amellyel újjáépítheti az adatbázist egy másik kiszolgálón. Ez időre van szükség (különösen a nagy adatbázisok esetében) a mentéshez és helyreállításhoz, így nagyon gyakran lehet végrehajtani ezt a műveletet, és a minimális terhelés során (például éjszaka) végezhető el. A rendszergazda helyreállításakor több parancsot kell végrehajtania ahhoz, hogy felkészítse mindazt, amire szüksége van (hozzon létre egy üres adatbázist, fiókok stb).

Fizikai biztonsági mentés (szint fájlrendszer) - Fájlok másolása, amelyeket a DBMS az adatbázisban lévő adatok tárolására használ. De egyszerűen másolás esetén a blokkolásokat és tranzakciókat figyelmen kívül hagyják, amelyeket valószínűleg helytelenül mentettek és megsértik. Ha megpróbálja csatolni ezt a fájlt, akkor inkonzisztens állapotban lesz, és hibákat eredményez. Az aktuális biztonsági mentés megszerzéséhez le kell állítania az adatbázist (csökkentheti az üresjárati időt kétszer az rsync - először egy dolgozónál, majd a leállított). Ennek a módszernek a hátránya nyilvánvaló - lehetetlen visszaállítani bizonyos adatokat, csak az egész adatbázist. Amikor elindítja az adatbázist a fájlrendszer archívumából, ellenőriznie kell az integritást. Különböző segédeszközök vannak. Például a PostgreSQL, Wal (írjon előre naplók) proaktív naplókat és speciális funkció (Időbeli helyreállítási pont - PitT), amely lehetővé teszi, hogy visszatérjen az adatbázis adott állapotához. Segítségük segítségével a harmadik forgatókönyv könnyen megvalósítható, ha a fájlrendszer szintű biztonsági mentés kombinálódik a Wal fájlok biztonsági mentésével. Először állítsa vissza a fájlrendszer biztonsági mentési fájljait, majd WAL-val, az alap a jelenlegi állapotba kerül. Ez egy kicsit összetettebb adminisztrációs megközelítés, de nincs probléma az adatbázis integritásával és a bázisok helyreállításával egy bizonyos időig.

A logikai biztonsági másolatot olyan esetekben használják, ahol az adatbázis teljes másolatát vagy a mindennapi használatra szükség van egy példány létrehozásához, sok időt vagy helyet igényel. Amikor az alap kirakodás hosszú időt vesz igénybe, figyelmet kell fordítani a fizikai archiválásra.

Csapos.

Engedély: Gnu gpl

Támogatott DBMS: Postgresql

A PostgreSQL támogatja a fizikai és logikus biztonsági mentés lehetőségeit, hozzáadva egy másik Wal szintet (lásd a betétet), amelyet folyamatos másolásnak nevezhetünk. De a szabványos eszközök segítségével, több kiszolgáló sem nagyon kényelmes, még az admin is a tapasztalat, és hiba esetén a számla másodpercekre megy.

Barman (Backup and Recovery Manager) - A vállalat belső fejlődése a 2ndQuadrant szolgáltatás nyújtása postgreSQL adatbázis. Ajánlott: A PostgreSQL fizikai mentéshez (logikai nem támogatja), Wal archiválása és gyors helyreállítása a hibák után. A távoli biztonsági mentés és a több kiszolgáló visszaállítása támogatott, pont-in-time-recovery funkciók (Pitlen), Wal Control. A távoli csomópontok, az SSH, a szinkronizálás és a biztonsági mentés módosítása az RSYNC segítségével lehetővé teszi a forgalom csökkentését. A Barman szintén integrálva van a Standard BZIP2, GZIP, TAR segédprogramok és hasonló. Elvileg bármilyen tömörítési és archiválási programot használhat, az integráció nem sok időt vesz igénybe. Különböző szerviz- és diagnosztikai funkciókat hajtanak végre, amelyek lehetővé teszik a szolgáltatás állapotának ellenőrzését és a sávszélesség beállítását. A forgatókönyvek előtti / postai küldemények támogatottak.

A Barman Pythonban van írva, a Biztonsági mentési házirend-kezelést egy Clear Barman.conf Ini fájl segítségével végezzük, amely / etc vagy a felhasználó otthoni könyvtárában lehet. A szállítás jön kész sablon Részletes megjegyzésekkel belül. Csak a * Nix-Systems-on működik. A RHEL, CENTOS és SCIENTIFIC LINUX telepítéséhez csatlakoztassa az EPEL-t - a tárolóat, amely tartalmazza. további csomagok. A Debian / Ubuntu felhasználók hivatalos tárolóval rendelkeznek:

$ sudo apt-get install install barman

A tárolóban nem mindig van legújabb verzióA telepítésnek a forrásszövegekhez kell fordulnia. A függőségek egy kicsit, és megértik a folyamat egyszerű.

Sypex dömper.

Engedély: BSD.

Támogatott DBMS: Mysql

A MySQLDUMP, a MySQlHotcopy segédprogramokat a MySQL-hez adja meg, így könnyen létrehozhat egy adatbázis-dumpot, jól dokumentáltak, és az interneten nagyszámú kész példát és frontandot találhat. Ez utóbbi lehetővé teszi, hogy egy újonc gyorsan elinduljon. A Sypex Dumper egy PHP parancsfájl, amely lehetővé teszi a MySQL adatbázis másolatának egyszerű létrehozását és visszaállítását. Nagy adatbázisokkal dolgozott, nagyon gyorsan, világos és kényelmes. Képes dolgozni a MySQL objektumokkal - bemutatók, eljárások, funkciók, triggerek és események.

Egy másik plusz, ellentétben más eszközökkel, amikor az UTF-8-ra történő átkódolás exportálása, a dömperben az exportot natív kódolásban végezzük. Az így kapott fájl kevesebb helyet foglal el, és maga a folyamat gyorsabban történik. Egy dumpban különböző kódolásokkal rendelkező tárgyak lehetnek. Ezenkívül könnyen importálható / exportálhat több lépésben előállítani, megállítani a folyamatot a terhelés során. A megújításkor az eljárás megindul a leállítási helyre. A helyreállítás során négy opciót támogatnak:

• Hozzon létre + betét - standard helyreállítási módot;
• TRUCKATE + INSERT - kevesebb idő a táblák létrehozásához;
• Cserélje ki - visszaállítottuk a régi adatokat a munkadokumentumban, anélkül, hogy új;
• A figyelmen kívül hagyja figyelmen kívül hagyását - Adja meg a törölt vagy új adatokat az adatbázisba, anélkül, hogy megérintene a meglévőket.

A másolási tömörítés fenntartása (GZIP vagy BZIP2) fennmarad, a régi mentések autóipari dátuma fennmarad, a dump fájl tartalma végrehajtásra kerül, csak a táblázatok szerkezetét helyreállítja. Vannak szolgáltatási adatbázis-kezelési funkciók (létrehozása, törlése, ellenőrzése, ellenőrzése, visszaállítása, optimalizálás, tisztítóasztalok, indexek és egyéb), valamint egy fájlkezelő, amely lehetővé teszi a fájlok átmásolását a szerverre.

A menedzsment webböngészővel történik, az Ajax használatával rendelkező felület lokalizálódik a dobozból, és létrehozza az asztali alkalmazással való munkát. Lehetőség van a konzolról és az ütemterven (Cron keresztül).

A dömpernek klasszikus L | WAMP kiszolgálóra van szüksége, a szokásos módon a PHP-ben írt összes alkalmazáshoz (másolási fájlok másolása és telepítése), és még az újoncok számára sem lesz nehéz. A projekt részletes dokumentációt és videoanyag, bizonyítani munka Sypex Dömper.

Két kiadás van: Sypex Dumper (ingyenes) és Pro (10 dollár). A másodiknak több lehetősége van, minden különbség jelenik meg a helyszínen.

SQL Backup és FTP

Engedély:

Támogatott DBMS: MS SQL Server

Az MS SQL Server az egyik népszerű megoldás, ezért gyakran megtalálható. A Biztonsági mentési feladat az SQL Server Management Studio környezetével, a Transct-SQL valójában és az SQL PowerShell modul cmdlets (Backup-sqldatabase) segítségével történik. A helyszínen az MS megtalálható nagy mennyiség dokumentáció, amely lehetővé teszi a folyamat kezelését. Dokumentáció Bár a teljes, de nagyon specifikus, és az interneten az információ gyakran ellentmond egymásnak. Az újonc ténylegesen meg kell valósulnia: "Vigye el a kezét", ezért még a fentiek ellenére is, harmadik fél fejlesztői Ott van, ahol megfordul. Továbbá ingyenes verzió Az SQL Server Express nem büszkélkedhet a beágyazott biztonsági mentési eszközökkel. Az SQL (2008-as) korábbi verzióihoz ingyenes segédprogramokat, például SQL Server biztonsági mentést találhat, de a legtöbb ilyen projektben már forgalomba került, bár gyakran a szimbolikus összeget kínálják az összes funkcionalitást.

Például az SQL Backup és az FTP és az egy kattintás SQL RESTORE fejlesztése megfelel a "beállított és elfelejtett" elvnek. Nagyon egyszerű és érthető felületen van, lehetővé teszik az MS SQL Server adatbázisok (beleértve az Express) és az Azure másolatát, a titkosított és tömörített fájlok az ftp i. felhőszolgáltatások (Dropbox, Box, Google Drive., Skydrive vagy Amazon S3), az eredmény azonnal megtekinthető. Lehetőség van a folyamat kézi és ütemtervének elindítására, üzenetet küldeni egy e-mail munka eredményéről, a felhasználói parancsfájlok indításáról.

A mentés összes variánsai támogatottak: teljes, differenciális, tranzakciós napló, fájl mappák és reggeli másolása. A régi biztonsági másolatok automatikusan eltávolításra kerülnek. K. csatlakoztatáshoz virtuális csomópont SQL Management Studio-t használ, bár itt lehetnek árnyalatok, és nem fog működni minden ilyen konfigurációban. Letöltéshez öt verziót kínálnak - a szabadban a vágott profi élettartamtól (az írás idején ezek a sorok csak 149 dollárba kerülnek). A szabad funkcionális elég elég ahhoz, hogy olyan kis hálózatokhoz van-e, ahol egy vagy két SQL szerver telepítve van, minden nagyobb funkció aktív. A számos biztonsági adatbázis korlátozott, a képesség, hogy küldjön fájlokat a Google Drive és a SkyDrive és titkosítja a fájlokat. Az interfész bár nem lokalizált, de még az újonc is nagyon egyszerű. Csak akkor kell csatlakozni az SQL Serverhez, amely után megjelenik az adatbázis-lista, meg kell jegyeznie a kívánt, konfigurálhatja a hozzáférést a távoli erőforrásokhoz, és adja meg a feladat végrehajtási idejét. És mindez egy ablakban.

De van egy "de". Maga a program nem célja az archívumok visszaállítására. Ez különálló ingyenes kattintásos SQL RESTORE segédprogramot kínál, a Backup adatbázis parancs által létrehozott formátum megértéséhez. Adminisztrátor Csak az archívum és a kiszolgáló meg kell adnia az adatokat, és nyomja meg az One gombot. De összetettebb forgatókönyvekben kell használni a visszaállítást.

MS SQL Server biztonsági mentési funkciók

Létrehozása biztonsági mentési és helyreállítási DBMS létesítő különbségeket, amelyeket meg kell figyelembe venni, különösen a sok, ha át az archívum egy másik szerverre. Például elemezzük az SQL Server néhány árnyalatát. A Tranzact-SQL használatával az archiváláshoz használja a Biztonsági mentési adatbázis parancsot (különbség-különbség) és a biztonsági napló-tranzakció naplója.

Ha a mentés egy másik szerveren bővül, meg kell győződnie arról, hogy ugyanazok a logikai lemezek vannak. Opcióként manuálisan regisztrálhatja az adatbázis-fájlok megfelelő elérési útjait az MOVE opció adatbázis parancsával.

Egyszerű helyzet - Biztonsági mentés és adatbázis átvitel más SQL Server verziókhoz. Ez a művelet támogatott, de az SQL Server esetében meg fog működni, ha a szerver verziója, amelyen a másolat telepítve van, azonos vagy újabb, mint a létrehozott. És van egy korlátozás: újabb legfeljebb két változat. Miután az adatbázis helyreállítása kompatibilitási módban lesz, az átmenet elvégzésével rendelkező verzióval, azaz az új funkciók nem érhetők el. A kompatibilitási_level megváltoztatásával könnyen megoldható. Ezt GUI vagy SQL segítségével lehet megtenni.

Alter Adatbázis MyDB SET Compatilitás_level \u003d 110;

Annak meghatározásához, hogy melyik verziót hozza létre, megtekintheti az archív fájl fejlécét. Nem kísérletezni váltáskor Új verzió Az SQL Server ingyenes Microsoft Upgrade Advisor segédprogramot kell futtatnia.

Iperius.

Engedély:kereskedelmi, ingyenes verzió van

Támogatott DBMS: Oracle 9-11, XE, MySQL, Mariadb, PostgreSQL és MS SQL Server

Ha többféle DBMS-t kell kezelnie, nincs kombináció nem. A választás nagy. Például iPerius egy könnyű, nagyon könnyű használni, és ezzel egyidejűleg erőteljes programot a fájlok biztonsági mentését, amelynek forró hát adatbázis-funkció megszakítása nélkül működik, vagy blokkolja. Teljes vagy inkrementális bacup. Teljes lemezképeket hozhat létre, hogy automatikusan újratelepítse az egész rendszert. Támogatja a biztonsági mentést NAS, USB eszközök, Streamer, FTP / FTPS, Google Drive, Dropbox és SkyDrive. Támogatja a zip tömörítést korlátozás nélkül a fájlok és az AES256-titkosítás méretében, külső szkriptek és programok indítása nélkül. Tartalmaz egy nagyon funkcionális feladat ütemezőt, esetleg párhuzamos vagy többféle feladat elvégzését, az eredményt e-mailben küldjük el. Számos szűrő, az útvonalak és beállítások személyre szabására szolgáló változók támogatottak.

Az FTP letöltésének képessége megkönnyíti az információk frissítését több webhelyen. Nyissa meg a fájlokat Fenntartva a VSS technológiával (árnyékmásolás a kötetek), amely lehetővé teszi a nem csak DBMS fájlok forró biztonsági mentését, de más alkalmazások is. Az Oracle magában foglalja az RMAN biztonsági mentési és helyreállítási szervezetet is (helyreállítási menedzser). Annak érdekében, hogy ne tegye túlterhelje a csatornát, lehetséges a sávszélesség beállítása. A foglalás és a helyreállítási menedzsment a helyi és webes konzol segítségével történik. A feladat minden funkciója ezért a feladat konfigurálásához csak a folyamat megértéséhez szükséges, a dokumentációnak még nem kellene megnéznie a dokumentációt. Csak kövesse a varázsló utasításait. Megjegyezheti a fiókkezelőt is, amely nagyon kényelmes számos rendszerrel.

Az alapfunkciók ingyenesen érhetők el, de az adatbázis fenntartási képességét csak az Advanced DB és a teljes verzióiban helyezik el. Támogatja a telepítést az XP-ről a Windows Server 2012-re.

Handy backup.

Engedély:kereskedelmi

Támogatott DBMS:Oracle, MySQL, IBM DB2 (7-9.5) és MS SQL Server

Az egyik legerősebb relációs menedzsment rendszer - az IBM DB2, egyedülálló méretezési funkcióval és több platform támogatására. Több kiadásban van, amelyek ugyanazon az alapon épülnek fel, és funkcionálisan eltérnek. A DB2 adatbázis-architektúra lehetővé teszi, hogy szinte mindenféle adatot kezeljen: Dokumentumok, XML, Médiafájlok és így tovább. Az ingyenes DB2 Express-C különösen népszerű. A Bacup nagyon egyszerű:

DB2 Backup db minta

Vagy pillanatfelvétel speciális másolási szolgáltatásokkal (ACS):

DB2 Backup DB Minta használata Pillanatkép

De emlékezni kell arra, hogy pillanatfelvételek esetén nem tudjuk visszaállítani az egyes táblákat (DB2 Recover DB). Van lehetőség az automatikus biztonsági mentésre, és még sok másra. A termékek jól dokumentáltak, bár az orosz nyelvű internet vezetése ritkán található. Az összes speciális megoldástól is messze megtalálható a DB2 támogatása.

Például Handy Backup lehetővé teszi, hogy végre egy biztonsági másolatot a többféle adatbázis-kiszolgálók és mentheti szinte minden média ( hDD, CD / DVD, felhős és hálózati tárolás, FTP / S, WebDAV és mások). Lehetséges biztonsági mentési adatbázisok ODBC-n keresztül (csak táblázat). Ez egyike azon kevés megoldások támogatása a DB2, és ezen kívül a „Ready for IBM DB2 Data Server Szoftver” logó. A teljes eljárást rendszeres varázsló segítségével végezzük, amelyben csak a kívánt elemet kell kiválasztania, és feladatot képez. Maga a konfiguráció folyamata olyan egyszerű, hogy az újonc képes lesz megérteni. Több munkahelyet hozhat létre, amely ütemezésen kezdődik. Az eredmény a naplóban van rögzítve és e-mailben küldhető. A feladat során a szolgáltatásmegálló nem szükséges. Az archívum automatikusan tömörített és titkosítva van, amely garantálja a biztonságát.

A DB2 támogatja a Handy Backup - Office Expert (helyi) és kiszolgálóhálózat (hálózat) két verzióját támogatja. Win8 / 7 / Vista / XP vagy 2012/2008/2003 futtató számítógépeken működik. A telepítési folyamat önmagában nem enyhült minden admin.

sQLCMD -S DECLSERVER \\ SQLGTD -E -Q "DECLARE @S VARCHAR (255) SET @ S \u003d 'E: \\ Backup \\ gtd_' + Convert (Varchar (1), DatePart (DW, GETDATE ()) + '. Bak 'Backup adatbázis GTD lemezre \u003d @s init, noformat, átugrás, főnév

sqlcmd. Lehetővé teszi a Tranzact-SQL utasítások, a rendszerfolyamatok és a szkriptfájlok bevitelét parancs sor A lekérdezési szerkesztőben SQLCMD módban,

• -S. - Megadja a kiszolgáló nevét, server [\\ casement_name];
• DECLSERVER \\ SQLGTD. - kiszolgálónév / példánynév, amelyen az alap fonódik;
• -. - az SQL Serverhez való csatlakozáshoz használt felhasználónév és jelszó bizalom helyett;
• -Q "cmdlinequery" - A program elindításakor sqlcmd. Kéri, de a program befejezése után a programból való kilépés nem történik meg. Több kérés végrehajtható, vesszővel elválasztva. Érintkezési idézetek a fentiek szerint;
• kijelent. - Kijelentjük a változó S, a név a változó mindig elkezdődik @, ezért @S.. A mi esetünkben @S. - ez a mentési tárolás mappája (lemez);
• varchar (n) - Megadja a változó típusát @S. mint egy hosszú karakterlánc, a 255 karakteres példában;
• kÉSZLET. - Beállítja a változó értékét @S., A példában ez az e lemez mentési mappája ( E: "Backup \\), akkor a biztonsági mentési fájl neve be van állítva, ahol a funkciókészlet Átalakítás (Varchar (1), Datepart (DW, GETDATE ())))) Visszatér a szöveges formátumban, hosszan 1 szimbólum A hét aktuális napja (hétfő - 1 , Kedd - 2 stb.) és a kiterjesztés hozzáadása bak.. A kimeneten kapunk egy nevű fájlt Gtd_donnedi.bak;
• biztonsági mentés. - biztonsági másolatot hoz létre;
• adatbázis - jelzi a teljes bázis biztonsági mentése;
• GTD. - példánkban az Alap neve az SQL szerveren;
• lemezre - jelzi az eszköz típusát tárolás, fájl merevlemezés a változó jelzi @S.amely a létrehozott fájl elérési útját és nevét hozzárendeli;
• az init, a noformat, augrás, a főnév - Azt jelzi, hogy szükség van, hogy átírják az adatokat egy kört felülírás fejlécek, amely lehetővé teszi számunkra, hogy 7 backup fájlokat minden nap a héten, átírt egy kört.

Szükség esetén más funkciókat, például tömörítést használhat, lásd a kérelmeket és a Tranzact-SQL funkciókat.

2. lépés: Változtassa meg a szövegfájl kiterjesztését. Cmd

Ennek eredményeként megkapjuk a fájlt backupgtd.cmd.. Futtassa a létrehozott parancsfájlt az adott géptől, ahol az MS SQL adatbázis telepítve van.

3. lépés. Automatizálja ezt a folyamatot

Fontolgat ez a lépés A Windows Server 2008 példájának példája: Szerverkezelő -\u003e Konfiguráció -\u003e Task Scheduler -\u003e Task Scheduler Könyvtár.