Synthetic full backup что это
Преимущества нового метода резервного копирования виртуальных машин перед классическими схемами
Обычный прямой инкрементный метод, как правило, установлен по умолчанию, и потому чаще используется. Он основан на том, что при первом прогоне создается полная резервная копия и далее сохраняется цепь последующих инкрементов. Для того, чтобы повысить надежность такой цепочки резервных копий и сократить время восстановления (оно будет линейно расти по мере роста числа созданных инкрементов), периодически необходимо создавать либо новую полную копию, либо синтетическую. Количество инкрементов, через которое нужно заново создавать полную резервную копию указывается в параметрах схемы резервного копирования. Схематично процесс выглядит вот так:
Прямой метод обеспечивает высокую скорость обработки данных (I/O), так как требуется всего одна операция чтения/записи на каждый сохраняемый блок данных. Время создания инкремента и время «жизни» снапшота виртуальной машины невелико, что минимизирует нагрузку на продакшн. Однако, расход емкости СХД будет значительным, из-за хранения избыточного количества данных. Почему?
Избежать перерасхода дискового пространства позволяет реверсивный инкрементный метод. Механизм создания таких резервных копий немного сложнее: «свежие» инкременты внедряются в первоначально созданный полный бекап, а замещенные таким образом блоки данных из полной копии сохраняются как предшествующие ей.
Реверсивный инкрементный метод, во-первых, позволяет увеличить эффективность использования системы хранения за счет того, что в наличии всегда есть одна полная резервная копия и цепочка предшествующих ей инкрементов (при этом «лишние» инкременты регулярно удаляются согласно установленному сроку хранения). Во-вторых, время восстановления данных из резервной копии, созданной реверсивным методом, минимально, так как полная копия содержит наиболее актуальную версию данных и не нужно тратить время на анализ инкрементов.
Впрочем, и в этом алгоритме есть своё «но»: снижается скорость обработки данных и увеличивается время существования снапшота. На каждый сохраняемый блок данных требуется 3 операции чтения/записи: прочитать вытесняемый блок данных из полной копии, записать этот блок на СХД в виде реверсивного инкремента, и затем вписать в полную копию новый блок изменившихся данных. В результате, если система хранения не поддерживает такой уровень производительности, процесс резервного копирования будет займет много времени, а снапшот увеличит нагрузку на производственную среду.
Как избежать компромиссов
В Veeam Backup & Replication v8 реализован метод «прямого инкрементно-бесконечного» резервного копирования, который объединяет сильные стороны алгоритмов, рассмотренных выше, и позволяет получить сразу и скорость копирования данных, и быстрое восстановление, и экономное использование СХД.
При прямом инкрементно-бесконечном методе создается полная копия и цепочка последующих инкрементов, которые хранятся до тех пор, пока не будет достигнут установленный срок хранения (пусть будет N дней). В день N записывается последний инкремент цепочки, и на следующем прогоне задания резервного копирования произойдет следующее:
С течением времени подобная операция будет повторяться раз за разом по мере добавления новых инкрементов в цепочку.
Общее количество циклов чтения/записи останется таким же, как при реверсивном инкрементном резервном копировании, однако, важно то как именно будет проходить обработка данных. Для создания инкремента потребуется только одна операция I/O, а значит, снапшот виртуальной машины будет открыт меньше времени. Оставшиеся 2 операции чтения/записи нужны для того, чтобы обновить файл полной резервной копии, и снапшот при этом уже не задействован. Кроме того, процесс создания новой полной синтетической резервной копии сведется к добавлению одного инкремента, вместо объединения целой цепочки инкрементов, как это происходило бы в случае создания «прямого инкрементного» с полными синтетическими копиями. Процедура «схлопывания» самого древнего инкремента с полной копией будет происходить уже вне окна резервного копирования без нагрузки на производственную среду, а значит, «в окне» можно успеть сделать больше резервных копий (в синтетическом бэкапе объединение блоков происходит в одном окне с созданием резервных копий).
Синтетическое резервное копирование (Synthetic Backup) – альтернативный прием эффективной защиты данных
Количество данных на предприятиях, больших и малых, с годами растет в геометрической прогрессии. Защита данных становится очень сложной задачей, а требования доступности растут с каждым днем. Учитывая, что защита данных является задачей первостепенной важности для предприятий любых размеров, эта задача требует значительных вложений (в зависимости от размера компании) и, определенно, является содействующим фактором в прибыльности компании. При тщательно продуманном планировании развертывания инфраструктуры ИТ и использовании только лучших приемов для содержания корпоративных данных, например планирование Disaster Recovery (DR) [1] для защиты и безопасности данных, компании смогут значительно сэкономить и увеличить границы своей прибыли. Синтетическое резервное копирование является одним из таких самых лучших DR приемов, который обеспечивает эффективную защиту данных при низкой стоимости работ. Оно также предлагает традиционные приемы резервного копирования файловой системы во время ее восстановления.
Что такое синтетическое резервное копирование?
Синтетическое резервное копирование является альтернативой создания полных резервных копий из периодических инкрементальных копий. Она состоит из одной обычной полной резервной копии (при первом создании), после создания которой, все последующие изменения вносятся в нее в виде периодических инкрементальных копий (periodic incremental [2] backups). Поскольку такой тип копирования синтезируется из полного резервного копирования, отсюда он и получил свое название.
Слово «синтетический» в данном контексте означает, что составной файл не является непосредственной копией любого (созданного в данный момент или ранее) единичного файла. Вместо этого, синтетический файл объединяется или «синтезируется» специальным приложением из оригинального файла и одной или большего количества его модификаций.
Рисунок 1: Концептуальное представление синтетического и полного резервного копирования
Эта процедура резервного копирования называется синтетической, поскольку копия создается не из оригинального файла данных. На рисунке 1 показаны шаги, из которых состоит традиционное полное резервное копирование и синтетическое. При синтетическом копировании меньше данных будет передаваться по каналам сети, что означает меньший объем сетевого трафика. Это происходит благодаря тому факту, что при традиционном создании резервных копий всего тома требуется передача всех используемых блоков данных из этого тома в хранилище резервных копий. А при синтетическом резервном копировании система использует лишь инкрементные изменения, передает их по каналам сети и после этого запускает специальную программу [3] в хранилище для применения этих изменений к предыдущей резервной копии (полной или синтетической). Суть заключается в том, что после первого создания полной резервной копии вам нужно будет использовать только инкрементные копии, а не полные резервные копии каждый раз. Каждая новая инкрементная копия будет синтезироваться и обновлять полную резервную копию.
Почему именно синтетическое резервное копирование?
Синтетическое резервное копирование – это не просто еще один способ создания резервных копий, это более удобная альтернатива. Наличие полной резервной копии и отдельных инкрементных составляющих не дает тех же преимуществ, которые предлагает синтетическое резервное копирование. В первом случае системному администратору пришлось бы иметь дело с большим количеством отдельных инкрементных файлов при восстановлении системы с их помощью. Во втором случае (при синтетическом резервном копировании) один единственный файл будет содержать все изменения с момента создания последнего инкрементного элемента.
Этот тип создания резервных копий подходит для корпоративного окружения, где пропускная способность сети имеет повышенное качество и ее нелегко масштабировать. Такие модели бизнеса как Application Service Providers являются типичными примерами, когда сотни гигабайт данных передаются по общим каналам, в большинстве случаев по линиям T1 или T3. Даже при использовании линии T3 создание резервных копий 20-30 серверов с 150 GB данных в среднем на каждом потребует серьезных вложений на оплату пропускной способности сети и соответствующих затрат на содержание линии. Более того, потребуются огромные ресурсы места для хранения всего объема периодических полных резервных копий.
Синтетическое резервное копирование лучше всего использовать, когда временные или системные требования не позволяют использовать полное резервное копирование. Некоторые ключевые преимущества:
Соответствующие пользователи (Featured Users)
Некоторые типичные пользователи синтетического резервного копирования:
Провайдеры сервисов приложений (Application Service Providers)
Application Service Providers (ASP) поставляют ПО от централизованных банков данных, через платный доступ выделенных, высокоскоростных сетей или Интернет. Службы приложений варьируются от систем планирования ресурсов предприятий (Enterprise Resource Planning (ERP)), решений управления взаимоотношениями потребителей (Customer Relationship Management (CRM)) и вертикальных приложений до ПО для рабочих групп, пакетов персональной производительности и полных сервисов десктопов и печати. Для того чтобы обеспечить защиту данных, провайдеры этих решений сталкиваются с проблемой создания со временем резервных копий этих важных данных, используя арендованные сети, например T1. Это довольно дорогая операция и требует значительных вложений, чтобы оплатить расходы аренды сетей и сетевой трафик.
Усовершенствованные приемы создания резервных копий, такие как синтетическое копирование, позволяют ASP значительно снижать стоимость этих операций (учитывая множитель), а также пользоваться преимуществом экономии времени и места, которое дает синтетический способ создания резервных копий.
Провайдеры Managed Service Providers
Провайдеры managed service provider (MSP) – это компании, которые управляют сервисами ИТ других компаний через Интернет. MSP – это компания, предлагающая продолжительный аутсорсинг ИТ функции. MSP обеспечивает техническую поддержку для данного сервера, включая обновление ПО, резервных копий, физических устройств, пропускной способности сети, брандмауэров и других технических вопросов. Учитывая ценовую эффективность и оптимизацию времени и места, которой обладает синтетическое резервное копирование, модель бизнеса MSP может со временем достичь значительного увеличения прибыли.
Предприятия малых и средних размеров (SMB)
Данные представляют собой важную интеллектуальную собственность любой компании, будь то ISV, страховая компания, банк, розничная торговая точка, компания разработки ПО, ASP/MSP, и т.д. Синтетический способ создания резервных копий гарантирует оптимальную работу касаемо требований времени на создание копий и места хранения копий. С меньшей нагрузкой на ресурсы производственной системы этот способ может создавать прерывистые синтезированные полные резервные копии с минимальным воздействием на общие и раздельные приложения, запущенные на этих производственных системах, включая файловые серверы, серверы базы данных и/или серверы печати. Еще одним преимуществом этого способа является меньшее количество времени, затрачиваемого на восстановление системы с помощью таких файлов. В отличие от множества традиционных инкрементных файлов, этот способ предполагает только одну резервную копию, содержащую все изменения, которые записывались в течение времени в каждом инкрементном файле.
Заключение
Эта статья дает технический обзор синтетического способа создания резервных копий системы. Воспринимайте его как лучший способ восстановления системы после сбоев DR, нацеленный на обеспечение эффективного в ценовом плане и сильного решения по защите данных. Благодаря его оптимальным параметрам времени и места, он поможет компаниям с огромными объемами важных данных эффективно справляться с резервным копированием томов и хранением этих копий. Вкратце, такой способ позволит обслуживать эффективное в ценовом плане хранилище данных и обеспечит оптимальные параметры создания резервных копий.
О Sonasoft
Sonasoft Corp. автоматизирует создание резервных копий с диска на диск и процесс восстановления для Microsoft Exchange, SQL и Windows Servers с помощью решений SonaSafe Point-Click Recovery. SonaSafe является единственным продуктом, обеспечивающим интегрированные решения по созданию резервных копий, восстановлению и репликации данных для серверов Exchange и SQL. Решения SonaSafe, созданные для упрощения и исключения возможных ошибок в процессе создания резервных копий и восстановления данных из-за человеческого фактора, также концентрируют процесс управления несколькими серверами и обеспечивают надежную дешевую стратегию восстановления данных после сбоев для компаний всех размеров. Для дополнительной информации перейдите по ссылке http://www.sonasoft.com/.
[1] Восстановление в случае сбоев (Disaster Recovery) – это важный момент в области управления жизненным циклом информации (Information Lifecycle Management), который подготавливает компанию к катастрофе и обеспечивает спокойствие ее сотрудникам.
[2] Относится к резервной копии, содержащей изменения на жестком диске (томе) с момента последнего создания резервной копии.
[3] Как правило это приложение работает на той же системе с Network Attached Storage (NAS). Либо оно может работать на любой другой машине, входящей в ту же подсеть с NAS.
Виды резервного копирования
Дата публикации: 21 ноября 2018 г.
Виды (типы) резервного копирования различаются по многим параметрам. В этой статье мы рассмотрим основные алгоритмы резервного копирования, проведем краткий обзор каждого из традиционных и новых видов резервного копирования. Покажем, чем они отличаются, а так же перечислим преимущества и недостатки каждого из них.
Full Backup: ПОЛНОЕ РЕЗЕРВНОЕ КОПИРОВАНИЕ
Данный метод создает полную копию набора исходных данных, поэтому является лучшим вариантом защиты с точки зрения управления и скорости восстановления данных. Но это метод занимает в разы больше времени, чем другие способы резервного копирования, а также создаёт значительную сетевую нагрузку.
Обычно, полные резервные копии делают периодически и объединяют их с другими типами резервного копирования.
Преимущества Full Backup:
Недостатки Full Backup:
Differential Backup: ДИФФЕРЕНЦИАЛЬНОЕ РЕЗЕРВНОЕ КОПИРОВАНИЕ
Системы с дифференциальным резервным копированием
Дифференциальный тип резервного копирования является промежуточным решением между полным резервным копированием и инкрементными резервными копиями. Подобно инкрементному резервному копированию, отправной точкой для дифференциальной резервной копии является создание полной резервной копии и резервное копирование только измененных данных. Однако, в отличие от инкрементных резервных копий, дифференциальная резервная копия сохраняет не данные, которые были изменены с момента последней резервной копии, а данные, которые были изменены с момента первоначальной полной резервной копии. Таким образом, полная резервная копия является постоянной точкой отсчета для последовательных резервных копий.
Дифференциальная резервная копия позволяет быстрее восстанавливать данные по сравнению с инкрементным резервным копированием, поскольку для этого требуется всего две части резервной копии: полная резервная копия и последняя дифференциальная резервная копия. Скорость резервного копирования / восстановления, находится где-то между полным и инкрементным методом резервного копирования. Резервное копирование выполняется быстрее, чем полная резервная копия, но медленнее, чем инкрементное резервное копирование. Восстановление выполняется медленнее, чем у полной резервной копии, но быстрее, чем у инкрементных резервных копий. Объем памяти, необходимый для дифференциального резервного копирования, по крайней мере на определенный период меньше, чем требуется для полного резервного копирования и больше, чем требуется для инкрементного резервного копирования.
Преимущества Differential Backup:
Недостатки Differential Backup:
Incremental Backup: ИНКРЕМЕНТНОЕ РЕЗЕРВНОЕ КОПИРОВАНИЕ
Инкрементное резервное копирование использует полную копию, как начальную точку. Затем выполняется резервное копирование только блоков данных, которые были изменены с момента последнего резервного задания, с заданным периодом выполнения задания. В зависимости от политики хранения резервных копии, через определенный период создается новая полная копия для повторения цикла.
Представим, что в воскресенье мы сделали полную копию данных, в понедельник мы делаем копию данных, которые изменились с момента полной копии. Во вторник только данные, которые изменились с понедельника, и так все дни до воскресенья, а в воскресенье делаем новую полную копию. Таким образом, инкрементное резервное копирование можно выполнять так часто, как требуется, так как сохраняются только копии последних изменений. Инкрементное резервное копирование позволяет уменьшить объем передаваемых данных, тем самым сокращая время выполнения бэкапа и снижая нагрузку на сеть. Резервное копирование выполняется быстро и требует гораздо меньше места для хранения, по сравнению с полными копиями, но процесс восстановления занимает больше времени, поскольку необходимо восстановить как полную резервную копию, так и целую цепочку последовательных блоков. Если хотя бы один блок в цепочке будет отсутствовать или окажется поврежденным, выполнение восстановления может стать невозможным.
Преимущества Incremental Backup:
Недостатки Incremental Backup:
Reverse Incremental Backup: ОБРАТНОЕ ИНКРЕМЕНТНОЕ РЕЗЕРВНОЕ КОПИРОВАНИЕ
Обратное инкрементное резервное копирование, аналогично другим типам резервного копирования, начинается с создания полной резервной копии, но при каждом новом резервном копировании, все данные из предыдущей (полной) резервной копии перемещаются в новую резервную копию, а предыдущая РК заменяется инкрементом. Таким образом, отличие данного типа заключается в том, что последняя (самая новая) резервная копия всегда является полной, а старые резервные копии наоборот, всегда есть инкременты. Это дает возможность более быстрого восстановления, так как именно самая последняя резервная копия чаще является самой ценной и востребованной.
В отличии от обратного, при обычном инкрементном резервировании последняя резервная копия зависит от всех сделанных ранее, поэтому на восстановление данных уходит больше времени (так как в процессе участвуют ни одна, а несколько резервных копий), а так же если хоть одна копия повреждена, восстановление данных будет не возможно.
Преимущества Reverse Incremental Backup:
Недостатки Reverse Incremental Backup:
Что нового в Veeam Backup & Replication 9.0: повышаем эффективность создания и хранения резервных копий
В этом посте я расскажу о новых функциональных возможностях, которые вы сможете задействовать, обновив вашу версию Veeam Backup & Replication до 9.0. Среди разнообразия новинок, признаюсь, у меня есть несколько любимцев — и хотя с виду они могут показаться малоприметными, но они приносят большую пользу, за что и ценю. Конечно, всю массу в рамках одного поста не опишешь, поэтому сразу дам ссылочку на полный обзор новинок на официальном сайте: What’s New in Veeam Backup & Replication v9.
Консоль для удаленного управления
В прошлом посте уже был обзор этого нового компонента. Напоминаю, что консоль позволяет подключаться к удаленным серверам Veeam backup; ее можно поставить отдельным сетапом, есть также и автоматическая установка (см. описание в User Guide). Таким образом, теперь Veeam поддерживает полностью распределенную архитектуру. В прошлых версиях компоненты Veeam.Backup.Service.exe и VeeamShell.exe вели исключительно совместное существование, а в v9 усилиями наших инженеров их взаимозависимость удалось, наконец, победить — то есть, как выразился TheRealGostev, «разделить сиамских близнецов».
Новые возможности репозиториев
В работе с репозиториями резервных копий появились новые возможности.
Во-первых, теперь любому репозиторию можно назначить сервер подключения (mount server). Это Windows-сервер, выполняющий определенную роль в инфраструктуре резервного копирования — при восстановлении на уровне файлов (FLR, file-level restore) такой сервер выполняет монтирование файлов ВМ прямо из бэкапа на свою файловую систему, как бы «подключая» их к себе. Сервер подключения можно задать на соответствующем шаге (Mount Server) мастера настройки репозитория.
Для обычных репозиториев также предлагается опция хранения резервных копий «по машинам» (per-VM backup files). При использовании этой опции поток записи будет сформирован для каждой ВМ (а не для каждого задания). В результате увеличивается глубина очереди, что улучшает производительность, поскольку обслуживание одного-единственного потока (глубина очереди = 1) является для большинства СХД фактором, ограничивающим производительность. Создание же нескольких потоков (глубина очереди
= N, то есть числу задач на репозитории) очень даже помогает делу.
Кроме того, стало возможным создавать задания большего объема без оговорок насчет трудностей с контролем над большими бэкапами. С выходом v9 наши системные архитекторы готовятся пересмотреть рекомендации о количестве ВМ, включаемых в одно задание — например, доведя его до 250-300. Во всяком случае, наше собственное тестирование подтвердило возможность обработки заданий, содержащих 5 000 виртуальных машин.
Разумеется, при планировании и настройке заданий резервного копирования нужно помнить, что ряд операций — например, создание синтетического бэкапа, задания Backup Copy Jobs (перенос бэкапа на резервную площадку) и др. — будут ожидать, когда отработает бэкап всех ВМ. По этой причине гигантские задания создавать не рекомендуется.
Важно! После того, как вы выбрали опцию хранения бэкапов Use per VM-backup files, ее нужно активировать, выполнив операцию создания активной полной резервной копии (Active Full) либо в ручном режиме, либо дождавшись срабатывания по расписанию.
Еще пара моментов: помним, что дедупликация на стороне источника никуда не денется. И второе — при создании новых репозиториев на СХД EMC DataDomain (с DDBoost), HP StoreOnce (с Catalyst) и ExaGrid (с Accelerated Data Mover) данная опция включается по умолчанию, но на всякий случай рекомендуется это проверить, равно как и другие рекомендуемые для этих СХД настройки.
Новые возможности хранения данных
После обновления новые возможности Veeam Backup & Replication по умолчанию будут отключены. Чтобы начать их использовать, вам следует перенастроить существующие задания резервного копирования. Замечу, что первые две опции из списка ниже были ранее доступны только для заданий переноса резервных копий (Backup Copy Jobs). Теперь же их можно использовать и при создании других типов заданий. Вот эти новые возможности:
Дефрагментация и сжатие. Использование этой опции будет полезно, если ваше задание резервного копирования не включает периодическое создание полного бэкапа (active full backup), и при этом политика хранения данных предполагает периодическое объединение файла полной копии с ближайшей инкрементальной копией. Такая трансформация приводит к тому, что файл бэкапа становится фрагментированным и в нем образуются «пустоты». Пустоты образуются также и в том случае, когда из задания резервного копирования была удалена часть ВМ (после их удаления из бэкапа сам файл не становится меньше). Чтобы уменьшить размер файла, а также несколько увеличить скорость работы с ним вы можете включить опцию Defragment and compact full backup file. Она работает следующим образом: в указанное время Veeam Backup & Replication будет создавать пустой файл VBK и копировать туда только нужные блоки из файла бэкапа, полученного в результате трансформаций. Для этой опции есть ограничения, которые описаны в User Guide.
Проверка работоспособности и самовосстановление. Чтобы быть уверенным в том, что резервные копии не повреждены, в дополнение к SureBackup вы можете активировать опцию Perform backup files health check. В этом случае при создании каждой резервной копии Veeam Backup & Replication будет вычислять хэш и контрольную сумму созданного файла. Затем перед началом следующего резервного копирования Veeam Backup & Replication заново вычислит хэш и контрольную сумму файла и сравнит ее с сохраненными ранее значениями. Если обнаружится, что данные файла были повреждены, Veeam Backup & Replication заменит поврежденные блоки, скопировав требуемые данные из исходной ВМ или из предыдущей резервной копии.
Исключение блоков, помеченных как удаленные. Удаляя файлы в NTFS, вы на самом деле не очищаете блоки данных, которые содержат файл, а помечаете их как удаленные. Поэтому зачастую при создании резервной копии образа ВМ (image-based backup) размер файла резервной копии может сильно превышать размер, отображаемый в файловой системе. До недавнего времени единственным способом избежать копирования «удаленных» данных было использование утилиты sdelete (SysInternals) перед началом резервного копирования. В Veeam Backup & Replication v9 вы можете активировать опцию BitLooker, чтобы перед началом резервного копирования Veeam анализировал раздел MFT и не копировал блоки, помеченные как удаленные.
В статье «Вышла новая версия решения Veeam Backup FREE Edition: краткий обзор» более детально рассказывается, как работает BitLooker. В настоящее время эта технология ожидает получения патента.
Новые возможности работы с гостевыми ОС
Оптимизация взаимодействия с гостевыми ОС. В инфраструктуре резервного копирования, построенной на базе Veeam Backup & Replication v9, появился новый компонент — Guest Interaction Proxy. Он предназначен для взаимодействия сервера резервного копирования с гостевой ОС (раньше это взаимодействие осуществлялось самим сервером резервного копирования, что сильно увеличивало нагрузку на него). Если вы настроите автоматический выбор машины для роли Guest Interaction Proxy, Veeam выберет менее загруженную машину, находящуюся на той же площадке, что и ВМ, для которой планируется выполнить резервное копирование. Такой подход упрощает резервное копирование в удаленных офисах и филиалах (взаимодействие компонентов происходит быстрее, когда они находятся на одной площадке) и не требует использования VMware VIX.
Исключение ненужных файлов при резервном копировании. Эта возможность является частью технологии BitLooker: при резервном копировании Veeam также анализирует раздел MFT и создает кэш в памяти прокси-сервера, в котором помечает, какие файлы и папки нужно исключить. В ходе резервного копирования чтение данных происходит одновременно с исходной ВМ и из кэша. Важно отметить, что исключение файлов возможно только если вы активировали опцию резервного копирования с учетом состояния приложений (application-aware image processing). При этом исключение множества маленьких файлов обрабатывается медленнее, чем исключение нескольких больших файлов того же размера, ибо обработка исключений увеличивает нагрузку на прокси-сервер. Например, чтобы исключить из резервной копии 100 000 файлов, потребуется 400 МБ памяти на прокси-сервере.
Настройка копирования полного бэкапа в задании переноса
Ну и еще одна операция теперь автоматизирована — раньше для создания полного бэкапа для задания переноса резервной копии (backup copy job) пользователи использовали скрипт PowerShell, а теперь можно просто поставить галочку Read the entire restore point from source backup instead of synthesizing it from increments на шаге Target при настройке задания.
Эта опция полезна для СХД с невысокой производительностью, на которых преобразовывать файлы, синтезируя полный бэкап из инкрементальных, неэффективно, а гораздо удобнее скопировать полный бэкап.