Pull to refresh

Comments 100

Расскажите, пожалуйста, True Image научился наконец делать образ скрытых разделов?
Например, ситуация: на ноутбучном жёстком диске есть recovery partition, который хотелось бы забэкапить (только этот раздел, а не весь диск). Но если в True Image 2014 пойти в «Disk Backup», то там в списке доступных разделов его просто нету. Что делать в этом случае?
Спасибо.
Снять атрибут скрытый, забакапить, вернуть. Всё равно раздел не меняется…
По идее должен быть виден, если там не какой-то специальное скрытие? У себя относительно недавно видел скрытый раздел от Sony, потом снес его правда. Если у вас не виден, сможем в личке обсудить как получить отчет с вашего компьютера? Вероятно в ближайшем обновлении сможем поправить.
Если отбросить более тесную интеграцию с облачным хранилищем, то какие объективные преимущества у 2014 версии перед 2012?

Пользуюсь 2012 и по фича листу с сайта не могу понять, есть ли мне реальный смысл обновляться.
Проделана серьезная работа по багфиксу клиентских проблем. В частности, значительно улучшена поддержка SSD.
Смысл есть, только он есть следствие некоторой, кхм, нечистоплотности фирмы Акронис.
При выпуске каждой новой версии фирма Акронис полностью сворачивает работы по исправлению ошибок в старших версиях.
Термин же «нечистоплотность» появляется когда к этому факту добавляется то, что фирма Акронис новые версии не предоставляет зарегистрированным пользователям старших версий, но в дополнение к отказу исправления ошибок в старших версиях — и продолжая исправлять только в новых версиях ошибки, выявленные в старших версиях — фактически принуждает пользователей старших версий покупать новые версии.
Да, исправлена масса мелочей, значительно упрощен процесс покупки, регистрации, но это больше для информации скорее.
UFO just landed and posted this here
Ну не совсем так и не только это. Не только покупка новой версии, переход на премиум подписку, покупка облачной подписки, продление и так далее. Переход на новую версию заработает с выходом еще более новой версии, сейчас заложена необходимая поддержка.
В новых версиях TI пофиксили проблему с неправильным разворачиванием бэкапов линух-разделов? Там груб криво копировался раньше, приходилось руками допиливать. Если пофиксили давно — просьба не пинать. Консерватор, редко обновляю список исошников на переносном харде.
Так на вскидку сложно сказать сейчас, было довольно много исправлений, вероятно это тоже поправили. Я попросил проверить на всякий случай, отпишусь как будут результаты.
Да, при ресторе линуксовых партиций линкусовые лоадеры типа GRUB, могут слетать.

Лоадер относится к загрузочности системы, а у нас виндовое приложение, для полноценной работы с линуксом есть специальные программы типа АБР for Linux
Спасибо за наводку. Будем посмотреть в строку ABP. Просто было предположение, что раз умеет бэкапить — должен уметь разворачивать ))
True Image Home изначально не нацелен на полноценную поддержку линуксов (поддерживается только бэкап/рестор на уровне дисков/разделов — kb.acronis.com/content/34862).

При использовании True Image Home даже клонирование портит линуксовый загрузчик — kb.acronis.com/content/4974. Но его вполне несложно заново реактивировать (http://kb.acronis.com/ru/node/1686)

P.S. — К сожалению, статьи только на английском.
Да я уже проверил, как работает Acronis Backup Recovery for Linux. После разворачивания образа линуха рядом с виндой Grub rescue со стандартной процедурой полуавтоматической реанимации. А вот виндовый загрузчик затёрся намертво, bootrec и подобный софт для восстановления брыкался на неизвестную файловую систему. Помогло только переразвернуть раздел винды заново.
В общем, я молчу про «полноценную поддержку линуха», но могли хотя бы писать русским по белому «вполне вероятно, всё забэкапит, но нихрена не ресторит». А то осадочек остался…
з.ы. отдельное спасибо за интерфейс, перемещаться по которому без мышки физически невозможно. Я понимаю, что там реализовано подключение псевдо-курсора по Ctrl+M, но иногда хочется быстро проTABать до нужной кнопки, а такой возможности просто нет
А можно поподробнее про сценарий? Вы восстанавливаете Linux на раздел, находящийся на том же самом диске, что и винда? Ожидаете, что в результате восстановления в загрузочный сектор будет записан GRUB, бутающийся и в винду, и в линукс?
Есть хард с 3 primary разделами, первый виндовый (2008 сервер), второй помойка ntfs, третий пустой. Разворачиваю линух на последний, указываю, что mbr накатить на этот хард (за неимением других), если это необходимо. Получаю неживой груб, который руками потом реанимирую. Винда после реанимации в нем тоже есть (реанимация заключается в ручном указании раздела с ядром и апдейте груба после загрузки). Только вот после выбора винды в меню загрузчика по дефолту (изменением /etc/default/grub) она не стартует, ссылаясь на отсутствующий winload.exe, а после ребута не появляется и GRUB обратно.
Не, такое ни ABR ни ATIH не умеют. В конце концов, это же backup приложения, а не бут менеджеры.
Чтобы поддержать ваш сценарий, надо сделать следующее:
  1. Восстановить Linux раздел БЕЗ MBR. А то оригинальный MBR с виндой будет безвозвратно затёрт
  2. Загрузиться в бутабельную линусковую медию, замаунтить линуксовый раздел и скопировать через dd MBR в какой-нибудь файлик
  3. Отредактировать grub.cfg и задать chainloader на этот файл
  4. Установить GRUB в MBR через grub-install

Если бы восстанавливали MBR оригинального диска (т.е. с уже установленным мультибутом) этих приседаний не понадобилось бы. Тут основная сложность в том, что ресторный продукт по сути используют для миграции разделов. А это не мейстримное применение. Поэтому надо попотеть (:
В общем, идея была в разработке метода «установки» linux поверх windows по сети, то есть только при наличии удаленного доступа (ssh/rdp) без прямого физического контакта или KVM. Пока с треском провалилась ) Будем подумать дальше
А расскажите по-подробнее, как обеспечивается защита данных, сохраненнёх в облаке от:
1) Повреждения (частично сказали, а технически — какая ФС и система репликации применена?)
2) Злоумышленников
3) Сотрудников вашей компании
4) Спецслужб: Где размещены сервера облака? Под юрисдикцией каких стран вы находитесь? Были ли уже случаи обращения к вам для поиска данных?
Обязаны ли вы сообщать об обнаружении «нечистого» контента в бакапах?
1. Все сервера линуксовые, на ext3, поверх реализована распределенная файловая система. Сохранность обеспечивается N,K алгоритмом, правильно соотношение N,K постоянно автоматически контролируется. В случае утери одной части сразу же запускается алгоритм регенерации. Могу привести пример, довольно давно мы закупили жесткие диски зеленой линии WD, и довольно большой процент их них пришел в негодность за короткий промежуток времени. Так вот, пользовательские данные не были потеряны.

2,3 Тут шифрование на стороне клиента, шифрование протокола, внутренние правила определения прав доступа. Не уверен, что в праве детально это описывать в открытом источнике.

4. В штатах и европе и подчиняются юрисдикциям стран размещения, конечно. Случаев обращения пока не было. Обязаны ли мы сообщать? Такие вопросы регулируются законодательно, мы тут не можем пойти наперекор законам соответствующих стран.
2. Шифрование на стороне клиента — либо ложь, либо умалчивание фактов, в любом случае, если данные сохранённые можно прочитать с другого устройства через веб — значит, ключи у вас сохранены, и при доступе до веб-сервера есть взможность их получить.
Рассматривались ли данные вектора атаки? Защищены ли личные данные пользователей от компрометации «внешних» серверов инфраструктуры?

3. Все ли способы получения ключей авторизации и шифрования со стороны пользователей запротоколированы нестираемым образом?

и в целом, по 2,3 ответ звучит как среднее между «я не знаю» и «у нас ничего нет». я надеюсь, всё-таки это «я не знаю».

4. Таки да, в США вы обязаны сообщать. Вы производите какой-либо анализ содержимого, или просто к вам еще не поступало запросов, и потому вы не задумывались о вашей защите?
Поддержу, тоже очень волнует второй вопрос. Надеюсь при отсутствии настроенного бекапа в облако никакие ключи никому не утекают.
Если я правильно понял вопрос, утекают ли в облако ключи, которые не имеют к нам отношения? Нет конечно.

Есть два ключа, которые могут иметь отношение к Acronis, ваш логин и пароль для авторизации на сайте или сервисе и ключ конкретного бэкапа. Ни тот ни другрй мы не храним. Первый можем помочь восстановить обнулив пароль, второй никак не можем восстановить.
«Нет конечно.» — есть где-либо в EULA это утверждение?
И какая ответственность, в случае обнаружения данной утечки?

Например, crash приложения не сильно позже ввода пароля, и пароль и/или ключ шифрования утек в Microsoft вместе с отчетом об ошибке и минидампом.
Предприняты какие-либо специальные усилия для недопущения этого?
Вот что прописано в EULA:

"...Acronis has no obligation to monitor the use of the Services and/or Data transmitted or stored through the Services."

Насчет краша и дампа, нет, ничего такого специально не делаем, но идея хорошая, спасибо!

Ну и надо понимать еще, цель любого EULA это в первую очередь защита интересов производителя софта.

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

3. Мы не храним пользовательские ключи и если нас просят этот ключ вспомнить, мы ничем не можем помочь. Соотвественно протоколы таких запросов мы не ведем.

4. Нет не производим и к нам не поступало запросов.
Тогда краткий вопрос по реализации шифрования — известно пока, только что используется AES.
1. Какой режим? ECB, CBC, OFB, CFB, CTR, XTS или еще чего?
2. Какой алгоритм генерации ключа из пароля применён?
3. Методика генерации IV?
4. Какой механизм верификации верности пароля — контрольные суммы всего файла целиком, или отдельного блока?
5. Шифруются ли _только_ данные файла, или все метаданные его тоже?
6. Какой алгоритм паддинга используется?
7. Как с поддержкой русских (и других национальных) букв в паролях шифрования? Как с кросс-платформенностью этой радости?
1. CBC
2. генерация случайной последовательности.
3. генерурируем случайную последовательность каждый раз.
4. Пока решили не отвечать.
5. шифруется все.
6. паддинг: мы генерируем случайную последовательность.
7. русские буквы поддерживаются. Код кроссплатформенный, в продакшене windows и linux.
2. То есть, пароль пользователя — инициализатор ГПСЧ? ГПСЧ-то хоть качественный?
3. Для каждого файла свой IV?
4. Странно — это ключевой момент стойкости к перебору. Сокрытие говорит о том, что применён какой-то «быстрый» метод, позволяющий вести ОЧЕНЬ эффективный перебор.
5. В виде одного контейнера? Соответственно, есть известные префиксы для Known-plaintext анализа.
2. Какой-то из стандартных, сейчас точно не вспомню.
3. для каждого блока. В некоторых случаях это меньше файла.
4. От перебора защиты нет, рекомендуется использовать сложные ключи.
5. файла два. Для каждого файла генерируется свой ключ.
Спасибо, за развернутый ответ.
Забыл еще вопрос.
Если у вас для каждого блока свой IV — а _ключ_ для этого блока из пароля — тоже свой?
4. Так вроде ни в одной популярной программе не используется проверка по контрольной сумме всего файла, так как файлы могут быть очень большие, и ждать несколько минут пока софтина скажет, что пароль неправильный (ну раскладку не ту включил юзер) не очень понравится юзеру.

Для стойкости к перебору используют PBKDF2 с большим числом итераций, или аналоги которые с помощью HMAC на основе пароля юзера генерят ключи (в TrueCrypt — 1000 итераций, в RAR — 262 тысяч итераций).

Причем во многих софтинах, как раз расшифровывают контент и ищут определенную фразу (в TrueCrypt в начале зашифрованного блока должно быть TRUE написано). У некоторых видел схему, когда из пароля юзера с помощью PBKDF2 получается ключ, с помощью которого расшифровывают случайносгенеренные IV и ключ, сохраненные в файле, а правильность пароля проверяют по HMAC расшифрованных IV и ключа.
Да в принципе, спасибо, что не как у ZIP! :D
Это я так рассуждал на счет вашего вопроса (просто делаю свой контейнер, и как раз недавно изучал эти вопросы), как обстоят дела с контейнером Acronis я не в курсе :)
Да, контроль «по всему файлу» никто не использует, из-за большого времени проверки; но «большое время» — это сколько? Например, 1 секунда на среднем компе — это адекватно.
Соответственно, если размер блока для проверки будет в 3-5 мегабайт — это будет адекватно, и не сильно мало и не сильно много.
Проверять по файлу не имеет смысла, так как в интересах пользователя владельца файла нужно максимально ускорять само шифрование. А его скорость и так постоянно растет с появлением новых процессоров, новых инструкций типа того же AES-NI. Сейчас топовые процы Intel выдают в TrueCrypt скорость около 5-7 ГБ/сек, так что для задержки в 0,1 секунду уже нужен блок в 500-700 МБ, а если в контейнере всего 2-3 МБ?
Кроме того алгоритмы шифрования обычно используют с возможностью распараллеливания. Потому для проверки и придумали PBKDF2, в котором постепенно увеличивается количество итераций и соответственно замедляется процесс перебора, при этом юзер не страдает от медленного шифрования, так как проверка делается один раз вначале.
Это роялит, если перебирать пароли. Начиная с некой сложности функции деривации ключа становится проще перебирать ключи, а не пароли.
А так, см.выше — они используют пароль как сид и ГПСЧ как дериватор ключа.
Вывод? Брутфорс в полный рост весьма эффективен.
Ну перебор ключа возможен для TrueCrypt, так как точно знаем где нужно искать слово TRUE, либо если точно известен CRC, размеры и смещение файла или блока (что маловероятно, так как такая информация обычно тоже шифруется), а иначе как вы будете знать, что расшифровали данные?
Перебор ключа возможен всегда и везде.
Вопрос в:
1) времени на перебор одного варианта (а точнее — в порядке числа вариантов в секунду)
2) воможности сокращения поля перебора
3) возможности использования частично известной информации для алгоритмической атаки в пункте 2.

Ну и самое жЫрное — AES-CBC уязвим к bit flipping. Использование рандомного паддинга отменяет защиту через поломку паддинга. Не знаю, насколько эффективен алгоритм проверки целостности, и не подвержен ли он так же ему. Уже влом.
Вот как раз загвоздка в первом пункте, для начала нужно знать когда остановиться.

Так bit flipping вроде предполагает, что атакующий должен во-первых, знать часть содержимого, во-вторых, позволяет только «испортить» содержимое, а не расшифровать его, в-третьих, для файлов, обычно предварительно сжатых, это не особо актуально, тем более, что как минимум есть CRC, а можно и с помощью HMAC контролировать целостность.
Ну их молчания компании я делаю один простой вывод — проверка есть и весьма простая.

А бит флиппинг для сохранённых данных плох тем, что в теории, можно встроить что-нибудь интересное.
Это, конечно, сложно, и слабо применим вектор для данного случая (хотя контент мы частично знаем!) поэтому нам не интересен, однако ж он уязвим-с.

Но новый IV для каждого блока — большой плюс, и сильно нивелирует эту проблему.
Очень сомнительно насчет встроить, чтобы потом после этого данные расшифровались, потом распаковались, и чтобы потом еще совпали все контрольные суммы. В общем это уже из области фантастики, и нужно чтобы вы там какую-то вселенскую тайну хранили.
Конечно сомнительно. Но шансы больше нуля же?
Терморектальный криптоанализ намного эффективнее, так что этими шансами можно пренебречь :)
Прочитав ваши вопросы, понял, что я _ничего_ не знаю о криптографии. Правильно писал Брюс Шнайер — дьявол кроется в мелочах.
Дело в том, что я видел как Acronis обращается с криптографией в прошлом, поэтому пытаюсь выяснить, проводили ли они какой-либо аудит этого вопроса, или это только для галочки в брошюре, а стойкость применённого алгоритма никто не проверял.
UFO just landed and posted this here
Давайте будем честными. Вы себе truecrypt сами собирали из исходников? Нет?
Ну и в чем разница? Только в том, что вы «знаете», что там.
Я выясняю что тут. Итог — знание на одном уровне, позволяющее сделать выбор, использовать или нет.
UFO just landed and posted this here
Да, интересный момент про юрисдикцию коммерческого софта в сравнении с опенсорс. Я как-то сразу не подумал.
Ну 65537%255 был и в опенсорсе ;)
Да и дырища у debian с ssh ключами тоже толстая…
UFO just landed and posted this here
Думаю правильнее рассуждать о сравнении специализированных продуктов. Acronis True Image все же не о шифровании в первую очередь.
Вообще, это как заявлять «мы можем делать бакап диска целиком», а потом быть не в стостоянии восстановить его так, чтоб он грузился.
Стоп, о чем это я
Метод аналогий как правило не уместен. С помощью него можно доказать все что угодно. Любой софт, это продукт компромиссов, наш продукт ориентирован на Windows системы в первую очередь и об этом говориться везде в документации, потому ваша ссылка не уместна при всем уважении.
Просто нельзя говорить, что это бакап диска, если бакапится не полный диск.
Так и тут — нельзя говорить, что у вас шифруется, если оно не шифруется — это введение в заблуждение.

Впрочем, из всего услышанного, если нигде нет спец-закладок или неприятного косяка, реализация выглядит достаточно надёжной.

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

Извинения приняты.
А какой смысл рассуждать о шифровании промышленного уровня для домашнего продукта резервного копирования? Если вам есть что скрывать, вам стоит выбирать специализированные продукты. Да, с развитием облаков это приобретает повышенное значение, но все равно специализированный продукт сделает это лучше.
У криптографии нет понятия «промышленного уровня»!
Есть только корректная реализация корректной схемы, а отличия должны быть ТОЛЬКО в длине ключа.
Всё остальное — это «криптография для галочки».
Вы ведь понимаете, что терзаете вопросами о яблоках продукт о грушах? ;)
Я терзаю вопросами о качестве груш, которые идут в сок «Яблочный с добавлением груш».
Я понимаю, что основное — яблоки. Но мне хочется, чтобы груши там были натуральные, а не «ароматизатор, идентичный натуральному»
Кстати, веб и мобильные приложения — расшифровку производят локально на машине пользователя, или онлайн — и пароль, получается, в этот момент вам передаётся?
Нет, локально они ничего не смогут расшифровать, пароль на время сессии предоставляется пользователем, но нами не сохраняется.
Пара дополнительных вопросов:

5. Какие гарантии отсутствия передачи каких-либо данных пользователя и данных о данных пользователя куда-либо в сеть (неважно, ваше облако или еще куда) в случае неиспользования облака?

6. Есть ли штатная методика отказа от использования облака через настройки, гарантирующая отсутствие возможности случайной отправки данных туда?
5. Мы можем собирать только логи проблем при работе приложения, но пользователю надо на это согласиться при установке программы. К облаку это не имеет отношения.

6. Уточните термин случайной отправки. Если у вас нет подписки, то клиентское приложение в облако не пустят. Если подписка истекла, то данные будут хранится еще два месяца на случай возврата клиента и потом удаляться.
6. При покупке 5Gb прилагается в комплекте же, соответственно, в качестве Target'а можно выбрать «Облако».
Если глянем на скриншот:


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

это вопрос не только простого домашнего параноика;
вопрос, в том числе, касается корпоративных политик недопущения вывода данных во внешнюю сеть.
Заблокировать принудительно в приложении нельзя и мне кажется реализовывать это в приложении все же неправильно:

1. Это все же приложение для домашнего пользователя и перегружать ее настройками не слишком хорошо.

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

3. Будете ли вы доверять таким настройкам в приложении, если дошли до мысли о таких настройках? Не разумнее ли использовать firewall и просто закрыть приложению доступ к определенным адресам?
0. Про необходимость настройки я вопрос не поднимаю — я просто спросил
Кстати, есть ли возможность деактивировать включенный Cloud?
Cloud, приложенный к нему, надо вручную активировать — или он активирован сразу с регистрацией?

1. Эм… У меня дома Win2003 до сих пор — я её не могу бакапить? Обычная домашняя машинка, игрушки, да DNLA…

2. Очень часто мелкие конторки используют SoHo продукты вместо корпоративных в своей работе, это никак не влияет на параноидальность политик, обычно. Как ни грустно.

3. Не, зарезание сетевого доступа ему — это и так понятно, хотя всё равно часть бакапа явно идёт с низкого уровня (иначе часть данных просто недоступна же) — и его фаервол не зарежет.
0. Деактивировать можно, но в интерфейс это нигде не выведено.

1. Если серверная ось, то ATI туда не поставится.

2. Да, это правда, и у нас для них тот же ответ. Нам в этом продукте надо сохранять фокус на домашних пользователях, поэтому иногда надо говорить нет.

3. Почему же? Данные просто некуда будет передать и все останется на компьютере пользователя. Но я повторюсь, если пользователь сам не настроил бэкап данных, мы определенно точно ничего с него собирать не будем. Это все же совсем не того профиля программа.

На самом деле когда речь идет о файловом или дисковом бэкапе в облако, его стоит воспринимать так же как локальный в плане возможностей шифрования. Если к нам придут с шифрованным локальным бэкапом и попросят восстановить пароль, мы тоже не сможем помочь.
0. А вот это — грустно.

1/2 — ясно, спасибо, значит, буду обходиться старыми средствами.

3. Потому, что фаервол блокирующий приложение — не заблокирует драйвер; а блокирующий target host — так это еще надо знать, куда именно отсылает.

А касательно последнего — вы, разумеется, не сможете в любом случае — даже если и могли бы, никогда не сознались бы, именно поэтому и важен ответ на этот коммент
3. Это не сложно выяснить.

Ответ на этот комментарий будет, он же нужен точный и аккуратный, а не просто мои воспоминания. Это требует время, сегодня-завтра отвечу.
Спасибо а терпение к этой пытке :)
3) а пананоики нынче доверяют программным фаерволам?
А какой предоставляете объем в своем облаке и за какие деньги?
Большие тарифы сейчас в разработке.
А где можно посмотреть список изменений, url есть?
Слишком маркетинговый список ))) есть более технического характера?
например вот как у MediaInfo
Version 0.7.33, 2010-05-14
— + Colorimetry field is replaced by Color space and Chroma subsampling
x Some words were not translatable
x Solaris port was broken
Когда продукт поступит в продажу? Поддержка ReFS уже есть?
Нет, пока только в работе еще. Но честно говоря, именно для Acronis True Image не самая приоритетная FS.
UFO just landed and posted this here
Хм, очень интересное поведение. А первый полный бэкап всегда доступен? Он где лежит?
UFO just landed and posted this here
А какая версия у вас Acronis True Image? Дело в том, что у нас есть такая настройка, не удалять первый бэкап в цепочке бэкапов, в таком случае как раз создается второй полный, который потом участвует в цепочке и может быть удален или сконсолидирован, а первый бэкап остается неизменным. Вероятно где-то эта настройка выставлялась не вовремя.
UFO just landed and posted this here
Кто-то уже шутил здесь про облачный бэкап? Нет, ну ладно, пусть буду я

«Хотите бесплатно забекапить свои данные на сверхнадежном облачном сервисе? Назовите папку с ними «Jihad Plans».»
Как насчёт планов по бэкапу в Sparse file в NTFS с использованием Hole Punching в режимах Non-stop backup/mirror? Чтобы например при бэкапе 2тб раздела и удалении 100гб данных не пересоздавать полностью раздел (и не хранить эти удалённые 100гб в incremental или diff), а пометить удалённую часть архива как неиспользуемую, что сразу высвобождает свободное место без перемещения остальной части файла, цена этому всего лишь фрагментация. Например для отдельно взятых файлов помечать неиспользуемые пустые области умеет утилита www.opalapps.com/sparse_checker/sparse_checker.html
Если ли нормальная поддержка новых сетевых интерфейсов последних материнских плат от Asus z77/z87 чипсетах, а так же бизнес-ПК вроде HP 8300elite?

Интересует, что версия 2012 не умеет вообще видеть встроенные сетевые интерфейсы при загрузке с диска., 2013 тоже очень ограниченно понимает сетевые интерфейсы

Так же плохо бэкапятся UEFI ноутбуки sony — в них часто не видится сеть или встроенный накопитель.

Хотелось бы хорошей поддержки GPT партиций. Часто не возможно при загрузке с диска сделать клон GPT, хотя Paragon HardDrive manager 2012 такие вещи делает вообще влет.
Спасибо
привет! ну версия 2012 довольно старая, надо проверить как минимум а 2014. Аналогично про ноутбуки Сони и GPT. Тоже надо проверять на последней версии.
Скажите пожалуйста, появилась ли возможность «включения» инкрементной копии в «родную цепочку»?..
Вопрос касается случая, когда из инкрементного архива дисков выполняется восстановление системного раздела (на котором расположен и сам ATI) — при этом Акронис вполне естественно «забывает» об архивациях, выполненных после того момента, на который был выполнен бэкап, из которого выполнено восстановление. при этом в списке архивов дисковый архив «разваливается» на два, в одном из которых пропадает кнопка «архивировать», а в другом неизвестнв схема архивирования. и «забытый» архив «болтается» с какими-то кривыми параметрами. причем ситуация не исправляется проверкой архива — хотя, по логике, должна бы.
Извините за задержку с ответом. Да, мы исправляли массу проблем вокруг именно такого сценария и сейчас версии должны подхватываться автоматически. Но на всякий случай, их можно добавить в ручную, в главной консоли надо выбрать «Add backup». и указать недостающие цепочки.
Sign up to leave a comment.