Tib и tibx в чем разница

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

Этот параметр определяет формат резервных копий, создаваемых планом резервного копирования. Можно выбрать между новым форматом (Версия 12 ), созданным для быстрого резервного копирования и восстановления, и устаревшим форматом ( Версия 11 ), сохраненным для обратной совместимости и специальных случаев. После применения плана резервного копирования этот параметр будет невозможно изменить.

Этот параметр не применим к резервным копиям почтового ящика. Резервные копии почтового ящика всегда имеют формат «Версия 12».

Значение по умолчанию: Автоматический выбор.

Для этого укажите Учетная запись для входа службы агента. Можно выбрать один из следующих вариантов:

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

В большинстве случаев для быстрого резервного копирования и восстановления рекомендуется новый формат. Каждая цепочка резервных копий (полного или дифференциального копирования, и всех зависящих от них инкрементных резервных копий) сохраняется в один файл .tibx.

С этим форматом правило хранения По общему размеру резервных копий не применимо.

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

Также используйте этот формат (с любой схемой резервного копирования, за исключением Всегда инкрементное (один файл) ) для полного, инкрементного и дифференциального резервного копирования в отдельные файлы.

Этот формат выбирается автоматически, если местом назначения резервной копии (или местом назначения репликации) является управляемое хранилище с включенной дедупликацией. Если изменить формат на Версию 12 , резервное копирование не будет выполнено.

Невозможно создать резервную копию групп обеспечения доступности баз данных (DAG), используя формат архива «Версия 11». Резервное копирование группы обеспечения доступности баз данных поддерживается только в формате архива «Версия 12».

Формат резервной копии и файлы резервных копий

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

Формат резервной копии Версии 11

Один файл .tib и один файл метаданных .xml

Несколько файлов .tib и один файл метаданных .xml (традиционный формат)

Формат резервной копии Версии 12

Один файл .tibx на каждую цепочку резервных копий (полное или дифференциальное резервное копирование и все зависящие от них инкрементные резервные копии)

Изменение формата резервной копии на 12 (.tibx)

При изменении формата резервной копии с версии 11 (формат .tib) на версию 12 (формат .tibx) имеет место следующее:

Следующая резервная копия будет полной.
В хранилищах резервных копий, которые доступны для обзора в диспетчере файлов (например, локальные или сетевые папки), создается новый файл с расширением .tibx. Новый файл имеет имя исходного файла с добавлением суффикса _v12A.
Правила хранения и репликации применяются только к новым резервным копиям.
Старые резервные копии не удаляются и остаются доступными на вкладке Хранилище резервных копий . Их можно удалить вручную.
Старые облачные резервные копии не будут занимать пространство в пределах квоты Облачное хранилище данных .
Старые локальные резервные копии будут занимать пространство в пределах квоты Локальная резервная копия до тех пор, пока не вы не удалите их вручную.

Дедупликация в архиве

Формат резервной копии версии 12 поддерживает дедупликацию в архиве, которая обеспечивает указанные ниже преимущества.

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

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

Дата последней сборки: 6 марта 2023 г.

Веб-справка по Acronis Cyber Protect 15 Обновление 6 . © Acronis International GmbH, 2003-2023

Tibx или не tib(x): вот в чем вопрос…

Сегодня я хочу поговорить о том, каких преимуществ в вопросах резервного копирования и аварийного восстановления можно добиться за счет смены архитектуры архива и правил хранения информации. Разумеется делать я это буду на примере нового формата архивов, который используют продукты КИБЕРПРОТЕКТ. Из интересного сразу выделю, что мы добились увеличения плотности до 5 раз! (это реальный показатель), а также повысили скорость, удобство и надежность. Не обошлось конечно и без проблем обратной совместимости и некоторых нюансов. Под катом — отличия нового формата, примеры оптимизаций, которые мы сделали, подробнее о плюсах инкрементного бэкапа, а также рекомендации по работе с резервными копиями в современных условиях. Всех заинтересованных приглашаю обсудить архитектурные подходы к работе с резервными копиями.

Ранее, когда деревья были большие, а сервер управления еще не умел в web, резервные копии хранились в предыдущем, 11 формате (tib). Он был относительно простой по своей структуре, неплохо поддерживал сжатие данных, каждая новая копия создавала новый файл в хранилище, а дедупликация работала на уровне управляемого (узлом хранения) хранилища.

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

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

Так появился архив формата 12 / Archive 3 /.tibx

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

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

Далее была добавлена дедупликация на источнике, в рамках файла резервной копии (одной цепочки полная + дифференциальная + инкременты). Таким образом, при хранении длинных цепочек инкрементов, эффективность хранения данных в архиве очень сильно выросла. Больше данных, больше база дедупликации. Работа по дедупликации и сжатию происходит прямо на агенте во время резервного копирования, он держит базу дедупликации в своей оперативной памяти и передает в архив только уникальные блоки. Блоки, кстати, переменного размера, а для работы дедупликации не нужно какое-то особое хранилище: агент будет сжимать и дедуплицировать сохраняемый архив одинаково – будь то локальный диск, smb, nfs или управляемое хранилище.

Плотность

Таким образом, благодаря сжатию и дедупликации на агенте, мы можем иногда получить эффективность уплотнения данных до 1:5 (данные реальные — не маркетинг). Например, в сценарии с резервным копированием рабочей станции на базе Windows 10: диск 256 ГБ, объем данных — 50 ГБ, получаемый архив занимает 12 ГБ.

Но стоит создать новую полную копию, как вся наша экономия превращается в тыкву, так как рядом создается новый файл архива размером в те же самые 12 ГБ. Поэтому хочу еще раз отметить, что максимальная эффективность хранения данных достигается в рамках одной цепочки полная + N инкрементов.

Скорость

Про хранение все понятно: полная + инкременты — это хорошо для уплотнения, но если посмотреть на резервное копирование, то тут мы тоже поймем, что создание инкрементной копии происходит на порядок быстрее, чем создание полной копии. И чем больше объём исходных данных, тем эффективнее использовать именно инкрементный подход резервного копирования. Почтовый сервер весит 10ТБ, его полная копия может спокойно выполняться сутки и займет 3-4 ТБ. А инкремент можно сделать за 0,5-2 часа, и занимать он будет порядка 50-200 ГБ, которые к тому же будут серьезно изъедены сжатием и дедупликацией. Если мы организуем цепочку в 60 копий, то получаем возможность, при необходимости, откатывать почтовый сервер на 2 месяца назад затрачивая в день не более 2-х часов на резервное копирование и примерно половину объема исходных данных на хранение всей цепочки резервной копии.

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

Восстановление

Плотность и скорость — это хорошо, но как же восстановление? Собрать вместе 60 копий и восстановить эти данные — это допустимо для холодного хранилища и слишком дорого для основного (боевого) сценария восстановления. Но это не совсем так, вернее в нашем случае — совсем не так. Благодаря хитрому хранению метаданных для каждой резервной копии (архив = множество резервных копий/точек восстановления) и принципу хранения данных, чем-то похожему на игру «маджонг»: при восстановлении даже очень далекого инкремента мы сразу понимаем путь (Самурая) для оптимального восстановления в один проход. Тем самым, даже на длинных цепочках резервных копий мы практически не теряем в скорости восстановления данных. Судя по нашим тестам и заверениям коллег из отдела разработки, заметная деградация скорости восстановления начинается после 500 (инкрементных) резервных копий в архиве. Как по мне, то 500 это, наверное, все же чересчур, но 100 копий в одной цепочке – это вполне себе рабочий сценарий.

Зачем же нам дифференциальная копия?

В связи с таким подходом к обеспечению эффективности инкрементных копий реализовывать дифференциальную копию для архива мы вообще не планировали, но поддержка обратной совместимости заставила внести изменения в планы. В итоге дифференциальная копия ломает структуру архива, создавая новый файл, так же как и полная копия, но имеет меньший размер. Новые инкрементные копии уже прилипают к этой дифференциальной копии и раздувают ее. Эффективность дедупликации тут сильно падает, так как она начинает работать еще в рамках дополнительной цепочки дифф+инкременты. Поэтому дифференциальную копию имеет смысл использовать только на очень больших цепочках, раз в 100 точек (тут она даст хоть какой-то выигрыш во времени восстановления) или не использовать вообще, последнее подчеркиваю.

Правила и ротация

Про скорость и плотность мы договорились: делаем длинные цепочки инкрементов и радуемся жизни, но как же быть с правилами хранения и ротации резервных копий?

Тут тоже есть свои хитрости. Если в правилах хранения указано хранить не более 60-и резервных копий, то при создании 61-й копии нам придется удалять самую первую, а она (неожиданно!) – полная и от нее зависят как минимум 6 следующих(неделя), а как максимум и все остальные 60 резервных копий. Ситуация не очень приятная. Обычно резервная копия в таком случае просто помечается на удаление и ждет момента, когда все зависимые резервные копии тоже пометят на удаление (либо выполняется дефрагментация — то, что у нас всегда называлось «консолидация” цепочки, что затратно по ресурсам и требует дополнительного места на диске) и только потом, вся цепочка со свистом удаляется из хранилища. Но в схеме «Всегда инкремент» это произойдет никогда, и до самой тепловой смерти вселенной мы будем растить архив, пока он не захватит все доступное пространство в хранилище. Звучит классно. Но мы так не делаем, вернее мы делаем совсем не так.

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

Рассмотрим этот вопрос на примере. Пусть 1-го сентября у нас была полная копия, а после нее 2 месяца каждый день создавались инкременты. Настал день Х и полную копию попросили на выход, агент взялся за дело и объединил вместе две точки восстановления от 1-го и 2-го сентября и на выходе получил полную копию, но по состоянию на 2-е сентября. Магия.

Таким образом, в цепочках «всегда инкремент» мы действительно можем хранить только N точек восстановления и не иметь лишнего «мусора» в архиве, который хранится из-за зависимостей и блокировок. Храним только полезные данные.

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

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

А компот…то есть надежность?

Так-с, хорошо, скорость, плотность, ротация – здорово, но как же надежность?

Это ключевой вопрос, который мы слышим от заказчиков. Все знают, что схема «всегда инкремент» — это как непьющий коллега. Вроде все хорошо, но какой-то он «ненадежный». Кто-то, где-то повредит одну из резервных копий, диск даст ошибку, или появятся пресловутые космические лучи и все, боевое восстановление почтового сервера из единственного архива на NASе приведет к новой записи в трудовой книжке системного администратора. Вот тебе и эффективное хранение и быстрое восстановление. И тут трудно спорить, потому что полная копия, всегда лучше, чем инкремент — это совершенно очевидно. И здесь я хочу поделиться с вами некоторой информацией о структуре нашего архива и опытом эксплуатации нашей системы. А нужные выводы, надеюсь, вы уже сделаете сами.

Архив tibx под капотом состоит из последовательности сущностей и на высоком уровне — это структура зависимостей. Например, есть архив с определенным ID, внутри него есть резервные копии/точки восстановления (это все одно и то же) каждая со своим ID и в каждой из резервных копий есть блоки переменного размера (как правило, это несколько десятков кБ). Каждая из этих сущностей при записи финализируется контрольной суммой и некой хэш-суммой, плюс каждая из резервных копия содержит информацию о своих «близких родственниках». В итоге, при каждой операции резервного копирования, агент быстро проверяет структуру архива и как он «финализирован» при последнем резервном копировании. Если все хорошо, то в архив добавляется новая резервная копия с новым ID и наполняется блоками свежих данных, после чего создаются метаданные для быстрого восстановления, резервная копия финализируется, архив закрывается. Если дополнительно использовать валидацию архива как дополнительный этап политики резервного копирования или как отдельную задачу, то проверяется и целостность данных — их соответствие записанным контрольным суммам.

Если агент обнаружит, что резервная копия финализирована некорректно, то он, по возможности, пытается дописать данные с того места, где запись закончилась в прошлый раз. Если агент обнаруживает нарушение структуры и это относится к последней резервной копии, то агент откатывается до последней финализированной копии, исправляет структуру (как будто и не было предыдущей попытки) и потом записывает новую копию поверх не финализированной резервной копии в конце архива. Самый типовой сценарий нарушения структуры архива — это ошибки на уровне файловой системы тома хранения, ошибки работы RAM или внешнее воздействие — ручное удаление/изменение части архива, например, в Проводнике). В этом случае архив переводится в режим «только чтение» и восстановление возможно (не всегда, в зависимости от типа повреждения) только для тех точек восстановления, которые предшествуют точке со сбоем. Здесь надо отметить, что алгоритмы работы архива могут предотвратить искажение данных даже при некоторых типах ошибок оперативной памяти (например, инвертирование битов), и я считаю, что это очень круто.

В заключение

Несмотря на все сказанное ранее, хочу напомнить простые вещи: хоть наш архив и довольно надежный, хранить все яйца в одной корзине не следует. Выполняйте периодическую репликацию архивов на дополнительные носители, сетевые папки, узлы хранения, выполняйте регулярную проверку архивов чтобы контролировать согласованность данных. Для контроля согласованности данных в архиве используйте валидацию. Держите 2-3 линии обороны с разной длинной цепочки в каждой и периодически отчуждайте экспортированные/реплицированные резервные копии в сухое и теплое место, в здании с другим цветом стен. Это важно, потому что космические лучи не дремлют.

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

Пользуясь случаем, хочу поблагодарить нашего системного архитектора Алексея Сергеева за ценные комментарии в процессе подготовки данного материала. Всем пока и до новых, волнительных встреч.

www.timosh.ru

Acronis True Image 2020 — это интегрированный пакет программ, гарантированно обеспечивающий безопасность всей информации на компьютере. С его помощью можно создавать резервные копии документов, фотографий, электронной почты, выбранных разделов или целого диска, включая операционную систему, приложения, настройки любых данных.

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

В Acronis True Image 2020 добавлен новый и надежный формат резервных копий — TIBX. Формат TIBX используется для создания резервных копий дисков на внутренние и внешние жесткие диски и сетевые хранилища.

При создании резервных копий в формате TIBX поддерживается использование всех схем резервного копирования. В отличие от формата TIB, при использовании которого каждая версия резервной копии сохранялась в виде отдельного файла, при использовании формата TIBX версии полных и дифференциальных резервных копий сохраняются как отдельные файлы, а версии инкрементных резервных копий автоматически объединяются с базовыми резервными копиями (полными или дифференциальными).

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

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

Для резервных копий:

• резервные копии на уровне файлов;
• непрерывные резервные копии;
• заверенные резервные копии;
• резервные копии, сохраняемые на CD/DVD/Blu-ray, FTP или в Зону безопасности Acronis.

Acronis True Image 2020 продолжает использоваться формат TIB.

Acronis True Image 2020 позволяет создать загрузочный диск CD-R/DVD-R или USB-накопитель для резервного копирования и восстановления дисков или разделов на компьютере с любым процессором Intel или AMD и любой операционной системой для ПК, включая Linux®. Компьютеры Apple Macintosh с процессором Intel не поддерживаются.

Интерфейс Acronis True Image 2020 позволяет работать с программой на устройствах с сенсорным экраном.

Acronis 2020

Минимальные системные требования

• Процессор Pentium с тактовой частотой 1 ГГц.
• 1 ГБ ОЗУ.
• 3,5 ГБ свободного места на диске
• Дисковод CD-RW/DVD-RW или USB-накопитель для создания загрузочного носителя (требуется около 600 МБ свободного пространства).
• Разрешение экрана 1024 x 768.
• Мышь или другое указывающее устройство (рекомендуется).

Внимание! Для развертываний на виртуальных машинах не гарантируется успешное резервное копирование и восстановление.

Для запуска Acronis True Image 2020 необходимы права администратора.

Поддерживаемые операционные системы

• Windows 10 (все выпуски, включая обновление за май 2020, кроме выпуска Windows IoT и Windows 10 с долгосрочным обслуживанием)*
• Windows 8.1 (кроме выпусков Windows Embedded)
• Windows 8 (кроме выпусков Windows Embedded)
• Windows 7 SP1 (все выпуски)
• Windows Home Server 2011
* Бета-версии не поддерживаются .

Внимание! Успешное восстановление гарантируется только для поддерживаемых операционных систем. Для других операционных систем можно создать резервные копии в посекторном режиме, но они могут перестать загружаться после восстановления.

Поддерживаемые файловые системы

• NTFS;
• Ext2/Ext3/Ext4
• ReiserFS(3)*
• Linux SWAP*.
• HFS+*/HFSX*
• FAT16/32/exFAT* **

* Файловые системы поддерживаются только для операций резервного копирования и восстановления дисков или разделов.
** Файловые системы поддерживаются только для операций восстановления дисков или разделов (без изменения размера).
Если файловая система не поддерживается или повреждена, Acronis True Image 2020 будет копировать данные в посекторном режиме.

Поддерживаемые носители данных

• Жесткие диски (HDD)*
• Твердотельные накопители (SSD)
• Сетевые устройства хранения
• FTP-серверы**
• CD-R/RW, DVD-R/RW, DVD+R (включая двухслойные DVD+R), DVD+RW, DVD-RAM, BD-R, BD-RE
• Устройства хранения USB 1.1/2.0/3.0, eSATA, FireWire (IEEE-1394), SCSI и PC Card

* Ограничения на операции с динамическими дисками

• Создание Зоны безопасности Acronis на динамических дисках не поддерживается.
• Восстановить динамический том как динамический том, изменив размер вручную, невозможно.
• Try&Decide® не может использоваться для защиты динамических дисков.
• Операция клонирования дисков не поддерживается для динамических дисков.

Скачать программу Acronis True Image 2020 бесплатно

Размер архива: 475,3 МБ
Интерфейс при установке на русскую версию Windows – русский
Активация: О’кей
Сайт разработчика: www.acronis.com/ru-ru/

Примечание.
При клонировании (восстановлении) ранее активированных операционных систем Windows 8/8.1/10 на другой жесткий диск, на тот же жесткий диск, заменив материнскую плату, на новый (другой) компьютер активация (лицензия) может не работать, поскольку ключ продукта типа уже использован на другом компьютере или на большем числе компьютеров, чем это допускается условиями лицензионного соглашения на использование программного обеспечения корпорации Майкрософт. Если вы используете нелицензионную копию Windows, которая не была опубликована и лицензирована корпорацией Майкрософт, активация не будет работать, поскольку корпорация Майкрософт не сможет установить соответствие между профилем оборудования вашего компьютера и вашим ключом продукта.