Парашутисти бувають різні.
Одні ходять в школу парашутного спорту і приземляються обличчям до вітру і на обидві ноги.
Інші роблять все те ж саме, але парашут у них дірявий. Треті і зовсім стрибають без парашута. На що вони сподіваються? Напевно, на те, що в польоті у них відростуть крила за спиною, їх підхопить дракон або гігантський орел.
Чомусь коли мова заходить про резервне копіювання сайту (яке все одно що парашут), власники сайтів перетворюються в цих третіх парашутистів: система бекапа у них або "є якась", або відсутня взагалі. А тим часом статистика невблаганна: від 25 до 45% компаній закриваються після масштабної втрати даних (cmitsolutions.com).
Ми переконані, що правил резервного копіювання всього два. Вони дуже прості.
Правило №1. Система резервного копіювання повинна бути багаторівневою.
Правило №2. Чим складніший проект, тим складніша система резервного копіювання.
Чому так робити не варто? Розповімо три історії з життя.
Історія перша, трагічна
Один наш клієнт - будівельна компанія - втратив пароль від пошти, на яку був зареєстрований сайт і хостинг. Завів нову, змінив адресу в налаштуваннях сайту, а про хостинг забув, поки одного разу сайт не впав. Проблему помітили лише через місяць (чому так пізно - інше питання). Почали розбиратися. Виявилося, на стару пошту приходили нагадування від хостингу з проханням оплатити послуги. Реакції не було, сайт вимкнули і видалили. Разом з резервною копією - як і належить, через 30 днів. Інших копій не було, відновити сайт не вдалося.
Історія друга, повчальна
Одного разу на один інтернет-магазин торгового обладнання звалилося держзамовлення. Роботи - на півроку. Від щастя про сайт забули, а коли робота по тендеру закінчилася, природно, вони захотіли роботу інтернет-магазину відновити. І тут з'ясувалося, що хостинг заблокований, сайт вилучений і резервної копії немає. У власників сайту її тим більше не виявилося.
На щастя при установлені сайту наші фахівці налаштували резервне копіювання в хмару СRM Бітрікс24 і в архівах служби підтримки знайшовся звіт про встановлення сайту, в якому зберігся ліцензійний ключ і пароль шифрування резервної копії. Сайт відновили, а клієнт задумався про багаторівневу систему резервного копіювання.
Історія третя, сумна
У 2014 році в одному відомому data-центрі сталася аварія. Коли сервера підняли, з'ясувалося, що файлове сховище разом з резервними копіями зникло. Скаржитися немає сенсу.
Врятувала хмара CRM Бітрікс24, в якій зберігалася застаріла версія бази даних, файли розробника і код з dev-сервера. Збирали сайт буквально по шматочках і в підсумку відновили його за 2-3 дня. Весь цей час інтернет-магазин, звичайно, не працював, втрачав прибуток і лояльність відвідувачів.
Мораль у всіх трьох історій одна: якщо у вас немає правильної системи резервного копіювання, рано чи пізно станеться катастрофа. Ви залишитеся без сайту, бізнес буде втрачати гроші, а ви клієнтів.
Якою ж має бути система резервного копіювання? Залежить від вашого проекту. Ми зазвичай даємо такі рекомендації.
Якщо у вас корпоративний сайт
Використовуємо дворівневу систему копіювання: 2-3 резервних копії зберігаються на сервері, ще 2-3 - в хмарі CRM Бітрікс24.
Як часто бекапити: щодня або раз в 2-3 дня в залежності від того, як часто ви оновлюєте сайт.
Якщо у вас інтернет-магазин
Буде потрібна складна система резервного копіювання та щоденного бекапа, в тому числі і в хмару.
Рекомендується:
-
Налаштувати стандартне щоденне резервне копіювання інструментами "Бітрікс: Управління сайтом" і передачу архіву в хмару.
-
Налаштувати резервне копіювання інструментами хостинг-майданчика в окреме сховище (наприклад віддалений FTP-сервер)
-
Забезпечити щоденну передачу резервних копій в локальну мережу підприємства, приватних хмар або на власний сервер резервного копіювання. При необхідності створити такий сервіс вам допоможуть в спеціалізованій компанії. Головне: дані фізично повинні бути на вашій території!
-
Розробити план відновлення і інструкцію на випадок аварії. Дуже важливо перевіряти працездатність цієї інструкції щомісяця. Для цього достатньо відновлювати копію на тестовому майданчику.
Для великих проектів
Під «великими» ми розуміємо інтернет-магазини з кількістю заявок від 50-100 в день і з оборотом понад 300 000 грн на місяць. Загальні правила ті ж, що і для інтернет-магазинів з попереднього пункту.
Що додатково необхідно зробити в цьому випадку:
-
Система контролю версій як додаткове джерело резервних копій програмного коду (захист від людського фактора і помилок програмістів).
-
Розподілений сервер баз даних з миттєвою репликацією.
-
Готовий резервний сервер - на боці розробника або на території замовника. Допоможе в екстреній ситуації перекинути трафік і не допустити падіння сайту
Emergency kit
Коли сайт падає, разом з ним стають недоступні найважливіші дані для його відновлення. На випадок аварійних ситуацій рекомендуємо мати під рукою логіни і паролі для доступу до хостингу і сайту, ключ до зашифрованої копії, що зберігається в хмарі, і номер ключа до Бітрікс: Управління сайтом. Заповніть і роздрукуйте таблицю, зберігайте її - це і буде ваш emergency kit на випадок аварійних ситуацій.
