Недавно мы опубликовали статью с рекомендациями, как добиться максимальной скорости при снятии образов дисков, и получили довольно много откликов – как вопросов, так и дополнений. Мы провели дополнительное тестирование (однозначно не последнее), и делимся с вами результатами.

Тестовое окружение и подготовка

Использовался тот же ноутбук, что и в прошлый раз: ASUS Vivobook S16 S5606MA, Intel Core Ultra 9 185H, 32GB RAM, порты Thunderbolt 4 (кстати, исправляемся: USB 4 и Thunderbolt 4 – не одно и то же, но об этом как-нибудь в следующий раз). Но кое-что изменилось.

Во-первых, сейчас мы тестировали с другим накопителем, существенно лучшим по характеристикам: Samsung 860 PRO (512GB). На него мы записали немного больше 100 ГБ сжатых данных (zip-архивы).

Во-вторых, мы не стали использовать блокиратор записи, поскольку он заметно влияет на скорость копирования; вместо этого взяли адаптер от Startech, очень быстрый и надёжный.

Далее, из тестирования был исключён Arsenal Image Mounter – мы очень любим эту программу за широкий функционал, но она однозначно не предназначена для создания образов ни по каким параметрам (низкая скорость, малая гибкость).

Наконец, в этот раз мы измеряли скорость только для двух выходных форматов: «сырого» образа (RAW) и EnCase E01 со средним уровнем компрессии.

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

Немного о программах

Фаворитом прошлого теста оказалась программа OSForensics от компании PassMark Software Pty Ltd из Австралии. Это достаточно мощный продукт, разработчики которого уделяют пристальное внимание удобству работы и скорости, хорошо оптимизируя свой код. Функционал программы, вероятно, пока не конкурирует с лидерами рынка, но обладает очень интересными возможностями, которых мы не видели в других продуктах, и, думаю, что мы внимательно их исследуем и опишем в новом материале.

Если вы помните, OSForensics отлично показал себя на создании несжатого образа, но отстал на создании E01. И вот, буквально на днях нам написали авторы программы и сообщили, что после нашей публикации они провели «работу над ошибками», пересмотрели свой подход к компрессии, и им удалось серьёзно оптимизировать код, получив ускорение буквально в несколько раз. Более того, оценивая проведенные нами исследования, они любезно предоставили нам лицензию на свою программу, за что им наша огромная благодарность.

Программа FTK Imager отработала тесты без изменений; честно говоря, для нас остаётся загадкой, почему она так популярна – сильно устаревший интерфейс, невыразительный функционал (даже с учётом того, что она предназначена только для работы с образами и ни для чего другого), очень редкие обновления, и, главное, низкая скорость. Но, в целом, пользоваться достаточно привычно.

Провели повторное тестирование и X-Ways Imager, который является сильно урезанной версией X-Ways Forensics; или, как вариант, можно использовать их же упрощённый продукт WinHex. Надо сказать, что все эти продукты невероятно недружелюбны в использовании, и, если нет опыта работы с ними – вы потратите значительно время даже запуск самых простых операций, не говоря о более продвинутом функционале.

Результаты тестирования

Не будем вас томить, сразу поделимся результатами (OSForensics мы проверили обе версии, и старую, и новую):

Тут даже не понадобилось выделять цветом – OSForensics опять стал безусловным победителем, теперь и при создании образа в формате EnCase E01. Скорость при создании сжатого образа падает очень незначительно.

В старой версии OSForensics, когда процесс создания образа в формате E01 добирался до копирования «несжимаемых» данных, скорость падала с 535 МБ/с до примерно 70 МБ/с, при этом утилизация процессора колебалась на уровне порядка 9%.

В новой версии все выглядит намного привлекательнее — скорость создания образа стабильно держится около 520 МБ/с, и добавился второй параметр — скорость сжатия, который варьировался около 110 МБ/с на уже сжатых данных и достигал фантастических 3.5 ГБ/с на пустых участках. Объем используемой памяти при этом составил около 700 МБ (разработчики обращали внимание, что для алгоритма сжатия, используемого в E01, очень важна скорость памяти), а загрузка процессора в пике достигала 40%.

Нельзя не упомянуть, что, при выборе формата E01, в OSForensics появилась новая опция — установить количество потоков. По умолчанию это 16; возможно, имеет смысл попробовать изменить значение как в сторону уменьшения, так и увеличения, хотя не думаю, что можно выжать ещё больше – результат и так превосходит ожидания.

Что касается размеров файла E01: в новой версии OSForensics размер образа у нас получился равным 107 ГБ (со старой версией — 105 ГБ); FTK Imager и X-Ways упаковали чуть лучше (104 ГБ), но ценой заметно более низкой скорости.

В остальных программах ничего, как и следовало ожидать, относительно прошлого тестирования не изменилось. FTK Imager грузит процессор на 30-50%, использование памяти совсем незначительное, около 50 МБ. X-Ways крайне непритязателен к ресурсам — потребяет от 10 до 25% мощности процессора и всего несколько мегабайт памяти. Компрессию мы выбирали всегда среднюю/оптимальную (при этом практически не теряем в скорости и, соответственно, времени, по крайней мере, при использовании OSForensics), но заметно экономим место.

Другие уровни компрессии мы пробовать не планируем. Причина проста: в этом нет смысла; максимальный уровень компрессии даст очень несущественный выигрыш в объёме данных (да, мы пробовали) при существенном замедлении процесса.

Wait, one more thing

Когда готовилась эта статья, появился ещё один игрок, точнее, достаточно известная программа, где раньше не было функционала снятия образов, но в новой версии он имеется. Это Oxygen Forensic Detective за авторством то ли американской компании Oxygen Forensics Inc, то ли кипрской компании Oxygen Forensics Ltd (в схемах лицензирования мы не разбирались). Разумеется, мы не могли пройти мимо и проверили её работу.

Результаты оказались настолько удручающими, что мы решили не включать их в приведённую выше таблицу. Образ в формате RAW создавался почти полчаса (28:30, если быть точным), а создания E01 мы еле дождались: почти час (55:15). И это при выборе минимальной (даже не средней) компрессии; результирующий образ получился размером всё те же 105 ГБ. Среднюю скорость считать по этим данным не очень корректо, поскольку она была неравномерной; могу лишь сказать, что на «тяжёлых» участках она падала до 50 МБ/с.

Что интересно – у российского брата-близнеца упомянутой программы, распространяющегося на территории РФ под названием «Мобильный Криминалист» (авторство принадлежит компании «МКО Системы», ранее «Оксиджен Софтвер») аналогичный функционал заявлен, но нам так и не удалось его отыскать. Сравните внешний вид (и обратите внимание на точное совпадение номера версии) – в российской программе просто отсутствует кнопка для создания образа, в остальном всё одинаково; сложно предположить, что американо-кипрский и российский продукты написаны разными разработчиками:

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

Обратим внимание, что программа KeyScout (или «МК Скаут» в российском варианте), которая, помимо снятия образов, обладает и другим функционалом, является частью «большого» продукта, может использоваться фактически автономно и не требует лицензии. В то же время собранные данные, за исключением образа носителя, сохраняются в формате, который могут открыть только продукты Oxygen Forensic Detective и Мобильный Криминалист.

С моей точки зрения, чтобы сделать так плохо, нужно исключительно постараться. Не исключаю, что разработчики KeyScout вдохновлялись программой с открытым кодом dc3dd, а её код даже близко не оптимален.

И ещё один странный момент. Некоторые (если не все) программы при создании образа делают и небольшой «отчёт», куда пишут информацию об исходном носителе и результатах процесса. И тут авторы KeyScout явно опирались на другой продукт, а именно FTK Imager, судите сами:

И снова про OSForensics

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

Source drive: 512GB NVMe SSD
Data on source drive: Windows boot drive + various office software installed
Destination: USB-C 3.2 connected SSD.
Format: E01 compressed format (medium compression). Single file (not split file)
CPU: Ryzen 5600X (mid range desktop CPU)

Note that imaging empty (or partially empty) drives is much faster than drives with data as there is special handling of sectors which are all zeros. This is also why imaging speeds up and gets slower during the process.

Imaging of data that is already compressed (or very random) is slower than data that can be compressed. SHA1 hashing is done at the same time as disk imaging. So avoids another pass at the end.

Note that the final result of 421MB/s isn’t very fast compared to disk speeds. It is only fast in the context of writing a compressed E01 format file with hashing.

If you have fast SSDs and plentiful disk space on the destination drive, raw image format will still be faster (between 50% and 100% faster). e.g. 7min instead of 12min for this example.

We found that it was impossible to use all CPU capacity for E01 compression as RAM bandwidth presents a bottle neck during the compression process. So in additional to having fast SSDs, having fast RAM and at least a 4 Core CPU can help with imaging speeds.

Compression rate was roughly 76% (so 465GB compressed to 111GB)

Скорость, которую вы видите на этом скриншоте, впечатляет (см. ниже, мы к NVMe ещё обязательно вернёмся).

Почему E01 и почему SATA?

Формат E01, несмотря на все его недостатки, является стандартом де-факто для работы с образами носителей. Да, он сильно устарел и несовершенен, но с ним работают абсолютно все продукты. Более современным и продвинутым является формат AFF4, но его внедрение идёт медленнее, чем хотелось бы – хотя он лишён большинства недостатков, присущих E01, и обладает рядом крайне полезных дополнительных возможностей.

Можно ли обойтись без компрессии и снимать образы в формате RAW? Конечно, но вам понадибится очень много свободного места. Но смысла в этом нет: при работе с E01 у вас будут абсолютно те же данные, до последнего бита – просто оптимально сохранённые. Можно снять RAW и упаковать его в ZIP или RAR, результат будет тот же – только места по-прежнему понадобится много (для исходного образа), а время на упаковку потратится приличное, так что лучше паковать «на лету», создавая E01. Есть, правда, специалисты, ратующие за использования RAW, якобы туда попадает больше данных, особенно когда речь идёт о незанятом пространстве (по которому можно проводить карвинг с целью восстановления удалённых файлов; иногда даже упоминается «межсекторное пространство»), но это не просто миф, а абсолютно некорректное утверждение, не имеющее под собой никакой основы. Впрочем, если у вас есть избыток свободного пространства – можно сохранять и в RAW, хуже не будет, а немного времени сэкономите, а также можете быть полностью спокойны по поводу совместимости.

Что касается SATA, то это на данный момент самый распространённый интерфейс, несмотря на активное распространение NVMe. При этом тестирование HDD не позволяет в полной мере оценить скорость создания образов, поскольку процесс будет ограничен скоростью самого диска (это в среднем от 150 до 250 МБ/с); соответственно, наш выбор пал на диски SSD, обеспечивающие линейную скорость чтения (с записью сложнее, но в данном случае это не имеет значения).

К тестированию дисков NVMe мы вернёмся обязательно; результаты могут оказаться ещё более интересными, и возможно разброс в скоростях разных продуктов будет не так велик. С другой стороны, для NVME большее значение будет иметь качество адаптера – наиболее распространены 10-гигабитные (USB 3.2 Gen2), но хочется попробовать и Thunderbolt 4.

Не лишним будет протестировать и скорость снятия образов с карт памяти. Это большой и очень интересный класс носителей данных, некоторые со своими протоколами и особенностями.

Почему так популярен FTK?

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

Наша рекомендация – использовать для снятия образов OSForensics, если есть возможность его приобрести. По крайней мере, пока основным форматом не стал AFF4 (для этого поставщикам нужно приложить ещё немало усилий).

И ещё один урок: не нужно доверять программам-комбайнам, претендующим на решение слишком широкого спектра задач. Хотите вы этого или нет, универсальные программы всегда будут хуже специализированных; да, вам придётся иметь их все (например, для работы с уже готовыми образами мы рекомендуем Arsenal Image Mounter, лучший продукт в своём классе).

Возвращаясь к бесплатности – это безусловное преимущество (а ещё лучше, когда продукт open source). Но, как обычно, преимущества легко превращаются в недостатки. От разработчиков платных программ вы вправе требовать улучшений и исправлений ошибок, и они действительно реагируют на замечания (хотя это относится далеко не ко всем вендорам), а стимулировать авторов свободно распространяемых программ уже сложнее. Мы упоминали, что FTK Imager остановился в развитии, и, хотя общеизвестно, что он весьма небыстрый – обновлений ждать не приходится.

Почему так важна скорость?

Ответ на этот вопрос достаточно очевиден: время. Если мы говорим об SSD, то объём обычно не превышает 4 ТБ; образ такого диска будет сниматься от одного часа в хорошей программе до нескольких часов в плохой. Тут всё просто: выбирайте «правильные» программы (хотя процесс копирования обычно идёт фоном).

С HDD ситуация хуже – объёмы больше, скорости ниже. Диск объёмом 16 ТБ при средней скорости чтения 200 МБ/с будет сниматься примерно сутки, и разница в скорости даже в скромные 10% (и уж тем более в два раза) превращается в существенное абсолютное время, которое может исчисляться часами. И тут, к сожалению, хорошей программой ситуацию уже не исправить – мы упираемся в физические ограничения самого носителя. Решение только одно: использование автономного устройства для копирования.

Ещё раз повторю, что в реальности скорости всегда будут очень сильно отличаться от «бенчмарков». Факторов великое множество: от использованного окружения до самого носителя, причём речь идёт не только о его характеристиках и состоянии износа, но (даже больше) о содержимом; имеется ввиду – насколько сильно он заполнени и какими данными, как хорошо они в принципе сжимаются.

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

Вместо заключения

Процитирую авторов OSForensics – я сам не смог бы сформулировать лучше.

So in conclusion. There are lots of variables. To get the best speeds, you need good SSDs, CPU, RAM and IO ports (e.g. USB3.2), plus the software to use them. Any one of these can end up being a bottleneck.