Rezervimi 1-sh dështoi. Periodiciteti i ndërlidhur i rezervimit të plotë dhe kopjimit të Diff

Tradicionalisht, përdoruesit e 1C ndahen në dy kategori: ata që bëjnë kopje rezervë * dhe ata që fillojnë t'i bëjnë ato. Për të mos mësuar nga gabimet tona, le të fillojmë të bëjmë kopje rezervë që tani.

*Nëse tashmë jeni duke bërë kopje rezervë, ky artikull do të jetë akoma i dobishëm për ju, sepse shumë nga ato që mund të gjeni dhe lexoni rreth kopjimit në internet janë të gabuara dhe shumë të rrezikshme për sigurinë e të dhënave tuaja. Nëse jeni specialist i TI-së, vazhdoni të lexoni seksionin "Kaprimi i një baze informacioni 1C duke përdorur SQL".

A ia vlen vërtet të shpenzosh kohë për këtë?

A mund të prishet disi baza e informacionit 1C në kohën tonë? Gjithçka thyhet: çajnikët dhe aeroplanët, një këmbë stoli dhe një mikroskop elektronik. Është e vështirë të thyesh vetëm diçka shumë të thjeshtë, si një top prej gize. Por baza e informacionit 1C është një objekt kompleks dhe funksionon në një mjedis kompleks teknologjik. Herët a vonë, diçka do të ndodhë, në fillim mjaft e parëndësishme, dhe më pas "vida e lirshme" do të shkaktojë një kaskadë dështimesh të softuerit dhe harduerit, të cilat përfundimisht do të përfundojnë në telashe të mëdha dhe humbje të bazës së informacionit.

Versioni i skedarit të bazës së informacionit

Le të fillojmë me shembullin më të thjeshtë. Në një organizatë të vogël, një konfigurim 1C funksionon me një bazë informacioni skedari, i cili mirëmbahet nga një administrator i sistemit në hyrje, i cili me siguri konfiguron gjithçka. Por! Mungesa e mesazheve "Backup nuk është konfiguruar" nuk do të thotë se është konfiguruar tani. Mund të nënkuptojë gjithashtu se mesazhi thjesht nuk shfaqet. Prandaj, duke marrë përgjegjësinë për besueshmërinë dhe sigurinë e rezultateve të punës sonë, fillimisht sigurohuni që baza e informacionit të jetë një skedar. Si ta bëni këtë tregohet qartë në ilustrimin e mëposhtëm. Nëse thotë Srv= në vend të File=, kjo është një bazë të dhënash SQL dhe kontaktoni DBA-në tuaj për të krijuar një kopje rezervë. Nëse baza e të dhënave është skedar, mund të përdorni kopjim manual ose automatik.

Mënyrë manuale– krijoni një kopje rezervë siç tregohet në ilustrim. Përpara shkarkimit, të gjithë përdoruesit duhet të përfundojnë punën me bazën e informacionit. Ngarkimi krijon një skedar të vetëm rezervë me një shtesë .dt që përmban Pothuajse te gjitha(më shumë për këtë më vonë), çfarë është aktualisht në infobazë dhe çfarë do të futet më pas. Jepini skedarit një emër kuptimplotë (për shembull, "Rezervimi i kontrollit të tregtisë në 2017-10-31") dhe zgjidhni një dosje të veçantë për ta ruajtur atë (për shembull, dosja "Backups" në dosjen "Dokumentet e mia"). Duke përdorur këtë skedar, më pas mund ta rivendosni bazën e informacionit në gjendjen që i parapriu shkarkimit. Për të rivendosur, përdorni funksionin "Ngarkoni infobazën".

Një konfigurim tipik rezervë tregohet në ilustrim. Ky cilësim supozon që një përdorues me të drejta administratori e lë programin të hapur në fund të ditës së punës (përndryshe rezervimi nuk do të kryhet) dhe të gjithë përdoruesit e tjerë mbyllin programin. Një opsion alternativ është të kryeni një kopje rezervë në mbyllje (do t'ju kërkohet të konfirmoni nëse nevojitet rezervimi).

Kur arrin koha e rezervimit në rastin e parë, ose kur përdoruesi i fundit me të drejta administrative del në rastin e dytë, sistemi do të bllokojë bazën e informacionit dhe do të mbyllë të gjithë përdoruesit. Ky është një proces kompleks që mund të mos funksionojë, duke rezultuar në një gabim rezervë (ilustruar më poshtë). Ju mund të lexoni një artikull të veçantë në lidhje me këtë në faqen tonë të internetit.

Prandaj, nuk do të funksionojë të kufizoni veten në një cilësim rezervë automatike një herë; ju ende duhet të monitoroni rregullisht krijimin e kopjeve rezervë.

Dhe tani disa pyetje që nuk mbulohen në artikujt e njohur mbi temën e kopjimit.

• A do të mbështetet gjithçka?

Nr. Ju mund të humbni ose korruptoni historinë e punës (kush dhe kur ka hyrë dhe ka dalë nga programi), historia e objektit ndryshon (kush dhe kur ka ndryshuar të dhënat). Ky informacion ruhet jashtë bazës së informacionit dhe ruajtja e tij dhe rikuperimi i saktë kërkojnë veprime të veçanta. Ju mund të humbni ose dëmtoni skedarët 1C të bashkangjitur me objekte (skanime dokumentesh, fotografi, etj.). Në varësi të cilësimeve, këto të dhëna mund të ruhen brenda ose jashtë bazës së informacionit; në rastin e fundit, ruajtja dhe rivendosja e saktë e saj kërkon gjithashtu veprime të veçanta. Rezervimi gjithashtu nuk ruan personalizimet e formave të menaxhuara të bëra nga përdoruesit.

• A është e mundur të bëni një kopje rezervë gjatë punës?

Mekanizmi standard fillimisht përpiqet të mbyllë përdoruesit. Megjithatë, kjo nuk është gjithmonë e mundur, kështu që operacioni rezervë mund të kryhet ndërsa përdoruesit janë duke punuar. Në këtë rast, supozohet se këta përdorues nuk i modifikojnë të dhënat. Por nëse nuk është kështu, nuk ka asnjë garanci që rezervimi është i saktë. Pra, përgjigja për këtë pyetje është jo, ju nuk mundeni.

• Sa shpesh duhet të bëhen kopje rezervë?

Varet nga intensiteti i futjes së të dhënave dhe kritika e humbjes së tyre. Për një biznes të vogël me një ose dy përdorues 1C, ju rekomandojmë ta bëni këtë të paktën çdo ditë. Me 20 përdorues, ne rekomandojmë krijimin e një kopje rezervë çdo natë dhe disa kopje rezervë gjatë rrjedhës së një dite pune. Siç e mbani mend, kjo do të sjellë një ndërprerje të përkohshme teknologjike në punën e përdoruesve.

• Kemi pasur raste të humbjes së të dhënave dhe do të donim të kalonim në versionin SQL të infobazës, por është shumë i shtrenjtë ...

Ju mund të dëshironi të përdorni versionin falas të MS SQL. Na kontaktoni për këshilla.

Versioni SQL i bazës së informacionit

Kjo pjesë e artikullit do të jetë me interes për specialistët dhe ata që sapo do të bëhen të tillë.

Le të sqarojmë menjëherë se është e pamundur të shmangësh detyrën rezervë. As riprodhimi dhe as hardueri absolutisht i besueshëm nuk do të mbrojnë nga korrupsioni aksidental ose me qëllim të keq të të dhënave në nivelin e aplikacionit (mbyllja e gabuar e muajit, funksionimi i gabuar i përpunimit të korrigjuar dobët të ndryshimeve masive të të dhënave, etj.). Të dhënat në këtë rast ruhen në mënyrë të sigurt, por janë të pasakta dhe nuk ka kopje rezervë, kështu që një rikthim nuk është i mundur. Në praktikë, ju duhet të rivendosni bazën e informacionit 1C për shkak të korrupsionit të të dhënave shumë më shpesh sesa mund ta imagjinoni.

Nga pikëpamja e një përdoruesi që jeton në hapësirën konceptuale të bazave të skedarëve, kemi pikat e rivendosjes në formën e kopjeve rezervë të bazës së informacionit, të ndara sipas kohës nga frekuenca e kopjeve rezervë: nëse bëjmë kopje një herë në ditë, atëherë në rast restaurimi do të humbasim ndryshimet e bëra në bazën e të dhënave për një maksimum një ditë ose më pak. Por në mjedisin e serverit SQL, si mënyra se si ruhen/modifikohen të dhënat ashtu edhe teknologjitë rezervë ofrojnë një numër "të pafund" pikash që bashkohen në një. linja e rikuperimit të vazhdueshëm. Kjo do të thotë që ju mund të ktheheni në pikën menjëherë para dështimit ose, nëse është e nevojshme, në çdo moment në kohë prapa. Në gjuhën e përdoruesit, kjo është e barabartë me krijimin e kopjeve rezervë një herë në sekondë ose më pak.

Fakti është se rezervimi në mjedisin SQL nuk është një sekuencë e shtypjes së butonave, por një grup ngjarjesh të rregullta mbi objekte komplekse. Dhe ky kompleks është krijuar në një mjedis shumë kompleks.

Për të kuptuar "si funksionon gjithçka", ne do të tregojmë edhe një herë qëllimin e veprimeve tona - kopjimin e plotë të të dhënave deri në sekondën para dështimit (ose momentin e bërjes së ndryshimeve të padëshiruara) dhe aftësinë për t'u rikthyer në një pikë arbitrare në koha e saktë për të dytën.

A është rikuperimi i të dhënave i saktë për të dytën me të vërtetë kaq të rëndësishëm?

Kjo është e rëndësishme për sistemet e zyrave të përparme ose kur ndërmarrja arrin një shkallë të caktuar. Le ta sqarojmë këtë deklaratë duke bërë disa pyetje kryesore. A është e lehtë të organizosh rihyrjen e të dhënave në një rrjet degësh që është i shpërndarë në 10 rajone me zona të ndryshme kohore dhe ka disa mijëra punonjës? Si të kontrolloni korrektësinë e tij? Le të themi se mund të marrësh faturën dhe të rifusësh të dhënat prej saj. Dhe si të rifuten të dhënat që kanë hyrë në sistem kur ndërvepron me pajisjet (regjistruesit fiskalë, terminalet bankare) ose me sistemet e informacionit të palëve të treta (krediti në internet, përpunimi i kartave zbritëse të një rrjeti të vetëm partneri), me pjesëmarrjen e një rrjeti të madh numri i njerëzve (gjurmë gishtash në sistemet e regjistrimit të kohës së punës)? Ku mund ta gjej burimin e informacionit për rihyrje nëse nuk ka dokumente dhe të gjitha veprimet regjistrohen në mënyrë pa letra (kontabilizimi i vakteve në mensën e korporatës duke përdorur një kartë punonjësi)?

Si të merrni një kopje të bazës së të dhënave me të gjitha të dhënat që ishin në sistem "një sekondë para shpërthimit"

Regjistri i transaksioneve (TLog)

Është e nevojshme të regjistrojmë të gjitha veprimet që do të kryejmë me bazën e të dhënave, plus kohën e tyre të saktë (deri në mikrosekonda), dhe vetëm atëherë t'i ekzekutojmë ato. Duke pasur një regjistër të tillë (të ruajtur në një medium shumë të besueshëm dhe të shpejtë, domosdoshmërisht të ndarë nga vetë baza e të dhënave), ne mund të përsërisim të gjitha operacionet që nga momenti kur baza e të dhënave filloi të ekzistonte deri në një moment rikuperimi arbitrar me saktësi mikrosekondi. Por regjistrimi i transaksioneve ka dy të meta: pas njëfarë kohe, ndërsa baza e të dhënave rritet, TLog do të zërë shumë hapësirë ​​(sepse rritet vazhdimisht), dhe rikuperimi nga pika "zero" në kohë do të marrë shumë kohë.

Rezervimet e regjistrit të transaksioneve (Rezervimet TLog)

Në mënyrë figurative, ne do t'i marrim rregullisht të gjitha fletët nga regjistri dhe do t'i çojmë në dhomën tjetër (le t'i quajmë fletët e sekuestruara TLog rezervë), dhe do të vendosim një paketë me fletë të reja bosh në vetë regjistrin në mënyrë që të ketë ku të regjistrohen të reja veprimet me bazën. Teknikisht, kjo bëhet si më poshtë: bëhet një kopje nga skedari TLog dhe shkruhet në diskun e arkivit, pas së cilës të gjitha hyrjet në TLog "fshihen" (shënohen si të lira, madhësia e skedarit log nuk ndryshon), informacioni për transaksionet e reja shkruhet në vendin e "fshirë". Është shumë e rëndësishme të kuptohet se çdo paketë fletësh të grisura, megjithëse në terminologjinë e vendosur quhet rezervë e regjistrit të transaksioneve, është i vetmi një bartës informacioni në lidhje me veprimet me bazën për këtë periudhë, dhe tani ky informacion nuk është në vetë regjistrin. Prandaj, humbja e qoftë edhe një “fletë e grisur” është absolutisht e papranueshme për momentin dhe termi Tlog rezervë maskon me dinakëri thelbin dhe qëllimin e këtij informacioni. Mbani mend - kjo nuk është një kopje rezervë! Ne e kemi ndarë regjistrin në shumë skedarë dhe informacioni në secilin prej tyre nuk kopjohet askund. Por termi "Rezervimi i regjistrit të transaksioneve" është përgjithësisht i pranuar, kështu që ne do të vazhdojmë ta përdorim atë në të ardhmen.

Tani TLog nuk rritet pafundësisht, por lind një detyrë rutinë - rezervimi i planifikuar i TLog.

Rezervimi i plotë i bazës së të dhënave (Rezervimi i plotë)

Nëse bëni periodikisht kopje të të gjithë bazës së të dhënave, atëherë për rikuperim do të jetë e mundur të merrni kopjen më të përshtatshme për sa i përket kohës dhe të përsërisni jo të gjitha operacionet nga pika zero në kohë, por vetëm operacionet nga momenti i krijimit të kësaj kopje deri në momentin e restaurimit (siç thonë ata, "merr një kopje rezervë të plotë dhe vendos TLog mbi të"). Kjo zvogëlon ndjeshëm kohën e rikuperimit, veçanërisht nëse baza e të dhënave ka ekzistuar për 5 vjet.Përveç kësaj, tani kemi mundësinë të fshijmë rezervimin e vjetër Full dhe TLog backup. Në fakt, kthimi në sekondën më të afërt shpesh mund të jetë i nevojshëm vetëm për një periudhë të shkurtër kohore (për shembull, dy muaj më parë nga momenti aktual për të hetuar disa incidente ose për të rivendosur bazën e të dhënave një sekondë përpara paraqitjes tragjike të ndryshimeve të padëshiruara). Gjatë kësaj periudhe, ne do të ruajmë një zinxhir të pandërprerë kopjesh rezervë TLog. Jashtë kësaj periudhe, ju mund të ruani vetëm pikat e rikuperimit në formën e një kopje rezervë të plotë (dhe madje edhe atëherë jo të gjitha, por për shembull, vetëm pikët për ditët e para të muajit). Rezervimet e TLog jashtë periudhës tani mund të fshihen fare (natyrisht, fshirja e tyre selektive dhe ruajtja selektive jashtë periudhës është plotësisht e pakuptimtë për shkak të ndërprerjes së zinxhirit TLog). Në një mënyrë apo tjetër, lind detyra rutinë e fshirjes inteligjente.

Këtu lind problemi i mëposhtëm. Imagjinoni një bazë të dhënash me një numër të madh përdoruesish dhe një shkallë të lartë ndryshimi. Me kusht - 33% e kohës shpenzohet për të shkruar dhe 67% për lexim, nuk ka kohë joproduktive. Kur rivendosim bazën e të dhënave, mund të shkruajmë pothuajse 100% të rasteve, d.m.th. tre herë më shpejt. Kjo do të thotë që ne mund të rivendosim tre orë punë me bazën e të dhënave nga regjistri në orë. Dhe kjo orë është koha maksimale e ndërprerjes për rikuperimin që biznesi pranon. Le të themi se Rezervimi i plotë bëhet një herë në ditë. Nëse dështimi ka ndodhur 21 orë nga tani, do të duhet të shpenzojmë 7 orë në rikuperimin e regjistrave, gjë që është absolutisht e papranueshme. Pra, rezervimi i plotë duhet të bëhet 1 herë në 3 orë? Mjerisht, kjo nuk është gjithmonë e mundur: bazat e të dhënave janë aq të mëdha (qindra gigabajt dhe madje terabajt) sa është thjesht e pamundur të krijosh një kopje rezervë të plotë në një kohë të tillë. Përveç kësaj, krijimi i shpeshtë i një kopje rezervë të plotë gjatë orarit të punës jep një ngarkesë shtesë dhe ngadalëson punën e përdoruesve, dhe është shumë e shtrenjtë të ruash një sasi të tillë të dhënash. Por në parim, mjafton që pamundësia për të krijuar një kopje rezervë të plotë në një kohë të pranueshme t'i japë fund plotësisht teknologjisë sonë rezervë.

Rezervimet diferenciale (Rezervimi diferencial, Rezervimi i dallimeve)

Ne mund të dalim me një strukturë të veçantë të ruajtjes së të dhënave me një numër vazhdimisht në rritje të transaksioneve dhe trukeve të tjera që e bëjnë të lehtë kuptimin e ndryshimit midis dy gjendjeve të bazës së të dhënave (nga tani e deri më tani - ka qenë tashmë, gjithçka që vijon është tashmë e re). Kjo do të lejojë që jo të gjitha të dhënat të ruhen në kopjen rezervë të bazës së të dhënave, por vetëm ndryshimet midis rezervimit aktual të plotë dhe rezervimit të plotë të mëparshëm. Procedura për marrjen e kopjes tjetër të plotë do të jetë e thjeshtë: merrni kopje rezervë të plotë dhe vendosni kopje rezervë të Diff mbi të. Në vend që të ruanim një terabajt të dhënash në kopje rezervë të plotë, ne ruajtëm vetëm dhjetë megabajt në rezervimin e Diff dhe patëm mundësinë për ta bërë këtë mjaft shpesh - për shembull, një herë në gjysmë ore. Por duhet të siguroheni që ekziston një kopje rezervë e plotë, përndryshe ajo diferenciale është e padobishme.

Në këtë vend, ju mund të krahasoni shumë mirë një kopje rezervë diferenciale dhe një kopje rezervë të regjistrit të transaksioneve, duke rregulluar informacionin e marrë. Nëse nuk bëni një kopje të plotë, madhësia e kopjeve rezervë diferenciale do të rritet në mënyrë monotone, sepse Gjithnjë e më shumë dallime nga kopja e plotë do të grumbullohen - dhe kështu me radhë derisa të krijohet rezervimi tjetër i plotë. Madhësia e rezervave të ardhshme të regjistrit të transaksioneve nuk do të ketë një tendencë të tillë, madhësia e tyre përcaktohet nga numri i veprimeve të kryera me bazën e të dhënave për periudhën. Zakonisht madhësia e tyre luhatet rreth një vlere mesatare të caktuar, por në periudha të caktuara (kur kryhen operacione të ndryshimit të të dhënave në masë, gjatë rritjes së aktivitetit të përdoruesit, etj.) mund të ndryshojë shumë nga mesatarja.

Ilustrimi më poshtë përshkruan sistemin tonë rezervë me një farë shkalle konvencionaliteti. Rreshti i parë i objekteve tregon gjendjen e bazës së të dhënave, në të cilën të dhënat shtohen periodikisht. E dyta shfaq një kopje rezervë të plotë dhe tre diferenciale. Rreshti i tretë shfaq përmbajtjen e kopjeve rezervë të regjistrit të transaksioneve. Çdo element është i numëruar. Le të vendosim disa varësi midis elementeve.

• 5+7=3. Kjo do të thotë se duke pasur Full backup 5 dhe Diff backup 7, ju mund ta rivendosni bazën e të dhënave në gjendjen 3. Në të njëjtën kohë, mungesa e 6 nuk do të ndikojë në asnjë mënyrë mundësinë e rikuperimit.
• 5+10+11=3. I njëjti rezultat (rikthimi në gjendjen 3) mund të arrihet nëse zbatojmë të gjitha ndryshimet e regjistruara në TLogBackup 10 dhe 11 në rezervimin e plotë 5. Kjo do të duhet të bëhet nëse nuk kemi 6 dhe 7 për faktin se orari parashikohet vetëm për krijimin 5 dhe 8 (ose nëse 6 dhe 7 janë të dëmtuara). Por nëse ka 7, atëherë mënyra 5+7 është shumë më e shpejtë se mënyra 5+10+11.
• Nëse mungon vetëm 7, atëherë baza mund të rikthehet në gjendjen 3 duke përdorur metodën 5+6+11.
• Nëse orari është i tillë që 11 nuk u krijua, përmbajtja e 12 do të jetë: "U shtua: Toporkov, Ufimtsev, Yashin".
• Regjistri i transaksioneve, në pamje të parë, nuk tregohet në foto, por siç e mbani mend, rezervimi i TLog nuk është aspak një kopje rezervë, por një regjistër i transaksioneve për një periudhë të caktuar. Ju lutemi vini re se shfaqja e emrave të rinj në ditar i paraprin paraqitjes së tyre në bazën e të dhënave.
• Nëse regjistrat e transaksioneve nuk janë të rezervuara, përmbajtja e TLog në kohën 12 do të jetë "Shtuar:", e ndjekur nga një listë me mbiemrat 4 (d.m.th., të gjitha veprimet janë regjistruar). Nëse kopjet rezervë krijohen si në foto, atëherë përmbajtja e regjistrit të transaksioneve në kohën 4, si dhe në kohën 8, do të jetë si vijon: "Asnjë veprim nuk është ndërmarrë ende".

Rezervimi i bishtit të regjistrit të transaksioneve

Nëse nuk po flasim për sisteme me disponueshmëri të lartë, atëherë në rast të një dështimi, nevojitet një operacion më shumë manual, i cili nuk është më rutinë, por krijimi i rezervës së fundit TLog. Nëse kjo nuk është e mundur, d.m.th. regjistri është i korruptuar së bashku me bazën e të dhënave ose së bashku me serverin - rikuperimi është i mundur vetëm deri në rezervimin e fundit të TLog, dhe jo deri në sekondën e fundit. ato. qëllimi fillestar nuk do të arrihet.

Nga kjo rezulton se elementi kryesor i të gjithë sistemit rezervë është regjistri i transaksioneve. Duhet të jetë i vendosur në media të veçanta (jo të njëjta si media për vetë bazën e të dhënave) me besueshmëri shumë të lartë, shpejtësi të lartë aksesi dhe disponueshmëri të lartë, por në asnjë rast në dosje të ndryshme në të njëjtin disk logjik, as në disqe të ndryshëm logjik në i njëjti bartës fizik. Për më tepër, është e dëshirueshme që edhe nëse serveri SQL prishet, regjistri të mbetet i disponueshëm ose të paktën të jetë i disponueshëm në kohën minimale (ne nuk i konsiderojmë metodat për arritjen e tolerancës së gabimeve, ato janë temë e një artikulli të veçantë të një vëllim mbresëlënës).

Është një sistem kaq kompleks që do të sigurojë që ne të arrijmë qëllimet e vendosura në fillim dhe do të jemi të lirë nga problemet e zbuluara gjatë zhvillimit të tij.

Modeli i rikuperimit të plotë (funksionon vetëm me detyra të planifikuara dhe nën kontrollin e administratorëve)

Ne kemi përshkruar modelin e rikuperimit të plotë të bazës së të dhënave - Modeli i rikuperimit të plotë. Për raste të veçanta në MS SQL Server ekziston një model i thjeshtë rikuperimi (Simple recovery model) dhe një model me regjistrim jo të plotë (Bulk-logged). Modeli i rikuperimit të plotë parashikon ekzekutimin e rregullt të detyrave të mirëmbajtjes së bazës së të dhënave, si dhe kontrollin mbi rregullsinë dhe rezultatet e ekzekutimit të detyrave nga administratori. Kjo sugjeron ekzistencën e një pakete mjetesh komplekse të projektimit të Planit të Mirëmbajtjes që duhet mësuar.

Le të kalojmë në praktikë

Ndoshta vështirësia e parë që do të hasni është se nuk mund të krijoni një plan të ri mirëmbajtjeje.

Është e nevojshme të mundësohet ky funksionalitet duke ekzekutuar një skript SQL (New Query në shiritin e veglave, shkruani skriptin, Ekzekutoni në shiritin e veglave). Nëse skripti ekzekutohet me sukses, do të shihni mesazhet përkatëse në fund të dritares me skriptin.

Teksti i këtij skenari për të kopjuar/ngjitur:

Plani i mirëmbajtjes reale

Le të fillojmë duke treguar një plan të mirëmbajtjes reale që shërben bazat e të dhënave joproduktive në ciklin e zhvillimit, dhe më pas do të shqyrtojmë fragmentet individuale të planit të nevojshëm për leximin dhe kuptimin e tij. Katër ilustrimet e mëposhtme tregojnë planin e mirëmbajtjes "Plani Kryesor", i cili përbëhet nga katër nënplane që funksionojnë sipas planit të tyre.

Në Object Explorer, mund të shohim se ka dy plane mirëmbajtjeje të konfiguruara në SQL Server (Plani kryesor, Plani i Testimit). Plani kryesor përbëhet nga katër nënplane me orare të ndryshme (Shedul):

• Mirëmbajtja javore
• Rezervimi diferencial
• Rezervimi ZhT

Në fushën e hartimit të detyrave, ne shohim detyra. Procesi i hartimit të një plani konsiston në zvarritjen e detyrave nga paleta e Toolbox, vendosjen e opsioneve të detyrave dhe vizatimin e shigjetave midis detyrave. Detyrat mund të kenë një përshkrim arbitrar në zonën e projektimit, korrespondenca midis detyrës në plan dhe detyrës në paletë mund të vendoset me ikona. Për shembull, detyra "Gabim i integritetit" është detyra "Njoftoni detyrën e operatorit" në paleta (ikona "person").

A është një bllok diagram?

Gjëja e parë që mund të mendoni kur shikoni një skenar të detyrës së planit të mirëmbajtjes është se ai është një diagram, shigjetat tregojnë kalimet nga një detyrë në tjetrën dhe ju mund t'i kaloni ato me gishtin tregues, duke gjurmuar të gjithë skenarin nga fillimi në fund. Megjithatë, nuk është kështu. Ndodh që në shikim të parë është madje e vështirë të përcaktohet se ku fillon gjithçka dhe cila është sekuenca e detyrave. Një skrip përgjithësisht mund të fillojë në shumë vende dhe të përfundojë gjithashtu në shumë vende, sepse SQL Server tenton të ekzekutojë absolutisht të gjitha detyrat në të njëjtën kohë.

Konkurrenca dhe kufizimet

E vetmja gjë që e ndalon është prania e kufizimeve. Detyra nuk mund të fillohet derisa të "kryhet e vërtetë" hyrëse shigjetat në të (kufizime, kufizime). Ngjyra e shigjetës tregon llojin e përfundimit të detyrës me ndikim. Shigjeta jeshile hyrëse tregon për detyrën e varur kufizimin "ekzekuto vetëm nëse detyra ndikuese ka sukses", e zeza - "vrapo vetëm pas përfundimit të detyrës ndikuese (Përfundimi)", e kuqja - "ekzekuo vetëm në rast të një gabim në detyrën ndikuese (Dështim)".

Lloji i linjës (e ngurtë ose e ndërprerë) tregon operatorin logjik AND ose OSE për të llogaritur kufizimin përfundimtar nga shigjetat e shumta hyrëse. Ky operator ndryshohet në dialogun e redaktuesit të kufizimeve të përparësisë (klikoni dy herë në ndonjë nga shigjetat). Shigjetat e ngurta duhet të realizohen të gjitha, të paktën një nga ato me pika duhet të realizohet - atëherë detyra e varur do të nisë menjëherë. Ngjyra e çdo shigjete hyrëse mund të ndryshohet në mënyrë të pavarur (klikoni me të djathtën, Sukses/Dështim/Përfundim). Lloji i linjës mund të ndryshohet vetëm për të gjitha shigjetat hyrëse menjëherë (klikoni dy herë, dialogu i Redaktuesit të Kufizimit të Përparësisë). Së pari, të gjitha detyrat që nuk kanë kufizime fillojnë të ekzekutohen njëkohësisht. Sapo të përfundojë detyra e radhës, kontrollohen të gjitha detyrat që varen nga ajo dhe në të njëjtën kohë ato detyra për të cilat vlera përfundimtare e kufizimeve është bërë e mjaftueshme për të marrë një vendim për nisjen, nisen për ekzekutim.

Informacioni në paragrafin e mëparshëm është i mjaftueshëm për të kuptuar mekanizmin e përgjithshëm me anë të të cilit SQL Server kryen detyrat e planit të mirëmbajtjes. Le të shqyrtojmë tani pyetjet me rëndësi praktike.

Orari i çuditshëm

Koha e çuditshme e ekzekutimit të detyrës është për shkak të ndryshimit prej 4 orësh midis zonës kohore të serverëve dhe zonës kohore të zhvilluesve. Gama e orëve të mundshme të punës për zhvilluesit është nga 9:00 deri në 21:00, kështu që nënplani "Backup ZhT" ekzekutohet çdo orë nga ora 10:00 deri në 21:00, duke rregulluar ndryshimet çdo orë (nuk ka ndryshime në orën 9: 00 akoma). E përkthyer në zonën kohore të serverëve, kjo është nga ora 14:00 e pasdites deri në 01:00 të mëngjesit, e cila tregohet në orar.

Kur specifikoni orën, mund të hidheni mbi mesnatë, kjo funksionon si duhet. Duket pak e çuditshme. Planifikues të tjerë, për të shmangur vështirësitë me të kuptuarit e kohës së përfundimit në ditën tjetër, kërkojnë kohëzgjatjen e detyrës - "brenda X orësh".

Nëse një kopje rezervë e plotë pasohet menjëherë nga një kopje rezervë e VT-së, mund të jeni 100% i sigurt se plani është krijuar nga magjistari i planit të mirëmbajtjes (mos e përdorni kurrë, ai nuk krijon asgjë tjetër përveç mbeturinave) ose nga një administrator me aftësi të ulët që konsideron një të plotë kopje rezervë + Çifti rezervë TLog , i bërë në të njëjtën kohë, nga një grup i detyrueshëm rikuperimi. Por këto janë detyra të pavarura që funksionojnë në orare të ndryshme.

Por plani ynë është një përjashtim, pasi qëllimi ynë është të mbledhim informacione për suksesin e detyrave kryesore (integriteti, rezervimi i plotë, rezervimi VT) në një nënplan, dhe vetëm nëse ato janë të suksesshme, jepni komandën për të fshirë kopjet rezervë të vjetra.

Nëse fshirja e kopjeve rezervë të vjetra kryhet pa kushte, mund të rezultojë se nuk krijohen kopje rezervë të reja dhe të vjetrat fshihen plotësisht. Nëse fshirja e kopjeve rezervë të vjetra shpërndahet në nënplane të ndryshme, në varësi të llojit të rezervimit, rezulton pothuajse e njëjtë. Le të themi se një kopje rezervë e plotë ka ndaluar së funksionuari. Në të njëjtën kohë, fshirja e kopjeve të plota të vjetra nuk u krye më. Por nënplani i VT rezervë nuk di asgjë për këtë dhe vazhdon të fshijë kopjet rezervë të VT të vjetëruara. Pas ca kohësh, jo vetëm që do të kemi një rivendosje të vazhdueshme të drejtpërdrejtë, por edhe pika të rikuperimit në dritaren aktuale: kopjimi i fundit i plotë i bërë është bërë shumë kohë më parë, dhe rezervat e ruajtura të ZT në vitet e fundit janë absolutisht të padobishme, sepse. nuk ka asnjë rezervë të vetme të plotë brenda zinxhirit të tyre të vazhdueshëm.

Detyra e një rezervimi diferencial nuk është një detyrë kryesore për rikuperimin dhe nuk shfaqet në nënplan. Por do të ishte ende e mundur që të shtohej në këtë nënplan, duke e vendosur menjëherë pas rezervimit të plotë.

*

*Vini re ikonën fx në detyrë

Çdo detyrë ka veti, disa prej të cilave mund të shihen në dialogun e cilësimeve të detyrës (klikoni dy herë) dhe lista e plotë mund të shihet në dialogun e vetive (klikoni me të djathtën, Karakteristikat). Detyrat kanë gjithashtu veçorinë Expressions, e cila ju lejon të krijoni një tabelë të vetive dhe shprehjet e tyre përkatëse SQL për të llogaritur vlerat e vetive menjëherë. Përdorimi praktik i kësaj mundësie është si më poshtë. Me siguri ju keni parë të ashtuquajturat. "skedarët bat" në mënyrë që të fshini gjithçka përveç kopjeve rezervë për numrat e parë, ose anasjelltas, në mënyrë që të kopjoni kopjet rezervë për këta numra në një vend tjetër përpara se të fshini kopjet rezervë.

Detyra të tilla nuk kërkojnë mjete të jashtme dhe zgjidhen me mjete standarde MS SQL. Zgjerimi i skedarit rezervë të plotë për ditët e para mund të bëhet me MNT, dhe për ditët e tjera - me BAK. Kjo do të thotë që detyra e pastrimit mund të fshijë BAK më të vjetër se 1 muaj dhe të ruajë MNT për një kohë më të gjatë, duke i fshirë ato, për shembull, pas 1 viti.

Kur hapni dialogun e konfigurimit të detyrës për Rezervimin e plotë të bazës së të dhënave, do të shihni shtesën e skedarit BAK ose MNT në varësi të datës së sotme.

Sipas rekomandimeve të 1C, statistikat duhet të përditësohen çdo ditë, dhe cache procedurale duhet të pastrohet në frekuencën e përditësimeve të statistikave. Këto detyra janë mjaft intensive me burime, nga njëra anë, dhe nga ana tjetër, ato nuk janë themelore për bazat e informacionit të ekipit të zhvillimit. Në fund të fundit, bazat e të dhënave të tilla nuk përmbajnë shumë të dhëna dhe çështjet e performancës nuk janë akute. Prandaj, këto detyra ekzekutohen në nënplanin javor, ndërsa çaktivizohen në atë ditor (klikoni me të djathtën mbi detyrën, Disable). Jo thjesht i munguar, por i krijuar dhe i ndaluar.

Le të shqyrtojmë një pyetje të natyrshme: a do të funksionojë gjithçka siç duhet në problemin e ndaluar? Si do të reagojnë shigjetat e kuqe, të zeza dhe jeshile ndaj një ndalimi të tillë?

Kur shkruani plane komplekse të mirëmbajtjes, lind detyra e korrigjimit dhe nevojat praktike që dalin prej tij:

• Në fakt, mos kryeni një detyrë të gjatë, por konsiderojeni të përfunduar me kusht, duke mbajtur ndikimin e saj në formën e shigjetave në detyra të tjera;
• Modelimi i ekzekutimit të gabuar të detyrës.

Për të parën, MS SQL ka një mekanizëm për parandalimin e ekzekutimit aktual të detyrës: kliko me të djathtën mbi detyrën, Disable. Në këtë rast, detyra do të bëhet gri, në të vërtetë nuk do të ekzekutohet, por do të konsiderohet si e përfunduar dhe e përfunduar (shigjetat e zeza dhe jeshile do të funksionojnë). Nëse duam të simulojmë një ekzekutim të gabuar, atëherë në dritaren e karakteristikave të detyrës duhet të vendosim veçorinë e detyrës ForceExecutionResult në Failure. Mos e ngatërroni këtë veti me veçorinë ForcedExecutionValue në një seksion tjetër.

Zbatimi i kushteve ((A ose B) dhe C) për kufizimet e detyrave ose detyrat e rreme që nuk janë fare të rreme

Kufizimet mund të kombinohen ose me operatorin AND ose me operatorin OR. Kjo do të thotë që në ilustrimin e mëposhtëm, shigjetat e Plotësimit me pika nuk mund të tërhiqen drejtpërdrejt në detyrën "Njoftoni përfundimin me gabime". Zgjidhja është krijimi i një detyre të ndërmjetme "Ka pasur gabime" që grumbullon rezultatin e shigjetave të zeza me pika. Detyra është një skrip SQL nga një deklaratë e vetme go, domethënë, duket se nuk bën asgjë të dobishme.

Por në fakt, ai mbledh kufizimet hyrëse dhe shërben si burim kufizimesh për detyra të tjera, duke qenë kështu një pikë e rëndësishme kontrolli përmes së cilës kalon ekzekutimi i skriptit. Ky truk me një detyrë bedel mund të përdoret në situata të tjera. Për shembull, në skenarin tuaj, nuk ka nevojë të sillni bazat e të dhënave jashtë linje dhe më pas të ktheni gjendjen. Por detyra "Bazat e të dhënave jo të rezervuara në internet" nuk mund të fshihet ashtu nga nënplani, është një pikë e rëndësishme ekzekutimi, duke mbledhur kufizime hyrëse dhe duke shërbyer si burim i atyre dalëse. Në këtë rast, ju duhet ta zëvendësoni këtë detyrë me një skenar të rremë.

Ekzekutimi asinkron

Në konstruksionin në ilustrimin e mësipërm, mund të ndodhë një "paradoks kuantik", kur efekti është përpara shkakut. Në të vërtetë, nëse një nga detyrat ndikuese, për shembull, "Gabimi i integritetit" dha një sinjal për të nisur detyrën e varur, nuk ka kuptim të presësh rezultatin nga pjesa tjetër e detyrave ndikuese, kjo ende nuk ndikon në faktin që duhet të ekzekutohet detyra e varur "Ka pasur gabime". Prandaj, ai do të ekzekutohet menjëherë. Pas ca kohësh, mund të ndodhë që detyra "Gabim rezervë ZT" të funksionojë dhe të përfundojë. Mund të kishte shkaktuar "Ka pasur gabime", por kjo ngjarje ka ndodhur tashmë më parë. Kjo është nga projektimi në nënplanin tonë, por këto lloj efektesh asinkrone duhet të mbahen parasysh për të shmangur rezultate të papritura. Për shembull, kur matni kohën totale të ekzekutimit të një nënplani të mirëmbajtjes duke përdorur detyrën Alert Operator në fillim dhe në fund.

Cfare eshte?

Kjo është detyra e parë dhe një nga detyrat e fundit për t'u ekzekutuar që janë skriptet SQL. Fakti është se në lakin e zhvillimit shpesh ka kopje të sistemeve historike të një vëllimi shumë të madh. Ato synojnë t'ju njohin me mirëmbajtjen e të dhënave historike, të shërbejnë si burim të dhënash në operacionet e migrimit. Të dhënat në to praktikisht nuk ndryshojnë. Origjinalet e bazave të të dhënave janë në qarkun aktual prodhues të klientit, kopjet e këtyre sistemeve mund të merren gjithmonë sipas kërkesës. Mbështetja e kësaj sasie gjigante informacioni është humbje e burimeve. Në parametrat e detyrave që krijojnë kopje rezervë, është praktikë e mirë të specifikoni parametrin "Të gjitha" në detyrat rezervë në vend që të listoni bazat e të dhënave specifike (kjo shmang gabimin tipik "baza e të dhënave u krijua, por ata harruan ta përfshinin atë në kopje rezervë listë"). Dhe nëse po, nevojitet një mekanizëm për një lloj përjashtimi të disa bazave të veçanta nga grupi Të gjitha. Kjo është pikërisht ajo që bën skripti i parë - i vendos bazat e të dhënave të tilla në gjendjen OFFLINE. Skenari i dytë bën të kundërtën. Në këtë rast, parametri "Injoro bazat e të dhënave në gjendje OFFLINE" vendoset në parametrat e detyrave rezervë ose riindeksimi, përndryshe do të ndodhë një gabim i detyrës.

Paralele ose seri

Në nënplanin "Rezervimi i plotë ditor", detyra "Bazat e të dhënave jo të rezervuara jashtë linje" është e para që kryhet, sepse kjo është e vetmja detyrë që nuk ka kufij. Poshtë saj shohim rreshtimin pasardhës kryerja e detyrave që janë thelbi kryesor i nënplanit të rezervimit të plotë ditor.

Si arsye për ekzekutimin e njëpasnjëshëm, le të themi, dëshira për të mos tejkaluar ngarkesën e serverit SQL gjatë mirëmbajtjes dhe dukshmëria e planit. Zakonisht, për shkak të dritares së madhe të natës me një ndërprerje në punën e përdoruesve, ekzekutimi vijues nuk bëhet problem. Por mund të ketë situata kur shumë përdorues nga zona të ndryshme kohore punojnë me bazën e të dhënave dhe dritarja e mirëmbajtjes bëhet shumë e vogël. Nëse ekzekutimi vijues i detyrave nuk përshtatet në dritaren e mirëmbajtjes, ato do të duhet të paralelizohen. Kjo mund të bëhet me shigjetat që vijnë nga "Bazat jo rezervë jashtë linje" ndaj secilit detyra kryesore, dhe më pas konvergimi në "Bazat jo rezervë në internet". Dy detyrat gri duhet të zhvillohen në mënyrë sekuenciale në lidhje me njëra-tjetrën. Rezultati i paralelizimit është paraqitur më poshtë. Qëllimet e vendosura arrihen, por dukshmëria humbet ndjeshëm:

Këtu është opsioni i dytë, topologjikisht i barabartë me skemën e mëparshme, por më vizual për shkak të rregullimit të ndryshuar të detyrave + heqjes së detyrave gri.

Paralelizmi brenda detyrave standarde të bazës së të dhënave rezervë dhe kontrollit të integritetit të bazës së të dhënave dhe interpretimi i rezultatit të ekzekutimit të tyre

Detyrat "Krijo një kopje rezervë" dhe "Kontrollo integritetin e bazës së të dhënave" në përgjithësi funksionojnë me një listë të bazave të të dhënave. A do të punojnë në mënyrë sekuenciale me secilën bazë të dhënash, apo do të ketë shumë detyra paralele të mirëmbajtjes për secilën bazë të dhënash? Le të klikojmë dy herë mbi detyrën, në dialogun që hapet, shtypim butonin "Shiko T-SQL". Mund të shohim se në skriptin që gjenerohet dhe ekzekutohet nga SQL Server, instruksionet rezervë të BACKUP DATABASE janë të ndara nga instruksionet GO, që do të thotë se këto procese rezervë do të funksionojnë paralelisht. Rezultati nuk i referohet paketave, por punës në tërësi. Nëse ndodh një gabim në një detyrë me të paktën një bazë të dhënash, detyra në përgjithësi do të konsiderohet e përfunduar gabimisht; nëse nuk ka gabime, detyra do të konsiderohet e përfunduar me sukses në përgjithësi.

Planifikimi i detyrave të mirëmbajtjes (një çështje kyçe, që shpesh konsiderohet dytësore)

Le të përmbledhim detyrat kryesore të një plani të mirëmbajtjes së bazës së të dhënave të modelit të rikuperimit të plotë:

1. Detyrë e plotë rezervë
2. Detyra e ndryshimit të rezervimit
3. Detyrë rezervë Tlog

Në artikujt e njohur mbi temën e kopjimit të SQL, çështja e planifikimit të detyrave më së shpeshti nuk merret parasysh në mënyrë specifike ose i caktohet një rol dytësor. Në të njëjtën kohë, periodiciteti i propozuar i detyrave nuk është i argumentuar qartë. Ndërkohë, kjo çështje është kyçe. Nuk ka rekomandime të qarta. Frekuenca dhe përbërja e detyrave mund të ndryshojnë në rrethana të ndryshme. Konsideroni parimet e përgjithshme.

Gjëja kryesore për të filluar është dritarja e pranueshme e humbjes së të dhënave (Objektivi i pikës së rikuperimit, RPO) + koha e rikuperimit (Objektivi i kohës së rikuperimit, RTO). Këta tregues, nga ana tjetër, përcaktojnë arkitekturën e harduerit, teknologjitë e përdorura dhe shpeshtësinë e ekzekutimit të detyrave.

Frekuenca e kopjimit të TLog

Frekuenca e rezervimit të TLog varet nga vlera e RPO. Frekuenca tipike e detyrës rezervë TLog për bazat e të dhënave produktive është nga ½ në 1 kohë RPO për të gjithë intervalin kohor ditor për të bërë ndryshime në bazën e të dhënave (përfshirë intervalet kohore gjatë të cilave ndryshimet bëhen nga detyrat e planifikuara dhe përpunimi një herë gjatë çaktivizimit -orë). Është tipike që bazat e të dhënave produktive të bëjnë ndryshime brenda 24 orëve. Nëse për një bazë të dhënash të tillë RPO=1 orë, atëherë kopjimi i regjistrave të transaksioneve duhet të kryhet rreth orës çdo 30-60 minuta. Por ka raste kur, për shkak të specifikave të sistemit, është e mundur të kufizohet vetëm në intervalin e orarit të punës, për shembull, nga 10 në 18, nga e hëna në të premte, si dhe pak a shumë frekuencë.

Për bazat e të dhënave jo produktive (në një mjedis zhvillimi), mund të jetë më e përshtatshme të përdoret një model i thjeshtë rikuperimi, ku kjo detyrë mungon plotësisht. Pavarësisht se në literaturë dhe dokumentacion të shumtë zyrtar deklarohet se përdorimi i një modeli të thjeshtuar nuk jep një fitim të performancës (sepse TLog ruhet ende), në praktikë nuk është kështu. Koha e ekzekutimit të operacionit të kryer shpesh për vendosjen e objekteve të konfigurimit të ndryshuar 1C në ruajtje kur përdorni një model të thjeshtuar rikuperimi zvogëlohet disa herë, dhe fitimi total në kohë rrit në mënyrë dramatike shpejtësinë e zhvillimit. Në të njëjtën kohë, me një frekuencë prej ½ deri në 1 kohë RPO, është e nevojshme të krijoni një kopje rezervë të Diff. E njëjta metodë mund të përdoret për sisteme produktive back office me norma të ulëta ndryshimi, ku ekziston mundësia e rifutjes së të dhënave që ishin në dritaren RPO dhe të humbura për shkak të një përplasjeje.

Periodiciteti i ndërlidhur i rezervimit të plotë dhe kopjimit të Diff

Frekuenca e të dy detyrave në përgjithësi zgjidhet në atë mënyrë që RTO të mund të përmbushet. Nëse intensiteti i ndryshimeve është i tillë që ju lejon të bëni kopje rezervë të plotë një herë në muaj, kopje rezervë diferenciale një herë në ditë dhe në të njëjtën kohë, në datën 29, restaurimi ndodh brenda RTO - pse jo. Nëse intensiteti i ndryshimeve është i tillë që me një periodicitet të tillë detyrash, koha e rikuperimit bëhet e papranueshme, mund t'ju duhet një kopje e plotë në fillim të ditës dhe disa kopje rezervë diferenciale gjatë ditës.

Frekuenca e detyrës së rezervimit të Diff varet gjithashtu nga vëllimi i rezervimit të Diff në krahasim me rezervimin e plotë. Nëse, me frekuencën e zgjedhur të kopjimit Diff, madhësia e tij fillon të kalojë gjysmën e madhësisë së kopjes rezervë të plotë, krijimi i mëtejshëm i rezervimit të Diff bëhet i papërshtatshëm, në këtë pikë ju duhet të krijoni një kopje rezervë të plotë. Sidoqoftë, ia vlen të kujtojmë se ky raport duhet të injorohet në bazat e të dhënave relativisht të reja - me kalimin e kohës, vëllimi i ndryshimeve ditore do të jetë një pjesë e vogël (d.m.th., e lejueshme për rezervimin e Diff) të vëllimit total të të dhënave dhe 95% të vëllimit do të pushtohen nga të dhënat historike.

Ndjekja e këshillave që mund të lexoni në internet për konfigurimin e kopjeve rezervë SQL mund të jetë një burim telash për të dhënat tuaja. Le të zbatojmë njohuritë nga ky artikull në këshillat e dhëna nga disa ekspertë:

Për bazat e të dhënave të përditësuara shpesh, sugjerohet të bëni kopje rezervë të plotë të dielave dhe kopjimi TLog një herë në ditë. Dritarja e humbjes së të dhënave (RPO)=1 ditë është e papranueshme e gjatë. Në të njëjtën kohë, eksperti është i bindur se kjo është mënyra më e mirë për të parandaluar çdo humbje të të dhënave. Koha e rikuperimit të shtunën do të jetë gjithashtu e papranueshme e gjatë, sepse do të jetë e nevojshme të aplikohen ndryshime në rezervimin e plotë për 6 ditë, dhe intensiteti i ndryshimeve në bazën e të dhënave është i lartë.

Këtu, çdo ditë nga e hëna në të premte, bëhet një kopje rezervë e VT dhe Shrink e VT (Teksti "kopje e bazës së të dhënave" në kolonën "Përshkrimi" është një gabim i dukshëm shtypi, sepse operacioni tregohet qartë në "veprimet" kolona - kopje rezervë e VT). Nëse ktheheni te nënplani ynë i mirëmbajtjes javore, do të shihni se detyra e shkurtimit të VT është emërtuar me vend "Shrink Don't" dhe është një detyrë e ndaluar (e grirë). Pyetja e kërkimit "shrink duhet të bëhet" do të ndihmojë në sqarimin e informacionit.

Ne zbresim një rresht dhe shohim që pas çdo rezervimi të Diff, rezervimi TLog fshihet - ky është një refuzim vullnetar i rikuperimit të vazhdueshëm të drejtpërdrejtë (qëllimi kryesor i të gjithë sistemit rezervë) dhe kalimi në pikat e rivendosjes. Pikat ndahen nga njëra-tjetra me një ditë. Kjo do të thotë që dritarja e humbjes së të dhënave është 24 orë (RPO=24 orë).

Ne zbresim në rreshtin e fundit dhe gjejmë gabimin më të madh të të gjithë planit. Nëse ka ndodhur prishje aksidentale ose me qëllim të keq, atëherë të dhënat ruhen në mënyrë shumë të sigurt, por janë të padobishme. Le të imagjinojmë një rast kur një programues del të shtunën për t'u marrë me problemin "raportet japin absurditet të plotë". Në orën 18:05, ai kupton se problemi është për faktin se të dhënat e regjistrave kryesorë janë deformuar (fshirë) plotësisht, dhe regjistrat thonë se kjo ka ndodhur pasditen e së premtes. Në këtë moment në kohë, ai ka një bazë të dhënash në të cilën të dhënat janë të pasakta, dhe një kopje rezervë të vetme të plotë të bërë 5 minuta më parë, të dhënat në të cilat janë gjithashtu të pasakta. Çdo gjë tjetër është hequr plotësisht, sepse. Një kopje rezervë e plotë është krijuar me sukses. Ky plan mirëmbajtjeje është kampion në numrin e gabimeve të bëra.

Ilustrimi i mësipërm është një plan i nivelit fillestar i krijuar nga një fillestar duke përdorur Magjistarin e Planit të Mirëmbajtjes dhe nuk zgjidh asnjë problem. Ka një gabim të zakonshëm: nuk mund ta bëni detyrën e krijimit të një kopje rezervë të plotë të varet nga rezultatet e një kontrolli të integritetit. Kur një bazë të dhënash rrëzohet, është më mirë të keni një kopje rezervë me dy lidhje të prishura në bazën e të dhënave sesa asgjë. Krahasoni me atë që është bërë në nënplanin "Rezervimi ditor" - shkelja e integritetit informon operatorin, por nuk pengon krijimin e kopjeve rezervë.

Karakteristikat e rikuperimit - si të mos humbni të dhënat

Duket se mund të jetë më e thjeshtë: thjesht kthejeni bazën e të dhënave disa kohë më parë nga rezervimi i saj. Dhe është pak më e vështirë të vendosësh një kopje rezervë të një baze të dhënash tjetër në bazën e të dhënave. Por në këtë operacion të thjeshtë na presin rreziqe të mëdha, si rezultat i të cilave mund të humbni lehtësisht të dhënat tuaja. Për më tepër, duhet të themi sinqerisht se ka kaq shumë absurditete në dialogun e rimëkëmbjes sa që me siguri do t'i duket një specialisti fillestar se ai nuk kupton diçka dhe po bën diçka të gabuar, edhe nëse po bën gjithçka siç duhet.

Meqenëse këto “veçori” nuk janë përshkruar askund, le ta plotësojmë këtë boshllëk. Le të shqyrtojmë një detyrë tipike të rivendosjes së bazës së prodhimit për disa kohë (burimi, ZUP3ENERGO në ilustrime) në bazën e të dhënave individuale të programuesit (marrësi, ZUP_SUV në ilustrime) për të hetuar incidentin. Duke përshkruar "veçoritë" e ndryshme të sjelljes së versioneve të ndryshme të SQL Server, me termin "versione të reja" nënkuptojmë lëshimin 13.0.4457.0, dhe me termin "versione të vjetra" - version 11.0.3156.0.

Veprimi i parë- kliko me të djathtën në bazën e të dhënave të destinacionit, Tasks, Restore, DataBase. Dhe menjëherë në dialogun Restore Database (ilustrimi më poshtë), ne shohim një shenjë rreziku të verdhë: do të bëhet një kopje rezervë e fragmentit përfundimtar të regjistrit të transaksioneve të bazës së të dhënave burimore. Sigurisht, në fakt, duhet të flasim për bazën marrëse dhe logjika këtu duhet të jetë si vijon: para se të shkatërrojmë përmbajtjen aktuale duke rivendosur, le të rregullojmë përfundimisht atë që kemi tani, për çdo rast. Kjo do t'ju lejojë të riktheni rikthimin aktual, duke kryer më pas një rivendosje tjetër në pikën përpara rivendosjes. Operacioni, me sa duket, është i dobishëm dhe nuk ka asgjë të rrezikshme nëse do të ishte vërtet një marrës. Por ky nuk është vetëm një gabim në mesazh, një kopje rezervë e regjistrit të bishtit kryhet gabimisht në burim. Kjo mund të testohet eksperimentalisht duke klikuar butonin Script dhe duke parë kodin.

Prandaj, në hapin e pestë, ky operacion duhet të anulohet (shih më poshtë). Rregullimi i ndryshimeve më të fundit në marrës (të cilat mund të kenë ndodhur që nga krijimi i rezervës së fundit VT) duhet të bëhet me dorë (për shembull, me nisje të paplanifikuar të detyrës përkatëse).

Tani le të shohim se çfarë në të vërtetë mund të shërbejë si burim. Dialogu tregon se burimi mund të jetë Baza e të Dhënave dhe Pajisja. A duhet të shpjegoj se vetë baza e të dhënave nuk mund të shërbejë si burim të dhënash për një moment arbitrar në të kaluarën. Burimi mund të jetë kopje rezervë e bazës së të dhënave. Prandaj, kërkohet një shpjegim i opsioneve.

• Baza e të dhënave burimore - i gjithë grupi i skedarëve që përmbajnë kopje rezervë të bazës së të dhënave burimore dhe regjistrave të saj sipas regjistrit rezervë, e cila mbahet në tabelat e sistemit të serverit SQL. "Sipas regjistrit rezervë" është një frazë jashtëzakonisht e rëndësishme për të kuptuar mekanizmin e funksionimit. Do të thotë që edhe nëse një skedar mungon aktualisht nga disku, ai mund të merret parasysh në planin e rikuperimit (sepse është i fiksuar në regjistër) dhe të shfaqet në listën e grupeve rezervë për të rivendosur. Gabimi do të ndodhë vetëm në fazën e rikuperimit, dhe nëse është një skedar rezervë Diff ose TLog - baza do të mbetet në gjendje të papërdorshme. Për të parandaluar që kjo të ndodhë, së pari kontrolloni mundësinë e rikthimit me butonin "Verifiko media rezervë".
• Burimi i pajisjes është një grup arbitrar skedarësh. Fakti është se historia e kopjeve rezervë mund të pastrohet. Ose kopjet rezervë janë krijuar në një server tjetër SQL dhe për këtë arsye nuk janë të regjistruara në regjistrin rezervë në këtë server. Prandaj, është e mundur që në mënyrë eksplicite të specifikohet një grup arbitrar skedarësh. Ju mund të specifikoni një grup skedarësh që janë të tepërt për rikuperim (për shembull, për shumë ditë - serveri SQL në hapin tjetër do të zgjedhë vetëm ato të nevojshme).

Akti i dytë- zgjidhni burimin, i cili në rastin tonë është i ndryshëm nga marrësi. Versionet më të reja të MS SQL Server reagojnë ndaj kësaj normalisht. Versionet e vjetra kanë efekte të këqija që duhet të monitorohen me kujdes për të shmangur humbjen e të dhënave:

• Efekti 1. MS SQL e ndryshon menjëherë Destinacionin në bazën e të dhënave të specifikuar në Source. Prandaj, Destinacioni duhet të kthehet mbrapsht. Nëse nuk e vëreni këtë, baza e të dhënave do të mbishkruhet në heshtje dhe madje edhe flamuri i pazgjedhur "Mbishkruani bazën e të dhënave ekzistuese" në skedën "Opsionet" nuk do të jetë në gjendje ta mbrojë atë;
• Efekti 2. Kalo te skeda Files dhe shiko - në vend të marrësit, MS SQL Server dëshiron të mbishkruajë burimin (shih ilustrimin e mëposhtëm). Është e nevojshme të futni manualisht emrat e skedarëve të bazës marrëse dhe regjistrin e saj, përndryshe burimi do të humbasë (shih hapin e katërt më poshtë).

Veprimi i tretë. Pasi të keni zgjedhur një grup skedarësh si burim, duhet të specifikoni pikën në kohë (Rivendosja në, butoni i "Kronologjisë". Përcaktimi i pikës në kohë ju lejon të zgjidhni një grup specifik (Backup sets to restore) nga grupi origjinal i skedarëve të përcaktuar nga burimi (Burimi), i cili është i nevojshëm për rikthimin në një kohë të caktuar. Një absurditet tjetër që është i pranishëm edhe në versionet e fundit të MS SQL bëhet i dukshëm: opsioni "Restore to" dhe butoni TimeLine vizatohen në dialog në vendin e gabuar. Ata sigurisht i referohen burimit, jo destinacionit. Ky gabim nuk do të rregullohet kurrë, është mbi 10 vjeç, kështu që thjesht duhet të mësoheni me të. Gjithashtu, kini shumë kujdes kur futni manualisht kohën pa përdorur një vizore: edhe versionet më të fundit të SQL Server "hanë" hyrjen e parë të ditës së muajit, kështu që numri do të duhet të futet dy herë.

Veprimi i katërt.

Veprimi i pestë. Kalo te skeda Opsione. Vendosni opsionin për të mbishkruar bazën e të dhënave, zgjidhni opsionin për të krijuar fragmentin përfundimtar të VT, aktivizoni opsionin "mbyll lidhjet ekzistuese me bazën e të dhënave të synuar", nëse është i disponueshëm:

Akti i gjashtë. Pas restaurimit nga një "burim i huaj", baza e restauruar (ZUP_SUV) do të marrë një emër logjik të huaj (ZUP3ENERGO). Duhet të kthehet përsëri në dialogun e veçorive të bazës së të dhënave (klikoni me të djathtën në bazën e të dhënave, Karakteristikat). Nëse kjo nuk bëhet, atëherë do të ketë pasoja shumë të pakëndshme.

Fat i mirë për ju dhe të dhënat tuaja!

Rezervimi në 1C 8.3 dhe 8.2 është operacioni më i rëndësishëm që duhet të jetë në gjendje të bëjë çdo përdorues, programues, administrator. Specialistët e teknologjisë së informacionit gjithashtu shpesh e quajnë kopjim të tillë një kopje rezervë 1C. Konsideroni se çfarë është dhe udhëzime të hollësishme.

Njerëzit ndahen në dy kategori: ata që nuk bëjnë ende kopje rezervë dhe ata që tashmë e bëjnë.— Një shaka e administratorëve të sistemit.

Pse është e rëndësishme të bëni kopje rezervë? Gjithçka është shumë e thjeshtë, duhet të mbani mend ligjin e poshtërësisë: gjërat më të këqija ndodhin në kohën e gabuar.

Imagjinoni - ju keni përgatitur raporte përfundimtare për një muaj, duke korrigjuar gabimet, duke futur kilogramë të dokumentacionit parësor në program. Pastaj vendosëm të bëjmë një pushim, të derdhim pak çaj. Duke u kthyer në vendin e punës, zbuloni se pastruesi preku kordonin (pati një rritje të energjisë, kolegët e përmbytën makinën me kafe, etj.) të njësisë suaj të sistemit. Ju furishëm përpiqeni të ndizni kompjuterin tuaj, por ai nuk do të përgjigjet. Raportimi nesër çfarë të bëni?

Për të mos u futur në një situatë të tillë, rekomandohet fuqimisht të bëni kopje rezervë të paktën një herë në javë (ose më mirë një herë në ditë). Kjo nuk është e vështirë për t'u bërë, do të duhen maksimumi 10 minuta, por do ta lehtësojë shumë jetën në një situatë të vështirë.

Merrni mësime video 267 1C falas:

Udhëzime për kopje rezervë në 1C

Konsideroni një udhëzim të shkurtër për heqjen e një kopje rezervë të bazës së të dhënave në 1C. Udhëzimi është i përshtatshëm si për modalitetin e skedarit të bazës së të dhënave ashtu edhe për modalitetin klient-server.

Ngarkimi i një kopje të bazës së të dhënave në një skedar

Futni programin në modalitetin e konfiguruesit. Për ta bërë këtë, në dritaren e fillimit të programit, zgjidhni bazën e të dhënave të kërkuara dhe klikoni "Konfigurator":

Do të hyni në mënyrën e zhvillimit dhe administrimit të bazës së të dhënave. Tjetra, zgjidhni artikullin e menysë "Administrimi - Shkarkimi i bazës së informacionit ...":

Programi do t'ju kërkojë të zgjidhni shtegun ku do të ngarkoni skedarin e bazës së të dhënave dhe emrin e tij. Pas përzgjedhjes, programi do të raportojë përfundimin e suksesshëm të operacionit:

Është më mirë ta ruani skedarin në media të jashtme (për shembull, një flash drive, një hard disk i jashtëm).

Si të rivendosni bazën e të dhënave 1C 8.3 nga një kopje rezervë

Për të rivendosur bazën e të dhënave nga një skedar, duhet gjithashtu të futni modalitetin e konfiguruesit, por zgjidhni artikullin "Administrimi - Ngarkoni bazën e informacionit ...":

Ka disa mënyra për të krijuar kopje rezervë:

• Kopjimi i skedarëve të bazës së të dhënave;
• Ngarkimi i një skedari në një skedar .dt;
• Rezervimi duke përdorur mjetet e konfigurimit 1C 8.3.

Le të shqyrtojmë secilën nga mënyrat për të krijuar "kopje rezervë" të bazave të të dhënave 1C në më shumë detaje.

Kopje e thjeshtë e skedarit me zgjatje " *.1 CD" dhe nëse është e nevojshme - 1Cv8Log" nga drejtoria IB :

Regjistri i ngjarjeve ruan informacione për hyrjen dhe daljen e sesionit, ndryshimet e të dhënave, nisjen dhe ekzekutimin e detyrave në sfond dhe informacione të tjera, në varësi të cilësimeve:

Kjo metodë kopjimi ju lejon të kryeni kur seancat e përdoruesit janë duke ekzekutuar, por në kohën e kopjimit në IB NUK DUHET jini aktiv (krijoni, regjistroni, postoni dokumente), pasi mund të merrni një kopje të pasaktë.

Shkarkimi i bazës së të dhënave 1C në konfiguruesin, ku krijohet një skedar i ngjeshur me shtrirjen dt. Nëse është e nevojshme, ju gjithashtu mund të arkivoni regjistrin e regjistrimit veçmas.

Shkarkimi i bazës së informacionit

Ne fillojmë IB në modalitetin Konfiguruesi:

Ne fillojmë magjistarin e shkarkimit IB:

Ne shkarkojmë IB, ku tregojmë vendndodhjen e rezervës:

Pas përfundimit, një mesazh do të shfaqet në përfundimin e shkarkimit të IB:

Pas krijimit të një kopjeje, duhet të kontrolloni (testoni) performancën dt skedar - duke ngarkuar IB, së pari krijoni IB për testim.

Si të rivendosni një bazë të dhënash nga një kopje rezervë 1C 8.3

Ne fillojmë IB në modalitetin konfigurues.

Ne hapim magjistarin e shkarkimit IB, ku specifikojmë vendndodhjen *.dt dosje:

Pas rivendosjes së kopjes rezervë 1C, do të shfaqet një paralajmërim për ngarkimin e suksesshëm të IB dhe një kërkesë për të rifilluar Konfiguruesi:

Kur krijoni këtë metodë rezervë, kërkohet që të gjithë përdoruesit e kësaj IB të përfundojnë sesionin e tyre.

Për më shumë detaje se si të rivendosni të dhënat nga një kopje rezervë e krijuar më parë, duke përfshirë mënyrën e rivendosjes së të dhënave në një bazë informacioni ekzistues ose një bazë informacioni të krijuar rishtazi, shihni videon tonë:

Krijimi dhe konfigurimi i një arkivi 1C duke përdorur mjete konfigurimi

Rezervimi automatik , i cili është konfiguruar në modalitetin e përdoruesit 1C:Enterprise. Kjo mënyrë është krijuar nga zhvilluesit në konfigurimet në platformën 1C: Enterprise 8.3 (Enterprise Accounting, rev. 8.3, Payroll and HR, rev. 8.3, Trade Management, rev. 11.2):

Këtu mund të:

• Ekzekutoni një kopje rezervë një herë:

• Krijo orar:

• Rivendosja nga një kopje rezervë:

Këshillë:

• Mbani kopje rezervë në media të tjera fizike ose të jashtme, si nëse hard drive dështon, ju mund të humbni vetë IB dhe kopjet e tij.
• Bëni kopje rezervë të rregullt. Për të vendosur se sa shpesh duhet të bëni kopje rezervë, duhet t'i përgjigjeni pyetjes: "Si e vlerësoni punën tuaj dhe punën e kolegëve tuaj". Sa më shpesh të krijoni kopje rezervë, aq më pak përpjekje duhet për të rifutur dokumente. Por, sigurohuni që të krijoni kopje rezervë përpara se të përditësoni konfigurimin.

Nëse keni ende pyetje, mund të shikoni videon tonë, e cila përshkruan më në detaje se si të krijoni një kopje arkivore të një infobaze duke përdorur vetë platformën e teknologjisë në modalitetin Konfigurator:

Vlerësoni këtë artikull:

Për t'u mbrojtur nga humbja e pjesshme ose e plotë e të dhënave, përpara se të kryeni ndonjë veprim me bazën tuaj të informacionit, bëhet e nevojshme të bëni kopje rezervë të të dhënave në 1C. Duke përdorur një kopje rezervë, mund ta ktheni bazën e të dhënave në gjendjen në të cilën ishte në kohën e kopjimit.

Krijimi i një kopje rezervë 1C me dorë

Ne fillojmë 1C dhe zgjedhim modalitetin e konfiguruesit për bazën tuaj të informacionit:

Pasi të keni hyrë në konfigurues, shkoni te menyja Administrata dhe zgjidhni artikullin "Ngarko infobazën"

Shfaqet një dritare në të cilën duhet të specifikoni dosjen për ruajtjen e kopjeve rezervë (në rastin tim quhet kopje arkivore 1C, mund ta emërtoni si të doni), emrin e skedarit rezervë (në rastin tim BP20082012, dy shkronjat e para janë përcaktimi i emrit të infobazës, pastaj data e ruajtjes, d.m.th. 20 gusht 2012) dhe klikoni butonin ruaj.

Ne jemi duke pritur që programi të ruajë skedarin. Ekzekutimi i këtij operacioni mund të vërehet në këndin e poshtëm të majtë të dritares së konfiguruesit:

Pas përfundimit, programi do të shfaqë mesazhin e mëposhtëm:

Rezervimi është krijuar.

Si të rivendosni një bazë të dhënash nga një kopje rezervë përshkruhet në.

Vendosja e rezervimit automatik në 1C sipas një plani

Ky udhëzues do t'ju ndihmojë të konfiguroni kopje rezervë automatike. Është i përshtatshëm vetëm për mënyrën e funksionimit të skedarit në bazën e të dhënave 1C. Për të konfiguruar në modalitetin klient-server, 1C rekomandon të bëni kopje rezervë duke përdorur mjete DBMS - MS SQL, Postgre, etj.

Për të konfiguruar, shkoni te skeda "Administrimi", artikulli "Mbështetje dhe mirëmbajtje":

Ju mund të ruani kopje të bazave të të dhënave në kompjuterin tuaj ose në një hard disk të jashtëm, dhe është gjithashtu e mundur të përdorni shërbimin 1C Cloud Archive.

Funksioni i fillimit manual të kopjimit dhe rivendosjes është gjithashtu i disponueshëm këtu, por ne jemi të interesuar për artikullin "Cilësimet e rezervimit":

Opsionet e mundshme të konfigurimit janë planifikuar dhe në fund të punës me programin. Më e mira nga të gjitha, veçanërisht nëse punoni në bazë më shumë se një, zgjidhni opsionin "Planifikuar rregullisht". Vendosja e tij është shumë e lehtë. Në pamjen e ekranit, unë kam vendosur një rutinë të përditshme:

Përveç këtyre cilësimeve, duhet të specifikoni gjithashtu drejtorinë për ruajtjen e kopjeve (është më mirë të përdorni Google Drive ose Yandex Disk) dhe sa kopje rezervë për të ruajtur:

Në këtë udhëzim, ne do të shikojmë se si është konfiguruar rezervimi i bazës së skedarit 1C, cilat opsione rezervë ekzistojnë dhe si të kontrolloni kopjen rezervë të krijuar.

Ky udhëzim është i rëndësishëm vetëm për bazat e të dhënave të skedarëve. Nëse keni një bazë të dhënash klient-server, rezervimi i saj duhet të konfigurohet ose duke përdorur DBMS () ose duke përdorur programe të palëve të treta.

Si shembull, le të marrim një konfigurim tipik "Edicioni i Kontabilitetit të Ndërmarrjeve 3.0"

Vendosja e kopjes rezervë të bazës së të dhënave të skedarit 1C

Shkoni te menyja "Administrimi" - "Mirëmbajtja":

Zgjero seksionin "Backup and Restore".

Këtu jemi të interesuar në fushën "Metoda rezervë".

Ka 2 opsione: dhe "1C: Arkivi i resë".

Le të shqyrtojmë secilën nga opsionet.

1C: Arkivi i resë

Nëse keni një abonim ITS:Prof dhe nuk do ta refuzoni, atëherë ju rekomandoj ta përdorni "1C: Arkivi i resë", sepse ky shërbim është falas për ju. Një tjetër plus i ruajtjes së resë kompjuterike është se ju mund të rivendosni bazën e të dhënave kur kompjuteri shkatërrohet fizikisht ose nëse hard disku juaj prishet. Nëse nuk keni një ITS, atëherë vazhdoni në seksionin tjetër.

Zgjidhni "1C: shërbimi cloud" dhe klikoni "Lidhu":

Në formularin që hapet, shkruani emrin e përdoruesit dhe fjalëkalimin nga ITS dhe klikoni "Connect":

Një letër do të gjenerohet për mbështetjen teknike dhe do t'ju ndihmojë të regjistroheni.

Nëse nuk ka abonim ITS:Prof, atëherë cloud do t'ju kushtojë pothuajse 1000 rubla / muaj. Tani do të analizojmë se si të bëjmë të njëjtën gjë, por falas.

Zgjidhni opsionin "Në kompjuterin lokal" dhe klikoni "Cilësimet e rezervimit":

Kontrolloni kutinë "Kryeni kopje rezervë automatike"

Specifikoni drejtorinë për të ruajtur kopjet rezervë. Është më mirë që të jetë një hard disk i veçantë. Nëse nuk ka hard disk të veçantë, atëherë specifikoni drejtorinë në ndarjen e diskut ku Windows NUK është i instaluar. ato. ndonjë tjetër përveç makinës "C":

Drejtori për ruajtjen e kopjeve rezervë

"Mbani kopje rezervë"- specifikoni "10 pjesët e fundit", zakonisht kjo është e mjaftueshme, plus nuk do të zërë shumë hapësirë ​​në hard disk:

Mbani vetëm 10 kopjet e fundit

Tani duhet të vendosim se si do të kryhet kopjimi: "Programi i rregullt" ose .

Kur zgjidhni, duhet të kihet parasysh se në të dyja rastet, të gjithë përdoruesit e bazës 1C do të "dëbohen" për të bërë një kopje rezervë.

Opsioni "Planifikuar rregullisht"

Ky opsion mund të zgjidhet nëse të gjithë përdoruesit largohen në të njëjtën kohë, për shembull, për drekë ose çaj.

Pastaj klikoni në “Një ditë; një herë në ditë" dhe zgjidhni një orar. Për shembull, 15 minuta pasi të gjithë u nisën për drekë (në rast se dikush vonohet)

Në menynë që hapet, vendosni "1" në fushën "Përsëriteni çdo" për të marrë "Çdo ditë; njehere ne dite":

Shkoni te skeda "Ditore" dhe specifikoni në fushën "Ora e fillimit" kohën kur dëshironi të bëni një kopje rezervë. Pastaj klikoni "OK":

Rezultati duhet të duket si ky:

Ju lutemi vini re se sesioni juaj 1s duhet të funksionojë në këtë kohë, d.m.th. duke u nisur për drekë, ju duhet të lini 1s të aktivizuara në mënyrë që të krijohet një kopje

Opsioni "Në mbyllje"

Ky opsion është i përshtatshëm për ju nëse jeni i fundit që largoheni nga zyra (ose të paktën i fundit që largoheni nga 1C).

Në këtë opsion, nuk keni nevojë të konfiguroni asgjë shtesë. Vetëm kur mbyllni 1C, sistemi do t'ju ofrojë të bëni një kopje rezervë.

Si funksionon një kopje rezervë e mbylljes?

Kur dilni nga 1C, do të shfaqet dritarja "Backup nuk u krye në mbyllje":

Rezervimi dështoi gjatë mbylljes

Nëse klikoni "Shut down", atëherë 1C do të mbyllet pa një kopje rezervë.

Kur klikoni "Vazhdo" në këndin e poshtëm të djathtë të 1C, do të shfaqet dritarja e mëposhtme:

Një dritare që ju kërkon të bëni një kopje rezervë

Klikoni mbi të për të shfaqur këtë dritare:

Drejtoni një kopje rezervë

Mbetet vetëm të klikoni "Finish" pa hequr zgjedhjen "Kryej kopje rezervë". Pas kësaj, 1C do të bëjë një kopje rezervë dhe do të përfundojë punën:

Krijimi i një kopje rezervë të bazës së informacionit

Pra, është bërë gjëja më e rëndësishme, po krijohen kopje rezervë, mbetet të ngarkohen automatikisht kopjet në cloud për të mbrojtur të dhënat nga forca madhore.

Ngarkimi i kopjeve rezervë 1C në cloud

Shkarkoni çdo aplikacion të shërbimit cloud në kompjuterin tuaj. Zakonisht ata zgjedhin midis Cloud mail.ru dhe Yandex.Disk. Nëse kopjet rezervë "peshojnë" më pak se 2 GB, atëherë mund të zgjidhni ndonjë, nëse kopjet rezervë peshojnë më shumë se 2 GB, atëherë patjetër që duhet të merrni Yandex.Disk. Nëse preferoni ndonjë shërbim tjetër cloud - përdorni atë. Gjëja kryesore është që ky shërbim pranon skedarë të madhësisë së duhur.

//help.mail.ru/cloud_web/confines

Kufizimet në skedarët e ngarkuar:

Gati! Konfigurimi i rezervimit të bazës së skedarit 1C tani ka përfunduar.

Po kontrollon kopjet rezervë të krijuar 1C

Shkoni te dosja me bazën e të dhënave dhe fshini skedarin "1Cv8.1CD"

Hapni arkivin e fundit të krijuar me një kopje të bazës së të dhënave dhe nxirrni skedarin që gjendet atje në dosjen me bazën e re të të dhënave:

Ekstraktimi i skedarit të bazës së të dhënave

Shkoni te baza e re e të dhënave dhe kontrolloni nëse të dhënat e nevojshme janë atje (për shembull, Implementimet e freskëta). Nëse baza e të dhënave ka filluar dhe të dhënat janë në vend, atëherë gjithçka është në rregull.