That poses at most a minor roadblock. You just take over the backup-and-restore service for a little while and corrupt the backups as they get made. If anybody tries to verify the backups they just restore them correctly until they make their demand. Would probably add between $10K and $100K to the cost of attack (probably closer to $10K), so would probably be immaterial to the profitability of this attack. Therefore, even if they did it they would almost absolutely still be attacked with exactly the same consequences if they did not pay the ransom.
Simple "common sense" solutions are pretty close to useless in these scenarios since they provide no meaningful impediment to halfway competent attackers. They stop children and script kiddies which is helpful in that there are a lot more of them, but essentially every actual economically-motivated attack remains viable.
To provide an analogy, the fence around a military base does good work stopping people from just walking onto base, but it does not stop the enemy tanks. That does not mean the fence is useless, it stops one kind of threat, but if tanks might actually attack the base you either need to have a way to stop them or be willing to take the loss. Throwing up more fences so it takes longer for the tanks to roll over all of them is not really meaningful if losing the base is still an unacceptable loss.
Ehh, a decent backup service (https://www.tarsnap.com/) will give you the ability to make write-only backups over time, i.e. you should be able to roll back to 6 months ago without any chance of something corrupting the backup process.
Of course, it depends how much data you're backing up.
To clarify I meant at the time of backup. When the data is being sucked out of the system to the backup they encrypt. All that requires is taking over the system pushing the data out to the backup for however long you want to deny backups. Obviously this requires not getting caught during that time, but the median time to discover a data breach is 279 days (~9 months) according to IBM [1] and this is actually easier to hide in many senses than a data breach since you are just messing with an existing data flow instead of trying to do the much more suspicious data exfiltration.
Simple "common sense" solutions are pretty close to useless in these scenarios since they provide no meaningful impediment to halfway competent attackers. They stop children and script kiddies which is helpful in that there are a lot more of them, but essentially every actual economically-motivated attack remains viable.
To provide an analogy, the fence around a military base does good work stopping people from just walking onto base, but it does not stop the enemy tanks. That does not mean the fence is useless, it stops one kind of threat, but if tanks might actually attack the base you either need to have a way to stop them or be willing to take the loss. Throwing up more fences so it takes longer for the tanks to roll over all of them is not really meaningful if losing the base is still an unacceptable loss.