Object First, a company that sells backup storage, paid analyst firm Omdia to survey IT and business leaders, and the results came out on 3 September 2026 under the title “Recovery Without Compromise”. The headline number is an odd one. 93% of respondents said they want backup storage with absolute immutability, meaning nobody can modify or delete the backup data, and yet only 16% said what they run today actually does that.

A vendor of immutable storage has every reason to like that finding, so take it with some salt. Still, the fix for most teams is a lot smaller than a new storage platform. You need one backup copy that an attacker who already owns your main environment can’t reach or delete, and an offsite server rented from a host such as PrivateAlps can do that job if you set it up properly. Below is what immutability really means and how I’d configure a storage VPS for it.

How often does ransomware reach the backups?

Omdia talked to 700 people, 500 IT decision makers and 200 line-of-business leaders, across the US, the UK, Ireland, France and the DACH region. 83% of their organisations had been hit by a successful ransomware attack in the previous 24 months. When the same survey ran in 2024, that figure was 66%.

Recovery got worse over the same stretch, and that’s the part I’d pay attention to. In 2024, 57% of victims got back at least 75% of their data, while in 2026 it was 39%. The share back up and running within five days fell from 49% to 39%. So more companies are getting hit and fewer of them get their data back, which says a backup that exists and a backup you can actually restore from have drifted a long way apart. Object First’s CEO, David Bennett, argues that recovery can’t depend on backups which can still be altered or deleted. You’d expect a vendor to say so, though respondents lean the same way, with 83% of them calling backup storage their last line of defence against ransomware.

Why one copy should live outside your main environment

The old 3-2-1 rule still does most of the work here. You keep three copies of your data on two different types of media, and one of them goes offsite. Where it usually goes wrong is the offsite bit, because plenty of companies tick that box with a second server in the same building or a cloud bucket run from the same admin account as everything else. That’s fine when a disk dies and not much use once the intruder has your domain admin password, since they’ll simply follow those credentials to the “offsite” copy as well. For that copy to count it has to sit on its own infrastructure, with logins that don’t exist anywhere else in the company, so breaking into your main environment gives nobody a way in. A different provider in a different location helps a lot here, and a PrivateAlps storage VPS rented in a separate data centre is one easy way to get both. You’ll also hear people talk about 3-2-1-1 now, where the extra 1 is a copy that’s offline or immutable.

What does “immutable backup” actually mean?

Strip away the marketing and an immutable backup is a copy nobody can change or delete before a retention date you picked in advance. Nobody means nobody here, your own admin included, and also whoever has stolen that admin’s password. Most backups out there don’t behave like this at all. They live on a NAS or a backup server joined to the same domain as production and reachable with the same passwords, so when someone gets into the network they usually get into the backup console on the same afternoon. Attackers know it. They go looking for the backups first and wipe them before they start encrypting anything, because a victim with no restore points left is far more likely to pay. Omdia sets the bar even higher in its study: in its definition, absolute immutability has to hold against the most privileged admin in the company, or an attacker with access to all of its IT secrets.

Using a storage VPS as an offsite backup target

A storage VPS is basically a virtual server built around disk space, with fairly modest CPU and RAM, which is why it’s a cheap place to park the offsite copy. You rent it outside your own network and give it accounts that exist nowhere else in your organisation, and since it runs in another data centre on someone else’s hardware, a breach of your office or your main cloud tenant doesn’t automatically spill over onto it. I’d pick a Linux box for this, because pretty much every backup tool that does append-only or immutable repositories runs happily on plain Linux. What the VPS won’t do on its own is stop anyone from deleting your backups. Out of the box it’s just a server with big disks that root can wipe, so the protection comes from how you set up the backup repository on top of it.

On the repository side, restic’s rest-server in append-only mode will take new backups from clients and refuse deletes and overwrites, and Veeam’s hardened Linux repository is built around the same idea. If you’d rather have an S3-compatible object store, you can run MinIO on the VPS and turn on object lock in compliance mode, after which even a valid access key can’t remove a locked object before its retention date. I’d also let the backup server pull data from production rather than have production push to it, and if you must push, use a dedicated key that can write but can’t delete. Encrypt everything before it leaves your network so the provider only ever holds ciphertext. Keep the root password and the provider’s control panel login out of your main environment entirely and behind MFA, because all of the above falls apart if someone can log in there with a password that also lives in production.

A quick checklist before you rely on it

Before you call the offsite server your safety net, run through this:

• Separate credentials for the VPS and the provider’s control panel, used nowhere in your main environment, with MFA on.
• Backups get pulled by the backup server, or pushed with a key that can write and can’t delete.
• Append-only mode or object lock is actually switched on, and retention runs longer than an intruder could plausibly sit in your network unnoticed.
• Data is encrypted before it leaves, and the keys live away from production.
• Test restores happen on a schedule, onto a clean machine. If you’ve never restored from it, you don’t really know it works.

Common questions

What is an immutable backup?

It’s a backup that can’t be changed or deleted by anyone, your own admins included, until the retention period you set runs out. That’s the whole point of it, since people who break into a network tend to end up with admin credentials, and with a normal backup those credentials are all they need to wipe your restore points before the ransom note arrives.

Is a storage VPS enough to protect backups from ransomware?

Not by itself, because anyone with root can delete whatever’s on it. It turns into a solid offsite copy once it has its own credentials, gets its backups pulled instead of pushed with production keys, and runs an append-only or object-locked repository.

What is the 3-2-1 backup rule?

Keep three copies of your data on two different kinds of media and put one of them offsite. During a ransomware attack the offsite one is usually the copy that saves you, as long as it’s on separate infrastructure with logins an intruder in your main network can’t use.

How do I know my backups will actually restore?

You restore them. Do a test restore onto a clean machine on a regular schedule, and again after any big change to your systems or your backup setup. The Omdia numbers are a good reason to bother, given that in 2026 only 39% of organisations hit by ransomware got back at least three quarters of their data, down from 57% in 2024.