At a previous company we used VCS and then PVCS. It was OK but a real drag to revert to a snapshot of the system - somehow you'd need to know it's this version of that file, that version of this file, etc. We solved that by applying a label across all files when we did a release (or just because), but per file versioning wasn't the way to go.
After some travels, paying for a quite reasonable system that's no longer appropriate or available, I settled on Subversion. Unlike xVCS it versions a project in its entirety, which is far more sensible. Subversion also comes, with the aforementioned in the thread, TortoiseSVN Windows client, which makes the whole thing very simple and easy to use. No remember arcane command lines, batch files, whatever - it's all embedded in your file manager (and hopefully you use a decent one, like DOpus, rather than Explorer, but it doesn't matter - TortoiseSVN integrates with them all).
World+dog has gone git mad, and any random hip developer will insist git is the only proper way to go now. Git is good for what it was designed for, which isn't what many of us are doing. There is a TortoiseGIT client for Windows (this stuff is what keeps Windows relevant for development IMO) but it's still git and easy to screw up in many weird ways.
Subversion scores for me because it has a master repo (you can have mirrors and change where the master is, but it's a star topology). Where you do stuff is just a checked-out copy that has no bearing until you check it back in. Practically, that means you can do silly stuff which affects the core of the versioning (like merging with completely inappropriate options) and end up with a completely trashed and worthless copy. No problem: just delete it, check out another and try again. I usually have several copies of the same thing checked out - one might be for trying stuff on, and another the real working copy. None of them are important and I can delete them as and when I like.
It really is difficult to screw up subversion. Even if you willfully break things and then check it all in so the repo is polluted, you can just go back to the previous revision and bypass the mess you snuck in there. I think you need to actually delete the repo to score a hit.
With git, you can't do that so easily. The working copy is THE authoritative repo and if you vape the folder you will lose the lot. Sure, you can make copies and all that but keeping track of what's where can be a hassle. I usually have a master repo and then push stuff to that at every check-in so it acts like the master repo. But essentially it is forcing a square git into a round process.
Git does have advantages when it comes to branches and merging, although it's not as foolproof as the walk-throughs and how-tos make it look. For a single developer used to backups as version control, it is way over the top and more likely to put you off than solve anything.
For subversion, I keep the repos on a NAS. The NAS is backed up every day en bloc and things like the repos folder(s) are separately backed up to alternative media. There is no problem having the repos on your main PC and having those backed up as anything else would be. Having them off-PC doesn't really protect against ransomware unless you keep them offline when not actively accessing them, but offline backups are a step in the right direction (although not infallible).