Płatnik, Optima і Subiekt після аварії бази — чого не робити перед діагностикою

Якщо після виходу з ладу комп'ютера, сервера або диска бухгалтерська програма раптово не відкриває базу, найгірші рішення зазвичай приймаються в перші хвилини. У компанії зростає тиск часу, і хтось хоче «тільки запустити систему». На тлі цього з’являються ідеї швидкого ремонту, безсистемного копіювання файлів MDB/MDF або відновлення середовища без перевірки, що насправді пошкоджено.

Коли проблема здається аварією програми, а насправді починається з носія

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

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

Чого не слід робити перед діагностикою

• Не запускайте CHKDSK або інші засоби ремонту файлової системи на носії з базою.
• Не копіюйте файли бази "на пробу" між пошкодженим та новим середовищем.
• Не оновлюйте бухгалтерську програму, якщо немає підтвердження, що база та носій узгоджені.
• Не відновлюйте резервну копію на той самий пошкоджений диск, щоб "перевірити, чи встане".
• Не запускайте багато спроб attach/repair на тій самій базі, якщо джерело проблеми може бути в диску або SQL.

Як зібрати інформацію, потрібну для сенсовної діагностики

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

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

Симптоми, які свідчать про проблему з диском або середовищем

Якщо, крім помилки програми, з'являються RAW, зникаючі томи, помилки CRC, незвичайні звуки HDD або повідомлення про ремонт файлової системи, спершу інцидент слід розглядати як проблему з носієм. У таких випадках паралельно корисні матеріали про аварії диска з бухгалтерськими даними та перші 24 години після збою сервера або NAS.

Резервне копіювання – це не все, якщо ти не знаєш, чи воно консистентне

У багатьох компаніях існує переконання, що раз «у нас є копія», то можна відразу відновлювати середовище. Проблема в тому, що після аварії диска або сервера резервна копія може бути неповною, застарілою або логічно неконсистентною. Це особливо стосується випадків, коли копії робилися під час роботи програми або без тесту відновлення.

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

Як виглядає безпечний B2B-шлях після такого інциденту

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

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

Часті запитання перед контактом

Чи можна відновити базу, якщо програма перестала відкриватися після перезапуску?

Так, але спершу потрібно з’ясувати, чи проблема стосується самої бази, файлової системи, диска чи SQL Server. Без цієї діагностики легко погіршити ситуацію.

Чи можна відразу відновити резервну копію?

Так, лише якщо ви впевнені, що копія є узгодженою і що відновлюєте її поза пошкодженим середовищем. Інакше можна витратити час і перезаписати важливі сліди.

Коли потрібна NDA?

У B2B середовищах з бухгалтерськими, кадровими даними або даними клієнтів варто визначити це ще до передачі носія або робочої копії.

Коли переходити від аналізу до подання справи

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