Инкрементальный, дифференциальный, полный: разница в цифрах

MAATRIX

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

Три подхода в двух словах

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

• Полный (full) — копируется абсолютно всё содержимое целиком, каждый раз заново, независимо от того, что изменилось. Проще всего восстанавливать: нужен один файл.
• Инкрементальный (incremental) — копируются только изменения с момента *последнего* бэкапа, неважно, полного или тоже инкрементального. Самый компактный и быстрый в создании, но для восстановления нужна вся цепочка: полный бэкап плюс все инкременты по порядку.
• Дифференциальный (differential) — копируются все изменения с момента *последнего полного* бэкапа (не с последнего любого, а именно с опорной точки). Каждый следующий дифференциальный бэкап растёт в размере, но для восстановления нужен только последний полный плюс один последний дифференциальный.

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

Полный бэкап: просто, но дорого

Полный бэкап — это снапшот всего защищаемого объёма на момент запуска: файловой системы, базы данных, диска виртуалки целиком. Классический пример — tar без флагов инкрементального режима:

tar -czf /backup/full-$(date +%F).tar.gz /var/www /etc /home

Каждый запуск создаёт независимый архив. Восстановление — это распаковка одного файла:

tar -xzf /backup/full-2026-08-30.tar.gz -C /

Плюсы очевидны: нет цепочек, нет зависимостей между запусками, повреждение вчерашней копии не влияет на сегодняшнюю. Минус — если данные весят 500 ГБ, каждый бэкап весит 500 ГБ, даже если за сутки изменилось 20 МБ. При ежедневном расписании это означает кратный рост нагрузки на диск, сеть (если бэкап улетает на другой сервер) и время выполнения — полная копия 500 ГБ по сети займёт часы, а не минуты. Полный бэкап каждую ночь имеет смысл для небольших объёмов данных или как редкая «опорная точка» раз в неделю, но не как единственная ежедневная схема на сколько-нибудь заметном объёме.

Инкрементальный бэкап: минимум места, длинная цепочка

Инкрементальный бэкап копирует только то, что изменилось с последнего бэкапа любого типа. В tar это делается через --listed-incremental, который ведёт файл-снапшот состояния:

# Полный, с созданием файла состояния
tar --listed-incremental=/backup/snapshot.snar -czf /backup/full.tar.gz /var/www

# Каждый следующий день — только изменения с предыдущего запуска
tar --listed-incremental=/backup/snapshot.snar -czf /backup/inc-day2.tar.gz /var/www

Каждый инкремент маленький и быстрый — если за сутки поменялось 20 ГБ из 500, инкремент весит около 20 ГБ, а не 500. Это и есть главное преимущество: минимальная нагрузка на диск и сеть при ежедневном запуске.

Обратная сторона — восстановление. Чтобы поднять данные на пятницу, нужен воскресный полный бэкап плюс инкременты понедельника, вторника, среды, четверга и пятницы — все по порядку, без пропусков. Если инкремент среды битый или потерян, всё, что после него — недоступно, даже если сами файлы четверга и пятницы целы: у tar в режиме --listed-incremental каждый следующий инкремент описывает изменения относительно состояния, зафиксированного предыдущим, а не относительно данных на диске. Восстановление — это последовательное применение всей цепочки:

tar -xzf full.tar.gz -C /restore
tar -xzf inc-day2.tar.gz -C /restore
tar -xzf inc-day3.tar.gz -C /restore
# ...и так далее по порядку, ни одного пропуска

Чем длиннее цепочка, тем выше риск, что где-то в середине окажется повреждённый или недостающий файл.

Дифференциальный бэкап: золотая середина

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

Для восстановления нужны только два файла: последний полный бэкап и последний дифференциальный. Никакой цепочки из семи звеньев — всегда ровно два. Из инструментов с диффами из коробки работают, например, rsync со ссылкой на предыдущий полный снапшот (--link-dest) или встроенные механизмы Windows Server Backup и большинства корпоративных систем резервного копирования; в мире PostgreSQL похожий принцип реализует pgBackRest с типами backup full/diff/incr.

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

Неделя бэкапов в цифрах: наглядное сравнение

Возьмём условный пример: в воскресенье делается полный бэкап объёмом 500 ГБ, а дальше каждый день данные меняются на одинаковые условные 20 ГБ (упрощение для наглядности — в реальности объём изменений скачет день ото дня, но принцип от этого не меняется).

Что создаётся каждый день (объём нового файла бэкапа):

Разница по объёму хранения при создании — почти в 6 раз между полным и инкрементальным подходом на этом объёме данных.

Что нужно для восстановления на конец каждого дня (количество файлов и их суммарный объём):

Обратите внимание на любопытный момент: суммарный объём данных, которые нужно прочитать для восстановления, к субботе одинаков у инкрементального и дифференциального подхода (620 ГБ) — в этом упрощённом примере с постоянным темпом изменений это математически неизбежно, ведь итоговые данные одни и те же. Но число файлов, которые должны быть целы и применены в правильном порядке, отличается кардинально: 7 против 2. Именно это число — а не объём — определяет реальный риск: чем длиннее цепочка, тем больше точек отказа. Один повреждённый архив среды в инкрементальной схеме обнуляет восстановление четверга, пятницы и субботы одновременно, тогда как в дифференциальной схеме нужно, чтобы были целы только два конкретных файла.

Как выбрать: экономия места vs надёжность восстановления

Итог из цифр выше складывается в три практических вывода:

• Инкрементальный — самый экономичный по месту при ежедневном запуске (620 ГБ против 3500 ГБ за неделю в нашем примере), но восстановление медленнее (нужно распаковать всю цепочку) и рискованнее — повреждение одного звена ломает восстановление всех последующих дней. Подходит, когда место или канал на бэкап-сервер — главное ограничение, а RTO (время на восстановление) не критично.
• Дифференциальный — требует больше места, чем инкрементальный (920 ГБ против 620 ГБ в примере), но восстановление проще и надёжнее: всегда два файла, а не цепочка произвольной длины. Хорош как компромисс, когда хочется предсказуемости восстановления, но полный бэкап каждый день — избыточен.
• Полный — самый безопасный и простой (один файл, никаких зависимостей), но самый затратный по месту (3500 ГБ за неделю) и по времени каждого запуска. Оправдан для небольших объёмов данных или как редкая опорная точка (например, раз в неделю), от которой строятся инкременты или диффы.

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

Стоит также учитывать нюанс современных инструментов: restic, borgbackup и Proxmox Backup Server работают не по классической схеме «полный/инкрементальный/дифференциальный», а через дедупликацию на уровне блоков — по сути, «инкрементальный навсегда», где каждый снапшот логически полный (легко восстановить один снапшот), но физически хранит только новые блоки данных. Мы подробно сравнивали такие инструменты между собой в статье restic или borgbackup — что выгоднее и когда: для новых проектов это часто разумнее, чем городить tar --listed-incremental вручную. Но если вы работаете с системами, которые исторически поддерживают только классическую триаду (Windows Server Backup, корпоративные agent-based решения, самописные скрипты на tar/rsync), выбор между полным, инкрементальным и дифференциальным остаётся актуальным.

Отдельно стоит проговорить цену экономии: если экономить на бэкапах слишком агрессивно — например, никогда не делать полный бэкап и годами наращивать цепочку инкрементов без опорных точек — риск потери данных растёт нелинейно. Мы разбирали эту экономику подробнее в статье экономия на бэкапах и её цена. А чтобы убедиться, что выбранная схема вообще работает, недостаточно один раз её настроить — нужно периодически проверять восстановление на практике; история о том, как это может пойти не так, описана в статье бэкапы шли год и оказались нерабочими.

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