Backing up RDM volumes

[borgiaj]

Hello everyone.

We recently migrated from an old physical Windows file server cluster to hosting this file server data from multiple VMs, connecting the storage as RDM volumes. Our old physical server was zoned with and directly connected to our LTO6 tape library and being backed up using the Windows agent. Performance at times reached 200-350Mbps.

Following migration to the VMs using RDM volumes, performance has been dismal. This past weekend was the first weekend we attempted our full backups. It is taking more than twice as along to backup these volumes than usual. One of the jobs that kicked off at 0200 on Saturday morning is still running now, and is not yet half way completed. This is almost performance I would expect if it was backing up over the network, rather than directly to the tape library, which I almost think it is.

All I did was configure the VMs as tape servers and configured tape jobs for file backups like I did on the physical servers. Is there anything we can do to get the performance back for these backups?

Thanks,
Joe

[HannesK]

Hello,

All I did was configure the VMs as tape servers and configured tape jobs for file backups like I did on the physical servers.

you get the award for the "most creative Veeam" design from me (sorry, that award is really negative)

Is there anything we can do to get the performance back for these backups?

please use the software in a way we designed it. Backup to disk to tape.

I recommend to start with the quick start guide to learn about the basic functionality of Veeam: https://helpcenter.veeam.com/docs/backup/qsg_vsphere/

Real VMs (those without RDMs) should be backed up VM-based. Physical machines (everything with RDMs) goes with agents.

The way is always backup to disk first. Keep in mind: the software is built for restore. Restore directly from tape was okay in the last century, but not today.

Best regards,
Hannes

[borgiaj]

you get the award for the "most creative Veeam" design from me (sorry, that award is really negative)

That actually made me lol. That's fine. I was telling our VMware guy that I really didn't think this was going to work anyway. Especially seeing how the initial testing was going in terms of performance. Probably falls under the category of "it's possible, but just because you can do it, doesn't mean that you should".

Real VMs (those without RDMs) should be backed up VM-based. Physical machines (everything with RDMs) goes with agents.

I understand the basic functionality of Veeam, but I guess the only thing we were trying to accomplish with these file-to-tape backups for the RDM volumes were for FLRs for users who messed up their file server data. We were backing up the VMs without the RDM volumes. Again, since I'm not the VMware engineer here and didn't even realize until last week that you could attach a physical LUN to a VM, it sounds like what you're saying is, if I have a file server with multiple LUNs that are between 6-8 TB each, I should probably keep that solution physical, unless I have repository capacity to backup to disk first. Before I initially posted this yesterday, I already prepared them for the possibility that we might have to purchase file server hardware. So I should go with physical hardware under these circumstances?

[HannesK]

Hello,
physical (RDM) volumes are normally only needed for Microsoft Failover clusters and other "corner case" situations.

A file server can work with 6-8TB VMDKs as "real-VM". Having multiple smaller VMDKs makes it easier for disk restore and parallel backup processing. I have seen many virtual file servers between 30-55 TB (also a few larger ones where customers split one VM on multiple VMFS datastores - ugly design in my opinion)

File level restore works fine with the agent. You only need backup-to-disk storage.

Best regards,
Hannes