Не гадай: точный размер резервной копии через формулу

Самый частый вопрос: «Сколько места нужно для бэкапа?» Ответ зависит от типа копии: полная (full), инкрементальная (diff или inc). Базовая формула на один цикл:

Но это без учёта сжатия и дедупликации. Пример: сайт на WordPress с базой 1.2 ГБ и файлами 3 ГБ. Полная копия — 4.2 ГБ. Ежедневный инкремент — ~200 МБ. Храним 7 дней до следующего полного. Резерв = 4.2 + 0.2×7 = 5.6 ГБ. Реально с учётом сжатия (tar.gz даёт ~2:1 на текстовых файлах) — около 3 ГБ. Всегда закладывайте 20% буфер на внезапный рост.

Сжатие сильно зависит от типа данных. Для текстов и логов коэффициент 5:1 (gzip), для сжатых изображений (JPEG) — 1:1 (не сжимается). Дедупликация на уровне блоков (ZFS, btrfs) даёт выигрыш 2-10x на виртуалках с одинаковыми ОС. Таблица ниже — ориентиры:

Как применить: размер_после_сжатия = исходный_размер / итоговый_множитель. Например, база 100 ГБ → 100 / 0.28 ≈ 357 ГБ до сжатия? Нет, наоборот: 100 * 0.28 = 28 ГБ после. Все расчёты сжимаемого размера — деление на коэффициент < 1.

Универсальная стратегия — GFS (Grandfather-Father-Son):

• Ежедневные (сын): 7 копий, инкрементальные
• Еженедельные (отец): 4-5 полных копий (раз в неделю)
• Ежемесячные (дед): 12 полных копий (первое число месяца)

Формула общего резерва:

Данные растут — без учёта этого резерв переполнится через месяц. Типичный прирост: 5-10% в месяц для файлов, 2-5% для баз. Формула на N месяцев:

Пример: текущие данные 200 ГБ, прирост 8% в месяц, нужно хранить 12 месяцев: 200 × (1.08^12) ≈ 200 × 2.518 = 503.6 ГБ. Итоговый резерв с учётом политики GFS: сначала размер данных через год (503.6 ГБ), потом применяем коэффициент полных/инкрементов (пусть 5 полных за год = 5×503.6 = 2518 ГБ) — но это для одного цикла. На практике используют инкрементальное резервирование с постепенным ростом: размер инкремента тоже растёт. Упрощённо: умножаем годовой прогноз на 1.5

Совет: каждые 3 месяца пересчитывайте формулу с актуальными данными. Используйте наш Калькулятор размера резервной копии — он автоматически учитывает прирост.

Ошибка 1: Забывают про дублирование правил 3-2-1. Если у вас один RAID-массив, это одна копия. Нужно минимум 3. Каждая дополнительная копия — +100% к месту. Ошибка 2: Считают сжатие неправильно. Сжатие применяется к данным, не к размеру бэкапа. Если база 100 ГБ, сжатие даст 30 ГБ — это размер одной копии. Но если копий 10, то 300 ГБ. Ошибка 3: Не учитывают метаданные бэкапа. Индексы, чек-суммы, служебная информация — 2-5% от объёма. Ошибка 4: Путают гигабайты (ГБ) и гибибайты (ГиБ). Производители дисков мерят в ГБ (1 ГБ = 10^9 байт), системы — в ГиБ (1 ГиБ = 2^30). Разница 7.3% — учтите.

Например, диск 1 ТБ (1000 ГБ) = 931 ГиБ. Если ваша формула дала 950 ГиБ — он не влезет!

Дано: веб-приложение, данные растут на 5% в месяц. Текущий размер: база 50 ГБ, файлы 20 ГБ, логи 5 ГБ. Политика: ежедневный полный бэкап (хранить 7 дней), еженедельный (4 недели), ежемесячный (12 месяцев). Сжатие: база — 3:1, файлы — 1.5:1 (компрессия JPEG), логи — 5:1.

1. Считаем сжатый размер: база 50/3=16.7 ГБ, файлы 20/1.5=13.3 ГБ, логи 5/5=1 ГБ. Итого сжатый = 31 ГБ.
2. Учитываем метаданные +5%: 31×1.05=32.55 ГБ — размер одной полной копии.
3. Количество кросс-копий: ежедневные (7) + еженедельные (4) + ежемесячные (12) = 23 копии. Но это полные? Нет, в нашей схеме все — полные (для простоты).
4. Объём без учёта прироста: 23×32.55 = 748.65 ГБ.
5. Прирост за 12 месяцев для последней копии: 32.55×(1.05^12) ≈ 32.55×1.7959 = 58.45 ГБ. Средний размер копии с учётом линейного роста можно взять как (32.55+58.45)/2 = 45.5 ГБ. Уточним: фактически каждая копия снимается в разное время, так что общий объём ≈ 23×45.5 = 1046.5 ГБ.
6. Буфер 20%: 1046.5×1.2 = 1255.8 ГБ ≈ 1.23 ТБ.

Если бы не учли прирост, ошиблись бы на 40% (749 vs 1256).

Ручной расчёт громоздкий. Используйте специализированные инструменты:

• Калькулятор размера резервной копии — вводите исходный размер, тип данных, политику хранения, прирост — получаете итог с буфером.
• Скрипты на Bash/Python с интеграцией в систему мониторинга (Zabbix, Prometheus). Пример на Python для подсчёта инкрементов:

  import shutil, os
  size_full = 100 # GB
  size_inc = 2 # GB
  count_inc = 7
  total = size_full + size_inc * count_inc
  print(f"Need {total*1.2:.1f} GB with buffer")

Для медиа-проектов также может пригодиться Изменить размер фото онлайн или Изменить размер видео онлайн — для оценки объёма исходников.

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

Для баз данных с индексами учитывайте, что размер индексов может превышать данные. В PostgreSQL VACUUM создаёт временные файлы до 20% от базы. Для виртуальных машин используйте дедупликацию — экономия 50-70%.