Виды бэкапов сайта и сервера: что выбрать и сколько это займёт места

Полный, инкрементальный, дифференциальный — разница между ними не в словах, а в том, сколько файлов вам понадобится в момент восстановления и сколько часов вы будете лежать. Разбираем на числах: 50 ГБ данных, 2% изменений в сутки, 30 дней хранения.

Бэкап — копия данных, из которой можно восстановить состояние системы на определённый момент в прошлом. Ключевое слово — «в прошлом»: копия, которая повторяет текущее состояние источника, бэкапом не является, потому что удаление или шифрование файла тут же попадает и в неё.

Шесть типов и чем они отличаются

Различие сводится к одному вопросу: относительно чего считаются изменения. Инкрементальный — относительно любого предыдущего бэкапа, дифференциальный — относительно последнего полного. Из этого вытекает всё остальное.

Сколько места съест каждая стратегия: расчёт на 50 ГБ

Условия: 50 ГБ данных, 2% изменений в сутки (то есть 1 ГБ), хранение 30 дней, полные бэкапы по расписанию раз в неделю — в дни 1, 8, 15, 22 и 29.

Откуда 84 ГБ у дифференциалов: внутри полной недели они растут 1+2+3+4+5+6 = 21 ГБ, таких недель четыре. Плюс один дифференциал после полного 29-го дня.

В сравнении с ежедневным полным инкрементальная схема экономит место в 5,5 раза, дифференциальная — в 4,5 раза, инкрементальный навсегда — в 19 раз. При этом инструменты с блочной дедупликацией вроде restic и borg дают сверху ещё в 2–5 раз, потому что ежедневные дампы базы данных отличаются друг от друга на единицы процентов. Это уже оценка, а не расчёт: выигрыш зависит от доли уже сжатых медиафайлов.

Правило 3-2-1 и его расширения

Правило сформулировал фотограф Питер Крог в книге The DAM Book в середине двухтысячных, а канонический текст закрепил документ US-CERT и Университета Карнеги — Меллона «Data Backup Options» 2012 года.

3-2-1-1-0 продвигает Veeam, 4-3-2 описывает Backblaze — это вендорские расширения, а не стандарты. Но добавленные ими «1» и «0» закрывают ровно те две дыры, через которые бэкапы и теряются: доступная злоумышленнику копия и непроверенное восстановление.

RPO и RTO: как частота бэкапа превращается в потерянные данные

Две метрики из NIST SP 800-34. RPO смотрит назад — сколько данных вы готовы потерять. RTO смотрит вперёд — сколько вы готовы лежать. Связь RPO с расписанием жёсткая: фактический RPO равен интервалу между бэкапами плюс время на выполнение задания.

Авторитетной таблицы «типовых RPO и RTO по отраслям» не существует: NIST предписывает выводить их из анализа влияния на бизнес, а не брать из справочника. Единственный честный способ — посчитать, сколько стоит час простоя именно у вас.

Почему «бэкап есть» и «восстановились» — разные вещи

Самая показательная статистика по теме — из отчёта Veeam Data Trust and Resilience Report 2026, опрос более 900 руководителей IT и информационной безопасности.

Разрыв между 90% уверенности и 28% полного восстановления — это и есть цена непроверенных бэкапов. Для сравнения, по телеметрии Acronis за второе полугодие 2025 года доля успешно завершённых заданий бэкапа составляла 92,4–94,1%. То есть само задание падает примерно в одном случае из пятнадцати — и об этом обычно узнают в момент, когда восстановление уже нужно.

Шифровальщики целятся в бэкапы первыми

Sophos опросил 2974 организации, пострадавшие от программ-вымогателей, и отдельно разобрал, что происходило с их резервными копиями.

В 94% атак злоумышленники пытались добраться до резервных копий, и в 57% случаев у них это получалось. Разница в стоимости восстановления — восьмикратная. Отсюда практический вывод: учётная запись, которой бэкапится сайт, не должна иметь права удалять уже сделанные копии.

Технически это решается иммутабельностью — режимом, в котором копию нельзя изменить или удалить до истечения срока хранения. В объектных хранилищах это S3 Object Lock, и у него два режима: Governance (удалить может пользователь с особой привилегией) и Compliance (не может никто, включая владельца аккаунта). От шифровальщика защищает только второй. По телеметрии Acronis типичный срок удержания — около 15 дней в режиме Governance и 30 дней в Compliance.

Базы данных: где заканчивается mysqldump

Файловый бэкап каталога /var/lib/mysql на работающей базе невосстановим. Для баз есть три подхода, и они решают разные задачи.

Практический ориентир по объёму (это оценка, а не норматив): до 20 ГБ mysqldump комфортен; на 20–100 ГБ терпим только при ночном окне и параллельных инструментах вроде mydumper; свыше 100 ГБ однопоточное восстановление растягивается на часы, и физический бэкап становится обязательным. В бенчмарке Percona на базе 96 ГБ лучшим по сумме «бэкап плюс восстановление» оказался именно XtraBackup.

# Консистентный дамп InnoDB без блокировки приложения
mysqldump \
  --single-transaction \
  --quick \
  --routines --triggers --events \
  --source-data=2 \
  --hex-blob \
  --default-character-set=utf8mb4 \
  --databases mydb \
  | zstd -T0 -12 > /backup/mydb-$(date +%F).sql.zst

# Восстановление
zstd -dc /backup/mydb-2026-09-14.sql.zst | mysql --binary-mode mydb

Чем бэкапить файлы

# restic: бэкап в S3 и ротация по схеме «дед — отец — сын»
export RESTIC_REPOSITORY="s3:s3.amazonaws.com/my-bucket/site"
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic backup /var/www /etc --exclude-caches --tag site
restic forget --tag site --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune

# borg: бэкап на удалённый сервер по SSH
borg create --stats --compression zstd,6 \
  ssh://borg@backup.example.com/./repo::site-{now:%Y-%m-%d_%H%M} \
  /var/www /etc
borg prune -v --list --glob-archives 'site-*' \
  --keep-daily=14 --keep-weekly=8 --keep-monthly=12 \
  ssh://borg@backup.example.com/./repo

# rsync: хардлинкованный снапшот — неизменившиеся файлы места не занимают
rsync -aAXH --delete --numeric-ids \
  --link-dest=/backup/daily/$(date -d yesterday +%F) \
  /var/www/ /backup/daily/$(date +%F)/

Как проверять, что бэкап восстановим

Зелёная галочка задания не означает восстановимость. У restic и borg есть две ступени проверки: структурная (быстрая) и полная вычитка данных с расшифровкой (долгая и дорогая по трафику).

restic check                          # структура, быстро — можно ежедневно
restic check --read-data-subset=10%   # 10% данных случайно — еженедельно
restic check --read-data              # полная вычитка — редко, дорого

borg check ssh://borg@host/./repo                 # регулярно
borg check --verify-data ssh://borg@host/./repo   # полная криптопроверка

Каденция — ориентир, а не норматив: авторитетного стандарта тут нет. Но контрольная цифра есть: по Databarracks Data Health Check 2025 девять из десяти организаций за год тестировали элементы восстановления, а полностью восстановиться после атаки, по Veeam, удаётся 28%. «Тестировали элементы» и «умеют восстановиться целиком» — разные вещи.

Шесть способов остаться без бэкапа

Бэкап нужен, когда что-то уже сломалось

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

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