Raw Luns (virtual) not visible in Veeam

[nicoletch]

Hoi folks!

Trying out Veeam currently, since our other backup solution broke for good a 2nd time (and not intending to set up everything again a 3rd).

All VMs are running with normal disks, with 3 exceptions:

2x VMs have 1x Mapped Raw LUN (virtual) each as 2nd disk.
1x VM (our Fileserver) has 7 Mapped Raw LUNs (virtual), all of them combined together into 1x 14 TB Disk (spanned volume) inside windows.
(All 3 Windows 2008 R2)

Not my prefered way at all, I just overtook it like that from my predecessors.

Anyhow, back to the topic:

How do I get those visible in Veeam B&R? I have read that pRDM's dont work but vRDM's should.
Or should I go via Direct SAN Mode? (Got full access to everything, so I could map it for that).
If I go via SAN Mode, how will the 7 Raw LUNs (-> the Datadrive from the Fileserver) be represented within Veeam?

Searched for hours, my brain is kindof a mash by now
Hopefully some experienced people can share some of their experiences & knowledge.

Cheers & thanks!

[PTide]

Hi,

Where do you expect them to be visible? Do you mean you can't see vRDM disks in job sessions or in backups?

Thanks

[nicoletch]

Hi,

The vRDM disks are not visible within the Virtual Machines node, which confused me, as I thought I can't backup those then.
I just created a test job and it caught the fact that the data drive is processed too: "VM size: 12.8 TB (100.00 GB used)".

Some more information to the infrastructure, since I left that out yesterday. Veeam is installed on a phyiscal server, which is part of a SAN Network, together with two SANs (MSA P2000 for the virtual infrastructure), Tape Library and the ESXi Hosts.

Is it in that case advisable to go for Direct San Access, to get an ethernet free process (except the vRDMs, since Direct SAN Access works only for thick-provisioned VM disks) ?

In our concrete example, all our VMs have thick-provisoned disks, with the addition that the 3 I spoke about have an additional vRDM. How would Veeam handle the backup job for those 3 VMs with Direct SAN Access enabled?
Would the system disk (thick-provisioned) go over direct SAN Access, while the vRDM would go over ethernet?

Cheers and thanks!

[PTide]

Is it in that case advisable to go for Direct San Access, to get an ethernet free process (except the vRDMs, since Direct SAN Access works only for thick-provisioned VM disks) ?

Thin-provisioned disks limitation applies only to Direct SANreplication and restores, so all disks will go via Direct SAN.

How would Veeam handle the backup job for those 3 VMs with Direct SAN Access enabled?
Would the system disk (thick-provisioned) go over direct SAN Access, while the vRDM would go over ethernet?

Since it's Veeam server connected to datastores via SAN the same server should hold the role of a proxy. Please refer to sys.reqs to make sure that the host is capable of holding two roles simultaneously. Btw, what about repository, what's your plan on that?

Thanks

[nicoletch]

Thin-provisioned disks limitation applies only to Direct SANreplication and restores, so all disks will go via Direct SAN.

Alright, thanks. Do I need to make the vRDM's avaiable (direct per SAN) on the Server as well, or only the Datastore which hosts the VMs?
If yes: How does Veeam handle the backup of the vRDMs in this way, especially of the Fileserver one, which consists of 7 vRDMs spanned together on one big single volume on the Fileserver (VM)?

I am probably making abit an idiot out of myself, I couldn't find such an example in the internet really. Veeam is a completely new world for me (coming from the other solution we had) but what I see so far I really like.

How would Veeam handle the backup job for those 3 VMs with Direct SAN Access enabled?
Since it's Veeam server connected to datastores via SAN the same server should hold the role of a proxy. Please refer to sys.reqs to make sure that the host is capable of holding two roles simultaneously. Btw, what about repository, what's your plan on that?

On the same server as well, basically the idea was that it holds all the roles (backup, proxy, repository & tape) needed. For the repository itself there is a storage bay attached directly to the server. From there it should go to Tape, for a Backup to Disk to Tape Configuration.
Our Backupserver has a Xeon with 6 cores (12 threads) and 102 GB RAM, after reading the sys.reqs I thought I could give that Idea a go.

[PTide]

Do I need to make the vRDM's avaiable (direct per SAN) on the Server as well, or only the Datastore which hosts the VMs?

Yes, vRDMs have to be visible to the Proxy server (VBR server in your case). This thread might be helpful.

On the same server as well, basically the idea was that it holds all the roles (backup, proxy, repository & tape) needed. For the repository itself there is a storage bay attached directly to the server. From there it should go to Tape, for a Backup to Disk to Tape Configuration.

Sounds good. Also I'd like to suggest you to setup some secondary storage in order to use it as a target for Backup Copy jobs, because tapes are more about long term archiving, while you might need another copy of a backup to be somewhere close and safe.

Our Backupserver has a Xeon with 6 cores (12 threads) and 102 GB RAM, after reading the sys.reqs I thought I could give that Idea a go.

You can give it a try. Just make sure that you have another machine with similar capabilities that can be hot-swapped in case something goes wrong with your primary VBR. Don't forget to do configuration backup for faster redeployment.

P.S. We also have recently published Best Practices for v9, worth checking!

Thanks.

[nicoletch]

Thanks alot for all the useful information! Much appreciated.

The storage bay at the server can hold 60 TB, for which I'd like to test and see now how long that can last with Veeam. Tape is indeed for long term archiving purposes (need to keep the data for 10 years).
If that's still not enough, yes I will have to think about an upgrade.

I will have a read at the best practices as well. For now I have setup a backup job over all the infrastructure to run tonight, lets see how that one will go. I will report back in

Cheers & have a nice Weekend!