Какой должна быть система резервного копирования?

Парашютисты бывают разные.
Одни ходят в школу парашютного спорта и приземляются лицом к ветру и на обе ноги.
Другие делают все то же самое, но парашют у них дырявый. Третьи и вовсе прыгают без парашюта. На что они надеются? Наверное, на то, что в полете у них отрастут крылья за спиной, их подхватит дракон или гигантский орел.
Почему-то когда речь заходит о резервном копировании сайта (которое все равно что парашют), владельцы сайтов превращаются в этих третьих: система бэкапа у них либо “есть какая-то”, либо отсутствует вообще. А между тем статистика неумолима: от 25 до 45% компаний закрываются после масштабной потери данных (cmitsolutions.com).
Как из-за собственной беспечности или незнания не остаться без сайта, денег и перспектив, мы и расскажем.
Мы убеждены, что правил резервного копирования всего два. Они очень простые.

Правило №1. Система резервного копирования должна быть многоуровневой.
Правило №2. Чем сложнее проект, тем сложнее система резервного копирования.


Часто владельцы сайта ограничиваются тем, что создают лишь одну резервную копию, которая хранится на сервере, или полагаются на систему резервного копирования хостинга.
Почему так делать не стоит? Расскажем 3 истории из жизни.

История первая, трагическая
Один наш клиент — строительная компания — потерял пароль от почты, на которую был зарегистрирован сайт и хостинг. Завел новую, изменил адрес в настройках сайта, а про хостинг забыл,пока однажды сайт не упал. Проблему заметили лишь через месяц (почему так поздно — другой вопрос). Стали разбираться. Оказалось, на старую почту приходили напоминания от хостинга с просьбой оплатить услуги. Реакции не последовало, сайт выключили и удалили. Вместе с бэкапами – как и положено, через 30 дней. Других копий не было, восстановить сайт не удалось.

История вторая, поучительная
Однажды на один интернет-магазин торгового оборудования свалился госзаказ. Работы — на полгода. От счастья про сайт и забыли, а когда работы по тендеру закончились, естественно, захотели работу интернет-магазина возобновить. И тут выяснилось, что хостинг заблокирован, сайт удален и резервной копии нет. У владельцев сайта ее тем более не оказалось.
К счастью при установке сайта наши специалисты настроили резервное копирование в облако 1С-Битрикс и в архивах службы поддержки нашелся отчет об установке сайта, в котором сохранился лицензионный ключ и пароль шифрования резервной копии. Сайт восстановили, а клиент задумался о многоуровневой системе резервного копирования.


История третья, печальная
В 2014 году в одном известном российском data-центре случилась авария. Когда сервера подняли, выяснилось, что файловое хранилище вместе с резервными копиями сгинуло в никуда. Жаловаться бессмысленно.
Спасло облако 1С-Битрикс, в котором хранилась устаревшая версия базы данных, файлы разработчика и код с dev-сервера. Собирали сайт буквально по кусочкам и в итоге восстановили его за 2-3 дня. Все это время интернет-магазин, конечно, не работал, терял прибыль и лояльность посетителей.

Мораль у всех трех историй одна: если у вас нет правильной системы резервного копирования, рано или поздно произойдет катастрофа. Вы останетесь без сайта, бизнес будет терять деньги и клиентов.
Какой же должна быть система резервного копирования? Зависит от вашего проекта. Мы в «Аспро» обычно даем следующие рекомендации.


Если у вас корпоративный сайт
Используем двухуровневую систему копирования: 2-3 резервных копии хранятся на сервере, еще 2-3 — в облаке 1С-Битрикс.
Как часто бэкапить: ежедневно или раз в 2-3 дня в зависимости от того, как часто вы обновляете сайт.

Если у вас интернет-магазин
Потребуется усложненная система резервного копирования и ежедневного бэкапа, в том числе и в облако.


Рекомендуется:

1. Настроить стандартное ежедневное резервное копирование средствами 1С-Битрикс и передачу архива в облако.
2. Настроить резервное копирование средствами хостинг-площадки в отдельное хранилище (например удаленный FTP-сервер)
3. Обеспечить ежедневную передачу резервных копий в локальную сеть предприятия, частное облаков или на собственный сервер резервного копирования. При необходимости создать такой сервис вам помогут в специализированной компании. Главное: данные физически должны быть на вашей территории!
4. Разработать план восстановления и инструкцию на случай аварии. Очень важно проверять работоспособность этой инструкции ежемесячно. Для этого достаточно восстанавливать копию на тестовой площадке.
   

Для крупных проектов
Под «крупными» мы понимаем интернет-магазины с количеством заявок от 50-100 в день и с оборотом более 1 миллиона рублей в месяц. Общие правила те же, что и для интернет-магазинов из предыдущего пункта. Однако
Что дополнительно необходимо в этом случае:

1. Система контроля версий как дополнительный источник резервных копий программного кода (защита от человеческого фактора и ошибок программистов).
2. Распределенный сервер баз данных с мгновенной репликацией.
3. Готовый резервный сервер — на стороне разработчика или на территории заказчика. Поможет в экстренной ситуации перебросить трафик и не допустить падения сайта. Рекомендуем использовать отказоустойчивый кластер.
   

Emergency kit
Когда сайт падает, вместе с ним становятся недоступны самые важные данные для его восстановления. На случай аварийных ситуаций рекомендуем иметь под рукой логины и пароли для доступа к хостингу и сайту, ключ к зашифрованной копии, хранящейся в облаке, и номер ключа к 1С-Битрикс. Заполните и распечатайте эту таблицу, храните в укромном месте (или наоборот) — это и будет ваш emergency kit на случай аварийных ситуаций.
Скачать таблицу в формате .docx или .pdf.