Backup Strategies for a Dev Machine: What Actually Needs More Than One Copy
A cloud-synced repo isn't a backup by itself -- a real backup strategy for a dev machine covers the things Git was never designed to protect in the first place.
The existing piece on UPS and power conditioning in this category covers protecting a dev machine against sudden power loss in the first place. Backups cover the other half of that same risk: what actually happens after data is already lost, whether from a failed drive, accidental deletion, ransomware, or a mistake nobody catches until much later.
A pushed Git repository, hosted on a remote you don't control the only copy of, is a genuinely solid backup for the code inside it -- that part of the misconception isn't wrong. What it doesn't cover is everything on a dev machine that was never committed anywhere: local environment configuration, database dumps, credentials and API keys deliberately kept out of version control, uncommitted work in progress, and any non-code files -- design assets, documentation drafts, personal files -- that were never part of a repo to begin with.
The standard framework worth actually following is the 3-2-1 rule: keep at least three total copies of anything that matters, store them on at least two different types of media (an internal drive and an external drive, or a local drive and a cloud service, rather than two partitions on the same physical disk), and keep at least one of those copies somewhere physically separate from the machine itself, so a single local event -- theft, fire, a single drive failure -- can't take out every copy simultaneously.
A plain synced mirror (a folder that continuously copies to another drive or cloud service) protects against hardware failure but not against ransomware or an accidental bad overwrite, since a mirror faithfully copies a corrupted or encrypted file right alongside every legitimate one, the moment it changes. A genuine backup strategy needs at least one destination that keeps versioned history or point-in-time snapshots, so a specific earlier, known-good version stays recoverable even after the corrupted version has already synced everywhere else.
The single most common gap in an otherwise reasonable backup setup is never actually testing a restore -- a backup that's never been restored from is an assumption, not a verified fact, and the only way to know a backup strategy genuinely works is running an actual test restore occasionally, before the day it's the only copy left.