Для сайту малого бізнесу резервна копія — це не формальність, а спосіб зменшити наслідки зламу, помилки під час оновлення, збою сервера або пошкодження бази даних. Водночас сама наявність файлу з написом «backup» ще не означає, що сайт вдасться відновити. Важливо продумати, де зберігаються копії, хто має до них доступ і чи перевірялося відновлення на практиці.
Докладніше про роль резервування можна прочитати у матеріалі Резервні копії сайту: чому вони рятують бізнес.
Що означає правило 3-2-1
Правило 3-2-1 передбачає:
- щонайменше три екземпляри важливих даних;
- зберігання їх на двох різних типах носіїв або в різних середовищах;
- одну копію в іншому фізичному місці, окремо від основного сервера.
Для сайту це може виглядати так: робочі файли та база даних розміщені на хостингу, одна резервна копія зберігається на окремому диску або іншому сервері, а ще одна — у віддаленому хмарному сховищі. Якщо сайт заразиться вірусом, сервер вийде з ладу або обліковий запис буде скомпрометований, усі копії не повинні постраждати одночасно.
Звичайне дублювання даних у тій самій панелі хостингу не завжди відповідає правилу 3-2-1. Наприклад, резервна копія в тій самій директорії або на тому самому сервері може бути видалена разом із сайтом. Перед налаштуванням резервування варто визначити, які дані критичні: файли WordPress, база даних, завантаження, конфігураційні файли, електронні листи та налаштування DNS.
Локальна й віддалена копія
Локальна копія дає змогу швидко отримати доступ до файлів без завантаження великих обсягів даних через інтернет. Її можна зберігати на окремому комп’ютері, мережевому сховищі або зовнішньому диску. Проте такий носій не варто постійно залишати підключеним до робочої системи: шкідливе програмне забезпечення або помилка користувача можуть пошкодити й оригінал, і копію.
Віддалене сховище захищає від фізичних проблем у місці розташування сервера: пожежі, затоплення, крадіжки обладнання чи тривалого збою дата-центру. Для нього важливі надійність провайдера, історія версій, обмеження доступу та зрозумілий порядок відновлення.
Безпечна схема зазвичай включає:
- автоматичну копію файлів сайту;
- окреме резервування бази даних;
- періодичне повне резервування перед великими оновленнями;
- копію поза основним хостингом;
- збереження кількох попередніх версій, а не лише останнього архіву.
Перед перенесенням резервних файлів, зміною прав доступу або очищенням старих архівів спочатку переконайтеся, що актуальна копія справді існує та відкривається. Видалення або перезапис є незворотними діями, тому поспішати з очищенням сховища небезпечно.
Частота резервування
Частоту копіювання потрібно визначати не за зручністю адміністратора, а за тим, скільки даних бізнес готовий втратити у разі збою. Якщо на сайті щодня надходять замовлення, працює інтернет-магазин або регулярно публікується контент, щотижневої копії може бути недостатньо.
Орієнтовний підхід:
- для сайту-візитки з рідкісними змінами — повна копія раз на тиждень або після важливих оновлень;
- для корпоративного сайту з регулярними публікаціями — щоденне резервування бази даних і періодичне копіювання файлів;
- для інтернет-магазину — частіші копії бази даних, оскільки в ній зберігаються замовлення, клієнти та товари;
- перед оновленням WordPress, теми, плагінів або версії PHP — окрема контрольна копія.
Автоматизація зменшує ризик людської помилки, але не усуває його повністю. Завдання резервного копіювання може завершуватися формально успішно, хоча архів буде неповним, пошкодженим або створеним без бази даних. Тому повідомлення про статус потрібно переглядати, а не лише налаштувати процес один раз.
Якщо сайт уже працює нестабільно, не запускайте масові оновлення та не видаляйте підозрілі файли до створення доступної копії. У разі зараження резервування змінених файлів може зберегти шкідливий код, тому інколи потрібен аналіз копій за датами та перевірка їхньої чистоти.
Шифрування та доступи
Резервні копії часто містять більше інформації, ніж відкрито видно на сайті: паролі у конфігураціях, дані клієнтів, замовлення, службові ключі та персональні відомості. Якщо архів зберігається без захисту, його викрадення може створити не меншу проблему, ніж злам самого сайту.
Для захисту резервів варто:
- шифрувати архіви або використовувати сховище з вбудрованим шифруванням;
- застосовувати унікальні складні паролі та двофакторну автентифікацію;
- не використовувати один пароль для хостингу, пошти й резервного сховища;
- обмежити кількість адміністраторів, які можуть читати, завантажувати або видаляти копії;
- зберігати ключі шифрування окремо від архівів;
- перевіряти журнали входів і сповіщення про підозрілу активність.
Надмірно широкі права доступу підвищують ризик випадкового видалення або крадіжки даних. Водночас надто суворі обмеження можуть перешкодити відновленню в аварійній ситуації. Потрібно заздалегідь перевірити, чи має відповідальна особа всі необхідні доступи, але не більше, ніж потрібно для її роботи.
Паролі та ключі не слід передавати у відкритих листах або зберігати у загальнодоступних документах. Якщо доступи вже могли потрапити до сторонніх осіб, спершу зробіть контрольну копію, а потім змініть паролі, відкличте старі токени й перевірте активні сесії.
Перевірка відновлення
Найслабше місце багатьох систем резервування — відсутність тестового відновлення. Архів може мати правильний розмір, але містити пошкоджену базу даних, неповний набір файлів або конфігурацію, яка не сумісна з поточним сервером.
Перевірку краще проводити не на робочому сайті, а на тестовому домені або окремому середовищі. Безпечна послідовність може бути такою:
- визначити дату й джерело резервної копії;
- завантажити архів та перевірити його цілісність;
- розгорнути копію на окремому сервері або локальному середовищі;
- імпортувати базу даних і підключити файли сайту;
- перевірити авторизацію, сторінки, форми, пошук, замовлення та медіафайли;
- переконатися, що посилання й налаштування не ведуть випадково на робочі дані;
- зафіксувати інструкцію та час, необхідний для відновлення.
Не варто відновлювати резервну копію поверх працюючого сайту без розуміння наслідків. Така дія може видалити нові замовлення, коментарі або зміни в контенті. Перед нею необхідно створити ще одну актуальну копію поточного стану, навіть якщо сайт уже має помилки.
Допомога спеціаліста потрібна, якщо відсутній доступ до панелі хостингу, пошкоджена база даних, сайт заражений, резерви суперечать один одному або після відновлення з’являються помилки сервера. У таких випадках важливо не перезаписувати оригінальні файли та не виконувати випадкові SQL-команди без резерву: неправильні дії можуть ускладнити діагностику й збільшити ризик втрати даних.