Skip to main content

For those with IBM Flash System Storage, you will have noticed a surprise at the end of your 12.2 upgrade. It will ask you to install the plug-in on your Veeam server at the end of the process. It will also tell you that backup jobs may not work properly until you do.

 

The first take away is don’t start this upgrade at 3PM on a Friday thinking you have plenty of time to upgrade your entire Veeam infrastructure before the end of the day.  This extra step didn’t take too long but still added some extra time to the process. As with anything, check the release notes, and compatibility with all hardware, software, and firmware before doing installs on production servers.

 

 

 

This is a very simple install that requires hitting next a few times and waiting. 

 

Setup

 

In this test, I’m using both backup from storage snapshots, as well as snapshot only jobs. Snapshot jobs are easy to configure as seen below.

For the backup repository, choose snapshot only. If you configure a secondary destination, you can replicate them to another SAN using Metro Mirror as policy based replication is not yet supported. For this test I am taking a snapshot every 6 hours. 

 

 

Veeam can’t do immutable copies, yet, so the IBM internal scheduler will be the best way to use this, however this is supposed to change soon. You may still find yourself using these jobs all the time along side the internal scheduler. 

 

 

So what did it do? 

 

Under storage infrastructure, you have the ability to take Volume or LUN level snapshots containing VM’s. 

From the storage snapshots, you can restore guest files, perform instant recovery, or even application items such as AD objects, or emails from Exchange.

 

“But I was already using this without the plug-in”.

You may have been using Veeam's ability to perform storage level snapshots, but lets go to the SAN now and see what's different. Keep in mind that I am on firmware 8.6 for these tests and you should do your own research for compatibility.

 

Before 8.6 and the plug-in, Veeam was creating Flash Copies on the SAN. This will remain true if you don’t update your firmware, or are using a V7000.  IBM has since replaced this with their V2 Snapshots.  This becomes an issue if you have a lot of volumes as they show in every view.  Keep in mind, this test was only a few volumes and jobs. Imagine keeping dailies for 30 days and weekly or monthly jobs on a few hundred volumes.    

 

 

Using the new plug-in, you can see see actual volumes, and how many Snapshots are located on each. 

 

If you double click the volume you can see more snapshot properties, including the time it was taken and if it was Safeguarded (Immutable)

 

 

 

Here is where things get a bit tricky.

You need to have volumes in a VolumeGroup to create the V2 snapshots.

So how does Veeam create snapshots outside of a volume group.

 

First, using the audit log, I found it very interesting that Veeam is creating the snapshots with the following command.

svctask addsnapshot -volumes ## -name VeeamAUX_VOLUME_NAME -ignorelegacy

 

-ignorelegacy  (Optional) Specifies the addition of the volume snapshots although there are already legacy FlashCopy mappings using the volume as a source.

 

In the audit logs you will see Veeam removing the Snapshots from the VolumeGroups using the svctask rmvolumegroup # command.

 

By taking the volume out of the volume group, I don’t have the ability to mount, delete, clone, or even interact with the snapshots. Veeam is the only thing in full control of them.  Once immutability is released for integration with Veeam, it will take it one step further. 

 

If you have fast storage (like an IBM Flash System) Yo could be running instant restore on 100’s of VM’s in a live environment from immutable snapshots within minutes of an outage. 

 

 

 

 

Interesting Scott. I use Nimble myself. I took Veeam out of the Snapshot task taking process once I upgraded/recreated my enivornment last yr. I now only manage it on my arrays (reasons why; hope to reintegrate this within Veeam next go-round). I’d like it if HPE would add immutability to snaps. Still waiting…

Thanks for the post!


Interesting Scott. I use Nimble myself. I took Veeam out of the Snapshot task taking process once I upgraded/recreated my enivornment last yr. I now only manage it on my arrays (reasons why; hope to reintegrate this within Veeam next go-round). I’d like it if HPE would add immutability to snaps. Still waiting…

Thanks for the post!

Once Veeam supports immutability I’ll be doing it more from Veeam for everything, Right now the IBM scheduler internally is pretty nice. Veeam is not able to delete them, can still restore from them etc. 

Where the Veeam enabled snapshots are fantastic is the fact that I can have a daily backup of my file servers, yet every 6 hours say, or 3 hours. or 5 minutes if you want, you can have the SAN take a storage snapshot with no performance decrease or stun.

When a user says they deleted a file at 5 PM, I don’t have to tell them, sorry last nights backup was from  9PM the night before and you lost a days work. 

Perhaps I’ll do another post on cloneing storage snapshots to thin clones to use your production VM’s for testing. (similar to what SureBackup and Veeam labs do) but the manual way.   It’s handy if you replicate SAN volumes to another site to be able to test, or actually restore them when you need them. 


I actually had to do something similar last week. I had to Clone a Snap then present it to vSphere as a temp Datastore to recover some files from a coworker's dev server. 


Comment