2021-03-09, 00:45:40
The time it takes is limited by the hardware.
Some notes on that.
Copying is done by a single thread by the vimalinWorker process. The copying itself is done via standard Windows API calls, nothing special there.
If Windows can copy fast, then so can Vimalin.
That thread does not have any UI interactions.
UI updates while copying is something that tends to slow down copying significantly and this is my guess why some users have reported Vimalin being faster than copying via the OS.
Windows being helpful and counting all the files before starting the copy is not good there either as it will copy a lot of small files you don't even need in your backups.
You can see progress from the GUI, but that runs in another process and does not impact the copy process performance itself.
As a small test I just ran a 12GB backup on a running VM and it took me 190 seconds, but that's with the md5 hashes enabled.
I then followed the steps from this post:
https://forums.vimalin.com/viewtopic.php?pid=89#p89
and killed the vimalinWorker process from task manager to force it to read the new settings.
.. and it then took 154 seconds. Aka, making the md5 hashes is not that slow from my POV.
Note that my test in this case is using nested virtualisation (running a Windows 7 VM in Workstation in a Windows 10 VM within Fusion and running Vimalin in that Windows 10 VM as well), so not as fast as it can be on a physical host, but it can help to give you an idea.
--
Wil
Some notes on that.
Copying is done by a single thread by the vimalinWorker process. The copying itself is done via standard Windows API calls, nothing special there.
If Windows can copy fast, then so can Vimalin.
That thread does not have any UI interactions.
UI updates while copying is something that tends to slow down copying significantly and this is my guess why some users have reported Vimalin being faster than copying via the OS.
Windows being helpful and counting all the files before starting the copy is not good there either as it will copy a lot of small files you don't even need in your backups.
You can see progress from the GUI, but that runs in another process and does not impact the copy process performance itself.
As a small test I just ran a 12GB backup on a running VM and it took me 190 seconds, but that's with the md5 hashes enabled.
I then followed the steps from this post:
https://forums.vimalin.com/viewtopic.php?pid=89#p89
and killed the vimalinWorker process from task manager to force it to read the new settings.
.. and it then took 154 seconds. Aka, making the md5 hashes is not that slow from my POV.
Note that my test in this case is using nested virtualisation (running a Windows 7 VM in Workstation in a Windows 10 VM within Fusion and running Vimalin in that Windows 10 VM as well), so not as fast as it can be on a physical host, but it can help to give you an idea.
--
Wil