Сколько хранить бэкапы сайта и как часто их делать

График строится из двух чисел: сколько данных не жалко потерять и как быстро надо вернуться в работу. Для сайта услуг это обычно ежедневная копия с хранением 14-30 дней. Для магазина в сезон интервал сокращают до нескольких часов.

Если спросить десять веб-мастеров, как часто и сколько хранить бэкапы сайта, получишь десять разных ответов. Кто-то говорит про ежедневный архив за 7 дней, кто-то про еженедельный за месяц, кто-то выкатывает GFR-схему и пугает аббревиатурами. На практике всё проще, и зависит ровно от двух вещей: сколько данных вы готовы потерять и сколько готовы платить за хранение.

Я веду регламент бэкапов на десятках клиентских проектов. Ниже разложу, какой график реально окупается на маленьком сайте в 2026 году, как считать объём, и как не платить лишнего за то, что никогда не пригодится.

Сначала два вопроса, без которых нельзя считать график

Перед тем как назначать частоту, я задаю клиенту два вопроса.

Сколько данных вам терпимо потерять при аварии. Если бэкап вчерашний, а сегодня вы уже принимали заказы и звонки, в худшем случае пропадёт сегодняшний день. Это окей для блога. Это уже не окей для интернет-магазина с 50 заказами в день.

Эту цифру в индустрии называют RPO, recovery point objective. Целевая точка восстановления. Чем меньше RPO, тем чаще приходится делать бэкапы.

Через сколько после аварии вы должны быть онлайн. Если сайт лежит, и вам нормально вернуться к работе через 8 часов, можно спокойно качать архивы из холодного хранилища. Если простой обходится в 50 тысяч рублей в час, нужен горячий резерв и быстрые медиа.

Эту цифру называют RTO, recovery time objective. Целевое время восстановления.

Для типового сайта услуг малого бизнеса я обычно ставлю RPO 24 часа и RTO 4 часа. Этого достаточно для того, чтобы спать спокойно. Для интернет-магазина в высокий сезон цифры меньше: RPO 4 часа, RTO 1 час.

Дедушка-отец-сын простыми словами

Классическая схема ротации, придуманная ещё в эпоху ленточных накопителей и всё ещё рабочая.

Сын. Ежедневный бэкап. Хранится 7 копий, по копии за каждый день недели. Понедельник перезаписывает прошлый понедельник.

Отец. Еженедельный бэкап. Хранится 4 копии, по копии за каждую неделю месяца. Третья неделя месяца перезаписывает третью неделю прошлого месяца.

Дедушка. Ежемесячный бэкап. Хранится 12 копий, по одной за каждый месяц. Январь перезаписывается через год.

В сумме получается 7 + 4 + 12 = 23 точки восстановления. С самой свежей за вчера до самой старой за год назад. На практике это покрывает большинство сценариев потерь, включая логические ошибки, замеченные через несколько месяцев.

Эту схему я ставлю по умолчанию, и для 90 процентов клиентов она остаётся неизменной.

Сколько это занимает места

Возьмём три типичных сценария.

Сайт-визитка на WordPress. 600 МБ файлов, 30 МБ база. Одна копия 630 МБ, в архиве с gzip это около 350 МБ.

23 копии × 350 МБ = 8 ГБ.

Корпоративный сайт с фото-галереей. 4 ГБ файлов, 80 МБ база. Одна копия 4 ГБ, gzip даст 3 ГБ (фото уже сжаты, особо не ужмутся).

23 копии × 3 ГБ = 69 ГБ.

Интернет-магазин с тысячей товаров и каталогом фотографий. 25 ГБ файлов, 500 МБ база. Одна копия 25.5 ГБ, gzip даст 22 ГБ.

23 копии × 22 ГБ = 506 ГБ.

В первых двух случаях полная схема влезает на 100 ГБ внешнего хранилища. Стоит это в Yandex Object Storage около 1.62 рубля за гигабайт в месяц, итого 113 рублей за всё. В Selectel Cold Storage в три раза дешевле.

Для интернет-магазина 500 ГБ это уже 800 рублей в месяц. Но и стоимость потери выше.

Как ужать ретенцию, если денег жалко

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

Сократить ежемесячные копии до 4. Только последний квартал. Логические ошибки, замеченные через полгода, восстановить не получится, но нечастые баги в маленьких проектах того стоят. Объём падает с 23 до 15 копий, экономия 35 процентов хранения.

Перейти с полных копий на инкрементальные. Каждая копия хранит только разницу от предыдущей. Объём падает в 5-10 раз для большинства типов данных, кроме интернет-магазинов с большим оборотом фотографий. Сложнее в реализации, и восстановление требует развёртывания цепочки копий, но при больших объёмах оно того стоит. Готовые инструменты: BorgBackup, Restic, Duplicati. Я использую Restic с шифрованием на S3.

Что делать нельзя: оставлять только одну ежедневную копию или вообще одну копию. Это работает примерно в 70 процентах сценариев. В остальных 30 процентах вы обнаруживаете проблему через два дня после того, как её зафиксировал бэкап.

Как часто делать на практике

Несколько типовых сценариев и моя рекомендация.

Блог или сайт-визитка без редакции

Контент меняется раз в неделю или реже. Достаточно еженедельного бэкапа с ретенцией 12 недель. Плюс ежемесячный за год. Всего 24 копии.

Но я всё равно ставлю ежедневный, потому что его стоимость это копейки, а ущерб от потери редкого изменения легко может быть выше.

Сайт услуг с регулярной редакцией контента

Менеджер раз в день обновляет страницу или цены. Ежедневный бэкап обязателен. Стандартная GFR-схема.

Интернет-магазин с заказами

Заказы это бизнес-критичные данные, которые меняются ежечасно. Ежедневный бэкап мало. Я ставлю:

• ежечасный дамп базы данных за 24 часа,
• ежедневный полный бэкап за 14 дней,
• еженедельный за 8 недель,
• ежемесячный за 12 месяцев.

В сумме около 60 точек восстановления. Плюс отдельная репликация базы на запасной сервер для нулевого RPO.

Сайт с активными комментариями или форумом

Похоже на интернет-магазин: пользователи генерируют контент постоянно. Ежечасный бэкап базы плюс ежедневный полный.

Лендинг, который не меняется

Заморозили версию, и трогать год не будем. Достаточно одного бэкапа после деплоя плюс ежемесячного на случай, если кто-то всё-таки залезет. Объём минимальный.

Где хранить и сколько копий держать в каждом месте

Принцип 3-2-1, который я объяснил бы как: три копии данных на двух разных носителях, одна из которых вне основной площадки.

В переводе на русский для маленького сайта:

1. Сам сайт работающий на хостинге это первая копия.
2. Бэкап в панели хостера автоматический, на той же инфраструктуре, но в отдельном хранилище. Вторая копия.
3. Бэкап в облаке на чужой инфраструктуре. Третья копия.

Иногда четвёртой добавляю локальный архив у клиента: раз в месяц владелец качает себе на ноутбук или внешний диск ежемесячный архив. Это страховка на случай, если оба хостинга и облако одновременно стали недоступны (звучит параноидально, но для критичных проектов разумно).

Конкретные цифры по типам сайтов

Сводная таблица по тому, как я обычно ставлю клиентам.

Тип сайта	Частота полного	Ежедневная база	Ретенция	Размер общего хранилища
Лендинг без формы	1 раз/мес	нет	12 копий	1-2 ГБ
Сайт-визитка	ежедневно	в полном	7+4+12	8-15 ГБ
Корпоративный сайт	ежедневно	в полном	7+4+12	50-80 ГБ
Магазин с заказами	ежедневно	каждые 4 часа	14+8+12, базы за 7 дней	200-600 ГБ
Магазин с активной редакцией	ежедневно	ежечасно	14+8+12, базы за 14 дней	300-800 ГБ

Цифры приближённые. На реальных проектах всегда корректирую под объём данных и активность.

Когда хранилища не хватает: как сжимать честно

Несколько техник, которые применяю чаще всего.

Не бэкапить кеш и временные файлы. WordPress генерирует кучу мусора в wp-content/cache/, wp-content/uploads/cache/, tmp/. Это всё восстанавливается само за минуту работы сайта. Исключение из бэкапа экономит 20-40 процентов объёма.

Не бэкапить публичный CDN-ассет каждый день. Если у вас изображения залиты в Yandex Object Storage и оттуда раздаются на сайте, бэкапить их в архив сайта нет смысла. Они уже в облаке.

Сжимать gzip-ом, а не zip-ом. Gzip даёт лучшее сжатие на текстовых данных. Для архивов с большим количеством мелких файлов лучше идёт tar.gz или tar.zst.

Дедупликация. Если используете Restic или BorgBackup, они делают её автоматически. Сжимают за счёт того, что одинаковые блоки между копиями хранятся один раз.

Холодное хранилище для старых копий. Свежие копии в горячем S3, а копии старше месяца автоматически перекладываются в Cold Storage. У Yandex это настраивается lifecycle policy на бакете. Цена падает в 4-5 раз.

Чек-лист на запуск регламента

Когда я подключаю нового клиента к абонентскому обслуживанию, прохожу по этим пунктам:

1. Выяснить RPO и RTO у клиента словами, потом перевести в числа.
2. Посчитать размер одной копии, умножить на ретенцию, прикинуть стоимость хранилища.
3. Согласовать с клиентом цифру и подписать в SLA.
4. Настроить хостерский бэкап и проверить, что он включён.
5. Настроить скрипт ежедневного бэкапа с шифрованием в облако.
6. Настроить ежечасный дамп базы, если нужен низкий RPO.
7. Настроить мониторинг успешного выполнения скрипта.
8. Сделать тестовое восстановление из облака на отдельный поддомен.
9. Записать в паспорт сайта расположение всех копий и пароль для расшифровки (хранить в менеджере паролей у владельца).
10. Поставить в календарь ежеквартальные учения по восстановлению.

Каждый пункт обычно занимает 15-30 минут. Полный регламент для нового сайта поднимается за половину рабочего дня и работает потом сам.

Когда схему нужно пересмотреть

Раз в полгода я пересматриваю регламент с клиентом. Поводы:

• Сайт сильно вырос: было 1 ГБ, стало 20 ГБ, и хранилище уже не справляется по бюджету.
• Появились новые критичные данные (например, начали записывать заявки в свою CRM-таблицу прямо в БД сайта).
• Изменился сценарий работы (стали активнее редактировать контент или начали продавать в шесть раз больше).
• Был инцидент, который показал, что текущая схема слабовата.

Без поводов схема живёт сама по себе годами, и это нормально.

Что почитать дальше

Соседние материалы по теме: Резервные копии WordPress без платных плагинов, Где хранить пароли от админки, На хостинге или в облаке: что надёжнее.

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

Частые вопросы

Как часто делать бэкапы

Ежедневно, если на сайте появляются заявки и заказы. Раз в неделю, если контент стоит. Плюс отдельная копия перед каждым обновлением и крупной правкой.

Сколько хранить копии

14-30 дней для обычного сайта. Смысл длинного хранения в том, что заражение или порчу данных замечают не сразу: копия недельной давности может оказаться уже испорченной.

Сколько места это займёт

Сайт услуг с блогом занимает единицы гигабайт, месяц ежедневных копий с разумной схемой хранения умещается в десятки. При цене хранилища около полутора рублей за гигабайт это копейки.

Как сэкономить на хранении честно

Держать ежедневные копии за две недели, недельные за пару месяцев и месячные за год. Так глубина сохраняется, а объём растёт не линейно.