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


ChatGPT
Perplexity