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