1С Бекапи

Всім більш-менш досвідченим системним адміністраторам і програмістам 1С (особливо "приходять") відомо що "бекапів мало не буває". Серед адміністраторів також висловлюється "Системні адміністратори діляться на тих хто робить бикапи і на тих хто їх робитиме". Можна сказати, що постійна тяга робити бекапи перед будь-якою зміною в системі - ознака того, що it-фахівець досяг початково-професійного рівня. Досягнути можна його двома шляхами: простий - зрозуміти що без цього ніяк і відразу почати їх робити, або, варіант два - наступити на побиті граблі, сподіваються на надійне обладнання та надійних користувачів (ні те ні інше не дає 100% гарантій і навіть 90% ), що і приведе вас спочатку до феєричного провалу, а потім до першої частини - бекапит і ще раз бекапит ☻

backup- у перекладі англ. "Резервна копія", файл який дозволяє розгорнути копію бази на певний момент часу, суть - стиснута архіватором копія "робочого" файлу бази даних.

Навіщо потрібен бекап:

Основне призначення - відновлення бази у разі поломки сервера з базою чи пошкодження будь-яким способом робочого файлу бази.
Допоміжне призначення - розгортати копії, або відновлення працездатної бази у разі якщо в неї внесли\стерли якісь дані, які не планувалося внести\стерти (визнатися, у випадку з 1С, варіант практично не використовується, тому що "поїзд пішов" , повернете стару версію - додасться робота з відновлення документів, які вже встигли набити).

Як правило, для бекапів виділяють окреме файлове сховище, може бути окремий диск на цьому ж сервері (не рекомендується), окремий сервер з диском або просто зовнішній жорсткий диск. У великих компаніях для цихцілей закуповують спеціальні пристрої зберігання, цілі дискові масиви та спеціальне обладнання, яке пише дані на ці диски, приклад такого в зборі:

У менших компаніях це звичайні сервери, на які додали побільше дисків або взагалі один- два зовнішні HDD.

Загальне правило для бекапів - не зберігати їх на тому ж сервері як і бази даних, ну на крайній випадок там же, але диск фізично повинен бути іншим, інакше гріш ціна такому бекапу, який ламається одночасно з базою.

Як зробити бекап

Насамперед дивимося де у нас зберігаються дані. У випадку з 1С це може бути два варіанти:

База файлова: дані зберігаються в каталозі, нам потрібен файл "*.1CD", який містить всі дані.
База серверна: база підключена через сервер 1С:Підприємства, а дані зберігаються на сервері СУБД (наприклад MSSQL), файли там теж є, але прямого доступу до них ми не маємо (у випадку з MSSQL файл має розширення) *.mdf", а де зберігається фізично - можна дізнатися або спеціальною командою до сервера СУБД або у властивостях бази через консоль управління MSSQL), проте файли СУБД нам і не потрібні.

Залежно від того яка база вибираємо один із варіантів:

Файловий варіант бази:

Варіант перший:

Відключаємо користувачів від бази (вночі можна і не вимикати)
Копіюємо файл 1Cv8.1CD в будь-яку папку
Стискаємо отриману копію архіватором
Переміщуємо архів у сховище бекапів

Другий варіант (через конфігуратор)*:

Відкриваємо базу у режимі "конфігуратор"

Вибираємо в меню "Адміністрування → Вивантажити інформаційну базу"

Переміщуємо отриманий файл *.dt у сховище бекапів. Файл dt вже стислий, тому архіватор тут не потрібний.

Серверний варіант бази (стороння СУБД):

Спеціальною командою змушуємо сервер СУБД "віддати" нам резервну копію файлу БД у файл ХХХХХ.bak (стандартне розширення для бекапів MSSQL "bak").

Стискаємо отриману копію архіватором. У нових версіях MSSQL можна встановити стиснення в момент створення файлу bak (рекомендується!), тому цей крок можна пропустити.

Переміщуємо архів у сховище бекапів. У нових версіях MSSQL можна як місце збереження одразу вказати мережевий каталог (рекомендується!), тому цей крок можна пропустити.

*-Цей спосіб використовується частіше для перенесення даних з файлового варіанта в серверний, можна використовувати для бекапу дрібних баз (великі таким способом бекапит проблематично). Спосіб підходить для файлового та серверного варіанту.

Особливість будь-якої системи резервного копіювання – самостійний періодичний запуск. Для файлового варіанта всі три пункти можуть бути виконані спеціальними програмами, яких багато, або скриптом у планувальнику (мені ближче цей спосіб), а в серверному варіанті команду резервного копіювання запускає сам сервер MSSQL (через "плани обслуговування").

Налаштування бекапів MSSQL

Відкриваємо MSSQL Server Management Studio
Створюємо новий план обслуговування → Правою на вузол "Плани обслуговування" → Створити план
Додаємо графічний блок резервного копіювання (перетягуємо мишею "завдання" з панелі зліва)
Подвійним кліком по рамці завдання відкриваємо її, заповнюємо властивості:
Вибираємо бази, які повинні зберігатися
Встановлюємо прапор стиснення баз (Увага! Це значно знижує трафік та місце!)
Вибираємо каталог зберігання бекапів (Раджу вказувати відразу мережевий шлях, сховище бекапів)
За бажанням налаштовуємо логування процесу (кнопку див. на рис. вище), у мене лог зберігається в папку, а також надходить лист на ел. пошту. Якщо треба надсилати листа, то треба налаштувати відповідний компонент і створити попередньо одного оператора.

Готово. Перевірку працездатності виконуємо так: правою на план → виконати. Після виконання плану: дивимося лог виконання, зрозуміло файли які з'явилися в сховищі, а також історію (праворуч на план → історія). Обов'язково – хоча б один раз перевірити працездатність резервної копії. Як зробити - створюємо нову порожню базу, праву на базу → . → відновити, як джерело задаємо мережевий шлях до нашого файлу ХХХХХ.bak (можна скопіювати шлях із провідника), змінюємо у параметрах цільовий файл (за умовчанням MSSQL спробує замінити робочу базу) на файли вашої нової копії – відновлюємо копію. На сервері 1С:Підприємство створюєте нову базу; вказуєте як джерело свою свіжу копію на сервері MSSQL; заходьте в 1С, додаєте базу, і перевіряєте, що все на місці і працює.

Налаштування бекапів у файловому варіанті бази

Готово. Чекаємо на перший запуск, для тесту можна запустити завдання вручну - правою - виконати.

Архів зі скриптом можна завантажити за посиланням. Робіть бекапи, але пам'ятайте, щоб спати спокійно, їх ще треба перевіряти, обов'язково підніміть одноразово копію з бекапу і перевірте її працездатність.

Висновок

За MSSQL: у статті розглянуто лише варіант "повної" резервної копії. Для економії місця займаного бекапами використовують "різносні" копії (тільки зміни) та інші варіанти, але в цьому випадку є свої проблеми з відновленням - потрібно не один файл бекапу, а кілька.

Є ще один нюанс - програмісти-початківці постійно борються з файлом журналу транзакцій, який розростається і забиває диски, моя порада - якщо з SQL на "Ви" поставте для бази "модель відновлення" в її параметрах в "проста", тоді журнал транзакцій буде використовуватися за мінімумом і не зростатиме.

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