Hi
SE/Pro neither know nor care what physical type of drive it is (aside from checking disk format, etc). We don't access the drive at a low level (there is no low-level code in SE/Pro), we use Windows API calls, that in turn address the hardware via the drivers.
Plus, I just did a quick test on my own SSD (C:) versus various partitions on my standard SATA 2TB mechanical drive
C: 143987 files scanned in 48 secs = 3000 files/sec
H: 028019 files scanned in 11 secs = 2547 files/sec
M: 033714 files scanned in 11 secs = 3064 files/sec
P: 203841 files scanned in 45 secs = 4529 files/sec
(the minor difference between C/M & H's performance are probably because of the depth of folder nesting involved on H being higher - thus, more recursion required, whereas M is fairly 'flat'. The test with P involves a stress-test folder/file-set of 180,000 files that forces use of disk database (in Pro) for scan/compare, rather than RAM)
Note: both my SSD and mechanical drive are GPT
Thus, it doesn't seem as if there's a particular problem with SSDs (plus, nobody else is reporting it), so does look like something odd on your machine. If you want to generate and send a Support Zip with debug-out to the ticket area (details in article), we can take a look, but please note if there are no actual errors reported, we won't be able to see anything except it is maybe slower than normal. SE/Pro have no concept of how long it 'should' take, and don't make comments about performance, because neither do the APIs...
(BTW, in case relevant: as per Help > Quick Start > 'Understanding Backup and Synchronization', SyncBackSE/Pro are not designed to (and can not) make an exact copy of a system drive)
SE/Pro neither know nor care what physical type of drive it is (aside from checking disk format, etc). We don't access the drive at a low level (there is no low-level code in SE/Pro), we use Windows API calls, that in turn address the hardware via the drivers.
Plus, I just did a quick test on my own SSD (C:) versus various partitions on my standard SATA 2TB mechanical drive
C: 143987 files scanned in 48 secs = 3000 files/sec
H: 028019 files scanned in 11 secs = 2547 files/sec
M: 033714 files scanned in 11 secs = 3064 files/sec
P: 203841 files scanned in 45 secs = 4529 files/sec
(the minor difference between C/M & H's performance are probably because of the depth of folder nesting involved on H being higher - thus, more recursion required, whereas M is fairly 'flat'. The test with P involves a stress-test folder/file-set of 180,000 files that forces use of disk database (in Pro) for scan/compare, rather than RAM)
Note: both my SSD and mechanical drive are GPT
Thus, it doesn't seem as if there's a particular problem with SSDs (plus, nobody else is reporting it), so does look like something odd on your machine. If you want to generate and send a Support Zip with debug-out to the ticket area (details in article), we can take a look, but please note if there are no actual errors reported, we won't be able to see anything except it is maybe slower than normal. SE/Pro have no concept of how long it 'should' take, and don't make comments about performance, because neither do the APIs...
(BTW, in case relevant: as per Help > Quick Start > 'Understanding Backup and Synchronization', SyncBackSE/Pro are not designed to (and can not) make an exact copy of a system drive)