Solved

Backup SAN volumes in VMs

  • 20 January 2022
  • 11 replies
  • 128 views

Userlevel 1
Badge +4

Hello,

 

I am wondering if there is some way to copy, through File System agent, SAN attached volumes in VMs without having to select them one by one for every client (or filtering all the rest of volumes).

My idea is to create a Virtual Server subclient to copy the VM itself and another FS subclient to copy the SAN-attached volumes, but avoiding copying again the content of VMDK for that VM. 

In a small and static environment, filtering the drives to exclude on a per-client base in FS subclient would be feasible, but if you have a big environment or an environment where VMs are constantly created and destroyed, the manual method is not possible.

Do you know if it exists a way to automatically select only the SCSI/iSCSI volumes of a File System subclient? Or, that is the same, automatically exclude the non SCSI/iSCSI volumes of a File System subclient?

 

Thanks!

icon

Best answer by Alessandro 24 March 2022, 09:05

View original

If you have a question or comment, please create a topic

11 replies

Userlevel 7
Badge +23

@Alessandro , would creating Subclient Policies help?  You’d basically create the configuration once and all associated subclients would follow.

If necessary, you could use wildcards for the content.

https://documentation.commvault.com/11.24/expert/14172_define_template_backup_for_file_servers.html

Let me know if that helps!

Userlevel 6
Badge +15

Hi @Alessandro 

When you write ‘copy’ , you mean to ‘backup’, right ?

Also, talking about SAN volumes, does it mean that for VMs, you use RawDeviceMapping/RDM ?

Or inside a VM, you have some SAN devices mapped but not mounted, and you would like the FS client to backup that ? :thinking:

Or is that related to mount points/mapped devices/volumes inside a server ?

Or maybe I did not understand what you mean.. Don’t hesitate to add more information or an example..

Userlevel 1
Badge +4

Hi Mike,

 

Thanks for the feedback! About the templates, I think it’s not exactly the solution but it’s in the path toward it.
You know, deploying through a template would work for an environment where you have two or three standard VMs, but imagine an infrastructure of thousand of VM where every VM is slightly different form the previous one: it doesn’t scale.

I.e. VM A has two disks + a SAN volume and VM B has one + a SAN volume 

You can’t create a subclient template for FS agent that says “copy all but the first disk” because VM A will have a local disk backed up through FS agent AND Virtual Server agent. And you cannot either create a subclient template for FS agent that says “copy all but the first two disks” because VM B will have not its SAN attached disk backed up through FS.

What I’m seeking is some kind of filter to apply to a Client Computer Group of clients of type File System that is able to exclude local disks (VMDKs).

 

Userlevel 1
Badge +4

Hi @Alessandro 

When you write ‘copy’ , you mean to ‘backup’, right ?

Also, talking about SAN volumes, does it mean that for VMs, you use RawDeviceMapping/RDM ?

Or inside a VM, you have some SAN devices mapped but not mounted, and you would like the FS client to backup that ? :thinking:

Or is that related to mount points/mapped devices/volumes inside a server ?

Or maybe I did not understand what you mean.. Don’t hesitate to add more information or an example..

Hi Laurent, sorry for the poor wording. Yes, when I say “copy” I mean “backup”.
The main point is, either I have RDM volumes or simple SCSI/iSCSI attached volumes, they cannot be copied through VM backup as VMware is not able to create a snapshot for them, so, if you want to copy their content, you need to use FS agent.

What I am looking for is some filter to apply to the Client Computer Group that contains all my VMs where I also installed FS agent. The filter should be able to exclude all the disks of the VM that are VMDKs and only include the volumes that would not be backed up through Virtual Server subclient.

The challenge is that every VM has a different disk layout, so I can’t just create a filter that excludes from FS backup the first “X” disks of the VM, because that will be ok for some VM belonging to that CCG and be bad for many others.

I hope this is more clear.

Userlevel 6
Badge +15

Yes @Alessandro now I have a clearer view.. (Don’t worry for the wording, it’s just to make sure we’re talking about backup and not snapshot backup copies or other close technical terms.)

 

We had the same considerations in my company before, and we could not find a suitable and scalable solution.

So we decided to backup everything using VSA, and get rid of all the RDM (or iscsi) volumes attached to VMs. This was also better for our virtual administrators and operators, as usual operations (snapshot/storage vmotion, and many key DR automated actions) could then be performed whatever kind of VM they were : no need ot worry about that, and that’s also not recommended (though possible or let’s say ‘supported’) by VMWare.

Thankfully a bit of money was put on the table to allow storage expansion to deal with this.

I would completely understand it’s not possible to move to such in your case.. 

 

One path we tried to work on was to make sure that all the ‘local’ volumes were labelled in a special way, like C: D  E: on a windows, or /, /local on linuxes, and all the non-vmdk disks were like R: S: T: on windows or /scsi1, /iscsi2 etc on linuxes.

That way, all the VMs would have the ‘local’ devices backup through VSA, and we could have global filters on filesystem clients to not backup /R: S: T: + /scsi*, /iscsi* paths on linux

But of course, it could be OK for new VMs to be created this way, but complicated (or impossible) to do this on existing VMs..  

 

Userlevel 1
Badge +4

Yes @Alessandro now I have a clearer view.. (Don’t worry for the wording, it’s just ot make sure we’re talking about backup and not snapshot backup copies or other close technical terms.)

 

We had the same considerations in my company before, and we could not find a suitable and scalable solution.

So we decided to backup everything using VSA, and get rid of all the RDM (or iscsi) volumes attached to VMs. This was also better for our virtual administrators and operators, as usual operations (snapshot/storage vmotion, and many key DR automated actions) could then be performed whatever kind of VM they were : no need ot worry about that, and that’s also not recommended (though possible or let’s say ‘supported’) by VMWare.

Thankfully a bit of money was put on the table to allow storage expansion to deal with this.

I would completely understand it’s not possible to move to such in your case.. 

 

One path we tried to work on was to make sure that all the ‘local’ volumes were labelled in a special way, like C: D: E: on a windows, or /, /local on linuxes, and all the non-vmdk disks were like R: S: T: on windows or /scsi1, /iscsi2 etc on linuxes.

That way, all the VMs would have the ‘local’ devices backup through VSA, and we could have global filters on filesystem clients to not backup /R: S: T: + /scsi*, /iscsi* paths on linux

But of course, it could be OK for new VMs to be created this way, but complicated (or impossible) to do this on existing VMs..  

 

Thanks @Laurent,

I see your point, unfortunately your method doesn’t look to fit in my company’s environment.
VMs are created and destroyed every minute and there are no limits on how the user can create them, so I don’t have a pattern to stick to...

Userlevel 1
Badge +4

I’m wondering if there is a way to select backup content based on a directive file/content file stored in the client itself like for ad-hoc backups...
If that was possible, we potentially could create a script that automatically creates that file on each client, including only SAN files.

Userlevel 7
Badge +23

@Alessandro , have you considered a Workflow?  You could potentially feed the scanned content into an On Demand backup Set….I’ve never done it, though it seems feasible.

@Chris Sunderland to keep me honest.

Userlevel 7
Badge +23

@Alessandro , following up on this one.  Were you able to find a solution?  Perhaps a Workflow?

Userlevel 7
Badge +23

@Alessandro , following up on this one.  Based on what you described, creating a Workflow would be your best solution.

Userlevel 1
Badge +4

Hi,

We eventually dropped that project. 

Solution is way too complex to implement and manage.

Thanks for the help though.