такой вариант безобиден и имеет шанс на существование?
Я даже не помню пользовался ли этой командой. Насколько помню, там собственно конвертации нет. Обычно перед этим делается clean, которая обнуляет 2048 секторов с начала и конца диска. А сама convert просто создаёт GPT разметку - то есть раздел виден не будет, но его можно вставить через DMDE. Будет время - проверю.
У микрософта есть реально конвертирующая в GPT утилита - появилась несколько лет назад в 10-ке. Название (по памяти) mbr2gpt. Но у неё есть небольшие ограничения, связанные с расширенным разделом.
Добавлено через 12 минут
Что касается восстановления данных.
Желателен скриншот экрана Разделы и лог полного скана DMDE.
Добавлено через 30 минут
Алгоритмы акрониса мне не ведомы, поэтому могу делать лишь выводы (предположения) на основе множественных кейсов. Попробую как можно проще обьяснить суть произошедшего.
Предположим, том начинается в секторе 2048. И происходит конвертация в GPT.
В случае иных программ том остаётся на месте и нетронутый - просто прописывается в таблице другого формата (MBR-GPT). А вот акронис считает что его надо сдвинуть, при этом дальнейшее зависит от конкретного релиза акрониса и (судя по всему) от расположения звёзд или ещё чего то.
Начало раздела смещается, а MFT пересчитывается, исходя из нового начала раздела. При этом смещение начала делается на число секторов, кратное размеру кластеру.
Но самая жесть, когда смещение делается на число секторов не кратное размеру кластера.
В этом случае абсолютно все (используемые сектора) переносятся в другое место + пересчёт MFT. Процесс очень длительный и обычно воспринимается за зависание и далее как обычно.
И тут многое зависит от того, в какой момент прервалось и от одного НО.
По нормальному (хотя о какой нормальности моно говорить в случае когда секундная операция происходит и часы), пересчёт делается последовательно. В этом случае можно найти на какой записи произошел обрыв. Но, судя по кейсам, пересчёт делается в несколько потоков, бывает что и сдвижка начала раздела не единичная и возможно хаотично - вполне возможно по алгоритму пересчёта не по записям а по структуре каталогов.
Вот в результате всего это и происходит бадабум с ошмётками файловой системы и данных. Я не знаю как автору DMDE удалось реализовать то, что мне сложно описать по простому, но в основном она умеет найти какие записи со старыми смещениями, какие с новыми. Восстановить такой раздел по месту малореально - поэтому практичнее восстановить данные на сторону, пересоздать раздел в новом формате и сделать полный формат, чтобы удалить ошмётки старых данных и метаданных файловой системы.
Как то так.
Добавлено через 34 минуты
Попробуйте написать ему в телегу
Респект и уважуха. 
Сразу видно что вам важно помочь человеку а не так как в иных "форумах", когда моментальный бан за упоминание иного ресурса.