Это горящий дата центр крупнейшего хостинг провайдера Европы - OVH. После пожара некоторые проекты так и не восстановились, другие долго зализывали раны. И чтобы такого не произошло - надо делать регулярные резервные копии. О том как, с какой периодичностью и что в них включать мы сегодня и поговорим.

Все, что написано ниже - это опыт нашей компании. Постарался писать как можно меньше теории и сосредоточится на практике и личном опыте. Если есть что добавить или хотите подискутировать - велком в комментарии или в личку (контакты в профиле).

Зачем нужны резервные копии?

Самый очевидный - это ситуация на фото. Дата центры в последнее время часто выходят из строя. Нет, это не значит, что они стали менее надежными. Просто их стало больше и такие случае чаще попадают в новостные ленты. У нас были и более экзотические варианты. Например, однажды мы потеряли проект клиента, т.к. владельцы хостинга разругались друг с другом и один из них пришел в дата центр, все вырубил и унес все сервера. Как вы, наверное, догадались, файлы забрать нам не дали. Проект мы быстро восстановили из резервок.

Вирусы, трояны, бэкдоры. В последнее время это самая частая ситуация, когда мы используем резервные копии. Особенно на фоне известных событий. В последнее время вирусы часто удаляют все файлы и сайт в том состоянии, что есть, восстановлению не подлежит. поэтому без резервной копии тут не обойтись.

Ошибка разработчика. Например, не учли некоторые моменты при создании синхронизации и грохнули доп поля у всех товаров. Или, например, “срочные” правки на бою удаляют статус у части заказов и весь сервис синхронизации заказов сыпется как карточный домик. В таких случаях быстрый откат базы из резервки спасает ситуацию. Все мы люди и у нас такие случаи тоже бывают, поэтому резервки есть всегда, даже если на проекте работает кто-то из топ разработчиков.

Резервка дает возможность быстро поднять проект локально. Пожалуй, это самое неочевидное преимущество резервной копии. Резервка - это всегда запакованный сайт и это дает возможность быстро скачать необходимые данные и поднять проект локально. На некоторых проектах, мы делаем такие манипуляции на автомате, оборачивая это в Vagrant, что дает возможность разработчику быстро поднять локальную копию сайта из последней резервной копии без лишних танцев с бубном. “Быстрое”, конечно, понятие относительно и если разраб уехал в глухую деревню, где у него только 3g интернет и тот ловит с базовой станции из соседнего села, то поднимет он ее только когда выйдет на пенсию.

Где хранить резервные копии?

Есть много вариантов хранения. Мы остановились на облаках для личного использования (яндекс диск, cloud.mail.ru, дропбокс и прочие подобные сервисы). Посудите сами, стоимость терабайта от 2000 рублей и никаких дополнительных платежей за трафик, коннекты и пр. Сервис подбираем исходя из потребностей клиента, иногда даже бесплатного аккаунта хватает.

Кратко про альтернативным варианты:

• Резервные копии от хостера. Мало того, что инфраструктура для хранения бэкапов принадлежит той же компании, так еще и хранятся они обычно в том же дата центре, что и ваш основной сайт, поэтому в случае проблем вы потеряете и сайт и резервки.

• Облака для бизнеса. Это всякого рода AWS и прочие Яндекс облака. Сейчас такое не делает только ленивый. В целом, это дорого, очень сложная тарификация и они, откровенно, не для этого.

• Сервер в другом дата центре. Вполне рабочий вариант для большого проекта. Проигрывает облакам в стоимости хранения, но выигрывает в гибкости и скорости создания бэкапов. Например, на втором сервере можно настроить реплику базы и уже с нее делать копии с любой периодичностью. Заодно можно держать на этом сервере активное зеркало.

• Место в облаке Битрикс. В Битриксе есть облачный бэкап и если у вас есть активная лицензия, то у вас есть инструмент и место хранения (от 2 до 10 Гб в зависимости от лицензии). Расширить это место нельзя (узнавал у поддержки). Места откровенно мало, бэкап и восстановление только стандартными средствами. Есть ряд клиентов которые этим пользуются, но больше одной резервной копии туда положить сложно.

Что и как хранить?

На самом деле с составом копий не все так просто.

База данных. Мы обычно работаем с mysql и там практически всегда забывают включить хранимые процедуры в бэкпап, тк по умолчанию утилита mysqldump этого не делает. Не на каждом проекте есть хранимки, но об этом нужно помнить.

Копию базы данных нужно хранить отдельно от файлов, а не пихать ее в один архив с файлами сайта, как часто делают. Если на сервере несколько баз, то каждая база должна лежать в отдельном архиве, т.к. чаще всего разработчики “ломают” именно данные и копия базы нужна чаще, чем копия файлов.

Файлы. Если на хостинге/сервере много сайтов, то каждый сайт должен быть в отдельном архиве (включая отдельные архивы для dev и stage серверов). Для интернет магазинов и разного рода фэшн сайтов лучше выделять медийку (картинки, видео) в отдельный архив, т.к. они реже нужны для восстановления и в случае аварии архив с кодом в таком случае скачается быстрее.

Cron скрипты. На сложных проектах в кроне, как правило, не один вызов. И при потере сервера восстановить все крон скрипты очень сложно, а иногда невозможно. Поэтому cron всегда должен быть включен в резервные копии. Да, мы знаем что такое crunz и аналоги, но к нам часто приходят уже готовые проекты на поддержку и приходится работать с тем что есть, а уже потом рефакторить.

Прочие скрипты и настройки. У нас чаще всего это конфиги для supervisord и sphinx. Их достаточно бэкапить раз в месяц, либо держать копию в гите.

Частота резервных копий зависит от проекта. Наша стандартная схема: 7 дневных копий базы данных и еженедельные резервные копии файлов за 60 дней. В еженедельные копии файлов мы также подливаем и базу (база и архивы файлов даже в этом случае хранятся отдельно согласно рекомендациям выше). Такой схемы вполне хватает для основных сценариев восстановления. Резервные копии создаем в часы минимальной нагрузки на сервер, как правило, это час ночи по серверному времени (нужно учитывать часовой пояс основной аудитории проекта).

Резервные копии всегда создаются перед деплоем и в любой ситуации, когда есть большая вероятность уронить проект клиента, например, перед обновлением Битрикса. Такие резервные копии создаются по запросу менеджера или разработчика проекта.

Как делать?

Для клиентов компании используем свои скрипты, которые делают все вещи, описанные выше, и заливают копию в подготовленное хранилище. Заодно отправляют уведомления в телеграм со служебной информацией и статусом бэкапа. Решение подходит только для серверов и VDS. На обычном хостинге его не запустить. В целом в наших скриптах нет ничего сложного и костяк решения гуглится по запросу "webdav резервные копии бесплатно и без смс".

Для популярных CMS есть отдельные решения, которые делают почти то же самое. Например, для Битрикс мы иногда используем ammina.backup (не реклама). В целом модуль работает стабильно, но не на каждом хостинге. Не работает, как правило, из-за ограничений хостинга на потребляемые ресурсы. Смена тарифного плана на более дорогой снимает ограничение и заставляет его работать.

Под другие CMS тоже есть подобные решения, но опыта работы с ними у нас не было, поэтому если накидаете в комментариях рабочие и проверенные варианты - буду благодарен.

Проверил и забыл?

Еще один момент о котором все забывают. Резервные копии необходимо проверять. Мы это делаем регулярно раз в неделю для каждого клиента.

Основные проблемы, которые возникают при проверках:

• Проблемы с сетью на стороне сервера. Практически не прогнозируется. Бэкап не улетает в облако.

• Перегруз сервера по ресурсам (низкая скорость отклика дисков, низкая производительность сервера) и, как следствие, зависание скрипта создания копии. Прогнозированию не поддается, можно только смириться и проверять.

• Закончилось свободное место на сервере клиента (подрос объем сайта, кеш какого-либо компонента распух и его надо почистить, логи клиентских скриптов или сервера распухли и начали заниматься много места и пр.). Как следствие, не хватает пространства для создания копии и все падает. Решается мониторингом сервера и алертами админам. Мы это реализуем на базе Prometheus и Grafana.

• Закончилось место в облачном хранилище. Как правило, это следствие предыдущего пункта. Так же мониторим в Prometheus.

Вместо заключения

Все что описано выше подойдет для интернет проектов, включая разного рода CRM системы, самописы и прочие “битриксы”, стоящие на сервере с объемом данных до 500-700 Гб. Все что ближе к терабайту просто так не резервируется и там уже нужны другие подходы.