"ECC recovered" means that there were bit errors that could be corrected during read. That is not great, because there were media errors, but to a certain extent these are to be expected, which is why the ECC mechanism exists in the first place.
"Uncorrectable ECC" means that enough bit errors existed in a sector that ECC could only tell that some bits were wrong, but could no longer tell which (because if you know which are wrong, you flip them and get the right answer). That is an error that is reported to the host, and means data was lost.
If the host has another copy of the data (e.g. because the disk is part of a RAID array), then the sector is rewritten, possibly stored somewhere else (you'd see that in the "reallocated sector count") and the error shouldn't reoccur. If there is no other copy, then the error remains on the media, and every further attempt to read the data again reports the sector as unreadable and increments the "uncorrectable" error counter.
So it is difficult to tell whether this is a single error in a place that is used a lot, or a lot of errors in different places, and without a rewrite of the offending sectors, these won't go away.
I'd run a "long" offline selftest in the SMART utility, followed by chkdsk
with a bad sector scan (so chkdsk /r
followed by the drive letter), that should make the file system avoid the unreadable sectors, and tell you which files were damaged. This will keep the remapped count at zero, because the sectors will never be rewritten, and the space (a few kilobytes) is lost, but that's the best you can do in a single-disk setup.
The best way (in my opinion) to run chkdsk is as a scheduled task on startup. If that is the system partition, it should suggest that automatically. This will take a while as it will read the entire disk once.
In the long run, this disk probably has some issues, so make sure you keep backups. I have a lot of disks, and only one has similar numbers, so this is certainly not normal.