- Veeam ProPartner
- Posts: 252
- Liked: 26 times
- Joined: Apr 05, 2011 11:44 pm
that datastore it mounted shows a total size of 99GB total size and 63GB free.
As I've watched that mounted datastore - it appeared veeam was copying VMDK files for the machine that we needed to restore file from. Those files are 2TB each and there are 5 of them (At least provisioned size and actual size showed 0).
So...what's going on here? Where are these files copied/mounted? What happens if during this restore operation there is a network issue and the connection is lost? Where would we clean up those copied files? Do we need be careful when attempting this process and do it on a server with 10TB of space? Will Veeam try to unpack 10TB of VMDKs on NAS while doing this?
When i "Canceled" the process - the NAS was not unmounted. And it still shows those files on a mounted storage. Where do i go to clean it up?
The IP address that wizard asks for: since we are restoring from a backup of a production server, i wouldn't want to have the backup of that server come up and on production network. Or it just the "appliance that gets mounted?
I guess i'm looking for details on how all of this really works
- VP, Product Management
- Posts: 5967
- Liked: 2819 times
- Joined: Jun 05, 2009 12:57 pm
- Full Name: Tom Sightler
Seriously though, it's really far simpler than you are making it. The files are not copied to the "datastore" and virtually no disk space is used at all.
The first thing to understand is that the "Other OS" FLR uses the same technology that it used for Instant Restore and Surebackup, i.e. vPower. Specifically, it's the vPower NFS feature. When you install Veeam on any server, the Veeam server includes this component although you can also make other Windows servers in your environment vPower servers as well. By default, the vPower NFS server uses a directory on the local Windows C: drive for a "cache" area, so when Veeam mounts the vPower NFS datastore, the "space, and free space" would typically be equal to the size a free space of this volume.
The second thing to remember is that Veeam backups files are basically just block stores, that encapsulate the blocks that makeup your VMDK files in a compressed and deduped format, thus how we are able to restore the entire VM, individual VM disks or VMDK files. The vPower NFS service simply presents the ESX host with what it thinks are the entire VMDK files, however they are really nothing but a "container" with nothing in it. When VMware request blocks from this VMDK file via NFS, the vPower NFS service actually retrieves the blocks from the Veeam backup files, decompresses the block, and fulfills the request. Effectively, VMware thinks it is retrieving blocks from a normal VMDK file, but in reality it is actually reading blocks out of the Veeam backup files.
For the "Other OS" FLR we mount the vPower NFS store, present the VMDK's of the requested VM as defined in the selected restore point, then start a small Linux "helper" VM that has support for many different filesystems, which then boots, scans, and mounts the disk volumes. As VMware requests blocks from these "fake" VMDK files, the vPower NFS retrieves them from the backup files.
If there was a network failure or other issue, there would really be nothing left to "recover", although there may be a small FLR helper VM still in vCenter that could be removed. There are certainly no files or anything that needs to be removed since no "real" files are ever actually created.
Also, we normally leave the vPower NFS store mounted to the host so that we can save time the next time a vPower feature is used since the store will already be mounted.
Users browsing this forum: No registered users and 11 guests