sql sigurnosna kopija. Sigurnosno kopiranje Microsoft SQL Server baza podataka

Opsežna funkcionalnost Bacula Enterprise Edition, između ostalog, omogućuje vam brzo i jednostavno stvaranje sigurnosnih kopija baze podataka za . Na primjer, govorimo o alatu s kojim možete sigurnosno kopirati MS SQL poslužitelj. Korisnik može izraditi sigurnosnu kopiju MS SQL-a stvaranjem sigurnosnih kopija velikog volumena specifičnih MS SQL baza podataka koje koristi platforma Windows, po nižoj cijeni za softver treće strane, uz mogućnost vraćanja podataka na određenu točku u vremenu (PITR oporavak ) na mreži i lokalni disk.

Skriptu Bacula Systems za izradu sigurnosnih kopija MS SQL Servera odlikuje iznimna učinkovitost, postignuta implementacijom moderne, visoko pouzdane arhitekture. Štoviše, softver vam omogućuje izradu sigurnosne kopije MS SQL Servera i korištenje raznih opcija za izradu MS SQL sigurnosnih kopija.

MS SQL Bacula Systems backup skripta radi neovisno o VSS-u. To znači da alat Rezervni primjerak MS SQL ne koristi VSS snimke za izradu sigurnosnih kopija. Stoga korisnik može postaviti sljedeću vrijednost "Omogući VSS = ne" u Bacula FileSet. Učinkovito stvaranje sigurnosnih kopija MS SQL Servera i njihovo vraćanje pomoću ovog rješenja postiže se kroz koristeći Microsoft API za SQL Server. To omogućuje Bacula Systems podršku sigurnosnim mehanizmima i svim vrstama autentifikacije implementiranim u Microsoft SQL Serveru.

Sigurnosno kopiranje dnevnika transakcija MS SQL-a i oporavak MS SQL-a u određenom trenutku: softver Bacula Enterprise Edition omogućuje vam vraćanje MS SQL blokova podataka ili specifičnih postavki na određenu točku u vremenu. S implementacijom potpunih i skupno prijavljenih modela oporavka, možete oporaviti MS SQL pomoću PITR oporavka ili koristiti LSN za vraćanje sustava u određeno stanje. Možete vratiti određeno stanje MS SQL baze podataka u bilo kojoj određenoj točki u vremenu, sve do sekunde. U slučaju sigurnosne kopije dnevnika transakcija MS SQL-a, prilikom vraćanja, stanje baze podataka će se vratiti iz različitih odabranih sigurnosnih kopija.

Značajke na prvi pogledautomatsko sigurnosno kopiranje i oporavak MS SQL-a s Bacula Enterpriseom

Bacula Systems je stvorio MS SQL Server backup plugin za korištenje s Bacula Enterprise Edition. Sigurnosno kopiranje MS SQL Servera s Baculom ima sljedeće značajke:

  • Podržava pune i diferencijalne MS SQL sigurnosne kopije
  • MS SQL podrška za inkrementalno sigurnosno kopiranje
  • MS SQL backup na mrežu i lokalni disk
  • Planirano MS SQL sigurnosno kopiranje
  • Izrada sigurnosnih kopija na razini MS SQL Server baze podataka
  • Mogućnost uključivanja/isključivanja baza podataka iz postupka izrade sigurnosne kopije
  • Podrška za stvaranje sigurnosnih kopija baze podataka samo za čitanje
  • Vraćanje MS SQL sigurnosnih kopija na disk
  • Slanje streama sigurnosna kopija izravno u Storage Daemon
  • MS SQL oporavak točke u vremenu

Pregled i konfiguracija sigurnosne kopije MS SQL 2008, 2008 R2, 2012 i 2014

U ovaj dokument predstavljena su rješenja za Bacula Enterprise Edition 8.4 i novije verzije, koja nisu podržana u ranijim verzijama softvera. MS SQL sigurnosna kopija baze podataka testirana je i podržavaju je MS SQL 2003 R2, MS SQL 2008 R2, MS SQL 2012, MS SQL 2005, MS SQL 2008, MS SQL 2014. MS SQL sigurnosna kopija iz Bacule može raditi sa SQL Expressom.

MS SQL Backup Glossary 2008, 2008 R2, 2012 i 2014

  • MS SQL stoji za Microsoft SQL Server.
  • Dnevnik transakcija. Svaka baza podataka MS SQL Servera ima dnevnik transakcija, koji bilježi sve transakcije i izmjene baze podataka izvršene tijekom takvih transakcija. Dnevnik transakcija je važan element baze podataka. U slučaju kvara sustava, dnevnik transakcija može biti potreban za vraćanje baze podataka u radno stanje. Više detaljne informacije naći ćete na https://msdn.microsoft.com/en-us/library/ms190925.aspx.
  • Diferencijalni backup MS SQL Server baze podataka. Diferencijalna sigurnosna kopija temelji se na posljednjoj punoj. Tijekom diferencijalne sigurnosne kopije bilježe se samo podaci koji su se promijenili od stvaranja zadnje pune sigurnosne kopije. Više informacija možete pronaći na https://msdn.microsoft.com/en-us/library/ms175526.aspx.
  • Puna sigurnosna kopija MS SQL Server baze podataka. Tijekom pune sigurnosne kopije baze podataka stvara se sigurnosna kopija cijele baze podataka. Sigurnosna kopija uključuje dio dnevnika transakcija u svrhu vraćanja kompletne baze podataka iz sigurnosne kopije. Pune sigurnosne kopije baze podataka sadrže bazu podataka u trenutku kada je sigurnosna kopija dovršena. Više informacija možete pronaći na https://msdn.microsoft.com/en-us/library/ms186289.aspx.
  • Sigurnosna kopija “samo kopija” (CopyOnly). Sigurnosne kopije samo za kopiranje su MS SQL sigurnosne kopije koje su neovisne o normalnom tijeku tradicionalnih sigurnosnih kopija SQL Servera. Ponekad je korisno stvoriti sigurnosne kopije za posebne potrebe bez utjecaja opći proces sigurnosno kopiranje i oporavak baze podataka. Više informacija možete pronaći na https://msdn.microsoft.com/en-us/library/ms191495.aspx.
  • VDI(Sučelje virtualnog uređaja) je Microsoftova tehnologija, omogućujući vam stvaranje imenovana cijev između programa.
  • standardne maske određuju skupove nizova sa zamjenskim znakovima. Na primjer, maska ​​standardne proizvodnje* uključivat će linije production1 i production2.
  • crta
  • cijeli broj.
  • LSN Svaki unos u zapisnik transakcija MS SQL Server identificiran je jedinstvenim serijskim brojem transakcije (LSN). Detaljnije informacije možete pronaći na https://technet.microsoft.com/en-us/library/ms190411%28v=sql.105%29.aspx.

Sigurnosna kopija MS SQL Server 2008, 2008 R2, 2012 i 2014

Puna sigurnosna kopija baza podataka MS SQL Server 2008, 2008 R2, 2012 i 2014

Tijekom pune sigurnosne kopije MS SQL baze podataka, spremaju se datoteke baze podataka i dnevnik transakcija, što vam omogućuje potpunu zaštitu MS SQL baze podataka u slučaju kvara medija. Ako je jedna ili više datoteka oštećeno, vraćanje MS SQL baze podataka iz sigurnosne kopije omogućit će vam vraćanje svih dovršenih transakcija. Sve transakcije koje su bile u tijeku također će biti vraćene. U ovaj način rada stvaraju se sigurnosne kopije master i mbdb baza podataka.

Diferencijalna sigurnosna kopija baza podataka MS SQL Server 2008, 2008 R2, 2012 i 2014

Diferencijalna sigurnosna kopija MS SQL Server baze podataka temelji se na najnovijoj punoj sigurnosnoj kopiji MS SQL baze podataka. Prilikom izrade diferencijalne MS SQL sigurnosne kopije, bilježe se samo podaci koji su promijenjeni od stvaranja zadnje pune MS SQL sigurnosne kopije. Za MS SQL funkciju diferencijalne sigurnosne kopije, redoslijed sigurnosne kopije je iznimno važan. Ako iz nekog razloga puna sigurnosna kopija koju navodi MS SQL nije dostupna, diferencijalne sigurnosne kopije baze podataka MS SQL Servera ne mogu se koristiti. Bacula MS SQL Backup koristi posebne tehnike za rješavanje ovog problema. Stoga, ako se pojave poteškoće, status diferencijalne sigurnosne kopije baze podataka može se automatski nadograditi na punu sigurnosnu kopiju.

Sigurnosna kopija dnevnika transakcija za MS SQL 2008, 2008 R2, 2012 i 2014

Postavljanje MS SQL sigurnosne kopije i konfiguracija baze podataka

Vraćanje MS SQL baze podataka iz sigurnosne kopije

Možete koristiti sve standardne metode pokretanje postupka vraćanja MS SQL baze podataka iz sigurnosne kopije. Međutim, morate osigurati da će u slučaju vraćanja diferencijalnih podataka, potpuna prethodna sigurnosna kopija MS SQL baze podataka također biti vraćena. U tom slučaju oporavak se događa automatski ako ga pokrenete u konzoli bkonzola korištenjem opcija oporavka 5 ili 12. U generiranoj strukturi datoteke trebate označiti oporavak punih baza podataka ili instanci DB-a.

Mogućnosti vraćanja MS SQL baze podataka iz sigurnosne kopije

Softver Bacula Enterprise Edition korisnicima omogućuje korištenje više opcija za oporavak MS SQL-a i primjenu najviše razne načine"vraćanje" baze podataka. Najčešće korištene opcije oporavka opisane su u nastavku:

  • Parametar Where: U slučaju Bacula Enterprise Edition, ovaj parametar omogućuje administratoru vraćanje baze podataka na određeno mjesto.
  • Parametar zamjene: Koristi se za definiranje kako bi se Bacula trebala ponašati s trenutnom bazom podataka kada se vrati. Bacula MS SQL sigurnosna kopija također vam omogućuje korištenje nekoliko dodatnih opcija prilikom vraćanja, kao što su:
  • Instanca: Budući da MS SQL koristi više instanci, sigurnosna kopija MS SQL baze podataka iz Bacule omogućuje vam da odaberete koju ćete instancu vratiti. Ovaj parametar nije obavezan, a ako nije naveden, prilikom vraćanja koristit će se vrijednost navedena prilikom stvaranja sigurnosne kopije. Prema zadanim postavkama koristi se instanca pod nazivom “MSSQLSERVER”.
  • Baza podataka. Ova opcija navodi naziv baze podataka za vraćanje i koristi vrijednost navedenu u vrijeme kada je baza podataka stvorena. Ovaj parametar nije obavezan. Prema zadanim postavkama, sigurnosne kopije baze podataka SQL Servera koriste parametar Where za određivanje naziva nove baze podataka. Ako je parametrom Gdje i Baza podataka dodijeljen važeći naziv baze podataka, koristit će se parametar Baza podataka.
  • Korisnik. Korisničko ime koje se koristi za povezivanje s instancom MS SQL baze podataka. Ovaj parametar nije obavezan, a ako nije naveden, prilikom vraćanja koristit će se vrijednost navedena prilikom izrade sigurnosne kopije.
  • Lozinka. Lozinka koja se koristi za povezivanje s instancom MS SQL baze podataka. Ovaj parametar nije obavezan, a ako nije naveden, prilikom vraćanja koristit će se vrijednost navedena prilikom izrade sigurnosne kopije.
  • Domena. Domena koja se koristi za povezivanje s instancom MS SQL baze podataka. Ovaj parametar nije obavezan, a ako nije naveden, prilikom vraćanja koristit će se vrijednost navedena prilikom izrade sigurnosne kopije.
  • Oporavak. Parametar vam omogućuje da odredite hoće li baza podataka biti vraćena u svoje prethodno stanje tijekom oporavka ili ne. Prema zadanim postavkama, prilikom vraćanja baze podataka, ona će se vratiti u prethodno stanje.
  • Zaustavi_prije_oznake. Uvjet SA ZAUSTAVLJANJEM ISPREDOZNAKE = Koristi se za označavanje da je unos dnevnika transakcija neposredno ispred oznake točka vraćanja. Točka oporavka može biti datum i vrijeme, LSN ili zastavica mark_name.
  • Stop_at_mark. Stanje SA ZNAKOM ZAUSTAVLJANJA = Koristi se za označavanje da je označena transakcija točka oporavka. STOPATMARK se pomiče naprijed do oznake i ponovno reproducira označenu transakciju. Točka oporavka može biti datum i vrijeme, LSN ili zastavica mark_name.
  • Stop_na= . Stanje SA STOPAT = se koristi za označavanje da je točka vraćanja datum/vrijeme.
  • Ograniči_korisnika. Klauzula WITH RESTRICT_USER koristi se za ograničavanje pristupa obnovljenoj bazi podataka. Zadana postavka je ne.

Vraćanje MS SQL-a na određeno vrijeme može se izvesti izravno iz dodatka za sigurnosno kopiranje MS SQL-a. Također možete vratiti datoteke lokalno i izvoditi operacije iz konzole za upravljanje Microsoft SQL Serverom kako biste dobili više funkcionalnosti.

LSN

LSN broj unosa dnevnika na kojem se dogodio određeni događaj sigurnosne kopije i oporavka može se vidjeti na jedan od sljedećih načina:

  • Prilikom prikaza opisa zadataka za izradu sigurnosne kopije pomoću softvera Bacula
  • U nazivu datoteke dnevnika
  • U tablici msdb.backupset
  • U tablici msdb.backupfile

Prilikom izvođenja zadatka stvaranja sigurnosne kopije MS SQL baze podataka, prilikom prikaza opisa zadatka bit će prikazane sljedeće informacije o LSN brojevima:

Broj Prvi LSN odgovara posljednjem LSN broju zadnje sigurnosne kopije dnevnika transakcija. Takva sigurnosna kopija može biti prva puna sigurnosna kopija ili posljednja sigurnosna kopija (inkrementalna).

Broj Zadnji LSN odgovara posljednjoj transakciji zabilježenoj u dnevniku.

U slučaju sigurnosne kopije dnevnika transakcija (inkrementalne), naziv datoteke povezane s ovom bazom podataka u zadatku za izradu inkrementalne sigurnosne kopije izgledat će ovako:

Broj u imenu, u našem slučaju 42000162001, odgovara zadnjem LSN broju prethodnog zadatka (za stvaranje pune ili inkrementalne sigurnosne kopije).

Slika 2: Prvi LSN, zadnji LSN i LSN-ovi u nazivima datoteka

Kao što je prikazano u primjeru na slici 2, ako administrator treba vratiti MS SQL bazu podataka u stanje koje odgovara LSN broju 14, mogu se izvršiti sljedeći koraci:

  • U izborniku za oporavak baze podataka koristite opciju 5
  • Izaberi posljednja datoteka puna sigurnosna kopija “data.bak” (LSN: 10)
  • Odaberite inkrementalnu sigurnosnu kopiju “log-10.trn”

Ili, ako najnovija puna sigurnosna kopija MS SQL Servera nije dostupna, ali je prethodna puna sigurnosna kopija dostupna, tada:

  • Koristite opciju vraćanja 3, odaberite odgovarajuće vrijednosti jobid-a
  • Odaberite direktorij baze podataka “/@mssql/db29187”
  • Odaberite datoteku pune sigurnosne kopije “data.bak” (LSN: 2)
  • Odaberite inkrementalne sigurnosne kopije “log-2.trn”, “log-3.trn”, “log-10.trn”
  • Postavite parametar stop_at_mark na "lsn:14"
  • Pokrenite zadatak za vraćanje sigurnosne kopije

MS SQL skripte za oporavak

Opis Gdje Baza podataka Primjer
Vratite datoteke na disk Staza gdje=c:/tmp
Vratite izvornu bazu podataka gdje=/
Vrati s novim imenom Ime gdje=newdb
Vrati s novim imenom Ime baza podataka=nova baza podataka
Oporavite s novim imenom i premjestite datoteke Ime

Tablica 1: Scenariji oporavka MS SQL-a

2.3.1 Vraćanje MS SQL baze podataka s izvornim nazivom

Za vraćanje baze podataka s izvornim nazivom, opcija Gdje ne smije biti navedena (prazna vrijednost) ili se mora navesti vrijednost “/” i parametar Zamijeniti mora se dodijeliti vrijednost Stalno, ili prvo morate izbrisati izvornu bazu podataka.

Vraćanje MS SQL sigurnosne kopije s novim imenom

Za vraćanje sigurnosne kopije MS SQL baze podataka s novim nazivom, možda ćete prvo morati premjestiti datoteke baze podataka na disk. Sve ovisi o tome postoji li izvorna baza podataka.

Ako izvorna baza podataka više nije dostupna, onda parametar gdje, ili polje "Opcije dodatka" može sadržavati naziv nove baze podataka. MS SQL Backup iz Bacule automatski će stvoriti bazu podataka s novim imenom.

Ako je izvorna baza podataka još uvijek potrebna, parametar where će se koristiti za premještanje datoteka na disk, a vi ćete morati imenovati novu bazu podataka pomoću izbornika Plugin Options. U stablu oporavka morate odabrati datoteku layout.dat.

Korištenje mog kataloga

Pokrenite zadatak oporavka MS SQL-a:

Koristeći Moj katalog, pokrenite zadatak oporavka MS SQL baze podataka:

Vratite MS SQL na lokalni disk

Ako navedete gdje=c:/put/, datoteke će biti vraćene na lokalni disk, a MS SQL administrator baze podataka moći će koristiti TSQL proceduralno proširenje za Microsoft SQL Server Management Console za vraćanje baze podataka. SQL naredbe potrebne za vraćanje baze podataka navedene su u opisu Rezultat posla kao što je prikazano na slici ispod.

Razmotrimo jednu nepoželjnu situaciju. Naime: iz nekog razloga baza podataka nije uspjela. Što imamo? Puna kopija, diferencijalna kopija za jučer, ali ima podataka i za danas, zar je stvarno bilo potrebno svaki sat raditi diferencijalnu kopiju? - Ne! Jesti Dnevnik transakcija.
Dnevnik transakcija - Dnevnik koji bilježi sve transakcije i sve promjene baze podataka izvršene svakom transakcijom. Oni. svaka radnja s bazom podataka bilježi se korak po korak u dnevniku. Svaki zapis označava DBMS kako bi se utvrdilo je li transakcija dovršena, je li dovršena ili nije. Uz njegovu pomoć možete vratiti stanje baze podataka ne samo nakon kvara, već iu slučaju neočekivanih radnji s podacima. Vratite se do određenog vremena. Kao i kod baze podataka, zapisnik transakcija mora imati sigurnosnu kopiju, potpunu, diferencijalnu, inkrementalnu. Da biste vratili dio dnevnika transakcija nakon kvara u intervalu između kreiranja sigurnosnih kopija, morate napraviti sigurnosnu kopiju posljednjeg fragmenta dnevnika, koji je zapravo točka finalizacije sigurnosne kopije. Izvršava se nakon neuspjeha, kao točka odbrojavanja.
Dakle, da bismo vratili bazu podataka nakon kvara, potrebna nam je trenutna puna kopija baze podataka, diferencijalna kopija baze podataka i kopija dnevnika transakcija.

Postoje 3 modela oporavka za samu bazu podataka - jednostavan, potpuni i masovno evidentiran. Smatrati:

  1. Jednostavan model - koristi se samo puna redundancija. Nema razlike sigurnosne kopije, kao i sigurnosne kopije dnevnika transakcija. Potpune kopije treba stvarati što je češće moguće. Relevantno za baze podataka koje se koriste "samo za čitanje".
  2. Model potpunog oporavka najčešće je korišten model u kojem su dostupne sve funkcije sigurnosnog kopiranja i oporavka podataka. Podržava oporavak pojedinačne stranice podaci. Transakcije se u potpunosti bilježe i dnevnik transakcija se sprema.
  3. Skupno zabilježeni model zamišljen je kao dopuna modelu potpunog oporavka. Većina masovnih operacija ne podržava bilježenje, i sukladno tome, ne podržava oporavak baze podataka do određene točke u vremenu.

Razmotrimo najnoviji lanac sigurnosnih kopija: Potpuna sigurnosna kopija - jednom tjedno, Diferencijalna sigurnosna kopija - jednom dnevno, Sigurnosna kopija dnevnika transakcija - jednom na sat.
Postoji nekoliko opcija za izradu sigurnosnih kopija:

  • Korištenje ugrađenog MS SQL planera zadataka
  • Korištenje Transact-SQL jezika
  • Korištenje sqlcmd i OS Task Scheduler
  • Ručno (što nam ne odgovara, jer zaposleni admin mora stalno petljati)

Razmotrimo prvu opciju kao najkorisniju. U tu svrhu koristi se Windows poslužitelj 2008 R2 Enterprise i MS SQL Server 2008 Eng.

Dakle, recimo da imamo TECH bazu podataka:

Prijeđimo na alat za stvaranje poslova:

Pritisnite desnu tipku miša i pozovite Master Joba:
Odaberite potvrdni okvir "Izvrši svaki zadatak zasebno", izvodimo samo jednu radnju

Majstor je bez turbana, ali veličina turbana nije glavna)) Odabiremo vrstu želje, u našem slučaju - puna rezervacija:

Majstor Joba je, kako se pokazalo, pomalo Židov, pa opet pita:

"Vrijedno je odabrati dodatne parametre, o mladi paddawan!":
Ovdje biramo bazu podataka, razdoblje pohrane sigurnosne kopije, adresu (traka ili disk), stazu spremanja i što je najvažnije - planer zadataka!

"Ne smijete zaboraviti na bazu podataka kada birate svoju. Koncentrirajte svoju snagu i odaberite bazu podataka":

“Žuri vam se prebrzo izraditi zadatak, kliknite na gumb na dnu s nazivom Raspored - Definiraj.”
Zapravo, planer zadataka, gdje biramo vrstu (ponoviti, jednom itd.), dan, vrijeme, vrstu početka:

To je to, mi smo ga stvorili. Master Joba je cool i zelen. Gledamo stanje u planovima održavanja:

Za paranoike, nemojte se bojati priznati to ogledalu, vrijedi pogledati u dušu SQL Server Agenta - Job Activity Monitor, Job Wizard pokazat će vam sve do detalja:

Sada, ako su ispunjeni navedeni uvjeti, treba napraviti punu sigurnosnu kopiju baze podataka. Koristeći isti princip, kreiraju se diferencijalna sigurnosna kopija i sigurnosna kopija dnevnika transakcija (ove se podstavke nalaze ispod "Potpuna sigurnosna kopija" na popisu za odabir zadataka).
Vrtite svoje MSSQL uši kako hoćete, nemojte ih odvrtati

U sljedećem članku - izrada pomoću Transact-SQL-a i par primjera.

Vratimo bazu podataka “Test _Recovery” u “ t 4».

Počnimo vraćati bazu podataka iz pune sigurnosne kopije "Full2_Test_Recovery.bak" koristeći "SQL Server Management Studio" " Klik desni klik miš temeljen na " Test_oporavak ", u izborniku koji se pojavi odaberite " Zadaci", zatim "Vrati", zatim "Baza podataka".

U prozoru koji se pojavi " Vrati bazu podataka" u odjeljku "Izvor" odaberite "Uređaj". Dalje « Dodaj ", unesite stazu "\\ vniz - tst - bkp 01. test . lokalni\Backup_SQL\Full 2_Test_Recovery. bak", kliknite "U redu". U odjeljku "Odredište" odaberite Baza podataka "Testni oporavak"

Kliknite "U redu"

Baza će biti uspješno obnovljena.

Pogledajmo vraćanje baze podataka pomoću Transact-SQL-a.

Desnom tipkom miša kliknite bazu podataka "Test_Recovery" i odaberite "Novi upit" iz izbornika koji se pojavi:

U prozor koji se pojavi unesite:

KORISTITI ovladati; majstorski

VRATITI DATABASE Test_Recovery

IZ DISK = "\\vniz-tst-bkp01.test.local\Backup_SQL\Full2_Test_Recovery.bak"

S ZAMIJENITI

Baza će biti uspješno obnovljena.

U ovom smo primjeru koristili parametar "REPLACE":

Oporavak obično sprječava da baza podataka slučajno prebriše druga baza podataka. Ako baza podataka navedena u izrazu RESTORE već postoji na trenutnom poslužitelju, a GUID obitelji za navedenu bazu podataka je različit od GUID-a obitelji za bazu podataka snimljenu u skupu sigurnosne kopije, tada baza podataka neće biti vraćena.

Opcija REPLACE nadjačava nekoliko važnih provjera koje se obično izvode operacijom vraćanja. Sljedeće provjere su otkazane.

  • Provjera vraćanja sigurnosne kopije stvorene za drugu bazu podataka preko postojeće baze podataka.Kada koristite opciju REPLACE, vraćanje može pisati podatke preko postojeće baze podataka, bez obzira na to koje su baze podataka sadržane u skupu sigurnosne kopije, čak i ako je navedeno ime podataka različito od onoga što je zapisano u skupu sigurnosne kopije. To može dovesti do slučajnog brisanja baze podataka drugom bazom podataka.
  • Testiranje oporavka baze podataka koja koristi model potpunog oporavka ili model oporavka s skupnim zapisom za koji nije napravljena sigurnosna kopija zadnjeg dnevnika i nije primijenjena opcija STOPAT.Kada koristite opciju ZAMIJENI, možete izgubiti predane podatke jer posljednji zabilježeni podaci još nisu kopirani u sigurnosnu kopiju.
  • Prebrišite postojeće datoteke.

Administratori baza podataka dijele se na one koji rade sigurnosne kopije i one koji će raditi sigurnosne kopije.

Uvod

Ovaj članak opisuje najčešći 1C IB backup pomoću alata MS SQL Server 2008 R2, objašnjava zašto biste to trebali učiniti na ovaj način, a ne drugačije, i razbija nekoliko mitova. Članak sadrži dosta referenci na MS SQL dokumentaciju; ovaj je članak više pregled mehanizama sigurnosnog kopiranja nego opsežan vodič. Ali za one koji se prvi put susreću s ovim zadatkom, jednostavno i upute korak po korak, koji se odnose na jednostavne situacije. Članak nije namijenjen guruima administracije, gurui to već znaju, ali pretpostavlja se da je čitatelj u stanju sam instalirati MS SQL Server i natjerati ovo čudo neprijateljske tehnologije da u svojim dubinama stvori bazu podataka, što je pak on sposoban prisiliti na pohranjivanje 1C podataka.

Smatram da je naredba TSQL BACKUP DATABASE (i njen brat BACKUP LOG) u biti jedino sredstvo za sigurnosno kopiranje 1C baza podataka koristeći MS SQL Server kao DBMS. Zašto? Pogledajmo koje metode općenito imamo:

Kako Fino Loše Ukupno
Upload na dt Vrlo kompaktan format. Potrebno je puno vremena da se formira, zahtijeva isključivi pristup, ne sprema neke nevažne podatke (kao što su korisničke postavke u ranijim verzijama) i dugo je potrebno za implementaciju. To nije toliko način sigurnosne kopije koliko način premještanja podataka iz jednog okruženja u drugo. Idealno za uske kanale.
Kopiranje mdf i ldf datoteka Vrlo jasan način za administratore početnike. Zahtijeva oslobađanje datoteka baze podataka od zaključavanja, a to je moguće ako je baza podataka izvan mreže (naredba take offline kontekstni izbornik), je odvojen (detach) ili je poslužitelj jednostavno zaustavljen. Očito, korisnici u ovom trenutku neće moći raditi. Ovu metodu ima smisla koristiti ako i samo ako se nesreća već dogodila, tako da pri pokušaju oporavka imate barem priliku vratiti se na opciju s koje je oporavak započeo.
Sigurnosno kopiranje pomoću OS-a ili hipervizora Prikladan način za razvojna i testna okruženja. Nije uvijek prijatelj s integritetom podataka. Resursno intenzivna metoda. Može imati ograničenu upotrebu za razvoj. To nema praktično značenje u prehrambenom okruženju.
Sigurnosno kopiranje pomoću MS SQL-a Nema prekida rada. Omogućuje vam vraćanje potpunog stanja u proizvoljnom trenutku, ako se o tome unaprijed brinete. Izvrsna automatizacija. Ekonomičan u vremenu i drugim resursima. Nije baš kompaktan format. Ne znaju svi koristiti ovu metodu u potrebnoj mjeri. Za prehrambena okruženja - glavni alat.

Glavne poteškoće pri korištenju sigurnosne kopije pomoću ugrađenih MS SQL alata proizlaze iz osnovnog nerazumijevanja principa rada. Dijelom se to objašnjava velikom lijenošću, dijelom nepostojanjem jednostavnog i razumljivog objašnjenja na razini “gotovih recepata” (hm, recimo, nisam naišao na takav), a situacija je i otežana po mitološkim savjetima “undergurua” na forumima. Ne znam što da radim s lijenošću, ali pokušat ću objasniti osnove backupa.

Što i zašto štedimo?

Prije mnogo vremena, u dalekoj galaksiji, postojao je takav proizvod inženjerske i računovodstvene misli kao što je 1C: Enterprise 7.7. Očito zbog činjenice da su prve verzije 1C:Enterprise razvijene za korištenje popularnog formata dbf datoteke, njegova SQL verzija nije pohranila dovoljno informacija u bazu da bi se sigurnosna kopija MS SQL-a smatrala potpunom, a čak i sa svakom promjenom strukture narušavali su se radni uvjeti modela potpunog oporavka, pa je bilo potrebno pribjeći raznim trikove za prisiljavanje rezervnog sustava da obavlja svoju glavnu funkciju. Ali otkako je izašla verzija 8, administratori baze podataka su se konačno mogli opustiti. Standardni alati za izradu sigurnosnih kopija omogućuju vam stvaranje potpunog i holističkog sustava za izradu sigurnosnih kopija. Jedino logbook i neke sitnice poput postavki položaja formi (u starijim verzijama) nisu uključene u backup, ali gubitak tih podataka ne utječe na funkcionalnost sustava, iako je svakako ispravno i korisno napravite sigurnosne kopije dnevnika.

Zašto nam uopće treba rezervna kopija? Hm. Na prvi pogled čudno pitanje. Pa, vjerojatno, prvo, da biste mogli implementirati kopiju sustava i drugo, da vratite sustav u slučaju kvara? Slažem se oko prvog, ali druga svrha je prvi rezervni mit.

Sigurnosna kopija je zadnja linija sigurnosti sustava. Ako administrator baze podataka mora vratiti sustav proizvoda iz sigurnosnih kopija, vrlo je vjerojatno da su napravljene mnoge ozbiljne pogreške u organizaciji rada. Sigurnosnu kopiju ne možete smatrati glavnim načinom osiguranja integriteta podataka; ne, ona je bliže sustavu za gašenje požara. Potreban je sustav za gašenje požara. Mora biti konfiguriran, testiran i operativan. Ali ako je uspjelo, onda je to samo po sebi ozbiljna hitna situacija s puno negativnih posljedica.

Kako biste osigurali da se sigurnosna kopija koristi samo u "miroljubive" svrhe, upotrijebite druga sredstva za osiguranje performansi:

  • Osigurajte fizičku sigurnost svojih poslužitelja: požari, poplave, loše napajanje, čistači, građevinski radnici, meteoriti i divlje životinje čekaju iza ugla da unište vašu sobu s poslužiteljima.
  • Odgovorno se pozabavite prijetnjama informacijskoj sigurnosti.
  • Učinite promjene u sustavu vješto i unaprijed se uvjerite da te promjene neće dovesti do pogoršanja. Osim plana za uvođenje promjena, poželjno je imati i plan “što učiniti ako sve pođe po zlu”.
  • Aktivno koristite tehnologije za povećanje dostupnosti i pouzdanosti sustava umjesto kasnijeg suočavanja s posljedicama nesreća. Za MS SQL trebate obratiti pozornost na sljedeće značajke:
    • Korištenje MS SQL klastera (iako, da budem iskren, mislim da je ovo jedan od najskupljih i beskorisnih načina zaokupljanja administratora baze podataka za sustave koji ne zahtijevaju 24x7)
    • Zrcaljenje baze podataka (sinkrono i asinkrono ovisno o dostupnosti, performansama i zahtjevima troškova)
    • Isporuka dnevnika transakcija
    • Replikacija pomoću 1C alata (distribuirane baze podataka)

Ovisno o zahtjevima dostupnosti sustava i proračunu dodijeljenom za te svrhe, sasvim je moguće odabrati rješenja koja će smanjiti vrijeme zastoja i vrijeme oporavka od kvara za 1-2 reda veličine. Ne treba se bojati tehnologija pristupačnosti: dovoljno su jednostavne da ih možete naučiti u nekoliko dana uz osnovno poznavanje MS SQL-a.

No, bez obzira na sve, sigurnosna kopija je i dalje neophodna. Ovo je isti rezervni padobran koji možete koristiti kada sva druga sredstva spašavanja zakažu. Ali, kao pravi rezervni padobran, za ovo:

  • ovaj sustav mora biti unaprijed ispravno i profesionalno konfiguriran,
  • stručnjak koji koristi sustav mora imati teorijske i praktične vještine u njegovom korištenju (redovito pojačane),
  • sustav bi se trebao sastojati od najpouzdanijih i najjednostavnijih komponenti (ovo je naša posljednja nada).

Osnove pohranjivanja i obrade MS SQL podataka

Podaci u MS SQL-u obično se pohranjuju u podatkovne datoteke (u daljnjem tekstu FD - skraćenica koja se ne koristi često; u ovom članku bit će još nekoliko ne baš uobičajenih kratica) s nastavcima mdf ili ndf. Osim ovih datoteka, postoje i zapisnici transakcija (TL), koji su pohranjeni u datotekama s nastavkom .ldf. Administratori početnici često su neodgovorni i neozbiljni kada je riječ o VT-u, kako u pogledu performansi, tako i u pogledu pouzdanosti pohrane. Ovo je vrlo ozbiljna greška. Zapravo je upravo suprotno, ako postoji pouzdano funkcionirajući sustav sigurnosne kopije i može se izdvojiti mnogo vremena za vraćanje sustava, tada možete pohraniti podatke na brz, ali krajnje nepouzdan RAID-0, ali tada podaci moraju biti pohranjeni na zasebnom pouzdanom i produktivnom resursu (iako bi bili na RAID-1). Zašto je to? Pogledajmo pobliže. Dopustite mi da odmah napomenem da je prezentacija donekle pojednostavljena, ali dovoljna za početno razumijevanje.

FD pohranjuje podatke na stranicama od 8 kilobajta (koje se kombiniraju u opsege od 64 kilobajta, ali to nije značajno). MS SQL ne jamči da će odmah nakon izvršenja naredbe za promjenu podataka te promjene ići u FD. Ne, samo je stranica u memoriji označena kao "zahtijeva spremanje." Ako poslužitelj ima dovoljno resursa, uskoro će ti podaci biti na disku. Štoviše, poslužitelj radi "optimistično" i ako se te promjene dogode u transakciji, onda mogu završiti na disku prije nego što se transakcija izvrši. To jest, u općem slučaju, kada aktivan rad FD sadrži razbacane dijelove nedovršenih podataka i nedovršenih transakcija za koje se ne zna hoće li biti otkazane ili predane. Postoji posebna naredba "CHECKPOINT", koja govori poslužitelju da mora isprazniti sve nespremljene podatke na disk "odmah", ali opseg ove naredbe je prilično specifičan. Dovoljno je reći da ga 1C ne koristi (nisam ga susreo) i razumjeti da tijekom rada FD obično nije u netaknutom stanju.

Da bismo se nosili s ovim kaosom, samo nam treba VT. U njemu su zabilježeni sljedeći događaji:

  • Podaci o početku transakcije i njen identifikator.
  • Informacije o činjenici izvršenja ili otkazivanja transakcije.
  • Informacije o svim promjenama podataka u FD (ugrubo rečeno, što se dogodilo i što se dogodilo).
  • Informacije o promjenama samog FD-a ili strukture baze podataka (povećanje datoteka, smanjenje datoteka, dodjela i oslobađanje stranica, stvaranje i brisanje tablica i indeksa)

Sve te informacije su napisane navodeći identifikator transakcije u kojoj su se dogodile i u dovoljnoj količini da se razumije kako se premjestiti iz stanja prije ove operacije u stanje nakon ove operacije i obrnuto (iznimka je model oporavka s djelomičnim zapisom) .

Važno je da se te informacije odmah zapišu na disk. Sve dok se informacija ne zabilježi u VT, naredba se ne smatra izvršenom. U normalnoj situaciji, kada je veličina VT-a dovoljna i kada nije jako fragmentiran, zapisi se u njega upisuju sekvencijalno u malim zapisima (ne nužno višekratnicima od 8 kb). Samo podaci koji su stvarno potrebni za oporavak uključeni su u dnevnik transakcija. Posebno Ne dobivaju se informacije o tome koji je tekst zahtjeva doveo do izmjena, kakav je plan izvršenja taj zahtjev imao, koji ga je korisnik pokrenuo i druge informacije nepotrebne za oporavak. Upit može pružiti određeni uvid u strukturu podataka dnevnika transakcija

Odaberite * iz::fn_dblog(null,null)

Zbog tvrdih diskova Oni rade mnogo učinkovitije sa sekvencijalnim pisanjem nego sa kaotičnim protokom naredbi za čitanje i pisanje, a zbog činjenice da će SQL naredbe čekati do kraja pisanja u VT, javlja se sljedeća preporuka:

Ako postoji i najmanja mogućnost, tada bi u okruženju proizvoda VT trebali biti smješteni na odvojenom (od svega ostalog) fizičkom mediju, po mogućnosti s minimalnim vremenom pristupa za sekvencijalno snimanje i s maksimalnom pouzdanošću. Za jednostavni sustavi RAID-1 je sasvim prikladan.

Ako je transakcija otkazana, tada će poslužitelj vratiti sve već napravljene promjene u prethodno stanje. Iz tog razloga

Otkazivanje transakcije u MS SQL Serveru obično traje usporedivo s ukupnim trajanjem operacija promjene podataka same transakcije. Pokušajte ne otkazati transakcije ili donesite odluku o otkazivanju što je prije moguće.

Ako poslužitelj iz nekog razloga neočekivano prestane s radom, tada će se prilikom njegovog ponovnog pokretanja analizirati koji podaci u FD-u ne odgovaraju integralnom stanju (nezabilježene, a izvršene transakcije i evidentirane, ali poništene transakcije) te će se ti podaci ispraviti. Stoga, ako ste, na primjer, započeli s ponovnom izgradnjom indeksa velike tablice i ponovno pokrenuli poslužitelj, tada će, kada ga ponovno pokrenete, trebati dosta vremena za vraćanje ove transakcije i ne postoji način da se ovaj proces prekine .

Što se događa kada VT dođe do kraja datoteke? Jednostavno je - ako na početku ima slobodnog prostora, on će početi upisivati slobodno mjesto na početku datoteke na zauzeti prostor. Poput zamotane magnetske trake. Ako nema prostora na početku, tada će poslužitelj obično pokušati proširiti datoteku dnevnika transakcija, dok je za poslužitelja novi dio dodijeljen nova virtualna datoteka dnevnika transakcija, kojih može biti puno u datoteci fizičkog transakcija. , ali to nema mnogo veze sa sigurnosnom kopijom. Ako poslužitelj ne uspije proširiti datoteku (ponestalo je prostora na disku ili postavke zabranjuju proširenje datoteke), tada će se trenutna transakcija otkazati s pogreškom 9002.

ups Što treba učiniti da u željeznici uvijek bude mjesta? Ovdje dolazimo do sustava sigurnosne kopije i modela oporavka. Za otkazivanje transakcija i vraćanje ispravnog stanja poslužitelja u slučaju iznenadnog gašenja, potrebno je pohraniti zapise u JT, počevši od početka najranije otvorene transakcije. Ovaj minimum je napisan i pohranjen u ZhT Obavezno. Bez obzira na vrijeme, postavke servera i želje admina. Poslužitelj ne može dopustiti da te informacije ne postoje. Stoga, ako otvorite transakciju u jednoj sesiji i izvršite različite radnje u drugima, dnevnik transakcija može neočekivano završiti. Najstarija transakcija se može identificirati pomoću DBCC OPENTRAN naredbe. Ali ovo je samo potreban minimum informacija. Što će se dalje dogoditi ovisi o modeli oporavka. Postoje tri od njih u SQL Serveru:

  • Jednostavan— pohranjuje se samo ostatak VT neophodan za život.
  • puna— cijeli VT je pohranjen od posljednje sigurnosne kopije dnevnik transakcija. Napomena, ne od trenutka pune sigurnosne kopije!
  • Skupno evidentirano— dio (obično vrlo mali dio) operacija se bilježi u vrlo kompaktnom formatu (u suštini samo zapis da je ta i ta stranica podatkovne datoteke promijenjena). Inače identičan Fullu.

Nekoliko je mitova povezanih s modelima oporavka.

  • Jednostavno vam omogućuje smanjenje opterećenja diskovnog podsustava. To je pogrešno. upisuje se točno isti iznos kao kod Bulk logged, samo što se mnogo ranije smatra besplatnim.
  • Skupno evidentiranje omogućuje smanjenje opterećenja diskovnog podsustava. Za 1C to gotovo nije slučaj. Zapravo, jedna od rijetkih operacija koja može potpasti pod minimalno evidentiranje bez dodatnih plesova s ​​tamburom je učitavanje podataka iz uploada u dt formatu i restrukturiranje tablica.
  • Pri korištenju modela skupne evidencije, neke transakcije nisu uključene u sigurnosnu kopiju dnevnika transakcija i ne dopušta vam vraćanje stanja u vrijeme izrade ove sigurnosne kopije. Ovo nije posve točno. Ako se operacija minimalno bilježi, tada će trenutne stranice s podacima biti uključene u sigurnosnu kopiju i bit će moguće "reprodukovati" dnevnik transakcija do kraja (iako to nije moguće u proizvoljnom trenutku ako postoje minimalno zabilježene operacije).

Gotovo je besmisleno koristiti Bulk logged model za 1C baze podataka, stoga ga dalje ne razmatramo. No izbor između Full i Simple razmotrit ćemo detaljnije u sljedećem dijelu.

  • Struktura dnevnika transakcija
    • Modeli oporavka i upravljanje dnevnikom transakcija
    • Upravljanje dnevnikom transakcija
  • Korištenje sigurnosnih kopija dnevnika transakcija

Kako radi sigurnosno kopiranje u modelima jednostavnog i potpunog oporavka

Ovisno o vrsti formiranja, sigurnosne kopije dijele se na tri vrste:

  • puna(puno)
  • Diferencijal(Razlika, razlika)
  • Dnevnik(Sigurnosna kopija dnevnika transakcija, s obzirom na to koliko se često ovaj izraz koristi, skratit ćemo ga na RKZhT)

Neka vas ovdje ne zbuni: model potpunog oporavka i puna sigurnosna kopija bitno su različite stvari. Kako ih ne bi zbunili, u nastavku ću koristiti engleske izraze za model oporavka i ruske izraze za vrste sigurnosnih kopija.

Puna i diferencijalna kopija rade isto za Jednostavnu i Punu. Sigurnosna kopija dnevnika transakcija u potpunosti nedostaje u Simpleu.

Potpuna sigurnosna kopija

Omogućuje vraćanje stanja baze podataka u određeno vrijeme (na ono u kojem je sigurnosno kopiranje pokrenuto). Sastoji se od kopije stranice po stranicu iskorištenog dijela podatkovnih datoteka i aktivnog dijela dnevnika transakcija tijekom vremena izrade sigurnosne kopije.

Diferencijalna sigurnosna kopija

Pohranjuje stranice s podacima koji su se promijenili od zadnje pune sigurnosne kopije. Prilikom vraćanja prvo morate vratiti potpunu sigurnosnu kopiju (u načinu NORECOVERY, primjeri će biti navedeni u nastavku), a zatim možete primijeniti bilo koju od sljedećih diferencijalnih kopija na rezultirajuću "praznu", ali, naravno, samo od onih napravljenih prije sljedeću punu sigurnosnu kopiju. Zbog toga možete značajno smanjiti glasnoću prostor na disku za pohranu sigurnosne kopije.

Važne točke:

  • Bez prethodne pune sigurnosne kopije, diferencijalna kopija je beskorisna. Stoga ih je preporučljivo pohraniti negdje blizu jedno drugome.
  • Svaka sljedeća diferencijalna sigurnosna kopija zadržat će sve stranice uključene u prethodnu diferencijalnu sigurnosnu kopiju snimljenu nakon prethodne pune sigurnosne kopije (iako možda s drugačijim sadržajem). Stoga je svaka sljedeća diferencijalna kopija veća od prethodnih, sve dok se ponovno ne napravi potpuna kopija (ako je ovo prekršeno, to je samo zbog algoritama kompresije)
  • Za oporavak u nekom trenutku to je dovoljno posljednji puna sigurnosna kopija u ovom trenutku i posljednji diferencijalna kopija u ovom trenutku. Međukopije nisu potrebne za oporavak (iako mogu biti potrebne za odabir trenutka oporavka)

RKZhT

Sadrži kopiju VT za određeno razdoblje. Obično od trenutka posljednjeg RKZhT do formiranja sadašnjeg RKZhT. RKZHT vam omogućuje vraćanje stanja iz kopije vraćene u načinu NORECOVERY u bilo kojem trenutku uključenom u razdoblje vraćene kopije ZHT-a u bilo kojem sljedećem trenutku uključenom u interval vraćene sigurnosne kopije. Prilikom izrade sigurnosne kopije sa standardnim parametrima, oslobađa se prostor u datoteci dnevnika transakcija (do trenutka zadnje otvorene transakcije).

Očito, RKZhT nema smisla u Jednostavnom modelu (tada ZhT sadrži samo informacije od trenutka posljednje nezatvorene transakcije).

Kada koristite RKZhT, pojavljuje se važan koncept - kontinuirani lanac RKZhT. Ovaj lanac se može prekinuti ili gubitkom nekih sigurnosnih kopija ovog lanca, ili pretvaranjem baze podataka u Jednostavnu i natrag.

Pažnja: skup RKZhT je u biti beskoristan ako nije kontinuirani lanac, a početna točka zadnje uspješne pune ili diferencijalne sigurnosne kopije mora biti iznutra period ovog lanca.

Uobičajene zablude i mitovi:

  • "RKZhT sadrži podatke dnevnika transakcija od trenutka prethodne pune ili diferencijalne sigurnosne kopije." Ne, to nije istina. RKZhT također sadrži, na prvi pogled, beskorisne podatke između prethodnog RKZhT-a i sljedeće pune sigurnosne kopije.
  • "Puna ili diferencijalna sigurnosna kopija trebala bi osloboditi prostor unutar dnevnika transakcija." Ne, to nije istina. Pune i diferencijalne sigurnosne kopije ne utječu na RKZhT lanac.
  • VT je potrebno povremeno ručno očistiti, smanjiti i usitniti. Ne, nije potrebno i, naprotiv, nepoželjno je. Ako otpustite VT između RCVT, RCVT lanac potreban za obnovu bit će prekinut. A stalno smanjenje/proširenje datoteke dovest će do njezine fizičke i logičke fragmentacije.

Kako to radi jednostavno

Neka postoji baza podataka od 1000 GB. Svaki dan baza raste za 2 GB, dok se mijenja 10 GB starih podataka. Napravljene su sljedeće sigurnosne kopije

  • Puna kopija F1 od 0:00 1. veljače (volumen 1000 GB, kompresija nije uzeta u obzir zbog jednostavnosti slike)
    • Diferencijalna kopija D1.1 od 0:00 2. veljače (volumen 12 GB)
    • Diferencijalna kopija D1.2 od 0:00 3. veljače (volumen 19 GB)
    • Diferencijalna kopija D1.3 od 0:00 4. veljače (volumen 25 GB)
    • Diferencijalna kopija D1.4 od 0:00 5. veljače (volumen 31 GB)
    • Kopija razlike D1.5 od 0:00 6. veljače (volumen 36 GB)
    • Diferencijalna kopija D1.6 od 0:00 7. veljače (volumen 40 GB)
  • Puna kopija F2 od 0:00 8. veljače (volumen 1014 GB)
    • Diferencijalna kopija D2.1 od 0:00 9. veljače (volumen 12 GB)
    • Diferencijalna kopija D2.2 od 0:00 10. veljače (volumen 19 GB)
    • Diferencijalna kopija D2.3 od 0:00 11. veljače (volumen 25 GB)
    • Diferencijalna kopija D2.4 od 0:00 12. veljače (volumen 31 GB)
    • Kopija razlike D2.5 od 0:00 13. veljače (volumen 36 GB)
    • Diferencijalna kopija D2.6 od 0:00 14. veljače (volumen 40 GB)

Pomoću ovog skupa možemo vratiti podatke u 0:00 bilo kojeg dana od 1. do 14. veljače. Da bismo to učinili, moramo uzeti punu kopiju F1 za tjedan od 1. do 7. veljače ili punu kopiju F2 za 8. do 14. veljače, vratiti je u NORECOVERY modu i zatim primijeniti diferencijalnu kopiju željenog dana.

Kako radi u potpunosti

Neka nam bude isti skup pune sigurnosne kopije i diferencijalne sigurnosne kopije kao u prethodnom primjeru. Pored ovoga, postoje sljedeći RKZhT:

  • RKZhT 1 za razdoblje od 12:00 31. siječnja do 12:00 2. veljače (oko 30 GB)
  • RKZhT 2 za razdoblje od 12:00 2. veljače do 12:00 4. veljače (oko 30 GB)
  • RKZhT 3 za razdoblje od 12:00 4. veljače do 12:00 6. veljače (oko 30 GB)
  • RKZhT 4 za razdoblje od 12:00 6. veljače do 12:00 7. veljače (oko 30 GB)
  • RKZhT 5 za razdoblje od 12:00 8. veljače do 12:00 10. veljače (oko 30 GB)
  • RKZhT 6 za razdoblje od 12:00 10. veljače do 12:00 12. veljače (oko 30 GB)
  • RKZhT 7 za razdoblje od 12:00 12. veljače do 12:00 14. veljače (oko 30 GB)
  • RKZhT 8 za razdoblje od 12:00 14. veljače do 12:00 16. veljače (oko 30 GB)

Bilješka:

  1. Veličina RKZhT-a bit će približno konstantna.
  2. Sigurnosne kopije možemo raditi rjeđe nego diferencijalne ili pune, ili ih možemo raditi češće, tada će biti manje veličine.
  3. Sada možemo vratiti stanje sustava na bilo koju točku od 0:00 1. veljače, kada imamo najraniju potpunu kopiju, do 12:00 16. veljače.

U samom jednostavan slučaj Za obnovu trebamo:

  1. Zadnja puna kopija prije oporavka
  2. Zadnja diferencijalna kopija prije oporavka
  3. Svi RKZhT, od trenutka posljednjeg razlikovnog primjerka do trenutka obnove
  • Puna kopija F2 od 0:00 8. veljače
  • Razlika primjerak D2.2 od 0:00 10. veljače
  • RKZhT 6 za razdoblje od 12:00 10. siječnja do 12:00 12. veljače

Prvo će se obnoviti F2, zatim D2.2, zatim RKZhT 6 do 13:13:13 10. veljače. Ali značajna prednost Full modela je ta što imamo izbor - koristiti posljednju punu ili diferencijalnu kopiju ili NE posljednju. Na primjer, ako se otkrije da je kopija D2.2 oštećena, a mi je trebamo vratiti na trenutak prije 13:13:13 10. veljače, tada bi za Jednostavni model to značilo da možemo vratiti samo podaci do trenutka D2.1. Uz Full - "DON"T PANIC", imamo sljedeće mogućnosti:

  1. Vratite F2, zatim D2.1, zatim RKZHT 5, zatim RKZHT 6 do 13:13:13 10. veljače.
  2. Vratite F2, zatim RKZHT 4, zatim RKZHT 5, zatim RKZHT 6 do 13:13:13 10. veljače.
  3. Ili čak vratite F1 i pokrenite sve RKZhT do RKZhT 6 do 13:13:13 10. veljače.

Kao što vidite, puni model daje nam više izbora.

Sada zamislimo da smo vrlo lukavi. I par dana prije neuspjeha (13:13:13 10. veljače) znamo da će biti neuspjeha. Vraćamo bazu podataka na susjednom poslužitelju iz potpune sigurnosne kopije, ostavljajući mogućnost smotanja sljedećih stanja s diferencijalnim kopijama ili RKZhT, tj. ostavili smo je u NORECOVERY modu. I svaki put, odmah nakon formiranja RKZhT-a, primjenjujemo ga na ovu pričuvnu bazu, ostavljajući je u načinu NORECOVERY. Wow! Zašto, sada će nam trebati samo 10-15 minuta da vratimo bazu podataka, umjesto vraćanja ogromne baze podataka! Čestitamo, ponovno smo izmislili otpremu trupaca, jedan od načina za smanjenje zastoja. Ako prenosite podatke na ovaj način ne jednom u razdoblju, već stalno, tada ćete dobiti zrcaljenje, a ako izvorna baza čeka da se baza zrcala ažurira, onda je to sinkrono zrcaljenje, ako ne čeka, onda je asinkrono .

Više o alatima visoke dostupnosti možete pročitati u pomoći:

  • Visoka dostupnost (motor baze podataka)
    • Razumijevanje rješenja visoke dostupnosti
    • Visoka razina pristupačnosti. Interakcija i suradnja

Ostala razmatranja sigurnosne kopije

Možete slobodno preskočiti ovaj odjeljak ako vam je dosadila teorija i želite li isprobati sigurnosne postavke.

Grupe datoteka

1C:Enterprise u biti ne zna kako raditi s grupama datoteka. Postoji jedna grupa datoteka i to je to. Zapravo, programer ili administrator MS SQL baze podataka može staviti neke tablice, indekse ili čak dijelove tablica i indeksa u zasebne grupe datoteka (u najjednostavnijoj verziji - u zasebne datoteke). To je potrebno ili radi ubrzanja pristupa nekim podacima (smještanjem na vrlo brze medije) ili obrnuto, žrtvovanjem brzine i stavljanjem na jeftinije medije (primjerice, malo korišteni, ali obimni podaci). Kada radite s grupama datoteka, moguće ih je zasebno izraditi sigurnosne kopije, a možete ih i zasebno restaurirati, ali morate uzeti u obzir da će se sve grupe datoteka morati “uhvatiti” do jedne točke okretanjem RKZhT.

Datoteke s podacima

Ako osoba upravlja smještanjem podataka u različite grupe datoteka, onda kada postoji nekoliko datoteka unutar grupe datoteka, tada MS SQL Server gura podatke u njih neovisno (ako je volumen datoteka jednak, pokušat će ravnomjerno). Sa gledišta aplikacije, ovo se koristi za paralelizaciju I/O operacija. Ali sa stajališta sigurnosnih kopija, postoji još jedna stvar. Za vrlo velike baze podataka u eri prije SQL-a 2008. bio je tipičan problem dodijeliti kontinuirani prozor za punu sigurnosnu kopiju, a odredišni disk za ovu sigurnosnu kopiju možda je jednostavno ne bi primio. Najviše na jednostavan način u ovom slučaju, to je bilo sigurnosno kopiranje svake datoteke (ili grupe datoteka) u vlastiti prozor. Sada, s aktivnim širenjem kompresije sigurnosne kopije, ovaj problem je postao manji, ali ovu tehniku ​​još uvijek možete imati na umu.

Sigurnosna kompresija

MS SQL Server 2008 predstavio je super-mega-ultra značajku. Od sada pa zauvijek sigurnosne kopije mogu se komprimirati kada se generiraju u hodu. Ovo smanjuje veličinu sigurnosne kopije baze podataka 1C za 5-10 puta. A s obzirom na to da je izvedba diskovnog podsustava obično usko grlo DBMS-a, to ne samo da smanjuje troškove pohrane, već i znatno ubrzava backup (iako se opterećenje procesora povećava, ali obično je snaga procesora sasvim dovoljna na DBMS poslužitelj).

Ako je u verziji 2008. ova značajka bila dostupna samo za izdanje Enterprise (koje je vrlo skupo), onda je u 2008. R2 ova značajka dana standardnoj verziji, što je vrlo ugodno.

Postavke kompresije nisu obuhvaćene primjerima u nastavku, ali toplo preporučam korištenje kompresije sigurnosne kopije osim ako postoji poseban razlog da se onemogući.

Jedna sigurnosna kopija - mnogo internih dijelova

Zapravo, sigurnosna kopija nije samo datoteka, to je prilično složen spremnik u koji se mogu pohraniti mnoge sigurnosne kopije. Ovaj pristup ima vrlo davnu povijest (osobno ga promatram od verzije 6.5), ali u ovom trenutku za administratore "običnih" baza podataka, posebno 1C baza podataka, nema ozbiljnih razloga da ne koriste "jedna sigurnosna kopija - jedan file” pristup . Za opći razvoj Korisno je istražiti mogućnost stavljanja nekoliko sigurnosnih kopija u jednu datoteku, ali najvjerojatnije je nećete morati koristiti (ili ako to učinite, bit će to rješavanje ruševina potencijalnog administratora koji je nekvalificirano koristio ovu značajku ).

Više zrcalnih kopija

SQL Server ima još jednu sjajnu značajku. Sigurnosnu kopiju možete napraviti paralelno u nekoliko prijamnika. Kako najjednostavniji primjer, možete ispisati jednu kopiju na lokalni disk i istovremeno je staviti mrežni resurs. Lokalna kopija je prikladna jer je oporavak s nje mnogo brži; udaljena kopija će puno bolje podnijeti fizičko uništenje glavnog poslužitelja baze podataka.

Primjeri backup sustava

Dosta teorije. Vrijeme je da praksom dokažete da cijela ova kuhinja funkcionira.

Postavljanje tipične rezervacije poslužitelja putem planova održavanja

Ovaj dio je strukturiran u obliku gotovih recepata s objašnjenjima. Ovaj dio je jako dosadan i dugačak zbog slika, pa ga možete preskočiti.

Korištenje čarobnjaka za izradu plana usluge

Postavljanje sigurnosne kopije poslužitelja pomoću TSQL skripti, primjeri nekih značajki

Odmah se postavlja pitanje što je još potrebno? Čini se kao da ste upravo sve postavili i sve radi kao sat? Zašto se mučiti sa svim vrstama skripti? Planovi usluga ne dopuštaju:

  • Koristite sigurnosnu kopiju zrcala
  • Koristite postavke kompresije različite od postavki poslužitelja
  • Ne dopušta fleksibilan odgovor na novonastale situacije (nema mogućnosti rukovanja pogreškama)
  • Ne dopušta fleksibilnu upotrebu sigurnosnih postavki
  • Planovi usluga vrlo su nezgodni za implementaciju (i održavanje istih). velike količine poslužitelji (čak, možda, već 3-4)

Ispod su tipične sigurnosne naredbe

Potpuna sigurnosna kopija

Potpuna sigurnosna kopija s prepisivanjem postojeće datoteke (ako postoji) i provjerom kontrolnih zbrojeva stranice prije pisanja. Prilikom izrade sigurnosne kopije broji se svaki postotak napretka

SIGURNOSNO KOPIRANJE BAZE PODATAKA NA DISK = N"C:\Backup\mydb.bak" S INIT, FORMAT, STATS = 1, CHECKSUM

Diferencijalna sigurnosna kopija

Slično - različita kopija

SIGURNOSNO KOPIRANJE BAZE PODATAKA NA DISK = N"C:\Backup\mydb.diff" SA DIFERENCIJAL, INIT, FORMAT, STATISTIKA = 1, KONTROLNA ZBORA

RKZhT

Sigurnosna kopija dnevnika transakcija

DNEVNIK SIGURNOSNE KOPIJE NA DISK = N"C:\Backup\mydb.trn" S INIT, FORMAT

Zrcalna sigurnosna kopija

Često je zgodno napraviti ne jednu sigurnosnu kopiju odjednom, već dvije. Na primjer, jedan se može pohraniti lokalno na poslužitelju (tako da je pri ruci), a drugi se odmah formira u fizički udaljen i zaštićen od nepovoljnih utjecaja spremnik:

SIGURNOSNO KOPIRANJE BAZE PODATAKA NA DISK = N"C:\Backup\mydb.bak", OGLEDALO DO DISK = N"\\safe-server\backup\mydb.bak" S INIT, FORMAT

Važna točka koja se često propušta: korisnik u čije ime se pokreće proces MSSQL Servera mora imati pristup resursu "\\safe-server\backup\", inače kopiranje neće uspjeti. Ako je MSSQL Server pokrenut u ime sustava, pristup treba dati korisniku domene "server_name$", ali ipak je bolje ispravno konfigurirati MS SQL da radi u ime posebno kreiranog korisnika.

Ako ne navedete MIRROR TO, tada to neće biti 2 zrcalne kopije, već jedna kopija, podijeljena u 2 datoteke, prema principu interleave-a. I svaki od njih zasebno bit će beskoristan.

sqlcmd -S DECLSERVER\SQLGTD -E -Q "deklariraj @s varchar(255) set @s='E:\backup\GTD_' + convert(varchar(1), datepart(dw, getdate())) + '. bak' backup baze podataka GTD na disk = @s s init, noformat, skip, nounload"

sqlcmd omogućuje unos Transact-SQL izjava, sistemskih procedura i datoteka skripti iz naredbeni redak uređivaču upita u SQLCMD načinu rada,

  • -S - navodi naziv poslužitelja, poslužitelj[\ime_instance];
  • DECLSERVER\SQLGTD - ime poslužitelja/ime instance na kojoj se izvodi baza podataka;
  • -E - koristi pouzdanu vezu za povezivanje sa SQL poslužiteljem umjesto korisničkog imena i lozinke;
  • -Q "cmdlinequery" - prilikom pokretanja programa sqlcmd izvršava zahtjev, ali ne izlazi iz programa nakon završetka njegovog izvršenja. Može se izvršiti više upita, odvojenih točkom i zarezom. Stavite upit u navodnike kao što je prikazano gore;
  • proglasiti - deklarirati varijablu s, ime varijable uvijek počinje sa @, dakle @s. U našem slučaju @s- ovo je mapa (disk) za spremanje sigurnosnih kopija;
  • varchar(n) - postavlja tip varijable @s kao niz sa duga linija n, u primjeru 255 znakova;
  • postaviti - postavlja vrijednost varijable @s, u primjeru ovo je mapa sigurnosne kopije na pogonu E ( E:\sigurnosna kopija\), tada je naveden naziv datoteke sigurnosne kopije, gdje je skup funkcija pretvori (varchar(1), datepart(dw, getdate())) vraća se na format teksta s duljinom od 1 znaka tekući dan u tjednu (ponedjeljak - 1 , utorak - 2 , itd.) i dodaje se proširenje bak. Izlaz će biti datoteka s nazivom GTD_Broj dana u tjednu.bak;
  • sigurnosna kopija - stvara sigurnosnu kopiju;
  • baza podataka - označava izradu sigurnosne kopije cijele baze podataka;
  • GTD - u našem primjeru naziv baze podataka na SQL poslužitelju;
  • na disk - označava vrstu uređaja za pohranu sigurnosne kopije, datoteke tvrdi disk, a varijabla je navedena @s, kojoj se dodjeljuje put i naziv datoteke koja se stvara;
  • s init, noformat, skip, nounload - označava da je potrebno prepisati podatke u krug uz redefiniranje zaglavlja, što će nam omogućiti da imamo 7 backup datoteka za svaki dan u tjednu, prepisanih u krug.

Po potrebi možete koristiti druge funkcije, poput kompresije, pogledajte Transact-SQL Query and Function Help.

Korak 2. Promijenite nastavak tekstualne datoteke u .cmd

Kao rezultat, dobivamo datoteku backupGTD.cmd. Morate pokrenuti stvorenu batch datoteku sa stroja na kojem je instalirana MS SQL baza podataka.

Korak 3. Automatizirajte ovaj proces

Razmotrimo ovaj korak koristeći MS Windows Server 2008 kao primjer: Upravitelj poslužitelja -> Konfiguracija -> Planer poslova -> Biblioteka planera poslova.