Feature request: Backing up directly to a VMFS store

[robg]

When using an iSCSI NAS target for both replicas and backups, you have to divide it because Veeam only writes its backups to local windows or linux volumes, as far as I know, unless I overlooked something.

I'm doing it this way because I want the flexibility to instantly activate a replica and also have long-term backups (instant recovery Vpower isn't a good fit)

In other words you have some space in the NAS for replicas, and then you also have to create a virtual drive in it with NTFS and attach it to a VM to store backups.

It would be great for Veeam to be able to allocate part of that vmfs chunk directly for its backups.

[rennerstefan]

Hi
You could use NFS instead of iscsi as most NAS systems support both.
With NFS you can use the same for VMware as well as Veeam target.

I don’t think there is a way for us the write directly into vmfs as it a a VMware specific file system.

[robg]

Thanks, but I don't think that solves the problem.. if Veeam can't write to vmfs it's game over, you still have to split the NAS's native file system with vmfs to use one device for backups and replicas at the same time.

Is vmfs locked down completely to 3rd parties?

[Mildur]

It would be great for Veeam to be able to allocate part of that vmfs chunk directly for its backups.

Do you want to create a backup of the replica or do you want to store backups directly on a vmware datastore?

if Veeam can't write to vmfs it's game over

Veeam can write to VMFS over official vsphere APIs. This is used for restores. VMFS is not a Backup repo type.

I don‘t see any value in this, because normally you are not storing backups on an esxi datastore. You want to have them away from the hypervisor.

[rennerstefan]

Correct for restore we can but you are asking to use vmfs as a repo, correct?
As already mentioned that is not possible.

Also I don’t understand you saying that you have to split the NAS. I mean if you use NFS you can attach the same nfs to VMware as well as Veeam and just make sure you have a unique folder landing your backup.
And if you keep using vmfs you can create a vmdk to land backups.

Not sure if I understand your request correctly.
Please add details as needed.

Thanks

[robg]

Do you want to create a backup of the replica or do you want to store backups directly on a vmware datastore?

I want both replicas and backups.. The reason for replicas is instant recovery (just turn it on). Backups for historical archives

Veeam can write to VMFS over official vsphere APIs. This is used for restores. VMFS is not a Backup repo type.

I don‘t see any value in this, because normally you are not storing backups on an esxi datastore. You want to have them away from the hypervisor.

The backups are on separate hardware (nas), meaning the entire host can die and the replicas can run off the NAS attached to another host, and I am looking for the fastest possible way.

I want to store both the backups and replicas on the same filesystem.

[Mildur]

The reason for replicas is instant recovery (just turn it on)

You can use instant recovery with backups.
For Replicas, it‘s called fail over.

Just turning it on is not recommend for replica vms. It must be managed over vbr console. Or you loose the replication relationship with the original vm.

I want to store both the backups and replicas on the same filesystem.

Then please configure your NAS as NFS Storage. Like Stefan has already told you.
- ESXI can use NFS datastores.
- Veeam can use NFS datastores.

Problem solved.

[robg]

Correct for restore we can but you are asking to use vmfs as a repo, correct?
As already mentioned that is not possible.

Also I don’t understand you saying that you have to split the NAS. I mean if you use NFS you can attach the same nfs to VMware as well as Veeam and just make sure you have a unique folder landing your backup.
And if you keep using vmfs you can create a vmdk to land backups.

Not sure if I understand your request correctly.
Please add details as needed.

Thanks

You have it correct, but landing backups into a vmdk and all of the steps around that method is what I'd like to reduce as much as possible, I'm looking for the fastest possible restore.

If Veeam and ESXi can both share the NFS volume on the NAS device, then yeah no splitting is needed, but I haven't experimented with this, I wanted to stick with iSCSI for simplicity.

[robg]

You can use instant recovery with backups.
For Replicas, it‘s called fail over.

Just turning it on is not recommend for replica vms. It must be managed over vbr console. Or you loose the replication relationship with the original vm.



Then please configure your NAS as NFS Storage. Like Stefan has already told you.
- ESXI can use NFS datastores.
- Veeam can use NFS datastores.

Problem solved.

I'm aware of Instant recovery, and it has limitations, it's not a good fit (as I've said). I don't want to use failover, I prefer to do that process manually.

[Mildur]

I don't want to use failover, I prefer to do that process manually.

Really bad idea.
If you do it, please disable the replica jobs first if you can. And after that, use a new replica jobs to get the vm back to the original host.

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

Use Veeam Backup & Replication to perform failover operations. Avoid powering on a replica manually — this may disrupt further replication operations or cause loss of important data.

[robg]

It ain't my first rodeo Mildur, I've been using Veeam since about 2014. But thanks anyway

It's only a bad idea if you fail to account for everything that's required for it in your head, just like every other task in life.

And a replica job running off the same replica will fail anyway because 1) The source will be gone. 2) The destination replica would be locked and in use.

I'm aware of everything that failover does automatically and still prefer to do it myself

[micoolpaul]

Hey Robg,

Certainly an interesting feature request, I can see the reasons why you want this. I'd be very surprised if it ever was released though as there's so many questions that come up from this.

- As far as I'm aware, VMFS doesn't have block clone support, so your backups would be less space efficient vs having the two iSCSI LUNs with VMFS on one and XFS/ReFS on the other. With the option to thin-provision LUNs that works around some of the splitting of the datastores if you're in a constrained environment.
- I don't know that many people would want to use this, purely because of the risks of putting your replicas and backups into the same partition. (I'd have the same concerns with the NFS suggestion above of Replica & Backup, sure, it's possible, but doesn't align with 3-2-1-1-0 mindset as you're sharing the same file system between production, replica and backup)
- VMFS doesn't have anywhere near as high as ceiling for file size maximums & file system maximums vs ReFS, XFS, NFS etc (https://configmax.esp.vmware.com/guest? ... gories=2-0). So you'd be creating multiple LUNs potentially for backup chains (or creating a SOBR across the LUNs). Not a problem for smaller requirements of course, though arguably at that point you could just store the backups within a VM's VMDK at that point...
- I'd also be concerned with the noisy neighbour interference of backups running whilst running the replica etc, but that's not specific to the request, as you'd have the same with NFS.
- Finally I'd worry that without careful monitoring, we could have a replica (or replicas) running, another backup job runs to the VMFS datastore such as an active/synthetic full, and that wipes out the available free space, then the business continuity that the replica is supposed to be providing has failed.

Now the last thing I'd want to do is be rude or disrespectful, so please don't take this as such, but with all that I've said above in addition to the wider conversation: File size limits of VMDK, NFS already offering same functionality, general ill-advisory of sharing the resources. I'd be interested in your views on what benefits this could bring, other than the avoidance of managing LUN sizing (as NFS meets this same goal already and we don't want to reinvent the wheel).

[robg]

Great info micoolpaul, this NAS device isn't my sole destination for backups, the primary is another server's internal storage, and I also make copies off site..

Regarding noisy neighbors, file size maximums, etc, I don't see that as much of an issue because the backups are just a collection of .VRBs, they wouldn't exceed the size of the original vmfs files. It would be nice for them to co-habitate in the same filesystem (vmfs) with the replicas, for the sake of simplicity.. not having to deal with multiple LUNs, pre-carving storage, etc. Also I'm working in small environments with no more than a dozen VMs and a few terabytes.

[micoolpaul]

Thanks for sharing robg.

I was purely thinking of edge case scenarios such as, server has been ransomware'd, so we've invoked DR to the replica, forgot to disable the backup job and now the 90% of changed blocks for every backup is now creating a massive set of new files on the VMFS datastore and causing pain etc.

Being honest, I do see the simplicity of your scenario as something that is desirable for people. I'm of course in no way/shape/form employed by Veeam so my opinion here is probably worth as much as having an umbrella in a tornado, but the way Veeam seem to be focusing, on removing the reliance on file systems and pushing towards Object Storage (I'm personally so excited about this!), plus the amount of ground already covered by using NFS instead of iSCSI, I would be surprised if Veeam suddenly announced support for this. Especially as in the past they've had issues with introducing support for lower-end features causing them a lot of headaches (here's looking at you OneDrive repositories for Agent backups and SMB shares!).

As that's neither here nor there, and what matters right now is you need a simple method to work with for your particular scenarios NOW, and for that I agree with Mildur and the rest to give NFS a good look into. It's solidly implemented by most NAS vendors these days and meets your objectives from what I can see. Then Veeam can decide if this is a feature they want to invest resource into building support for!