What happens when hard drive sectors get corruped?

[istrauss]

I'm using FreeFileSync with the RealTimeSync addon to automatically keep two external drives in sync (two-way sync). The drives should contain exactly the same data since I'm doing this for redundancy. It's pretty much a RAID setup with external drives tbh.

I saw the "sync.ffs_db" files in the root of both drives which made me think that RealTimeSync keeps track of all files that are present on the drives. When a sector on one drive goes bad, what exactly does RealTimeSync do? It would be pretty bad if it e.g. decided to delete a folder from the other drive, if it cannot access it anymore on one drive.

Thanks

[xCSxXenon]

A sector going bad does not show up as a missing folder/file. If a sector goes bad, first the HDD is going to attempt to reallocate it to a set of reserved sectors. If that isn't possible, you'll get SMART errors regarding "Uncorrectable errors", and that is when the possibility for data loss starts. But, at either stage, the file won't just cease to exist, causing the backup to also lose that file. It will still show up in file explorer. Although it may show up, it may not open or be accessible, obviously. This is when you would check the backup for a good copy of such file. Usually sectors don't fail until they are being written to, in which case you'll notice an issue because you can't save your updated file anymore, which is fine because you already have it open and can save it elsewhere. If you can't even open it, the backup is likely still viable. Sure, FFS may see a failed sector as a change in a file, but it won't be able to overwrite the backup since it can't access that file anyway, due to the bad sector(s). In short, it is very unlikely to have that chain of events occur, bad sector -> FFS sees a change in file data -> FFS is actually able to access that file and overwrite the backup. Also, you should have more than two copies of data if it's important enough to worry about this. Follow the 3-2-1 rule, 3 copies of your data, on 2 different storage types, and 1 copy offsite. The offsite copy won't be fully up to date, unless it is cloud-based or self-hosted and shared, but a month old file is better than no file.

The ffs_db files is like a snapshot that contains data about renames/moves to provide a faster sync, versus delete and copy when files get renamed/moved.

[Plerry]

For all clarity, and supplementary to xCSxXenon's reply:
*.ffs_db files are created and used by FreeFileSync (FFS), and are fully unrelated to RealTimeSync (RTS).

@istrauss: your approach has very little to do with RAID. It simply provides a full duplication of data in the form of two mutual copies on two different (logical and physical) drives.
All RAID configurations have in common that they appear to the user as a single logical drive, although data may be physically spread over multiple disks. And that for all RAID variants except RAID 0, all data is still available at logical drive level if one (or in some RAID variants: two) of the disks in the RAID set fail.