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 позволяет работать с программой на устройствах с сенсорным экраном.
Минимальные системные требования
• Процессор 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, которая не была опубликована и лицензирована корпорацией Майкрософт, активация не будет работать, поскольку корпорация Майкрософт не сможет установить соответствие между профилем оборудования вашего компьютера и вашим ключом продукта.
Acronis True Image Home 11
- Acronis True Image Home 11
- Что такое Acronis TI Home 11
- Что нового в Acronis TI Home 11
- Резервное копирование
- Восстановление данных
- Зона безопасности Acronis
- Восстановление при загрузке
- Очистка системы
.TIBX — Расширение файла
Расширение файла .tibx связано с Acronis True Image 2020, популярным программным обеспечением для резервного копирования и восстановления. Представленные как новый тип формата файлов резервного копирования, файлы .tibx предлагают расширенные функции и возможности для защиты данных и восстановления.
История
Разработка расширения файла .tibx может быть прослежена до выпуска Acronis True Image 2020. Эта версия программного обеспечения внесла значительные улучшения в технологиях резервного копирования и восстановления, включая введение формата файла .tibx.
Описание
Расширение файла .tibx представляет собой файл резервной копии, созданный Acronis True Image 2020. Эти файлы содержат полный снимок данных пользователя, включая операционную систему, приложения, настройки и файлы. Целью создания файлов .tibx является предоставление пользователям надежного и эффективного способа защиты своих данных от сбоев аппаратного обеспечения, проблем с программным обеспечением или случайного удаления.
Acronis True Image 2020 использует расширенные алгоритмы сжатия и шифрования, чтобы гарантировать, что файлы резервного копирования являются компактными, безопасными и легко восстановившимися. Файлы .tibx могут храниться на локальных устройствах хранения, внешних дисках, сетевых местах или службах облачного хранения, поддерживаемых Acronis True Image.
Опубликованные спецификации
Акронис публично не опубликовал подробные спецификации формата файла .tibx. Точные технические характеристики и внутренняя структура файлов являются собственными и специфичными для программного обеспечения True Image Acronis.
Как открыть и использовать?
Чтобы открыть и использовать файлы .tibx, вам понадобится Acronis True Image 2020 или более поздняя версия программного обеспечения. Следуй этим шагам:
- Запустите Acronis True Image на вашем компьютере.
- Нажмите на опцию «Backup» или «Восстановление», в зависимости от того, хотите ли вы создать новое резервное копирование или восстановить из существующей резервной копии.
- Выберите файл .tibx в качестве источника или пункта назначения, в зависимости от ваших потребностей в резервном копировании или восстановлении.
- Следуйте инструкциям на экране, чтобы завершить процесс резервного копирования или восстановления.
Как преобразовать?
Файлы .tibx, созданные Acronis True Image 2020, не предназначены для преобразованы в другие форматы файлов. Они служат запатентованными файлами резервного копирования, специфичными для программного обеспечения True Image Acronis, и могут использоваться только в среде программного обеспечения.
Безопасен ли файл, вирус или шпион?
Расширение файла .tibx по своей природе не является небезопасным, вирусом или шпионом. Это законный формат файла резервного копирования, введенный Acronis True Image 2020. Однако важно убедиться, что файлы .tibx хранятся надежно и защищены от несанкционированного доступа или модификации.
Как и в случае с любыми файлами резервного копирования, крайне важно принимать надлежащие меры безопасности, такие как удержание компьютера и резервных устройств хранения в бесплатном от вредоносных программ, использование прочных паролей для защиты ваших резервных копий и хранение файлов резервного копирования в безопасных местах.
Acronis Inc.
- .metadata — Расширение файла
- .tibx — Расширение файла
Tibx или не tib(x): вот в чем вопрос… 28.03.2023 15:17
Сегодня я хочу поговорить о том, каких преимуществ в вопросах резервного копирования и аварийного восстановления можно добиться за счет смены архитектуры архива и правил хранения информации. Разумеется делать я это буду на примере нового формата архивов, который используют продукты КИБЕРПРОТЕКТ. Из интересного сразу выделю, что мы добились увеличения плотности до 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 линии обороны с разной длинной цепочки в каждой и периодически отчуждайте экспортированные/реплицированные резервные копии в сухое и теплое место, в здании с другим цветом стен. Это важно, потому что космические лучи не дремлют.
Этой статьей я хотел осветить внутренние механики работы нашего архива, а также подчеркнуть его плюсы при работе с длинными инкрементами. Возможно, вы посмотрите на такие сценарии работы немного под другим углом, и эта информация позволит оптимизировать ваши планы резервного копирования, и, как результат, немного улучшит качество вашей жизни.
Пользуясь случаем, хочу поблагодарить нашего системного архитектора Алексея Сергеева за ценные комментарии в процессе подготовки данного материала. Всем пока и до новых, волнительных встреч.
Резервное копирование с помощью программы Acronis True Image 2020
Как создать резервную копию системного раздела с помощью Acronis True Image Home 2020. Установка программы, подготовка раздела для хранения резервных копий и дополнительные настройки резервного копирования
Введение
Продуктами фирмы Acronis я пользуюсь 10 лет. Каждый год я покупаю обновление для Acronis True Image. Acronis Disk Director с такой частотой не обновляют. При администрировании рабочих станций, а также в учебном процессе я использую и штатные средства резервного копирования Windows, и Acronis True Image и корпоративные решения Acronis, а также средства резервного копирования других разработчиков. Но данная статья посвящена программе Acronis True Image 2020, а именно резервному копированию системного раздела.
Acronis True Image Home 2020 – это программный комплекс, в который входят средства, позволяющие создавать резервные копии операционной системы, приложений, пользовательских настроек и всех имеющихся данных, средства для уничтожения информации, создания загрузочных дисков, выполнения «небезопасных» операций в операционной системе и др.
Резервные копии, создаваемые программой Acronis True Image 2020, имеют расширение TIBX. По умолчанию они создаются с использованием сжатия данных, поэтому требуется гораздо меньше дискового пространства для их хранения. Степень сжатия всегда можно настроить перед запуском резервного копирования.
Данные из резервных копий формата TIBX можно восстановить только с помощью версии программы Acronis True Image 2020. При попытке восстановить резервную копию формата TIBX более ранней версией будет выведено сообщение Рис.1

Рис.1 Невозможность восстановление резервной копии формата TIBX версией Acronis True Image 2019
Для непрерывных резервных копий, заверенных, на уровне файлов, а также резервных копий, сохраненных на CD/DVD/Blu-ray, FTP или в Зоне безопасности Acronis продолжает использоваться формат TIB.
Системные требования
В данной статье рассматривается версия Acronis True Image 2020 build 22510 для Windows, выпущенная 21 ноября 2019 года, поэтому требования для версии Acronis True Image 2020 для Mac не описываются.
- Процессор Pentium с тактовой частотой не менее 1 ГГц.
- 1 Гбайт ОЗУ.
- 3,5 ГБ свободного пространства на жестком диске.
- Привод CD-RW/DVD-RW или флэш-накопитель USB для создания загрузочных носителей
- Мышь или иное указывающее устройство (рекомендуется).
Поддерживаемые устройства хранения
- Жесткие диски (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, FireWire (IEEE-1394), eSATA, SCSI и PC card
Поддерживаемые операционные системы
- Windows 7 SP1
- Windows 8
- Windows 8.1
- Windows 10
Используя загрузочный носитель Acronis True Image Home 2020, можно осуществлять резервное копирование и восстановление дисков или разделов на компьютере под управлением любой операционной системы Windows или Linux.
Поддерживаемые файловые системы
- FAT16/32;
- NTFS;
- Ext2/Ext3/Ext4;
- ReiserFS;
- Linux SWAP;
- HFS+/HFSX.
Файловые системы Ext2/Ext3/Ext4, ReiserFS, HFS+/HFSX и Linux SWAP поддерживаются только для операций резервного копирования и восстановления дисков или разделов с использованием загрузочного носителя Acronis.
Установка Acronis True Image 2020
Пробная версия Acronis True Image 2020 может быть использована в течение 30 дней со следующими ограничениями:
- клонирование дисков отключено;
- при загрузке с носителя Acronis доступно только восстановление, нельзя создать резервную копию. Создание резервной копии доступно в пробной версии в среде Windows.
Установка
Запустить файл инсталляции Acronis True Image 2020

Рис.2 Завершение установки программы Acronis True Image
Нажать кнопку Установить.
По окончании инсталляции запустить приложение Acronis True Image 2020.

Рис.3 Завершение установки программы Acronis True Image
Принять лицензионное соглашение и нажать кнопку ОК.

Рис.4 Лицензионное соглашение
Ввести серийный номер в окне Активация и нажать кнопку Активировать. Если планируется использовать пробный режим, нажать соответствующую кнопку. В данной статье будет описана зарегистрированная версия Acronis True Image 2020. На рисунке ниже представлена активация продукта с ключом обновления, поэтому необходим ввод лицензионного ключа новой версии, а также предыдущей.

Рис.5 Активация программы Acronis True Image 2020

Рис.6 Главное окно программы Acronis True Image 2020
Подготовка раздела для хранения резервных копий
Перед тем, как запустить средство создания резервной копии системного раздела, необходимо убедиться в наличии места хранения для резервной копии. Это может быть отдельный раздел жесткого диска, внешний носитель информации, сетевое хранилище, либо можно воспользоваться облачным хранилищем Acronis, в зависимости от редакции программы, которая приобретена.
В данной статье будет описан вариант создания отдельного раздела для хранения резервных копий за счет сжатия системного раздела.
Создать второй раздел жесткого диска, за счет свободного пространства системного раздела
Запустить оснастку Управление дисками
Данную оснастку можно запустить разными способами:
- Через Панель управления. Открыть раздел Администрирование через диалоговое окно стандартной Панели управления. Далее найти в конце списка доступных оснасток Управление компьютером и запустить оснастку Управление дисками.
- С помощью окна Выполнить. Данное окно можно открыть, используя сочетание клавиш Win +R или кликнув правой клавишей мыши по кнопке windows и выбрав команду Выполнить или выбрать через меню Все приложения > Служебные …. > Выполнить
- Набрать в окне Выполнить название оснастки compmgmt.msc для запуска оснастки Управление компьютером или сразу diskmgmt.msc для запуска оснастки Управление дисками

Рис.7 Запуск окна Выполнить
- Можно запустить оснастку, кликнув правой клавишей мыши ко кнопке Windows и выбрать Управление дисками.
Оснастка Управление дисками позволяет управлять логическими разделами на таких носителях, как жесткий диск, USB-накопитель или оптический привод. Через Управление дисками можно создавать и удалять разделы, или, если это необходимо, форматировать их.
- выбрать системный раздел (в приведенном примере диск С:) и ПКМ вызвать контекстное меню
- В контекстном меню выбрать команду Сжать том

Рис.8 Оснастка Управление дисками
- В открывшемся окне дождаться окончания опроса. Затем в появившемся окне в строке Размер сжимаемого пространства указать количество свободного места и нажать Сжать

Рис.9 Оснастка Управление дисками
- Щелкнуть ПКМ по нераспределенному пространству жесткого диска и выбрать команду Создать простой том.

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

Рис.11 Мастер создания простых томов оснастки Управления дисками
- Просмотреть выбранные параметры и нажать кнопку Готово.
- Перезагрузить компьютер. Раздел для хранения резервной копии готов.
Создание резервной копии системного раздела
- Запустить программу Acronis True Image 2020
- В главном окне программы на боковой панели выбрать раздел Резервное копирование
Раздел Резервное копирование и восстановление обеспечивает быстрый доступ ко всем функциям программы, связанным с резервным копированием и восстановлением данных.

Рис.12 Выбор раздела Резервное копирование
- Далее необходимо указать, что нужно резервировать. Для этого щелкнуть по источнику резервного копирования.

Рис.13 Выбор источника резервного копирования
- В окне Источник резервного копирования выбрать Диски и разделы

Рис.14 Выбор источника резервного копирования
- Установить флажок в чекбоксе системного раздела. Флажки с других разделов необходимо убрать. Нажать кнопку ОК.

Рис.15 Выбор источника резервного копирования
- Далее необходимо выбрать место назначения резервной копии, щелкнув по разделу Выбор хранилища

Рис.16 Выбор хранилища для резервных копий
- В окне Место назначения резервного копирования выбрать Обзор.

Рис.17 Выбор хранилища для резервных копий
- Раскрыть узел Этот Компьютер и выбрать нужный раздел для хранения резервных копий, нажать кнопку ОК.

Рис.18 Выбор хранилища для резервных копий

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

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

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

Рис.22 Раздел Активность
Отдельные дополнительные настройки резервного копирования
В разделе Параметры можно указать дополнительные настройки для будущей резервной копии.

Рис.23 Раздел Параметры
Ниже в статье рассмотрены отдельные дополнительные настройки резервного копирования.
В разделе Расписание можно настроить периодичность создания резервных копий. По умолчанию система Acronis предлагает создавать резервные копии еженедельно. А также раскрыв узел Дополнительные настройки, можно указать вариант запуска резервного копирования при простое компьютера, возможности программы выводить компьютер из спящего режима, согласно заданному расписанию резервного копирования и др.

Рис.24 Раздел Расписание
В разделе Схема можно указать методы резервного копирования. Acronis True Image позволяет выполнять следующие варианты резервного копирования.
1 вариант. Полное резервное копирование. В этом варианте:
- в архив включаются все архивируемые данные;
- созданный архив является полной, самостоятельной базой;
- созданная база является основой для других вариантов резервного копирования.
2 вариант. Инкрементное резервное копирование. В этом варианте:
- созданная база содержит только изменившиеся за определенный период данные;
- период изменений определяется текущим временем и временем создания последней резервной копии любого варианта;
- созданная база содержит не все архивируемые данные;
- для восстановления необходимы все предыдущие инкрементные резервные копии и полную резервную копию, созданную по 1 варианту.
3 вариант. Дифференциальное резервное копирование. В этом варианте:
- создается отдельный файл;
- созданный файл содержит все изменения данных по отношению к последней полной резервной копии (1 вариант).

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

Рис.26 Раздел Дополнительно
В разделе Защита резервной копии раздела Дополнительно можно установить пароль для будущей резервной копии. Нельзя изменить параметры защиты для существующей резервной копии.
В разеделе Производительность раздела Дополнительно можно настроить степень сжатия резервной копии в случае ограничения свободного пространства. А также приоритет операции резервного копирования.

Рис.27 Выбор уровня сжатия резервной копии

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

Рис.29 Настройка параметра Обработка ошибок