Questions and answers backing up/cloning a VM NFS

Situation :

1. I use vsphere 5.1 with thin VM.
2. I will only use virtual machines for backup targets.
3. I am currently using Windows 2003 Server VM, projecting an NFS volume, to back up to. A big advantage of this is NTFS compression. The problem is from 2003 and 2008 cannot manage virtual machines without running frequently in file size problems. Example: I have a 1 TB NTFS compressed volume I export as a NFS volume. It has 667 GB of free space. If I clone a virtual machine that has a declared 80 GB size and a slim waist 42 GB, is the command and the result:

# vmkfstools-i d inh.vmdk thin /vmfs/volumes/nas-2/backups/server1/inh/inh-2014-03-19_05-22-41/inh.vmdk

Destination disk format: thin provisioned VMFS

Cloning disk "inh.vmdk"...

Clone: 78% of fact. Impossible to clone the drive: there is not enough space on the file system for the selected operation (13)
A few days later, after a few copy and delete could start working again, or I can run chkdsk on it, and he will back up again. You can run the chkdsk command 10 times in a row and getting errors every time. Microsoft knows the problem, did not fix, it has not been set, and if they have not fixed now, I doubt they will ever be, because those aren't their current products. At the time virtualization and files of several gigabytes were not a market reality.
4. I read that ESXi is default for thin then copy to NFS, and I specify in vmkfstools when you are copying anyway.
5. to correct my backup file of the size matters, I thought I'd use a? NIX to replace 2003 as the VM NFS for backup. It seems? NIX is no good compression options. ZFS looks like its as good as it gets, and from what I've read, it's great to manage a large number of data and records, but slow and a resource hog for this type of work.
6. I decided just thin backup would be good enough, and I could go out without compression. However, when I tested the backups on the NFS volumes, they used their full size declared. Here are the results of these measures.

As backed up to a volume of Windows Server 2003 NFS
# ls - l fstop - flat hard
-rw - 1 root 42949672 85899345920 Mar 14 06:53 fstop - flat hard

# stat fstop - flat hard
File: fstop - flat hard
Size: 85899345920 blocks: block IO 167772160: 131072 regular file

Calculation:
167772160 * 512 = 85,899,345,920
85,899,345,920/1024/1024/1024 = 80 GB (full size, not thin)

Same virtual machine running on VMFS Volume:
# ls-l fstop - flat hard
-rw - 1 root root 85899345920 15 March 23:11 fstop - flat hard

# stat fstop - flat hard
File: fstop - flat hard
Size: 85899345920 blocks: 124723200 IO block: 131072 regular file

Calculation:
124723200 * 512 = 63,858,278,400
63,858,278,400/1024/1024/1024 = 59.47265625 (thin) GB

Another VM saved on a compressed volume of NFS for Windows Server 2003
-inh - flat hard has a declared 80 GB size
-As thin on VMFS, it has a size of 38,72 GB
-Also supported up to a window thin hard, with NTFS compression, projected as an NFS share is 19.26 GB

Analysis/thoughts:
1. the VMware docs state that, by default, VMDK made on an NFS volume are slim. In fact, when I backup my thin VMs to an NFS share and restore to a file system vmfs, the hard just thin back, so there is no doubt that it is stored as thin.

2. even if a hard backed up on an NFS share is thin, unlike under vmfs, a thin hard residing on a NFS volume consumes all of the blocks required by its size declared. FOR EXAMPLE we have a VM said thin with a size of 80 GB, which uses 59,47 Go on a vmfs volume, but when saved on a store NFS, there are 80 GB of disk space each time. On a 250 GB NFS volume, so there room for not more than 3 backups.

3. the only way to effectively store backups on a volume of NFS is whether this volume supports compression. The only solid choices in this area seem to be NTFS and ZFS. ZFS is to consume a lot of resources because of all the other things, it was designed to do. If I was going to ZFS, I would probably just add to an existing FreeBSD VM. I don't need all the stuff done FreeNAS. Windows through 2008 have problems with large files. I have not tried Windows 2012.

Question:
At this point, I think to try a Windows VM to 2012 to take the place of VM Windows 2003 to see if 2012 has beaten the problems of file size of volume. In 2012, virtualization was hot, and so I guess that he could not have the problem with large files. Everyone using one? NIX VM for this assignment which is effective, reliable and supports compression?

Thank you!

Forward:
I installed a Server Microsoft 2012 64 VM today to serve as the target of compressed backup NFS to determine if they have fixed the problem with large files which is rampant in the 2 K - 2008 R2 and learned by doing more tests and more.

2012 compressed Server NFS volume tests:

Backup on compressed NTFS volume projected as NFS
* The VM has here a test size declared 80 GB. The NFS VHD said to 150 GB

-vmkfstools-i d dstop.vmdk thin /vmfs/volumes/nas-4/backups/server1/dstop/1/dstop.vmdk

-When you have finished, stat reports he uses 40.23 GB

-VCLI engages with the Go 40,23 and shows that I have 109,53 GB remaining in free space

-Windows shows Go 40.2 used on the disk and 109 GB free

Second backup
-Size of the vhd is 80 GB, so there should be more than enough space to make a second backup if vmkfstools considers that the first backup is 40.2 GB and not his declared 80 GB size.

-vmkfstools-i d dstop.vmdk thin /vmfs/volumes/nas-4/backups/server1/dstop/2/dstop.vmdk

-When you have finished, stat says it requires 40.23 GB

-VCLI agrees with the 80.66 and shows that I have 69,21 GB remaining in free space

-Windows shows also 80.4 GB used on the disk and 69.2 GB free

-Because the backup is complete, it turned vmkfstools saw all the remaining space on the compressed volume. If such were not the case, there is not room for the second copy as we would have been short 10 GB. (80 GB * 2 = 160 GB on a 150 GB NFS volume)

-Doing a stat on virtual hard drive storage shows its size to be 121,93 GB, not the expected 40,23 GB X 2 = 80.46 GB. Which indicates that, during the thin vhd for volume cloning compressed NFS, the VHD used initially full value declared of the 80 GB (40.23 + 80 GB + ~1.5GB) vhd.

Third backup

-From the second backup, we learned that cloning for the volume compressed all of the 80 GB declared value plus a few initially used NFS. After the second copy, we have only 69GB of free space, the third backup to fail if our hypothesis is that a compressed volume Windows initially requires at least the size of the free space to successfully carry out the correct copy. The 69GB remaining should be too small for the initial 80 GB size required.

-vmkfstools-i d dstop.vmdk thin /vmfs/volumes/nas-4/backups/server1/dstop/3/dstop.vmdk

-Command instantly failed with the following error message:

«Impossible to clone the drive: there is not enough space on the file system for the selected operation (13).»

Tests of corruption:

GUI test
-Windows scanned the disc and found no errors

-Then, I did a stat on the VHD and seen that it has not changed because of the analysis.

CHKDSK command prompt:

-Then, I ran v: chkdsk /R from the command prompt and restart. It took a long time to complete because it checks the sectors and trying to recover and re-map information. I thought that it would increase the hard. He did not. This seems to indicate that vSphere extend and access the unused space of the disc even for chkdsk/r.

Recover the thin space experience:

-Deleted the first backup and subsequently checked with stat. The size of the vhd has not changed of the original 121,93 Go as planned.

-Downloaded and run sdelete on the volume. (Documentation, it is said, run it with? nix dd if = / dev/zero of = / [PATH] / zero bs = 4096 & rm f / [PATH] / zeros (I don't understand nor have I tried this command to see if it is correct or even work.))

-Check the VHD with stat, and as expected, it now has the declared size of 150 GB

-Ran vmkfstools - punchzero nas - 2_1.vmdk who went much faster than sdelete

-Run stats on it. I expect to be the same size, and I have to do a-i thin d vmkfstools to reach the smaller hard, but it was only 42 GB down 150 GB. I got all but 2 GB back. Curiously, the free space is exactly the same as before, 109 GB.

-Decided to try to start the virtual machine, without cloning the hard to see if it would work. It worked perfectly. These two steps are the steps only recover space on a thin hard.

-When he was in disbelief that it was that easy, I decided to do the-i thin d vmkfstools to see what would happen. It worked well, and it is still thin and still the same size.

Analysis:
-When you clone one - thin vhd to an NFS volume, it will use the declared size in disk space, not the - thin space as seen with vmfs volumes.
-When you clone a volume compressed Windows, it uses initially declared the virtual hard disk size in space before it is compressed.
-2012 server do not have problems with large files than 2008 R2 and earlier. I do not buy, but the price is mitigated when you consider that you get two licenses VM for that price.
-Recovering a previously too inflated thin virtual hard drive space is a simple two-step process. (At least with Windows that is)

Closed:

The issue of corruption with versions of Windows server before 2012 and the mystery of why backups were not complete when there was apparently a lot of disk space, has been something that has plagued me for a long time. Person here and other forums have been able to help. I hope that my tests have clarified the issues, so that others can enjoy.

Tags: VMware

Questions and answers backing up/cloning a VM NFS

Similar Questions

Maybe you are looking for