Когда разговор заходит о резервном копировании, многие представляют одну простую картину: сделали копию данных, положили в безопасное место, а в случае беды восстановили. Звучит логично, но на практике всё упирается в один неприятный факт. Данных слишком много, инфраструктура слишком большая, а окно резервного копирования (часть суток, в течение которой нагрузка на продуктивную систему минимальна и резервное копирование разрешено) - слишком короткое.
Именно поэтому в индустрии появилось несколько подходов к тому, как именно сохранять данные. Иногда данные копируют полностью каждый раз, иногда сохраняют только изменения, а иногда собирают полную точку восстановления из уже сохранённых частей. Каждый тип резервного копирования влияет на три вещи, которые важны всегда: скорость выполнения бэкапа, скорость восстановления и нагрузка на инфраструктуру, включая сеть, диски, процессор и хранилище.
Если сказать проще, выбор типа бэкапа – это не религия или вопрос вкуса. Это компромисс между ресурсами, рисками, требованиями, доступной сетевой инфраструктурой, и тем, как быстро нужно будет вернуть систему в строй после сбоя.
Полное резервное копирование (Full Backup)
Полный бэкап — это резервная копия, которая содержит все выбранные данные целиком на момент выполнения задания. Каждый раз мы как бы делаем полную фотографию системы. Это может быть весь набор файлов, вся база данных или весь объём виртуальной машины - в зависимости от того, что именно мы защищаем.
У полного бэкапа есть сильный плюс: восстановление из него максимально простое. В случае инцидента чаще всего достаточно одной точки восстановления, и не нужно собирать длинную цепочку изменений. Поэтому полный бэкап обычно выигрывает по предсказуемости восстановления и снижает шанс того, что процесс восстановления превратится в лотерею.
Но есть и обратная сторона. Полный бэкап дорог по ресурсам. Он требует много места в хранилище, создаёт нагрузку на сеть и СХД, а также часто не укладывается в доступное окно резервного копирования. Поэтому идея делать полный бэкап каждый день хорошо звучит в лабораторных условиях, но в реальной инфраструктуре быстро начинает мешать работе сервисов и становится причиной постоянных компромиссов.
При всем этом полное резервное копирование необходимо выполнять вне зависимости от выбранных типов и стратегий, о чем мы поговорим в дальнейшем.
Инкрементальное резервное копирование (Incremental Backup)
Инкрементальный бэкап - это копирование только изменений с момента последнего резервного копирования. Как правило, речь идёт о последнем бэкапе любого типа. После полного бэкапа выполняется первый инкремент, затем второй, потом третий и так далее - пока цепочка не будет сброшена новым полным бэкапом или синтетическим полным бэкапом.
Инкрементальный подход выглядит очень практично. Меньший объём данных означает более быстрый бэкап, меньшую нагрузку на продакшен и экономию места. Именно поэтому инкрементальные схемы широко применяются в виртуальных средах, на файловых серверах и в инфраструктурах, где данные меняются постоянно, а объёмы измеряются терабайтами.
Однако у инкрементов есть критически важный нюанс - восстановление требует цепочки. Начинать её необходимо именно с полного бэкапа, затем потребуются несколько десятков инкрементальных точек, а для восстановления нужно корректно собрать всю историю. Достаточно потерять один элемент цепочки или получить повреждённую точку, чтобы восстановление сорвалось. Поэтому инкрементальные схемы требуют дисциплины хранения, контроля целостности и регулярных проверок восстановления.
Таким образом, на практике обычно настраивают ежедневное инкрементальное резервное копирование, а полный бэкап выполняют по выходным — раз в одну-две недели.
Современные системы резервного копирования умеют хранить и восстанавливать полностью цепочку данных без необходимости ручного указания каждой инкрементальной резервной копии. Однако для соблюдения необходимых требований SLA по времени восстановления необходимо аккуратно подходить к расписанию инкрементальных и полных бэкапов в рамках одной политики.
Дифференциальное резервное копирование (Differential Backup)
Дифференциальный бэкап также копирует только изменения, но они считаются не от последнего инкремента, а от последнего полного бэкапа. Это означает, что каждый следующий дифференциальный бэкап становится больше предыдущего, поскольку включает все накопленные изменения с момента полного резервного копирования.
Если представить это проще, картина будет следующей. В понедельник делается полный бэкап. Во вторник дифференциальный содержит изменения за один день. В среду - изменения за два дня. К концу недели такой бэкап может заметно вырасти и приблизиться по размеру к полному.
Главный плюс дифференциальной схемы в том, что восстановление проще, чем у инкрементов. Обычно достаточно полного бэкапа и последнего дифференциального. Цепочка получается короткой, точек отказа меньше, а вероятность успешного восстановления выше.
Минус заключается в том, что дифференциальные бэкапы со временем разрастаются и начинают требовать больше места, времени и ресурсов. Поэтому этот подход часто выбирают там, где объём данных не запредельный, но важно упростить восстановление и снизить риск проблем с цепочками. Как и в случае с инкрементальным резервным копированием, расписание полной резервной копии настраивается раз в одну–две недели - в зависимости от требований и доступных объемов хранения.
Синтетическое резервное копирование (Synthetic Full Backup)
Синтетический полный бэкап — это полный бэкап, который создаётся без повторного чтения всех данных с источника. Вместо этого ПО СРК формирует новую полную точку восстановления, используя предыдущий полный бэкап и накопленные инкрементальные изменения на основе существующих индексов резервных копий.
Идея синтетического бэкапа довольно прагматична. Мы получаем полноценную полную точку восстановления, но не перегружаем продакшен повторной перекачкой огромных объёмов данных. Это особенно важно в крупных средах, где источники данных и так постоянно находятся под нагрузкой, а лишнее чтение может негативно влиять на производительность приложений.
Синтетические полные копии часто используют, когда нужно совместить ежедневные инкременты и регулярные полные точки восстановления. Это помогает держать баланс между скоростью резервного копирования и удобством восстановления. По сути, это своего рода «компиляция» инкрементального или дифференциального резервного копирования с полным.
Современные системы резервного копирования умеют выполнять синтетическое резервное копирование как «на лету», так и в фоновом режиме, используя уже существующие резервные копии. Однако необходимо проверять типы нагрузок, исходя из листов совместимости конкретного решения.
К минусам синтетического резервного копирования относятся:
- не всё прикладные нагрузки поддерживаются конкретными СРК;
- повышенная нагрузка на серверы инфраструктуры СРК;
- более высокая чувствительность к консистентности цепочки резервных копий.
Тип и стратегия - это не одно и то же
На практике многие путают две вещи: тип резервного копирования и стратегию резервного копирования. Это происходит потому, что в интерфейсах многих решений кажется, будто выбор типа и есть вся стратегия. Но в реальности это разные уровни.
Тип резервного копирования - полный, инкрементальный, дифференциальный или полный синтетический - это технический способ формирования точек восстановления. Он отвечает на вопрос, как именно создаётся копия данных и как строится цепочка бэкапов. В большинстве случаев это ещё и терминология конкретного продукта, который определяет логику хранения, дедупликации, компрессии и сборки точек восстановления.
Стратегия резервного копирования находится уровнем выше. Она отвечает на вопрос, как именно инфраструктура будет восстанавливаться при реальном инциденте. Стратегия включает частоту резервного копирования, правила хранения и расписание, требования по RPO и RTO, изоляцию хранилища, модель доступа, защиту от вредоносных программ и регулярное тестирование восстановления.
На практике почти никто не строит резервное копирование на одном единственном типе, потому что в реальной инфраструктуре слишком много разных данных и требований, чтобы один подход подошёл всем бизнес-системам. Поэтому обычно используют смешанные стратегии, где комбинируют несколько типов резервного копирования. Например, периодически делают полный или синтетический полный бэкап как базовую точку восстановления, а между ними выполняют инкрементальные копии для экономии времени и ресурсов. Иногда для отдельных систем добавляют дифференциальные копии, если важна более простая схема восстановления. Такой подход позволяет балансировать нагрузку на прод и хранилище, контролировать размер цепочек и при этом обеспечивать восстановление в пределах RPO и RTO.
Важно и то, что стратегия почти всегда подразумевает комбинацию разных типов. Например, часто используются полные или синтетические полные копии как базовые точки, а между ними выполняются ежедневные инкременты. Отдельно в стратегию добавляют контроль целостности и тесты восстановления, потому что в инциденте решает не факт наличия копий, а способность восстановиться в нужные сроки и без сюрпризов. Конкретным стратегиям будет посвящён один из следующих материалов.
Как выбрать подход на практике
Разница между типами бэкапа проявляется в нескольких практических вопросах. Первый - как часто и насколько активно меняются данные. Чем выше нагрузка и интенсивность изменений, тем сложнее выполнять регулярные полные копии без влияния на продуктивную систему.
Второй вопрос - насколько критична скорость восстановления. Если бизнес требует быстрого возврата в строй, то длинные цепочки инкрементов могут стать риском, особенно если восстановление не отрабатывалось заранее.
Третий вопрос - что важнее в конкретной системе. Иногда это экономия места и быстрый бэкап, а иногда - простое и максимально надёжное восстановление.
В реальности всегда приходится искать баланс. Универсального ответа не существует, поскольку инфраструктуры отличаются по объёму данных, требованиям бизнеса, доступным ресурсам и допустимым рискам.
Заключение
Полное, инкрементальное, дифференциальное и синтетическое резервное копирование — это разные подходы, которые по-разному распределяют нагрузку между источником данных, инфраструктурой хранения и временем восстановления.
Полный бэкап проще всего восстанавливать, но он дорог по ресурсам. Инкрементальный экономит место и быстрее выполняется, но требует контроля цепочек и регулярных проверок восстановления. Дифференциальный проще восстанавливать, чем инкременты, но со временем он раздувается по объёму. Синтетический полный позволяет регулярно получать полную точку восстановления, снижая нагрузку на источники данных, но требует производительного хранилища резервных копий.
Самое важное - выбор типа бэкапа сам по себе не является стратегией. Реальная защита данных начинается там, где резервное копирование планируется с учётом восстановления, сроков, угроз и готовности пережить инцидент.
"ДИАМАНТ" - простые в использовании решения, которые помогают хранить, управлять, защищать, архивировать и анализировать огромные объемы данных организациям любого масштаба: от малого бизнеса до крупных корпораций и государственных учреждений.