Резервні копії 1С/BAS на MS SQL: повна, диференційна, журнал

Для чого і кому

Резервні копії бази 1С/BAS на MS SQL складаються з трьох частин: повної копії, диференційної та копії журналу транзакцій. Разом вони визначають, скільки роботи доведеться відтворювати вручну після збою. Як SQL Server влаштовує такі копії, описано в Microsoft Learn: Back up and restore of SQL Server databases.

Інструкція стосується компаній, де 1С/BAS працює в клієнт-серверному режимі на MS SQL Server: на власному сервері, у віртуальній машині або на сервері для 1С/BAS на MS SQL у дата-центрі. Якщо ваша база файлова і SQL Server не використовує, режими й терміни нижче до неї не застосовуються. Керівнику достатньо прочитати цей розділ і розділ про перевірку, адміністратору знадобляться всі.

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

Три типи копій простими словами

Повна копія – це стан усієї бази на момент завершення копіювання, як фотографія. Диференційна містить лише те, що змінилося після останньої повної, і без своєї повної копії не відновлюється. Копія журналу зберігає записи про операції, яких ще немає в попередніх копіях журналу, і дозволяє повернути базу на потрібний момент, скажімо, за п'ять хвилин до помилкового проведення.

Копії журналу доступні не завжди: все залежить від режиму відновлення (recovery model) бази. У простому режимі (simple) їх немає, і зміни після останньої копії при збої втрачаються. У повному (full) копії журналу обов'язкові, зате втрата даних зазвичай мінімальна. За замовчуванням редакції Standard та Enterprise використовують повний режим, а Express простий, тому саме з перевірки режиму варто починати.

Пріоритет

Сьогодні: якщо свіжої копії бази за останню добу немає або вона лежить лише на тому самому сервері, що й база. Цього тижня: перевірити режим відновлення, скласти розклад і зробити перше тестове відновлення. При плановому оновленні сервера або раз на квартал: переглянути розклад, місце зберігання та час відновлення.

Що знадобиться

Потрібен доступ адміністратора до SQL Server, де лежать бази 1С/BAS, і список цих баз. Базу «Бухгалтерія» часто доповнюють окремі бази зарплати, торгівлі чи тестова копія, тож краще звірити список з людиною, яка веде 1С. Окремо потрібне місце для копій: диск, мережева папка або сховище, не пов'язане з диском бази.

Ще знадобляться два рішення від керівництва. Перше: скільки роботи компанія готова втратити (для бухгалтерії це години чи хвилини?). Друге: скільки часу база може бути недоступною. У термінах джерела це відповідно точка (RPO) і час відновлення (RTO). Без цих цифр розклад копій складають навмання.

Для перевірки потрібен окремий сервер або віртуальна машина, куди можна відновити копію, не торкаючись робочої бази. Відновлювати «поверх» бойової бази для тесту не можна.

Якщо немає свого адміністратора

Налаштувати розклад копій і перевірити відновлення може зовнішній спеціаліст, але вирішувати, які втрати допустимі, мусить власник бізнесу. Якщо у вашій компанії немає людини, яка стежить за резервними копіями бази 1С/BAS, це обслуговування можна передати команді TakeIT.

Кроки

Порядок такий, що кожен наступний крок спирається на попередній. Розклад у кроці 2 наведено як приклад для відштовхування, а не як норму: ваші цифри залежать від відповідей керівництва.

1. Визначте режим відновлення кожної бази 1С/BAS. Як переглянути й змінити режим відновлення (recovery model), описано в документації Microsoft SQL Server, у задачі «View or change the recovery model»; серед пов'язаних матеріалів згадано й системне представлення sys.databases. Перевірка: у вас є таблиця «база – режим», і для баз, де потрібне відновлення на момент, стоїть повний режим. Режим можна змінити в будь-який час, тож після зміни перевірте, що розклад копій відповідає новому режиму.
2. Складіть розклад за допустимою втратою даних. Для прикладу: повна копія раз на добу вночі, диференційна кілька разів протягом робочого дня, копія журналу кожні 15–30 хвилин. Чим частіше журнал, тим менше роботи доведеться повторювати. Перевірка: розклад записаний, і керівник підтвердив, що така максимальна втрата його влаштовує.
3. Створіть автоматичні завдання. Для цього зазвичай використовують SQL Server Agent: окреме завдання для повних, диференційних копій і журналу, з іменами файлів, у яких видно базу, тип і час. Перевірка: за добу в історії завдань є успішні запуски кожного типу, а файли з'явилися у цільовій папці.
4. Винесіть копії за межі сервера. Копії на тому ж диску, що й база, не рятують від збою диска чи втрати сервера. Потрібна друга копія в іншому місці: на окремому сховищі, в іншому приміщенні або у віддаленому сховищі. Перевірка: файл вчорашньої копії відкривається з другого місця, а доступ до нього мають лише облікові записи, яким він потрібен.
5. Зробіть тестове відновлення на окремому сервері. Відновіть набір копій, який ви реально створюєте за розкладом (повну, а також диференційну й копії журналу, якщо вони є), за процедурою з документації Microsoft для вашого режиму відновлення; для повного режиму це розділ «Complete database restores (full recovery model)». Перевірка: база піднялась, 1С/BAS підключається до неї, а бухгалтер знаходить у ній документи за останній день і підтверджує, що дані схожі на правду.
6. Налаштуйте сповіщення й контроль. Адміністратор має одержувати листа або повідомлення, коли завдання копіювання завершилося помилкою, а також стежити за розміром журналу та вільним місцем у сховищі. Перевірка: тимчасово зламайте шлях у тестовому завданні й переконайтеся, що сповіщення прийшло.

Як перевірити результат

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

Друга перевірка стосується відновлення на момент часу. Оберіть момент у середині робочого дня і відновіть базу на нього, використавши копії журналу. У повному режимі це можливо, якщо ланцюжок копій без розривів. У простому режимі можна повернутися лише до кінця однієї з копій.

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

Типові помилки

Журнал росте без кінця

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

Копії лежать поруч із базою

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

Відновлення жодного разу не пробували

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

Очікування як у повному режимі, а режим простий

Керівник чекає, що втратиться не більше пів години роботи, а база на Express у простому режимі з однією копією на ніч. Тоді реальна втрата може сягати майже доби. Звіряйте режим і розклад з тим, що ви пообіцяли бізнесу.

Пов'язані бази копіюються окремо

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

Висновок

Почніть з однієї дії на цей тиждень: з'ясуйте, який режим відновлення задано для бази 1С/BAS. Решта (розклад, друге місце зберігання, тестове відновлення) логічно випливає з цієї відповіді та з рішення керівництва про допустиму втрату даних. Копія, яку жодного разу не відновлювали, залишається припущенням, тож запишіть дату першого тесту в календар.