
Полная копия сохраняет выбранные данные целиком, инкрементальная — очередные изменения, дифференциальная — изменения с полной базы. Разница определяет нагрузку, место в хранилище и набор данных для восстановления. Подходящий вариант выбирают по тому, как компания должна вернуться к работе.
Понять зависимости
Какие части копии потребуются для возврата на нужную дату.
Рассчитать хранение
Как изменения данных влияют на объём копий за неделю.
Уложиться в окно
Сопоставить ночные задания с нагрузкой и пропускной способностью.
Проверить возврат
Оценить всю процедуру возврата сервиса, а не только размер бэкапа.
Что сохраняется при каждом запуске
Полное копирование
Каждый запуск сохраняет весь выбранный набор данных на новую точку времени.
- Понятная исходная точка для восстановления
- При самостоятельных полных копиях не нужны предыдущие точки
- Повторное чтение большого объёма нагружает источник и канал
Инкрементальное копирование
Сохраняет изменения относительно предыдущей опорной копии. В классической прямой цепочке — относительно последнего полного или инкрементального запуска.
- Меньше передаваемых изменений при умеренной активности
- Для возврата нужна базовая полная копия и зависимые инкременты
- Длинная цепочка требует контроля целостности и политики хранения
Дифференциальное копирование
Сохраняет накопленные изменения относительно своей полной базы. Каждый новый дифференциал снова учитывает изменения с этой базы.
- Для выбранной точки нужны полная база и соответствующий дифференциал
- Предыдущие дифференциалы для этой точки не требуются
- По мере накопления изменений объём может приближаться к полной копии
Базовые определения и зависимости: руководство Кибер Бэкап 18.1. Названия «инкрементное» и «инкрементальное» обозначают один подход. Конкретная цепочка зависит от продукта и выбранной схемы.
Какие копии нужны для возврата на четверг
Предположим, первая копия создана в воскресенье, затем задания выполняются ежедневно. Ниже показаны три отдельные схемы. Обозначение «Вс» — полная база; «Пн», «Вт», «Ср», «Чт» — последующие точки.
Полная каждый день
Достаточно самостоятельной полной копии четверга.
Полная + прямые инкременты
Нужны база и все зависимые инкременты до четверга.
Полная + дифференциалы
Нужны база и дифференциал четверга; предыдущие дифференциалы не участвуют.
Не удаляйте старую полную копию вручную, если от неё зависят нужные точки. Очистку поручают механизму хранения продукта. При повреждении одного звена прямой цепочки возврат на последующие зависимые точки может стать невозможен.
Сколько места потребуется: пример на 1 ТБ
Условный расчёт: в воскресенье защищаемый набор занимает 1 000 ГБ. В следующие шесть дней ежедневно меняются отдельные 20 ГБ блоков: повторных изменений и роста нет. Храним все семь ежедневных точек. Сжатие, дедупликацию, метаданные и служебные резервы не учитываем.
Полная ежедневно
7 000 ГБ7 × 1 000 ГБ
Полная + инкременты
1 120 ГБ1 000 + 6 × 20 ГБ
Полная + дифференциалы
1 420 ГБ1 000 + (20 + 40 + 60 + 80 + 100 + 120) ГБ
Для субботней точки в этой модели нужны: 1 000 ГБ полной копии; либо база и шесть инкрементов общим объёмом 1 120 ГБ; либо база и дифференциал 120 ГБ — всего 1 120 ГБ. Разница в суммарном хранении всех точек не равна разнице в объёме для одной точки восстановления.
В реальной системе блоки могут меняться повторно. Замена большого файла, обновление виртуальной машины или обслуживание базы меняют картину. Дедупликация уменьшает повторное хранение, но её коэффициент нельзя заранее принять за гарантированный. Ёмкость рассчитывают по измеренным заданиям и сроку хранения с резервом на рост и операции продукта.
Как выбрать схему под свою нагрузку
Небольшой объём и свободная ночь
Начните с оценки полной копии. Простой набор точек удобнее сопровождать, если чтение и передача успевают завершиться.
- Измерить длительность полного задания
- Проверить влияние на утреннюю работу
Крупная ВМ или узкий канал
Рассмотрите инкрементальную схему с поддерживаемым продуктом обновлением базы.
- Измерить объём изменённых блоков
- Проверить длительность восстановления длинной цепочки
Нужен ограниченный набор зависимостей
Дифференциальная схема может упростить состав данных для выбранной точки.
- Оценить рост дифференциала к концу периода
- Задать частоту новой полной базы
Рабочая база и частые изменения
Метод копирования дополняют механизмами согласованности и журналами СУБД, если они нужны выбранному сценарию.
- Уточнить поддержку СУБД и режима работы
- Проверить приложение после восстановления
Частота успешных и пригодных точек влияет на RPO — допустимую потерю изменений. RTO — цель по времени возврата работы — включает получение копии, доступ к ключам, подготовку среды, восстановление и проверку сервиса. Одинаковое ежедневное расписание само по себе не даёт инкрементальной схеме меньший RPO, чем полной.
Общая организация хранения, изоляция и проверка результата разобраны в статье «Резервное копирование для бизнеса».
Синтетическая полная копия и современные хранилища
Полная точка без повторной передачи всего источника
Синтетическая полная копия собирается в хранилище из имеющейся базы и изменений. Активная полная заново получает данные источника. Это позволяет по-разному распределять нагрузку между рабочим сервером, сетью и репозиторием. Синтетическая операция всё равно требует ресурсов хранилища.
Veeam описывает активную, синтетическую полную и прямую инкрементальную цепочку. Режим forever forward поддерживает историю по правилам хранения; его нельзя обслуживать ручным удалением первого файла.
Инкрементальная передача не всегда означает классическую последовательность отдельных файлов, которые нужно применять друг за другом. В Proxmox Backup Server каждая точка ссылается на полный нужный набор блоков, а уже имеющиеся блоки повторно не загружаются. Поэтому важно читать устройство конкретного хранилища. Техническое описание PBS.
Где применяются эти подходы
Сначала определяют защищаемую систему и способ восстановления, затем проверяют версию, агент, модуль и поддерживаемое хранилище. Наличие метода в продукте не означает его доступность для любого объекта.
Кибер Бэкап · Россия
В руководстве 18.1 описаны полные, инкрементные и дифференциальные копии.
- Сверить доступные схемы для своей нагрузки
- Проверить зависимости и автоматическую очистку
RuBackup · Россия
Производитель указывает три основных типа копирования.
- Проверить документацию нужного модуля
- Согласовать правила и хранение точек
Microsoft SQL Server
Дифференциал содержит изменения относительно своей полной базы. Copy-only полная копия не меняет дифференциальную базу.
- Не выбирать базу только по дате файла
- Учитывать модель восстановления и журналы
PostgreSQL
pg_combinebackup собирает синтетическую полную копию из зависимых физических резервных копий.
- Сохранить все необходимые части
- Проверять связь цепочки и целостность данных отдельно
Что чаще всего мешает восстановиться
- Хранится только последний инкремент. Зависимая база и предыдущие части потеряны.
- Копии создаются, но задания запаздывают. Фактические точки отстают от требуемого RPO.
- Проверяют только запись в журнале. Успех задания ещё не подтверждает запуск приложения после возврата.
- Все копии доступны одной учётной записи. Выбор метода не решает задачу изоляции от удаления и шифрования.
- Для восстановления нет ресурсов. Данные сохранены, но некуда развернуть сервер или базу.
Как проверить выбранную схему
- 1
Зафиксировать требования
Выбрать сервис, допустимую потерю изменений, время возврата и сроки хранения.
- 2
Измерить рабочую неделю
Учесть полный запуск, изменения, нагрузку, канал, место и очистку.
- 3
Вернуть трудную точку
В изолированной среде проверить конец цепочки и нужную историческую дату; исключить влияние на рабочие интеграции.
- 4
Подтвердить работу
Проверить данные и согласованные операции приложения, записать время этапов и обновить регламент.
Две памятки для выбора
Частые вопросы
Какое резервное копирование лучше?
То, которое создаёт пригодные точки с нужной частотой и позволяет вернуть сервис в согласованное время. Проверяют нагрузку, цепочку, хранение и восстановление на своей системе.
Чем инкрементальное отличается от дифференциального?
В обычной прямой схеме инкремент хранит изменения с предыдущей опорной копии, а дифференциал — со своей полной базы. От этого зависит состав данных для выбранной точки возврата.
Можно ли удалить старую полную копию?
Только когда механизм хранения продукта подтверждает отсутствие нужных зависимостей или корректно переносит их на другую базу. Возраст файла сам по себе ничего не говорит о безопасности удаления.
Будет ли восстановление инкрементов всегда медленнее?
Нет. Время зависит от формата хранилища, цепочки, скорости чтения, целевого сервера и способа восстановления. Сравнивать нужно одинаковые сценарии на своей инфраструктуре.
Копия журнала СУБД — это обычный инкремент?
Журнальные копии относятся к механизму восстановления конкретной СУБД. Например, PostgreSQL использует физическую базовую копию и последовательность WAL для возврата на нужный момент. Логический pg_dump в эту цепочку не входит. Руководство PostgreSQL по WAL и PITR.
Достаточно ли одной полной копии раз в неделю?
Если компания готова потерять изменения после этой точки, такая частота может соответствовать её цели. Для рабочих данных с более строгим RPO нужны более частые пригодные точки или предусмотренные СУБД журнальные механизмы.
Подберём схему под ваши данные и восстановление
Обсудим объём, скорость изменений, доступное окно, RPO/RTO и условия хранения. По этим требованиям определим подходящую схему и порядок проверки результата.
Обсудить резервное копирование