How would you design a backup and restore strategy, and what is wrong with treating a sandbox refresh as a backup?

A sandbox refresh is a development artefact. Its timing is governed by the sandbox refresh interval rather than by any recovery objective, and there is no supported way to selectively restore records from it into production with their relationships intact. It is a copy, not a restore capability.

A real strategy starts from two numbers the business owns, not the architect: the recovery point objective — how much data loss is tolerable — and the recovery time objective — how quickly the business must be operational again. Everything else follows from those.

Then the mechanism that meets them: Salesforce's own backup offering, the scheduled data export service, or a partner backup product, chosen on frequency, granularity of restore, and how it handles relationships and attachments. Metadata needs its own answer, which for most orgs is the version control repository, provided it is actually current.

And then the part that gets cut: a tested restore, on a realistic subset, with the elapsed time measured against the recovery time objective. Nobody has a backup until they have completed a restore. I would rather present a modest strategy that has been rehearsed than a comprehensive one that has not.