Data Recovery and Disk Utilities Forum @R-TT

Version: 7.3 Compilation 7305 remains just as slow as always.

[quote=BluePT post_id=19789 time=1740935103 user_id=5930]
My startup disk is an SSD Western Digital 500GB Black SN750 NVMe M.2 PCIe 3.0. I normally do a full backup every day (the startup disk as 146GB of data) with a compress level in commitment between size and speed - image file size: ~80GB) and this takes about 25 minutes. I tested other flagship backup/imaging products and the time was always higher or similar. My question for the community, are my imaging times ok, or should be better?

My SSD times:
[img]https://i.ibb.co/qMk6k9Cf/Snap1.jpg[/img]

The backup destination is an external usb 3.0 hdd Seagate ST8000DM004 with ~100MB/s write speed.
[/quote]

Hdd as destination is just different and if you now get similiar timings with other programs I'd say it's probably working for you as should plus your write speed matches well, but previous reply before you by "Indaliax" he seem to have same issues as I did, but for me latest builds are working correctly now so maybe they are still looking in to this?, they did say they're working on it in another thread and being aware of the problem

My diskpeeds are in 7000MB/s range and I could not possibly go under 25 minutes with even half your Image size with previous builds, therefore it's probably working for you as you're even faster than that with hdd's

Image time with WD Caviar Black 8TB internal SATA-3 hard disk: 11min 47sec

[img]https://i.ibb.co/ksXZysY9/Snap1.jpg[/img]

So, the faster the destination drive, the faster the backup is...

Update time with build 7303: 18min 8 sec

[img]https://i.ibb.co/FkRDGwNT/Snap2.jpg[/img]

My startup disk is an SSD Western Digital 500GB Black SN750 NVMe M.2 PCIe 3.0. I normally do a full backup every day (the startup disk as 146GB of data) with a compress level in commitment between size and speed - image file size: ~80GB) and this takes about 25 minutes. I tested other flagship backup/imaging products and the time was always higher or similar. My question for the community, are my imaging times ok, or should be better?

My SSD times:
[img]https://i.ibb.co/qMk6k9Cf/Snap1.jpg[/img]

The backup destination is an external usb 3.0 hdd Seagate ST8000DM004 with ~100MB/s write speed.

I just did a test (R-Drive.image V.7.2 Compilation: 7302 and 7303) with one of my previous images that normally take 22 minutes, the copy begins well, but when it reaches 49% it starts very slow. After 22 minutes the work ends, it happens by copying and restoring. I use a 1TB Samsung SSD (Windows 11) and another 256Gb. Samsung (backups).

Comment that I have tried a demonstration version of (Macrium) and it takes 2 minutes and 45 seconds.

Just tried 7302 with one of my previous slower scenario images normally taking 30 minutes, this build is a completely different monster being right up there with the competition when all space included or selected on my SSD, great job team and thank you so much for looking in to this!, this if now completely fixed?, it'll make a lot of people happier guaranteed, and thank you for enabling a GUI for own drivers, a really nice upgrade this one!!

[url=https://ibb.co/zhBhBFYw][img]https://i.ibb.co/zhBhBFYw/Way-Faster.png[/img][/url]

---
Next on my whish list to improve even further would perhaps be a boot menu selector as an addition rather than just BIOS?, I say that cause many people are still seeking alternatives for Macrium, just as I did a while back and found this sweet program, nonetheless thanks for the massive improvements this time

[quote=sdanrt post_id=19741 time=1738101408 user_id=6179]
Oh, and by the way, imaging software that recognizes the filesystem doesn't typically try to back up an entire partition including empty space. So repartitioning to make the partition smaller should make no difference. And I can confirm that the speed problem here is not that it was trying to back up the empty space, it is that it was backing up the used space at a very slow speed. Task Manager is able to show performance info both for individual drives and for individual processes, so I can see that reading and writing is simply not fast.
[/quote]

Used and free space is exactly what this is all about, free space shouldn't normally be an issue but it is,
I know this because I could get the estimation timer to halt at different percentages depending where partitions or free space is located,
it strongly indicates and in all scenarios it halts on large free space and with less free space it got absurdly faster as in several hundred percent

I hope my dumps will help here, I've sent them three different scenarios so they have something to compare with

And yes it's admirable when users spend the extra mile of their time to narrow down things like this, I have a long track record of translating popular software titles and lots of beta testing in my past, I don't mind it though even if it involves re-partitioning or taking a day or even when paying for it as in this case, without the dumps y'all be stuck so they indeed need them and the more voices heard, more likely is it to be fixed

[quote=Alt post_id=19736 time=1737750351 user_id=59]
[quote=Bionic post_id=19733 time=1737574310 user_id=6159]
Further tests including my Y: partition (I wouldn't normally do that" but "Operation 4 of 6" takes two minutes for completion (my entire OS)
[/quote]
Please contact our [url=https://www.r-tt.com/TechnicalSupport.shtml]techsupport[/url] with system dumps when image creations are fast and slow. About -> Write system dump.
[/quote]

My report with dumps should be in now, at your support page could you please arrange so people can attach their dumps?

Personally I'm not keen to upload system dumps of any kind to random public filesharing hosts so had to use my own private hosting space for this matter, it's just a lot of extra hoops for a simple report, Thank you

Oh, and by the way, imaging software that recognizes the filesystem doesn't typically try to back up an entire partition including empty space. So repartitioning to make the partition smaller should make no difference. And I can confirm that the speed problem here is not that it was trying to back up the empty space, it is that it was backing up the used space at a very slow speed. Task Manager is able to show performance info both for individual drives and for individual processes, so I can see that reading and writing is simply not fast.