Author: Michael Melter

Posted on

Veeam Storage Plugin for DataCore – V1.2.0 improvements

I already discussed the initial version of this plugin in https://www.elasticsky.de/en/2020/06/veeam-storage-plugin-for-datacore-deepdive/.

The cosmetical “1970” bug mentioned in the blog post above has already been fixed in an interims release. With V1.2.0 now we get full CDP support. CDP in this context does not relate to Veeam’s functionality of the same name. DataCore maintains a feature with this acronym for at least 10 years already.

I also explained a workaround to leverage CDP rollback points with the old version of the plugin already. We will not need the workaround any more, as the plugin now detects CDP rollback points just like it detects snapshots on your SanSymphony volumes!

The first installation of the plugin is pretty straightforward and was also discussed already. To update your installation, the new version of the plugin can be installed on top of the old one. Just disable all jobs beforehand and wait for VBR to become idle. The installer will replace the plugin files within the path.

C:\Program Files\Veeam\Backup and Replication\Plugins\Storage\DataCore Software Corporation

Once installed and configured, VBR will detect all CDP rollback points you create from the DataCore console right away and will let you do all recoveries as with common snapshots. The difference is, that you do not need to have any snapshot schedules. Just enable CDP for your volumes. Only when necessary, create your rollback to the exact moment in time needed. Could e.g. be just a few seconds BEFORE the ransomware started to encrypt your fileserver. This allows to lower your RPO for all VMs to a few seconds.

In contrast to snapshots you are currently not able to generate rollback points from within your Veeam console. You have to jump to DataCores console. This is because some extra decisions have to be made to generate a rollback point:

  1. Exact point in time to spawn the rollback point to
  2. Type of the rollback point: either “Expire Rollback” or “Persistant Rollback”

The amount of time you can rewind depends on your license within DataCore on one hand and the size of the history buffer you reserved on the other. I would strive for at least 8h here, to allow for rolling back a regular working day. But more is even better of course. For a 24h buffer you would have to reserve your daily change rate as a history buffer at least. So have some extra disk space ready.

An “Expire Rollback” will automatically be disposed, once the rollback point in time moves out of this history buffer. This could of course be dangerous in a recovery scenario, as you would all of a sudden loose the valuable restore point. Maybe right in the middle of a recovery. This is why in the default settings only a “Persistant Rollback” will be detected by Veeam. But this can be changed of course. Read about the details in this whitepaper.

I would though recommend to stick with only detecting “Persistant Rollbacks”. Those rollbacks should preferably only be used with mirrored volumes. Here a rollback will still be secured once it reaches the end of the history buffer. Now the productive volume on the side of the history buffer will be disconnected. With a mirrored volume this will result in a volume running from only one side of your cluster. But your VMs will be available and so will the rollback point.

One should plan for CDP accordingly. Have an independent disk pool for your history buffer to minimize performance penalties. This buffer should offer the same performance rate as the productive pool does. I would recommend 32MB as a SAU (Storage Allocation Unit) size for the buffer pool. For the productive pool I usually stick to 128MB, though 1024MB is the default now. This enhances granularity for AST

Posted on

ExaGrid Time-Lock – Who’s (still) afraid of ransomware?

Introduction

Ransomware currently represents one of the most prominent threats to IT infrastructures. Reports of successful attacks are accumulating, the attacks are getting closer. More than 30% of all companies, institutes, universities or public authorities in Germany have already dealt with such attacks. In some cases, a ransom was paid to get access to their own data again.

Even with payment, success is never certain. After all, one negotiates with criminals. Authorities therefore advise against payment.

The essential protective measure against the consequences of such an attack is an up-to-date and consistent backup.

Ransomware vs. Backup

Unfortunately, attackers also know about the importance of backups. The currently circulating malware, such as Emotet or Ryuk, contain code that actively searches for backups on the net. Using previously obtained access data for Active Directory accounts or by attacking via RDP exploits or using the brand-new Zerologon exploit an attempt could be made to take over the systems that operate the data backup in the company or hold the backup data.

The automatic attack is often followed by hackers in the flesh who actively browse the net and try to destroy all backups. This is often an easy task, since backups today are preferably held on hard disk systems, permanently connected to the infrastructure.

The reason is obvious: If all backups are deleted or also encrypted, the compliance of the “customer” to pay his ransom increases by far.

Many approaches have therefore already been conceived to store the backup data out of reach of an attacker. A very simple and secure variant is an Air-Gap – a physical separation of the backup media from the system. For example, LTO tapes can be physically removed from the library.

Without this kind of time-consuming manual extraction – which would also have to be performed daily – the data remains latently vulnerable. It doesn’t matter whether it is stored on disk systems, dedup appliances, tapes in a library or even in an S3 cloud repository.

S3 cloud providers have therefore proposed an API extension called “Immutability” some time ago. With this, at least the backups in the cloud layer can be made immune to changes for a certain time.

Some of these solutions are natively supported by Veeam. Amazon AWS is one of them. Microsoft Azure is currently still missing. Furthermore S3 memory is not suitable for every application. A primary backup with Veeam on S3 is for example not directly possible. The S3 layer is only available as an extension of a scale-out backup repository.

Continue reading “ExaGrid Time-Lock – Who’s (still) afraid of ransomware?”
Posted on

Veeam Storage Plugin for DataCore – Deepdive

Any questions, remarks or additions: melter[at]idicos.de

SANsymphony meets Veeam Backup and Replication – true love in the end!

In December 2019 the plugin for the popular DataCore SANsymphony SDS was finally released. And it is done in the only proper way: With full support and validation by Veeam.

In this article series we will cover several aspects of the plugin:

Continue reading “Veeam Storage Plugin for DataCore – Deepdive”
Pages: 1 2 3 4 5 6