Как алгоритм сжатия DFS-R соответствует с 7 zip?

DFS-R использует так называемое удаленное дифференциальное сжатие.

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

Таким образом, RDC несравнимо с алгоритмами сжатия, используемыми в 7-zip. Хотя они используют аналогичные методы (создание словарей сигнатур по диапазонам данных), алгоритм 7-zip предназначен для преобразования байтов в контейнерный формат без потерь, где все данные «сжаты» вместе, а цель RDC - выявить различия между похожими файлами или версии файлов, чтобы минимизировать объем передаваемых данных, чтобы поддерживать синхронизацию реплик

Если у вас уже есть похожие файлы VMDX в целевом расположении, нет необходимости разбивать файл на блоки по 100 МБ. Просто убедитесь, что вы всегда используете один и тот же алгоритм (ы) сжатия при архивировании изображений

Такое поведение (сравнение похожих файлов , не разных версий одного и того же файла и извлечение фрагментов) известно как «перекрестное -file RDC », а общедоступная документация довольно скудна, но у команды блога AskDS есть краткое, но довольно хорошее разъяснение в этом посте вопросов и ответов

As Mathias already noted, DFS-R employs the "remote differential compression" algorithm similar to rsync's to only transmit the changed / appended portions of a file already present on the remote side. Additionally, the data is compressed before transfer using the XPRESS compression algorithm (Reference: Technet blog) since the very first appearence of DFS-R in Server 2003 R2. I could not find any details on the actual variant of XPRESS used, but since the compression has to happen on-the-fly, it might be using LZNT1 (basically LZ77 with reduced complexity) as this is what is used in NTFS for the very same purpose.

If you want to monitor the compression ratios, consider enabling DFS-R debug logging and evaluating the log files.

The compression ratio for any of the EXPRESS algorithms is likely to be lower (probably even by a factor as large as 2) than what you get with 7zip, which has algorithms optimized for file size reduction, not CPU usage reduction. But then again using RDC, which allows for transmitting only changed portions of the file, you are likely to get significantly less data over the wire than your 20 GB archive.

Pre-creating a 7zip archive to be transferred with RDC might seem like a good idea to get the best of both worlds - only transmit changes but with a higher compression ratio for the changed portions - but isn't. Compression would mangle the entire file and even a single byte changed at the beginning of the data stream would cause the compressed file look entirely different than before. There are compression algorithm modifications to mitigate this problem, but 7zip does not seem to implement them so far.

All in all, you are likely to significantly save on bytes transmitted over the wire when using DFS-R to transfer file modifications. But it is rather unlikely you are going to get any savings in time and you are inducing significant I/O and CPU load on the destination as well as the source as both files (source and destination) need to be read and checksummed before the actual transmission can start.

Edit: if you have new files, RDC indeed would be of little help - there is no counterpart to rsync's --fuzzy parameter which would look for similar files at the destination and take them as a baseline for differential transfers. If you know you have a similar file (e.g. a baseline image of the transferred VM HD), you could pre-seed the destination directory with this one, though.