Air Gap Data Protection with Storware Backup and Recovery

Number of ransomware attacks has been constantly growing in recent years. No wonder that backup solutions are also being enhanced in this area. We did the same – with Storware Backup and Recovery 5.1 we introduced additional mechanism to protect data at rest from such attacks.

When ransomware attacks the system the usual scenario goes as follows: first exploit the system and gain access, then encrypt user data and then the user is informed that he must pay the ransom. Backup data obviously can also be of significant value, so no wonder, that there is a need to protect such data as well.

With Storware Backup and Recovery, the obvious way to create some sort of a boundary between the SBR Node and the backup data is to use object storage or one of the supported enterprise backup providers, cause node doesn’t have a direct file-based access (usually used by ransomware).

However file system backup destinations could be affected, cause these are constantly accessible by the Node. One way to protect such data would be to use Immutable Backup option or DD Retention Lock, but you still may want to have a clear separation between the node and the storage.

And here Storware Backup and Recovery can easily help you to achieve such scenario. Let’s start with build-in Air Gap Data Protection cases – currently there are 3 choices of backend supported – Rubrik Managed Volumes, Catalogic vStor Server and isoLayer.

Rubrik Managed Volumes

Rubrik Managed Volumes allow you to easily connect to your Rubrik environment and with each backup dynamically create a managed volume for each protected entity (which corresponds to a Virtual Machine, application, storage instance) and attach such volume on the fly during any task that needs to access backup storage for this entity. This means that the managed volume is mounted over NFS only during backup, restore, etc. and is not accessible all the time.

When ransomware attacks the node, even if it manages to reach the data during backup/restore – you still have additional layer of protection – Managed Volumes are based on the snapshot concept. This means that each change on the volume is a separate snapshot with the Rubrik SLA specified in the configuration file for Rubrik pre/post access integration module.

Managed Volume require a size to be specified when they are created and Storware Backup and Recovery and automatically adjust the size of this volume, as the backup data grows for each entity.

Catalogic vStor Server

Another snapshot-based approach is Catalogic vStor Server, which allows to do exactly the same as with Rubrik Managed Volumes with one additional option – replication. With every backup not only a new snapshot on the dedicated (per-entity) volume is created, but optionally you also can initiate replication of such snapshot to the secondary vStor server.

Same as Rubrik – for each entity an NFS-based share is created and accessed only during backup/restore sessions, but there is no need to adjust the size of the volumes.

Storware isoLayer

If you have any Linux (maybe not any, but closer to Red Hat family) which is able to expose an NFS share then isoLayer would be the way to go. With isoLayer you just need to provide SSH access details to your remote server and NFS settings and SBR will automatically create, attach and detach shares per-entity, to create such separation.

The requirement is to be able to expose NFS 4.2 shares and backend file system needs to support ref-links (usually XFS is used). This implies that unlike 2 previous options – this backup destination allows to use synthetic backups (which allow instant restore and forever-incremental backup scenarios).

A very important note – because this is not a snapshot-based approach it would be recommended to use it together with Immutable Backup feature, which locks the files from being removed or overwritten by the ransomware.

Custom storage

With Storware Backup and Recovery you also can easily integrate with your type of backend storage. In the file system (synthetic and non-synthetic) backup destination settings you have a section for pre/post access scripts. This is the hook where you can put your custom scripts to be executed. You just need to prepare 2 scripts which will be able to mount (and optionally create a volume) on the remote system and expose as a file system to the node.

These scripts are invoked in any store, clean old backups, connectivity check and restore tasks so just make sure to prepare such script to handle different contexts. In order to do that you just need to use environment variables automatically exposed as environment variables during its invocation. Here you can see an example configuration for isoLayer.

Remember that mount operation needs to be invoked as root, and by default SBR services run under vprotect user, so you need an additional entry in your suborders file (you can put it in /etc/sudoers.d similar to this:

%vprotect ALL=(root) NOPASSWD: /opt/vprotect/scripts/my-custom-bd/privileged.sh

More details can be found in the Storware Backup and Recovery Documentation.

Wrap up

Storware Backup and Recovery allows to create a clear gap between the itself and the storage that keeps your important backup data. It offers 3 build-in choices for smooth integration and allows to build add integration scripts with your own storage if necessary.