[mindajar]

If TM detects an I/O error while writing to a networked backup volume, it aborts the backup and forces a filesystem check on the remote disk image at the start of the next backup. This fails, because the filesystem actually is corrupt and has been for some time. You had no idea, of course, because TM only reports four-horsemen level errors in the UI, and silently eats the rest. You even had a good run of "successful" backups afterwards, so long as you managed to avoid changing any files in directories with damaged metadata in your backup.

Anyway, as your digital life flashes before your eyes, TM helpfully offers to delete all your backups and start with a fresh disk image now, or delete all your backups and start with a fresh disk image later. And you can't blame it, really, because the filesystem has had some unknown, nonzero amount of corruption for an unknown, nonzero amount of time. For all anyone knows or can prove, the whole backup is random garbage.

This fractal of failure is specific to backups over WiFi. Backups to USB-connected disks aren't that reliable either, because HFS+, but USB backups have all the nines of reliability compared to network backups.