Izvedba varnostnega kopiranja 1s ni uspela. Medsebojno povezana periodičnost popolne varnostne kopije in varnostne kopije diff

Tradicionalno so uporabniki 1C razdeljeni v dve kategoriji: tisti, ki izdelujejo varnostne kopije *, in tisti, ki jih začnejo delati. Da se ne bomo učili na lastnih napakah, začnimo delati rezerva takoj zdaj.

*Če že delate varnostne kopije, vam bo ta članek še kako koristil, saj je veliko tega, kar lahko najdete in preberete o varnostnem kopiranju na internetu, napačnega in zelo nevarnega za varnost vaših podatkov. Če ste strokovnjak za IT, nadaljujte z branjem razdelka »Varnostno kopiranje informacijske baze 1C z uporabo SQL«.

Ali je res vredno porabiti čas za to?

Ali se lahko informacijska baza 1C v našem času nekako pokvari? Vse se lomi: čajniki in letala, noga blata in elektronski mikroskop. Težko je razbiti samo nekaj zelo preprostega, kot je žoga iz litega železa. Toda informacijska baza 1C je kompleksen objekt in deluje v kompleksnem tehnološkem okolju. Prej ali slej se bo nekaj zgodilo, sprva precej nepomembno, nato pa bo »zrahljan vijak« povzročil slap programskih in strojnih okvar, ki se bodo na koncu končale z velikimi težavami in izgubo informacijske baze.

Datotečna različica informacijske baze

Začnimo od samega preprost primer. V majhni organizaciji konfiguracija 1C deluje z informacijsko bazo datotek, ki jo streže dohodna Sistemski administrator kar je verjetno vse postavilo. Ampak! Odsotnost sporočila »Varnostno kopiranje ni konfigurirano« ne pomeni, da je zdaj konfigurirano. Lahko tudi pomeni, da sporočilo preprosto ni prikazano. Zato prevzamemo odgovornost za zanesljivost in varnost rezultatov našega dela, najprej poskrbimo, da je podatkovna baza datotečna. Kako to storiti, je jasno prikazano na spodnji sliki. Če piše Srv= namesto File=, je to zbirka podatkov SQL in se za nastavitev varnostne kopije obrnite na skrbnika baze podatkov. Če je zbirka podatkov datoteka, lahko uporabite ročno ali samodejno kopiranje.

Ročni način– ustvarite varnostno kopijo, kot je prikazano na sliki. Pred razkladanjem morajo vsi uporabniki dokončati delo z informacijsko bazo. Nalaganje ustvari eno varnostno kopijo datoteke s pripono .dt, ki vsebuje Skoraj vsi(več o tem kasneje), kaj je trenutno v informacijski bazi in kaj bo vneseno kasneje. Datoteki dajte smiselno ime (na primer »Trade Control Backup on 2017-10-31«) in izberite posebno mapo, v katero jo želite shraniti (na primer mapa »Varnostne kopije« v mapi »Moji dokumenti«). S to datoteko lahko naknadno obnovite informacijsko bazo v stanje pred razkladanjem. Za obnovitev uporabite operacijo "Naloži informacijsko bazo".

Tipična nastavitev varnostnega kopiranja je prikazana na sliki. Ta nastavitev predvideva, da zapusti uporabnik s skrbniškimi pravicami odprt program ob koncu delovnega dne (sicer varnostna kopija ne bo izvedena), vsi ostali uporabniki pa zaprejo program. Druga možnost je izvedba varnostnega kopiranja ob zaustavitvi (prosil vas bo, da potrdite, ali je varnostno kopiranje potrebno).

Ko pride čas varnostne kopije v prvem primeru ali ko zadnji uporabnik z administratorskimi pravicami zapusti v drugem primeru, bo sistem zaklenil informacijsko bazo in izklopil vse uporabnike. To je zapleten postopek, ki morda ne bo deloval, kar povzroči napako pri varnostnem kopiranju (na sliki spodaj). O tem si lahko preberete poseben članek na naši spletni strani.

Zato ne bo delovalo, če se omejite na enkratno samodejno varnostno kopiranje, še vedno morate redno spremljati ustvarjanje varnostnih kopij.

In zdaj nekaj vprašanj, ki niso zajeta v priljubljenih člankih na temo varnostnega kopiranja.

• Bo vse varnostno kopirano?

št. Lahko izgubite ali poškodujete zgodovino dela (kdo in kdaj je vstopil in izstopil iz programa), zgodovino sprememb objekta (kdo in kdaj je spreminjal podatke). Ti podatki so shranjeni zunaj informacijske baze, njihovo shranjevanje in pravilna obnovitev pa zahtevata posebna dejanja. Lahko izgubite ali poškodujete datoteke 1C, priložene predmetom (skeni dokumentov, fotografije itd.). Odvisno od nastavitev so lahko ti podatki shranjeni znotraj ali zunaj informacijske baze; v slednjem primeru so za njihovo pravilno shranjevanje in obnovitev potrebna tudi posebna dejanja. Tudi varnostna kopija ne bo shranila nastavitev. upravljane oblike ki so jih naredili uporabniki.

• Ali je mogoče med delom narediti varnostno kopijo?

Standardni mehanizem najprej poskuša prekiniti uporabnike. Vendar to ni vedno mogoče, zato je operacijo varnostnega kopiranja mogoče izvesti, medtem ko uporabniki tečejo. V tem primeru se predpostavlja, da ti uporabniki ne spreminjajo podatkov. Če pa temu ni tako, ni nobenega zagotovila, da je varnostna kopija pravilna. Torej je odgovor na to vprašanje ne, ne morete.

• Kako pogosto je treba narediti varnostne kopije?

Odvisno od intenzivnosti vnosa podatkov in kritičnosti njihove izgube. Za majhno podjetje z enim ali dvema uporabnikoma 1C priporočamo, da to počnete vsaj vsak dan. Pri 20 uporabnikih priporočamo, da ustvarite eno nočno varnostno kopijo in več varnostnih kopij v teku delovnega dne. Kot se spomnite, bo to povzročilo začasno tehnološko prekinitev dela uporabnikov.

• Imeli smo primere izgube podatkov in radi bi prešli na SQL različico informacijske baze, vendar je zelo drago ...

Morda boste želeli uporabiti brezplačno različico MS SQL. Kontaktirajte nas za nasvet.

SQL različica informacijske baze

Ta delČlanek bo zanimiv za strokovnjake in tiste, ki bodo to šele postali.

Naj takoj pojasnimo, da se nalogi varnostnega kopiranja ni mogoče izogniti. Niti replikacija niti absolutno zanesljiva strojna oprema ne bosta zaščitili pred naključnimi ali zlonamernimi poškodbami podatkov na ravni aplikacije (napačno zapiranje meseca, nepravilno delovanje slabo razhroščene obdelave množičnih sprememb podatkov itd.). Podatki so v tem primeru varno shranjeni, vendar so nepravilni in ni varnostnih kopij, zato povratek ni mogoč. V praksi morate obnoviti informacijsko bazo 1C zaradi poškodb podatkov veliko pogosteje, kot si morda predstavljate.

Z vidika uporabnika, ki živi v konceptualnem prostoru datotečnih baz, imamo obnovitvene točke v obliki varnostnih kopij informacijske baze, časovno ločenih s pogostostjo varnostnih kopij: če delamo kopije enkrat na dan, potem bomo v primeru obnovitve izgubili spremembe v bazi za največ en dan ali manj. Toda v okolju strežnika SQL način shranjevanja/spreminjanja podatkov in tehnologije varnostnega kopiranja zagotavljajo "neskončno" število točk, ki se združijo v eno neprekinjena obnovitvena linija. To pomeni, da se lahko vrnete na točko tik pred trenutkom okvare ali, če je potrebno, na katero koli točko nazaj. V jeziku uporabnika je to enakovredno ustvarjanju varnostnih kopij enkrat na sekundo ali manj.

Dejstvo je, da varnostno kopiranje v okolju SQL ni zaporedje pritiskov na gumbe, temveč niz rednih dogodkov nad kompleksnimi objekti. In ta kompleks nastaja v zelo kompleksnem okolju.

Da bi razumeli, "kako vse deluje", bomo še enkrat navedli cilj naših dejanj - popolno varnostno kopiranje podatkov do sekunde pred napako (ali trenutek neželenih sprememb) in možnost vrnitve na poljubno točko v čas natančen do sekunde.

Ali je obnovitev podatkov do sekunde res tako pomembna?

To je pomembno za sisteme front office ali ko podjetje doseže določen obseg. Pojasnimo to izjavo tako, da postavimo nekaj vodilnih vprašanj. Ali je enostavno organizirati ponovni vnos podatkov v poslovni mreži, ki je razpršena v 10 regijah z različnimi časovnimi pasovi in ​​ima več tisoč zaposlenih? Kako preveriti njegovo pravilnost? Recimo, da lahko vzamete račun in znova vnesete podatke iz njega. In kako znova vnesti podatke, ki so vstopili v sistem pri interakciji z opremo ( fiskalni registratorji, bančni terminali) ali pri tretjih osebah informacijski sistemi(spletni kredit, obdelava diskontnih kartic ene same partnerske mreže), s sodelovanjem velikega števila ljudi (sistem za sledenje časa s prstnimi odtisi)? Kje lahko dobim vir informacij za ponovni vnos, če ni dokumentov in so vsa dejanja zabeležena na brezpapirni način (obračunavanje obrokov v menzi podjetja s kartico zaposlenega)?

Kako do kopije baze z vsemi podatki, ki so bili v sistemu "sekundo pred eksplozijo"

Dnevnik transakcij (TLog)

Zabeležiti je treba vsa dejanja, ki jih bomo izvedli z bazo podatkov, ter njihov točen čas (do mikrosekund) in jih šele nato izvesti. S takim dnevnikom (shranjenim na zelo zanesljivem in hitrem mediju, ki je nujno ločen od same baze podatkov), bi lahko ponovili vse operacije od trenutka, ko je baza začela obstajati, do poljubnega trenutka obnovitve z natančnostjo mikrosekund. Toda beleženje transakcij ima dve pomanjkljivosti: čez nekaj časa, ko se zbirka podatkov poveča, bo TLog zavzel veliko prostora (ker nenehno raste), okrevanje od "ničelne" točke v času pa bo trajalo zelo dolgo.

Varnostne kopije dnevnika transakcij (TLog varnostne kopije)

Figurativno povedano bomo vse liste redno jemali iz dnevnika in jih odnašali v sosednjo sobo (zaseženim listom rečemo TLog backup), v sam dnevnik pa dajali paket novih praznih listov, da bomo imeli kam zapisovati nove. dejanja z bazo. Tehnično se to izvede na naslednji način: iz datoteke TLog se naredi kopija in se zapiše na arhivski disk, nato pa se vsi vnosi v TLog »izbrišejo« (označeni kot prosti, velikost dnevniške datoteke se ne spremeni), informacije o novih transakcijah so zapisane na "izbrisanem" mestu. Zelo pomembno je razumeti, da je vsak raztrgan paket listov, čeprav se temu v ustaljeni terminologiji reče varnostna kopija dnevnika transakcij, edini nosilec informacij o dejanjih z bazo za to obdobje, zdaj pa teh informacij ni v samem dnevniku. Zato je izguba že enega »iztrganega lista« zaenkrat absolutno nesprejemljiva, izraz Tlog varnostna kopija zvito prikriva bistvo in namen teh informacij. Ne pozabite - to ni varnostna kopija! Dnevnik smo razdelili na veliko datotek in informacije v vsaki od njih se nikjer ne podvajajo. Toda izraz varnostna kopija dnevnika transakcij je splošno sprejet, zato ga bomo uporabljali tudi v prihodnje.

Zdaj TLog ne raste v nedogled, ampak se pojavi rutinsko opravilo - načrtovano varnostno kopiranje TLog.

Popolne varnostne kopije baze podatkov (Full backup)

Če občasno naredite kopije celotne baze podatkov, bo za obnovitev mogoče vzeti najprimernejšo kopijo glede na čas in ponoviti ne vse operacije od ničelne točke v času, ampak le operacije od trenutka, ko je bila ta kopija ustvarjena do trenutek obnove (kot pravijo, »izdelajte popolno varnostno kopijo in nanjo prenesite TLog«). To bistveno skrajša čas obnovitve, še posebej, če baza podatkov obstaja 5 let.Poleg tega imamo zdaj možnost brisanja stare varnostne kopije Full in TLog. Pravzaprav je lahko vrnitev nazaj na najbližjo sekundo pogosto potrebna le za kratek čas (na primer pred dvema mesecema od trenutnega trenutka za preiskavo nekaterih incidentov ali obnovitev baze podatkov sekundo pred tragično uvedbo neželenih sprememb). V tem obdobju bomo shranili neprekinjeno verigo varnostnih kopij TLog. Izven tega obdobja lahko shranjujete samo obnovitvene točke v obliki popolne varnostne kopije (pa še to ne vseh, ampak npr. le točke za prve dni v mesecu). Varnostne kopije TLog izven obdobja je po novem sploh mogoče brisati (očitno je njihovo selektivno brisanje in selektivno shranjevanje izven obdobja popolnoma nesmiselno zaradi motenj v verigi TLog). Tako ali drugače se pojavi rutinsko opravilo inteligentnega brisanja.

Tu se pojavi sledeča težava. Predstavljajte si bazo podatkov z velikim številom uporabnikov in visoko stopnjo sprememb. Pogojno - 33% časa porabimo za pisanje in 67% za branje, izpadov ni. Ko obnovimo bazo podatkov, lahko pišemo skoraj 100% časa, tj. trikrat hitreje. To pomeni, da lahko na uro obnovimo tri ure dela z bazo iz dnevnika. In ta ura je najdaljši čas izpada za obnovitev, s katerim se podjetje strinja. Recimo, da se popolna varnostna kopija izvede enkrat na dan. Če se okvara pojavi čez 21 ur, bomo morali porabiti 7 ur za obnovitev dnevnika, kar je absolutno nesprejemljivo. Torej je treba popolno varnostno kopijo narediti 1-krat v 3 urah? Žal, to ni vedno mogoče: baze podatkov so tako velike (na stotine gigabajtov in celo terabajtov), ​​da je preprosto nemogoče ustvariti popolno varnostno kopijo v takem času. Poleg tega pogosto ustvarjanje popolne varnostne kopije med delovnim časom dodatno obremeni in upočasni delo uporabnikov, poleg tega je shranjevanje takšne količine podatkov zelo drago. Toda načeloma je dovolj, da nezmožnost ustvarjanja popolne varnostne kopije v sprejemljivem času popolnoma uniči našo tehnologijo varnostnega kopiranja.

Diferencialne varnostne kopije (diferencialna varnostna kopija, diferencialna varnostna kopija)

Lahko si izmislimo posebno strukturo shranjevanja podatkov z nenehno naraščajočim številom transakcij in drugimi triki, ki olajšajo razumevanje razlike med obema stanjema baze podatkov (od zdaj do zdaj - je že bilo, vse kar sledi je že novo). To ne bo omogočilo, da se vsi podatki shranijo v varnostno kopijo baze podatkov, ampak samo razlike med trenutno popolno varnostno kopijo in prejšnjo popolno varnostno kopijo. Postopek za pridobitev naslednje celotne kopije bo preprost: vzemite popolno varnostno kopijo in nanjo zavrtite varnostno kopijo razlike. Namesto enega terabajta podatkov v Full backup smo shranili le deset megabajtov v Diff backup in dobili priložnost, da to počnemo kar pogosto – na primer enkrat na pol ure. Vendar se morate prepričati, da je na voljo popolna varnostna kopija, sicer je diferencialna neuporabna.

Na tem mestu lahko zelo dobro primerjate diferencialno varnostno kopijo in varnostno kopijo dnevnika transakcij, s čimer popravite prejete informacije. Če ne naredite celotne kopije, se bo velikost diferencialnih varnostnih kopij monotono povečala, ker kopičilo se bo vse več razlik od celotne kopije - in tako naprej, dokler ne bo ustvarjena naslednja popolna varnostna kopija. Velikost naslednjih varnostnih kopij dnevnika transakcij ne bo imela takšnega trenda, njihova velikost je določena s številom dejanj, izvedenih z bazo podatkov v določenem obdobju. Običajno se njihova velikost giblje okoli neke povprečne vrednosti, vendar se lahko v določenih obdobjih (pri izvajanju operacij masovne spremembe podatkov, ob povečani uporabniški aktivnosti itd.) zelo razlikuje od povprečja.

Spodnja ilustracija prikazuje naš varnostni sistem z določeno mero konvencionalnosti. Prva vrstica objektov prikazuje stanje baze podatkov, v katero se občasno dodajajo zapisi. Drugi prikazuje eno polno varnostno kopijo in tri diferencialne. Tretja vrstica prikazuje vsebino varnostnih kopij dnevnika transakcij. Vsak element je oštevilčen. Nastavimo nekaj odvisnosti med elementi.

• 5+7=3. To pomeni, da lahko s popolno varnostno kopijo 5 in različno varnostno kopijo 7 obnovite bazo podatkov v stanje 3. Hkrati odsotnost 6 na noben način ne bo vplivala na možnost obnovitve.
• 5+10+11=3. Enak rezultat (obnovitev v stanje 3) je mogoče doseči, če se vse spremembe, zabeležene v TLogBackup 10 in 11, uporabijo za popolno varnostno kopijo 5. To bo treba storiti, če nimamo 6 in 7 zaradi dejstva, da urnik zagotovljeno samo za kreacijo 5 in 8 (ali če sta 6 in 7 poškodovana). Če pa je 7, potem je metoda 5 + 7 veliko hitrejši način 5+10+11.
• Če manjka le 7, se lahko osnova povrne v stanje 3 z metodo 5+6+11.
• Če je razpored tak, da 11 ni bil ustvarjen, bo vsebina 12: "Dodano: Toporkov, Ufimcev, Jašin."
• Dnevnik transakcij na prvi pogled ni prikazan na sliki, a kot se spomnite, varnostna kopija TLog sploh ni varnostna kopija, temveč dnevnik transakcij za določeno obdobje. Upoštevajte, da se nova imena v reviji pojavijo pred njihovim pojavom v bazi podatkov.
• Če dnevniki transakcij niso varnostno kopirani, bo vsebina TLog ob času 12 »Dodano:«, čemur sledi seznam priimkov 4 (tj. vsa dejanja so zabeležena). Če so varnostne kopije ustvarjene kot na sliki, bo vsebina transakcijskega dnevnika v času 4 in tudi v času 8 naslednja: "Še ni bilo izvedeno nobeno dejanje."

Varnostno kopiranje repa dnevnika transakcij

Če ne govorimo o visokorazpoložljivih sistemih, potem je v primeru okvare potrebna še ena ročna operacija, ki ni več rutina, ampak izdelava zadnje varnostne kopije TLog. Če to ni mogoče, tj. dnevnik je poškodovan skupaj z bazo podatkov ali skupaj s strežnikom - obnovitev je možna samo do zadnje varnostne kopije TLog in ne do zadnje sekunde. Tisti. prvotni cilj ne bo dosežen.

Iz tega izhaja, da je ključni element celotnega varnostnega sistema transakcijski dnevnik. Nahajati se mora na ločenem mediju (ne istem kot medij za samo bazo podatkov) z zelo visoko zanesljivostjo, visoko hitrostjo dostopa in visoko razpoložljivostjo, vendar v nobenem primeru različne mape istem logičnem disku, pa tudi na različnih logičnih pogonih istega fizičnega medija. Poleg tega je zaželeno, da tudi v primeru sesutja strežnika SQL dnevnik ostane na voljo ali pa bi bil vsaj na voljo v najkrajšem možnem času (metod za doseganje tolerance na napake ne upoštevamo, so tema posebnega članka impresiven volumen).

Prav tako kompleksen sistem bo poskrbel, da bomo dosegli na začetku zastavljene cilje in se izognili težavam, ki smo jih odkrili med razvojem.

Model popolne obnovitve (deluje samo z načrtovanimi opravili in pod nadzorom skrbnikov)

Opisali smo model popolne obnovitve baze podatkov - Full recovery model. Za posebne priložnosti v MS SQL Server obstaja preprost model obnovitev (model preproste obnovitve) in model z nepopolnim beleženjem (množično beleženje). Model popolne obnovitve zagotavlja redno izvajanje nalog vzdrževanja baze ter nadzor nad pravilnostjo in rezultati izvajanja nalog s strani skrbnika. To kaže na obstoj zapletenega orodja za načrtovanje načrta vzdrževanja, ki se ga je treba naučiti.

Pojdimo k praksi

Morda je prva težava, s katero se je treba soočiti, nezmožnost ustvarjanja nov načrt storitev.

To funkcionalnost je potrebno omogočiti z izvajanjem SQL skripta (Nova poizvedba v orodni vrstici, vtipkajte skript, Izvedi v orodni vrstici). Če je skript uspešno izveden, boste na dnu okna s skriptom videli ustrezna sporočila.

Besedilo tega skripta za kopiranje/prilepljanje:

Realni načrt vzdrževanja

Začnimo s prikazom pravega vzdrževalnega načrta, ki služi neproduktivnim bazam podatkov v razvojni zanki, nato pa razmislimo o posameznih delih načrta, ki so potrebni za njegovo branje in razumevanje. Štiri ilustracije spodaj prikazujejo načrt vzdrževanja "Glavni načrt", ki je sestavljen iz štirih podnačrtov, ki delujejo po svojem urniku.

V Object Explorerju lahko vidimo, da sta na strežniku SQL konfigurirana dva načrta vzdrževanja (glavni načrt, preskusni načrt). Glavni načrt je sestavljen iz štirih podnačrtov z različnimi urniki (Razpored):

• Tedensko vzdrževanje
• Diferencialno varnostno kopiranje
• Varnostna kopija ZhT

Na področju oblikovanja nalog vidimo naloge. Postopek oblikovanja načrta je sestavljen iz vlečenja opravil iz palete Toolbox, nastavljanja možnosti opravila in risanja puščic med opravili. Naloge imajo lahko poljuben opis v območju oblikovanja, ujemanje med nalogo na načrtu in nalogo na paleti lahko nastavimo z ikonami. Na primer, naloga »Napaka integritete« je naloga »Obvesti operatersko nalogo« na paleti (ikona »oseba«).

Je blokovni diagram?

Prva stvar, na katero pomislite, ko pogledate scenarij naloge vzdrževalnega načrta, je, da gre za diagram poteka, puščice označujejo prehode iz ene naloge v drugo, po njih pa se lahko premikate s kazalcem in sledite celotnemu scenariju od začetka do konec. Vendar pa ni. Zgodi se, da je na prvi pogled celo težko ugotoviti, kje se vse začne in kakšno je zaporedje nalog. Skript se na splošno lahko začne na več mestih in tudi konča na več mestih, ker SQL Server običajno izvaja absolutno vse naloge hkrati.

Sočasnost in omejitve

Edina stvar, ki ga ustavi, je prisotnost omejitev. Naloge ni mogoče začeti, dokler se ne "uresniči" dohodni puščice vanj (omejitve, omejitve). Barva puščice označuje vrsto dokončanja zadevne naloge. Prihajajoča zelena puščica za odvisno nalogo označuje omejitev "zaženi le, če je vplivanje opravilo uspešno", črna - "zaženi samo po zaključku vplivanja (Dokončanje)", rdeča - "zaženi samo v primeru napaka v nalogi vplivanja (Napaka)".

Vrsta črte (polna ali črtkana) označuje logični operator IN ali ALI za izračun končne omejitve iz več prihajajočih puščic. Ta operator se spremeni v pogovornem oknu Urejevalnik omejitev prednosti (dvokliknite katero koli puščico). Vse polne puščice se morajo uresničiti, vsaj ena od pikčastih se mora uresničiti - potem se bo odvisna naloga takoj zagnala. Barvo vsake prihajajoče puščice lahko spremenite neodvisno (desni klik, Uspeh/Neuspeh/Dokončanje). Vrsto črte je mogoče spremeniti samo za vse dohodne puščice hkrati (dvoklik, pogovorno okno Urejevalnik omejitev prednosti). Najprej se vse naloge, ki nimajo omejitev, začnejo izvajati hkrati. Takoj, ko je naslednja naloga končana, se preverijo vse naloge, ki so odvisne od nje, hkrati pa se zaženejo v izvedbo tiste naloge, za katere je končna vrednost omejitev zadostovala za odločitev o zagonu.

Informacije v prejšnjem odstavku zadostujejo za razumevanje splošnega mehanizma, s katerim SQL Server izvaja naloge načrta vzdrževanja. Zdaj pa razmislimo o vprašanjih praktičnega pomena.

Čuden urnik

Nenavaden čas izvajanja naloge je posledica 4-urne razlike med časovnim pasom strežnika in časovnim pasom razvijalca. Razpon možnih delovnih ur za razvijalce je od 9:00 do 21:00, zato se podnačrt "Backup ZhT" izvaja vsako uro od 10:00 do 21:00, popravlja spremembe vsako uro (ob 9 ni sprememb: 00 še). Prevedeno v časovni pas strežnikov je to od 14:00 popoldne do 01:00 zjutraj, kar je navedeno v urniku.

Pri določanju ure lahko skočite čez polnoč, to deluje pravilno. Izgleda malo nenavadno. Drugi načrtovalci, da bi se izognili težavam z razumevanjem končnega časa v naslednjem dnevu, zahtevajo trajanje naloge - "znotraj X ur."

Če popolni varnostni kopiji takoj sledi varnostna kopija VT, ste lahko 100 % prepričani, da je načrt ustvaril čarovnik za načrt vzdrževanja (nikoli ga ne uporabljajte, ustvari samo smeti) ali nizkokvalificirani skrbnik, ki meni, da je popoln backup + TLog backup par , narejen hkrati, z nekim obveznim kompletom za obnovitev. Toda to so neodvisne naloge, ki se izvajajo po različnih urnikih.

Toda naš načrt je izjema, saj je naš cilj zbrati podatke o uspešnosti ključnih nalog (integriteta, popolna varnostna kopija, varnostna kopija VT) v enem podplanu in šele, če so uspešne, dati ukaz za brisanje starih varnostnih kopij.

Če se brezpogojno izvede brisanje starih varnostnih kopij, se lahko izkaže, da nove varnostne kopije niso ustvarjene, stare pa se popolnoma izbrišejo. Če se brisanje starih varnostnih kopij porazdeli po različnih podplanih, glede na vrsto varnostne kopije izpade skoraj enako. Recimo, da je popolna varnostna kopija prenehala delovati. Hkrati se brisanje starih polnih kopij ni več izvajalo. Toda podnačrt Backup VT o tem ne ve ničesar in še naprej briše zastarele varnostne kopije VT. Čez nekaj časa ne bomo imeli le neprekinjenega neposrednega obnavljanja, ampak celo obnovitvene točke v trenutnem oknu: zadnja izdelana polna varnostna kopija je bila izdelana predolgo, shranjene varnostne kopije VT v zadnjem času pa so popolnoma neuporabne, ker. v njihovi neprekinjeni verigi ni niti ene popolne varnostne kopije.

Naloga diferencialne varnostne kopije ni ključna za obnovitev in ni prikazana v podnačrtu. Še vedno pa bi ga bilo mogoče dodati temu podnačrtu in ga postaviti takoj za popolno varnostno kopijo.

*

*Opazite ikono fx na nalogi

Vsako opravilo ima lastnosti, nekatere si lahko ogledate v pogovornem oknu z nastavitvami opravila (dvoklik) in celoten seznam– v pogovornem oknu lastnosti (desni klik, Lastnosti). Naloge imajo tudi lastnost izrazov, ki vam omogoča, da ustvarite tabelo lastnosti in njihovih ustreznih izrazov SQL za sprotni izračun vrednosti lastnosti. Praktična uporaba te možnosti je naslednja. Zagotovo ste že videli t.i. "bat datoteke", da izbrišete vse razen varnostnih kopij za prve številke, ali obratno, da kopirate varnostne kopije teh številk na drugo mesto, preden izbrišete varnostne kopije.

Takšne naloge ne zahtevajo zunanjih orodij in jih rešujejo standardna orodja MS SQL. Razširitev datoteke polne varnostne kopije za prve dni lahko izvedete z MNT, za preostale dni pa z BAK. To pomeni, da lahko opravilo čiščenja izbriše BAK, starejše od 1 meseca, in shrani MNT dlje časa ter jih izbriše na primer po 1 letu.

Ko odprete pogovorno okno za nastavitev naloge Full Database Backup, boste videli datotečno pripono BAK ali MNT, odvisno od današnjega datuma.

V skladu s priporočili 1C je treba statistiko posodabljati vsak dan, postopkovni predpomnilnik pa je treba očistiti s pogostostjo posodobitev statistike. Te naloge so po eni strani precej zahtevne, po drugi strani pa niso temeljne za informacijske baze razvojne ekipe. Navsezadnje takšne zbirke podatkov ne vsebujejo veliko podatkov in težave z delovanjem niso pereče. Zato se te naloge izvajajo v tedenskem podplanu, medtem ko so v dnevnem onemogočene (desni klik na nalogo, Onemogoči). Ne le odsoten, ampak ustvarjen in prepovedan.

Razmislimo o naravnem vprašanju: ali bo v prepovedani težavi vse delovalo pravilno? Kako se bodo rdeče, črne in zelene puščice odzvale na takšno prepoved?

Pri pisanju zapletenih načrtov vzdrževanja se pojavi naloga odpravljanja napak in praktične potrebe, ki izhajajo iz nje:

• Dejansko ne izvajajte dolge naloge, ampak jo smatrajte za pogojno dokončano, pri čemer ohranite svoj vpliv v obliki puščic na druge naloge;
• Modeliranje napačne izvedbe naloge.

Za prvo ima MS SQL mehanizem za preprečitev dejanske izvedbe naloge: desni klik na nalogo, Onemogoči. V tem primeru bo naloga postala siva, dejansko ne bo izvedena, vendar se bo štela za dokončano in dokončano (črna in zelena puščica bosta delovali). Če želimo simulirati napačno izvedbo, moramo v oknu z lastnostmi opravila lastnost opravila ForceExecutionResult nastaviti na Failure. Ne zamenjujte te lastnosti z lastnostjo ForcedExecutionValue v drugem razdelku.

Implementacija pogojev ((A ali B) in C) za omejitve opravil ali navidezna opravila, ki sploh niso navidezna

Omejitve je mogoče kombinirati z operatorjem IN ali operatorjem ALI. To pomeni, da na spodnji sliki pikčastih puščic za dokončanje ni mogoče narisati neposredno na opravilo »Obvesti o dokončanju z napakami«. Rešitev je ustvariti vmesno nalogo "Prišlo je do napak", ki zbere rezultat pikčastih črnih puščic. Naloga je skript SQL iz enega stavka go, kar pomeni, da se zdi, da ne naredi nič uporabnega.

Toda v resnici zbira dohodne omejitve in služi kot vir omejitev za druge naloge, s čimer je pomembna kontrolna točka, skozi katero poteka izvajanje skripta. Ta trik z navidezno nalogo lahko uporabite v drugih situacijah. Na primer, v vašem scenariju ni treba prenesti zbirk podatkov brez povezave in nato vrniti stanja nazaj. Toda naloge »Spletne baze podatkov brez možnosti varnostnega kopiranja« ni mogoče kar tako izbrisati iz podnačrta, je pomembna točka izvajanja, zbira dohodne omejitve in služi kot vir odhodnih. V tem primeru morate to nalogo zamenjati z navideznim scenarijem.

Asinhrono izvajanje

V konstrukciji na zgornji ilustraciji lahko pride do "kvantnega paradoksa", ko je posledica pred vzrokom. Dejansko, če je ena od nalog vplivanja, na primer "Napaka integritete", dala signal za zagon odvisne naloge, ni več smiselno čakati na rezultat preostalih nalog vplivanja, to še vedno ne vpliva na dejstvo, da je treba zagnati odvisno nalogo "Prišlo je do napak". Zato bo izvedena takoj. Čez nekaj časa se lahko zgodi, da bo opravilo »ZT backup error« delovalo in se končalo. Lahko bi sprožil "Prišlo je do napak", vendar se je ta dogodek že zgodil. To je zasnovano v našem podnačrtu, vendar je treba upoštevati te vrste asinhronih učinkov, da se izognemo nepričakovanim rezultatom. Na primer pri merjenju skupnega časa izvajanja podnačrta vzdrževanja z uporabo naloge Alert Operator na začetku in na koncu.

Kaj je to?

To je prva in ena zadnjih nalog, ki se izvajajo in so skripti SQL. Dejstvo je, da so v razvojni zanki pogosto kopije zgodovinskih sistemov zelo velikega obsega. Namenjeni so seznanitvi z vzdrževanjem zgodovinskih evidenc, služijo kot vir podatkov pri migracijskih operacijah. Podatki v njih se praktično ne spreminjajo. Izvirniki baz podatkov so v trenutnem proizvodnem krogu stranke, kopije teh sistemov pa je vedno mogoče dobiti na zahtevo. Varnostno kopiranje te ogromne količine informacij je izguba virov. V parametrih opravil, ki ustvarjajo varnostne kopije, je dobra praksa, da določite parameter »Vse« v nalogah varnostnega kopiranja namesto navajanja določenih baz podatkov (s tem se izognete tipična napaka"Podatkovna baza je bila ustvarjena, vendar so jo pozabili vključiti v rezervni seznam"). In če že, je potreben mehanizem za nekakšno izključitev nekaterih posebnih osnov iz nabora Vse. Točno to počne prva skripta - takšne baze podatkov postavi v stanje OFFLINE. Drugi scenarij naredi nasprotno. V tem primeru je v parametrih opravil varnostnega kopiranja ali ponovnega indeksiranja nastavljen parameter »Prezri baze podatkov v stanju OFFLINE«, sicer bo prišlo do napake opravila.

Vzporedno ali serijsko

V podnačrtu »Dnevno polno varnostno kopiranje« je naloga »Baze podatkov, ki jih ni mogoče varnostno kopirati brez povezave« prva, ki se izvede, ker to je edina naloga, ki nima meja. Pod njo vidimo črtasto podzaporedje izvajanje nalog, ki so glavno jedro podnačrta dnevne popolne varnostne kopije.

Kot razloge za zaporedno izvajanje navedimo željo, da ne presežemo obremenitve SQL strežnika med vzdrževanjem in vidnost načrta. Običajno zaradi velikega nočnega okna s prekinitvijo dela uporabnikov zaporedno izvajanje ne postane težava. Lahko pa pride do situacij, ko veliko uporabnikov iz različnih časovnih pasov dela z zbirko podatkov in obdobje vzdrževanja postane zelo majhno. Če zaporedno izvajanje nalog ne ustreza oknu vzdrževanja, jih bo treba vzporediti. To lahko storite s puščicami, ki prihajajo iz "Baz brez varnostnih kopij brez povezave" vsakemu glavna naloga in nato konvergiranje k "spletnim nerezervnim bazam". Dve sivi nalogi se morata izvajati zaporedno glede na drugo. Rezultat paralelizacije je prikazan spodaj. Zastavljeni cilji so doseženi, vendar je vidnost bistveno izgubljena:

Tukaj je druga možnost, topološko enakovredna prejšnji shemi, vendar bolj vizualna zaradi spremenjene razporeditve nalog + odstranitev sivih nalog.

Paralelizem znotraj standardnih nalog Backup Database in Check Database Integrity ter razlaga rezultatov njihove izvedbe

Nalogi »Ustvari varnostno kopijo« in »Preveri celovitost baze podatkov« običajno delujeta s seznamom baz podatkov. Ali bodo delali zaporedno z vsako zbirko podatkov ali bo za vsako zbirko podatkov veliko vzporednih nalog vzdrževanja? Dvokliknimo nalogo, v pogovornem oknu, ki se nam odpre, pritisnemo gumb "View T-SQL". Vidimo lahko, da so v skriptu, ki ga generira in izvaja SQL Server, navodila za varnostno kopiranje BACKUP DATABASE ločena z navodili GO, kar pomeni, da bodo ti procesi varnostnega kopiranja potekali vzporedno. Rezultat se ne nanaša na pakete, temveč na delo kot celoto. Če pride do napake pri opravilu z vsaj eno zbirko podatkov, se bo opravilo na splošno štelo za napačno zaključeno; če ni napak, se bo opravilo na splošno štelo za uspešno zaključeno.

Načrtovanje vzdrževalnih nalog (ključno vprašanje, ki se pogosto šteje za sekundarno)

Povzemimo glavne naloge načrta vzdrževanja baze podatkov popolnega obnovitvenega modela:

1. Naloga popolnega varnostnega kopiranja
2. Varnostna naloga diff
3. Naloga varnostnega kopiranja TLog

V priljubljenih člankih na temo varnostnega kopiranja SQL vprašanje razporejanja opravil najpogosteje ni posebej obravnavano ali pa mu je dodeljena sekundarna vloga. Hkrati pa predlagana periodičnost nalog ni jasno argumentirana. Medtem je to vprašanje ključno. Nedvoumnih priporočil ni. Pogostost in sestava nalog se lahko razlikujeta v različnih okoliščinah. Upoštevajte splošna načela.

Glavna stvar, pri kateri morate začeti, je sprejemljivo okno izgube podatkov (cilj točke obnovitve, RPO) + čas obnovitve (cilj časa obnovitve, RTO). Ti indikatorji pa določajo arhitekturo strojne opreme, uporabljene tehnologije in pogostost izvajanja nalog.

Pogostost varnostnega kopiranja TLog

Pogostost varnostnega kopiranja TLog je odvisna od vrednosti RPO. Tipična pogostost naloge varnostnega kopiranja TLog za produktivne baze podatkov je od ½ do 1 časa RPO v celotnem dnevnem časovnem intervalu za spreminjanje baze podatkov (vključno s časovnimi intervali, v katerih pride do sprememb rutinska opravila in enkratna obdelava med izven delovnega časa). Za produktivne baze je značilno, da spremembe izvedejo v 24 urah. Če je za takšno zbirko podatkov RPO=1 ura, potem je treba varnostno kopiranje dnevnikov transakcij izvajati 24 ur na dan vsakih 30-60 minut. Toda obstajajo primeri, ko se je zaradi specifičnosti sistema mogoče omejiti le na interval delovnega časa, na primer od 10. do 18. ure, od ponedeljka do petka, pa tudi na večjo ali manjšo frekvenco.

Za neproduktivne baze podatkov (v razvojnem okolju) je morda bolj primerna uporaba preprostega obnovitvenega modela, kjer dano nalogo je v celoti odsoten. Kljub dejstvu, da je v številni literaturi in uradni dokumentaciji navedeno, da uporaba poenostavljenega modela ne daje povečanja zmogljivosti (ker se TLog še vedno vzdržuje), v praksi temu ni tako.Čas izvajanja pogosto izvajane operacije namestitve spremenjenih konfiguracijskih objektov 1C v shrambo z uporabo poenostavljenega obnovitvenega modela se večkrat zmanjša, skupni dobiček v času pa dramatično poveča hitrost razvoja. Hkrati morate s frekvenco ½ do 1 časa RPO že ustvariti varnostno kopijo Diff. Enako metodo lahko uporabimo za produktivne zaledne sisteme z nizkimi stopnjami sprememb, kjer obstaja možnost ponovnega vnosa podatkov, ki so bili v oknu RPO in izgubljeni zaradi zrušitve.

Medsebojno povezana periodičnost popolne varnostne kopije in varnostne kopije diff

Pogostost obeh nalog je na splošno izbrana tako, da je mogoče izpolniti RTO. Če je intenzivnost sprememb tolikšna, da vam omogoča izdelavo popolnih varnostnih kopij enkrat na mesec, diferencialnih varnostnih kopij enkrat na dan in hkrati, 29., poteka obnova znotraj RTO - zakaj pa ne. Če je intenzivnost sprememb tolikšna, da s takšno periodičnostjo opravil čas obnovitve postane nesprejemljiv, boste morda potrebovali celotno kopijo na začetku dneva in več diferencialnih varnostnih kopij čez dan.

Pogostost opravila varnostnega kopiranja Diff je odvisna tudi od obsega varnostnega kopiranja Diff v primerjavi s popolnim varnostnim kopiranjem. Če z izbrano pogostostjo varnostne kopije Diff njena velikost začne presegati polovico velikosti celotne varnostne kopije, nadaljnje ustvarjanje varnostne kopije Diff postane neustrezno, na tej točki morate ustvariti še eno popolno varnostno kopijo. Vendar si velja zapomniti, da je treba to razmerje prezreti pri relativno novih bazah podatkov – sčasoma bo obseg dnevnih sprememb majhen (tj. dovoljen za varnostno kopijo Diff) del celotne količine podatkov, 95 % količine pa zasedejo zgodovinski podatki.

Upoštevanje nasvetov, ki jih lahko preberete na internetu o konfiguriranju varnostnih kopij SQL, je lahko vir težav za vaše podatke. Uporabimo znanje iz tega članka na nasvete nekaterih strokovnjakov:

Za pogosto posodobljene podatkovne baze je priporočljivo narediti popolno varnostno kopijo ob nedeljah in varnostno kopijo TLog enkrat na dan. Okno izgube podatkov (RPO)=1 dan je nesprejemljivo dolgo. Ob tem je prepričan strokovnjak, da je to Najboljši način prepreči morebitno izgubo podatkov. Tudi čas obnovitve v soboto bo nesprejemljivo dolg, saj bo potrebno 6 dni izvajati spremembe v Full backupu, intenzivnost sprememb v bazi pa je velika.

Tu se vsak dan od ponedeljka do petka naredi varnostna kopija VT in Shrink VT (besedilo "kopije baze podatkov" v stolpcu "Opis" je očitna tipkarska napaka, saj je operacija jasno navedena v stolpcu "dejanja" - varnostna kopija VT). Če se vrnete na naš podnačrt za tedensko vzdrževanje, boste videli, da je opravilo obrezovanja VT primerno poimenovano »Shrink Do Not« in je prepovedano opravilo (obarvano sivo). Iskalna poizvedba "skrčiti je treba narediti" bo pomagala razjasniti informacije.

Spustimo se eno vrstico navzdol in vidimo, da se po vsaki varnostni kopiji Diff izbriše varnostna kopija TLog - to je prostovoljna zavrnitev neprekinjenega neposrednega obnavljanja (ključni cilj celotnega sistema varnostnega kopiranja) in prehod na obnovitvene točke. Točke so med seboj ločene z dnevom. To pomeni, da je okno izgube podatkov 24 ur (RPO=24 ur).

Spustimo se do zadnje vrstice in najdemo največjo napako celotnega načrta. Če je prišlo do nenamerne ali zlonamerne poškodbe podatkov, so podatki zelo varno shranjeni, vendar so neuporabni. Predstavljajmo si primer, ko programer pride v soboto, da bi se ukvarjal s problemom "poročila dajejo popolne neumnosti." Ob 18:05 ugotovi, da je težava v tem, da so bili podatki ključnih registrov popolnoma popačeni (izbrisani), v dnevnikih pa piše, da se je to zgodilo v petek popoldne. V tem trenutku ima bazo podatkov, v kateri so podatki napačni, in eno samo popolno varnostno kopijo, narejeno pred 5 minutami, podatki v kateri so prav tako napačni. Vse ostalo je v celoti odstranjeno, saj. Popolna varnostna kopija je bila uspešno ustvarjena. Ta načrt vzdrževanja je prvak v številu storjenih napak.

Zgornja ilustracija je začetni načrt, ki ga ustvari začetnik s pomočjo čarovnika za načrt vzdrževanja in ne rešuje nobenih težav. Ima pogosto napako: naloga ustvarjanja popolne varnostne kopije ne more biti odvisna od rezultatov preverjanja integritete. Ko se zbirka podatkov zruši, je bolje imeti varnostno kopijo z dvema pokvarjenima povezavama v bazi podatkov kot nič. Primerjajte s tem, kar je bilo narejeno v podnačrtu "Dnevno varnostno kopiranje" - kršitev celovitosti obvesti operaterja, vendar ne prepreči ustvarjanja varnostnih kopij.

Značilnosti obnovitve - kako ne izgubiti podatkov

Zdi se, da bi lahko bilo preprostejše: preprosto vrnite bazo podatkov pred časom iz lastne varnostne kopije. In nekoliko težje je razmestiti varnostno kopijo druge baze podatkov v bazi podatkov. Toda pri tej preprosti operaciji nas čakajo velike nevarnosti, zaradi katerih lahko zlahka izgubite svoje podatke. Poleg tega moramo odkrito reči, da je v pogovornem oknu za obnovitev toliko absurdov, da se bo specialistu začetniku zagotovo zdelo, da nečesa ne razume in dela nekaj narobe, tudi če dela vse prav.

Ker te "lastnosti" niso nikjer opisane, zapolnimo to vrzel. Oglejmo si tipično nalogo obnovitve proizvodne baze iz nekega časa (vir, ZUP3ENERGO na ilustracijah) v individualno bazo programerja (sprejemnik, ZUP_SUV na ilustracijah), da raziščemo incident. Opisovanje različnih "lastnosti" vedenja različne različice SQL strežnik, pod pojmom »nove različice« bomo razumeli izdajo 13.0.4457.0, pod izrazom »stare različice« pa izdajo 11.0.3156.0.

Prvo dejanje- z desno miškino tipko kliknite ciljno zbirko podatkov, Opravila, Obnovi, Baza podatkov. In takoj v pogovornem oknu Obnovi bazo podatkov (spodnja slika) vidimo rumen znak za nevarnost: izdelana bo varnostna kopija končnega fragmenta dnevnika transakcij izvorne baze podatkov. Seveda bi pravzaprav morali govoriti o sprejemni bazi in logika tukaj bi morala biti naslednja: preden z obnovo uničimo trenutno vsebino, za vsak slučaj končno popravimo to, kar imamo. To vam bo omogočilo, da povrnete trenutno obnovitev in nato izvedete drugo obnovitev na točko pred obnovitvijo. Zdi se, da je operacija uporabna in v njej ni nič nevarnega, če bi res šlo za sprejemnik. Vendar to ni samo napaka v sporočilu, varnostna kopija zadnjega dnevnika je pomotoma izvedena na viru. To lahko eksperimentalno preizkusite tako, da kliknete gumb Skript in pogledate kodo.

Zato je treba v petem koraku to operacijo preklicati (glejte spodaj). Popravljanje najnovejših sprememb sprejemnika (ki bi se lahko zgodile od ustvarjene zadnje varnostne kopije VT) je treba opraviti ročno (na primer z nenačrtovanim zagonom ustrezne naloge).

Zdaj pa poglejmo, kaj dejansko lahko služi kot vir. V pogovornem oknu je prikazano, da je vir lahko zbirka podatkov in naprava. Ali moram pojasnjevati, da sama baza podatkov ne more služiti kot vir podatkov za poljubno časovno točko v preteklosti. Vir so lahko varnostne kopije baze podatkov. Zato je potrebna razlaga možnosti.

• Izvorna baza podatkov – celoten niz datotek, ki vsebujejo varnostne kopije izvorne baze podatkov in njenih dnevnikov glede na rezervni register, ki se vzdržuje v sistemskih tabelah strežnika SQL. »Glede na rezervni register« je izredno pomembna fraza za razumevanje mehanizma delovanja. To pomeni, da tudi če kakšna datoteka trenutno manjka na disku, se lahko upošteva v obnovitvenem načrtu (ker je popravljena v registru) in se prikaže na seznamu Varnostno kopiranje naborov za obnovitev. Napaka se bo pojavila samo v fazi obnovitve in če gre za varnostno kopijo Diff ali varnostno kopijo TLog - baza bo ostala v neuporabnem stanju. Da se to ne bi zgodilo, najprej preverite možnost obnovitve z gumbom "Preveri medij varnostne kopije".
• Vir naprave je poljuben nabor datotek. Dejstvo je, da je zgodovino varnostnih kopij mogoče počistiti. Ali pa so bile varnostne kopije ustvarjene na drugem strežniku SQL in zato niso registrirane v registru varnostnih kopij na tem strežniku. Zato je mogoče izrecno podati poljuben nabor datotek. Določite lahko nabor datotek, ki so odvečne za obnovitev (na primer več dni - strežnik SQL bo v naslednjem koraku izbral samo potrebne).

Drugo dejanje- izberite vir, ki je v našem primeru drugačen od sprejemnika. Novejše različice MS SQL Server se na to odzivajo normalno. Starejše različice imajo neprijetne učinke, ki jih je treba skrbno spremljati, da preprečite izgubo podatkov:

• Učinek 1. MS SQL takoj spremeni Destination v bazo podatkov, navedeno v Source. Zato je treba destinacijo vrniti nazaj. Če tega ne opazite, bo baza podatkov tiho prepisana in tudi nepotrjena zastavica "Prepiši obstoječo bazo podatkov" na zavihku Možnosti je ne bo mogla zaščititi;
• Učinek 2. Preklopite na zavihek Datoteke in vidite - namesto sprejemnika želi MS SQL Server prepisati izvor (glejte naslednjo sliko). Potrebno je ročno vnesti imena datotek prejemne baze in njenega dnevnika, sicer bo vir izgubljen (glej četrti korak spodaj).

Tretje dejanje. Ko izberete nabor datotek kot vir, morate določiti časovno točko (Obnovi v, gumb Časovnica). Določanje časovne točke vam omogoča, da izberete določen nabor (Backup sets to restore) iz prvotnega nabora datotek, ki jih določa vir (Source), ki je potreben za obnovitev v določen čas. Očiten postane še en absurd, ki je prisoten tudi v najnovejših različicah MS SQL: možnost »Obnovi v« in gumb TimeLine sta v pogovornem oknu narisana na napačnem mestu. Vsekakor se nanašajo na izvor, ne na cilj. Ta napaka ne bo nikoli odpravljena, stara je več kot 10 let, zato se je morate samo navaditi. Prav tako bodite zelo previdni pri ročnem vnašanju časa brez uporabe ravnila: celo najnovejše različice SQL strežniki "pojedo" prvi vnos dneva v mesecu, zato bo treba številko vnesti dvakrat.

Četrto dejanje.

Peto dejanje. Preklopite na zavihek Možnosti. Nastavite možnost za prepis baze podatkov, počistite možnost za ustvarjanje končnega fragmenta VT, omogočite možnost "zapri obstoječe povezave s ciljno bazo", če je na voljo:

Šesto dejanje. Po obnovitvi iz »tujega vira« bo obnovljena osnova (ZUP_SUV) dobila tuje logično ime (ZUP3ENERGO). Vrniti ga je treba nazaj v pogovornem oknu lastnosti baze podatkov (desni klik na bazo podatkov, Lastnosti). Če tega ne storite, bodo posledice zelo neprijetne.

Vso srečo vam in vašim podatkom!

Varnostno kopiranje v 1C 8.3 in 8.2 je najpomembnejša operacija, ki bi jo moral znati izvajati vsak uporabnik, programer, skrbnik. Taki specialisti za kopiranje Informacijska tehnologija pogosto imenovan tudi rezervni 1C. Razmislite, kaj je to in podrobna navodila.

Ljudje so razdeljeni v dve kategoriji: tisti, ki še ne delajo varnostnih kopij, in tisti, ki že delajo.— Šala sistemskih administratorjev.

Zakaj je pomembno varnostno kopiranje? Vse je zelo preprosto, spomniti se morate zakona zlobnosti: najhujše stvari se zgodijo ob nepravem času.

Predstavljajte si - en mesec pripravljate končna poročila, popravljate napake, vozite kilograme primarne dokumentacije v program. Potem smo se odločili, da si vzamemo odmor, natočimo čaj. Nazaj delovnem mestu, ugotovite, da se je čistilka dotaknila kabla (napetost električnega toka, sodelavci so preplavili aparat s kavo itd.) vašega sistemski blok. Mrzlično poskušate prižgati računalnik, a se ne odziva. Javljam se jutri kaj storiti?

Da ne bi prišli v takšno situacijo, je zelo priporočljivo, da varnostno kopirate vsaj enkrat na teden (ali bolje enkrat na dan). To ni težko narediti, trajalo bo največ 10 minut, vendar bo močno olajšalo življenje v težki situaciji.

Pridobite 267 video lekcij 1C brezplačno:

Navodila za varnostno kopiranje v 1C

Razmislite kratka navodila za odstranitev varnostne kopije baze podatkov v 1C. Navodilo je primerno tako za datotečni način baze podatkov kot za način odjemalec-strežnik.

Nalaganje kopije baze podatkov v datoteko

Vnesite program v načinu konfiguratorja. Če želite to narediti, v začetnem oknu programa izberite želeno bazo podatkov in kliknite »Konfigurator«:

Vstopili boste v način razvoja baze podatkov in administracije. Nato izberite točko menija "Administracija - Odstrani informacijsko bazo ...":

Program vas bo pozval, da izberete pot, kamor želite naložiti datoteko zbirke podatkov, in njeno ime. Po izbiri bo program poročal o uspešnem zaključku operacije:

Najbolje je, da datoteko shranite na zunanji medij (na primer bliskovni pogon, zunanji HDD).

Kako obnoviti bazo podatkov 1C 8.3 iz varnostne kopije

Če želite obnoviti bazo podatkov iz datoteke, morate vstopiti tudi v način konfiguratorja, vendar izberite element »Administracija - Naloži informacijsko bazo ...«:

Varnostne kopije lahko ustvarite na več načinov:

• Kopiranje datotek baze podatkov;
• Nalaganje datoteke v datoteko .dt;
• Varnostno kopiranje z uporabo konfiguracijskih orodij 1C 8.3.

Razmislimo o vsakem od načinov za ustvarjanje "varnostnih kopij" baz podatkov 1C podrobneje.

Preprosto kopiranje datoteke z razširitvijo " *.1CD" in če je treba - 1Cv8Log" iz imenika IB :

Dnevnik dogodkov shranjuje informacije o vstopu in izstopu iz seje, spremembah podatkov, zagonu in izvajanju opravil v ozadju ter druge informacije, odvisno od nastavitve:

Ta metoda kopiranja vam omogoča izvajanje, ko se izvajajo uporabniške seje, vendar v času kopiranja v IB NE BI SMEL bodite aktivni (ustvarjanje, snemanje, objavljanje dokumentov), ​​saj lahko dobite napačno kopijo.

Raztovarjanje baze podatkov 1C v konfiguratorju, kjer se ustvari stisnjena datoteka s pripono dt. Po potrebi lahko registracijski dnevnik tudi posebej arhivirate.

Razkladanje informacijske baze

IB zaženemo v načinu Konfigurator:

Zaženemo čarovnika za razkladanje IB:

Razložimo IB, kjer navedemo lokacijo varnostne kopije:

Po zaključku se prikaže sporočilo o zaključku razkladanja IB:

Ko ustvarite kopijo, morate preveriti (testirati) delovanje dt datoteka - z nalaganjem IB najprej ustvarite IB za testiranje.

Kako obnoviti bazo podatkov iz varnostne kopije 1C 8.3

IB zaženemo v načinu konfigurator.

Zaženemo čarovnika za prenos IB, kjer določimo lokacijo *.dt mapa:

Po obnovitvi varnostne kopije 1C se prikaže opozorilo o uspešnem nalaganju IB in zahteva za ponovni zagon Konfigurator:

Pri ustvarjanju tega načina varnostnega kopiranja morajo vsi uporabniki tega IB zaključiti svojo sejo.

Za več podrobnosti o tem, kako obnoviti podatke iz predhodno ustvarjene varnostne kopije, vključno s tem, kako obnoviti podatke v obstoječo informacijsko bazo ali novo ustvarjeno informacijsko bazo, si oglejte naš videoposnetek:

Ustvarjanje in konfiguriranje arhiva 1C z uporabo konfiguracijskih orodij

Samodejno varnostno kopiranje , ki je konfiguriran v uporabniškem načinu 1C:Enterprise. Ta način ustvarili razvijalci v konfiguracijah na platformi 1C:Enterprise 8.3 ("Enterprise Accounting, rev. 8.3", "Salary and HR Management, rev. 8.3", "Trade Management, rev. 11.2"):

Tukaj lahko:

• Zaženite enkratno varnostno kopijo:

• Ustvari urnik:

• Obnovi iz varnostne kopije:

Nasvet:

• Hranite varnostne kopije na drugih fizičnih ali zunanjih medijih, npr v primeru okvare trdi disk lahko izgubite sam IB in njegove kopije.
• Izdelujte redne varnostne kopije. Da bi se odločili, kako pogosto morate varnostno kopirati, morate odgovoriti na vprašanje: "Kako cenite svoje delo in delo svojih sodelavcev." Pogosteje kot ustvarjate varnostne kopije, manj truda je potrebno za ponovno vnašanje dokumentov. Vendar ne pozabite ustvariti varnostne kopije, preden posodobite konfiguracijo.

Če imate še vedno vprašanja, si lahko ogledate naš videoposnetek, ki podrobneje opisuje, kako ustvariti arhivsko kopijo informacijske baze z orodji same tehnološke platforme v načinu konfiguratorja:

Ocenite ta članek:

Da bi se zaščitili pred delno ali popolno izgubo podatkov, morate pred kakršnimi koli dejanji z vašo informacijsko bazo varnostno kopirati podatke v 1C. Z varnostno kopijo lahko bazo podatkov vrnete v stanje, v katerem je bila v času kopiranja.

Ročno ustvarjanje varnostne kopije 1C

Zaženemo 1C in izberemo način konfiguratorja za vašo informacijsko bazo:

Po vstopu v konfigurator pojdite v meni Administracija in izberite postavko “Naloži informacijsko bazo”

Prikaže se okno, v katerem morate določiti mapo za shranjevanje varnostnih kopij (v mojem primeru se imenuje Arhivske kopije 1C, poimenujete jo lahko poljubno), ime datoteke varnostne kopije (v mojem primeru BP20082012, prvi dve črki so oznaka imena infobaze, nato datum shranjevanja, to je 20. avgust 2012) in kliknite gumb shrani.

Čakamo, da program shrani datoteko. Izvajanje te operacije lahko opazujete v spodnjem levem kotu okna konfiguratorja:

Po zaključku bo program prikazal naslednje sporočilo:

Varnostna kopija je ustvarjena.

Kako obnoviti bazo podatkov iz varnostne kopije je opisano v.

Nastavitev samodejnega varnostnega kopiranja v 1C po urniku

Ta vodnik vam bo pomagal nastaviti varnostno kopijo v avtomatski način. Primeren je samo za datotečni način delovanja v bazi podatkov 1C. Za konfiguracijo v načinu odjemalec-strežnik 1C priporoča izdelavo varnostnih kopij z orodji DBMS - MS SQL, Postgre itd.

Če želite konfigurirati, pojdite na zavihek "Administracija", element "Podpora in vzdrževanje":

Kopije podatkovnih baz lahko shranite na svoj računalnik ali na zunanji trdi disk, možna pa je tudi uporaba storitve 1C Cloud Archive.

Tukaj je na voljo tudi funkcija ročnega zagona varnostnega kopiranja in obnovitve, vendar nas zanima element »Nastavitve varnostnega kopiranja«:

Možne konfiguracijske možnosti so načrtovane in ob koncu dela s programom. Najboljše od vsega, še posebej, če delate v bazi več kot enega, izberite možnost "Redno po urniku". Nastavitev je zelo enostavna. Na posnetku zaslona sem nastavil dnevno rutino:

Poleg teh nastavitev morate določiti tudi imenik za shranjevanje kopij (najbolje je uporabiti Google Drive ali Yandex Disk) in koliko varnostnih kopij želite shraniti:

V tej vadnici si bomo ogledali, kako je konfigurirana varnostna kopija. baza datotek 1C, katere možnosti varnostnega kopiranja obstajajo in kako preveriti ustvarjeno varnostno kopijo.

To navodilo velja samo za zbirke podatkov datotek. Če imate bazo podatkov odjemalec-strežnik, mora biti njena varnostna kopija konfigurirana z uporabo DBMS () ali s programi drugih proizvajalcev.

Kot primer vzemimo tipično konfiguracijo "Enterprise Accounting Edition 3.0"

Nastavitev varnostnega kopiranja podatkovne baze datotek 1C

Pojdite v meni "Administracija" - "Vzdrževanje":

Razširite razdelek »Varnostno kopiranje in obnovitev«.

Tukaj nas zanima polje "Metoda varnostnega kopiranja".

Obstajata 2 možnosti: in "1C: arhiv v oblaku".

Razmislimo o vsaki od možnosti.

1C: Arhiv v oblaku

Če imate naročnino na ITS:Prof in je ne nameravate zavrniti, priporočam uporabo "1C: Arhiv v oblaku", Ker ta storitev je za vas brezplačna. Še en plus shranjevanja v oblaku je, da lahko obnovite bazo podatkov, ko je računalnik fizično uničen ali če se vaš trdi disk pokvari. Če nimate ITS, nadaljujte z naslednjim razdelkom.

Izberite "1C: storitev v oblaku« in kliknite »Poveži«:

V obrazec, ki se odpre, vnesite svoje uporabniško ime in geslo iz ITS in kliknite »Poveži«:

Tehnični podpori bo ustvarjeno pismo, ki vam bo pomagalo pri registraciji.

Če ni naročnine ITS:Prof, vas bo oblak stal skoraj 1000 rubljev / mesec. Zdaj bomo analizirali, kako narediti isto, vendar brezplačno.

Izberite možnost »Vklopljeno lokalni računalnik« in kliknite »Nastavitve varnostnega kopiranja«:

Potrdite polje »Izvedi samodejno varnostno kopiranje«

Določite imenik za shranjevanje varnostnih kopij. Bolje je, da je ločen trdi disk. Če ni ločenega trdega diska, določite imenik na particiji diska, kjer Windows NI nameščen. Tisti. vse razen pogona "C":

Imenik za shranjevanje varnostnih kopij

"Hrani varnostne kopije"- določite "Zadnjih 10 kosov", običajno je to dovolj, poleg tega ne bo zavzelo veliko prostora na trdem disku:

Ohranite samo zadnjih 10 kopij

Zdaj se moramo odločiti, kako bo varnostno kopiranje izvedeno: "Redno po urniku" ali .

Pri izbiri je treba upoštevati, da bodo v obeh primerih vsi uporabniki baze 1C "izgnani", da naredijo varnostno kopijo.

Možnost "Redno načrtovano"

To možnost lahko izberete, če vsi uporabniki odidejo hkrati, na primer na kosilo ali čaj.

Nato kliknite »En dan; enkrat na dan" in izberite urnik. Na primer, 15 minut po tem, ko so vsi odšli na kosilo (če kdo zamuja)

V meniju, ki se odpre, vnesite "1" v polje "Ponovi vsak", da dobite "Vsak dan; enkrat na dan":

Pojdite na zavihek "Dnevno" in v polju "Začetni čas" določite čas, ko želite narediti varnostno kopijo. Nato kliknite "V redu":

Rezultat bi moral izgledati takole:

Upoštevajte, da mora vaša 1s seja teči v tem času, tj. ko odhajate na kosilo, morate pustiti 1s omogočeno, da se ustvari kopija

Možnost "Ob zaustavitvi"

Ta možnost je primerna za vas, če zadnji zapustite pisarno (ali vsaj zadnji, ki zapustite 1C).

Pri tej možnosti vam ni treba ničesar dodatno konfigurirati. Ko zaprete 1C, vam bo sistem ponudil, da naredite varnostno kopijo.

Kako deluje varnostna kopija ob zaustavitvi?

Ko zapustite 1C, se prikaže okno "Varnostno kopiranje ni dokončano ob zaustavitvi":

Varnostno kopiranje ob zaustavitvi ni uspelo

Če kliknete »Zaustavi«, se bo 1C zaprl brez varnostne kopije.

Ko v spodnjem desnem kotu 1C kliknete »Nadaljuj«, se prikaže naslednje okno:

Okno s pozivom, da naredite varnostno kopijo

Kliknite nanj, da se prikaže to okno:

Zaženite varnostno kopijo

Preostane vam le, da kliknete »Dokončaj«, ne da bi počistili polje »Izvedi varnostno kopiranje«. Po tem bo 1C naredil varnostno kopijo in dokončal delo:

Ustvarjanje varnostne kopije informacijske baze

Torej, najpomembnejše je bilo storjeno, varnostne kopije se ustvarjajo, ostalo je samodejno nalaganje kopij v oblak, da se podatki zaščitijo pred višjo silo.

Nalaganje varnostnih kopij 1C v oblak

Prenesite katero koli aplikacijo storitve v oblaku v svoj računalnik. Običajno izbirajo med Cloud mail.ru in Yandex.Disk. Če vaše varnostne kopije "tehtajo" manj kot 2 GB, potem lahko izberete katero koli, če varnostne kopije tehtajo več kot 2 GB, potem morate zagotovo vzeti Yandex.Disk. Če imate raje kakšno drugo storitev v oblaku - jo uporabite. Glavna stvar je, da ta storitev sprejema datoteke prave velikosti.

//help.mail.ru/cloud_web/confines

Omejitve naloženih datotek:

pripravljena! Nastavitev varnostne kopije baze datotek 1C je zdaj končana.

Preverjanje ustvarjenih varnostnih kopij 1C

Pojdite v mapo z bazo podatkov in izbrišite datoteko "1Cv8.1CD"

Odprite zadnji ustvarjeni arhiv s kopijo baze podatkov in ekstrahirajte datoteko, ki je tam, v mapo z novo bazo podatkov:

Ekstrahiranje datoteke baze podatkov

Pojdite v novo bazo podatkov in preverite, ali so tam potrebni podatki (na primer sveže implementacije). Če se je zbirka podatkov začela in so podatki na svojem mestu, je vse v redu.