If you don't back up very frequently, you're always vulnerable to having something recent taken.
If you do back up very frequently, you need to make some hard choices:
You need to connect to your backup media very frequently. But, you don't want any ransomware that may find you to also find your backup media; that would defeat the purpose of the backups.
Backing up a lot of data very frequently will end up requiring a lot of storage. If you erase old backups to save on storage, you're vulnerable to your latest backup turning out to contain only ransomware-encrypted data.
If I was hit by ransomware and needed to restore from backup, I'd make damn sure to mount that backup drive readonly.
Everything but the requirement to have your backup media connected frequently is a long-solved problem in corporate-level software, we just need to start seeing it at the consumer level.
The ransomware, while still in silent mode, will decrypt the data before the backup software sees it, so that the backup software doesn't see any changed data.
The ransomware could, however, know about a fixed set of backup programs, and, when it detects one is running, silently encrypt (parts of) backups of old data.
Things will get complicated for the ransomware, though. While in stealth mode, it must be smart enough to discriminate between files it encrypted and those that it didn't encrypt (yet). Otherwise, a test restore could fail. I would use an extended file attribute or a separate database (would be a single point of failure, but hey, it would not be _my_ data) for that, but from what I read here, lots of ransomware just encrypts everything in a target directory and then uses 'everything under directory foo is encrypted' (that should be done in a transaction, but ransomware writers wouldn't be too concerned about that)
That assumes that the ransomware has direct access to the stored backup data, which seems like a flaw in the backup system that you're imagining.
I've got a particular backup system in mind, which I've been basing my assumptions on when I reply. It has a way to add a new backup, a way to retrieve any old backup that hasn't been expired yet, and a way to see if a piece of a file has been backed up in the past, but the server itself doesn't provide a way to remotely change past backup data directly.
Flooding the system with new data to push old backups out (as sokoloff mentioned) would be possible, assuming that the ransomware generated enough new backup data to fill up the backing storage, especially if it were scaled to give enough storage just for one or two computers.
I'm just playing with ideas =) The software I'm familiar with comes with hardware, generally scaled to keep a few months of nightly backups of a few hundred workstations and some fairly powerful rulesets for data expiration...so I've never really had to consider malicious backup expiration by ransomware. It's an interesting set of problems to consider.
Done and done. Additional storage is only taken if a file changes. You can always use a snapshot to revert to an earlier version of the filesystem (in the case of a malware attack).
Actual backups of the NASBox do happen of course, should the case fall over and all the hard-drives get scratched simultaneously.
An alarm or quota on disk IO volume could mitigate this.
Since the NAS is the center of my important data, I pay attention to it more.
-----------
A business solution would probably need an alarm of some kind, because a busy IT professional isn't going to have the time to baby a machine like I do.
Its just the whole "computers are cattle in professional IT settings" but are "pets for the home user".
The attack happens on a file-by-file basis, within the free space that you have allocated on the live filesystem. foo.txt, bar.pdf, and baz.jpg are all encrypted in place, consuming only marginal free space during the operation.
Then, when the incremental backup happens, THAT will notice that ALL the non-OS files have changed and the backup consumption will explode.
Perhaps RAM snapshots could be employed as part of the backup to allow retrieval of the encryption key.