Craig Mullinin kirjan ”Database Administration” alussa hän sanoo ”in many ways, business today is data”. Useimmissa organisaatioissa henkilö, joka on vastuussa tietojen suojaamisesta, on tietokannan ylläpitäjä … Sinä.

se on oikein; koko liiketoiminta on osaavissa käsissäsi, käynnissä sillä palvelimella, joka ei koskaan kaadu, kaikkien niiden loppukäyttäjien kanssa, jotka eivät koskaan tee virheitä sovellusten avulla, jotka ovat rakentaneet ne kehittäjät, jotka kirjoittavat virheetöntä koodia ensimmäistä kertaa, joka kerta, uuden co-op: n kanssa, jolla on ” sa ” – oikeudet pomosi ansiosta.

OK. Älä itke. On asioita, voit tehdä suojella SQL Server tiedot oman hoidon ja yksi tärkeimmistä on käynnissä säännöllisesti tietokannan varmuuskopiot.

varmuuskopiot

Microsoft määrittelee SQL Server Books Onlinessa varmuuskopiot seuraavasti:

kopio tiedoista, joita käytetään tietojen palauttamiseen ja palauttamiseen järjestelmähäiriön jälkeen

SQL-varmuuskopiot voidaan luoda useilla tavoilla ja ne voivat sisältää kaikki tai osan tiedoista sekä osan tapahtumalokista. Vaikka tämä artikkeli keskittyy vuoden 2005 syntaksiin, useimmat käsitteet ovat sovellettavissa vuoteen 2000. Tämä on valtava aihe. Korkeintaan raapaisen pintaa ja annan tarpeeksi tietoa, ettet ala taas itkemään. Kun olet lukenut tämän, sinun pitäisi pystyä perustamaan kohtuullinen joukko varmuuskopioita järjestelmään.

Palautusmallit

jotta varmuuskopiot voidaan aloittaa, liiketoiminnan tarpeet määrittelevät tietokannan palautusmallin. Pohjimmiltaan, elpyminen malli määrittelee, mitä aiot tehdä tapahtumalokin tiedot.

palautusmalleja on kolme: Full, Simple ja Bulk Logged. Nämä on aika helppo määritellä:

• yksinkertainen-yksinkertaisessa palautustilassa tapahtumalokia ei varmuuskopioida, joten voit vain palauttaa viimeisimmän täyden tai differentiaalisen varmuuskopioinnin.
• täysi palautustilassa varmuuskopioit tietokannan ja tapahtumalokin, jotta voit palauttaa tietokannan mihin tahansa ajankohtaan.
• Bulk Logged-in bulk logged-tilassa suurin osa tapahtumista tallennetaan tapahtumalokiin, mutta joitakin irtotavaratoimintoja, kuten irtokuormia tai indeksin luontia, ei kirjata.

kaksi yleisimmin käytettyä tilaa ovat yksinkertaiset ja täydet. Älä välttämättä oleta, että, tietenkin, sinun täytyy aina käyttää täydellistä hyödyntämistä suojata tietosi. Se on bisnespäätös. Liike aikoo kertoa, jos sinun täytyy toipua tiettyyn ajankohtaan tai jos tarvitset vain viimeisen täyden varmuuskopion. Se tulee määritellä, jos tiedot on kerrytettävissä muilla keinoin, kuten manuaalinen syöttö, tai jos sinun täytyy suojata niin paljon kuin mahdollista, koska se tulee koko Lanka. Käytät yksinkertaista hyödyntämistä, jos sinulla on varaa menettää tallennetut tiedot, koska viimeinen täysi tai ero varmuuskopiointi ja / tai et vain tarvitse elpymistä tiettyyn aikaan. Yksinkertaisessa tilassa, sinun täytyy palauttaa kaikki toissijaiset luku / kirjoitus tiedostoryhmät, kun palautat ensisijainen. Käytät yksinkertaista enimmäkseen toissijaisissa tietokannoissa, jotka eivät ole ehdottoman tärkeä osa yritystä tai raportointijärjestelmiä, joissa on vain lukuoikeus, joten ei ole tapahtumalokia, josta huolehtia muutenkaan. Käytät Koko, jos jokainen vähän tietoja on elintärkeää, sinun täytyy palauttaa tiettyyn ajankohtaan tai, yleensä jos kyseessä on hyvin suuria tietokantoja (VLDB), sinun täytyy palauttaa yksittäisiä tiedostoja ja tiedostoryhmiä riippumatta muista tiedostoista ja tiedostoryhmiä.

sekä yksinkertaisilla että täydellisillä palautusmalleilla voi nyt ajaa vain kopioivan varmuuskopion, jonka avulla tietokannan voi kopioida varmuuskopiotiedostoon, mutta se ei vaikuta lokiin, differentiaalisiin varmuuskopiointiaikatauluihin tai törmäyksen palautukseen tiettyyn ajankohtaan. Yritän porata alas niin monta näistä aiheista kuin mahdollista artikkelin kautta, mutta ei tiedostoja ja filegroups.

työskentely yksinkertaisella elvytyksellä

tarpeeksi puhetta. Aloitetaan varmuuskopiot. Oletetaan, että olemme yksinkertainen elpyminen pieni tai keskikokoinen tietokanta. Aion käyttää AdventureWorks kaikki näytekäsikirjoitukset. Asettaa sen yksinkertainen elpyminen:

yksinkertaisin varmuuskopiointistrategiasi on suorittaa säännöllisin väliajoin seuraava SQL Server backup-komento, joka suorittaa tietokannan täyden varmuuskopioinnin.:

miksi kirjoitat noin paljon? Eikö meillä ole GUI-työkaluja, jotka hoitavat työn puolestamme? Kyllä, useimmat yksinkertaiset varmuuskopiot voidaan suorittaa SQL Server Management Studion avulla. Kuitenkin, jos haluat oppia ja ymmärtää, mitä Management Studio tekee sinulle, tai jos haluat hienorakeinen valvoa, mitä varmuuskopioidaan, miten ja missä, sitten sinun täytyy murtaa näppäimistön ja laittaa pois hiiri.

yllä oleva komento sakkaa levylle perusturvan. Useimmat DBAs tiedän varmuuskopioida tiedoston ja sitten kaapia tiedostot päälle nauha tai jokin muu media. Tämä johtuu siitä, että levyn tiedostot ovat yksinkertaisia ja nopeita palauttaa, kun taas media voi joskus olla hieman tuskaa. Esimerkiksi, meillä on yleensä kaksi tai kolme päivää arvoinen varmuuskopiot meidän tiedostojärjestelmät välitöntä elpymistä. Siirrymme nauhajärjestelmiin vain, jos meidän on ajettava vanhojen varmuuskopioiden palautuksia.

mitä tuo käsky teki? Se teki kopion kaikista tietokannassa olevista sidotuista tiedoista. Se myös kopioi toimittamattomia lokimerkintöjä. Näitä käytetään palautuksen aikana tietojen varmuuskopioinnin aikana tapahtuneiden muutosten toimittamiseen tai palauttamiseen.

vain Kopioidut varmuuskopiot

normaalisti tietokannan varmuuskopiointi vaikuttaa muihin varmuuskopiointi-ja palautusprosesseihin. Esimerkiksi suoritettuaan edellisen komennon, mikä tahansa ero varmuuskopiot (varmuuskopio, joka vain kopioi tiedot muuttunut viime varmuuskopiointi) käyttäisi tätä lähtökohtana tietojen muutokset, ei varmuuskopiointi ajoit viime yönä. Kuten aiemmin todettiin, SQL 2005 esittelee uuden konseptin varmuuskopiot, COPY_ONLY varmuuskopiot, joiden avulla voimme pitää keskeyttämästä sykli:

olemme jo löytäneet sellaisen rakeisemman hetken, kun Johtamisstudio ei suostunut auttamaan. Jos haluat kopion vain varmuuskopio, sinun täytyy käyttää komentoriviltä.

Differential backups

oletetaan hetki, että olemme vielä yksinkertaisessa palautuksessa, mutta kyseessä on suurempi tietokanta, vaikkapa jotain yli 100 Gt: n kokoinen. Täysi varmuuskopiot voi todella alkaa hidastaa prosessia hieman. Sen sijaan, kuulemisen jälkeen liiketoiminnan, olemme päättäneet tehdä viikoittain täysi varmuuskopio ja päivittäin ero varmuuskopiot. Differential varmuuskopiot vain varmuuskopioida datasivuja, jotka ovat muuttuneet viimeisen täyden varmuuskopion. Seuraavassa on SQL backup komento suorittaa ero varmuuskopiointi:

nyt, jos meidän piti palauttaa tämä tietokanta, me ensin mennä viimeinen täysi varmuuskopio, palauttaa, että, ja sitten palauttaa ero varmuuskopiot järjestyksessä (lisää siitä myöhemmin).

on olemassa useita muita varmuuskopiointivaihtoehtoja, joita en yksityiskohtaisesti täällä. Lue kirjoja verkossa nähdä yksityiskohtia lohkokoko, EXPIREDATE, PIDÄTYSPÄIVÄT, salasana, nimi, tilastot, ja niin edelleen.

voit myös ajaa lausunnon, joka tarkistaa tietokannan varmuuskopion eheyden. Se ei tarkista eheyden tietojen sisällä varmuuskopio, mutta se varmistaa, että varmuuskopio on muotoiltu oikein ja saatavilla.

Full recovery and log backups

we ’ ve primarely been working on a database that was in Simple recovery mode (this used to be called Typcate Log on Checkpoint). Tässä tilassa, emme varmuuskopioi tapahtumalokit myöhempää hyödyntämistä varten. Jokainen varmuuskopiointi tämän mekanismin alla on tietokannan varmuuskopiointi. Lokin varmuuskopiot eivät yksinkertaisesti ole mahdollisia.

tietoja on kuitenkin suojattu vain viimeiseltä kunnon varmuuskopiolta, joko täydeltä tai tasauspyörästöltä. Muutetaan oletuksiamme. Nyt kyseessä on iso, tehtäväkriittinen sovellus ja tietokanta. Haluamme palauttaa tietokannan viime hetkeen asti. Tämä on hyvin tärkeä asia. Teoriassa, koska lokimerkintöjä säilytetään ja varmuuskopioidaan, – olemme suojattuja mahdollisiin epäonnistumisiin asti. Jotkut epäonnistumiset voivat kuitenkin aiheuttaa lokin korruptoitumista, jolloin palautuminen tiettyyn ajankohtaan asti on mahdotonta. Niin, meidän täytyy määrittää, mikä kohtuullinen vähimmäisaika välillä loki varmuuskopiot on. Tässä tapauksessa voimme elää enintään 15 minuutin edestä kadonneita tietoja.

niin, aloitetaan laittamalla tietokantamme täyteen palautustilaan:

sitten, aikataulun perusteella, tässä tapauksessa 15 minuutin välein, suoritamme SQL varmuuskopiointi komento tapahtumaloki:

tämä komentosarja varmuuskopioi tapahtuneet tapahtumat tapahtumalokista. Siinä on merkkejä tiedostossa, jotka näyttävät käynnistys-ja pysäytysajan. Se katkaisee lokin, kun se on onnistuneesti valmis, puhdistaen tapahtumalokista varmennetut tapahtumat, jotka on kirjoitettu varmuuskopiotiedostoon. Tarvittaessa voit käyttää WITH NO_TRUNCATE-lauseketta tallentaaksesi tietoja tapahtumalokista tietokannan tilasta riippumatta olettaen, että se on verkossa eikä hätätilassa. Tämä on vain hätätapauksia varten.

huomaa, että emme käytä INIT-lausetta tässä tapauksessa, mutta voit tehdä niin, jos haluat. Kun teet loki varmuuskopiot, sinulla on vaihtoehtoja:

1. Suorita kaikki varmuuskopiot yhteen tiedostoon, jossa ne pino ja kaikki mitä sinun tarvitsee tehdä, on palauttaa (katettu myöhemmin), on selata niitä.
2. nimeä varmuuskopiot yksikäsitteisesti, luultavasti käyttäen merkkijonossa päivämäärää ja aikaa.

jälkimmäisessä tapauksessa turvallisuus sanoo, Käytä INITÄ, koska käytät maksimaalista kontrollia siihen, mitä varmuuskopioidaan missäkin, ja voit tietää nimen perusteella tarkalleen, mikä varmuuskopio on, milloin se on otettu ja mistä. Tämä on vielä yksi paikka, jossa toimivat varmuuskopiot komentoriviltä antaa sinulle enemmän valvontaa kuin GUI. Olemme käyttäneet molempia lähestymistapoja järjestelmissämme eri syistä. Voit päättää, mikä on parasta teknologian ja liiketoiminnan vaatimukset.

suurin osa tietokannan varmuuskopiointiin käytettävissä olevista valinnoista sisältyy lokin varmuuskopiointiin, mukaan lukien COPY_ONLY. Näin voit kaapata joukon tapahtumatietoja vaikuttamatta lokiin tai seuraavaan ajoitettuun lokin varmuuskopiointiin. Tämä olisi kätevä viedä tuotantotiedot toiseen järjestelmään vianmääritystä jne. varten.

jos tietokantasi on asetettu täyteen palautukseen, sinun on suoritettava loki-varmuuskopiot. Joskus ihmiset unohtavat ja tapahtumaloki kasvaa siihen pisteeseen, että se täyttää levyaseman. Tällöin voit juosta:

No_login liittäminen loki-varmuuskopioon ja lokin sijainnin määrittelemättä jättäminen aiheuttaa lokin epäaktiivisen osan poistamisen, ja se tekee tämän ilman lokimerkintää itse, jolloin koko levyasema häviää. Tämä ei todellakaan ole suositeltavaa, koska se rikkoo lokiketjun, sarjan loki varmuuskopiot, josta voit palauttaa tietokannan tiettyyn aikaan. Microsoft suosittelee täyden varmuuskopion suorittamista välittömästi tämän lausunnon käytön jälkeen. Edelleen, he varoittavat, että tämä lausunto voi olla vanhentunut tulevassa tiedotteessa.

tietokantojen palauttaminen

niin tärkeitä kuin SQL Server-varmuuskopiot ovat, ja ne ovat elintärkeitä, ne ovat hyödyttömiä ilman mahdollisuutta palauttaa tietokantaa.

täydellisen tietokannan varmuuskopion palauttaminen

täydellisen tietokannan varmuuskopion palauttaminen on yhtä yksinkertaista kuin oli luoda:

se on todella niin yksinkertaista-ellei, koska me olemme varmuuskopioida kaiken tiedostoon ikään kuin se olisi varmuuskopio laite. Siinä tapauksessa, sinun täytyy määrittää, mikä tiedosto sisällä ”laite” käytät. Jos et tiedä, mikä tiedosto, sinun täytyy luoda luettelo:

tämä antaa sinulle saman listan kuin näytin yllä Management Studio. Joten nyt, jos haluamme palauttaa toisen tiedoston ryhmässä, COPY_ONLY varmuuskopiointi, voit antaa seuraavan komennon:

valitettavasti, jos olet seuraavat pitkin, saatat huomata, että olet juuri luonut tämän virheen:

mitä tämä tarkoittaa, että tietokanta on täysin palautustilassa, mutta et ole varmuuskopioinut ”tail of Loki”, eli tapahtumat tuli koska viime kerran ajo varmuuskopio. Voit ohittaa tämän vaatimuksen, jos vaihdat edellisen syntaksin:

se on ensimmäinen kerta, kun olemme pinottu lausekkeet (kanssa FILE=2 ja korvaa on edustettuna kuten FILE=2, korvata), mutta se ei ole viimeinen. Lue kirjat netistä. Useimpia WITH-lausekkeita voidaan käyttää yhdessä muiden lausekkeiden kanssa.

mitä tapahtuu, jos haluamme palauttaa eri tietokantaan kuin alkuperäinen? Haluamme esimerkiksi tehdä kopion tietokannastamme erillisestä varmuuskopiosta. Ehkä haluamme siirtää sen alas tuotannon tukipalvelimelle, jossa aiomme tehdä työtä sen, erillään tuotannon kopio tietokannasta. Jos otamme yksinkertainen lähestymistapa, no, kokeile tätä:

tässä tapauksessa, sinun pitäisi nähdä koko joukko virheitä, jotka liittyvät tiedostoja ei korvata. Voit todella luoda uusia tietokantoja varmuuskopioista, mutta jos teet sen palvelimella olemassa olevan tietokannan, sinun täytyy muuttaa sijaintia fyysisiä tiedostoja käyttäen loogisia nimiä. Jotta tietää loogiset nimet tiedostot tietyn tietokannan, suorita tämä ennen yrittää siirtää tiedostoja:

tätä voidaan sitten käyttää tunnistamaan sopivat loogiset nimet, jotta voidaan luoda Tämä skripti:

differentiaalisen varmuuskopion palauttaminen

viimeinen tapa on soveltaa differentiaalista varmuuskopiointia. Tämä vaatii kaksi vaihetta. Ensin, palautamme tietokannan, mutta kierre ja sitten käytämme ero varmuuskopiointi:

suurin osa tästä lienee itsestään selvää sen perusteella, mitä olemme jo käsitelleet. Yksi ryppy on NORECOVERY-avainsanan sisällyttäminen. Hyvin yksinkertaisesti, aikana palauttaa, liiketoimet ovat voineet alkaa aikana varmuuskopiointi. Palautuksen lopussa valmiit tapahtumat rullataan eteenpäin tietokantaan ja epätäydelliset tapahtumat rullataan takaisin. Asetus NORECOVERY pitää tapahtumat auki. Näin seuraavat tapahtumat voidaan noutaa seuraavasta varmuuskopiosta järjestyksessä.

tässä artikkelissa käsitellään lähinnä yksinkertaisia varmuuskopioita ja palautuksia, mutta kehittyneempi palautus vuonna 2005 mahdollistaa toissijaisten tiedostoryhmien palauttamisen tietokannan ollessa verkossa. Sen ensisijainen tiedostoryhmä on oltava verkossa operaation aikana. Tästä on enemmän hyötyä hyvin suurissa tietokantajärjestelmissä.

SQL Server-tietokantojen palauttaminen tiettyyn ajankohtaan

lokien palauttaminen ei ole paljon vaikeampaa kuin juuri valmistunut differentiaalitietokannan palautus. Hetkeen palautumiseen liittyy vain aika paljon muutakin. Olettaen, että varmuuskopioit lokit yhteen tiedostoon tai laitteeseen:

muuten, voit yksinkertaisesti mennä ja saada tiedostojen nimet tarvitset. Ensin ajaa tietokannan palauttaminen, huolehtien jättää sen ei-talteen tilassa. Tämän jälkeen tehdään sarja lokin palautuksia tiettyyn ajankohtaan.

nyt meillä on tietokanta, joka vastaa viimeistä tapahtumaa 23.lokakuuta kello 14.30.29. Muista, aikana monivaiheinen palauttaa, kuten tämä, sinun täytyy jättää tietokannan toipumassa tila. Tämä tarkoittaa notecovery jokaiseen tiliotteeseen, kunnes olet suorittanut palautusprosessin. Jos jostain syystä olet lisännyt NORECOVERY kaikki lausunnot, tai yksinkertaisesti lopettaa keskellä, ja haluat tuoda tietokannan takaisin verkossa, voit käyttää tätä lausumaa loppuun prosessin:

tietokannan tilannekuvat

SQL Server 2005 otti käyttöön käsitteen tilannekuva eli vain luku-ja staattinen näkymä tietokannasta. Tilannekuvat luodaan ensisijaisesti vain luku-version toimittamiseksi tietokannasta raportointia varten. Ne toimivat kuitenkin samalla tavalla kuin varmuuskopiot. Yksi ensisijainen ero on, että kaikki sitomattomat tapahtumat rullataan takaisin. Ei ole vaihtoehtoa liikkuvan eteenpäin, kaappaus lokit, jne., että varmuuskopiot tarjoavat, eikä kovin monia SQL Server resursseja käytetään lainkaan. Sen sijaan levytekniikkaa käytetään datan kopioimiseen. Tämän vuoksi ne ovat paljon nopeampia kuin varmuuskopiot sekä luoda ja palauttaa.

HUOM:
lisätietoja SQL 2005-tilannekuvasta löytyy osoitteesta http://www.simple-talk.com/sql/database-administration/sql-server-2005-snapshots/.

hyvä tilannekuvien käyttö raportoinnin lisäksi voisi olla sellaisen luominen ennen ylläpitoa, kun olet jo poistanut kaikki aktiiviset käyttäjät (ja heidän tapahtumansa) järjestelmästä. Vaikka tilannekuvat eivät tue live-varmuuskopioiden volatiliteettia, niiden nopeus ja palautumisen helppous ovat erinomainen työkalu nopeaan toipumiseen epäonnistuneesta käyttöönotosta. Tilannekuvat tallennetaan palvelimelle, joten sinun on varmistettava, että sinulla on riittävä tallennustila.

syntaksi on erilainen, koska et varmuuskopioi tietokantaa, vaan luot uuden tietokannan:

nyt se on käytettävissä vain luku-oikeus. Koska olemme ensisijaisesti huolissaan käyttämällä tätä varmuuskopio mekanismi, Let ’ s sisällyttää menetelmä palauttaa tietokannan tietokantaan tilannekuvan.

tunnista ensin tilannekuva, jota haluat käyttää. Jos palautettavassa tietokannassa on useampi kuin yksi, sinun on poistettava kaikki paitsi käyttämäsi tietokanta.:

sitten voit palauttaa tietokannan ajamalla palauttaa lausuma (sekoitettu metaforia, ei hyvä):

juuri noin. Minun järjestelmä, käynnissä tietokanta tilannekuvia Adventureworks kesti 136 ms. täysi varmuuskopiointi kesti 5670 ms. palauttaminen tilannekuvan kesti 905ms ja tietokannan palautus kesti 13382 ms. Tämän sisällyttäminen tuotannon käyttöönottoprosessiin voisi johtaa merkittäviin hyötyihin

jälleen, on syytä huomata, että tilannekuvan käytössä on joitakin varoituksia. Sinulla täytyy olla tarpeeksi levytilaa toisen kopion tietokantaan. Sinun täytyy olla varovainen tekemisissä tilannekuvia, koska suurin osa syntaksi on samanlainen kuin käytetään tietokantojen itse. Viimeinen, vaikka on tilannekuvia liitetty tietokantaan et voi suorittaa palauttaa tietokannasta varmuuskopiointi että tietokantaan.

parhaat käytännöt

tapa, jolla tietokannan varmuuskopiointi tehdään, ei saisi olla tekninen päätös. Sen pitäisi olla yrityksen sanelemaa. Pienet järjestelmät, joilla on alhaiset tapahtumahinnat ja / tai raportointijärjestelmät, jotka ladataan säännöllisesti, tarvitsevat vain täyden tietokannan varmuuskopion. Keskikokoiset järjestelmät ja suuret järjestelmät tulevat riippuvaisiksi siitä, minkä tyyppisten tietojen avulla voidaan määrittää, millaisia varmuuskopiointeja tarvitaan.

keskikokoisessa järjestelmässä päivittäinen varmuuskopiointi lokin varmuuskopioineen päivän aikana vastaisi todennäköisesti useimpiin tietovaatimuksiin oikea-aikaisesti.

suurelle tietokannalle paras lähestymistapa on sekoittaa ja sovittaa varmuuskopiot, jotta varmistettaisiin mahdollisimman hyvä palautettavuus mahdollisimman lyhyessä ajassa. Suorita esimerkiksi viikoittainen täysi varmuuskopio. Kahdesti päivässä viikon aikana, suorita ero varmuuskopio. 10 minuutin välein päivällä, suorita loki varmuuskopiointi. Tämä antaa sinulle useita palautumismekanismeja.

hyvin suurissa tietokannoissa on päästävä filegroupin ja tiedostojen varmuuskopioiden ajamiseen, koska täyden varmuuskopioinnin tai edes differentiaalisen varmuuskopioinnin tekeminen koko tietokannasta ei välttämättä ole mahdollista. Useita lisätoimintoja on saatavilla auttamaan tällä alueella, mutta en aio mennä niihin täällä.

kannattaa käyttää aikaa muutamien skriptien kehittämiseen varmuuskopioiden ja palautusten ajamiseen. Nimeämiskäytäntö joten tiedät mitä tietokantaa, jolta palvelimelta, mistä päivämäärästä, mitä erityisiä varmuuskopiointi ja muoto on erittäin edistää oman mielenterveys. Yhteinen sijainti varmuuskopioita, loki, täydellinen tai inkrementaalinen, olisi määriteltävä. Jokainen vastuussa olisi koulutettava sekä varmuuskopiointi ja palautus ja vianmääritys sama. On olemassa monia tapoja tehdä tämä, mutta löydät muutamia ehdotuksia Pop varmuuskopiot ja Pop palauttaa.

todellinen testi on suorittaa varmuuskopiomekanismit ja suorittaa sitten palautus. Kokeile sitten toisenlaista palautusta ja toista ja toista. Varmista, että, ei vain olet tehnyt due diligence määrittelyssä miten varmuuskopioida järjestelmä, mutta että olet tehnyt ylimääräinen askel varmistaa, että voit palauttaa nämä varmuuskopiot. Jos et ole harjoitellut tätä ja dokumentoinut käytäntöä ja sitten testannut dokumenttia, et itse asiassa ole valmis katastrofiin.

Yhteenveto

varmuuskopiot oman yrityksen sisällä pitäisi olla kuin äänestäisi Chicagossa, aikaisin ja usein. Perustamalla perus varmuuskopiot on melko yksinkertainen. Lokin varmuuskopioiden ja differentiaalien lisääminen on myös helppoa. Tutustu vaihtoehtoja nähdä, miten lisätä tiedoston ja tiedostoryhmän varmuuskopiot ja palauttaa nopeuttaa varmuuskopiot ja palauttaa, jotka molemmat lisäävät järjestelmän käytettävyyttä ja ylös aikaa. Pidä yhteinen nimeämisstandardi. Ole varovainen, kun käytät tilannekuvia, mutta varmasti käyttää niitä. Säilytä tiedostot vakiopaikalla palvelimien välillä. Harjoittele toipumista. Lopuksi, todella tehdä varmuuskopiot laulaa, lataa ilmainen kokeiluversio Red Gaten SQL Backupâ¢. Se tarjoaa korkean suorituskyvyn pakkaus-ja verkon sietokykyä, jotta prosessi kirjallisesti tai kopioimalla varmuuskopioita koko hilseilevissä verkoissa vikasietoinen.