Biztonsági mentés a Windows rendszerben. A Windows operációs rendszer biztonsági mentése az Acronisba

Vírusoktól és szoftverhibáktól, hardverhibáktól vagy emberi hibáktól kezdve számos lehetséges veszély fenyegeti a fájlokat.

Vagy még ennél is rosszabb történhet – például személyes fényképek, zenei könyvtár, fontos üzleti dokumentumok elvesztése –, ami valóban értékes lehet. Ezért szükséges automatikusan biztonsági másolatot készíteni a számítógépről.

Ezt nagyon nehéz saját kezűleg megtenni, de megfelelő szoftverrel sokkal könnyebb lesz, mint gondolná. Pénzbeli kiadások nélkül, mert vannak ilyenek ingyenes biztonsági mentési és lemezklónozó programok.

Ha akarod, másolja át dokumentumai tartalmát valahol , klónozzuk egyik lemezt a másikra, vagy készítsen biztonsági másolatot a teljes rendszerről, sok olyan programot találtam, ami segíthet.

Akció biztonsági mentése

Az Action Backup talán a legjobb ütemezett fájlok biztonsági mentése otthoni és munkahelyi számítógépekhez. A program nagyon kényelmes, mivel egyesíti a könnyű használatot, valamint a biztonsági mentések készítésének széles funkcionalitását. Az Action Backup segítségével a következőket kapja: teljes, differenciális, növekményes biztonsági mentések támogatása, biztonsági mentések automatikus* mentése FTP szerverekre, CD/DVD, távoli hálózati erőforrások, zip64 formátum támogatás, árnyékmásolási funkció támogatása, munka Windows szerviz módban *, korábbi (elavult) archívumok automatikus törlése*, jelentés küldése e-mailben és még sok más (a funkciók részletes leírása a fejlesztő hivatalos honlapján érhető el).

Az Action Backup kezdőknek és tapasztalt felhasználóknak egyaránt tökéletes, így kiváló eszköz az otthoni számítógépeken, munkaállomásokon és szervereken lévő fájlok biztonsági mentéséhez.

* - csak a fizetős verzióban érhető el. A hivatalos weboldalon található a verziók összehasonlítása.

Aomei Backupper

Ha szereti a biztonsági mentési programokat, az Aomei egyszerű felülettel rendelkezik. Válassza ki a biztonsági mentéshez szükséges meghajtót vagy partíciót, a célmeghajtót, és kattintson a gombra Backupper képalkotás lesz.

A programnak elég jó eszközei vannak, ha kell. Lehetőségek vannak rá titkosítsa vagy tömörítse a biztonsági másolatokat. Létrehozhatsz növekményes vagy differenciális biztonsági mentések a nagyobb sebesség érdekében. tudsz helyreállíthatja az egyes fájlokat és mappákat, vagy a teljes képet, sőt vannak lemez- és partícióklónozó eszközök is.

Amit sajnos nem tudsz megtenni Ütemezett biztonsági mentések- manuálisan kell elindítani. Egyébként Aomei Backupper egy kiváló eszköz, rengeteg funkcióval, ugyanakkor könnyen használható.

EASEUS Todo biztonsági mentés ingyenes

Mint a legtöbb ingyenes (személyes használatra) kereskedelmi szoftver, EASEUS Todo biztonsági mentés ingyenes van néhány korlátozása – de a csomag még mindig több mint elegendő funkcióval rendelkezik a legtöbb ember számára.

A program mind fájl, mind fájl alapú biztonsági mentés alapján működhet, például manuálisan vagy ütemezetten. Tudsz-e dolgozni teljes vagy növekményes biztonsági mentések.

Az írási sebesség korlátozásának lehetősége csökkenti a biztonsági mentések hatását a rendszer teljesítményére. Ez lehetséges az egyes fájlokban vagy mappákban, vagy a teljes képfájlban egy lemez-helyreállító programmal. És vannak eszközök a meghajtók klónozására és formázására is.

A negatív oldalon nem kapunk titkosítást, nem kapunk differenciális biztonsági mentést, és csak lemezalapú Linuxot kapunk (nem Windows PE-t). De az EASEUS Todo Backup Free továbbra is nagyszerű programnak tűnik számunkra.

Ismételje meg a biztonsági mentést és helyreállítást

Ismételje meg a biztonsági mentést és helyreállítást — egy vizualizációs biztonsági mentési eszköz egy különbséggel. A program telepítése helyett le kell töltenie egy nagy (249 MB) ISO fájlt és írd CD-re vagy USB-meghajtóra. Ezután csak indítsa el, hogy elindítson egy egyszerű eszközt, amely biztonsági másolatot készíthet a merevlemezről, és később visszaállíthatja azokat.

Van még egy helyreállítási eszköz, és még egy webböngésző is, ha számítógépes probléma esetén kell segítséget kérnie.

A program nem teljesen kényelmes. A biztonsági mentéseket nem ütemezheti, mindegyiket manuálisan kell elindítani, és nagyon kevés lehetőség van.

De emellett könnyen használható és mindenki számára ingyenes, így ha időnként olyan biztonsági mentést szeretne készíteni, amelyet bármilyen számítógépen használhat szoftver telepítése nélkül, akkor ez a termék az Ön számára.

Cobian biztonsági mentés

Cobian biztonsági mentés egy kiváló biztonsági mentési szoftver sok funkcióval. Például teljes, differenciális és növekményes biztonsági mentéseket kap; ZIP vagy 7zip tömörítés, 256 bites AES titkosítás; szűrők belefoglalása és kizárása; ütemező, biztonsági mentés vagy FTP szerverek, és a lista folytatódik. A program minden aspektusa rendkívül testreszabható (több mint 100 testreszabható paraméter áll rendelkezésre).

PC vagy biztonsági mentés, kezdőknek valószínűleg nagyon nehéz lesz. Ha tapasztaltabb, szeretni fogja a szerszámok számát Cobian biztonsági mentés ellenőrzést biztosít a biztonsági mentési folyamat minden aspektusa felett.

Macrium Reflect ingyenes

Az egyik legnépszerűbb ingyenes (otthoni használatra) lemezképkészítő program, Macrium Reflect ingyenes Az alapfunkciók a felületen keresztül könnyen használhatók.

A program nem rendelkezik növekményes vagy differenciális biztonsági mentésekkel. És nem kap titkosítást vagy jelszavas védelmet. Nagyon egyszerűvé teszi a biztonsági mentések készítését (a forrásmeghajtó kiválasztása és a tömörítési arány beállítása kész).

Van egy tervező; A képeket felcsatolhatja a Windows Intézőben, vagy teljesen visszaállíthatja őket mind Linux, mind Windows PE helyreállítási lemezek. És úgy általában Macrium Reflect ingyenes Kiváló választás azoknak, akik egy egyszerű, de megbízható képmentő eszközre vágynak.

DriveImage XML

Személyes használatra ingyenes, DriveImage XM egyszerű alternatívája a fejlettebb versenytársaknak. A biztonsági mentés olyan egyszerű, mint a forrásmeghajtó, a célhely kiválasztása és a tömörítési szint (opcionális) beállítása.

A helyreállítás ugyanilyen egyszerű, és az egyetlen jelentős plusz az egyik meghajtóról a másikra való közvetlen másolás lehetősége.

Máshol is vannak komplikációk. Kattintson a "Feladatütemező" gombra, és utasításokat kap a kézi beállításhoz Windows Feladatütemező a biztonsági mentés elindításához. De ha csak egy alap renderelő eszközre van szüksége, akkor adjon DriveImage XML fogantyú.

FBiztonsági mentés

FBiztonsági mentés egy jó fájlmentési eszköz, ingyenes személyes és kereskedelmi használatra. A felület egyszerű és áttekinthető, és számos funkciót tartalmaz.

A bővítmények lehetővé teszik az egyes programok biztonsági mentését egyetlen kattintással; támogatja a szűrők be- és kizárását; és futtathat "Mirror" biztonsági mentéseket, amelyek egyszerűen átmásolnak mindent tömörítés nélkül (ami nagyon egyszerűvé teszi a fájlok helyreállítását).

A tömörítés azonban nem olyan jó (gyenge Zip2), és az ütemező is alaposabb, mint más programokban. De ha az Ön igényei egyszerűek, akkor FBiztonsági mentés megfelelnie kell neked.

Backup Maker

Személyes használatra eleinte ingyenes BackupMakerÚgy tűnik, mint bármely más fájlmentési eszköz, opcionális vagy teljes biztonsági másolatokkal, ütemezéssel, tömörítéssel, titkosítással, beillesztési és kizárási szűrőkkel stb.

De érdekes kiegészítő szolgáltatások közé tartozik az online biztonsági mentés támogatása az FTP-kiszolgálókon és a végrehajtás során automatikus biztonsági mentés ha USB-eszköz van csatlakoztatva.

A programadatokat Zip fájlok is tárolják, ami nagyon egyszerűvé teszi a hozzáférést. ÉS BackUp Maker egy kis, 6,5 MB-os telepítőcsomagban érkezik, sokkal jobban kezelhető, mint néhány nagyméretű versenytárs.

Ha otthoni felhasználó keres fájlok biztonsági mentésének módja, majd biztonsági mentés Készítő tökéletes lehet.

Clonezilla

Csakúgy, mint a biztonsági mentés és visszaállítás ismétlése, Clonezilla nem a telepítő: ez dos boot környezet, amely CD-ről vagy USB flash meghajtóról futtatható.

És ez egy nagyon erős program is: képes lesz lemezkép létrehozására; kép visszaállítása (egy lemezen vagy egyszerre többen); lemez klónozása (egyik lemez másolása a másikra), nagyobb vezérléssel.

Míg az ismételt biztonsági mentés és visszaállítás a könnyű használatra összpontosít, Clonezilla további lehetőségek, például a „felügyelet nélkül” Clonezilla PXE rendszerindításon keresztül." Nem nehéz, valószínűleg a legjobb ingyenes lemezklónozó program - de a program a tapasztalt biztonsági mentési felhasználóknak szól, kezdőknek jobb, ha találnak egy megfelelőbb lehetőséget.

Paragon Backup & Recovery 2014 ingyenes

Egy másik ingyenes program személyes használatra, Paragon Backup & Recovery 2014 ingyenes
jó eszköz, bizonyos korlátokkal.

Az alapítvány erős támogatása: megteheti készítsen biztonsági másolatot a képről(teljes vagy differenciált), tömöríteni és titkosítani használatuk kizárási szűrők hogy segítsen meghatározni, hogy mit tartalmaz, tegye meg ütemezett biztonsági mentések, majd állítsa vissza az egyes fájlokat és mappákat vagy mindegyiket.

Ezenkívül tartalmaz egy külön részt, amely segít a biztonsági másolatok biztonságában. És egy jó készlet alapvető eszközöket is tartalmaz.

Problémák? Nem fog növekményes biztonsági másolatot készíteni; Nem lehet lemezeket vagy partíciókat klónozni, és a felület néha nem túl jó. Mindazonáltal Paragon Backup & Recovery 20134 ingyenes Minőségi eszköz, érdemes figyelni.

Másolat

Ha online biztonsági mentésre van szüksége, akkor Másolat az egyik legsokoldalúbb eszköz, amely támogatja a fájlok mentését SkyDrive, Google Docs, FTP szerverek, Amazon S3, Rackspace Cloudfiles és WebDAV.

A program is képes mentse a helyi és hálózati meghajtókra, bár sok hasznos opciót tartalmaz (AES-256 titkosítás, jelszavas védelem, ütemező, teljes és növekményes biztonsági mentések, reguláris kifejezések támogatása szűrők beillesztéséhez/kizárásához, sőt fel- és letöltési sebességkorlátozások a rendszerre gyakorolt ​​hatás csökkentése érdekében).

Akár online, akár helyben menti a fájlokat, ez a program az Ön számára készült.

ALEXEY BEREZHNOY, Rendszergazda. Fő tevékenységi köre: virtualizáció és heterogén hálózatok. A cikkírás mellett egy másik hobbi az ingyenes szoftverek népszerűsítése

biztonsági mentés
Elmélet és gyakorlat. Összegzés

A biztonsági mentési rendszer leghatékonyabb megszervezéséhez valódi stratégiát kell felépítenie az információk mentésére és visszaállítására

A biztonsági mentés (vagy ahogy más néven biztonsági mentés - az angol „backup” szóból) fontos folyamat bármely IT-struktúra életében. Ez egy ejtőernyő, amely előre nem látható katasztrófa esetére szolgál. Ugyanakkor a biztonsági mentést arra használják, hogy egyfajta történeti archívumot hozzon létre a vállalat üzleti tevékenységeiről az élet egy bizonyos időszakában. Tartalék nélkül dolgozni olyan, mint a szabad ég alatt élni – az időjárás bármelyik pillanatban rosszra fordulhat, és nincs hová bújni. De hogyan kell helyesen megszervezni, hogy ne veszítsen fontos adatokat, és ne költsön rá fantasztikus összegeket?

A biztonsági mentések szervezése témakörben megjelenő cikkek jellemzően elsősorban technikai megoldásokat tárgyalnak, és csak elvétve fordítanak figyelmet az adattárolás megszervezésének elméletére és módszertanára.

Ebben a cikkben ennek az ellenkezőjéről lesz szó: a fő figyelmet az általános fogalmakra fordítjuk, a technikai eszközöket csak példaként fogjuk érinteni. Ez lehetővé teszi számunkra, hogy elvonatkoztassunk a hardvertől és a szoftvertől, és megválaszoljunk két fő kérdést: „Miért csináljuk ezt?”, „Megtehetjük ezt gyorsabban, olcsóbban és megbízhatóbban?”

A biztonsági mentés céljai és céljai

A biztonsági mentés megszervezése során két fő feladatot tűznek ki: az infrastruktúra helyreállítását meghibásodások esetén (katasztrófa-helyreállítás), valamint egy adatarchívum fenntartását, hogy utólagosan hozzáférjenek az elmúlt időszakok információihoz.

A Disaster Recovery biztonsági másolatának klasszikus példája az Acronis True Image által létrehozott kiszolgálórendszer-partíció képe.

Példa az archívumra az adatbázisok havi letöltése az 1C-ből, kazettára rögzítve, majd tárolása egy speciálisan kijelölt helyen.

Számos tényező különbözteti meg a gyors helyreállítási biztonsági másolatot az archívumtól:

• Adattárolási időszak. Az archív másolatok esetében ez meglehetősen hosszú időt vesz igénybe. Egyes esetekben nemcsak üzleti követelmények, hanem törvény is szabályozza. A katasztrófa utáni helyreállítási másolatok esetében viszonylag kicsi. Általában legfeljebb egy-két napos időközönként készítenek egy vagy két (megnövelt megbízhatósági követelmények mellett) biztonsági másolatot a Disaster Recovery számára, majd ezeket felülírják frissekkel. Különösen kritikus esetekben lehetőség van a biztonsági másolat gyakrabban, például néhány óránkénti frissítésére katasztrófa utáni helyreállítás céljából.
• Gyors hozzáférés az adatokhoz. A hosszú távú archívumhoz való hozzáférés sebessége a legtöbb esetben nem kritikus. Jellemzően az „időszakra vonatkozó adatok frissítésének” szükségessége a dokumentumok egyeztetésekor, egy korábbi verzióhoz való visszatéréskor stb. merül fel, vagyis nem vészhelyzetben. Egy másik dolog a katasztrófa utáni helyreállítás, amikor a szükséges adatokat és szolgáltatási teljesítményt a lehető leghamarabb vissza kell adni. Ebben az esetben a biztonsági mentéshez való hozzáférés sebessége rendkívül fontos mutató.
• A másolt információk összetétele. A biztonsági másolat általában csak felhasználói és üzleti adatokat tartalmaz egy meghatározott időszakra vonatkozóan. A katasztrófa-helyreállításra szánt másolat ezen adatokon kívül vagy rendszerképeket, vagy az operációs rendszer beállításainak és alkalmazásszoftvereinek másolatait, valamint a helyreállításhoz szükséges egyéb információkat tartalmaz.

Néha lehetséges kombinálni ezeket a feladatokat. Például egy évre szóló teljes havi pillanatkép egy fájlszerverről, valamint a hét folyamán végrehajtott változtatások. A True Image megfelelő eszköz egy ilyen biztonsági mentés készítéséhez.

A legfontosabb dolog az, hogy világosan megértsük, miért történik a foglalás. Mondok egy példát: egy kritikus SQL-kiszolgáló meghibásodott egy lemeztömb meghibásodása miatt. A megfelelő hardver van raktáron, így a megoldás a szoftver és az adatok helyreállítása volt. A cég vezetése érthető kérdést tesz fel: „Mikor kezd el dolgozni?” – és kellemetlen meglepetést okoz, amikor megtudja, hogy négy teljes órába telhet a felépülés. A tény az, hogy a kiszolgáló teljes élettartama alatt csak az adatbázisokról készült rendszeresen biztonsági mentés, anélkül, hogy figyelembe vették volna a szerver visszaállításának szükségességét az összes beállítással, beleértve magát a DBMS szoftvert is. Egyszerűen fogalmazva, hőseink csak az adatbázisokat mentették el, és megfeledkeztek a rendszerről.

Hadd mondjak még egy példát. Munkája teljes időtartama alatt a fiatal szakember az ntbackup programmal elkészítette a Windows Server 2003 operációs rendszert futtató fájlszerver egyetlen példányát, amely egy másik számítógép megosztott mappájában tárolja az adatokat és a rendszerállapotot. A korlátozott lemezterület miatt ezt a példányt folyamatosan felülírták. Egy idő után megkérték, hogy állítsa vissza egy többoldalas jelentés korábbi verzióját, amely a mentéskor megsérült. Nyilvánvaló, hogy mivel az előzmények archiválását nem kapcsolta ki a Shadow Copy-val, nem tudta teljesíteni ezt a kérést.

Egy megjegyzésre Árnyékmásolat, szó szerint – „árnyékmásolat”. Gondoskodik arról, hogy a fájlrendszer azonnali másolatai úgy készüljenek el, hogy az eredeti további módosításai ne legyenek hatással rájuk. Ezzel a funkcióval lehetőség van egy adott időn belül több rejtett másolat létrehozására egy fájlról, valamint az írásra megnyitott fájlokról menet közbeni biztonsági másolatok készítésére. A Kötetmásolat Árnyékszolgáltatás felelős az Árnyékmásolat működéséért. Rendszerállapot, szó szerint – „a rendszer állapota”. A System State Copy biztonsági másolatot készít a Windows operációs rendszerek kritikus összetevőiről. Ez lehetővé teszi a korábban telepített rendszer visszaállítását a megsemmisítés után. A rendszerállapot másolásakor a rendszer elmenti a rendszerleíró adatbázist, a rendszerindító és egyéb, a rendszer számára fontos fájlokat, beleértve az Active Directory, a Certificate Service adatbázis, a COM+Class Registration adatbázis, a SYSVOL címtár helyreállítását. UNIX operációs rendszerekben a rendszerállapot másolásának közvetett analógja az /etc, /usr/local/etc könyvtárak és a rendszerállapot visszaállításához szükséges egyéb fájlok tartalmának mentése.

Ami ebből következik: mindkét típusú biztonsági mentést kell használni: a katasztrófa utáni helyreállításhoz és az archív tároláshoz egyaránt. Ebben az esetben meg kell határozni a másolt erőforrások listáját, a feladatok végrehajtási idejét, valamint azt, hogy hol, hogyan és mennyi ideig tárolják a biztonsági másolatokat.

Kis adatmennyiség és nem túl bonyolult IT-infrastruktúra esetén megpróbálhatja kombinálni a két feladatot egyben, például napi teljes másolatot készíteni az összes lemezpartícióról és adatbázisról. De még mindig jobb különbséget tenni két cél között, és mindegyikhez kiválasztani a megfelelő eszközöket. Ennek megfelelően minden feladathoz más eszközt használnak, bár vannak univerzális megoldások is, mint például az Acronis True Image csomag vagy az ntbackup program

Nyilvánvaló, hogy a mentés céljainak és célkitűzéseinek, valamint a megvalósítási megoldások meghatározásakor az üzleti követelményekből kell kiindulni.

A katasztrófa utáni helyreállítási feladat végrehajtásakor különböző stratégiákat használhat.

Bizonyos esetekben szükség van a rendszer közvetlen visszaállítására csupasz fémre. Ezt megteheti például az Acronis True Image programmal kiegészítve az Universal Restore modullal. Ebben az esetben a kiszolgáló konfigurációja nagyon rövid időn belül visszaállítható. Például teljesen lehetséges egy 20 GB-os operációs rendszerrel rendelkező partíció helyreállítása egy biztonsági mentésből nyolc perc alatt (feltéve, hogy a biztonsági másolat elérhető 1 Gb/s-os hálózaton).

Egy másik lehetőségnél célszerűbb egyszerűen „visszaadni” a beállításokat az újonnan telepített rendszerbe, például a konfigurációs fájlok másolása a /etc mappából és a többi UNIX-szerű rendszerekben (Windowsban ez nagyjából a másolásnak felel meg és a rendszerállapot visszaállítása). Természetesen ezzel a megközelítéssel a szerver legkorábban az operációs rendszer telepítése és a szükséges beállítások visszaállítása előtt kerül üzembe, ami sokkal hosszabb időt vesz igénybe. De mindenesetre a katasztrófa utáni helyreállításról szóló döntés az üzleti igényekből és az erőforrások korlátaiból fakad.

Az alapvető különbség a tartalék és a redundáns redundancia rendszerek között

Ez egy másik érdekes kérdés, amit szeretnék feltenni. A redundáns berendezések redundanciarendszerei bizonyos redundanciát jelentenek a hardverben annak érdekében, hogy az egyik komponens hirtelen meghibásodása esetén fenntartsák a funkcionalitást. Kiváló példa ebben az esetben a RAID tömb (Redundant Array of Independent Disks). Egy lemez meghibásodása esetén elkerülheti az információvesztést és biztonságosan kicserélheti azt, magának a lemeztömbnek a sajátos felépítése miatt mentheti az adatokat (a RAID-ről bővebben itt olvashat).

Hallottam a következő mondatot: "Nagyon megbízható berendezéseink vannak, mindenhol vannak RAID tömbeink, így nincs szükségünk biztonsági másolatokra." Igen, természetesen ugyanaz a RAID-tömb megvédi az adatokat a megsemmisüléstől, ha az egyik merevlemez meghibásodik. Ez azonban nem menti meg Önt a számítógépes vírusok által okozott adatkárosodástól vagy a nem megfelelő felhasználói műveletektől. A RAID nem menti, ha a fájlrendszer összeomlik egy jogosulatlan újraindítás következtében.

Apropó A biztonsági mentés és a redundáns rendszerek megkülönböztetésének fontosságát fel kell mérni az adatok másolására vonatkozó terv elkészítésekor, legyen szó akár szervezetről, akár otthoni számítógépekről. Kérdezd meg magadtól, hogy miért készítesz másolatokat. Ha biztonsági mentésről beszélünk, akkor ez egy véletlen (szándékos) művelet során történő adatmentést jelent. A redundáns redundancia lehetővé teszi az adatok mentését, beleértve a biztonsági másolatokat is, a berendezés meghibásodása esetén. Manapság sok olyan olcsó eszköz létezik a piacon, amelyek megbízható biztonsági mentést biztosítanak RAID-tömbök vagy felhőtechnológiák használatával (például Amazon S3). Javasolt mindkét típusú információs biztonsági mentés egyidejű használata. Andrej Vasziljev, a Qnap Russia vezérigazgatója

Hadd mondjak egy példát. Vannak esetek, amikor az események a következő forgatókönyv szerint alakulnak: amikor egy lemez meghibásodik, az adatok visszaállítása redundancia mechanizmuson keresztül történik, különösen mentett ellenőrző összegek használatával. Ilyenkor jelentősen csökken a teljesítmény, lefagy a szerver, és az irányítás szinte elveszik. A rendszergazda, mivel nem lát más kiutat, hideg újraindítással újraindítja a szervert (vagyis rákattint a „RESET” gombra). Az ilyen élő túlterhelés eredményeként fájlrendszeri hibák lépnek fel. A legjobb, ami ebben az esetben elvárható, hogy a lemezellenőrző program hosszú ideig fut, hogy helyreállítsa a fájlrendszer integritását. A legrosszabb esetben el kell búcsúznia a fájlrendszertől, és fejtörést okoz az a kérdés, hogy hol, hogyan és milyen időn belül lehet visszaállítani az adatokat és a szerver teljesítményét.

Akkor sem kerülheti el a biztonsági mentést, ha fürt architektúrája van. A feladatátvevő fürt lényegében fenntartja a rábízott szolgáltatások funkcionalitását, ha valamelyik kiszolgáló meghibásodik. A fenti problémák, például vírustámadás vagy a hírhedt „emberi tényező” miatti adatsérülés esetén semmilyen fürt nem menti meg.

Az egyetlen dolog, ami a katasztrófa-helyreállítás gyengébb biztonsági mentési helyettesítőjeként működhet, az a tükör biztonsági mentési kiszolgáló jelenléte, amely folyamatos adatreplikációt biztosít a fő kiszolgálóról a tartalék szerverre (az elsődleges  készenléti elv szerint). Ebben az esetben, ha a főszerver meghibásodik, annak feladatait a tartalék veszi át, és még adatátvitel sem szükséges. De egy ilyen rendszer megszervezése meglehetősen drága és munkaigényes. Ne feledkezzünk meg az állandó replikáció szükségességéről.

Világossá válik, hogy egy ilyen megoldás csak olyan kritikus szolgáltatások esetében költséghatékony, amelyeknél magas a hibatűrés és minimális helyreállítási idő. Általában az ilyen rendszereket nagyon nagy szervezetekben használják, nagy áru- és készpénzforgalommal. Ez a séma pedig gyengébb helyettesítője a biztonsági mentésnek, mert egyébként is, ha az adatokat egy számítógépes vírus, nem megfelelő felhasználói műveletek vagy az alkalmazás hibás működése sérti meg, mindkét szerver adatai és szoftverei hatással lehetnek.

És természetesen egyetlen redundáns biztonsági mentési rendszer sem oldja meg az adatarchívum egy bizonyos ideig történő karbantartásának problémáját.

A „biztonsági ablak” fogalma

A biztonsági mentés végrehajtása nagy terhelést jelent a mentett kiszolgálóra. Ez különösen igaz a lemez alrendszerére és a hálózati kapcsolatokra. Egyes esetekben, amikor a másolási folyamat meglehetősen magas prioritású, ez bizonyos szolgáltatások elérhetetlenségéhez vezethet. Ezenkívül az adatok másolása a módosítások végrehajtása során jelentős nehézségekkel jár. Természetesen vannak technikai eszközök a problémák elkerülésére az adatok sértetlenségének megőrzése mellett, de ha lehetséges, jobb elkerülni az ilyen menet közbeni másolást.

E problémák megoldására a fent leírt megoldás önmagát sugallja: a másolatkészítési folyamat kezdetét el kell halasztani egy inaktív időszakra, amikor a biztonsági mentés és a többi futó rendszer kölcsönös hatása minimális lesz. Ezt az időszakot „mentési ablaknak” nevezik. Például egy 8x5 képlet szerint működő szervezetnél (heti öt nyolcórás munkanap) ilyen „ablak” általában a hétvégék és az éjszakai órák.

A 24x7 képlet szerint működő rendszereknél (egész héten éjjel-nappal) a minimális aktivitási időszakot használják ilyen időszakként, amikor nincs nagy terhelés a szervereken.

A biztonsági mentés típusai

A mentések megszervezése során felmerülő felesleges anyagköltségek elkerülésére, illetve lehetőség szerint a biztonsági mentési ablakon túlmenően több mentési technológiát fejlesztettek ki, amelyeket az adott helyzettől függően alkalmaznak.

Teljes biztonsági mentés (vagy teljes biztonsági mentés)

Ez a biztonsági másolatok készítésének fő és alapvető módszere, amelyben a kiválasztott adattömb teljes egészében másolásra kerül. Ez a legteljesebb és legmegbízhatóbb biztonsági mentési típus, bár ez a legdrágább. Ha több adatpéldányt kell menteni, a teljes tárolt mennyiség azok számával arányosan növekszik. Az ilyen pazarlás megelőzése érdekében tömörítési algoritmusokat használnak, valamint ennek a módszernek a kombinációját más típusú biztonsági mentésekkel: növekményes vagy differenciális. És természetesen a teljes biztonsági mentés nélkülözhetetlen, ha biztonsági másolatot kell készítenie a rendszer gyors helyreállításához a semmiből.

Növekményes másolat

A teljes biztonsági mentéssel ellentétben ebben az esetben nem minden adat (fájlok, szektorok stb.) kerül másolásra, hanem csak azok, amelyek az utolsó másolat óta megváltoztak. Különféle módszerekkel határozható meg a mentési idő, például Windows operációs rendszert futtató rendszereken egy megfelelő fájlattribútumot (archív bit) használnak, amely akkor kerül beállításra, amikor a biztonsági mentési program módosította és visszaállítja a fájlt. Más rendszerek használhatják a fájl módosításának dátumát. Nyilvánvaló, hogy az ilyen típusú biztonsági mentést használó séma hiányos lesz, ha időről időre nem hajtják végre a teljes biztonsági mentést. A teljes rendszer-visszaállítás végrehajtásakor vissza kell állítania a Full backup által létrehozott legutóbbi másolatot, majd felváltva „feltekerni” az adatokat a növekményes másolatokból a létrehozásuk sorrendjében.

Mire használják ezt a másolási módot? Archív másolatok készítése esetén csökkenteni kell a tárolóeszközök fogyasztott mennyiségét (például csökkenteni kell a felhasznált szalagos adathordozók számát). Ezzel minimálisra csökkenti a biztonsági mentési feladatok elvégzéséhez szükséges időt is, ami rendkívül fontos lehet olyan körülmények között, amikor napi 24 órában elfoglalt munkarendben kell dolgoznia, vagy nagy mennyiségű információt kell pumpálnia.

A fokozatos másolásnak van egy figyelmeztetése, amelyet tudnia kell. A lépésről lépésre történő helyreállítás a szükséges törölt fájlokat is visszaadja a helyreállítási időszak alatt. Hadd mondjak egy példát. Tegyük fel, hogy a teljes biztonsági mentés hétvégén, a növekményes pedig hétköznapokon történik. A felhasználó hétfőn létrehozott egy fájlt, kedden megváltoztatta, szerdán átnevezte, csütörtökön pedig törölte. Tehát egy heti időszakra szóló szekvenciális, lépésről lépésre történő adatvisszaállítással két fájlt kapunk: kedden az átnevezés előtti régi névvel, szerdán pedig új névvel. Ez azért történt, mert a különböző növekményes másolatok ugyanannak a fájlnak különböző verzióit tárolták, és végül az összes verziót visszaállították. Ezért az archívumból az adatok szekvenciális visszaállítása során érdemes több lemezterületet lefoglalni, hogy a törölt fájlok is elférjenek.

Differenciális biztonsági mentés

Ez abban különbözik a növekményestől, hogy az adatokat a teljes biztonsági mentés utolsó pillanatától másolják át. Az adatokat „halmozottan” tároljuk az archívumban. A Windows család rendszerein ezt a hatást úgy érik el, hogy a differenciális másolás során az archív bitet nem állítják vissza, így a megváltozott adatok addig kerülnek az archív másolatba, amíg egy teljes másolat vissza nem állítja az archív biteket.

Tekintettel arra, hogy minden ilyen módon létrehozott új másolat tartalmaz adatokat az előzőről, ez kényelmesebb az adatok teljes visszaállításához a katasztrófa idején. Ehhez mindössze két példányra van szüksége: a teljesre és az utolsóra a differenciálisak közül, így sokkal gyorsabban életre keltheti az adatokat, mintha az összes lépést fokozatosan kivezetné. Ráadásul ez a fajta másolás mentes a növekményes másolás fent említett jellemzőitől, amikor teljes helyreállítással a régi fájlok, mint egy Főnix madár, újjászületnek a hamvakból. Kevesebb a zűrzavar.

De a differenciális másolás lényegesen gyengébb a növekményes másolásnál a szükséges hely megtakarításában. Mivel minden új másolat a korábbiak adatait tárolja, a lefoglalt adatok teljes mennyisége összehasonlítható egy teljes másolattal. És természetesen az ütemterv megtervezésekor (és annak kiszámításakor, hogy a mentési folyamat belefér-e az időablakba), figyelembe kell venni az utolsó, legvastagabb, differenciális másolat elkészítésének idejét.

Tartalék topológia

Nézzük meg, milyen biztonsági sémák vannak.

Decentralizált rendszer

Ennek a sémának a magja egy bizonyos megosztott hálózati erőforrás (lásd 1. ábra). Például egy megosztott mappa vagy egy FTP-kiszolgáló. Szükség van egy biztonsági mentési programkészletre is, amely időről időre információkat tölt fel a szerverekről és a munkaállomásokról, valamint egyéb hálózati objektumokról (például az útválasztók konfigurációs fájljairól) erre az erőforrásra. Ezek a programok minden szerverre telepítve vannak, és egymástól függetlenül működnek. Kétségtelen előnye ennek a rendszernek a végrehajtásának egyszerűsége és alacsony költsége. Másoló programokként az operációs rendszerbe vagy a szoftverbe beépített szabványos eszközök, például DBMS alkalmasak. Ez lehet például az ntbackup program a Windows családhoz, a tar program UNIX-szerű operációs rendszerekhez, vagy olyan szkriptek, amelyek beépített SQL szerver parancsokat tartalmaznak az adatbázisok biztonsági mentési fájlokba való törléséhez. Egy másik előny a különféle programok és rendszerek használatának lehetősége, mindaddig, amíg mindegyik hozzáfér a biztonsági másolatok tárolására szolgáló célforráshoz.

A hátránya ennek a rendszernek az ügyetlensége. Mivel a programok egymástól függetlenül kerülnek telepítésre, mindegyiket külön kell konfigurálni. Elég nehéz figyelembe venni az ütemezés sajátosságait és elosztani az időintervallumokat annak érdekében, hogy elkerüljük a versenyt a cél erőforrásért. A felügyelet is nehézkes; az egyes szerverekről történő másolási folyamatot a többitől külön kell figyelni, ami viszont magas munkaerőköltségekhez vezethet.

Ezért ezt a sémát kis hálózatokban használják, valamint olyan helyzetekben, amikor lehetetlen központi biztonsági mentési sémát megszervezni a rendelkezésre álló eszközökkel. Ennek a sémának és a gyakorlati felépítésnek részletesebb leírása megtalálható a.

Központosított biztonsági mentés

Az előző sémától eltérően ebben az esetben egyértelmű hierarchikus modellt alkalmazunk, amely a kliens-szerver elven működik. A klasszikus változatban minden számítógépre speciális ügynökprogramok, a központi szerverre pedig a szoftvercsomag szervermodulja kerül telepítésre. Ezek a rendszerek speciális háttérkezelő konzollal is rendelkeznek. A vezérlési séma a következő: a konzolról másolási, visszaállítási, rendszerinformáció-gyűjtési, diagnosztikai, stb feladatokat hozunk létre, és a szerver megadja az ügynököknek a szükséges utasításokat ezen műveletek elvégzéséhez.

Ezen az elven működik a legtöbb népszerű biztonsági mentési rendszer, mint például a Symantec Backup Exec, a CA Bright Store ARCServe Backup, a Bacula és mások (lásd 2. ábra).

A legtöbb operációs rendszerhez különféle ágensek mellett fejlesztések vannak népszerű adatbázisok és vállalati rendszerek biztonsági mentésére, például MS SQL Server, MS Exchange, Oracle Database stb.

Nagyon kis cégek esetében bizonyos esetekben kipróbálhatja a központosított biztonsági mentési séma egyszerűsített változatát ügynökprogramok használata nélkül (lásd 3. ábra). Ez a séma akkor is használható, ha a használt biztonsági mentési szoftverhez nincs speciális ügynök implementálva. Ehelyett a szervermodul már meglévő szolgáltatásokat fog használni. Például „lekaparja” az adatokat a Windows-kiszolgálók rejtett megosztott mappáiból, vagy másoljon fájlokat SSH-n keresztül UNIX rendszereket futtató szerverekről. Ennek a sémának nagyon jelentős korlátai vannak az írásra nyitva álló fájlok mentési problémáival kapcsolatban. Az ilyen műveletek eredményeként a megnyitott fájlok vagy kimaradnak, és nem kerülnek bele a biztonsági másolatba, vagy hibásan másolódnak át. Számos megoldás létezik erre a problémára, például a feladat ismételt futtatása, hogy csak a korábban megnyitott fájlokat másolja, de egyik sem megbízható. Ezért ez a séma csak bizonyos helyzetekben használható. Például kis szervezetekben, amelyek 5x8-as üzemmódban dolgoznak, fegyelmezett alkalmazottakkal, akik elmentik a változtatásokat és bezárják a fájlokat, mielőtt hazamennének. Az ntbackup jó választás egy ilyen csonka központosított séma szervezéséhez, amely kizárólag Windows környezetben működik. Ha hasonló sémát kell használnia heterogén környezetben vagy kizárólag UNIX számítógépek között, akkor azt javaslom, hogy a Backup PC felé nézzen (lásd).

4. ábra Vegyes biztonsági mentési séma

Mi az off-site?

Zavaros, változó világunkban olyan események fordulhatnak elő, amelyek kellemetlen következményekkel járhatnak az informatikai infrastruktúra és a vállalkozás egészére nézve. Például tűz egy épületben. Vagy a központi fűtés akkumulátorának meghibásodása a szerverteremben. Vagy a berendezések és alkatrészek banális ellopása. Az információvesztés elkerülésének egyik módja ilyen helyzetekben az, hogy a biztonsági másolatokat a fő helytől távolabbi helyen tárolják. szerver berendezések. Ugyanakkor biztosítani kell a gyors hozzáférést a helyreállításhoz szükséges adatokhoz. A leírt módszert off-site-nek nevezik (más szóval a másolatok tárolása a vállalkozás területén kívül). Alapvetően két módszert alkalmaznak ennek a folyamatnak a megszervezésére.

Adatok írása cserélhető adathordozóra és fizikai mozgatása. Ebben az esetben mérlegelnie kell az adathordozó gyors visszaszerzésének módját hiba esetén. Például tárolja őket egy szomszédos épületben. Ennek a módszernek az az előnye, hogy ezt a folyamatot nehézségek nélkül meg lehet szervezni. Hátránya az adathordozók visszaküldésének nehézsége és a tároláshoz szükséges információk átvitelének szükségessége, valamint az adathordozó szállítás közbeni sérülésének veszélye.

Adatok másolása egy másik helyre hálózati kapcsolaton keresztül. Például VPN-alagút használata az interneten keresztül. Ebben az esetben az az előnye, hogy nincs szükség információs médiát valahova szállítani, a hátránya pedig az, hogy kellően széles csatornát kell használni (ez általában nagyon költséges), és meg kell védeni a továbbított adatokat (pl. ugyanaz a VPN). A nagy mennyiségű adat átvitele során felmerülő nehézségek jelentősen csökkenthetők tömörítési algoritmusok vagy deduplikációs technológia alkalmazásával.

Az adattárolás megszervezésénél külön érdemes megemlíteni a biztonsági intézkedéseket. Mindenekelőtt ügyelni kell arra, hogy az adathordozók biztonságos helyen legyenek elhelyezve, és gondoskodni kell arról, hogy illetéktelen személyek ne olvashassák be az adatokat. Például használjon titkosítási rendszert, kössön titoktartási megállapodásokat stb. Cserélhető adathordozó használata esetén a rajta lévő adatokat is titkosítani kell. A használt címkézési rendszer nem segítheti a támadót az adatok elemzésében. Arc nélküli számozási sémát kell használni az átvitt fájlok nevének adathordozójának megjelölésére. A hálózaton keresztüli adatátvitel során (ahogy fentebb már említettük) biztonságos adatátviteli módszereket kell használni, például VPN-alagút.

Megbeszéltük a biztonsági mentés megszervezésének főbb pontjait. A következő részben a módszertani ajánlásokat tárgyaljuk, és gyakorlati példákat adunk egy hatékony biztonsági mentési rendszer létrehozására.

1. A Windows biztonsági mentésének leírása, beleértve a rendszerállapotot is: http://www.datamills.com/Tutorials/systemstate/tutorial.htm.
2. A Shadow Copy leírása - http://ru.wikipedia.org/wiki/Shadow_Copy.
3. Az Acronis hivatalos weboldala – http://www.acronis.ru/enterprise/products.
4. Az ntbackup leírása - http://en.wikipedia.org/wiki/NTBackup.
5. Berezhnoy A. Az MS SQL Server működésének optimalizálása. //Rendszergazda, 2008. 1. szám – 14-22.o. ().
6. Berezhnoy A. Kis és közepes méretű irodák számára tartalék rendszert szervezünk. //Rendszergazda, 2009. 6. szám – 14-23. ().
7. Markelov A. Linux őrzi a Windowst. A BackupPC biztonsági mentési rendszer áttekintése és telepítése. //Rendszergazda, 2004. 9. szám – 2-6. o. ().
8. A VPN leírása – http://ru.wikipedia.org/wiki/VPN.
9. Adatduplikáció - http://en.wikipedia.org/wiki/Data_deduplication.

Kapcsolatban áll

Az új szerver működésre való felkészítése a biztonsági mentés beállításával kezdődik. Úgy tűnik, mindenki tud erről – de néha még a tapasztalt rendszergazdák is elkövetnek megbocsáthatatlan hibákat. És itt nem csak az a lényeg, hogy nagyon gyorsan meg kell oldani egy új szerver beállítását, hanem az is, hogy nem mindig egyértelmű, melyik mentési módszert érdemes használni.

Természetesen lehetetlen olyan ideális módszert alkotni, amely mindenkinek megfelelne: mindennek megvan a maga előnye és hátránya. Ugyanakkor meglehetősen reálisnak tűnik egy olyan módszer kiválasztása, amely a legjobban megfelel egy adott projekt sajátosságainak.

A biztonsági mentési módszer kiválasztásakor először a következő kritériumokra kell figyelnie:

1. A tárhelyre mentés sebessége (ideje);
2. A biztonsági másolatból való visszaállítás sebessége (ideje);
3. Hány példány tárolható korlátozott tárolóméret mellett (tartaléktároló szerver);
4. A biztonsági másolatok inkonzisztenciájából, a biztonsági mentések kidolgozatlan módjából, a biztonsági másolatok teljes vagy részleges elvesztéséből adódó kockázatok nagysága;
5. Rezsiköltségek: a kiszolgálón a másolás során keletkező terhelés mértéke, a szolgáltatás válaszadási sebességének csökkenése stb.
6. Az összes igénybe vett szolgáltatás bérleti díja.

Ebben a cikkben a Linux rendszereket futtató szerverek biztonsági mentésének fő módszereiről és a leggyakoribb problémákról fogunk beszélni, amelyekkel a kezdők találkozhatnak a rendszeradminisztráció ezen nagyon fontos területén.

A tárolás és a biztonsági másolatokból való helyreállítás megszervezésének sémája

A biztonsági mentési módszer megszervezésének sémája kiválasztásakor ügyeljen a következő alapvető pontokra:

1. A biztonsági másolatok nem tárolhatók ugyanazon a helyen, ahol a biztonsági másolat készül. Ha a biztonsági másolatot ugyanazon a lemeztömbön tárolja, mint az adatokat, akkor azt elveszíti, ha a fő lemeztömb megsérül.
2. A tükrözést (RAID1) nem lehet összehasonlítani a biztonsági mentéssel. A raid csak az egyik lemez hardverproblémáitól véd meg (és előbb-utóbb előfordul egy ilyen probléma, hiszen szinte mindig a lemez alrendszer jelenti a szűk keresztmetszetet a szerveren). Ezenkívül hardveres raidek használatakor fennáll a vezérlő meghibásodásának veszélye, pl. tartalék modellt kell tartania belőle.
3. Ha a biztonsági másolatokat egy DC-ben vagy egyszerűen egy DC-ben tárolja, akkor ebben a helyzetben is vannak bizonyos kockázatok (erről például olvashat.
4. Ha a biztonsági másolatokat különböző DC-kben tárolja, akkor a hálózati költségek és a távoli másolatból történő helyreállítás sebessége meredeken megnő.

Az adatok helyreállításának oka gyakran a fájlrendszer vagy a lemezek károsodása. Azok. a biztonsági másolatokat valahol egy külön tárolószerveren kell tárolni. Ebben az esetben a probléma az adatátviteli csatorna „szélessége” lehet. Ha van dedikált szerverünk, akkor nagyon tanácsos külön hálózati interfészen biztonsági mentéseket végezni, nem pedig azon, amelyik a kliensekkel adatot cserél. Ellenkező esetben előfordulhat, hogy az ügyfél kérései nem „férnek bele” a korlátozott kommunikációs csatornába. Illetve az ügyfélforgalom miatt a biztonsági mentések nem készülnek el időben.

Ezután át kell gondolnia az adat-helyreállítás sémáját és idejét a biztonsági másolatok tárolása szempontjából. Elégedett lehet azzal, hogy éjszaka 6 óra alatt elkészül a biztonsági mentés korlátozott hozzáférési sebességgel, de a 6 órás helyreállítás valószínűleg nem felel meg Önnek. Ez azt jelenti, hogy a biztonsági másolatokhoz való hozzáférésnek kényelmesnek kell lennie, és az adatokat elég gyorsan kell másolni. Így például 1 TB adat visszaállítása 1 Gb/s sávszélesség mellett közel 3 órát vesz igénybe, és ez akkor van, ha nem korlátozza a tárolóban és a szerverben lévő lemez alrendszer teljesítménye. És ne felejtse el ehhez hozzáadni a probléma észleléséhez szükséges időt, a visszaállításhoz szükséges időt, a visszaállított adatok sértetlenségének ellenőrzéséhez szükséges időt, valamint az ügyfelek/kollégák közötti elégedetlenség mértékét. .

Növekményes biztonsági mentés

Nál nél járulékos A biztonsági mentés csak azokat a fájlokat másolja, amelyek az előző mentés óta megváltoztak. A későbbi növekményes biztonsági mentések csak azokat a fájlokat adják hozzá, amelyek az előző óta megváltoztak. A növekményes biztonsági mentések átlagosan kevesebb időt vesznek igénybe, mivel kevesebb fájlt másolnak. Az adat-helyreállítási folyamat azonban tovább tart, mert vissza kell állítani az utolsó teljes biztonsági másolat adatait, valamint az összes további növekményes biztonsági mentés adatait. Ebben az esetben a differenciális másolástól eltérően a módosított vagy új fájlok nem helyettesítik a régieket, hanem önállóan kerülnek az adathordozóra.

A növekményes másolás leggyakrabban az rsync segédprogrammal történik. Segítségével tárhelyet takaríthat meg, ha a napi változtatások száma nem túl nagy. Ha a módosított fájlok nagyok, a rendszer a korábbi verziók cseréje nélkül teljesen átmásolja őket.

Az rsync használatával végzett biztonsági mentési folyamat a következő lépésekre osztható:

1. A rendszer összeállítja a redundáns szerveren és a tárolóban lévő fájlok listáját, metaadatokat (engedélyek, módosítási idő stb.) vagy ellenőrző összeget (a —checksum kulcs használatakor) beolvas minden fájlhoz.
2. Ha a fájlok metaadatai eltérnek, akkor a fájl blokkokra van osztva, és minden blokkra ellenőrző összeget számítanak ki. Az eltérő blokkok feltöltődnek a tárhelyre.
3. Ha az ellenőrzőösszeg kiszámítása vagy a fájl átvitele közben változás történik a fájlban, akkor a biztonsági mentés elölről megismétlődik.
4. Alapértelmezés szerint az rsync SSH-n keresztül továbbítja az adatokat, ami azt jelenti, hogy minden adatblokk további titkosításra kerül. Az Rsync démonként is futtatható, és titkosítás nélkül továbbíthatja az adatokat a protokolljával.

Az rsync működésével kapcsolatos részletesebb információk a hivatalos weboldalon találhatók.

Az rsync minden fájl esetében nagyon sok műveletet hajt végre. Ha sok fájl van a szerveren, vagy ha a processzor erősen le van terhelve, akkor a biztonsági mentés sebessége jelentősen csökken.

Tapasztalatból elmondható, hogy a SATA lemezeken (RAID1) a problémák körülbelül 200 G adatmennyiség után kezdődnek a szerveren. Valójában természetesen minden az inódák számától függ. És minden esetben ez az érték eltolódhat egyik vagy másik irányba.

Egy bizonyos pont után a biztonsági mentés végrehajtási ideje nagyon hosszú lesz, vagy egyszerűen nem fejeződik be egy nap alatt.

Annak érdekében, hogy ne hasonlítsa össze az összes fájlt, van lsyncd. Ez a démon információkat gyűjt a megváltozott fájlokról, pl. már előre lesz egy listánk, amely készen áll az rsync-re. Ugyanakkor figyelembe kell venni, hogy ez további terhelést jelent a lemez alrendszerére.

Differenciális biztonsági mentés

Nál nél differenciális A biztonsági mentésben minden fájlról, amely az utolsó teljes biztonsági mentés óta megváltozott, minden alkalommal biztonsági másolat készül. A differenciális másolás felgyorsítja a helyreállítási folyamatot. Csak a legújabb teljes és legújabb differenciálmentésre van szüksége. A differenciális biztonsági mentések egyre népszerűbbek, mivel a fájlokról bizonyos időpontokban minden másolat készül, ami például nagyon fontos vírusfertőzés esetén.

A differenciális biztonsági mentés például egy segédprogram, például az rdiff-backup segítségével történik. Amikor ezzel a segédprogrammal dolgozik, ugyanazok a problémák merülnek fel, mint a növekményes biztonsági mentéseknél.

Általánosságban elmondható, hogy ha teljes fájlkeresést hajt végre, amikor az adatok eltéréseit keresi, az ilyen biztonsági mentés problémái hasonlóak az rsync problémáihoz.

Külön szeretnénk megjegyezni, hogy ha a biztonsági mentési sémában minden fájlt külön-külön másol, akkor érdemes törölni/kizárni azokat a fájlokat, amelyekre nincs szüksége. Ezek lehetnek például CMS-gyorsítótárak. Az ilyen gyorsítótárak általában sok kis fájlt tartalmaznak, amelyek elvesztése nem befolyásolja a szerver megfelelő működését.

Teljes biztonsági mentés

A teljes biztonsági mentés általában az egész rendszert és az összes fájlt érinti. A heti, havi és negyedéves biztonsági mentés magában foglalja az összes adat teljes másolatának létrehozását. Általában pénteken vagy hétvégén hajtják végre, amikor a nagy mennyiségű adat másolása nem befolyásolja a szervezet munkáját. A következő biztonsági mentések, amelyeket hétfőtől csütörtökig a következő teljes biztonsági mentésig hajtanak végre, lehetnek differenciális vagy növekményes mentések, elsősorban az idő és a tárhely megtakarítása érdekében. A teljes biztonsági mentést legalább hetente el kell végezni.

A legtöbb kapcsolódó kiadvány azt javasolja, hogy hetente egyszer vagy kétszer végezzen teljes biztonsági mentést, a fennmaradó időben pedig növekményes és differenciális biztonsági mentéseket. Az ilyen tanácsoknak oka van. A legtöbb esetben elegendő egy teljes biztonsági mentés hetente egyszer. Célszerű újra futtatni, ha nem tudja frissíteni a teljes biztonsági másolatot a tárolási oldalon, és nem tudja biztosítani a biztonsági másolat helyességét (erre szükség lehet például olyan esetekben, amikor valamilyen okból ne bízzon a meglévő szkriptekben vagy biztonsági mentési szoftverekben.

Valójában a teljes biztonsági mentés 2 részre osztható:

1. Teljes biztonsági mentés a fájlrendszer szintjén;
2. Teljes eszközszintű biztonsági mentés.

Nézzük meg jellemző tulajdonságaikat egy példa segítségével:
root@komarov:~# df -h Fájlrendszer méret Használt Elérhetőség Felhasználás% Felszerelve a /dev/mapper/komarov_system-root 3.4G 808M 2.4G 25% / /dev/mapper/komarov_system-home 931G 439G 493G 48% /home 4,0K 383M 1% /dev tmpfs 107M 104K 107M 1% /futtatás tmpfs 531M 0 531M 0% /tmp nincs 5,0M 0 5,0M 0% /futtatás/zárolás nincs 531M 0 /dev/8Mshm 22M 109M 17% /boot

Csak foglalni fogunk /otthon. Minden más gyorsan visszaállítható manuálisan. Telepíthet egy kiszolgálót konfigurációkezelő rendszerrel is, és csatlakoztathatja hozzá a /home-unkat.

Teljes biztonsági mentés a fájlrendszer szintjén

Tipikus képviselője: szemétlerakó.

A segédprogram létrehozza a fájlrendszer „kiíratását”. Nem csak teljes, hanem növekményes biztonsági mentést is készíthet. A dump az inode táblával működik, és „érti” a fájlszerkezetet (tehát a ritka fájlok tömörítésre kerülnek).
Egy futó fájlrendszer kiíratása "hülye és veszélyes", mert a fájlrendszer megváltozhat a kiíratás létrehozása közben. Pillanatképből kell létrehozni (kicsit később részletesebben tárgyaljuk a pillanatképekkel való munkavégzés jellemzőit), egy csatolt vagy lefagyott fájlrendszerből.

Ez a séma a fájlok számától is függ, és a végrehajtási ideje a lemezen lévő adatok mennyiségével nő. Ugyanakkor a dump működési sebessége nagyobb, mint az rsync.
Ha nem a teljes biztonsági másolatot kell visszaállítani, hanem például csak néhány véletlenül sérült fájlt, akkor az ilyen fájlok visszaállítása a visszaállító segédprogrammal túl sok időt vehet igénybe.

Teljes eszközszintű biztonsági mentés

1. mdraid és DRBD
   Valójában a RAID1 egy lemezzel/raiddel van konfigurálva a szerveren és egy hálózati meghajtón, és időről időre (a biztonsági mentések gyakoriságának megfelelően) a kiegészítő lemezt szinkronizálja a szerveren lévő fő lemezzel/raiddel.

   A legnagyobb plusz a sebesség. A szinkronizálás időtartama csak az utolsó napon végrehajtott módosítások számától függ.
   Ezt a biztonsági mentési rendszert elég gyakran használják, de kevesen veszik észre, hogy a segítségével megszerzett biztonsági másolatok hatástalanok lehetnek, és itt van miért. Amikor a lemez szinkronizálása befejeződött, a biztonsági másolatot tartalmazó lemez leválasztásra kerül. Ha például olyan DBMS-t futtatunk, amely részletekben írja ki az adatokat a helyi lemezre, közbenső adatokat tárolva a gyorsítótárban, akkor nincs garancia arra, hogy azok még a mentési lemezre is kerülnek. Legjobb esetben a módosítandó adatok egy részét elveszítjük. Ezért az ilyen biztonsági mentések aligha tekinthetők megbízhatónak.

2. LVM+dd
   A pillanatképek nagyszerű eszköz a következetes biztonsági mentések készítéséhez. Pillanatkép létrehozása előtt vissza kell állítania az FS gyorsítótárát és a szoftvert a lemezalrendszerre.

Például egyedül a MySQL-lel ez így nézne ki:
$ sudo mysql -e "A TÁBLÁZATOK ÖBLÍTÉSE OLVASÁSZÁROLÁSSAL;" $ sudo mysql -e "FLUSH LOGS;" $ sudo sync $ sudo lvcreate -s -p r -l100%free -n %s_backup /dev/vg/%s $ sudo mysql -e "TÁBLÁZATOK OLDÁSA;"

* A kollégák mesélnek arról, hogy valaki „olvasási zárolása” néha holtponthoz vezetett, de emlékezetem szerint ez soha nem történt meg.

A DBMS biztonsági mentések külön is létrehozhatók (például bináris naplók használatával), így kiküszöbölhetők a leállások a gyorsítótár-visszaállítás során. A tárolóban is létrehozhat kiíratokat, ha ott elindít egy DBMS-példányt. A különböző DBMS-ek biztonsági mentése külön kiadványok témája.

Pillanatképeket másolhat a folytatás segítségével (például rsync egy javítással a blokkeszközök másolására bugzilla.redhat.com/show_bug.cgi?id=494313), blokkolhat blokkonként és titkosítás nélkül (netcat, ftp). A blokkokat tömörített formában is átviheti, és a tárolóba illesztheti az AVFS segítségével, és felcsatolhat egy partíciót biztonsági mentésekkel SMB-n keresztül a szerveren.

A tömörítés kiküszöböli az átviteli sebességgel, a csatornatorlódással és a tárhellyel kapcsolatos problémákat. Ha azonban nem használ AVFS-t a tárolóban, akkor sok időbe telik, amíg az adatoknak csak egy részét állítja vissza. Ha AVFS-t használsz, találkozni fogsz a „nedvességgel”.
A blokktömörítés alternatívája a squashfs: felcsatolhatunk például egy Samba partíciót a szerverre és futtathatunk mksquashfs-t, de ez a segédprogram fájlokkal is működik, pl. mennyiségüktől függ.

Ráadásul a squashf-ek létrehozásakor elég sok RAM megy kárba, ami könnyen az oom-killer meghívásához vezethet.

Biztonság

Meg kell védenie magát az olyan helyzetektől, amikor a tárolót vagy a szervert feltörik. Ha feltörték a szervert, akkor jobb, ha az oda adatokat író felhasználónak nincs joga a tárhelyen lévő fájlok törlésére/módosítására.
Ha a tárhelyet feltörték, akkor is célszerű a tartalék felhasználó jogait a szerveren a maximumra korlátozni.

Ha a tartalék csatorna lehallgatható, akkor titkosításra van szükség.

Következtetés

Minden biztonsági mentési rendszernek megvannak a maga előnyei és hátrányai. Ebben a cikkben megpróbáltunk kiemelni néhány árnyalatot a biztonsági mentési rendszer kiválasztásakor. Reméljük, segítik olvasóinkat.

Ennek eredményeként, amikor a projekthez biztonsági mentési rendszert választ, tesztelnie kell a kiválasztott biztonsági mentési típust, és figyelnie kell a következőkre:

• tartalék idő a projekt jelenlegi szakaszában;
• biztonsági mentési idő arra az esetre, ha sokkal több adat lenne;
• csatorna terhelés;
• betölti a lemez alrendszerét a szerveren és a tárolóban;
• ideje visszaállítani az összes adatot;
• egy pár fájl helyreállítási ideje;
• az adatok konzisztenciájának szükségessége, különösen az adatbázisok esetében;
• memóriafelhasználás és oom-killer hívások jelenléte;

Biztonsági mentési megoldásként használhatja a feltöltést és a felhőalapú tárhelyünket.
Azokat az olvasókat, akik nem tudnak itt megjegyzést írni, csatlakozzanak hozzánk a blogon.

Címkék: Címkék hozzáadása

2012.10.29. Michel Poulet

Az adatbázis-mentés a legegyszerűbb és legolcsóbb eszköz a vállalati adatok biztonságának biztosítására. Ne hagyja magát belenyugodni abba a hamis biztonságérzetbe, amely a legújabb magas rendelkezésre állású rendszer bevezetésével jár. Ha minden adatot virtualizálunk és konszolidálunk, a kockázatok még nőnek is

Michel Poulet ( [e-mail védett]) - az SQL Server Pro magazin szerkesztője, a Mount Vernon Data Systems és a Six Sigma Uptime társalapítója.

A legtöbb hosszú ideje működő vállalat katasztrofális eseményeket élt át, amelyek akár ki is sodorhatták volna őket, például adatbázishiba. Az adatbázis biztonsági másolata az adatbázisban található adatok, struktúrák és biztonsági objektumok másolata. Minden adatbázisról más ütemezés szerint kell biztonsági másolatot készíteni a napi írási tranzakciók száma alapján. Az adatbázis meghibásodása esetén a veszteségek minimalizálása érdekében biztonsági másolatot kell készíteni a vállalatban használt összes adatbázisról. Annak érdekében, hogy a biztonsági mentések működőképesek legyenek, ellenőrizze a működésüket a visszaállítási műveletek után. Minimálisan szükség van az adatbázisok gyors helyreállításra alkalmas másolataira, és magát a helyreállítási műveletet is ki kell dolgozni, és nem kell nehézséget okoznia.

Az alkalmazottak és az ügyfelek után a vállalatok legértékesebb vagyona az adatok. Az adatbázis adminisztrátor feladata, hogy gondoskodjon az adatok biztonságáról, hogy az adatbázis az adatközpont teljes megsemmisülése esetén is visszaállítható legyen. Az adatbázis-mentés a legegyszerűbb és legolcsóbb eszköz a vállalati adatok biztonságának biztosítására.

Ne hagyja magát belenyugodni abba a hamis biztonságérzetbe, amely a legújabb magas rendelkezésre állású rendszer bevezetésével jár. Ha minden adatot virtualizálunk és konszolidálunk, a kockázatok még nőnek is. Milyen egyszerű volt az élet, amikor egy számítógépen az adatbázis egyetlen példánya futott. Manapság általában több tucat SQL Server-példány fut egy kiszolgálón a virtuális gépekben, amelyek a fizikai szerver meghibásodása esetén egyszerre mind meghibásodnak. Ha a pénzeszközök megengedik, létrehozhat egy feladatátvételi fürtöt a virtuális gépek gazdagépeiből különböző fizikai kiszolgálókon. Ha magas rendelkezésre állásra van szükség, ezt általában megteszik. De még egy ilyen hibatűrő rendszer is sebezhető lehet például tűz, árvíz vagy földrengés esetén. A biztonsági mentések továbbra is szükségesek. Ugyanakkor a biztonsági másolatok készítését korlátozott számú személyre bízzák. További információért arról, hogy ki készíthet biztonsági másolatot, lásd a „Ki készíthet biztonsági másolatot?” oldalsávot.

Az adatbázis biztonsági mentésének gyakorisága attól függ, hogy mennyi ideig tart a biztonsági mentésből történő visszaállítása. Minél gyakrabban készül biztonsági mentés az adatbázisról, annál kevesebb időt vesz igénybe a visszaállítás. A biztonsági mentési és helyreállítási ütemezés minden adatbázishoz egyedileg konfigurálható. A foglalás típusa az adatbázis méretétől és az időegység alatt végrehajtott tranzakciók számától is függ. A biztonsági mentés fő típusai a teljes, naplós és növekményes mentések. A helyreállítási módokkal kapcsolatos további információkért tekintse meg az „Adatbázis-helyreállítási modellek” oldalsávot. Az SQL Server biztonsági mentési parancsait a „Standard Backup Commands” oldalsáv ismerteti.

Teljes foglalás

A teljes redundancia-stratégia a legkönnyebben megérthető és megvalósítható. Minden munkanap végén (vagy bármely más megjelölt időintervallumban) egyszerűen elindul egy teljes adatbázis-mentési eljárás (1. ábra). Ez nem igényel külön naplómentést, és nem igényel további beállításokat. A fájlkezelés ebben a biztonsági mentési módban szintén nem igényel különösebb figyelmet, mivel ez egyetlen teljes biztonsági mentési fájl. A teljes biztonsági másolatból való visszaállítás is nagyon egyszerű: csak egyetlen fájlból kell visszaállítania. A teljes biztonsági mentések használata jó választás a nem kellően tapasztalt informatikai személyzettel rendelkező szervezetek számára.

A teljes biztonsági mentés „kis” adatbázisokhoz a legalkalmasabb – nevezzük azokat az adatbázisokat, amelyekről a megadott időn belül biztonsági másolatot lehet készíteni. Amikor az SQL Server teljes adatbázis-mentést hajt végre, először az összes kiterjedést lemezre menti (egy terjedelem nyolc egymást követő oldal, egyenként 8 KB méretű). Az SQL Server ezután biztonsági másolatot készít a tranzakciós naplóról, így az adatbázisban a biztonsági mentés során esetlegesen bekövetkezett változások is a teljes biztonsági mentési fájlban kerülnek tárolásra.

Ha csak teljes biztonsági mentést hajt végre, akkor a rendszer összeomlása esetén bizonyos adatok elveszhetnek – elsősorban az utolsó biztonsági mentés óta végrehajtott módosítások. Ha az adatbázis-frissítések gyakorisága alacsony, például csak nagy sebességű tömeges műveleteket hajtanak végre, akkor a tömeges adatfrissítések után azonnal ütemezheti a teljes biztonsági mentést, amely esetben az adatok meglehetősen biztonságosnak tekinthetők.

A teljes redundancia nem alkalmas olyan termelési rendszerekre, amelyeket meglehetősen intenzíven frissítenek. Teljes biztonsági mentés használatakor, ha vissza kell állítania, újra le kell futtatnia az összes tranzakciót és tömeges adatbetöltést, amely a biztonsági mentés után történt. Ha az utolsó teljes biztonsági másolat megsérült, vissza kell állítania az előző biztonsági másolatot, és ismét manuálisan kell ellenőriznie, hogy a biztonsági mentés óta történt összes tranzakció alkalmazásra került-e.

Az adatbázis teljes biztonsági mentésének végrehajtásához futtassa a következő kódot:

BACKUP DATABASE AdventureWorks TO DISK = 'E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak'WITH INIT, NAME = 'AdventureWorks teljes Db biztonsági mentés', DESCRIPTION = 'AdventureWorks teljes adatbázis biztonsági mentése

A DISK paraméter határozza meg a cél biztonsági mentési fájlt. Biztonsági másolatot készíthet lemezre vagy szalagra (ebben az esetben lemezre). A biztonsági mentés megkezdése előtt győződjön meg arról, hogy létezik a biztonsági másolat tárolására szolgáló mappa. A legtöbb esetben a lemezre mentés sokkal gyorsabb, mint a szalagra, de a lemeztárolás költsége lényegesen magasabb. A további védelem érdekében készíthet biztonsági másolatot lemezre, majd mentheti a biztonsági másolatot szalagra. A WITH INIT beállítás megadja, hogy a biztonsági mentési fájlt felül kell írni. Ez a módszer akkor megfelelő, ha minden adatbázis-mentés után Windows biztonsági mentést készít. NÉV – tartalék név, legfeljebb 128 karakter. Ha nem ad meg nevet, a név mező üresen marad. A DESCRIPTION egy teljesebb és részletesebb leírás, amely segíthet például hosszú idő után rájönni, hogy milyen biztonsági mentésről van szó, és miért készült.

Az adatbázis teljes visszaállításához futtassa a következő parancsot:

ADATBÁZIS VISSZAÁLLÍTÁSA LEMEZRŐL AdventureWorks = ‘E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.BAK’ HELYREÁLLÍTÁSSAL, CSERÉLÉS

A WITH RECOVERY utasítja az SQL Servert, hogy szakítsa meg a tranzakciós naplóban esetlegesen szereplő függőben lévő tranzakciókat, és hagyja futni az adatbázist. A REPLACE azt jelenti, hogy felülírja az azonos nevű meglévő fájlokat. Erről részletesebben az „Adatbáziscsere” oldalsávban van szó.

Teljes biztonsági mentési stratégia használatakor figyelnie kell a tranzakciós naplófájl méretét. A teljes biztonsági mentés nem törli az inaktív bejegyzéseket a tranzakciós naplóból. Ha csak egy teljes adatbázis-mentést hajt végre, kövesse ezt a műveletet a naplófájl biztonsági mentésével és tisztításával. Ezt a TRUNCATE_ONLY beállításával teheti meg, az alábbi parancs szerint:

BIZTONSÁGI NAPLÓ Az AdventureWorks WITH TRUNCATE_ONLY

Ha a TRUNCATE_ONLY beállítás meg van adva, akkor ténylegesen nem történik naplómentés, ez arra utasítja az SQL Servert, hogy hozzon létre egy ellenőrzőpontot, tisztítsa meg az inaktív elemeket, és csökkentse a naplófájl méretét. Az SQL Server későbbi verziói megszüntették ezt a beállítást, de használhatja helyette az Egyszerű helyreállítási módot is, hogy az SQL Server automatikusan törölje az inaktív elemeket a tranzakciós naplóból.

Teljes biztonsági mentés naplómegőrzéssel

Ha nem tolerálja az adatvesztést a helyreállítás során, használhat teljes biztonsági mentési stratégiát hozzáadott naplóval. Ez a módszer megakadályozza az adatvesztést; gyakran frissített adatbázisokhoz alkalmas. Bár ez a stratégia megnöveli az üzemeltetési és karbantartási összetettséget, az adatbázis-mentésre fordított teljes idő csökken.

A 2. ábra egy példaütemezést mutat be egy teljes biztonsági mentéshez naplómegőrzéssel – heti teljes biztonsági mentés vasárnaponként, és a tranzakciós napló mentése minden következő napon a következő vasárnapig, amikor is a teljes biztonsági mentés újra megtörténik. A naplómentés menti az előző naplómentés óta végrehajtott összes módosítást. A vizsgált tervezési sémában a napi változtatások mentésre kerülnek.

Eltérő rendelkezés hiányában a napló biztonsági mentésének befejezése után a napló inaktív bejegyzései „eltávolításra kerülnek” (valójában felülírásra vannak jelölve). A BACKUP LOG parancs futtatásakor hozzáadhatja a NO_TRUNCATE vagy a COPY_ONLY paramétert, hogy a naplóbejegyzések ne módosuljanak a biztonsági mentés során. De nem javasoljuk ezeknek a lehetőségeknek a használatát, hacsak nem tudja biztosan, hogy mire lehet szüksége.

Az SQL Server 2005 rendelkezik egy tail-log biztonsági mentési móddal, vagyis az adatbázis-összeomlás utáni biztonsági mentéssel, ha a tranzakciós napló nem sérült. Ez a mód az utolsó naplómentés óta végrehajtott legutóbbi tranzakciókról készít biztonsági másolatot. Ezt a módot részletesebben a „Mik azok a tail-log backups” oldalsáv ismerteti.

A teljes helyreállítási modell használata viszonylag egyszerű visszaállítási élményt biztosít, és ez az előnyben részesített lehetőség teljes naplómentés végrehajtásakor. Ez visszaállítja az utolsó teljes biztonsági másolatot, majd sorrendben visszaállítja a meglévő naplókat időrendi sorrendben (a létrehozásuk sorrendjében), és végül visszaállítja a napló utolsó részét. Ez a stratégia alkalmas termelési rendszerekre, különösen akkor, ha azok tranzakciós és kevés tömeges művelettel rendelkeznek.

Ha az adatbázis rendszeres tömeges frissítéseket tapasztal, érdemes lehet tömegesen naplózott helyreállítási modellt használni. Mivel a tömeges műveletben szereplő egyedi rekordok ebben az esetben nem kerülnek naplózásra, ez a megközelítés csökkenti az SQL Server naplózási többletköltségét. Bár a tömeges műveletek végrehajtása során észrevehető teljesítménynövekedést tapasztalhat, fennáll az adatvesztés veszélye a helyreállítás során, ha a tömeges műveletek újraindításához szükséges forrásadatok már nem állnak rendelkezésre a helyreállítás időpontjában. Az egyszerű helyreállítási modell használatakor a naplómentés szintén nem lehetséges, mert az ellenőrzőponttá csonkolja a naplót.

A teljes naplómentés végrehajtásához először biztonsági másolatot kell készítenie a teljes adatbázisról, az alábbi példa szerint:

BACKUP DATABASE AdventureWorks TO DISK = 'E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak' WITH INIT, NAME = 'AdventureWorks teljes Db biztonsági mentés', DESCRIPTION = 'AdventureWorks teljes adatbázis biztonsági másolat'

Ezután végre kell hajtania a napló biztonsági mentését a következő paranccsal:

BACKUP LOG AdventureWorks TO DISK = 'E:\SQLdata\BACKUPS\AdventureWorks_TlogBkup.bak' WITH NOINIT, NAME = 'AdventureWorks Translog backup', DESCRIPTION = 'AdventureWorks tranzakciós napló biztonsági mentése', NOFORMAT

Az utolsó parancs WITH NOINIT opciója azt határozza meg, hogy a biztonsági mentési fájlt hozzáfűzés módban kell írni meglévő adathordozóra, lemezre vagy szalagra. Ebben az esetben az összes tranzakciós napló biztonsági másolata egymás után ugyanabba a fájlba kerül. A NOFORMAT arra utasítja a biztonsági mentési folyamatot, hogy őrizze meg a fejlécekben lévő biztonsági mentési lemezeken található összes fejlécinformációt. Ez az alapértelmezett, és ennek a beállításnak a konkrét megadása nem kötelező, de hasznos öndokumentáló műveletként.

Ha vissza szeretne állítani egy teljes biztonsági másolatból vagy egy teljes biztonsági másolatból naplózás megőrzésével, kövesse az alábbi lépéseket.

1. Ha az adatbázis online, korlátozza a hozzáférést úgy, hogy a hozzáférési módot (a tulajdonságok ablakában) RESTRICTED_USER értékre állítja. Ezzel csak a db_owner adatbáziscsoport tagjai, valamint a dbcreator és sysadmin kiszolgálócsoportok tagjai érhetik el az adatbázist.
2. Javítsa ki az adatbázis összeomlását okozó hibát.
3. Ha lehetséges, alkalmazza az összes mentett tranzakciós naplót a NORECOVERY opcióval.

A faroknapló biztonsági mentésének végrehajtásához futtassa a következő parancsot:

BACKUP NAPLÓ AdventureWorks TO DISK = 'E:\SQLdata\BACKUPS\AdventureWorks_TaillogBkup.bak' NORECOVER-lel

A teljes biztonsági másolatból való teljes visszaállításhoz először vissza kell állítania az adatbázisfájlokat a következő paranccsal:

ADATBÁZIS VISSZAÁLLÍTÁSA Az AdventureWorks LEMEZRŐL = 'E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak' NORECOVERY-VEL

A NORECOVERY paraméter azt mondja az SQL Servernek, hogy a részleges tranzakciókat úgy kell hagyni, ahogy vannak, anélkül, hogy megkísérelné visszagörgetni őket. A tranzakciós naplók ezt követő visszaállítása visszaállítja az adatokat, amelyek lehetővé teszik a részleges tranzakciók befejezését. A NORECOVERY opció használatával az adatbázis használhatatlan állapotba kerül. A teljes visszaállítást követően azonnal vissza kell állítani az összes tranzakciós napló biztonsági másolatát a NORECOVERY opcióval, az alábbiak szerint:

NAPLÓ VISSZAÁLLÍTÁSA AdventureWorks FROM DISK = 'E:\SQLdata\BACKUPS\AdventureWorks_TlogBkup.bak' NORECOVERY-VEL

Végül állítsa vissza a végső töredéket a RECOVERY paraméterrel:

NAPLÓ VISSZAÁLLÍTÁSA AdventureWorks FROM DISK = 'E:\SQLdata\BACKUPS\AdventureWorks_TaillogBkup.bak' HELYREÁLLÍTÁSSAL

A teljes helyreállítási stratégia napló-helyreállítással nem jelent abszolút védelmet. Ha az egyik naplómentés megsérül, a helyreállítás csak a sérült napló előtti pontig lehetséges. Tegyük fel például, hogy a heti teljes biztonsági mentés vasárnaponként, a naplózás pedig hétfőtől szombatig történik. Ha a keddi biztonsági mentés megsérül, akkor csak a hétfői adatok állíthatók vissza: valószínűleg nem éri meg az adatintegritás sérelmét a szerdai tranzakciók hétfői adatokra történő alkalmazása. És a végső töredék visszaállítása sem fog semmit tenni.

Teljes plusz differenciális redundancia

Azokban az esetekben, amikor további garanciális szintre van szükség, a naplómentés mellett differenciált biztonsági mentés is hozzáadható a tervhez. Ez a stratégia olyan tranzakciós adatbázisokhoz alkalmas, ahol a rekordok gyakran kerülnek hozzáadásra, a helyreállítás során az adatvesztés nem tolerálható, és a rendszergazdák a gyors helyreállítást részesítik előnyben.

A differenciális biztonsági mentés kumulatív jellegű – minden olyan adatot és struktúrát magában foglal, amely az utolsó teljes biztonsági mentés óta megváltozott, függetlenül attól, hogy az utolsó teljes biztonsági mentés mikor történt, vagy hogy a differenciális biztonsági mentést hányszor hajtották végre azóta. Tegyük fel, hogy a teljes biztonsági mentést vasárnap, a differenciális mentést pedig minden nap végezték el, amint az a 3. ábrán látható. A hétfői differenciálmásolat minden hétfőn, a keddi differenciálmásolat a hétfőn és kedden végrehajtott módosításokat tartalmazza. , a szerdai differenciálpéldány pedig a hétfői, keddi és szerdai változásokat fogja tartalmazni.

3. ábra: A differenciális biztonsági mentési feladatok ütemezése

A differenciális biztonsági másolat visszaállítása általában kevesebb időt vesz igénybe, mint a teljes biztonsági mentés és a naplók visszaállítása, mivel gyorsabban lehet visszaállítani egyetlen különbségi másolatot, mint egy naplóláncot. A differenciális biztonsági mentés mentése a következő paranccsal történik:

BACKUP DATABASE AdventureWorks TO DISK = 'E:\SQLdata\BACKUPS\AdventureWorks_DiffDbBkup.bak' WITH INIT, DIFFERENTIAL, NAME = 'AdventureWorks Diff Db backup', DESCRIPTION = 'Backup Differential Database'Works

Ha vissza szeretne állítani egy adatbázist differenciális biztonsági másolatból, kövesse az alábbi lépéseket.

1. Ha az adatbázis online, korlátozza a hozzáférést úgy, hogy a hozzáférési módot (a tulajdonságok ablakában) RESTRICTED_USER értékre állítja. Ez csak a db_owner adatbáziscsoport tagjai, valamint a dbcreator és sysadmin kiszolgálócsoportok tagjai számára teszi lehetővé az adatbázishoz való hozzáférést.
2. Végezzen biztonsági mentést.
3. Javítsa ki azt a hibát, amely az adatbázis összeomlását okozta.
4. Teljes biztonsági másolat visszaállítása a NORECOVERY opcióval.
5. Állítsa vissza az utolsó elérhető differenciálmentést a NORECOVERY opcióval.
6. Állítson vissza egy tail-log biztonsági másolatot a RECOVERY opcióval.

A differenciális biztonsági mentés visszaállításához (a teljes biztonsági másolat visszaállítása után hajtsa végre) írja be a következő parancsot:

ADATBÁZIS VISSZAÁLLÍTÁSA Az AdventureWorks LEMEZRŐL = ‘E:\SQLdata\BACKUPS\AdventureWorks_DiffDbBkup.bak’ NORECOVERY-VEL

Ezután állítsa vissza a végső naplórészletet a RECOVERY opcióval a korábban bemutatott paranccsal.

A differenciális biztonsági mentés magasabb szintű adatintegritást biztosít, mint a naplómentés önmagában. Ha a legutóbbi differenciális biztonsági másolat megsérül, visszaállíthatja a korábbi differenciál biztonsági másolatot, és továbbra is megőrizheti az adatok integritását.

A stratégia kombinálása

Ha a tranzakciók újrafuttatása az utolsó napi tranzakciók helyreállítása érdekében nem praktikus, végezhet egy teljes biztonsági mentést vasárnap, egy differenciális biztonsági mentést minden következő éjszaka, és egy tranzakciónapló biztonsági mentést hétfőtől szombatig reggel és este, az ábra szerint. 4. Ha péntek este az adatbázissal Ha adatkatasztrófa van, és a csütörtöki differenciális biztonsági mentés megsérült, akkor visszaállíthatja a szerdai differenciális biztonsági mentést, majd csütörtöktől és péntektől alkalmazhatja a naplókat. Így az adatbázis a meghibásodás pillanatáig helyreáll. Ezt a problémát részletesebben a „Hogyan lehet visszaállítani egy adatbázist egy adott időpontra” oldalsáv tárgyalja.

Az adatvesztés kockázatának csökkentése érdekében vegyes stratégiát kell alkalmaznia, amely magában foglalja a teljes biztonsági mentést, a naplózási mentést és a differenciális biztonsági mentést, bár ez a keverék némileg bonyolultabbá teszi a biztonsági mentési stratégiát és a biztonsági mentés kezelését. Azt is értékelnie kell, hogy mennyi adat veszíthet el adatbázishiba és helyreállítás után. A teljes helyreállítási stratégia vagy a tömeges naplózási modell használata az egyszerű visszaállítás helyett több tranzakciós naplófájlt terhel, és nagyobb biztonsági mentési fájlokat eredményez, de nagyobb adatintegritást biztosít.

Alternatív foglalási stratégiák

Az SQL Server biztonsági mentése nem korlátozódik a teljes, differenciális és tranzakciós naplóra. Az összetettebb stratégiák közé tartozik a fájlok vagy fájlcsoportok biztonsági mentése, a részleges biztonsági mentési stratégia és a csak másolásra szolgáló biztonsági mentés.

Adatbázis-hozzáférés a biztonsági mentés és a visszaállítás során

Az SQL Server-adatbázis biztonsági mentése online folyamat. Az SQL Serverben tárolt összes adat elérhető a biztonsági mentés során. Az adatbázis-módosítási műveletek, az INSERT, UPDATE és DELETE utasítások az adatok kiválasztásához (SELECT) hasonlóan érhetők el. Az adatbázis- vagy fájlstruktúra nem módosítható biztonsági mentés közben – az ALTER DATABASE, ADD FILE vagy SHRINKFILE utasítások nem hajthatók végre biztonsági mentés közben. Ha az adatbázis automatikus zsugorításra van állítva, ütközés léphet fel a biztonsági mentés futása közben. Tehát, ha a biztonsági mentési folyamat során elindul az adatbázisfájl automatikus csökkentése, akkor mindkét művelet meghiúsulhat. Az elsőként induló művelet zárolja a fájlt, a következő műveletnek pedig várnia kell a zárolás feloldására. Ha az első művelet feloldja a zárat, a második művelet megkezdődik. Ha az első művelet blokkolása időtúllépéssel jár, a második művelet sikertelen lesz. Ez a megközelítés helytelennek tűnhet a második művelet végrehajtása szempontjából, amely kénytelen megvárni a meghibásodást, és csak azután ad ki hibát. De ha figyelembe vesszük, hogy a második művelet munkája az első sikerétől függ, ha az első művelet során hiba történik, akkor a második művelet végrehajtásának nincs értelme. A probléma megelőzése érdekében a biztonsági mentés előtt le kell tiltani az adatbázisfájl automatikus zsugorítását.

A legtöbb esetben az SQL Server-adatbázis visszaállítása offline művelet, amely során a felhasználó nem férhet hozzá az adatbázishoz. Ha az SQL Server 2005 Enterprise Editiont teljes helyreállítási modellel használja, a részleges helyreállítás és a kisebb fájlcsoportok helyreállítása alapértelmezés szerint online művelet. Az adatbázis azon részei, amelyeket nem kell visszaállítani, például a csak írási hozzáféréssel rendelkező fájlcsoportok, a visszaállítási művelet időtartama alatt elérhetők a felhasználók számára. A fájlcsoportok olvashatók/írhatók, kivéve, ha a helyreállítás céljából offline állapotba kerültek. Ez a funkció nagyon hasznos nagyméretű, 24x7x365-ös adatbázisok esetén. További információkért tekintse meg az SQL Server 2005 BOL dokumentációját: „Online visszaállítások végrehajtása” (http://msdn.microsoft.com/en-us/library/ms188671.aspx) és a „Why Database Restores Fail” oldalsávban ."

Foglaljuk össze

Az adatok nagyon fontosak az üzleti életben, ezért biztonságuk biztosítása az egyik legfontosabb feladat. Az adatok biztonsági mentése fontos szerepet játszik ebben a folyamatban. Az adatokhoz való folyamatos hozzáférés biztosításának első lépése az adatbázisok rendszeres biztonsági mentésének és teszt-helyreállításának rendszerének létrehozása. Amikor új adatbázist hoz létre, azonnal létre kell hoznia a biztonsági másolatot és vissza kell állítania a parancsfájlokat. Az SQL Server számos biztonsági mentési és helyreállítási lehetőséget kínál, amelyek az Ön egyedi adatbázis-szükségleteihez szabhatók.

Ki foglalhat helyet?

Az adatbázis biztonsági mentése korlátozott számú ember számára elérhető. Alapértelmezés szerint bizonyos kiszolgálói rendszergazdai csoportok tagjai, valamint a db_owner és db_backupoperator adatbázis-szerepkörök jogosultak az engedélyekre. Biztonsági mentési eszközök, lemezek vagy szalagok használatakor ügyelni kell arra, hogy ki a tulajdonos és milyen engedélyek vannak beállítva. Az SQL Servernek képesnek kell lennie az eszköz olvasására és írására. Ha a fiók, amelyen az SQL Server fut, nem rendelkezik engedélyekkel az eszköz eléréséhez, ezt csak akkor fogja tudni, ha a biztonsági mentési vagy visszaállítási művelet meghiúsul. Az sp_addumpdevice tárolt eljárás, amely egy biztonsági mentési eszköz bejegyzést ad a rendszertáblákhoz, nem végez fájlszintű engedély-ellenőrzést.

Megadhat jelszót a biztonsági másolat létrehozásához. Ebben az esetben az adatbázis visszaállításakor jelszót is meg kell adni. A jelszavas védelem egy opcionális intézkedés, amelyet egyébként megbízhatatlannak tartanak. A jelszavas védelmet arra használják, hogy megakadályozzák az adatok helyreállítását illetéktelen személyek által, akik nem ismerik a vállalat biztonsági mentési/visszaállítási szabályzatát. Mivel a jelszó megadásakor az adatok nincsenek titkosítva, ez az intézkedés nem akadályozza meg a biztonsági mentési adatok speciális eszközökkel történő olvasását. Ezenkívül a jelszó nem akadályozza meg a biztonsági mentési fájl felülírását vagy törlését.

Adatbázis-helyreállítási modellek

A helyreállítási modell beállítása határozza meg, hogy adatbázis-összeomlás esetén mennyi adatot lehet helyreállítani. Minden adatbázisnak saját helyreállítási modellje lehet, attól függően, hogy mekkora adatvesztést hajlandó elviselni. Adatbázis-helyreállítási modell SQL Server Management Studio (SSMS) használatával történő beállításához kattintson a jobb gombbal a kívánt adatbázisra, nyissa meg a Tulajdonságok ablakot, lépjen a Beállítások oldalra, és válassza ki a kívánt biztonsági mentési modellt a legördülő listából.

Háromféle helyreállítási modell létezik: teljes, egyszerű és tömegesen naplózott. A teljes helyreállítási modell teljes mértékben kihasználja a tranzakciós napló összes képességét, és lehetővé teszi az adatbázis nagy pontosságú visszaállítását egy adott időpontban. Minden művelet, például adattranzakciók, adatbázis szerkezeti módosítások, működési utasítások, például tranzakció befejezése vagy törlése, nagy objektumok és tömeges műveletek egy naplóban tárolódnak. A tranzakciós napló mindaddig frissül, amíg a tranzakciós napló biztonsági mentése be nem fejeződik.

Az egyszerű helyreállítási modell minimálisan használja a tranzakciós naplót, és lehetővé teszi az utolsó teljes adatbázis-mentés visszaállítását. A teljes helyreállítási modellhez hasonlóan minden tranzakció (egyes kötegelt tranzakciók kivételével) egy naplóban tárolódik. A teljes helyreállítási modelltől eltérően az SQL Server automatikusan törli a fel nem használt elemek naplóját. Emiatt az egyszerű helyreállítási modell használatakor nem készíthet biztonsági másolatot a tranzakciós naplóról.

A tömegesen naplózott helyreállítási modell valahol a teljes és az egyszerű helyreállítási modellek szélsőségei közé esik. Bár a tömeges naplózás elnevezés a tömeges tranzakciók naplózására gondolhat, a valóságban ezek csak részben kerülnek naplózásra. A tömeges műveletek során, amelyek gyakran nagy számú rekord hozzáadásával járnak rövid időn belül, az SQL Server beállít egy bitjelzőt minden egyes, a frissítés által érintett adatbázis kiterjedésén, de a beillesztett rekordok valójában nem kerülnek hozzáadásra a naplófájlhoz. Egy későbbi tranzakciós napló biztonsági mentése során az SQL Server ellenőrzi ezt a jelzőt, és a szokásos beszúrási és törlési rekordokon kívül beírja a tranzakciós napló biztonsági másolatába a tömeges művelet által módosított tényleges adatbázis-terheket. Ezért a tömeges naplózott helyreállítási modell naplómentése a tömeges műveletek eredményeit tartalmazza, nem pedig a ténylegesen befejezett egyedi tranzakciókat.

A tömegesen naplózott helyreállítási modell használata ugyanolyan teljességet biztosít, mint a teljes helyreállítási modell, de az összes tömeges adatbeszúrás biztonsági mentésével járó többletköltség nélkül. A tömegesen naplózott helyreállítási modell használata azonban kockázatokkal jár. Ha elveszíti egy tömeges művelet forrásadatait a biztonsági mentési műveletek között, az adatbázis teljes helyreállítása nem lehetséges. Ezenkívül nem lehet egy adott időpontra visszaállítani egy adatbázist a végnapló biztonsági másolatából – a visszaállítási kísérlet sikertelen lesz.

Bár a teljes és tömeges helyreállítási modellek nagyobb tranzakciós naplótevékenységet és nagyobb biztonsági mentési fájlméretet foglalnak magukban, ezt kompenzálja a teljesebb adat-helyreállítás adatbázis-hiba esetén.

Szabványos parancsok a foglaláshoz

Az SQL Server 2005 és az SQL Server 2000 két parancsot tartalmaz, amelyek lényegében ugyanazt végzik: DUMP és BACKUP (vagyis DUMP DATABASE vagy BACKUP DATABASE és DUMP LOG vagy BACKUP LOG). A DUMP parancs az SQL Server 6.5 óta létezik, amikor egy adatbázis biztonsági mentése egyszerűen azt jelentette, hogy az adatbázist abba az állapotba másolták, amelyben a mentési művelet megkezdése előtt volt. Ugyanakkor a biztonsági másolatban nem szerepeltek azok az adatbázisban bekövetkezett változások, amelyek a mentés megkezdése után következhettek be.

A 7-es verziótól kezdődően az SQL Server valódi "dinamikus" biztonsági mentéseket tud végezni, ami azt jelenti, hogy a biztonsági mentési folyamat megkezdése után végrehajtott módosítások a tranzakciós naplóba kerülnek, és a biztonsági mentési fájlban tárolódnak. Így a biztonsági másolat az adatbázis „pillanatfelvétele” a mentési művelet befejezésekor. A DUMP parancs megmarad a visszamenőleges kompatibilitás érdekében, de a Microsoft nem javasolja annak használatát a fejlesztés alatt álló új rendszereken. Egyszer ez a parancs megszűnik, és a fejlesztőknek meg kell szabadulniuk tőle azokban a kódrészletekben, ahol még mindig használják.

Azok számára, akik mindig is óvatosak voltak az SQL Server-adatbázisok biztonsági mentésével, és szívesen megismerkedtek az SQL Server 2005 újdonságaival, továbbra is fokozottan ügyeljenek a biztonsági mentésekre: az SQL Server 2005-ben nem található az ismerős DBCC REPAIR parancs. A parancs „helyettesítése” a DROP DATABASE.

Az adatbázis cseréje

Amikor adatbázist állít vissza egy új kiszolgálóra, használja a REPLACE beállítást, amely letiltja a normál biztonsági ellenőrzéseket, és lehetővé teszi a meglévő adatbázisok felülírását, még akkor is, ha a név eltér a visszaállítandó adatbázis nevétől. Tegyük fel például, hogy az A kiszolgálón található D adatbázisról készült biztonsági másolat. Ezt a biztonsági mentést vissza kell állítani a B kiszolgálón. Először is létre kell hozni egy üres átmeneti adatbázist a B kiszolgálón, és az adatbázis neve és mérete nem ügy. Ezután vissza kell állítania a D adatbázist a REPLACE paraméterrel a B kiszolgálón az újonnan létrehozott köztes adatbázis tetején. Ha a visszaállítást vissza kell hajtani az A kiszolgálóra, annak eredeti helyére, a REPLACE paraméter nem szükséges. Alapértelmezés szerint az adatbázis-visszaállítási művelet beépített biztonsági ellenőrzéseket hajt végre, például amikor az adatbázis-visszaállítás általában nem hajtható végre egy másik meglévő adatbázison. Hasonlóképpen tilos a teljes vagy tömeges naplózási mentési móddal mentett adatbázis visszaállítása, ha nem áll rendelkezésre biztonsági mentés.

Ha olyan adatbázist kell helyreállítania, amely valamilyen okból nem tartalmazott faroknapló biztonsági másolatot (például azért, mert a tranzakciónapló biztonsági mentési fájlja sérült), akkor a REPLACE mód lehet az egyetlen módja a sikeres helyreállításnak. Egy másik példa, ahol szükség van a REPLACE paraméterre, ha egy éles adatbázis biztonsági másolatát vissza kell állítani egy teszt- és fejlesztőkörnyezetben. Még akkor is, ha az éles környezetben és a fejlesztői környezetben az adatbázisnevek megegyeznek, az SQL Server szempontjából ezek különböző adatbázisok.

Mik azok a faroknapló biztonsági mentései?

A végnapló biztonsági mentése egy új biztonsági mentési mód az SQL Server 2005-ben. Ez a mód hozzáfűzi azokat a tranzakciós naplórekordokat, amelyek a naplófájl legutóbbi biztonsági mentése óta kerültek a biztonsági mentéshez. Amikor egy adatbázist a meghibásodás helyéről próbál meg helyreállítani, a helyreállítás megkezdése előtt végezzen biztonsági mentést a végszegmensről. Ez utóbbi biztonsági mentést nem szükséges elvégezni, ha az adatbázist az utolsó tranzakciónapló-mentés előtti pontra kívánja visszaállítani, vagy ha az adatbázist egyik kiszolgálópéldányról a másikra helyezi át, vagy ha felülírja az adatbázist. Előfordulhat, hogy a tranzakciós napló megsérült, ebben az esetben a végtöredékről nem lehet biztonsági másolatot készíteni, és a helyreállítást nélküle kell végrehajtani.

Hogyan lehet visszaállítani egy adatbázist egy adott időpontra

Előfordulhat olyan helyzet, amikor hibás kódvégrehajtás miatt adatbázis-visszaállítást kell végrehajtania – például valaki tévedésből törölt egy táblát egy éles adatbázisban, vagy elfelejtett beilleszteni egy WHERE záradékot a DELETE záradékba. Ilyen esetekben vissza kell állítani az adatbázist a hibás kód végrehajtása előtti állapotba.

A helyreállítás olyan műveletek összessége, amelyek az adatbázist konzisztens állapotba hozzák. Az adatbázis egy adott időpontra történő visszaállításához teljes vagy részleges naplózási visszaállítást kell végrehajtania. Az egyszerű helyreállítási modell azt eredményezi, hogy levágja a tranzakciós naplót egy ellenőrzési pontra anélkül, hogy az újra-visszavonás lehetősége és egy adott időpontra való visszaállítás lehetősége nélkül lenne.

A helyreállítási műveletek végrehajtása, amelyeket a „módosítások ismétlése/visszavonása” követ, magában foglalja az adatok eredeti állapotának visszaállítását egy adott felhasználó által megadott időpontban – a befejezett tranzakció nevével vagy a naplóban szereplő sorszámmal. A tömegesen naplózott helyreállítási modell további korlátja, hogy a pont-időben történő helyreállítás csak akkor lehetséges, ha az előző naplómentés óta nem hajtottak végre tömeges műveletet. Más szavakkal, a sikeres pont-időben történő helyreállítás megköveteli, hogy a naplómentési fájlok sorrendje folyamatos legyen.

A visszaállítandó pont-időbeli adatoknak szerepelniük kell egy tranzakciós napló biztonsági másolatában. Napló visszaállításakor visszaállíthatja az adott időpontig lezajlott tranzakciókat, ha megadja az időpontot a STOPAT, STOPATMARK vagy STOPBEFOREMARK utasítással.

Amikor egy adatbázist egy adott időpontra állít vissza, végezzen teljes biztonsági mentést a NORECOVERY beállítással, az alábbiak szerint:

ADATBÁZIS VISSZAÁLLÍTÁSA Az AdventureWorks FROM DISK = "E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak" A NORECOVERY-VEL

Ezután alkalmazza az összes naplómentést a RECOVERY beállítással, és adja meg a kívánt időpont dátumát és időpontját minden RESTORE LOG záradékban:

NAPLÓ VISSZAÁLLÍTÁSA AdventureWorks FROM DISK = "E:\SQLdata\BACKUPS\AdventureWorks_TlogBkup.bak" HELYREÁLLÍTÁSSAL, STOPAT = ‘2007. december 10. 20:10’

Fájlok/fájlcsoportok biztonsági mentése

Ez a biztonsági mentési stratégia csak akkor megfelelő, ha az adatbázis több fájlból vagy fájlcsoportból áll. Ha az adatbázis méretére vagy teljesítményére vonatkozó követelmények lehetetlenné teszik az adatbázis teljes biztonsági mentését, és meghibásodás esetén gyors helyreállításra van szükség, érdemes lehet fontolóra venni a fájl/fájlcsoport biztonsági mentési stratégiáját.
Ez a stratégia SQL Server 2005 vagy SQL Server 2000 esetén használható, és minden műveletnél meg kell adni, hogy mely fájlokról, fájlcsoportokról vagy kombinációkról készül biztonsági mentés. Mindazonáltal nem sokkal a létrehozás után végre kell hajtania egy teljes adatbázis-mentést, amelyet a fájlok vagy fájlcsoportok rendszeres biztonsági mentése követ. Ha egy adott adatbázishoz az egyszerű helyreállítási modellt szeretné használni, akkor az összes olvasható/írható fájlról és fájlcsoportról egyidejűleg biztonsági másolatot kell készíteni. A helyreállítás során bekövetkező adatvesztés minimalizálása érdekében válasszon egy teljes vagy tömeges naplózású helyreállítási modellt, és vegye fel a stratégiájába a tranzakciónapló biztonsági másolatát.
Az adatbázis visszaállítása továbbra is az adatbázishoz való hozzáférés korlátozását jelenti, de rövidebb ideig, mint az adatbázis teljes helyreállítása esetén. A helyreállítás során a hozzáférés csak az éppen visszaállítás alatt álló fájlcsoportokra korlátozódik.
A legrosszabb esetben, ha vissza kell állítania a teljes adatbázist, és a teljes helyreállítási modellt használja, akkor az adatbázis létrehozása óta szükség lesz az összes tranzakciós napló biztonsági másolatára. Ezen túlmenően, ha egy adott időpontban vissza kell állítania az adatbázist, akkor a tranzakciónaplók teljes készletére lesz szüksége.

Részleges helyreállítás

Ez az SQL Server 2005-ben bevezetett stratégia olyan adatbázisokhoz készült, amelyek több csak olvasható fájlcsoporttal rendelkeznek, és egyszerű helyreállítási modellt használnak. Mivel az ilyen típusú adatbázisok elsősorban csak olvashatóak, a teljes biztonsági mentési és teljes visszaállítási stratégiák redundánsak. A frakcionált redundancia modell azonban bármilyen típusú adatbázisra alkalmazható.

Amikor részleges biztonsági mentést végez, először a fő fájlcsoportról, az összes írható/olvasható fájlcsoportról és a megadott írásvédett fájlcsoportokról készít biztonsági másolatot. Mivel a csak olvasható táblák nem változnak gyakran, elméletileg nem kell olyan gyakran biztonsági másolatot készíteni róluk, mint a változtatásoknak kitett táblákról.

A töredékes redundancia beállítása előtt gondos tervezésre van szükség. Adatbázis létrehozásakor különféle fájlcsoportokat kell létrehozni, táblák készítésekor pedig kifejezetten a megfelelő fájlcsoportokba kell helyezni azokat. Így az adatbázis-könyvtártáblák az elsődleges fájlcsoportban, az írásvédett táblák a csak olvasható fájlcsoportokban, az író-olvasható táblák pedig az írható/olvasható fájlcsoportokban találhatók.

A részleges biztonsági mentések csökkenthetik az adatbázis teljes visszaállításához szükséges időt. Ha a teljes adatbázis csak olvasható, akkor csak a fájlok elsődleges csoportja kerül bele a részleges biztonsági mentésbe, hacsak másként nem ad meg. Ezenkívül egy részleges másolat is használható a teljes másolat helyett a differenciális biztonsági mentés alapjaként. A töredékes redundancia további lehetőségeket és nagyobb rugalmasságot biztosít a redundancia-stratégia kiválasztásában.

A részleges biztonsági mentésből történő helyreállítás továbbra is magában foglalja az adatbázishoz való hozzáférés korlátozását, de rövidebb ideig, mint a teljes adatbázis-helyreállítás – és csak az elsődleges fájlcsoport, az írási/olvasási csoportok és a csak olvasható csoportok esetében, amelyek a biztonsági mentés részét képezték. . További információkért tekintse meg az SQL Server 2005 Books Online „Partial Backups” című dokumentációját: http://msdn.microsoft.com/ru-ru/library/ms191539.aspx.

Állami biztonsági mentések

Néha speciális feladatokhoz kell foglalni, például egy prezentáció létrehozásához, amelyet meg kell mutatni az ügyfélnek. Azonban nem kívánja megzavarni az adatbázis visszaállításához szükséges fájlok normál sorrendjét. Ebben az esetben kihasználhatja azt a lehetőséget, hogy biztonsági másolatot készítsen az adatbázis állapotáról. Egy ilyen másolat létrehozható függetlenül attól, hogy melyik adatbázis-helyreállítási stratégiát használjuk – teljes, tömeges másolat vagy egyszerű (tömeges másolás vagy egyszerű).

De az állami biztonsági mentéseket nem szabad a helyreállítási stratégia részévé tenni. Létrehozhat másolatot az állapotról, visszaállíthatja belőle az adatbázist a demólaptopon, majd biztonságosan törölheti a biztonsági másolat fájlját. Más "normál" biztonsági mentések semmilyen módon nem függenek az állapotmásolatoktól, így a visszaállítás során nem lesz szükség állapotmásolatokra.

Az állapotfoglalási stratégia nem használható a differenciális lefoglalások alapjaként, mert az állapotmásolat létrehozása nem frissíti a differenciális bittérképet, amely meghatározza, hogy melyik kiterjedést kell másolni és melyiket kell megtartani. A valóságban a differenciált másolási eljárás nem veszi figyelembe az állapot másolatait, amelyek készültek, így az ilyen másolatok nem vehetnek részt a különbözeti helyreállítási folyamatban.

Amikor biztonsági másolatot készít az adatbázis állapotának tranzakciós naplójáról, a tranzakciónapló nem csonkolódik, ellentétben a normál biztonsági mentéssel. Az állapotmentés szintén nincs hatással a helyreállítási naplóval rendelkező teljes biztonsági mentéshez használt naplóláncra. Az állapotmentések visszaállításkor egyáltalán nem szerepelnek a naplómentések listájában. További információkért tekintse meg az SQL Server 2005 BOL "State Backups" dokumentációját a http://msdn.microsoft.com/en-us/library/ms191495.aspx címen.

Miért nem hajtható végre online az adatbázis-helyreállítás?

A biztonsági mentés rendszergazdáit gyakran kérdezik, hogy miért tiltják le az adatbázishoz való hozzáférést az adatbázis-visszaállítás során. Valójában az elvégzett helyreállítás típusától függően részleges adathozzáférés is lehetséges. Az általános szabály az, hogy az automatikus helyreállítás alá eső fájlok, fájlcsoportok vagy oldalak offline állapotba kerülnek, mert ez szükséges a helyreállítási műveletek sikeres befejezéséhez.

A helyreállítási folyamat általában az adatok, naplók és indexoldalak biztonsági mentési adathordozóról az adatbázisfájlokba másolásával kezdődik. Ezután jön az újravégrehajtás fázisa – a naplóba mentett tranzakciók alkalmazása az adatbázis-mentéskor mentett adatokra; ezt a folyamatot gyakran „ismétlődő változásnak” nevezik. Ezek a naplózott tranzakciók az adatbázisban a hiba előtti utolsó adatbázis-mentés óta bekövetkezett változásokat jelentik. Az SQL Server először a tranzakciónaplóba másolja az adatokat és a szerkezeti változtatásokat, majd végrehajtja ezeket a változtatásokat a tényleges adatbázison. A módosítások újrajátszása biztosítja, hogy a naplóban végrehajtott módosítások alkalmazásra kerüljenek az adatbázisban.

Ebben a szakaszban az adatbázis általában függőben lévő tranzakciókat tartalmaz, és az adatbázishoz nem lehet hozzáférni. Ezután az SQL Server 2005 Standard Edition az utolsó visszaállítási fázisba lép, amely minden függőben lévő tranzakciót visszaállít. Miután ez a fázis befejeződött, az adatbázis teljesen helyreáll, és használatra kész. Az Enterprise Edition egy kicsit másképp működik - az adatbázis azonnal használatra kész a változtatások megismétlése után, anélkül, hogy megvárná a függőben lévő tranzakciók törlési szakaszát.

A fájlokhoz, fájlcsoportokhoz és oldalakhoz való hozzáférés megtagadva az adatbázis-helyreállítás és a visszaállítási/visszagörgetési fázis során, mert a visszakereshető adatok érvénytelenek. A piszkos adatok feldolgozásának kísérlete problémákat okozhat az elmulasztott és hiányos tranzakciókkal.

Az új szerver működésre való felkészítése a biztonsági mentés beállításával kezdődik. Úgy tűnik, mindenki tud erről – de néha még a tapasztalt rendszergazdák is elkövetnek megbocsáthatatlan hibákat. És itt nem csak az a lényeg, hogy nagyon gyorsan meg kell oldani egy új szerver beállítását, hanem az is, hogy nem mindig egyértelmű, melyik mentési módszert érdemes használni.

Természetesen lehetetlen olyan ideális módszert alkotni, amely mindenkinek megfelelne: mindennek megvan a maga előnye és hátránya. Ugyanakkor meglehetősen reálisnak tűnik egy olyan módszer kiválasztása, amely a legjobban megfelel egy adott projekt sajátosságainak.

A biztonsági mentési módszer kiválasztásakor először a következő kritériumokra kell figyelnie:

1. A tárhelyre mentés sebessége (ideje);
2. A biztonsági másolatból való visszaállítás sebessége (ideje);
3. Hány példány tárolható korlátozott tárolóméret mellett (tartaléktároló szerver);
4. A biztonsági másolatok inkonzisztenciájából, a biztonsági mentések kidolgozatlan módjából, a biztonsági másolatok teljes vagy részleges elvesztéséből adódó kockázatok nagysága;
5. Rezsiköltségek: a kiszolgálón a másolás során keletkező terhelés mértéke, a szolgáltatás válaszadási sebességének csökkenése stb.
6. Az összes igénybe vett szolgáltatás bérleti díja.

Ebben a cikkben a Linux rendszereket futtató szerverek biztonsági mentésének fő módszereiről és a leggyakoribb problémákról fogunk beszélni, amelyekkel a kezdők találkozhatnak a rendszeradminisztráció ezen nagyon fontos területén.

A tárolás és a biztonsági másolatokból való helyreállítás megszervezésének sémája

A biztonsági mentési módszer megszervezésének sémája kiválasztásakor ügyeljen a következő alapvető pontokra:

1. A biztonsági másolatok nem tárolhatók ugyanazon a helyen, ahol a biztonsági másolat készül. Ha a biztonsági másolatot ugyanazon a lemeztömbön tárolja, mint az adatokat, akkor azt elveszíti, ha a fő lemeztömb megsérül.
2. A tükrözést (RAID1) nem lehet összehasonlítani a biztonsági mentéssel. A raid csak az egyik lemez hardverproblémáitól véd meg (és előbb-utóbb előfordul egy ilyen probléma, hiszen szinte mindig a lemez alrendszer jelenti a szűk keresztmetszetet a szerveren). Ezenkívül hardveres raidek használatakor fennáll a vezérlő meghibásodásának veszélye, pl. tartalék modellt kell tartania belőle.
3. Ha a biztonsági másolatokat egy DC-ben vagy egyszerűen egy DC-ben tárolja, akkor ebben a helyzetben is vannak bizonyos kockázatok (erről például olvashat.
4. Ha a biztonsági másolatokat különböző DC-kben tárolja, akkor a hálózati költségek és a távoli másolatból történő helyreállítás sebessége meredeken megnő.

Az adatok helyreállításának oka gyakran a fájlrendszer vagy a lemezek károsodása. Azok. a biztonsági másolatokat valahol egy külön tárolószerveren kell tárolni. Ebben az esetben a probléma az adatátviteli csatorna „szélessége” lehet. Ha van dedikált szerverünk, akkor nagyon tanácsos külön hálózati interfészen biztonsági mentéseket végezni, nem pedig azon, amelyik a kliensekkel adatot cserél. Ellenkező esetben előfordulhat, hogy az ügyfél kérései nem „férnek bele” a korlátozott kommunikációs csatornába. Illetve az ügyfélforgalom miatt a biztonsági mentések nem készülnek el időben.

Ezután át kell gondolnia az adat-helyreállítás sémáját és idejét a biztonsági másolatok tárolása szempontjából. Elégedett lehet azzal, hogy éjszaka 6 óra alatt elkészül a biztonsági mentés korlátozott hozzáférési sebességgel, de a 6 órás helyreállítás valószínűleg nem felel meg Önnek. Ez azt jelenti, hogy a biztonsági másolatokhoz való hozzáférésnek kényelmesnek kell lennie, és az adatokat elég gyorsan kell másolni. Így például 1 TB adat visszaállítása 1 Gb/s sávszélesség mellett közel 3 órát vesz igénybe, és ez akkor van, ha nem korlátozza a tárolóban és a szerverben lévő lemez alrendszer teljesítménye. És ne felejtse el ehhez hozzáadni a probléma észleléséhez szükséges időt, a visszaállításhoz szükséges időt, a visszaállított adatok sértetlenségének ellenőrzéséhez szükséges időt, valamint az ügyfelek/kollégák közötti elégedetlenség mértékét. .

Növekményes biztonsági mentés

Nál nél járulékos A biztonsági mentés csak azokat a fájlokat másolja, amelyek az előző mentés óta megváltoztak. A későbbi növekményes biztonsági mentések csak azokat a fájlokat adják hozzá, amelyek az előző óta megváltoztak. A növekményes biztonsági mentések átlagosan kevesebb időt vesznek igénybe, mivel kevesebb fájlt másolnak. Az adat-helyreállítási folyamat azonban tovább tart, mert vissza kell állítani az utolsó teljes biztonsági másolat adatait, valamint az összes további növekményes biztonsági mentés adatait. Ebben az esetben a differenciális másolástól eltérően a módosított vagy új fájlok nem helyettesítik a régieket, hanem önállóan kerülnek az adathordozóra.

A növekményes másolás leggyakrabban az rsync segédprogrammal történik. Segítségével tárhelyet takaríthat meg, ha a napi változtatások száma nem túl nagy. Ha a módosított fájlok nagyok, a rendszer a korábbi verziók cseréje nélkül teljesen átmásolja őket.

Az rsync használatával végzett biztonsági mentési folyamat a következő lépésekre osztható:

1. A rendszer összeállítja a redundáns szerveren és a tárolóban lévő fájlok listáját, metaadatokat (engedélyek, módosítási idő stb.) vagy ellenőrző összeget (a —checksum kulcs használatakor) beolvas minden fájlhoz.
2. Ha a fájlok metaadatai eltérnek, akkor a fájl blokkokra van osztva, és minden blokkra ellenőrző összeget számítanak ki. Az eltérő blokkok feltöltődnek a tárhelyre.
3. Ha az ellenőrzőösszeg kiszámítása vagy a fájl átvitele közben változás történik a fájlban, akkor a biztonsági mentés elölről megismétlődik.
4. Alapértelmezés szerint az rsync SSH-n keresztül továbbítja az adatokat, ami azt jelenti, hogy minden adatblokk további titkosításra kerül. Az Rsync démonként is futtatható, és titkosítás nélkül továbbíthatja az adatokat a protokolljával.

Az rsync működésével kapcsolatos részletesebb információk a hivatalos weboldalon találhatók.

Az rsync minden fájl esetében nagyon sok műveletet hajt végre. Ha sok fájl van a szerveren, vagy ha a processzor erősen le van terhelve, akkor a biztonsági mentés sebessége jelentősen csökken.

Tapasztalatból elmondható, hogy a SATA lemezeken (RAID1) a problémák körülbelül 200 G adatmennyiség után kezdődnek a szerveren. Valójában természetesen minden az inódák számától függ. És minden esetben ez az érték eltolódhat egyik vagy másik irányba.

Egy bizonyos pont után a biztonsági mentés végrehajtási ideje nagyon hosszú lesz, vagy egyszerűen nem fejeződik be egy nap alatt.

Annak érdekében, hogy ne hasonlítsa össze az összes fájlt, van lsyncd. Ez a démon információkat gyűjt a megváltozott fájlokról, pl. már előre lesz egy listánk, amely készen áll az rsync-re. Ugyanakkor figyelembe kell venni, hogy ez további terhelést jelent a lemez alrendszerére.

Differenciális biztonsági mentés

Nál nél differenciális A biztonsági mentésben minden fájlról, amely az utolsó teljes biztonsági mentés óta megváltozott, minden alkalommal biztonsági másolat készül. A differenciális másolás felgyorsítja a helyreállítási folyamatot. Csak a legújabb teljes és legújabb differenciálmentésre van szüksége. A differenciális biztonsági mentések egyre népszerűbbek, mivel a fájlokról bizonyos időpontokban minden másolat készül, ami például nagyon fontos vírusfertőzés esetén.

A differenciális biztonsági mentés például egy segédprogram, például az rdiff-backup segítségével történik. Amikor ezzel a segédprogrammal dolgozik, ugyanazok a problémák merülnek fel, mint a növekményes biztonsági mentéseknél.

Általánosságban elmondható, hogy ha teljes fájlkeresést hajt végre, amikor az adatok eltéréseit keresi, az ilyen biztonsági mentés problémái hasonlóak az rsync problémáihoz.

Külön szeretnénk megjegyezni, hogy ha a biztonsági mentési sémában minden fájlt külön-külön másol, akkor érdemes törölni/kizárni azokat a fájlokat, amelyekre nincs szüksége. Ezek lehetnek például CMS-gyorsítótárak. Az ilyen gyorsítótárak általában sok kis fájlt tartalmaznak, amelyek elvesztése nem befolyásolja a szerver megfelelő működését.

Teljes biztonsági mentés

A teljes biztonsági mentés általában az egész rendszert és az összes fájlt érinti. A heti, havi és negyedéves biztonsági mentés magában foglalja az összes adat teljes másolatának létrehozását. Általában pénteken vagy hétvégén hajtják végre, amikor a nagy mennyiségű adat másolása nem befolyásolja a szervezet munkáját. A következő biztonsági mentések, amelyeket hétfőtől csütörtökig a következő teljes biztonsági mentésig hajtanak végre, lehetnek differenciális vagy növekményes mentések, elsősorban az idő és a tárhely megtakarítása érdekében. A teljes biztonsági mentést legalább hetente el kell végezni.

A legtöbb kapcsolódó kiadvány azt javasolja, hogy hetente egyszer vagy kétszer végezzen teljes biztonsági mentést, a fennmaradó időben pedig növekményes és differenciális biztonsági mentéseket. Az ilyen tanácsoknak oka van. A legtöbb esetben elegendő egy teljes biztonsági mentés hetente egyszer. Célszerű újra futtatni, ha nem tudja frissíteni a teljes biztonsági másolatot a tárolási oldalon, és nem tudja biztosítani a biztonsági másolat helyességét (erre szükség lehet például olyan esetekben, amikor valamilyen okból ne bízzon a meglévő szkriptekben vagy biztonsági mentési szoftverekben.

Valójában a teljes biztonsági mentés 2 részre osztható:

1. Teljes biztonsági mentés a fájlrendszer szintjén;
2. Teljes eszközszintű biztonsági mentés.

Nézzük meg jellemző tulajdonságaikat egy példa segítségével:
root@komarov:~# df -h Fájlrendszer méret Használt Elérhetőség Felhasználás% Felszerelve a /dev/mapper/komarov_system-root 3.4G 808M 2.4G 25% / /dev/mapper/komarov_system-home 931G 439G 493G 48% /home 4,0K 383M 1% /dev tmpfs 107M 104K 107M 1% /futtatás tmpfs 531M 0 531M 0% /tmp nincs 5,0M 0 5,0M 0% /futtatás/zárolás nincs 531M 0 /dev/8Mshm 22M 109M 17% /boot

Csak foglalni fogunk /otthon. Minden más gyorsan visszaállítható manuálisan. Telepíthet egy kiszolgálót konfigurációkezelő rendszerrel is, és csatlakoztathatja hozzá a /home-unkat.

Teljes biztonsági mentés a fájlrendszer szintjén

Tipikus képviselője: szemétlerakó.

A segédprogram létrehozza a fájlrendszer „kiíratását”. Nem csak teljes, hanem növekményes biztonsági mentést is készíthet. A dump az inode táblával működik, és „érti” a fájlszerkezetet (tehát a ritka fájlok tömörítésre kerülnek).
Egy futó fájlrendszer kiíratása "hülye és veszélyes", mert a fájlrendszer megváltozhat a kiíratás létrehozása közben. Pillanatképből kell létrehozni (kicsit később részletesebben tárgyaljuk a pillanatképekkel való munkavégzés jellemzőit), egy csatolt vagy lefagyott fájlrendszerből.

Ez a séma a fájlok számától is függ, és a végrehajtási ideje a lemezen lévő adatok mennyiségével nő. Ugyanakkor a dump működési sebessége nagyobb, mint az rsync.
Ha nem a teljes biztonsági másolatot kell visszaállítani, hanem például csak néhány véletlenül sérült fájlt, akkor az ilyen fájlok visszaállítása a visszaállító segédprogrammal túl sok időt vehet igénybe.

Teljes eszközszintű biztonsági mentés

1. mdraid és DRBD
   Valójában a RAID1 egy lemezzel/raiddel van konfigurálva a szerveren és egy hálózati meghajtón, és időről időre (a biztonsági mentések gyakoriságának megfelelően) a kiegészítő lemezt szinkronizálja a szerveren lévő fő lemezzel/raiddel.

   A legnagyobb plusz a sebesség. A szinkronizálás időtartama csak az utolsó napon végrehajtott módosítások számától függ.
   Ezt a biztonsági mentési rendszert elég gyakran használják, de kevesen veszik észre, hogy a segítségével megszerzett biztonsági másolatok hatástalanok lehetnek, és itt van miért. Amikor a lemez szinkronizálása befejeződött, a biztonsági másolatot tartalmazó lemez leválasztásra kerül. Ha például olyan DBMS-t futtatunk, amely részletekben írja ki az adatokat a helyi lemezre, közbenső adatokat tárolva a gyorsítótárban, akkor nincs garancia arra, hogy azok még a mentési lemezre is kerülnek. Legjobb esetben a módosítandó adatok egy részét elveszítjük. Ezért az ilyen biztonsági mentések aligha tekinthetők megbízhatónak.

2. LVM+dd
   A pillanatképek nagyszerű eszköz a következetes biztonsági mentések készítéséhez. Pillanatkép létrehozása előtt vissza kell állítania az FS gyorsítótárát és a szoftvert a lemezalrendszerre.

Például egyedül a MySQL-lel ez így nézne ki:
$ sudo mysql -e "A TÁBLÁZATOK ÖBLÍTÉSE OLVASÁSZÁROLÁSSAL;" $ sudo mysql -e "FLUSH LOGS;" $ sudo sync $ sudo lvcreate -s -p r -l100%free -n %s_backup /dev/vg/%s $ sudo mysql -e "TÁBLÁZATOK OLDÁSA;"

* A kollégák mesélnek arról, hogy valaki „olvasási zárolása” néha holtponthoz vezetett, de emlékezetem szerint ez soha nem történt meg.

A DBMS biztonsági mentések külön is létrehozhatók (például bináris naplók használatával), így kiküszöbölhetők a leállások a gyorsítótár-visszaállítás során. A tárolóban is létrehozhat kiíratokat, ha ott elindít egy DBMS-példányt. A különböző DBMS-ek biztonsági mentése külön kiadványok témája.

Pillanatképeket másolhat a folytatás segítségével (például rsync egy javítással a blokkeszközök másolására bugzilla.redhat.com/show_bug.cgi?id=494313), blokkolhat blokkonként és titkosítás nélkül (netcat, ftp). A blokkokat tömörített formában is átviheti, és a tárolóba illesztheti az AVFS segítségével, és felcsatolhat egy partíciót biztonsági mentésekkel SMB-n keresztül a szerveren.

A tömörítés kiküszöböli az átviteli sebességgel, a csatornatorlódással és a tárhellyel kapcsolatos problémákat. Ha azonban nem használ AVFS-t a tárolóban, akkor sok időbe telik, amíg az adatoknak csak egy részét állítja vissza. Ha AVFS-t használsz, találkozni fogsz a „nedvességgel”.
A blokktömörítés alternatívája a squashfs: felcsatolhatunk például egy Samba partíciót a szerverre és futtathatunk mksquashfs-t, de ez a segédprogram fájlokkal is működik, pl. mennyiségüktől függ.

Ráadásul a squashf-ek létrehozásakor elég sok RAM megy kárba, ami könnyen az oom-killer meghívásához vezethet.

Biztonság

Meg kell védenie magát az olyan helyzetektől, amikor a tárolót vagy a szervert feltörik. Ha feltörték a szervert, akkor jobb, ha az oda adatokat író felhasználónak nincs joga a tárhelyen lévő fájlok törlésére/módosítására.
Ha a tárhelyet feltörték, akkor is célszerű a tartalék felhasználó jogait a szerveren a maximumra korlátozni.

Ha a tartalék csatorna lehallgatható, akkor titkosításra van szükség.

Következtetés

Minden biztonsági mentési rendszernek megvannak a maga előnyei és hátrányai. Ebben a cikkben megpróbáltunk kiemelni néhány árnyalatot a biztonsági mentési rendszer kiválasztásakor. Reméljük, segítik olvasóinkat.

Ennek eredményeként, amikor a projekthez biztonsági mentési rendszert választ, tesztelnie kell a kiválasztott biztonsági mentési típust, és figyelnie kell a következőkre:

• tartalék idő a projekt jelenlegi szakaszában;
• biztonsági mentési idő arra az esetre, ha sokkal több adat lenne;
• csatorna terhelés;
• betölti a lemez alrendszerét a szerveren és a tárolóban;
• ideje visszaállítani az összes adatot;
• egy pár fájl helyreállítási ideje;
• az adatok konzisztenciájának szükségessége, különösen az adatbázisok esetében;
• memóriafelhasználás és oom-killer hívások jelenléte;

Biztonsági mentési megoldásként használhatja a feltöltést és a felhőalapú tárhelyünket.
Azokat az olvasókat, akik nem tudnak itt megjegyzést írni, csatlakozzanak hozzánk a blogon.

Címkék:

• biztonsági mentések
• biztonsági mentés
• selectel

Címkék hozzáadása