New to FreeNAS - How To Back Up VMWare ESXi VMs to a FreeNAS

[LHemeryck]

Hi;

I have not used FreeNAS before but have installed and configured it as best I can. The issue I'm trying to figure out is how do I backup a Windows VM hosted on a separate VMWare ESXi 6.5 server to the FreeNAS? This is a non-production environment, just a test lab I use to play ...

Here's a summary of my test lab config:

VMWare ESXi 6.5 Server - 10.0.0.205
- hosts two Windows Server VMs (approx 400GB disk space used)
- this is the free version of ESXi 6.5

FreeNAS - 10.0.0.100
- FreeNAS 11.0-U2 (latest)
- configured with a single 4TB drive

I want to regularly (daily) backup the two Windows VMs hosted on the VMWare server (10.0.0.205) to the FreeNAS (10.0.0.100) for system recovery. Should the VMWare server go up in flames, I want to be able to easily recover the backed up VMs from the FreeNAS to another VMWare server.

I did lots of googling and forum searches and tried many things without success so if anyone could put together a simple step-by-step "How To" on how to accomplish this, I would be grateful!

Thanks in advance,
L

 

[Stux]

I would like to know how to backup ESXi datastores/VMs too.

 

[melloa]

There are several tools you can use, but if they use esx(I) API you won't be able with esx(I) free edition. Veeam is the one I've looked and has a free function to create a backup with its free version, but again won't communicate with esx(I) if you are not running a paid version (my case :( ).

I heard from the 'ld man he uses XsiBackup. Maybe you want to research that.

 

[jgreco]

ghettoVCB is one of the normal tools used when you've got Free ESXi and no access to the VMware API.

 

[LHemeryck]

Thanks I will look into these suggestions! L

 

[Black Ninja]

Speaking of backup vm to FreeNAS:

What I do for vm backup is, I use export to >OFV file and for Restore - Deploy from OVF file.

This make a single (compressed) file that don't rely on 3th party software, it's build in vSphere and always works flawless. Unless you need a backup of running VM I don't see any other reason to make it more complicated.

 

[Robert Riedel]

I have a spare drive where I make a copy and just remove the drive after making a copy.

 

[Black Ninja]

I have a spare drive where I make a copy and just remove the drive after making a copy.

It's not about there you putting it , it's about how you are making the backup.


If you just copy all files from a thin provision VM (which on ssd is logical choice) and then later decide to restore them back , thin provisioning is gone, and your files become thick. I can't just copy whatever files you find somewhere outside the ESXI and then pluck them them back for restore.

 

[Robert Riedel]

I thin provision mine on to a SSD and have a copy on a hard drive. When I restore them I delete them from the SSD and then copy them from the hard drive back over. They still keep their thin provision in ESXi 6.5. I have done this several times. I think the best way it could be done is a NFS datastare on FreeNAS that is accessible by ESXi instead of a hard drive but I am lazy. I just have not done it yet due to life keeping me busy.

 

[Black Ninja]

I don't know how is with 6.5 ,things could've changed. I use ESXI 5.5, but I still think the best way is to let ESXI handle the export <-> import of the VM, and then it wont matter if it's stored of USB FAT32, NTFS or NFS. If you purchase (or get free software) VM appliance it will come in the OVA file form.

 

[ragomez]

guys, read the following

https://blog.yavilevich.com/2016/03...oving-vmware-snapshot-integration-in-freenas/

regards
Rafa

 

[jgreco]

If you just copy all files from a thin provision VM (which on ssd is logical choice) and then later decide to restore them back , thin provisioning is gone, and your files become thick. I can't just copy whatever files you find somewhere outside the ESXI and then pluck them them back for restore.

I think what you're finding is that the act of copying with external tools tends to fill all sparse blocks with zero blocks. The VMDK's do not "become thick" but rather become fully allocated thin files. You can repair this on ESXi VMDK filesystems by powering down the VM and then running "vmkfstools -K foo.vmdk" on each of the VM's vmdk's. If you're running VMware Fusion or Workstation and have installed VMware Tools, you can actually ask for it to happen while the guest is running (note: the guest may be suspended for the duration) with "vmware-toolbox-cmd disk shrinkonly".

This is tied in with the whole UNMAP boggle VMware has been fighting with for a long time now. A nice summary is at

http://vsphere-land.com/news/automatic-space-reclamation-unmap-is-back-in-vsphere-6-5.html

 

[Black Ninja]

I think what you're finding is that the act of copying with external tools tends to fill all sparse blocks with zero blocks. The VMDK's do not "become thick" but rather become fully allocated thin files. You can repair this on ESXi VMDK filesystems by powering down the VM and then running "vmkfstools -K foo.vmdk" on each of the VM's vmdk's. If you're running VMware Fusion or Workstation and have installed VMware Tools, you can actually ask for it to happen while the guest is running (note: the guest may be suspended for the duration) with "vmware-toolbox-cmd disk shrinkonly".

This is tied in with the whole UNMAP boggle VMware has been fighting with for a long time now. A nice summary is at

http://vsphere-land.com/news/automatic-space-reclamation-unmap-is-back-in-vsphere-6-5.html

I sure this will work, but I don't see why go through this when much simple and clean solution is in our hands.
I'll quote myself: "What I do for vm backup is, I use export to >OFV file and for Restore - Deploy from OVF file."


P.S. Out of million other things you could help , you pick this one ?

 

[jgreco]

P.S. Out of million other things you could help , you pick this one ?:)

I can't just copy whatever files you find somewhere outside the ESXI and then pluck them them back for restore.

Sure, 'cuz it was an easy answer.

 

[Black Ninja]

Ones you learn/know something it always easy, to get there is the hard part.

 

[jgreco]

Ones you learn/know something it always easy, to get there is the hard part.

"it always easy"? No. For a lot of the stuff here, I actually have to stop and analyze information and details, and sometimes I don't. The guy who's having some strange performance problem and has posted reams of data can present a significant challenge, something I do not always feel like pursuing, especially if I only have a few minutes of spare time. Fortunately, this is no longer "the early days" of this forum, and there are plenty of other knowledgeable hackers happy to dig into stuff, so I tend not to feel obligated to help.

I am much more tempted to respond to things that others here are *less* likely to already know, even for longish answers. I think there are probably other people at or maybe even above my knowledge level for things like ESXi, but I seem to be one of the major posters for all things virty.

 

[Black Ninja]

I do not always feel like pursuing, especially if I only have a few minutes of spare time.

I am afraid you are right. I understand the value of time , and despite all the help you provide here , I am sure you have much more in your personal life/work that also need huge chunk of time. You can only prioritize I guess, what you think is important and what could be an issue that most people know and hopefully would help the guy.

I think there are probably other people at or maybe even above my knowledge level for things like ESXi

I am sure they are, but they might be missing more important ingredient. There is no value(the way I see it) to ask experts that knows more than me , if I think their process of thinking is wrong in a first place. I think the advice from a single person who you trust knows what he is talking about is more valuable than reading 100 opinion of random experts on internet, that could leave you in the same spot you were in the beginning - wondering for the right answer.


P.S. The people that really knows are not always (mostly not) willing to help sometimes, on the other hand the ones that have no clue are the ones most willing to help. I guess they are trying to "shine" as experts to the completely ignorant ones is my guess

 

[Stux]

I think what you're finding is that the act of copying with external tools tends to fill all sparse blocks with zero blocks. The VMDK's do not "become thick" but rather become fully allocated thin files. You can repair this on ESXi VMDK filesystems by powering down the VM and then running "vmkfstools -K foo.vmdk" on each of the VM's vmdk's. If you're running VMware Fusion or Workstation and have installed VMware Tools, you can actually ask for it to happen while the guest is running (note: the guest may be suspended for the duration) with "vmware-toolbox-cmd disk shrinkonly".

This is tied in with the whole UNMAP boggle VMware has been fighting with for a long time now. A nice summary is at

http://vsphere-land.com/news/automatic-space-reclamation-unmap-is-back-in-vsphere-6-5.html

Cool. So, does FreeNAS honor the UNMAP?

If so, then my iSCSI VMFS6 datastores, which are in use by ESXi 6.5u1 should be automagically reclaiming by default... just at the lower, and perfectly acceptable (to me) rate... right?

 

[jgreco]

Cool. So, does FreeNAS honor the UNMAP?

If so, then my iSCSI VMFS6 datastores, which are in use by ESXi 6.5u1 should be automagically reclaiming by default... just at the lower, and perfectly acceptable (to me) rate... right?

I'm not using ESXi 6.5 so I can't say from experience. Overall, I believe it should generally work, as some significant effort was put in by @mav@ on the new kernel iSCSI and ZVOL's to make UNMAP work, but because we're discussing features that have significant complexity at each level (guest, hypervisor, NAS) it appears that this doesn't always work as well as you might expect. Some debugging and other useful information in this bug report:

https://redmine.ixsystems.com/issues/19387

I remain firmly in the old-timers camp of building thin-provisioned VM's that do not do a lot of unnecessary writes, do a fsck_ffs -Z for all filesystems on newly built systems or during major maintenance, and then migrate storage or run vmkfstools -K as a secondary step to "squeeze the water out of the sponge." Like most tech, the UNMAP stuff is exciting but may underdeliver somewhat, and probably needs several more years to mature and reach that point of working as well as you might expect. This is tough stuff at each level. I do not envy VMware, in particular, because they gleefully introduced the UNMAP stuff in 5.0 thinking that it was the bee's knees, followed by an UNMAPocalypse and nearly immediate advice to disable it as it was crushing SAN arrays built by major vendors with hundreds of engineers, so @mav@'s work is competing favorably in a complex, rarefied arena against vendors with much larger engineering departments, and at a minimum everyone should buy him a beer.

Just trying to manage expectations there.

 

[Rickinfl]

I wouldn't install Veeam on any machine! I use GhettoVCB it's FREE and it works flawless and I don't have to do anything but setup a text file it reads from for which VM's to backup. It runs daily and weekly backups, because it's CLI most people are to LAZY to learn how to use it. Most people just want to point and click. GhettoVCB will backup running VM's on ESXI. I'm running the Free ESXI. Once setup you never touch it again unless you want to change something.

He updated it to work with ESXI 6.5 so ignore the versions. I have it running on the latest 6.5 on several machines at work.

https://github.com/lamw/ghettoVCB

Here is the Readme file... Located on VMware's website. 90% of this file you will not use

https://communities.vmware.com/docs/DOC-8760