Using Veeam Agent for Windows within a VM protected with B&R

[RayVonGeezer]

Hi,

Just wondering whether anyone has done this, and if so if there's any caveats or cautions.

Basically we have a Hyper-V VM using storage spaces for a file store, and backed up with Veeam B&R to our on-premise repository and then to cloud with a Backup Copy job. We keep the last 30 days restore points on each repository.

For archive and compliance reasons we also have a need to keep older copies of the data from this server - and just the data, and it occurs to me I could use Agent to take a volume level backup.

This would have the added advantage that we'll be able to restore a file from the storage spaces volume without having to use Instant VM recovery to spin up the VM.

Has anyone done this (using Agent within a VM also protected by B&R)? Is it a valid configuration or are we asking for trouble?

Thanks in advance for any advice.

[Technogod]

This is not recommended. Use B&R to backup VM's to ensure proper recovery.

[RayVonGeezer]

Hi,

Thanks for the response.

Just to be clear, I am talking about using both - continuing to use B&R to protect the VM, but also Agent for an archive copy of the file store volume that can also be used for FLR.

Is your advice based on information you could point me to please? I did do a Google and a search of the forums but i couldn't find any information on this specific question - I did find one discussion on why B&R is obviously better for protecting VMs than Agent, particularly when it comes to recovery and management, but not anything on the pitfalls or limitations of using both together.

Thank you.

[Mike Resseler]

I'm not sure if you can run both at the same time (I don't think it is an issue but will ask if this scenario is supported).

But I might also misunderstand your requirement. Because you can do a volume recovery from inside a VM backup? Besides restoring a full VM or instant recovery and so on, you can do FLR recovery also so maybe that can fulfill your requirement?

Cheers

[Mike Resseler]

Hi RayVonGeezer,

I just got confirmed that it is possible, but you need to take the schedule into account so you can't have overlapping VSS snapshot creation. But still, see my message above. It might be more interesting to solve this differently

Cheers
Mike

[RayVonGeezer]

Hi Mike,

Thanks very much for the information - completely understood regarding VSS, I'll ensure the schedules don't overlap.

I'd welcome any other solution you can suggest because I know this is a bit messy!

The reason I'm considering this is (as well as giving us the archive copy we need) it will allow us to do file level restores without using Instant Recovery. FLR doesn't work with storage spaces, so as far as I know using IR is the only workaround (would be pleased if you know different!) but spinning up a backup VM when a user needs to recover a file that's older than the Shadow Copy is a chore.

Thanks and best regards.

[Mike Resseler]

No. Unfortunately that is indeed the case. FLR does not work with storage spaces. (To be honest, I missed that part about storage spaces in your original post )

So I guess that means I am out of cleaver ideas.

PS: Did you tested with VAW and storage spaces? (I haven't so I am not sure what the results are)

[RayVonGeezer]

Hi Mike,

Sorry for delay responding. After creating a copy of the VM in an isolated environment, I've today progressed to testing...... and unfortunately the results aren't promising!

I set VAW to do a volume level backup of the two data drives, one is a traditional single vdisk volume, the other the SS volume. VAW backs up the standard volume fine, then..... nothing.... So far as the Restore point detail screen goes, the clock is incrementing but the last item in the "Action" pane is the completed backup of the standard volume. Restore point size is frozen and no changes to the backup files, nothing in the App, System or Veeam Agent event logs either.

If I look in ResMon I can see VeeamAgent is constantly reading about about 100KB/s from \\device\harddiskVolumeShadowCopy\$BitMap but that's the only sign of activity since it completed the first volume backup about 3.5 hours ago.

I'm going to leave it running to see if anything happens, just out of interest, on the face of it either something is very wrong or SS isn't supported.

ETA - 10 minutes after posting this and VAW has started backing up the SS volume. Typical! My plan is to check if FLR is possible, then do a restore followed by a checksum comparison of the source and target data. Will update once done in case anyone is interested in the results.

[billeuze]

Case ID# 02636481

There are so many variables involved here that I need to get the starting point narrowed down a bit before testing. I started researching and ended up with too many questions. so...

Environment:
2 esxi 6.5 hosts (Del PE r730 and t630) on a vmware essentials license, 5 VMs per host
Veeam B&R 9.5

I am setting up a new file server on our newest vmware host. Planing to use Windows Storage Spaces in order to use our SSDs in tiered storage. Unless I missed something we cannot implement vcache or other types of tiered storage on the esxi host level without using an enterprise license which is way over our budget so Storage Spaces it is. This brings up 2 issues:

-1) I saw some articles saying Veeam B&R cannot backup Storage Spaces Volumes but Veeam Agent for Windows can but it cannot do file level restore - only the whole volume. Can someone please confirm or clarify this? I am considering using B&R to backup the OS disk and use Agent (on a different Schedule) to backup Storage Spaces Volumes. But I will need to be able restore one file or one directory at a time from the file share Storage Spaces volumes.

-2) Use Physical or Virtual RDM to pass the physical disks to Storage Spaces? What I have been able to learn is that i need virtual in order to enable vm snapshots which is required by Veeam B&R. But these discussions are about using a single RDM disk as a volume. If I can't even use B&R to backup Storage Spaces volumes (see above), then can I get away with using physical RDM? I imagine using physical will have slightly less overhead and fewer layers of virtualization that could go wrong (VMFS)

[PTide]

Hi,

I think that I have to point out that Microsoft does not support Storage Spaces in VMs:

Storage layers that abstract the physical disks are not compatible with Storage Spaces. This includes VHDs and pass-through disks in a virtual machine,<...>

Thanks

[billeuze]

Hmm, yes, I don't how much virtualization is involved with "pass-through disks" in Microsoft Hyper-V. With vmware, an RDM disk in virtual compatibility mode is definitely virtualized with the VMFS layer. but, according to https://docs.vmware.com/en/VMware-vSphe ... 94478.html "In physical mode, the VMkernel passes all SCSI commands to the device...all physical characteristics of the underlying hardware are exposed". So, other than the one exception listed in the above linked article, it would appear that physical mode RDM does not actually "abstract the physical disks"

At any rate, we do not have a support contract with Microsoft so, as long as something works, we do not require it to be in their officially supported list"

I also found something interesting about FLR with Windows Storage Spaces - that here might be a way to make it work if your backup server has the same version of windows as the Storage Spaces server: veeam-backup-replication-f2/guest-vm-wi ... 15928.html.

[billeuze]

Hi,

I think that I have to point out that Microsoft does not support Storage Spaces in VMs:

Thanks

Further to this. None of the research I have done to help me set up my system supports your claim. The article you quote only refers to virtualized disks not being supported in Storage Spaces. Like I said I came a across a number of examples of Storage Spaces being supported in VMs. I quickly googled and found this example from Microsoft (and there are others): https://docs.microsoft.com/en-us/window ... rect-in-vm In fact in this article they even support using virtualized disks (in Azure).

[billeuze]

For anyone interested. My implementation is similar to the Original Poster (although I can't tell from his information if the VM he is trying to backup is actually hosting its own Storage spaces or if it is mounting a Storage Spaces Virtual Disk hosted by another server).

What I have is a Windows Server 2016 VM on an esxi Host. This server is running Storage Spaces (not Storage Spaces Direct) using physical disks and SSDs directly attached to the host. They are presented to the VM as physical mode RDM disks. The system drive of the VM is backed up by Veeam B&R and the deduplicated Storage spaces volume (only one so far) is backed up by Veeam Agent to a B&R repository. So far Veeam Agent is working (no backup jobs have failed). File level restore tests are also working so far but with some issues:

First I installed the Agent on the VM itself and configured the backup job. Then ran a test file level restore from the VM Agent on the console. This all worked but I had limited options in the job setup and I could not configure a copy job to link to the backup. Veeam support told me to enter the agent license in Backup and Recovery - this gives me more configuration options and I can link copy jobs to it. I have 2 issues which I am still working out with support:

-1) If I have the Agent backup job managed by the agent itself, I can do file level restore right from the agent console on the VM. I can configure copy jobs to run against this backup job, but so far, the copy jobs don't seem to notice when the job is done as they don't kick in and start the copy job once the backup is complete. I get email notifications of all backup jobs -success or fail. But for this agent managed job, I get them 8 hours after the backup completes. I am still waiting to hear from support on these issues

-2) If I have the agent backup job managed by the B&R server, then the copy jobs run as expected. But I am not able to do a file level restore from the backup server - at least I thought I couldn't. I thought so because when I tried, I got a pop-up saying:

Copying data from deduplicated volumes requires that the console is installed on Windows Server 2012 R2 with data deduplication enabled

Well, since my backup server doesn't meet those requirements I cancelled the restore job. I believed this pop-up because it corresponded to what I read here at the end of this thread: https://forums.veeam.com/veeam-backup-r ... 15928.html. So I tried from a windows 2016 computer with dedup enabled and the Veeam backup console installed. I got the same pop-up warning but this time I clicked OK because I know I met the requirement - the file restore worked. In the meantime, I learned from support that what is important is that the MOUNT SERVER hosting the repository has to have dedup enabled. As this repository is hosted on the Storage Spaces server, this is not an issue. So I tried again from the Veeam Backup server which is not dedup enabled, ignored the pop-up and indeed the file restore was successful.

Still waiting for an update from support... but that pop-up message is misleading and looks as if it may be left over from a time when dedup had to be enabled in the console not necessarily in the mount server.

[PTide]

<...>The article you quote only refers to virtualized disks not being supported in Storage Spaces.

Right, it also mentions that the same applies to pass-through disks in a virtual machine, and I'm not quite sure how is that contradictory to what I've said. Each and every VM uses either virtualized disks, or pass-through, or both. Therefore, Storage Spaces is not supported for VMs, although it might even work in some cases.

Like I said I came a across a number of examples of Storage Spaces being supported in VMs.

I'm not sure if your definition of 'supported' is the same as mine. I say 'stuff is supported' when I want to indicate that there are specially trained people obligated to help you fix things in case the stuff blows up, at least to the point which is prescribed by SLA.

I quickly googled and found this example from Microsoft (and there are others): https://docs.microsoft.com/en-us/window ... rect-in-vm In fact in this article they even support using virtualized disks (in Azure).

The article talks about Storage Spaces Direct, which is not the same thing as Storage Spaces.

<...>but that pop-up message is misleading and looks as if it may be left over from a time when dedup had to be enabled in the console not necessarily in the mount server.

This has been noted, thank you for pointing that out.

Thanks

[billeuze]

OK, I stand corrected. I did some more searching and I can't actually find that MS supports SS in a VM. I thought I had come across it but I must have been mistaken. It is hard to search for server 2016 simple Storage Spaces as there is so much talk about Storage Spaces Direct.