Zálohování se nezdařilo 1 s. Vzájemná periodicita plné zálohy a rozdílové zálohy

Uživatelé 1C jsou tradičně rozděleni do dvou kategorií: ti, kteří vytvářejí záložní kopie *, a ti, kteří je začínají dělat. Abychom se nepoučili z vlastních chyb, začněme zálohovat právě teď.

*Pokud již zálohujete, bude pro vás tento článek stále užitečný, protože mnoho z toho, co můžete najít a přečíst o zálohování na internetu, je chybné a velmi nebezpečné pro bezpečnost vašich dat. Pokud jste IT specialista, pokračujte ve čtení části „Zálohování 1C infobase pomocí SQL“.

Opravdu stojí za to tomu věnovat čas?

Může se informační základna 1C v naší době nějak rozpadnout? Všechno se rozbije: čajové konvice a letadla, noha stoličky a elektronový mikroskop. Je těžké rozbít jen něco velmi jednoduchého, jako je litinová koule. Informační základna 1C je však komplexní objekt a funguje ve složitém technologickém prostředí. Dříve nebo později se stane něco, zprvu docela nepodstatného, ​​a pak „povolený šroub“ způsobí kaskádovou reakci softwarových a hardwarových selhání, která nakonec skončí velkými potížemi a ztrátou informační základny.

Verze souboru infobáze

Začněme tím nejjednodušším příkladem. V malé organizaci funguje konfigurace 1C se souborovou infobází, o kterou se stará administrátor příchozího systému, který pravděpodobně vše nastavil. Ale! Absence zpráv „Záloha není nakonfigurována“ neznamená, že je nyní nakonfigurována. Může to také znamenat, že se zpráva jednoduše nezobrazí. Proto při převzetí odpovědnosti za spolehlivost a bezpečnost výsledků naší práce se nejprve ujistěte, že informační databáze je souborová. Jak to udělat, je jasně znázorněno na obrázku níže. Pokud je tam uvedeno Srv= místo File=, jedná se o SQL databázi a kontaktujte svého DBA, aby nastavil zálohu. Pokud je databáze soubor, můžete použít ruční nebo automatické kopírování.

Manuální způsob– vytvořte záložní kopii, jak je znázorněno na obrázku. Před vyložením musí všichni uživatelé dokončit práci s infobází. Nahráním se vytvoří jeden záložní soubor s příponou .dt, který obsahuje Téměř všechny(více o tom později), co je aktuálně v infobázi a co bude zadáno poté. Dejte souboru smysluplný název (například „Trade Control Backup on 2017-10-31“) a vyberte speciální složku, do které jej uložíte (například složka „Zálohy“ ve složce „My Documents“). Pomocí tohoto souboru můžete následně obnovit infobázi do stavu, který předcházel uvolnění. Pro obnovení použijte operaci "Načíst infobázi".

Typické nastavení zálohování je znázorněno na obrázku. Toto nastavení předpokládá, že uživatel s právy správce nechá program na konci pracovního dne otevřený (jinak se záloha neprovede) a všichni ostatní uživatelé program ukončí. Alternativní možností je provést zálohu při vypnutí (budete požádáni o potvrzení, zda je záloha potřebná).

Když v prvním případě nastane čas zálohování, nebo když v druhém případě odejde poslední uživatel s právy správce, systém uzamkne infobázi a vypne všechny uživatele. Jedná se o složitý proces, který nemusí fungovat a může mít za následek chybu zálohování (viz obrázek níže). Na našem webu si o tom můžete přečíst speciální článek.

Omezit se na jednorázové automatické zálohování tedy nebude fungovat, i tak musíte tvorbu záloh pravidelně sledovat.

A nyní několik otázek, které nejsou pokryty populárními články na téma zálohování.

• Bude vše zálohováno?

Ne. Můžete ztratit nebo poškodit historii práce (kdo a kdy vstoupil a opustil program), historii změn objektů (kdo a kdy změnil data). Tyto informace jsou uloženy mimo informační databázi a jejich uložení a správná obnova vyžaduje speciální akce. Můžete ztratit nebo poškodit soubory 1C připojené k objektům (naskenované dokumenty, fotografie atd.). V závislosti na nastavení mohou být tato data uložena uvnitř nebo vně infobáze, v druhém případě vyžaduje jejich správné uložení a obnovení také speciální akce. Záloha také neukládá přizpůsobení spravovaných formulářů provedená uživateli.

• Je možné vytvořit záložní kopii v průběhu práce?

Standardní mechanismus se nejprve pokusí uživatele ukončit. To však není vždy možné, takže operaci zálohování lze provádět za běhu uživatelů. V tomto případě se předpokládá, že tito uživatelé data neupravují. Ale pokud tomu tak není, neexistuje žádná záruka, že záloha je správná. Takže odpověď na tuto otázku je ne, nemůžete.

• Jak často by se mělo zálohovat?

Záleží na intenzitě zadávání dat a kritičnosti jejich ztráty. Pro malou firmu s jedním nebo dvěma uživateli 1C to doporučujeme provádět alespoň denně. S 20 uživateli doporučujeme vytvořit jednu noční zálohu a více záloh v průběhu pracovního dne. Jak si pamatujete, bude to znamenat dočasnou technologickou přestávku v práci uživatelů.

• Měli jsme případy ztráty dat a rádi bychom přešli na SQL verzi databáze, ale je to velmi drahé ...

Možná budete chtít použít bezplatnou verzi MS SQL. Kontaktujte nás pro radu.

SQL verze infobáze

Tato část článku bude zajímat odborníky a ty, kteří se jimi teprve stanou.

Hned si ujasněme, že se nelze vyhnout úloze zálohování. Replikace ani absolutně spolehlivý hardware neochrání před náhodným nebo škodlivým poškozením dat na aplikační úrovni (chybná uzávěrka měsíce, nesprávné fungování špatně odladěného zpracování hromadných změn dat apod.). Data jsou v tomto případě bezpečně uložena, ale jsou nesprávná a neexistují žádné zálohy, takže vrácení není možné. V praxi musíte informační základnu 1C obnovovat kvůli poškození dat mnohem častěji, než byste si představovali.

Z pohledu uživatele žijícího v konceptuálním prostoru spisových základen máme body obnovení formou záloh infobáze, oddělených časem podle četnosti záloh: pokud děláme kopie jednou denně, tak v případě obnovy přijdeme o změny provedené v databázi maximálně na den nebo méně. V prostředí SQL serveru však způsob ukládání/úpravy dat a technologie zálohování poskytují „nekonečný“ počet bodů, které se spojují do jednoho kontinuální regenerační linka. To znamená, že se můžete vrátit k bodu těsně před okamžikem selhání nebo v případě potřeby k libovolnému bodu v čase zpět. V jazyce uživatele to odpovídá vytváření záloh jednou za sekundu nebo méně.

Faktem je, že zálohování v prostředí SQL není sekvence stisku tlačítek, ale soubor pravidelných událostí nad komplexními objekty. A tento komplex vzniká ve velmi složitém prostředí.

Abychom pochopili, „jak vše funguje“, ještě jednou naznačíme cíl našeho jednání – kompletní zálohu dat do sekundy před selháním (nebo okamžikem provedení nechtěných změn) a možnost vrátit se do libovolného bodu v čas přesný na sekundu.

Je obnova dat na vteřinu přesná opravdu tak důležitá?

To je důležité pro systémy front office nebo když podnik dosáhne určitého rozsahu. Pojďme si toto tvrzení objasnit tím, že si položíme několik hlavních otázek. Je snadné zorganizovat opětovné zadávání dat v pobočkové síti, která je rozptýlena v 10 regionech s různými časovými pásmy a má několik tisíc zaměstnanců? Jak zkontrolovat jeho správnost? Řekněme, že můžete vzít fakturu a znovu z ní zadat údaje. A jak znovu zadat údaje, které se dostaly do systému při interakci se zařízeními (fiskální registrátoři, bankovní terminály) nebo s informačními systémy třetích stran (online kredit, zpracování slevových karet jediné partnerské sítě), za účasti velké počet lidí (otisk systému pro záznam pracovní doby)? Kde získám zdroj informací pro opětovný vstup, pokud nejsou doklady a všechny úkony jsou evidovány bezpapírově (účtování stravy v podnikové jídelně pomocí zaměstnanecké karty)?

Jak získat kopii databáze se všemi daty, která byla v systému „sekundu před výbuchem“

Protokol transakcí (TLog)

Je potřeba zalogovat všechny akce, které budeme s databází provádět, plus jejich přesný čas (až mikrosekundy), a teprve potom je provést. S takovým logem (uloženým na velmi spolehlivém a rychlém médiu, nutně odděleném od databáze samotné), bychom mohli opakovat všechny operace od okamžiku, kdy databáze začala existovat, až do libovolného okamžiku obnovení s mikrosekundovou přesností. Ale protokolování transakcí má dvě nevýhody: po nějaké době, jak databáze roste, TLog zabere hodně místa (protože neustále roste) a obnova z „nulového“ bodu v čase bude trvat velmi dlouho.

Zálohy protokolu transakcí (zálohy TLog)

Obrazně řečeno, pravidelně odebereme všechny listy z deníku a odneseme je do vedlejší místnosti (říkejme zabaveným listům záloha TLog) a do samotného deníku vložíme balíček nových prázdných listů, aby bylo kam zaznamenat nové akce se základnou. Technicky se to dělá následovně: vytvoří se kopie ze souboru TLog a zapíše se na disk archivu, poté jsou všechny záznamy v TLog „vymazány“ (označeny jako volné, velikost souboru protokolu se nemění), informace o nových transakcích se zapisují na „vymazané“ místo. Je velmi důležité pochopit, že každý roztrhaný balík listů, ačkoli se v zavedené terminologii nazývá záloha protokolu transakcí, je jediný nosič informací o akcích se základnou za toto období a nyní tyto informace nejsou v samotném protokolu. Ztráta byť jen jednoho „vytrženého listu“ je proto prozatím absolutně nepřijatelná a termín Záloha TLlogu lstivě maskuje podstatu a účel těchto informací. Pamatujte - toto není záloha! Log jsme rozdělili do mnoha souborů a informace v každém z nich nejsou nikde duplikovány. Ale termín Záloha protokolu transakcí je obecně přijímán, takže jej budeme používat i v budoucnu.

Nyní TLog neroste donekonečna, ale vzniká rutinní úkol - plánované zálohování TLog.

Úplné zálohy databáze (Úplná záloha)

Pokud pravidelně vytváříte kopie celé databáze, pak pro obnovu bude možné vzít nejvhodnější kopii z hlediska času a opakovat ne všechny operace od nulového bodu v čase, ale pouze operace od okamžiku vytvoření této kopie. až do okamžiku obnovení (jak se říká, „vezměte plnou zálohu a nahrajte na ni TLlog“). To výrazně zkracuje dobu obnovy, zvláště pokud databáze existuje 5 let. Navíc nyní máme možnost odstranit starou plnou zálohu a zálohu TLog. Ve skutečnosti může být návrat na nejbližší sekundu často nutný pouze na krátkou dobu (například před dvěma měsíci od aktuálního okamžiku k vyšetření některých incidentů nebo k obnovení databáze sekundu před tragickým zavedením nechtěných změn). Během tohoto období budeme ukládat nepřerušený řetězec záloh TLog. Mimo toto období lze ukládat pouze body obnovy ve formě Plné zálohy (a i to ne všechny, ale např. pouze body za první dny v měsíci). Zálohy TLog mimo období lze nyní mazat vůbec (je zřejmé, že jejich selektivní mazání a selektivní ukládání mimo období je kvůli narušení řetězce TLog zcela nesmyslné). Tak či onak vzniká rutinní úkol inteligentního mazání.

Zde nastává následující problém. Představte si databázi s velkým počtem uživatelů a vysokou mírou změn. Podmíněně – 33 % času je věnováno psaní a 67 % čtení, nedochází k prostojům. Když obnovíme databázi, můžeme zapisovat téměř 100% času, tzn. třikrát rychleji. To znamená, že za hodinu dokážeme z logu obnovit tři hodiny práce s databází. A tato hodina je maximální prostoj pro obnovu, se kterým firma souhlasí. Řekněme, že úplné zálohování se provádí jednou denně. Pokud k selhání došlo za 21 hodin, budeme muset strávit 7 hodin obnovou protokolu, což je absolutně nepřijatelné. Úplná záloha by se tedy měla provádět jednou za 3 hodiny? Bohužel to není vždy možné: databáze jsou tak velké (stovky gigabajtů a dokonce terabajtů), že je prostě nemožné vytvořit plnou zálohu v takové době. Časté vytváření Plné zálohy v pracovní době navíc přináší další zátěž a zpomaluje práci uživatelů a ukládání takového množství dat je velmi nákladné. V zásadě ale stačí, že nemožnost vytvořit Full zálohu v přijatelném čase zcela ukončí naši zálohovací technologii.

Rozdílové zálohy (rozdílová záloha, Rozdílová záloha)

Můžeme vymyslet speciální strukturu úložiště dat s neustále se zvyšujícím počtem transakcí a další triky, které usnadní pochopení rozdílu mezi dvěma stavy databáze (od nynějška doteď - to už bylo, vše, co následuje, je již nové). To umožní, aby do zálohy databáze nebyla uložena všechna data, ale pouze rozdíly mezi aktuální plnou zálohou a předchozí plnou zálohou. Postup pro získání další úplné kopie bude jednoduchý: musíte vezměte plnou zálohu a nahrajte na ni zálohu rozdílu. Namísto uložení jednoho terabajtu dat v plné záloze jsme ušetřili pouze deset megabajtů v záloze Diff a dostali příležitost to dělat poměrně často – například jednou za půl hodiny. Musíte se ale ujistit, že je k dispozici plná záloha, jinak je rozdílová k ničemu.

Na tomto místě můžete velmi dobře porovnat rozdílovou zálohu a zálohu transakčního protokolu a opravit přijaté informace. Pokud nevytvoříte úplnou kopii, velikost rozdílových záloh se monotónně zvětší, protože bude se hromadit stále více rozdílů od úplné kopie – a tak dále, dokud nebude vytvořena další plná záloha. Velikost dalších záloh transakčního logu nebude mít takový trend, jejich velikost je dána počtem akcí provedených s databází za dané období. Obvykle se jejich velikost pohybuje kolem určité průměrné hodnoty, ale v určitých obdobích (při provádění operací hromadné změny dat, při prudkém nárůstu aktivity uživatelů apod.) se může od průměru značně lišit.

Obrázek níže znázorňuje náš záložní systém s určitou mírou konvenčnosti. První řádek objektů zobrazuje stav databáze, do které jsou pravidelně přidávány záznamy. Druhý zobrazuje jednu plnou zálohu a tři rozdílové zálohy. Třetí řádek zobrazuje obsah záloh protokolu transakcí. Každý prvek je očíslován. Pojďme nastavit nějaké závislosti mezi prvky.

• 5+7=3. To znamená, že s Full backup 5 a Diff backup 7 můžete obnovit databázi do stavu 3. Zároveň absence 6 nijak neovlivní možnost obnovy.
• 5+10+11=3. Stejného výsledku (obnovení do stavu 3) lze dosáhnout, pokud všechny změny zaznamenané v TLogBackup 10 a 11 aplikujeme na Úplnou zálohu 5. To bude nutné provést, pokud nemáme 6 a 7 z důvodu, že plán pouze pro vytvoření 5 a 8 (nebo pokud jsou 6 a 7 poškozeny). Ale pokud je 7, pak je způsob 5+7 mnohem rychlejší než způsob 5+10+11.
• Pokud chybí pouze 7, pak lze základnu obnovit do stavu 3 metodou 5+6+11.
• Pokud je rozvrh takový, že 11 nebyla vytvořena, obsah 12 bude: "Přidáno: Toporkov, Ufimcev, Jašin."
• Transakční protokol na první pohled není na obrázku zobrazen, ale jak si pamatujete, záloha TLog vůbec není záloha, ale protokol transakcí na určité období. Upozorňujeme, že výskyt nových jmen v časopise předchází jejich výskytu v databázi.
• Pokud transakční protokoly nejsou zálohovány, obsah protokolu TLog v čase 12 bude „Přidáno:“ následovaný seznamem příjmení 4 (tj. všechny akce jsou protokolovány). Pokud jsou zálohy vytvořeny jako na obrázku, bude obsah protokolu transakcí v čase 4 a také v čase 8 následující: "Zatím nebyla provedena žádná akce."

Zálohování konce protokolu transakcí

Pokud se nebavíme o systémech s vysokou dostupností, tak v případě poruchy je potřeba ještě jedna ruční operace, která již není rutinou, ale vytvořením nejnovější zálohy TLog. Pokud to není možné, tzn. log je poškozen spolu s databází nebo spolu se serverem - obnova je možná pouze do poslední zálohy TLog a ne do poslední sekundy. Tito. původního cíle nebude dosaženo.

Z toho vyplývá, že klíčovým prvkem celého zálohovacího systému je transakční log. Musí být umístěn na samostatném médiu (ne stejném jako médium pro samotnou databázi) s velmi vysokou spolehlivostí, vysokou rychlostí přístupu a vysokou dostupností, ale v žádném případě v různých složkách na stejné logické jednotce, ani na různých logických jednotkách na stejný fyzický nosič. Navíc je žádoucí, aby i v případě havárie SQL serveru zůstal log dostupný nebo alespoň mohl být dostupný v minimálním čase (o metodách pro dosažení odolnosti proti chybám neuvažujeme, ty jsou tématem samostatného článku působivý objem).

Jde o tak komplexní systém, který zajistí, že dosáhneme cílů stanovených na začátku a budeme oproštěni od problémů objevených při jeho vývoji.

Model úplné obnovy (funguje pouze s naplánovanými úlohami a pod kontrolou správců)

Popsali jsme model úplné obnovy databáze - model úplné obnovy. Pro speciální případy v MS SQL Server existuje jednoduchý model obnovy (Simple recovery model) a model s neúplným protokolováním (Bulk-logged). Model úplné obnovy zajišťuje pravidelné provádění úloh údržby databáze a také kontrolu nad pravidelností a výsledky provádění úloh správcem. To naznačuje existenci komplexní sady nástrojů pro návrh plánu údržby, kterou je třeba se naučit.

Pojďme k praxi

Možná prvním problémem, se kterým se setkáte, je, že nemůžete vytvořit nový plán údržby.

Tuto funkcionalitu je nutné povolit spuštěním SQL skriptu (Nový dotaz na nástrojové liště, zadejte skript, Spustit na nástrojové liště). Pokud je skript úspěšně spuštěn, uvidíte odpovídající zprávy ve spodní části okna se skriptem.

Text tohoto skriptu ke zkopírování/vložení:

Skutečný plán údržby

Začněme tím, že si ukážeme skutečný plán údržby sloužící neproduktivním databázím ve vývojové smyčce, a poté zvážíme jednotlivé fragmenty plánu nezbytné pro jeho čtení a pochopení. Čtyři ilustrace níže ukazují plán údržby "Hlavní plán", který se skládá ze čtyř dílčích plánů, které fungují podle vlastního plánu.

V Průzkumníku objektů vidíme, že na serveru SQL Server jsou nakonfigurovány dva plány údržby (hlavní plán, testovací plán). Hlavní plán se skládá ze čtyř dílčích plánů s různými harmonogramy (Hedule):

• Týdenní údržba
• Rozdílová záloha
• Záložní ZhT

V oblasti návrhu úkolů vidíme úkoly. Proces navrhování plánu se skládá z přetahování úkolů z palety Toolbox, nastavení voleb úkolů a kreslení šipek mezi úkoly. Úkoly mohou mít v oblasti návrhu libovolný popis, pomocí ikon lze nastavit shodu mezi úkolem na plánu a úkolem na paletě. Například úloha „Chyba integrity“ je úloha „Upozornit operátora“ na paletě (ikona „osoba“).

Je to blokové schéma?

První věc, která vás možná napadne, když se podíváte na scénář úlohy plánu údržby, je, že se jedná o vývojový diagram, šipky označují přechody z jednoho úkolu do druhého a můžete je procházet ukazováčkem a sledovat celý scénář od začátku do konec. Nicméně není. Stává se, že na první pohled je dokonce těžké určit, kde to všechno začíná a jaká je posloupnost úkolů. Skript může obecně začínat na více místech a také končit na více místech, protože SQL Server má tendenci spouštět absolutně všechny úlohy současně.

Souběh a omezení

Jediná věc, která ho zastaví, je přítomnost omezení. Úkol nelze spustit, dokud se „neuskuteční“ přicházejícíšipky do něj (omezení, omezení). Barva šipky označuje typ dokončení ovlivňujícího úkolu. Příchozí zelená šipka označuje u závislého úkolu omezení "spustit pouze v případě, že ovlivňující úkol uspěje", černá - "spustit pouze po dokončení ovlivňujícího úkolu (Dokončení)", červená - "spustit pouze v případě chyba v ovlivňujícím úkolu (selhání)“.

Typ čáry (plná nebo přerušovaná) označuje logický operátor AND nebo OR pro výpočet konečného omezení z více příchozích šipek. Tento operátor se změní v dialogu Editor omezení priority (dvojitě klikněte na kteroukoli šipku). Plné šipky se musí splnit všechny, alespoň jedna z tečkovaných se musí splnit - pak bude závislý úkol okamžitě spuštěn. Barvu každé příchozí šipky lze změnit nezávisle (kliknutí pravým tlačítkem, Úspěch/Neúspěch/Dokončení). Typ čáry lze změnit pouze pro všechny příchozí šipky najednou (dvojité kliknutí, dialog Editor omezení priority). Za prvé, všechny úlohy, které nemají žádná omezení, začnou běžet současně. Jakmile je dokončen další úkol, jsou zkontrolovány všechny úkoly na něm závislé a zároveň jsou spuštěny k realizaci ty úkoly, u kterých konečná hodnota omezení již stačila k rozhodnutí o spuštění.

Informace v předchozím odstavci jsou dostatečné k pochopení obecného mechanismu, kterým SQL Server provádí úkoly plánu údržby. Podívejme se nyní na praktické otázky.

Divný rozvrh

Podivný čas provádění úlohy je způsoben čtyřhodinovým rozdílem mezi časovým pásmem serverů a časovým pásmem vývojářů. Rozsah možné pracovní doby pro vývojáře je od 9:00 do 21:00, takže podplán „Záložní ZhT“ se provádí každou hodinu od 10:00 do 21:00, přičemž změny se opravují každou hodinu (v 9:00 nejsou žádné změny: 00 ještě). Přeloženo do časového pásma serverů je to od 14:00 odpoledne do 01:00 ráno, jak je uvedeno v rozvrhu.

Při zadávání času můžete přeskočit půlnoc, funguje to správně. Vypadá to trochu divně. Ostatní plánovači, aby se vyhnuli potížím s pochopením času ukončení následujícího dne, požadují dobu trvání úkolu – „do X hodin“.

Pokud po úplné záloze bezprostředně následuje záloha VT, můžete si být 100% jisti, že plán vytvořil průvodce plánem údržby (nikdy jej nepoužívejte, nevytváří nic než odpadky) nebo málo kvalifikovaný správce, který považuje za úplný backup + TLog backup pair , vytvořený současně, nějakou povinnou sadou pro obnovu. Ale to jsou nezávislé úlohy, které běží v různých plánech.

Náš plán je ale výjimkou, protože naším cílem je shromáždit informace o úspěšnosti klíčových úloh (integrita, plná záloha, zálohování VT) v jednom dílčím plánu a pouze v případě, že budou úspěšné, dát příkaz k odstranění starých záloh.

Pokud je mazání starých záloh prováděno bezpodmínečně, může se stát, že se nové zálohy nevytvoří a staré budou zcela odstraněny. Pokud je mazání starých záloh rozloženo do různých dílčích plánů, v závislosti na typu zálohy to dopadne téměř stejně. Řekněme, že plná záloha přestala fungovat. Zároveň se již neprovádělo mazání starých plných kopií. Ale podplán Backup VT o tom nic neví a nadále odstraňuje zastaralé zálohy VT. Po nějaké době budeme mít v aktuálním okně nejen průběžnou přímou obnovu, ale dokonce i body obnovy: poslední úplná záloha byla vytvořena příliš dávno a uložené zálohy ZT z poslední doby jsou naprosto k ničemu, protože. v jejich nepřetržitém řetězci neexistuje jediná úplná záloha.

Úloha rozdílové zálohy není klíčová pro obnovu a neobjevuje se v dílčím plánu. Stále by však bylo možné jej přidat do tohoto podplánu a umístit jej ihned po úplné záloze.

*

*Všimněte si ikony fx na úkolu

Každá úloha má vlastnosti, z nichž některé lze zobrazit v dialogovém okně nastavení úlohy (dvojité kliknutí) a úplný seznam lze zobrazit v dialogovém okně vlastností (klepnutí pravým tlačítkem, Vlastnosti). Úlohy mají také vlastnost Expressions, která vám umožňuje vytvořit tabulku vlastností a jejich odpovídajících SQL výrazů pro výpočet hodnot vlastností za běhu. Praktické využití této možnosti je následující. Určitě jste viděli tzv. "bat files" za účelem smazání všeho kromě záloh pro první čísla, nebo naopak, za účelem zkopírování záloh pro tato čísla na nějaké jiné místo před odstraněním záloh.

Takové úlohy nevyžadují externí nástroje a jsou řešeny standardními nástroji MS SQL. Rozšíření úplného záložního souboru pro první dny lze provést pomocí MNT a pro zbývající dny - pomocí BAK. To znamená, že úloha čištění může odstranit BAK starší než 1 měsíc a uložit MNT na delší dobu, smazat je například po 1 roce.

Když otevřete dialogové okno nastavení úlohy Úplná záloha databáze, uvidíte příponu souboru BAK nebo MNT v závislosti na dnešním datu.

Podle doporučení 1C by statistiky měly být aktualizovány denně a mezipaměť procedur by měla být mazána s frekvencí aktualizací statistik. Tyto úkoly jsou na jednu stranu poměrně náročné na zdroje a na druhou stranu nejsou zásadní pro informační základny vývojového týmu. Koneckonců, takové databáze neobsahují mnoho dat a problémy s výkonem nejsou akutní. Tyto úlohy se tedy provádějí v týdenním podplánu, zatímco v denním jsou zakázány (klikněte pravým tlačítkem na úlohu, Zakázat). Nejen nepřítomné, ale vytvořené a zakázané.

Uvažujme přirozenou otázku: bude vše v zakázaném problému fungovat správně? Jak na takový zákaz zareagují červené, černé a zelené šipky?

Při psaní komplexních plánů údržby vyvstává úkol ladění a z toho vyplývající praktické potřeby:

• Ve skutečnosti neprovádějte dlouhý úkol, ale považujte jej za podmíněně dokončený, přičemž jeho vliv v podobě šipek si ponechte na ostatní úkoly;
• Modelování chybného provedení úkolu.

Pro první z nich má MS SQL mechanismus pro zamezení skutečného provedení úlohy: klepněte pravým tlačítkem myši na úlohu, Zakázat. V tomto případě úkol zešedne, nebude ve skutečnosti proveden, ale bude považován za splněný i splněný (budou fungovat černé a zelené šipky). Pokud chceme simulovat chybné provedení, pak v okně vlastností úlohy musíme nastavit vlastnost úlohy ForceExecutionResult na Failure. Nezaměňujte tuto vlastnost s vlastností ForcedExecutionValue v jiné sekci.

Implementace podmínky ((A nebo B) a C) pro omezení úlohy nebo fiktivní úlohy, které vůbec nejsou fiktivní

Omezení lze kombinovat buď s operátorem AND nebo operátorem OR. To znamená, že na obrázku níže nelze tečkované šipky Dokončení nakreslit přímo na úlohu "Upozornit na dokončení s chybami". Řešením je vytvořit meziúlohu „Byly chyby“, která shromažďuje výsledek tečkovaných černých šipek. Úloha je SQL skript z jediného příkazu go, to znamená, že by se zdálo, že nedělá nic užitečného.

Ve skutečnosti však shromažďuje příchozí omezení a slouží jako zdroj omezení pro další úkoly, takže je důležitým kontrolním bodem, kterým prochází provádění skriptů. Tento trik s figurínou lze použít i v jiných situacích. Například ve vašem scénáři není nutné převádět databáze do režimu offline a poté vrátit stav zpět. Úlohu „Online nezálohovatelné databáze“ ale nelze z podplánu jen tak smazat, je to důležitý bod provádění, shromažďující příchozí omezení a sloužící jako zdroj odchozích. V tomto případě musíte tento úkol nahradit fiktivním scénářem.

Asynchronní provádění

V konstrukci na obrázku výše může nastat „kvantový paradox“, kdy účinek předčí příčinu. Pokud totiž jeden z ovlivňujících úkolů, například „Chyba integrity“ dal signál ke spuštění závislého úkolu, nemá již smysl čekat na výsledek ze zbytku ovlivňujících úkolů, stále to neovlivňuje skutečnost že by měla být spuštěna závislá úloha "Došlo k chybám". Proto bude okamžitě provedena. Po nějaké době se může stát, že úloha „ZT backup error“ bude fungovat a skončí. Mohlo to spustit "Byly tam chyby", ale tato událost se již stala dříve. Toto je záměrné v našem dílčím plánu, ale tyto druhy asynchronních efektů je třeba mít na paměti, aby se zabránilo neočekávaným výsledkům. Například při měření celkové doby provádění dílčího plánu údržby pomocí úlohy Alert Operator na začátku a na konci.

co to je

Toto je první a jedna z posledních úloh, které se mají spustit, což jsou skripty SQL. Faktem je, že ve vývojové smyčce jsou často kopie historických systémů velmi velkého objemu. Mají vás seznámit s vedením historických záznamů, slouží jako zdroj dat při migračních operacích. Údaje v nich se prakticky nemění. Originály databází jsou v aktuálním výrobním okruhu zákazníka, kopie těchto systémů lze vždy získat na vyžádání. Zálohování tohoto obrovského množství informací je plýtváním zdrojů. V parametrech úloh, které vytvářejí zálohy, je dobré v úlohách zálohování místo vypisování konkrétních databází uvést parametr „Vše“ (vyhnete se tím typické chybě „databáze byla vytvořena, ale zapomněli ji zahrnout do zálohy seznam"). A pokud ano, je potřeba mechanismus pro jakési vyřazení některých speciálních základen z množiny Vše. Přesně to dělá první skript – uvádí takové databáze do stavu OFFLINE. Druhý skript dělá opak. V tomto případě je v parametrech úloh zálohování nebo reindexace nastaven parametr "Ignorovat databáze ve stavu OFFLINE", jinak dojde k chybě úlohy.

Paralelně nebo sériově

V podplánu „Denní plná záloha“ je úloha „Offline nezálohovatelné databáze“ provedena jako první, protože toto je jediný úkol, který nemá žádné limity. Pod ním vidíme lemované subsekvence provádění úkolů, které jsou hlavním jádrem podplánu „Denní plná záloha“.

Jako důvody pro sekvenční provádění řekněme přání nepřekročit zatížení SQL serveru při údržbě a viditelnost plánu. Obvykle kvůli velkému nočnímu oknu s přestávkou v práci uživatelů se sekvenční provádění nestává problémem. Mohou však nastat situace, kdy s databází pracuje mnoho uživatelů z různých časových pásem a okno údržby se velmi zkrátí. Pokud se sekvenční provádění úloh nevejde do okna údržby, bude nutné je paralelizovat. To lze provést pomocí šipek přicházejících z "Offline nezálohovaných základen" ke každému hlavní úkol a poté konvergování k "Online nezálohované základny". Tyto dvě šedé úlohy musí běžet postupně vzhledem k sobě navzájem. Výsledek paralelizace je uveden níže. Stanovených cílů je dosaženo, ale viditelnost se výrazně ztrácí:

Zde je druhá možnost, topologicky ekvivalentní s předchozím schématem, ale více vizuální díky změněnému uspořádání úkolů + odstranění šedých úkolů.

Paralelnost v rámci standardních úloh Backup Database a Check Database Integrity a interpretace výsledku jejich provedení

Úlohy "Vytvořit záložní kopii" a "Kontrola integrity databáze" obecně pracují se seznamem databází. Budou pracovat postupně s každou databází, nebo bude pro každou databázi existovat mnoho paralelních úkolů údržby? Dvakrát klikneme na úlohu, v dialogu, který se otevře, stiskneme tlačítko „Zobrazit T-SQL“. Vidíme, že ve skriptu, který je generován a spouštěn SQL Serverem, jsou instrukce zálohování BACKUP DATABASE odděleny instrukcemi GO, což znamená, že tyto zálohovací procesy poběží paralelně. Výsledek se nevztahuje na balíčky, ale na zakázku jako celek. Pokud dojde k chybě v úloze s alespoň jednou databází, bude úloha obecně považována za chybně dokončenou, pokud žádné chyby nebudou, bude úloha obecně považována za úspěšně dokončenou.

Plánování úkolů údržby (klíčový problém, často považovaný za sekundární)

Shrňme si hlavní úkoly plánu údržby databáze modelu úplné obnovy:

1. Úplná úloha zálohování
2. Rozdílová úloha zálohování
3. Úloha zálohování TLog

V populárních článcích na téma SQL zálohování není problematika plánování úloh nejčastěji konkrétně zvažována nebo je mu přidělena sekundární role. Navržená periodicita úkolů přitom není jasně zdůvodněna. Mezitím je tato otázka klíčová. Jednoznačná doporučení neexistují. Frekvence a složení úkolů se může za různých okolností lišit. Zvažte obecné zásady.

Hlavní věcí, kterou je třeba začít, je přijatelné okno ztráty dat (cíl bodu obnovy, RPO) + doba obnovy (cíl doby obnovy, RTO). Tyto indikátory zase určují hardwarovou architekturu, použité technologie a frekvenci provádění úloh.

Frekvence zálohování TLog

Frekvence zálohování TLog závisí na hodnotě RPO. Typická frekvence úlohy zálohování TLog u produktivních databází je od ½ do 1 času RPO za celý denní časový interval pro provádění změn v databázi (včetně časových intervalů, během kterých jsou změny prováděny naplánovanými úlohami a jednorázovým zpracováním ve vypnutém stavu). -hodiny). Pro produktivní základny je typické provádět změny do 24 hodin. Pokud je pro takovou databázi RPO = 1 hodina, pak by se záloha transakčních protokolů měla provádět nepřetržitě každých 30-60 minut. Existují však případy, kdy je vzhledem ke specifikům systému možné omezit se pouze na interval pracovní doby, například od 10 do 18, od pondělí do pátku, stejně jako na větší či menší frekvenci.

Pro neproduktivní databáze (ve vývojovém prostředí) může být vhodnější použít jednoduchý model obnovy, kde tato úloha zcela chybí. Navzdory skutečnosti, že v četné literatuře a oficiální dokumentaci je deklarováno, že použití zjednodušeného modelu nepřináší zvýšení výkonu (protože TLog je stále udržován), v praxi tomu tak není. Doba provádění často prováděné operace umístění změněných konfiguračních objektů 1C do úložiště při použití zjednodušeného modelu obnovy se několikrát zkrátí a celkový zisk v čase dramaticky zvyšuje rychlost vývoje. Současně s frekvencí ½ až 1 čas RPO již musíte vytvořit zálohu rozdílu. Stejnou metodu lze použít pro produktivní back office systémy s nízkou rychlostí změn, kde existuje možnost opětovného zadání dat, která byla v okně RPO a ztracena v důsledku havárie.

Vzájemná periodicita plné zálohy a rozdílové zálohy

Frekvence obou úkolů je obecně volena tak, aby bylo možné splnit RTO. Pokud je intenzita provádění změn taková, že umožňuje provádět plné zálohy jednou měsíčně, rozdílové zálohy jednou denně a zároveň 29. dne dojde k obnově v rámci RTO - proč ne. Pokud je intenzita změn taková, že při takové periodicitě úloh se doba obnovy stává nepřijatelnou, možná budete potřebovat úplnou kopii na začátku dne a několik rozdílových záloh během dne.

Četnost úlohy zálohování Rozdíl závisí také na objemu zálohy Rozdíl ve srovnání s Úplnou zálohou. Pokud při zvolené frekvenci rozdílové zálohy její velikost začíná překračovat polovinu velikosti plné zálohy, další vytváření rozdílové zálohy se stává nevhodným, v tomto okamžiku je třeba vytvořit další plnou zálohu. Je však třeba připomenout, že tento poměr by měl být u relativně nových databází ignorován – v průběhu času bude objem denních změn představovat malou část (tj. povolenou pro zálohování rozdílů) z celkového objemu dat a 95 % objemu budou obsazeny historickými údaji.

Dodržování rad, které si můžete přečíst na internetu o konfiguraci záloh SQL, může být zdrojem problémů pro vaše data. Aplikujme poznatky z tohoto článku na rady některých odborníků:

U často aktualizovaných databází se doporučuje provádět úplné zálohování v neděli a zálohování TLog jednou denně. Okno ztráty dat (RPO) = 1 den je nepřijatelně dlouhé. Odborník je přitom přesvědčen, že je to nejlepší způsob, jak předejít případné ztrátě dat. Doba obnovy v sobotu bude také nepřijatelně dlouhá, protože bude nutné aplikovat změny na Plnou zálohu po dobu 6 dnů a intenzita změn v databázi je vysoká.

Zde se každý den od pondělí do pátku provádí záloha VT a Shrink VT (Text „kopie databáze“ ve sloupci „Popis“ je zřejmým překlepem, protože operace je jasně uvedena ve sloupci „akce“ - záloha VT). Pokud se vrátíte k našemu dílčímu plánu Weekly Maintenance, uvidíte, že úloha zkrácení VT se výstižně jmenuje „Shrink Do Not“ a je zakázanou úlohou (zašedlá). Vyhledávací dotaz „smrštění by mělo být provedeno“ pomůže objasnit informace.

Jdeme o řádek dolů a vidíme, že po každé záloze Diff se záloha TLog smaže – jde o dobrovolné odmítnutí průběžné přímé obnovy (klíčový cíl celého zálohovacího systému) a přechod na body obnovy. Body jsou od sebe odděleny dnem. To znamená, že okno ztráty dat je 24 hodin (RPO=24 hodin).

Sjíždíme na poslední řádek a nacházíme největší chybu celého plánu. Pokud došlo k náhodnému nebo škodlivému poškození dat, jsou data velmi bezpečně uložena, ale jsou k ničemu. Představme si případ, kdy v sobotu přijde programátor řešit problém „zprávy rozdávají úplné nesmysly“. V 18:05 si uvědomuje, že problém je způsoben tím, že data klíčových registrů byla zcela zkreslena (smazána) a protokoly říkají, že se tak stalo v pátek odpoledne. V tuto chvíli má databázi, ve které jsou nesprávná data, a jednu úplnou zálohu vytvořenou před 5 minutami, ve které jsou také nesprávná data. Vše ostatní je zcela odstraněno, protože. Úplná záloha byla úspěšně vytvořena. Tento plán údržby je šampiónem v počtu chyb.

Výše uvedený obrázek je plán základní úrovně vytvořený nováčkem pomocí Průvodce plánem údržby a neřeší žádné problémy. Má to běžnou chybu: nemůžete vytvořit úplnou zálohu závislou na výsledcích kontroly integrity. Když se databáze zhroutí, je lepší mít zálohu se dvěma nefunkčními odkazy v databázi než nic. Porovnejte s tím, co bylo provedeno v podplánu "Denní zálohování" - porušení integrity informuje operátora, ale nezabrání vytváření záloh.

Funkce obnovy - jak neztratit data

Zdálo by se, že by to mohlo být jednodušší: stačí vrátit databázi před časem z její vlastní zálohy. A nasadit zálohu jiné databáze v databázi je trochu složitější. V této jednoduché operaci na nás ale číhají velká nebezpečí, v jejichž důsledku můžete o svá data snadno přijít. Navíc musíme upřímně říci, že v dialogu obnovy je tolik absurdit, že se začínajícímu specialistovi bude jistě zdát, že něčemu nerozumí a něco dělá špatně, i když dělá všechno správně.

Protože tyto "vlastnosti" nejsou nikde popsány, vyplňte tuto mezeru. Podívejme se na typický úkol obnovení výrobní základny po určité době (zdroj, ZUP3ENERGO na obrázcích) do individuální databáze programátora (přijímač, ZUP_SUV na obrázcích), aby se incident prošetřil. Popisem různých „funkcí“ chování různých verzí SQL Serveru termínem „nové verze“ rozumíme vydání 13.0.4457.0 a termínem „staré verze“ – vydání 11.0.3156.0.

První akce- klikněte pravým tlačítkem myši na cílovou databázi, Úkoly, Obnovit, Databázi. A hned v dialogu Obnovit databázi (ilustrace níže) vidíme žlutý znak nebezpečí: vytvoří se záložní kopie konečného fragmentu transakčního protokolu zdrojové databáze. Samozřejmě, ve skutečnosti bychom měli mluvit o přijímací základně a logika by zde měla být následující: než zničíme aktuální obsah obnovením, pro jistotu konečně opravme to, co teď máme. To vám umožní vrátit zpět aktuální obnovení a následně provést další obnovení do bodu před obnovením. Operace, zdá se, je užitečná a není v ní nic nebezpečného, ​​pokud by skutečně šlo o přijímač. Nejde však jen o chybu ve zprávě, na zdroji je chybně provedena záloha tail-logu. To lze experimentálně otestovat kliknutím na tlačítko Skript a pohledem na kód.

Proto v pátém kroku musí být tato operace zrušena (viz níže). Oprava nejnovějších změn v přijímači (které mohly nastat od vytvoření poslední zálohy VT) je nutné provést ručně (například neplánovaným spuštěním odpovídající úlohy).

Nyní se podívejme na to, co vlastně může sloužit jako zdroj. Dialog ukazuje, že zdrojem může být Databáze a Zařízení. Musím vysvětlit, že samotná databáze nemůže sloužit jako zdroj dat pro libovolný časový okamžik v minulosti. Zdrojem mohou být zálohy databáze. Proto je vyžadováno vysvětlení možností.

• Zdrojová databáze - celá sada souborů obsahujících zálohy zdrojové databáze a jejích protokolů podle záložního registru, který je udržován v systémových tabulkách SQL serveru. „Podle registru záloh“ je extrémně důležitá fráze pro pochopení mechanismu operace. Znamená to, že i když na disku aktuálně chybí nějaký soubor, může to být zohledněno v plánu obnovy (protože je to opraveno v registru) a objeví se v seznamu Sady záloh pro obnovu. K chybě dojde pouze ve fázi obnovy a pokud se jedná o zálohu rozdílů nebo záložní soubor TLog - základna zůstane v nepoužitelném stavu. Abyste tomu zabránili, nejprve zkontrolujte možnost obnovení pomocí tlačítka „Ověřit záložní médium“.
• Zdroj zařízení je libovolná sada souborů. Faktem je, že historii záloh lze vymazat. Nebo byly zálohy vytvořeny na jiném SQL serveru, a proto nejsou registrovány v registru záloh na tomto serveru. Proto je možné explicitně specifikovat libovolnou sadu souborů. Můžete určit sadu souborů, která je pro obnovu nadbytečná (například po mnoho dní - SQL server v dalším kroku vybere pouze ty potřebné).

Druhé dějství- vyberte zdroj, který se v našem případě liší od přijímače. Novější verze MS SQL Serveru na to reagují normálně. Starší verze mají nepříjemné efekty, které je třeba pečlivě sledovat, aby nedošlo ke ztrátě dat:

• Účinek 1. MS SQL okamžitě změní Cíl na databázi uvedenou ve Zdroji. Proto musí být Destinace vrácena zpět. Pokud si toho nevšimnete, databáze bude tiše přepsána a ani nezaškrtnutý příznak "Přepsat existující databázi" na kartě Možnosti ji nedokáže ochránit;
• Efekt 2. Přejděte na záložku Soubory a uvidíte - místo přijímače chce MS SQL Server přepsat zdroj (viz následující obrázek). Je nutné ručně zadat názvy souborů přijímající základny a její log, jinak dojde ke ztrátě zdroje (viz čtvrtý krok níže).

Třetí akce. Po výběru sady souborů jako zdroje je třeba určit bod v čase (Obnovit do, tlačítko Časová osa). Zadání časového okamžiku umožňuje vybrat konkrétní sadu (Záložní sady k obnovení) z původní sady souborů definované zdrojem (Zdroj), která je nezbytná pro obnovení do zadaného času. Ještě jedna absurdita, která je přítomná i v nejnovějších verzích MS SQL, je zřejmá: volba "Obnovit do" a tlačítko TimeLine jsou v dialogu nakresleny na špatném místě. Určitě odkazují na zdroj, nikoli na cíl. Tato chyba nebude nikdy opravena, je stará přes 10 let, takže je potřeba si na ni jen zvyknout. Buďte také velmi opatrní při ručním zadávání času bez použití pravítka: i nejnovější verze SQL Serveru "sežerou" první záznam dne v měsíci, takže číslo bude nutné zadat dvakrát.

Čtvrtá akce.

Pátá akce. Přejděte na kartu Možnosti. Nastavte možnost přepsání databáze, zrušte zaškrtnutí možnosti vytvořit konečný fragment VT, povolte možnost „uzavřít existující připojení k cílové databázi“, pokud je k dispozici:

Šesté dějství. Po obnovení z „cizího zdroje“ obdrží obnovená základna (ZUP_SUV) cizí logické jméno (ZUP3ENERGO). Musí být vrácen zpět v dialogu vlastností databáze (klikněte pravým tlačítkem na databázi, Vlastnosti). Pokud se tak nestane, bude to mít velmi nepříjemné důsledky.

Hodně štěstí vám a vašim datům!

Zálohování v 1C 8.3 a 8.2 je nejdůležitější operace, kterou by měl umět každý uživatel, programátor, správce. Specialisté na informační technologie také často nazývají takové kopírování zálohou 1C. Zvažte, co to je, a podrobné pokyny.

Lidé jsou rozděleni do dvou kategorií: ti, kteří ještě neprovádějí zálohy, a ti, kteří již zálohují.— Vtip systémových administrátorů.

Proč je důležité zálohovat? Všechno je velmi jednoduché, musíte si pamatovat zákon podlosti: nejhorší věci se dějí ve špatnou dobu.

Představte si – měsíc připravujete závěrečné zprávy, opravujete chyby, vozíte do programu kilogramy primární dokumentace. Pak jsme se rozhodli dát si pauzu, nalít si čaj. Po návratu na pracoviště zjistíte, že se uklízečka dotkla kabelu (došlo k přepětí, kolegové zaplavili stroj kávou atd.) vaší systémové jednotky. Zběsile se pokoušíte zapnout počítač, ale nereaguje. Hlášení zítra co dělat?

Abyste se do takové situace nedostali, důrazně se doporučuje zálohovat alespoň jednou týdně (nebo lépe jednou denně). Není to těžké, zabere to maximálně 10 minut, ale výrazně to usnadní život v těžké situaci.

Získejte zdarma lekce videa 267 1C:

Pokyny pro zálohování v 1C

Zvažte stručný návod k odstranění zálohy databáze v 1C. Instrukce je vhodná jak pro souborový režim databáze, tak pro režim klient-server.

Nahrání kopie databáze do souboru

Vstupte do programu v režimu konfigurátoru. Chcete-li to provést, v úvodním okně programu vyberte požadovanou databázi a klikněte na „Konfigurátor“:

Vstoupíte do režimu vývoje a správy databáze. Dále vyberte položku nabídky "Administrace - Uvolnit infobázi ...":

Program vás vyzve k výběru cesty, kam chcete nahrát databázový soubor, a jeho názvu. Po výběru program oznámí úspěšné dokončení operace:

Nejlepší je uložit soubor na externí médium (například flash disk, externí pevný disk).

Jak obnovit databázi 1C 8.3 ze zálohy

Chcete-li obnovit databázi ze souboru, musíte také vstoupit do režimu konfigurátoru, ale vybrat položku „Administrace - Načíst infobázi...“:

Existuje několik způsobů, jak vytvořit zálohy:

• Kopírování databázových souborů;
• Nahrání souboru do souboru .dt;
• Zálohování pomocí konfiguračních nástrojů 1C 8.3.

Zvažme každý ze způsobů, jak vytvořit „zálohy“ databází 1C, podrobněji.

Jednoduchá kopie souboru s příponou" *.1CD" a v případě potřeby - 1Cv8Log" z adresáře IB :

Protokol událostí ukládá informace o vstupu a ukončení relace, změnách dat, spouštění a provádění úloh na pozadí a další informace v závislosti na nastavení:

Tato metoda kopírování vám umožňuje provádět, když jsou spuštěny uživatelské relace, ale v době kopírování do IB NEMĚL BY buďte aktivní (vytváření, nahrávání, účtování dokumentů), protože můžete získat nesprávnou kopii.

Vyjmutí databáze 1C v konfigurátoru, kde se vytvoří komprimovaný soubor s příponou dt. V případě potřeby můžete registrační protokol také archivovat samostatně.

Vykládání infobáze

IB spustíme v režimu Konfigurátor:

Spustíme průvodce vyložením IB:

Vyložíme IB, kde uvedeme umístění zálohy:

Po dokončení se objeví zpráva o dokončení vykládky IB:

Po vytvoření kopie je potřeba zkontrolovat (otestovat) výkon dt soubor - načtením IB nejprve vytvořte IB pro testování.

Jak obnovit databázi ze zálohy 1C 8.3

IB spustíme v režimu konfigurátor.

Spustíme průvodce stahováním IB, kde určíme umístění *.dt soubor:

Po obnovení zálohy 1C se objeví upozornění na úspěšné načtení IB a požadavek na restart Konfigurátor:

Při vytváření této metody zálohování je nutné, aby všichni uživatelé tohoto IB ukončili svou relaci.

Další podrobnosti o tom, jak obnovit data z dříve vytvořené záložní kopie, včetně toho, jak obnovit data do existující infobáze nebo nově vytvořené infobáze, najdete v našem videu:

Vytvoření a konfigurace archivu 1C pomocí konfiguračních nástrojů

Automatické zálohování , který je nakonfigurován v uživatelském režimu 1C:Enterprise. Tento režim vytvořili vývojáři v konfiguracích na platformě 1C:Enterprise 8.3 (Enterprise Accounting, rev. 8.3, Payroll and HR, rev. 8.3, Trade Management, rev. 11.2):

Zde můžete:

• Spusťte jednorázovou zálohu:

• Vytvořit rozvrh:

• Obnovení ze zálohy:

Tipy:

• Uchovávejte zálohy na jiných fyzických nebo externích médiích, např pokud selže pevný disk, můžete ztratit samotný IB a jeho kopie.
• Provádějte pravidelné zálohy. Abyste se mohli rozhodnout, jak často potřebujete zálohovat, musíte si odpovědět na otázku: „Jak si vážíte své práce a práce vašich kolegů.“ Čím častěji vytváříte záložní kopie, tím méně úsilí vyžaduje opětovné vkládání dokumentů. Před aktualizací konfigurace však nezapomeňte vytvořit zálohy.

Pokud máte další dotazy, můžete se podívat na naše video, které podrobněji popisuje, jak vytvořit archivní kopii infobáze pomocí samotné technologické platformy v režimu Konfigurátor:

Ohodnoťte tento článek:

Chcete-li se chránit před částečnou nebo úplnou ztrátou dat, před provedením jakýchkoli akcí s vaší informační základnou je nutné zálohovat data v 1C. Pomocí zálohy můžete vrátit databázi do stavu, ve kterém byla v době kopírování.

Ruční vytvoření zálohy 1C

Spouštíme 1C a vybíráme režim konfigurátoru pro vaši infobázi:

Po vstupu do konfigurátoru přejděte do nabídky Správa a vyberte položku „Uvolnit infobázi“

Zobrazí se okno, ve kterém je třeba zadat složku pro ukládání záloh (v mém případě se nazývá Archival copy 1C, můžete si ji pojmenovat, jak chcete), název souboru zálohy (v mém případě BP20082012, první dvě písmena jsou označení názvu infobáze, poté datum uložení, tj. 20. srpna 2012) a klikněte na tlačítko uložit.

Čekáme, až program uloží soubor. Provedení této operace lze sledovat v levém dolním rohu okna konfigurátoru:

Po dokončení program zobrazí následující zprávu:

Záloha byla vytvořena.

Jak obnovit databázi ze zálohy je popsáno v.

Nastavení automatického zálohování v 1C podle plánu

Tato příručka vám pomůže nastavit automatické zálohování. Je vhodný pouze pro souborový režim provozu v databázi 1C. Pro konfiguraci v režimu klient-server doporučuje 1C provádět zálohy pomocí nástrojů DBMS - MS SQL, Postgre atd.

Pro konfiguraci přejděte na záložku "Správa", položka "Podpora a údržba":

Kopie databází si můžete ukládat na svůj počítač nebo na externí pevný disk, dále je možné využít službu 1C Cloud Archive.

K dispozici je zde i funkce ručního spuštění zálohování a obnovy, nás však zajímá položka „Nastavení zálohování“:

Možné možnosti konfigurace jsou naplánovány a na konci práce s programem. Nejlepší ze všeho, zvláště pokud pracujete v základu více než jeden, zvolte možnost „Pravidelně plánováno“. Nastavení je velmi snadné. Na snímku obrazovky jsem nastavil denní rutinu:

Kromě těchto nastavení musíte také určit adresář pro ukládání kopií (nejlépe použít Disk Google nebo Yandex Disk) a kolik záloh uložit:

V tomto návodu se podíváme na to, jak je nakonfigurována základní záloha souboru 1C, jaké existují možnosti zálohování a jak zkontrolovat vytvořenou zálohu.

Tato instrukce je relevantní pouze pro souborové databáze. Pokud máte databázi klient-server, její zálohování musí být nakonfigurováno buď pomocí DBMS () nebo pomocí programů třetích stran.

Jako příklad si vezměme typickou konfiguraci „Enterprise Accounting Edition 3.0“

Nastavení zálohy databáze souborů 1C

Přejděte do nabídky "Správa" - "Údržba":

Rozbalte část „Zálohování a obnovení“.

Zde nás zajímá pole "Způsob zálohování".

Jsou 2 možnosti: a "1C: Cloudový archiv".

Zvažme každou z možností.

1C: Cloudový archiv

Pokud máte předplatné ITS:Prof a nehodláte ho odmítnout, pak doporučuji využít "1C: Cloudový archiv", protože tato služba je pro vás zdarma. Další výhodou cloudového úložiště je, že můžete obnovit databázi, když je počítač fyzicky zničen nebo pokud se vám rozbije pevný disk. Pokud nemáte ITS, přejděte k další části.

Vyberte „1C: cloudová služba“ a klikněte na „Připojit“:

Do formuláře, který se otevře, zadejte své uživatelské jméno a heslo z ITS a klikněte na „Připojit“:

Bude vygenerován dopis technické podpoře, který vám pomůže s registrací.

Pokud neexistuje předplatné ITS:Prof, bude vás cloud stát téměř 1 000 rublů / měsíc. Nyní budeme analyzovat, jak udělat totéž, ale zdarma.

Vyberte možnost „Na místním počítači“ a klikněte na „Nastavení zálohování“:

Zaškrtněte políčko „Provádět automatické zálohování“

Určete adresář pro ukládání záloh. Je lepší, aby to byl samostatný pevný disk. Pokud není k dispozici samostatný pevný disk, zadejte adresář v oddílu disku, kde NENÍ nainstalován systém Windows. Tito. jakákoli jiná než jednotka "C":

Adresář pro ukládání záloh

"Uchovávat zálohy"- zadejte "Posledních 10 kusů", obvykle to stačí a navíc to nezabere mnoho místa na pevném disku:

Ponechte si pouze posledních 10 kopií

Nyní se musíme rozhodnout, jak bude záloha provedena: "Pravidelně naplánováno" nebo .

Při výběru je třeba mít na paměti, že v obou případech budou všichni uživatelé základny 1C „vyhnáni“, aby si mohli vytvořit záložní kopii.

Možnost „Pravidelně plánováno“

Tuto možnost lze vybrat, pokud všichni uživatelé odcházejí ve stejnou dobu, například na oběd nebo čaj.

Poté klikněte na „Jeden den; jednou denně“ a vyberte plán. Například 15 minut poté, co všichni odešli na oběd (pro případ, že by se někdo zpozdil)

V nabídce, která se otevře, zadejte „1“ do pole „Opakovat každý“, abyste získali „Každý den; jednou denně":

Přejděte na kartu „Denně“ a do pole „Čas zahájení“ zadejte čas, kdy chcete vytvořit záložní kopii. Poté klikněte na „OK“:

Výsledek by měl vypadat takto:

Vezměte prosím na vědomí, že v tuto chvíli musí běžet vaše první relace, tzn. odcházíte na oběd, musíte nechat 1s povoleno, aby se vytvořila kopie

Možnost "Při vypnutí"

Tato možnost je pro vás vhodná, pokud opouštíte kancelář jako poslední (nebo alespoň poslední z 1C).

V této možnosti nemusíte nic dodatečně konfigurovat. Jakmile zavřete 1C, systém vám nabídne vytvoření záložní kopie.

Jak funguje záloha při vypnutí?

Když ukončíte 1C, zobrazí se okno „Zálohování nebylo dokončeno při vypnutí“:

Zálohování se při vypnutí nezdařilo

Pokud kliknete na „Vypnout“, 1C se zavře bez zálohy.

Když kliknete na "Pokračovat" v pravém dolním rohu 1C, objeví se následující okno:

Okno s výzvou k vytvoření zálohy

Kliknutím na něj vyvoláte toto okno:

Spusťte zálohu

Zbývá pouze kliknout na "Dokončit" bez zrušení zaškrtnutí "Provést zálohu". Poté 1C vytvoří záložní kopii a dokončí práci:

Vytvoření zálohy infobáze

Takže to nejdůležitější je hotovo, zálohy se vytvářejí, zbývá automaticky nahrávat kopie do cloudu, aby byla data chráněna před vyšší mocí.

Nahrávání záloh 1C do cloudu

Stáhněte si do počítače jakoukoli aplikaci cloudové služby. Obvykle si vybírají mezi Cloud mail.ru a Yandex.Disk. Pokud vaše zálohy „váží“ méně než 2 GB, pak si můžete vybrat libovolné, pokud zálohy váží více než 2 GB, pak musíte určitě vzít Yandex.Disk. Pokud dáváte přednost nějaké jiné cloudové službě - použijte ji. Hlavní věc je, že tato služba přijímá soubory správné velikosti.

//help.mail.ru/cloud_web/confines

Omezení nahrávaných souborů:

Připraveno! Nastavení základní zálohy souboru 1C je nyní dokončeno.

Kontrola vytvořených záloh 1C

Přejděte do složky s databází a odstraňte soubor "1Cv8.1CD"

Otevřete naposledy vytvořený archiv s kopií databáze a extrahujte soubor v něm obsažený do složky s novou databází:

Extrahování databázového souboru

Přejděte do nové databáze a zkontrolujte, zda tam jsou potřebná data (například čerstvé implementace). Pokud je databáze spuštěna a data jsou na svém místě, pak je vše v pořádku.