Резервне копіювання BAS: як гарантувати збереження даних
База BAS — це серце більшості бізнес-процесів компанії. Бухоблік, зарплата, продажі, склад, закупівлі тощо — все фіксується в обліковій програмі. Втрата цих даних найчастіше призводить до зупинки роботи, фінансових збитків та витрат часу на відновлення.
Саме тому правильна схема резервного копіювання BAS сьогодні — не рекомендація, а необхідність, яка дозволить підприємству продовжити працювати навіть якщо станеться збій чи вірусна атака.
Як часто потрібно створювати резервні копії - від чого це залежить
Оптимальна періодичність резервного копіювання — поняття дуже суб’єктивне. Критеріями слугують:
- кількість одночасно працюючих користувачів;
- та кількість операцій, які ці користувачі виконують протягом робочого дня.
Саме рівень навантаження на систему є ключовим показником, який допоможе визначитися з частотою виконання резервних копій.
Адже якщо в інформаційній базі працює 5–10 користувачів, а дані оновлюються щохвилини, то вимоги до бекапування значно вищі, ніж, наприклад, для малого бізнесу, де з програмою працює одна людина, яка здійснює до 5 операцій на день.
Давайте розглянемо кожен варіант:
Для підприємств, які
активно працюють в базі.
Доцільно створювати резервні копії кілька разів протягом робочого дня.
Це дозволить у разі непередбаченої ситуації втратити лише незначну кількість даних, а отже їх можна буде швидко внести знову.
Для компаній з меншим навантаженням.
Мінімальною рекомендацією є:
- щоденне/щотижневе резервне копіювання (в залежності від активності роботи в базі);
- обов’язкова резервна копія після закриття кожного місяця.
Такий підхід дозволяє завжди мати «контрольну точку» із закритим бухгалтерським періодом і мінімізує ризики втрати вже перевірених даних.
Якщо резервні копії створюються щодня, то підприємство зможе відновити стан бази практично на будь-яку дату останнього тижня. Якщо ж лише раз на тиждень — в разі збою доведеться наново вносити дані за цілий тиждень роботи.
Резервне копіювання SQL і файлових баз
Не останнє значення для бекапування має архітектура роботи з BAS — клієнт-серверна чи файлова.
Про різницю між ними читайте в статті.
Для клієнт-серверної архітектури спеціалісти СОФТКОМ рекомендують використовувати професійну СУБД, таку як Microsoft SQL Server. Вона є однією з найбільш поширених і зручних в роботі з високо навантаженими інформаційними базами. Резервне копіювання для них налаштовується на рівні SQL Server, тобто самої бази, й виконується автоматично в запрограмований вами час.
Що дуже важливо — копіювання можна виконувати без зупинки роботи користувачів!
Періодичність здійснення таких бекапів для SQL баз зазвичай налаштовується:
- раз на 1 годину / раз на 2 години / раз на 4 години;
- та в кінці кожного дня.
У файловому варіанті також можна налаштувати автоматичне резервне копіювання. Однак воно має свої особливості:
- На час створення копії всі користувачі мають вийти з бази. А отже роботу в BAS доведеться призупиняти, якщо копіювання відбувається межах робочих годин компанії.
- Для великих файлових баз процес резервного копіювання може тривати довго — це залежить від розміру бази, потужності ПК/ноутбуку, де розташована база, швидкості інтернету.
- Найчастіше резервні копії створюються поруч із самою базою — на тому ж ПК/ноутбуці. Відповідно для безпеки їх необхідно регулярно переносити на інші носії, а ще краще — до хмарного сховища. Це призводить до того, що кожен бекап — це додаткові витрати часу та коштів, якщо роботи виконує залучений фахівець.
Досвід СОФТКОМ.Незалежно від того наскільки навантажена у вас система, ми рекомендуємо робити резервні копії:
- кожен день протягом шести днів;
- кожен тиждень протягом чотирьох тижнів;
- за поточний місяць;
- за поточний квартал;
- за поточний рік.
Тобто сумарно 13 бекапів.
Така схема дозволяє відновити дані за різні проміжки часу та забезпечує баланс між рівнем захисту й витратами на зберігання бекапів.
Чи варто зберігати більше, ніж 13 резервних копій?
Звичайно, за потреби можна зберігати й більше копій, якщо цього вимагає внутрішня політика безпеки вашої компанії чи бізнес-процеси. Але варто пам’ятати, що кожен бекап — це місце у сховищі. А зі збільшенням їх кількості зростають і витрати на зберігання.
Для прикладу: якщо інформаційна база має обсяг близько 100 ГБ, то одна резервна копія може займати приблизно 50 ГБ. Для зберігання такої бази за 13 копій знадобиться майже 1 терабайт дискового простору.
Тому стратегія резервного копіювання повинна враховувати не лише максимальний рівень захисту, а й економічну доцільність.
допустимими ризиками втрати даних.
Де потрібно зберігати резервні копії
Одна з найбільш поширених помилок — зберігати резервні копії на тому ж сервері, де знаходиться основна база даних.
Тому фахівці СОФТКОМ рекомендують використовувати окремі місця зберігання для бази та бекапів:
- окремий фізичний сервер;
- хмарний сервер;
- поєднання фізичного та хмарного зберігання.
Найкращою практикою є наявність кількох незалежних копій у різних місцях.
Як резюме
- Проаналізуйте рівень навантаження на вашу облікову систему, щоб визначити оптимальну періодичність резервного копіювання саме для вашого бізнесу.
- 6 щоденних;
- 4 щотижневих;
- 1 щомісячна;
- 1 квартальна;
- 1 річна.
- Дотримуйтеся балансу між кількістю бекапів та витратами на їх зберігання. Зберігайте резервні копії окремо від основної бази даних, бажано у незалежному сховищі або хмарі.
- Регулярно перевіряйте можливість відновлення даних із резервних копій.
Якщо ви не впевнені, чи ефективна ваша схема резервного копіювання? Зверніться до фахівців СОФТКОМ. Ми допоможемо оцінити вашу систему, налаштувати автоматичне резервне копіювання та підібрати оптимальну стратегію зберігання даних саме для вашого бізнесу.


ChatGPT
Perplexity