Windows 10: Reflect backup performance...

This one puzzles me...

The PC has two Samsung 960 EVO 250GB PCIe NVMe - M.2 drives, one is for the system and the other for data. Reflect scheduled to create a full image on the daily basis with default compression and encrypted with the same password. The backup device is a 2TB Seagate, connected to to PC via a USB 3.0 port. The backups are scheduled and the number of backup images kept is three in both cases.

For all practical purposes, the difference between the to backups is just the used space for the backed up drives. The time it takes to complete the image backups for the drives obviously different, due to the used space size, but not linear.

System drive size and backup time:





Data drive size and backup time:






The data drive's used space is ~40% larger and its I/O performance is better than the system drive's. Yet, the backup time is more than twice as long as the system drive's.

What could be the reason for the difference?
TIA...

:)

 

Windows 10 backup

You haven't described what steps you are performing to backup or what program you are using.

Windows 10 has two backup utilities: File History and System Image.

I myself prefer third-party software for backup. Macrium Reflect makes my image backup in approx. 6 minutes and my file-and-folder backup in approx. 4 minutes.

 

Anyone tell me how to sort the 8078014B and 80070570 error message

In addition go over the
Windows 10 Install Integrity Checklist.

If you're using a bloated antivirus then uninstall it to default to built-in Defender long enough to test the difference. You'll always get best performance with Defender which is perfectly adequate.

If you're using Windows built-in imaging you can consider an alternative like popular

Macrium Reflect is a Free and Easy To Use Backup Utility .

 

Backup performance depends very much on number of files, size of files etc.

You see this when simply copying a large file say 1 GB from one drive to another, compared with copy 1000 files each of 1 MB -the latter is much slower. Large files can be very slow if you have limited RAM, causing lots of paging.

Additionally, some files compress more easily e.g. video files hardly compress at at all, so you have to write a lot more data to the backup.

In the end, you are really comparing oranges and apples.

 

I would agree with cereberus on the drop in speed when copying many small files. I have a 14MB folder that comprises around 8000 very small .txt files, many just a kb or so in size.

When I copy these to a USB 3 drive the speed slows to a crawl as can be seen by the estimate of the time required. 95% of the time required to transfer all my documents content is taken by this one folder.

When I make a system image of the drive that restriction doesn't seem to come into play and the whole C drive which is around 30Gb in content is imaged in around 3 minutes. That is with AOMEI but Macrium and Windows own backup give similar speeds.

 

I was not saying Macrium necessarily suffers same issue as copying though, just pointing out there are lots of factors that influence how fast a drive backs up.

Compression can have a big effect e.g. A large file that compresses well takes more time to compress but is quicker to write, and probably vice versa for a file that hardly compresses (it might even take longer to compress if it is more difficult to compress?).

Also, times can vary due to fragmentation, hardware drive differences etc.

There is no direct correlation between size of backup and speed other than an obvious directional trend that large backups take more time than much smalller backups.

 

Thanks guys/gals...

I am aware that the size of the file can greatly impact the transfer rate, be that local or remote. I am also aware that Reflect utilizes sector based backup:





What I had not been aware/forgot, that Reflect does not backup page and hibernation files. It means that the system used space size is about 40GBs, when all thing considered.

And from this perspective, it seems that the size of the file doesn't matter that much. At least that what I believed incorrectly.

The first thing should have been done is look at the backed up image size:

System drive: ~23 GBs
Data drive: ~62 GBs

Well, that's pretty much self explanatory... *Busted