Типы резервного копирования: полное, инкрементное и дифференциальное

Полное резервное копирование проще всего восстанавливать: для возврата данных обычно достаточно одной копии. Инкрементное копирование создается быстрее и расходует меньше места, поскольку сохраняет изменения после последней успешной копии. Дифференциальная копия занимает промежуточное положение: она больше инкрементной к концу цикла, зато для восстановления обычно нужны только полный бэкап и одна differential-копия.

Универсально лучшего типа резервного копирования нет. Выбор зависит от допустимого времени создания копии, объема изменяемых данных, емкости репозитория, требований RPO и RTO, скорости сети и сложности восстановления. Для большинства серверов подходит схема с периодическим full и регулярными incremental. Differential удобна, когда нужно сократить число зависимых файлов при restore.

Какой тип резервного копирования выбрать: короткий ответ

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

Когда выбрать полное, инкрементное или дифференциальное копирование

• Полный бэкап выбирают, когда критичны предсказуемый restore, независимые точки восстановления и есть время на чтение всего набора данных.
• Инкрементный бэкап выбирают при частых изменениях, ограниченном окне и нехватке места. Каждая новая копия обычно содержит только изменения после последнего успешного задания.
• Дифференциальный бэкап выбирают, когда нужно упростить восстановление по сравнению с длинной цепочкой incremental. Копия включает все изменения после последнего full, поэтому ее размер растет до создания следующей полной копии.

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

Как работают три типа резервного копирования

Для сравнения используем один пример. В первый день набор данных занимает 100 ГБ. Каждый следующий день изменяется примерно 5 ГБ. Обозначим полную копию как Full-1, а последующие точки как Inc-2, Inc-3 или Diff-2, Diff-3.

Полное резервное копирование

Полная копия содержит весь выбранный набор данных на момент запуска задания. Full-1 включает 100 ГБ. Если на следующий день снова запустить full, новая копия опять прочитает и запишет весь актуальный набор, даже если изменилось только 5 ГБ.

Главное преимущество full заключается в независимости точки восстановления. Для возврата состояния на дату создания Full-1 достаточно проверить доступность этой копии и восстановить из нее нужные данные. Структура репозитория получается понятной, а диагностика обычно требует меньше действий.

Цена подхода состоит в максимальном объеме записи и чтения. Полный бэкап дольше работает, сильнее нагружает продуктивные диски, сеть и целевое хранилище. Для больших виртуальных машин ежедневный full может выйти за допустимое окно резервного копирования.

Инкрементное резервное копирование

Инкремент сохраняет изменения после последней успешной копии, независимо от ее типа. Если Full-1 создан в первый день, Inc-2 содержит изменения второго дня. Inc-3 содержит изменения после Inc-2, а не все изменения после Full-1.

Последовательность выглядит так:

1. День 1: Full-1, полный набор данных, 100 ГБ.
2. День 2: Inc-2, изменения за день, около 5 ГБ.
3. День 3: Inc-3, новые изменения после Inc-2, около 5 ГБ.
4. День 4: Inc-4, новые изменения после Inc-3, около 5 ГБ.

Для восстановления состояния четвертого дня нужны Full-1, Inc-2, Inc-3 и Inc-4. Потеря или повреждение одного промежуточного элемента может сделать недоступными последующие точки этой цепочки. Поэтому инкрементная схема требует контроля целостности, понятной политики хранения и регулярного тестового восстановления.

Инкременты уменьшают ежедневный объем передачи данных и сокращают окно backup. Они особенно полезны при больших наборах данных, когда за короткий период изменяется небольшая часть информации. Ограничение длины цепочки новым full снижает число зависимостей и упрощает аварийные операции.

Дифференциальное резервное копирование

Дифференциальная копия содержит все изменения после последней полной копии. В нашем примере Diff-2 включает изменения второго дня, Diff-3 включает изменения второго и третьего дней, а Diff-4 включает изменения второго, третьего и четвертого дней.

Схема выглядит так:

1. День 1: Full-1, 100 ГБ.
2. День 2: Diff-2, около 5 ГБ изменений после Full-1.
3. День 3: Diff-3, около 10 ГБ изменений после Full-1.
4. День 4: Diff-4, около 15 ГБ изменений после Full-1.

Для восстановления состояния четвертого дня обычно нужны Full-1 и Diff-4. Новая differential-копия становится больше с каждым днем, пока не будет создан следующий full. При этом восстановление зависит от двух наборов данных, а не от всей цепочки промежуточных incrementals.

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

Чем бэкап отличается от snapshot и репликации

Резервная копия хранит данные в формате, из которого система резервного копирования может восстановить файлы, виртуальные машины, приложения или отдельные объекты. Для надежной защиты копию размещают отдельно от основной системы и проверяют процедуру restore.

Snapshot фиксирует состояние тома, виртуальной машины или файловой системы в конкретный момент. Он удобен для быстрого локального отката после ошибочного изменения, обновления или удаления файла. Снимок часто находится в том же массиве или пуле, что и исходные данные. Отказ устройства, повреждение пула или ошибка администратора могут уничтожить исходную информацию и snapshot одновременно.

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

Снимки ZFS полезны для локального отката файловых хранилищ и виртуальных машин, но не отменяют независимую копию на другом устройстве или площадке. Подходы к такой схеме хранения разобраны в руководстве по резервному копированию в системах хранения.

Сравнение по скорости, месту и восстановлению

Тип копии определяет компромисс между скоростью создания, объемом репозитория и числом зависимостей при восстановлении. Сравнивать схемы нужно на конкретной нагрузке: при изменении 1% данных результат будет одним, при изменении 40% каждый день, другим.

Скорость резервного копирования и восстановления

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

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

Дифференциальная копия в начале цикла близка по размеру к incremental. До следующего full она постепенно увеличивается, поскольку каждый раз включает накопленные изменения после базовой полной копии. Восстановление обычно быстрее и предсказуемее, чем из длинной цепочки incremental: системе нужны full и последняя differential.

RPO показывает, сколько данных допустимо потерять по времени. RTO показывает, за какой срок сервис нужно вернуть в рабочее состояние. Частый incremental помогает уменьшить RPO, а короткая differential-цепочка или свежий full упрощает достижение RTO.

Расход хранилища и рост цепочки

Для условного набора 100 ГБ с ежедневными изменениями по 5 ГБ расчет без сжатия и дедупликации выглядит так:

• Один full занимает около 100 ГБ.
• Full плюс семь ежедневных incremental занимает около 135 ГБ, если изменения не повторяются и не учитываются служебные данные.
• Full плюс семь differential занимает около 240 ГБ: 100 + 5 + 10 + 15 + 20 + 25 + 30 + 35 ГБ.

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

Расчет емкости нужно делать с учетом retention policy. В формулу входят число хранимых точек, срок хранения, частота full, средний объем изменений, коэффициент сжатия, дедупликация и количество параллельных цепочек для разных заданий. Оставляйте резерв свободного места для временных файлов, служебных операций и внепланового полного бэкапа.

Надежность и сложность цепочки восстановления

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

Основные схемы резервного копирования

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

Полная копия плюс инкременты

Типовой вариант: полный бэкап создается раз в неделю, а incremental запускается каждый день или чаще. При необходимости уменьшить RPO инкремент можно запускать несколько раз в сутки, если инфраструктура выдерживает частоту заданий.

Схема сокращает ежедневное окно и расходует меньше места, чем частые full. Ее цена, длинная цепочка восстановления. Перед запуском определите максимальную длину цепочки, срок хранения и день создания нового full. После этого проверьте восстановление точки в начале и в конце цикла.

Для большинства виртуальных машин и файловых серверов это базовый вариант. Для критичных систем добавьте удаленную или неизменяемую копию и отдельный регламент восстановления.

Полная копия плюс дифференциальные копии

Пример расписания: full каждое воскресенье, differential с понедельника по субботу. Копия за субботу содержит изменения после воскресного full. Для restore обычно достаточно воскресной полной копии и субботней differential.

Схема требует больше места и сетевого трафика к концу недели, чем full плюс incremental. Зато число зависимых файлов при восстановлении остается небольшим. Вариант подходит для систем, где RTO важнее минимального ежедневного объема, а хранилище выдерживает рост differential.

Комбинированная схема с регулярным полным бэкапом

При большом объеме данных используют редкий full, частые incremental и периодический новый full, который ограничивает длину цепочки. Например, full создается раз в неделю, incremental запускается каждые 4 часа, а дополнительный Active Full выполняется раз в месяц или после существенных изменений инфраструктуры.

Точный цикл задают по RPO, RTO, скорости репозитория, доступному окну и сроку хранения. Ускорить создание full можно за счет дедупликации и сжатия, но эти функции увеличивают нагрузку на процессор и могут изменить фактическую скорость restore.

Как дополнить схему правилом 3-2-1

Правило 3-2-1 описывает размещение копий, а не их тип. Храните минимум три экземпляра данных, используйте два разных типа носителей и размещайте одну копию вне основной площадки. Для защиты от шифровальщиков добавляют офлайн- или неизменяемое хранение, отдельные учетные записи и ограничение прав удаления.

Одна локальная full-копия на том же NAS не защищает от пожара, кражи, отказа массива или компрометации учетной записи администратора. Удаленный репозиторий нужно проверить по реальной скорости передачи и времени восстановления. Практическая схема с расчетом канала, хранением и контролем доступа описана в материале про удаленное резервное копирование. Для второй площадки можно использовать отдельную облачную инфраструктуру с нужным объемом дисков и сетью, например серверы и хранилище Timeweb Cloud, если такой вариант соответствует требованиям к размещению и защите данных.

Как выбрать тип для серверов, рабочих станций и баз данных

Одинаковая схема для всех объектов часто создает лишние расходы или не закрывает требования к восстановлению. Для каждой нагрузки отдельно определите состав данных, допустимый простой, RPO, RTO и способ проверки результата.

Резервное копирование серверов и виртуальных машин

Для виртуальных машин обычно защищают весь образ, конфигурацию ВМ и состояние приложений внутри гостевой ОС. Full плюс incremental дает короткое ежедневное окно и подходит для большинства серверов. Differential уместна, если хранилище позволяет увеличить размер промежуточных копий, а восстановление из нескольких файлов нужно упростить.

Для файл-сервера проверьте права доступа, владельцев, ACL, расширенные атрибуты и открытие документов после restore. Для ВМ измерьте время загрузки ОС, запуска служб и возврата сетевого доступа. Репозиторий должен находиться отдельно от гипервизора, иначе отказ хоста может вывести из строя исходную систему и копии.

В Veeam Backup & Replication можно создать задание для виртуальных машин, vApp или организации. Для каждой ВМ задайте отдельное расписание и срок хранения, если критичность объектов различается.

Резервное копирование рабочих станций

Разделите системный образ и пользовательские данные. Образ нужен для восстановления ОС и приложений на рабочем устройстве, а отдельная копия файлов позволяет быстрее вернуть документы без полного развертывания системы.

Для постоянно подключенных рабочих станций подходят частые incremental и периодический full. Устройства с нестабильной связью могут сохранять локальный буфер, а затем отправлять накопленные изменения в центральный репозиторий. Исключите временные каталоги, кэши и файлы, которые можно получить повторно. Контролируйте состояние агента, дату последней успешной передачи и свободное место на локальном буфере.

Для Windows полезно сопоставить образ диска, копирование пользовательских файлов и восстановление учетных данных с конкретными задачами организации. Практические варианты для файлов, диска и системы собраны в руководстве по резервному копированию в Windows.

Резервное копирование баз данных

Образ ВМ или копия файлов не заменяют нативную стратегию СУБД. База может находиться в промежуточном состоянии, а восстановление файлов без журналов не даст point-in-time recovery.

Если конкретная СУБД поддерживает такую схему, используйте полный бэкап, differential-копии и журналы транзакций. Полный бэкап задает базу, differential содержит изменения после него, а журналы уменьшают допустимую потерю данных между точками. Перед выбором расписания проверьте, как продукт строит цепочку и какие журналы нужны для восстановления.

Для базы проверьте запуск экземпляра, целостность таблиц, права доступа и контрольный запрос. Сохраняйте ключи шифрования отдельно от репозитория, но доступно для аварийной команды. Версия СУБД и формат резервной копии должны поддерживать планируемый способ restore. Отдельные сценарии для SQL и 1C разобраны в руководстве по резервному копированию баз данных.

NAS, файловые хранилища и данные контейнеров

Для NAS отдельно копируйте общие папки, конфигурацию системы, ACL, метаданные, ключи шифрования и данные приложений. Snapshot файловой системы помогает быстро вернуть файл после ошибки пользователя, но хранение snapshot в том же пуле не создает независимую копию.

Для контейнеров защищайте compose-файлы, манифесты, секреты, конфигурации, persistent volumes и базы данных, которые работают внутри сервисов. Образ контейнера можно получить заново из реестра, а данные тома часто уникальны. Восстановление проверьте на отдельном узле с чистым окружением.

В ZFS учитывайте состояние пула, свойства dataset, ACL и совместимость целевой системы. Репликация snapshot на второй NAS повышает доступность, но для защиты от удаления и шифровальщика добавьте копию с отдельной политикой хранения.

Практическая настройка задания резервного копирования

Сначала определите требования к данным, затем выбирайте тип копий и расписание. Название технологии не заменяет расчета окна backup, емкости репозитория и фактического времени восстановления.

Параметры, которые нужно определить до выбора типа

• RPO: сколько последних минут или часов данных допустимо потерять.
• RTO: сколько времени есть на возврат сервиса и проверку его работы.
• Объем данных: сколько места занимает полный набор сейчас и как он растет.
• Объем изменений: сколько гигабайт меняется за час или сутки.
• Окно бэкапа: сколько времени доступно для чтения источника и записи в репозиторий.
• Сеть и хранилище: пропускная способность, задержки, скорость дисков и лимиты одновременных заданий.
• Срок хранения: число точек восстановления, дни, недели и месяцы.
• Тестовая площадка: место, где можно восстановить файлы, ВМ или базу без риска для production.

Если изменения малы, а окно короткое, начинайте с full плюс incremental. Если RTO жесткий и репозиторий достаточно емкий, сократите длину цепочки full или используйте differential. При высокой критичности добавьте отдельную копию и регулярный restore-тест.

Настройка задания в Veeam Backup & Replication

Общий порядок настройки задания выглядит так:

1. Откройте раздел Jobs и создайте задание резервного копирования.
2. На шаге Virtual Machines нажмите Add и выберите виртуальные машины, vApp или организацию.
3. Настройте расписание на шаге Job Schedule. Укажите дни и время запуска с учетом нагрузки на продуктивные системы и репозиторий.
4. В блоке Retention policy задайте количество точек восстановления или количество дней хранения.
5. Укажите репозиторий, параметры обработки данных и правила уведомлений.
6. После первого запуска проверьте результат задания и выполните тестовое восстановление.

Названия пунктов и доступные параметры могут различаться по версии продукта и типу задания. Перед изменением настроек проверьте их соответствие вашей редакции Veeam и выбранному объекту резервного копирования.

Active Full как новая базовая точка

Active Full заново считывает полный набор данных и формирует новую базу для последующих копий. После него цепочка incremental или differential начинает отсчет от новой полной точки.

В Veeam запуск выполняется через Jobs -> Active Full. Новая базовая копия оправдана после существенных изменений инфраструктуры, при чрезмерном росте цепочки, после переноса задания на другой репозиторий или по внутреннему регламенту.

Active Full требует времени и свободного места для записи полного набора. Запускайте его в окно, когда источник и репозиторий выдерживают дополнительную нагрузку. После завершения проверьте новую точку и восстановление хотя бы одного объекта.

Согласованность приложений и Windows-ВМ

Файловый образ ВМ может быть создан успешно, но состояние базы или другого приложения внутри гостевой ОС останется несогласованным. Для Windows-ВМ, совместимых с MS VSS, в шаге Guest Processing включите Enable application-aware image-processing.

Application-aware image-processing координирует обработку приложений через механизмы гостевой ОС и помогает получить транзакционно-консистентный бэкап. После включения проверьте учетные данные, доступ агента к гостевой системе и сообщения задания. Для обычных файл-серверов такой режим тоже может быть полезен, даже если внутри нет транзакционных приложений.

Уведомления и индексирование файлов

В разделе Guest Processing можно включить Enable guest file system indexing, если нужен поиск файлов внутри гостевой файловой системы. Индексирование увеличивает объем обрабатываемых метаданных и должно соответствовать реальной задаче восстановления.

Для контроля заданий включите Enable e-mail notifications в разделе уведомлений по электронной почте. Отправляйте ответственным администраторам статусы успешных, пропущенных и завершившихся ошибкой заданий. Ежедневная проверка уведомлений сокращает время между сбоем backup и обнаружением проблемы.

Как проверить, что резервная копия действительно восстанавливается

Статус Job completed подтверждает завершение операции, но не доказывает, что нужный файл, сервер или база восстановятся в аварийной ситуации. Проверка должна включать чтение копии, запуск восстановленного объекта и сопоставление результата с целевым RTO.

Тестовое восстановление файлов, серверов и виртуальных машин

• Файлы: восстановите документы разных размеров и форматов, проверьте открытие, владельцев, ACL, даты и права записи.
• Виртуальные машины: загрузите ОС в изолированной сети, проверьте диски, сетевые интерфейсы, системные службы и запуск приложений.
• Базы данных: запустите экземпляр, выполните проверку целостности и контрольный запрос, проверьте доступ приложения и восстановление на нужный момент времени.
• Контейнеры: разверните сервис из конфигураций, подключите восстановленные тома и проверьте миграции, секреты и доступ к зависимым системам.

Фиксируйте фактическое время каждой операции: поиск точки, подготовка целевого узла, передача данных, загрузка ОС, запуск приложения и проверка пользователем. Если результат выходит за RTO, меняйте схему, инфраструктуру или требования, а не ограничивайтесь отметкой об успешном задании.

Проверка цепочки и политики хранения

Для incremental найдите базовый full и все промежуточные точки до нужной даты. Для differential проверьте доступность full и соответствующей differential. Для отдельной полной копии убедитесь, что файл читается и содержит ожидаемый набор данных.

Сопоставьте фактическое число точек с Retention policy. Проверьте, что автоматическая очистка не удаляет базу раньше зависимых копий и не нарушает RPO. Проверьте доступ к репозиторию после смены пароля, обновления системы резервного копирования и переноса хранилища.

Типовые причины неудачного восстановления

• Поврежден один файл в цепочке incremental.
• На репозитории закончилось свободное место, и новая точка создалась не полностью.
• Потерян сетевой доступ к удаленному репозиторию.
• Сменились учетные данные или отозваны права сервисной учетной записи.
• Версия платформы резервного копирования не поддерживает нужный формат или способ восстановления.
• Для базы не включена application-aware обработка, а журналы транзакций отсутствуют.
• Ключ шифрования не сохранен в доступном для аварийной команды месте.
• На целевой системе недостаточно диска, памяти, лицензий или сетевых адресов.
• Копии доступны только на основной площадке и повреждены вместе с production.

Минимальный чек-лист эксплуатации

1. Каждый рабочий день проверяйте статусы заданий и уведомления об ошибках.
2. Раз в неделю проверяйте наличие новых точек, свободное место и срок хранения.
3. Раз в месяц восстанавливайте отдельные файлы и один объект из полной цепочки.
4. По согласованному графику восстанавливайте ВМ или базу в изолированной среде.
5. Периодически проверяйте удаленную, офлайн- или неизменяемую копию.
6. Документируйте владельца системы, RPO, RTO, расположение репозитория и порядок выдачи ключей.
7. После изменения гипервизора, СУБД, NAS или сетевой схемы повторяйте тест восстановления.

Итоговый алгоритм выбора типа бэкапа

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

Если приоритет, простое восстановление

Используйте регулярные полные копии или full с короткой цепочкой differential. Такой подход увеличивает расход хранилища и требует более широкого окна backup. Он подходит для критичных систем, где несколько минут на поиск зависимого файла создают больший риск, чем дополнительные диски.

Если приоритет, экономия места и короткое окно бэкапа

Выбирайте full с incremental. Ограничивайте длину цепочки регулярным созданием новой полной копии, задавайте retention policy и проверяйте целостность репозитория. Храните независимую удаленную или неизменяемую копию и заранее тестируйте восстановление при недоступности основной площадки.

Если нужно сбалансировать место и скорость восстановления

Используйте full с differential, если ежедневный рост копий укладывается в емкость хранилища. Восстановление будет зависеть от полной и последней differential-копии, но к концу цикла потребуется больше диска и времени на backup. Перед назначением расписания рассчитайте объем всех точек и измерьте фактический RTO.

Алгоритм выбора состоит из шести шагов:

1. Определите критичность данных, RPO и RTO.
2. Измерьте полный объем и средний объем изменений.
3. Оцените окно backup, сеть, производительность источника и емкость репозитория.
4. Выберите базовый full и тип последующих копий, incremental или differential.
5. Настройте расписание, retention policy, изоляцию и правило 3-2-1.
6. Проведите тестовое восстановление и зафиксируйте фактический результат.

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