Craig Mullin adatbázis-adminisztrációs könyvének nyitó fejezetében azt mondja: “sok szempontból az üzlet ma adat”. A legtöbb szervezeten belül az adatok védelméért felelős személy az adatbázis adminisztrátora… te.

ez így van; az egész üzlet az Ön képes kezében van, azon a szerveren fut, amely soha nem omlik össze, mindazokkal a végfelhasználókkal, akik soha nem hibáznak az alkalmazások használatával, azok a fejlesztők építették, akik hibátlan kódot írnak először, minden alkalommal, annak az új szövetkezetnek a segítségével, amely a főnökének köszönhetően ‘sa’ jogosultságokkal rendelkezik.

rendben. Ne sírj. Vannak dolgok, amelyeket megtehetsz az SQL Server adatainak védelme érdekében, és az egyik legfontosabb a rendszeres adatbázis-mentések futtatása.

biztonsági mentések

a Microsoft az SQL Server Books Online-ban a biztonsági mentéseket a következőképpen határozza meg:

a rendszerhiba után az adatok visszaállítására és helyreállítására használt adatok másolata

az SQL biztonsági mentések számos módon hozhatók létre, és magukban foglalhatják az adatok egészét vagy egy részét, valamint a tranzakciós napló egy részét. Míg ez a cikk a 2005-ös szintaxisra összpontosít, a legtöbb fogalom 2000-re alkalmazható. Ez egy hatalmas téma. Legfeljebb a felszínt kaparom, és elég információt adok neked, hogy ne kezdj el újra sírni. Miután elolvasta ezt, képesnek kell lennie arra, hogy ésszerű biztonsági mentéseket állítson be a rendszeréhez.

helyreállítási modellek

a biztonsági mentések megkezdéséhez az üzleti igények meghatározzák az adatbázis-helyreállítási modellt. Lényegében egy helyreállítási modell határozza meg, hogy mit fog tenni a tranzakciós napló adataival.

három helyreállítási modell létezik: Full, Simple és Bulk Logged. Ezeket elég könnyű meghatározni:

• egyszerű-egyszerű helyreállítási módban a tranzakciós napló nem készül biztonsági mentéssel, így csak a legutóbbi teljes vagy differenciális biztonsági mentésre lehet visszaállítani.
• Full – teljes helyreállítási módban biztonsági másolatot készít az adatbázisról és a tranzakciós naplóról, hogy bármikor visszaállíthassa az adatbázist.
• tömeges Bejelentkezés – tömeges bejelentkezés módban a legtöbb tranzakció a tranzakciós naplóban van tárolva, de néhány tömeges művelet, például a tömeges terhelés vagy az index létrehozása nincs naplózva.

a két leggyakrabban használt mód Egyszerű és teljes. Ne feltétlenül feltételezzük, hogy természetesen mindig teljes helyreállítást kell használnia az adatok védelme érdekében. Ez egy üzleti döntés. A vállalkozás megmondja, hogy helyre kell-e állnia egy adott időpontig, vagy egyszerűen csak az utolsó teljes biztonsági mentésre van szüksége. Meg fogja határozni, hogy az adatok más módon helyreállíthatók-e, például kézi bevitel, vagy ha a lehető legnagyobb mértékben meg kell védenie, ahogy a vezetéken keresztül érkezik. Az egyszerű helyreállítást akkor használja, ha megengedheti magának, hogy elveszítse az utolsó teljes vagy differenciális biztonsági mentés óta tárolt adatokat, és/vagy csak nem kell egy bizonyos időpontig helyreállítani. Egyszerű módban vissza kell állítania az összes másodlagos olvasási/írási fájlcsoportot az elsődleges visszaállításakor. A Simple-t többnyire másodlagos adatbázisokon használja,amelyek nem abszolút létfontosságú részét képezik a vállalati vagy jelentési rendszereknek, csak olvasható hozzáféréssel, így egyébként nincs ügyleti napló. Ha az adatok minden bitje létfontosságú, akkor helyre kell állnia egy bizonyos időpontig, vagy általában nagyon nagy adatbázisok (VLDB) esetén vissza kell állítania az egyes fájlokat és fájlcsoportokat más fájloktól és fájlcsoportoktól függetlenül.

mind az egyszerű, mind a teljes helyreállítási modellekkel futtathat egy csak másolható biztonsági másolatot, amely lehetővé teszi az adatbázis másolását egy biztonsági mentési fájlba, de nem befolyásolja a naplót, a differenciális biztonsági mentési ütemezéseket vagy az ütközési helyreállítást egy adott időpontra. Megpróbálom a cikken keresztül a lehető legtöbb ilyen témát lebontani, de nem a fájlokat és a fájlcsoportokat.

munka egyszerű helyreállítási

elég beszélni. Térjünk le a biztonsági mentések futtatására. Tegyük fel, hogy egyszerű helyreállításban vagyunk egy kis vagy közepes méretű adatbázisban. Az AdventureWorks-t fogom használni az összes mintaszkripthez. Állítsa be az egyszerű helyreállítást:

a legegyszerűbb biztonsági mentési stratégia az, ha rendszeres időközönként futtatja a következő SQL Server biztonsági mentési parancsot, amely teljes biztonsági másolatot készít az adatbázisról:

mi ez a sok gépelés, amit kérdezel? Nincs GUI eszközök kezelni a munkát nekünk? Igen, a legtöbb egyszerű biztonsági mentést az SQL Server Management Studio segítségével lehet elvégezni. Azonban, ha meg akarja tanulni és megérteni, hogy mit csinál a Management Studio az Ön számára, vagy ha finom szemcsés ellenőrzést szeretne a biztonsági mentés, hogyan és hol, akkor ki kell bontania a billentyűzetet, és el kell helyeznie az egeret.

a fenti parancs kicsap egy alap biztonsági mentést a lemezre. A legtöbb dBA-t tudom biztonsági mentés fájlba, majd kaparja a fájlokat egy szalagra vagy más adathordozóra. Ez azért van, mert a lemezen lévő fájlok egyszerűek és gyorsan helyreállíthatók, míg a Média néha fájdalmat okozhat. Például általában két-három napos biztonsági mentésünk van a fájlrendszereinken az azonnali helyreállítás érdekében. Csak akkor megyünk a szalagos rendszerekhez, ha visszaállítást kell futtatnunk a régebbi biztonsági mentésekhez.

mit tett ez a parancs? Másolatot készített az adatbázisban elkövetett összes adatról. Azt is másolt lekötött napló bejegyzéseket. Ezeket a helyreállítás során használják a biztonsági mentési folyamat során az adatokban bekövetkezett változások elkövetésére vagy visszagörgetésére.

csak másolható biztonsági mentések

az adatbázisok biztonsági mentése általában más mentési és visszaállítási folyamatokra is hatással van. Például az előző parancs futtatása után minden differenciális biztonsági mentés (olyan biztonsági mentés, amely csak az utolsó biztonsági mentés óta megváltozott adatokat másolja) ezt használja az adatváltozások kiindulópontjaként, nem pedig a tegnap esti biztonsági mentést. Mint korábban megjegyeztük, az SQL 2005 új koncepciót vezet be a biztonsági mentésekhez, a COPY_ONLY biztonsági mentésekhez, amelyek lehetővé teszik számunkra, hogy ne szakítsuk meg a ciklust:

már találtunk egy olyan szemcsésebb pillanatot, amikor a menedzsment stúdió nem segít. Ha csak másolatot szeretne készíteni, akkor a parancssort kell használnia.

differenciális mentések

tegyük fel egy pillanatra, hogy még mindig egyszerű helyreállításban vagyunk, de egy nagyobb adatbázissal van dolgunk, Mondj valamit 100 GB felett. A teljes biztonsági mentések valójában kissé lelassíthatják a folyamatot. Ehelyett a vállalkozással folytatott konzultációt követően úgy döntöttünk, hogy heti teljes biztonsági mentést és napi differenciált biztonsági mentéseket készítünk. A differenciális biztonsági mentések csak az utolsó teljes biztonsági mentés óta megváltozott adatoldalakat mentik. Az alábbiakban bemutatjuk az SQL backup parancsot a differenciális biztonsági mentés végrehajtásához:

most, ha vissza kellene állítanunk ezt az adatbázist, először az utolsó teljes biztonsági mentéshez megyünk, visszaállítjuk azt, majd visszaállítjuk a differenciális biztonsági mentéseket sorrendben (erről bővebben később).

számos más biztonsági mentési lehetőség van, amelyeket itt nem részletezek. Olvassa el a könyveket online, hogy megtekinthesse a BLOCKSIZE, EXPIREDATE, RETAINDAYS, jelszó, név, statisztika stb.

futtathat egy utasítást is, amely ellenőrzi az adatbázis biztonsági mentésének integritását. Nem ellenőrzi a biztonsági mentésben lévő adatok integritását, de ellenőrzi, hogy a biztonsági mentés megfelelően van-e formázva és elérhető-e.

Full recovery and log backups

elsősorban olyan adatbázison dolgoztunk, amely egyszerű helyreállítási módban volt (ezt korábban csonka napló Ellenőrzőpontnak hívták). Ebben a módban nem készítünk biztonsági másolatot a tranzakciós naplókról a későbbi helyreállításhoz. A mechanizmus minden biztonsági mentése adatbázis-biztonsági mentés. A napló biztonsági mentése egyszerűen nem lehetséges.

az adatokat azonban csak az utolsó jó biztonsági mentés óta védte, akár teljes, akár differenciális. Változtassunk a feltételezéseinken. Most egy nagy, küldetéskritikus alkalmazással és adatbázissal van dolgunk. Azt akarjuk, hogy képes legyen visszaállítani ezt az adatbázist a legújabb percig. Ez egy nagyon fontos pont. Elméletileg, mivel a naplóbejegyzéseket tárolják és biztonsági másolatot készítenek, minden meghibásodásig védettek vagyunk. Néhány hiba azonban a napló sérülését okozhatja, ami lehetetlenné teszi a helyreállítást egy adott időpontban. Tehát meg kell határoznunk, hogy mi lesz az ésszerű minimális idő a naplómentések között. Ebben az esetben tudunk élni nem több, mint 15 perc értékű elveszett adatok.

Tehát kezdjük azzal, hogy adatbázisunkat teljes helyreállítási módba állítjuk:

ezután ütemezett módon, ebben az esetben 15 percenként futtatjuk az SQL backup parancsot a tranzakciós naplóhoz:

ez a parancsfájl biztonsági másolatot készít az elkövetett tranzakciókról a tranzakciós naplóból. A fájlban jelölők vannak, amelyek megmutatják az Indítás és a leállítás idejét. Ez csonkítja a naplót, ha sikeresen befejeződött, takarítás ki a tranzakciós napló az elkötelezett tranzakciók írtak a biztonsági mentési fájlt. Szükség esetén a WITH NO_TRUNCATE utasítással adatokat rögzíthet a tranzakciós naplóból az adatbázis állapotától függetlenül, feltételezve, hogy az online állapotban van, és nem vészhelyzetben van. Ez csak vészhelyzetekre van.

vegye figyelembe, hogy ebben az esetben nem használjuk az INIT utasítást, de megteheti, ha úgy dönt. Amikor naplóbeviteleket készít, lehetőségei vannak:

1. futtassa az összes biztonsági mentést egyetlen fájlba, ahol összeállnak, és mindössze annyit kell tennie, hogy visszaállítja (később lefedik), hogy átmenjen rajtuk.
2. nevezze el a biztonsági mentéseket egyedileg, valószínűleg a dátum és az idő használatával a karakterláncban.

ez utóbbi esetben a safety azt mondja, hogy használja az INIT-t, mert maximális ellenőrzést gyakorol arra, hogy mi kerül biztonsági mentésre, és pontosan tudja, hogy mi a biztonsági mentés, mikor készült, és honnan a név alapján. Ez egy újabb hely, ahol a parancssorból származó biztonsági mentések működtetése nagyobb irányítást biztosít, mint a GUI. Különböző okokból mindkét megközelítést alkalmaztuk rendszereinkben. Ön döntheti el, hogy mi a legjobb a technológiai és üzleti követelményeknek.

az adatbázis-biztonsági mentéshez rendelkezésre álló lehetőségek többsége szerepel a napló biztonsági mentésében, beleértve a COPY_ONLY-t is. Ez lehetővé tenné a tranzakciós adatok rögzítését anélkül, hogy befolyásolná a naplót vagy a következő ütemezett naplómentést. Ez hasznos lenne a termelési adatok másik rendszerbe történő átviteléhez hibaelhárítás céljából stb.

ha az adatbázis teljes helyreállításra van állítva, akkor naplómentéseket kell futtatnia. Néha az emberek elfelejtik, és a tranzakciós napló olyan mértékben növekszik, hogy kitölti a lemezmeghajtót. Ebben az esetben futtathatja:

a NO_LOG csatolása a napló biztonsági mentéséhez, és a napló helyének megadása nélkül a napló inaktív részét eltávolítja, és ezt maga a naplóbejegyzés nélkül teszi, így legyőzve a teljes lemezmeghajtót. Ez egyáltalán nem ajánlott, mert megszakítja a naplóláncot, a naplómentések sorozatát, amelyből az adatbázist egy adott időpontig helyreállíthatja. A Microsoft azt javasolja, hogy az utasítás használata után azonnal futtasson teljes biztonsági másolatot. Továbbá figyelmeztetnek arra, hogy ez az állítás egy későbbi kiadásban elavult lehet.

adatbázisok visszaállítása

bármennyire is fontosak az SQL Server biztonsági mentései, és létfontosságúak, az adatbázis visszaállítása nélkül haszontalanok.

teljes adatbázis-biztonsági mentés visszaállítása

a teljes adatbázis-biztonsági mentés visszaállítása olyan egyszerű, mint a létrehozása:

ez tényleg ilyen egyszerű-kivéve, ha mi mindent biztonsági másolatot készítünk egy fájlra, mintha egy biztonsági mentési eszköz lenne. Ebben az esetben meg kell adnia, hogy melyik fájlt használja az “eszközön”. Ha nem tudja, melyik fájl, akkor létre kell hoznia egy listát:

ez ugyanazt a listát fogja adni, mint amit fent mutattam a Management Studio-tól. Tehát most, ha vissza akarjuk állítani a csoport második fájlját, a COPY_ONLY biztonsági másolatot, akkor a következő parancsot adná ki:

sajnos, ha végigköveti, előfordulhat, hogy csak ezt a hibát generálta:

ez azt jelenti, hogy az adatbázis teljes helyreállítási módban van, de nem készített biztonsági másolatot a “napló farkáról”, vagyis a legutóbbi biztonsági mentés futtatása óta bevitt tranzakciókról. Felülbírálhatja ezt a követelményt, ha az előző szintaxist:

ez az első alkalom, hogy a WITH záradékokat egymásra rakjuk (a FILE=2 és a REPLACE kifejezéssel, mint a FILE=2, REPLACE), de nem ez lesz az utolsó. Olvassa el a könyveket online. A legtöbb with clause utasítás a többivel együtt használható.

mi történik, ha az eredetitől eltérő adatbázisba akarunk visszaállítani? Például szeretnénk másolatot készíteni az adatbázisunkról egy külön biztonsági másolatból. Lehet, hogy le akarjuk helyezni egy gyártástámogató szerverre, ahol valamilyen munkát fogunk végezni rajta, külön az adatbázis gyártási példányától. Ha az egyszerű megközelítést alkalmazzuk, jól, próbáld ki ezt:

ebben az esetben a fájlok nem felülírásával kapcsolatos hibák egész sorát kell látnia. Valóban létrehozhat új adatbázisokat a biztonsági másolatokból, de ha a meglévő adatbázissal rendelkező kiszolgálón csinálja, akkor a logikai nevek használatával meg kell változtatnia a fizikai fájlok helyét. Annak érdekében, hogy megismerje az adott adatbázis fájljainak logikai nevét, futtassa ezt a fájlok áthelyezésének megkísérlése előtt:

ez felhasználható a megfelelő Logikai nevek azonosítására a Szkript létrehozása érdekében:

differenciál biztonsági mentés visszaállítása

az utolsó módszer a differenciál biztonsági mentés alkalmazása. Ez két lépést igényel. Először visszaállítjuk az adatbázist, de csavarral, majd alkalmazzuk a differenciális biztonsági másolatot:

ennek nagy része valószínűleg magától értetődő az alapján, amit már lefedtünk. Az egyik ránc a NORECOVERY kulcsszó felvétele. Nagyon egyszerűen, a visszaállítás során a tranzakciók megkezdődhettek a biztonsági mentési folyamat során. Néhány közülük teljes, néhány pedig nem. a visszaállítás végén a befejezett tranzakciókat előre gördítik az adatbázisba, a hiányos tranzakciókat pedig visszaállítják. A NORECOVERY beállítása nyitva tartja a tranzakciókat. Ez lehetővé teszi, hogy a következő tranzakciókészletet sorrendben vegye fel a következő biztonsági mentésből.

ebben a cikkben elsősorban az egyszerű biztonsági mentésekkel és visszaállításokkal foglalkozunk, de egy fejlettebb Visszaállítás 2005-ben lehetővé teszi a másodlagos fájlcsoportok visszaállítását az adatbázis online állapotában. Elsődleges fájlcsoportjának online kell lennie a művelet során. Ez sokkal hasznosabb lesz a nagyon nagy adatbázis-rendszerek számára.

az SQL Server adatbázisok visszaállítása egy adott időpontra

a naplók visszaállítása nem sokkal nehezebb, mint az imént befejezett differenciális adatbázis-visszaállítás. Csak egy kicsit több részt vesz a helyreállításban egy pillanatra az időben. Feltételezve, hogy a naplókat egyetlen fájlra vagy eszközre menti:

ellenkező esetben egyszerűen megkapja a szükséges fájlneveket. Először futtassa az adatbázis visszaállítását, ügyelve arra, hogy nem helyreállított állapotban maradjon. Kövesse ezt fel egy sor napló visszaállítja egy adott időpontban.

most van egy adatbázisunk, ami a pontos, utolsó tranzakcióról szól, 14: 30: 29-kor, október 23-án. Ne feledje, hogy az ilyen többlépcsős visszaállítások során az adatbázist helyreállítási állapotban kell hagynia. Ez azt jelenti, hogy a NORECOVERY-t minden utasításhoz hozzá kell fűzni, amíg be nem fejezi a visszaállítási folyamatot. Ha valamilyen oknál fogva hozzáadta a NORECOVERY-t az összes utasításához, vagy egyszerűen megáll a közepén, és szeretné újra online állapotba hozni az adatbázist, akkor ezt az állítást használhatja a folyamat befejezéséhez:

Adatbázis pillanatképek

az SQL Server 2005 bevezette az adatbázis pillanatképének vagy csak olvasható, statikus nézetének fogalmát. A pillanatfelvételeket elsősorban az adatbázis csak olvasható verziójának biztosítása érdekében hozzák létre jelentési célokra. Ezek azonban a biztonsági mentésekhez hasonló módon működnek. Az egyik elsődleges különbség az, hogy az összes le nem kötött tranzakció visszagurul. Nincs lehetőség előre gördítésre, naplók rögzítésére stb., hogy a biztonsági mentések biztosítják, nem is nagyon sok SQL Server-erőforrást használnak. Inkább a lemez technológiát használják az adatok másolatának létrehozására. Emiatt sokkal gyorsabbak, mint a biztonsági mentések mind a létrehozáshoz, mind a visszaállításhoz.

megjegyzés:
az SQL 2005 Pillanatképpel kapcsolatos további részletekért lásd: http://www.simple-talk.com/sql/database-administration/sql-server-2005-snapshots/.

a jelentéskészítésen kívül a pillanatfelvételek jó haszna lehet, ha karbantartás előtt létrehozunk egyet, miután már eltávolítottuk az összes aktív felhasználót (és tranzakcióikat) a rendszerből. Bár a pillanatképek nem támogatják az ÉLŐ biztonsági mentések volatilitását, sebességük és könnyű helyreállításuk nagyszerű eszköz a gyors helyreállításhoz egy elrontott bevezetésből. A pillanatfelvételeket a szerver tárolja, ezért meg kell győződnie arról, hogy megfelelő tárhelye van-e.

a szintaxis más, mert nem biztonsági másolatot készít egy adatbázisról; újat hoz létre:

most csak olvasható hozzáférésre lesz elérhető. Mivel elsősorban azzal foglalkozunk, hogy ezt biztonsági mentési mechanizmusként használjuk, vegyük fel az adatbázis adatbázis pillanatképpé történő visszaállításának módszerét.

először azonosítsa a használni kívánt pillanatképet. Ha bármelyik adatbázisban egynél több van, amelyet vissza kíván állítani, akkor az összeset törölnie kell, kivéve azt, amelyet használ:

ezután visszaállíthatja az adatbázist egy RESTORE utasítás futtatásával (vegyes metaforák, nem jó):

ez az. A rendszeremen az Adventureworks adatbázis-pillanatképeinek futtatása 136 ms-ot vett igénybe. a teljes biztonsági mentés 5670 ms-ot vett igénybe. a pillanatkép visszaállítása 905 ms-ot, az adatbázis-visszaállítás pedig 13 382 ms-ot vett igénybe. Ennek beépítése a gyártási bevezetési folyamatba jelentős előnyöket eredményezhet

ismét érdemes megjegyezni, hogy vannak bizonyos figyelmeztetések a pillanatkép használatára. Elegendő lemezterületre van szüksége az adatbázis második példányához. Óvatosan kell kezelnie a pillanatképeket, mivel a szintaxis nagy része hasonló az adatbázisok által használt szintaxishoz. Utolsó, míg vannak pillanatképek csatolt egy adatbázis nem tudja futtatni a visszaállítás egy adatbázis biztonsági másolatot az adatbázis.

legjobb gyakorlatok

az adatbázis-mentések végrehajtásának módja nem lehet technikai döntés. Ezt az üzletnek kell diktálnia. Az alacsony tranzakciós arányú kis rendszereknek és / vagy a rendszeresen betöltött jelentési rendszereknek csak teljes adatbázis-biztonsági mentésre lesz szükségük. A közepes méretű rendszerek és a nagy rendszerek a kezelt adatok típusától függenek annak meghatározásához, hogy milyen típusú biztonsági mentésre van szükség.

közepes méretű rendszer esetén a napi biztonsági mentés naplómentésekkel valószínűleg időben megválaszolja a legtöbb adatkövetelményt.

nagy adatbázis esetén a legjobb megközelítés a biztonsági mentések keverése és illesztése a maximális helyreállítás minimális idő alatt. Például futtasson heti teljes biztonsági másolatot. A hét folyamán naponta kétszer futtasson differenciális biztonsági mentést. A nap folyamán 10 percenként futtasson naplóbevonást. Ez ad egy nagy számú helyreállítási mechanizmusok.

nagyon nagy adatbázisok esetén be kell lépnie a filegroup és a fájlmentések futtatásába, mert előfordulhat, hogy a teljes adatbázis teljes biztonsági mentése vagy akár differenciális biztonsági mentése nem lehetséges. Számos további funkció áll rendelkezésre ezen a területen, de itt nem fogok belemenni.

szánjon időt arra, hogy dolgozzon ki néhány szkriptet a biztonsági mentések futtatásához és visszaállításához. Egy elnevezési konvenció, hogy tudd, milyen adatbázis, melyik szerverről, melyik dátumtól, milyen konkrét biztonsági mentésben és formátumban lesz nagyon kedvező a józanságodhoz. Meg kell határozni a biztonsági mentések, a napló, a teljes vagy a növekményes közös helyét. Minden felelősnek képzettnek kell lennie mind a biztonsági mentésben, mind a helyreállításban, mind a hibaelhárításban. Ennek számos módja van, de néhány javaslatot találhat a Pop biztonsági mentések és a Pop visszaállítások részben.

az igazi teszt a biztonsági mentési mechanizmusok futtatása, majd a visszaállítás futtatása. Ezután próbáljon meg egy másik típusú visszaállítást, majd egy másik, és egy másik. Győződjön meg róla, hogy nemcsak a rendszer biztonsági mentésének meghatározásában végzett átvilágítást, hanem azt is, hogy megtette az extra lépést annak biztosítása érdekében, hogy helyreállítsa ezeket a biztonsági mentéseket. Ha még nem gyakorolta ezt, és dokumentálta a gyakorlatot, majd tesztelte a dokumentumot, akkor valójában nem áll készen a katasztrófára.

Összegzés

a vállalkozáson belüli biztonsági mentéseknek olyanoknak kell lenniük, mint a chicagói szavazás, Korán és gyakran. Az alapvető biztonsági mentések beállítása meglehetősen egyszerű. A log mentések és különbségek hozzáadása is egyszerű. Fedezze fel a lehetőségeket, hogy hogyan kell hozzáadni a fájl és fájl csoport mentések és visszaállítja, hogy növelje a sebességet a biztonsági mentések és visszaállítja mindkettő növeli a rendszer rendelkezésre állását és a rendelkezésre álló idő. Tartson közös elnevezési szabványt. Legyen óvatos pillanatképek használatakor, de mindenképpen alkalmazza őket. Tárolja a fájlokat egy szabványos helyen a szerverek között. Gyakorold a gyógyulásodat. Végül, hogy valóban a biztonsági mentések énekeljenek, töltsön le egy ingyenes próbaverziót a Red Gate SQL biztonsági mentéséről. Nagy teljesítményű tömörítést és hálózati rugalmasságot kínál, hogy a biztonsági másolatok írásának vagy másolásának folyamata a pelyhes hálózatokon keresztül hibatűrő legyen.