1C архивиране

данни

Всички повече или по-малко опитни системни администратори и 1C програмисти (особено "предстоящите") знаят, че "никога няма достатъчно резервни копия." Сред администраторите също има поговорка "Системните администратори се делят на тези, които правят архиви и тези, които ще ги правят." Можем да кажем, че постоянното желание да се правят резервни копия преди всяка промяна в системата е знак, че ИТ специалистът е достигнал първоначалното професионално ниво. Можете да го постигнете по два начина: прост - да разберете, че без него няма как и веднага да започнете да ги правите, или, вариант две - да стъпите на утъпкан рейк, да разчитате на надеждна техника и надеждни потребители (нито един от тях не дава 100% гаранция и дори 90%), което ще ви доведе първо до фееричен провал, а след това до първата част - архивиране и пак архивиране☻

backup- превод от английски. "резервно копие", файл, който ви позволява да разположите копие на базата данни в определен момент от време, същността е копие на "работещия" файл на базата данни, компресиран от архиватора.

Защо е необходимо архивиране:

  • Основната цел е възстановяване на базата данни в случай на повреда на сървъра с базата данни или повреда по какъвто и да е начин на работния файл на базата данни.
  • Спомагателна цел е да разположите копия или да възстановите работеща база данни, ако някои данни са били въведени / изтрити в нея, които не са били планирани да бъдат въведени / изтрити (честно казано, в случая на 1C опцията практически не се използва, поради факта, че „влакът е напуснал“, върнете старата версия - ще бъде добавена работа за възстановяване на документи, които вече са заковани).

По правило за архивиране се отделя отделно файлово хранилище, може да има отделен диск на същия сървър (не се препоръчва), отделен сървър с диск или просто външен твърд диск. В големи компании за тезиза целите те купуват специални устройства за съхранение, цели дискови масиви и специално оборудване, което записва данни на тези дискове, пример за това е сглобка:

базата
В по-малките компании това са обикновени сървъри, които са добавили повече дискове или дори един или два външни твърди диска.
данни
Общото правило за архивите е да не се съхраняват на същия сървър като базите данни, добре, в краен случай, на едно и също място, но дискът трябва да е физически различен, в противен случай такъв архив, който се повреди едновременно с базата данни, е безполезен.

Как да направите резервно копие

На първо място, ние гледаме къде съхраняваме данните. В случай на 1C това могат да бъдат две опции:

  • Файлова база: данните се съхраняват в директорията, имаме нужда от файла "*.1CD", който съдържа всички данни.
  • Сървърна база: базата е свързана чрез сървъра 1C:Enterprise и данните се съхраняват на сървъра на СУБД (например MSSQL), файловете също са там, но нямаме директен достъп до тях (в случая на MSSQL файлът има разширение "*.mdf" и къде се съхранява физически - можете да разберете или със специална команда към сървъра на СУБД, или в свойствата на базата данни чрез конзолата за управление на MSSQL ), обаче не се нуждаем от СУБД файловете.

В зависимост от базата избираме една от опциите:

  • Файлова версия на базата:
  • Вариант едно:
  • Изключване на потребителите от базата данни (не можете да прекъсвате връзката през нощта)
  • Копирайте файла 1Cv8.1CD във всяка папка
  • Компресиране на полученото копие с архиватор
  • Преместване на архива в резервното хранилище
  • Втора опция (чрез конфигуратор)*:
  • Отваряне на базата данни в режим "конфигуратор".
  • Изберете "Администриране → Качване на информационна база" от менюто
  • Преместваме получения *.dt файл в резервното хранилище. Dt файлът вече е компресиран, така че архиваторът не е необходим тук.
  • Сървърна версия на базата данни (СУБД на трета страна):
  • Със специална команда принуждаваме СУБД сървъра да ни "даде" резервно копие на файла на базата данни към файла XXXXXX.bak (стандартното разширение за архивиране на MSSQL е "bak").
  • Ние компресираме полученото копие с архиватора. В по-новите версии на MSSQL е възможно да се зададе компресия по време на създаването на bak файла (препоръчително!), така че тази стъпка може да се пропусне.
  • Преместваме архива в резервното хранилище. В новите версии на MSSQL можете веднага да посочите мрежова директория като място за запис (препоръчително!), така че тази стъпка може да бъде пропусната.
  • *-Този метод се използва по-често за прехвърляне на данни от файловата версия към сървърната версия, може да се използва за архивиране на малки бази данни (големите са проблематични за архивиране с този метод). Методът е подходящ за файлови и сървърни версии.

    Характеристика на всяка резервна система е независимо периодично стартиране. За файловата версия и трите точки могат да бъдат изпълнени от специални програми, от които има много, или от скрипт в планировчика (този метод е по-близо до мен), а в сървърната версия командата за архивиране се стартира от самия MSSQL сървър (чрез „планове за поддръжка“).

    Настройка на MSSQL резервни копия

    • Отворете MSSQL Server Management Studio
    • Създайте нов план за поддръжка → Право до възела „Планове за поддръжка“ → Създайте план
      данни
    • Добавяне на графичен резервен блок (плъзгане и пускане на "задача" от левия панел)
      архивиране
    • Кликнете два пъти върху рамката на задачата, за да я отворите, попълнете свойствата:
    • Избор на бази данни за запазване
    • Задайте флага за компресиране на базата данни (Внимание! Това значително намалява трафика и заетото пространство!)
    • Изберете директорията за съхраняване на архиви (съветвам ви незабавно да посочите мрежовия път, резервно хранилище)
      архивиране
    • По желание настройваме регистриране на процеса (вижте бутона на фигурата по-горе), моят регистър се записва в папка и също се получава имейл. поща. Ако трябва да изпратите писмо, първо трябва да конфигурирате съответния компонент и да създадете един оператор.
      архивиране

    Готов. Извършваме проверка на здравето, както следва: точно върху плана → изпълни. След изпълнението на плана: разглеждаме дневника на изпълнението, ясни са файловете, които са се появили в хранилището, както и историята (вдясно върху плана → история). Задължително - поне веднъж за проверка на ефективността на архивирането. Как да го направите - създайте нова празна база, точно до основата → . → възстановяване, задайте мрежовия път към нашия файл XXXXX.bak като източник (можете да копирате пътя от Explorer), променете целевия файл в параметрите (MSSQL ще се опита да замени работещата база данни по подразбиране) с файловете на вашето ново копие - възстановете до копието. Създайте нова база данни на сървъра на 1C:Enterprise; посочете като източник вашето ново копие на MSSQL сървъра; отидете на 1C, добавете базата данни и проверете дали всичко е на мястото си и работи.

    Настройка на резервни копия във файловата версия на базата данни

    архивиране

    данни
  • Готов. Очакваме първото стартиране, за теста можете да стартирате задачата ръчно - надясно - изпълнете.
  • Архивът със скрипта може да бъде изтеглен от връзката. Направете резервни копия, но не забравяйте да спите спокойно, те все още трябва да бъдат проверени, не забравяйте да направите копие от архива веднъж и да проверите неговата ефективност.

    Заключение

    Относно MSSQL: в статията се разглежда само вариант на "пълно" резервно копие. За да се спести място, заето от архиви, се използват "диференциални" копия (само промени) и други опции, но в този случай има някои проблеми с възстановяването - не е необходим един архивен файл, а няколко.

    Има още един нюанс - начинаещите програмисти постоянно се борят с регистрационния файл на транзакциите, който расте и задръства дисковете, моят съвет е, че ако зададете "модела за възстановяване" за базата данни в нейните параметри на "прост" от SQL на "Вие", тогава регистрационният файл на транзакциите ще се използва до минимум и няма да расте.

    Според файла: скриптът може лесно да се добави за изтриване на стари копия, за да не се съхраняват очевидно остарели и следователно безполезни файлове. Можете да добавите собствено копие към друга задача, но на интервали от един месец и да посочите друго хранилище, където да се съхраняват архивите веднъж месечно. И накрая, вместо да копирате и архивирате, можете да посочите командата за стартиране на 1C и запазване чрез конфигуратора за архивиране *.dt (вижте стартиране на 1C в пакетен режим).