Резервное копирование данных интернет-магазина: стратегия бэкапа баз данных, файлов и конфигураций с хранением в другом регионе
I. Почему нельзя «просто забэкапить весь диск целиком»
Многие владельцы сайтов выбирают стратегию «каждый день упаковывать весь сервер и сохранять». Звучит надёжно, но на практике есть три проблемы.
Во-первых, полный архив слишком большой, одно резервное копирование занимает несколько часов, а инкрементальный бэкап сделать детально невозможно. Во-вторых, частота изменений у трёх типов активов кардинально различается: база данных меняется каждый час, файлы — время от времени, конфигурации — месяцами не трогаются. Использовать одну частоту для всех — значит либо тратить ресурсы впустую, либо бэкапить недостаточно. В-третьих, при восстановлении из полного архива вместе с сайтом восстанавливаются мусорные файлы и взломанный код — то есть вы восстанавливаете и саму аварию.
Контринтуитивный вывод здесь такой:Ценность бэкапа определяется не тем, «сколько вы забэкапили», а тем, «можно ли восстановить и как быстро». Я видел слишком много сайтов с «ежедневным бэкапом», которые в день падения сервера обнаруживали, что файлы бэкапа повреждены, пароли неизвестны, а копия в другом регионе ни разу не загрузилась успешно.
Критерий приёмки стратегии бэкапа только один: взять этот бэкап, развернуть на совершенно новой машине и запустить сайт за 4 часа. Именно поэтому Бэкап и восстановление сайта подчёркивает «проверку возможности восстановления».
| Тип актива | Что входит | Частота изменений | Последствия пропуска бэкапа |
|---|---|---|---|
| База данных | Заказы, заявки, пользователи, таблицы контента | Ежечасно | Потеря транзакций и данных клиентов |
| Документ | Загрузки пользователей, изображения, вложения, медиа | Ежедневно | Потеря вложений и изображений товаров |
| Конфигурации / код | Темы, плагины, конфигурация Nginx, переменные окружения | При каждом изменении | После переустановки невозможно воспроизвести исходный сайт |
| Полный архив диска | Всё вышеперечисленное плюс системный мусор | Ежедневно | Слишком большой и медленный, восстановление вместе с заражением |
II. Бэкап базы данных: полный плюс инкрементальный, RPO в пределах 1 часа
База данных — самый важный из трёх типов активов, и потерять её нельзя. Стратегия — «полный плюс инкрементальный»: раз в сутки ночью делаем логический полный бэкап (mysqldump или аналог), включаем binlog для почасового инкремента. В худшем случае потеряем данные только за последний час — этот показатель называется RPO (целевая точка восстановления).
Нужно учесть две детали. Первая: полный бэкап не запускайте в часы пик, ставьте на 3–5 утра. Вторая: файлы бэкапа нужно проверять на целостность, а не просто смотреть, что «файл создался», — выборочно восстанавливайте во временную базу. Иначе бэкап может оказаться битым начиная с какого-то момента. Когда база вырастет, логический бэкап замедлится — тогда переходите на физический бэкап или автоматическое резервное копирование облачной базы.
Пример из практики: В 4 утра в базе случайно удалили таблицу заказов. Порядок восстановления: берём полный бэкап за прошлую ночь, восстанавливаем во временную базу, затем проигрываем binlog с 4 утра вчерашнего дня до момента аварии — и база возвращается к состоянию за минуту до сбоя. Весь процесс занимает около часа, потери минимальны.
| Способ резервного копирования | Частота | RPO | Этап применения |
|---|---|---|---|
| Ежедневный полный логический бэкап | 1 раз в день | Около 24 часов | Менее 5000 посещений в день |
| Полный + инкремент binlog | Полный ежедневно, инкремент ежечасно | ≤ 1 часа | Стандартный вариант для проектов с транзакциями |
| Автоматический бэкап облачной базы | Управляет провайдер | Обычно в пределах 5 минут | Удобный вариант после переезда в облако |
| Репликация master-slave в реальном времени | В реальном времени | близко к 0 | Добавляют при высоких требованиях к доступности |
Три. Файлы и конфигурация: храните отдельно, не смешивайте с бэкапом базы
Файлы (вложения из заявок, изображения товаров, медиа) объёмные и меняются медленно — их не стоит запихивать в ежедневный бэкап базы. Синхронизируйте каталог загрузок в удалённое объектное хранилище отдельным инструментом инкрементальной синхронизации, достаточно раза в день. Как управлять большими файлами вроде картинок и видео, читайте в Управление медиаактивами.
Конфигурацию и код забывают чаще всего. У многих база резервируется отлично, а конфиги Nginx, версии плагинов и переменные окружения разбросаны по серверам — после переустановки непонятно, как всё работало.
Правильный подход: код и конфигурацию — в Git, переменные окружения и ключи — отдельно в менеджер паролей, не в Git. Тогда конфигурация не «бэкапится», а версионируется при каждом изменении, и вы в любой момент откатитесь к любому прошлому состоянию.
| Актив | Инструмент / способ резервного копирования | Частота | Удалённое хранилище |
|---|---|---|---|
| Полный бэкап базы | Автоматический скрипт mysqldump | Каждую ночь | Объектное хранилище в другом регионе |
| Инкремент базы | Архив binlog | Каждый час | Вместе с полным бэкапом в удалённое хранилище |
| Файлы пользователей | Инкрементальная синхронизация в объектное хранилище | Ежедневно | Пишутся сразу в удалённое хранилище |
| Код и конфигурация | Коммит в Git | При каждом изменении | Удалённый репозиторий в облаке |
| Переменные окружения и ключи | Менеджер паролей | Сохраняется при каждом изменении | Зашифрованное хранение в облаке |
Четыре. Удалённое хранилище: как применить принцип 3-2-1
3-2-1 — старое правило резервного копирования, но одиночки часто выполняют только первую половину. Полностью оно звучит так: храните 3 копии данных, на 2 разных носителях, и 1 из них — в другом месте. Смысл «другого места» не в «ещё одном диске», а в том, что оно не погибнет вместе с основным при той же аварии.
На практике для одного облачного сервера это так: на локальном диске — свежая копия (восстанавливается быстрее всего), ещё одна — в дата-центре, где стоит сервер, и третья — в объектном хранилище в другом городе. Снапшоты блочного диска в том же аккаунте и регионе не считаются настоящим удалённым хранением: пожар в дата-центре или блокировка аккаунта — и все копии пропадут разом. Удалённую копию храните не меньше 30 дней, а раз в месяц — долгосрочный архив полугодовой давности, чтобы шифровальщик не зашифровал и старые бэкапы.
Пример из практики: Сервер зашифровал шифровальщик. Локальная копия и копия на сервере зашифрованы, но копия в объектном хранилище в другом городе, которой 30 дней, лежит офлайн — вредоносное ПО до неё не дотянется. Вы восстанавливаете её на новой машине и теряете максимум 30 дней данных, но сайт жив.
В этом и смысл удалённой копии — она нужна не для более быстрого восстановления, а чтобы остаться хоть с чем-то, когда «все онлайн-копии пропали». Как действовать после взлома — см.После взлома сайта.
| Где лежит копия | Носитель | Срок хранения | Что даёт |
|---|---|---|---|
| Локальный диск сервера | Облачный диск | Последние 7 дней | Быстрое повседневное восстановление |
| Объектное хранилище в том же дата-центре | Объектное хранилище | Последние 30 дней | Восстановление при сбое сервера |
| Удалённое объектное хранилище | Бакет в другом регионе | 30 дней + месячный архив | Авария уровня дата-центра или аккаунта |
| Копия на локальный диск | Личный жёсткий диск | Раз в квартал | Подстраховка на случай, если и провайдеру нет доверия |
Пять. Ловушки: четыре самых частых ложных ощущения безопасности при резервном копировании
Первая ловушка — «бэкап на той же машине». Складываете файлы бэкапа в другую папку на сервере — сервер падает или его удаляют, и обе копии пропадают разом. Бэкап обязан покинуть эту машину. Вторая ловушка — «никогда не проверяем восстановление». Скрипт каждый день рапортует об успехе, но восстановление вы ни разу не делали — вполне возможно, что какая-то копия повреждена ещё с полгода назад.
Третья ловушка — «бэкапим данные, но не конфигурацию». Базу восстановили, а какие версии плагинов стояли, как был настроен Nginx — вспомнить не можете, и сайт всё равно не поднимается. Четвёртая ловушка — «у бэкапа нет оповещений». Скрипт резервного копирования тихо отвалился три недели назад, и никто не заметил, пока в день восстановления не выяснилось, что копия пустая. Задача резервного копирования обязана слать оповещение о сбое: два дня подряд без успеха — и вам приходит уведомление.
| Ложное ощущение безопасности | Внешнее проявление | Реальная проблема | Как исправить |
|---|---|---|---|
| Бэкап в другой папке на той же машине | Каждый день появляются файлы бэкапа | Сервер упал — всё пропало | Обязательно хранить копию в другом месте |
| Восстановление никогда не проверяем | Скрипт бэкапа рапортует об успехе | Файл бэкапа может быть повреждён | Раз в квартал проводить учебное восстановление |
| Бэкапим только базу данных | База бэкапится каждый день | Конфигурация и код разбросаны где попало | Конфигурацию — в Git, ключи — в сейф |
| У бэкапа нет оповещений | Три недели никто не замечал | Задача резервного копирования молча падала | Два сбоя подряд — и приходит оповещение |
FAQ: частые вопросы
Как часто нужно делать резервную копию сайта?
В правиле 3-2-1 — насколько далеко должно быть “другое место”?
Зачем нужны учения по восстановлению, если файлы бэкапов уже есть?
Достаточно ли автоматических снимков от облачного провайдера?
Нужно ли бэкапить загруженные пользователями изображения и вложения вместе с базой?
Как скрипт бэкапа узнает, что тихо упал?
В заключение
Резервное копирование — та область, где проще всего обмануть самого себя: скрипт работает, файлы сохраняются, выглядит надёжно. Но настоящая проверка только одна — восстановление. Для одиночного независимого сайта достаточно разделить три типа активов, держать копии по схеме 3-2-1 в другом месте и раз в квартал проводить учебное восстановление. Всё это настраивается за один вечер, а дальше работает автоматически каждый день — раз в неделю достаточно взглянуть на оповещения.
Три шага на практике. Первый: полный бэкап базы данных ежедневно плюс инкрементальный каждый час, целевой RPO — 1 час. Второй: файлы и конфигурацию хранить отдельно — файлы ежедневно синхронизировать в объектное хранилище в другом регионе, код и конфигурацию — в Git. Третий: раз в квартал проводить учебное восстановление с замером времени — уложиться в 4 часа, а к задачам резервного копирования подключить оповещения о сбоях.
После этих трёх шагов перед лицом отказа сервера вы будете не надеяться, что бэкап в порядке, а точно знать, что поднимете сайт за полдня. Ритм обслуживания можно сверить с графиком обслуживания сайта и спланировать вместе.
Запомните одну фразу: резервное копирование — это не просто копия файлов, а страховка для вашего сайта на случай, когда всё придётся начинать заново. Полис, по которому ни разу не было выплат, — просто бумажка.