Just trying to understand why I am experiencing what I am among my computers using Macrium Reflect. FYI: I am using Macrium Reflect 8, which fully supports the EXFAT filesystem and works well for me. ALL of my computers are LVM on LUKS and fully encrypted excluding their boot partitions of course. I decided to format all my large external drives to EXFAT because I don't want the journaling feature present (and forensically observable) on these unencrypted storage drives. THESE ARE OFF PREMISES DEVICES! I use Macrium Reflect (RAM recovery environment) to forensically backup these linux computers to the EXFAT storage drives. Of course I am not doing "hot image" and only forensic-everything backup captures. Compression is set to medium automatically. For years these drives were NTFS formatted and the compression was basically zero due to forensic capture. Since I am now using EXFAT on some of my machines I get amazing compression, which saves writing time by alot and therefore the entire project time is cut by over 50% as compared to the NTFS externals. By the way, I have acid tested these EXFAT backups by blowing away the linux system disk completely and then rebuilding from Macrium's backup. Perfect every single time so the compression is valid and accurate - amazing. However; I don't get any significant compression on the backups from my Laptop. ? Same LVM on LUKS config and even writing the MR backups to the exact same EXFAT externals as the other machines. Multiple EXFAT saves on several externals and always the same result. I created separate MR recovery disks for the Laptop because its a legacy bios machine, while my newer stuff is all UEFI, etc... Maybe the recovery environment is different somehow but the build# from MR is the same. The Laptop OS is only 75 Gig so we are talking a 20 minute project including verification instead of say 8-10 minutes if it worked the same as the other machines. No big deal. Just scratching my head as to why this is happening? The Laptop backups have been acid tested as well. Thoughts. ps - If you are wondering why I am using MR with linux is because it works 100%. The largest plus is that my advanced computers have 10-40 gbps ports and the backups write out at many multiple Gbps. If I used dd or similar I just couldn't stand the project times. I get backups of a hundred Gig OS with verification in under 10 minutes on these machines. I am not going back, LOL
Compression ratio/factor/percentage depends on the type of data being compressed, and the compression algorithm in use. According to Macrium, textual data compresses very well, whereas binary data not as well. So how much compression you get depends on the data mix of the data being backed up, and will vary accordingly. I believe you are not getting a lot of compression on your laptop data probably because most of the data on your laptop does not compress very well.
You may have a point. However; the laptop system disk is a linux lvm on luks just like the major desktop units. Seems like the data would be quite similar in composition. I do appreciate the suggestion and/or thought about what the issue might be. One interesting thing that stood out to me was that backing up ANY of my system disks in forensic configuration ONTO an NTFS external results in virtually no compression, but backing up onto an EXFAT external gives great compression. That is interesting to observe since the data being backed up is exactly the same. Only the filesystem being backed up upon was changed. Reminding readers that these backups were thoroughly "acid tested" and are perfect. Hmmmmm!
Should compression of encrypted data have little to no difference in file size, shouldn't it? Maybe somehow sparse file indicator or TRIM command slipped though marking part of space as empty? Just a wild guess
While writing my first post it slipped my mind that your data was actually encrypted. Encrypted data does not compress, as compression algorithms cannot use their techniques on the data. So you should see a very slight or almost no compression of your data. Saying that I think I have figured out what is causing the size discrepancy in your case. It is actually not due to compression, or the file system in use, but due to different default cluster sizes of the two file systems. NTFS usually defaults to 4 KB, while exFAT defaults to 128 KB for drives bigger than 500 GB, which I assume yours are. Same data will show up with different sizes on different sized file clusters. So the size of your data is most likely same, it is just being reported differently by the two filing systems. You can do a simple test. Copy some data that is lets say 10 GB on your NTFS drive over to your exFAT drive, and see what size exFAT reports. EDIT: Actually the size difference is also dependent on the file sizes of the data. One large file will show up with the same size on both 4 KB and 128 KB cluster size. A bunch of small files will report different total data size.
You are absolutely right! Encrypted data does not compress at all. It slipped my mind that @Palancar's data was encrypted.
I am sorry but I am traveling a little bit this week. I want to test something when I get home. Let me just throw this out though: Running MR in forensic backup mode (in RAM of course - recovery environment) on NTFS externals using my "brisk" computer takes about 20 minutes to complete including verification. Using that exact external drive formatted in EXFAT the MR backup completes with verify in around 7 minutes total. Reminding: this machine churns out multi GBPS file moves. The difference in time to complete the projects is stark. Both filesystem projects acid test as perfect backups when recovered for examination purposes.
In that case this becomes a question for Macrium devs, because there may be a difference in how Macrium handles NTFS vs exFAT. Unfortunately, due to Macrium being a proprietary software this information is not available online. You can post this question on Macrium forum, one of the Macrium staff who knows Macrium internals may be able to answer this question better than anyone here.
Still traveling. Life!!!! Eventually I will be back and will get around to this. Thanks for the suggestion!!
