-
- Novice
- Posts: 7
- Liked: never
- Joined: Jan 14, 2010 2:47 pm
- Full Name: michael mun
- Contact:
restore image question
What is the best way to restore an image from a backup? Should I shut down the existing, running VM first?
-
- Novice
- Posts: 7
- Liked: never
- Joined: Jan 14, 2010 2:47 pm
- Full Name: michael mun
- Contact:
Re: restore image question
I overwrote the existing vm. However, when i powered on the restored vm, I was surprised to see that it started up in a crash consistent state even though I checked "Enable VMware tools quiescence" under Backup options in the advanced backup settings.
-
- VP, Product Management
- Posts: 6035
- Liked: 2860 times
- Joined: Jun 05, 2009 12:57 pm
- Full Name: Tom Sightler
- Contact:
Re: restore image question
If your restoring the entire VM over the existing VM, well, then it probably doesn't matter, I think Veeam will power off the VM for you prior to removing it.
However, I've found that I prefer to restore the VMDK file rather that restoring the entire VM. Why? Well, when you restore the entire VM the old VM is deleted and the restored VM is recreated as a new VM, generally in the root folder, with a new UID. This means that if you backup by folders you'll need to move the VM back into the folder in vCenter, or, if you backup by selecting specific VM's, you'll need to modify your jobs to remove the "old" VM and include the "new" VM even though they are the same. Even more annoying, until you run a new full backup, there will forever be a final "shadow" of the old restored VM in the VBK file. Might not be much of an issue if you use small jobs or one job per VM, however, with jobs with many VM's, it eventually gets to be quite annoying.
Powering off the VM and restoring the VMDK avoids all of these problems, since the VM is not deleted it won't move in vCenter so you Veeam job will continue to backup that VM normally.
To summarize, here's the use cases that we came up with at my employer and our preferred restore method for those cases (YMMV):
1. VM already deleted, being restored to same VM name -- Restore entire VM
2. VM being restored to a new VM name -- Restore entire VM
3. VM still exist, but needs to be restored to previous state -- Restore VMDK files to existing VM
4. VM still exist, but some files damaged or deleted -- Restore via FLR
However, I've found that I prefer to restore the VMDK file rather that restoring the entire VM. Why? Well, when you restore the entire VM the old VM is deleted and the restored VM is recreated as a new VM, generally in the root folder, with a new UID. This means that if you backup by folders you'll need to move the VM back into the folder in vCenter, or, if you backup by selecting specific VM's, you'll need to modify your jobs to remove the "old" VM and include the "new" VM even though they are the same. Even more annoying, until you run a new full backup, there will forever be a final "shadow" of the old restored VM in the VBK file. Might not be much of an issue if you use small jobs or one job per VM, however, with jobs with many VM's, it eventually gets to be quite annoying.
Powering off the VM and restoring the VMDK avoids all of these problems, since the VM is not deleted it won't move in vCenter so you Veeam job will continue to backup that VM normally.
To summarize, here's the use cases that we came up with at my employer and our preferred restore method for those cases (YMMV):
1. VM already deleted, being restored to same VM name -- Restore entire VM
2. VM being restored to a new VM name -- Restore entire VM
3. VM still exist, but needs to be restored to previous state -- Restore VMDK files to existing VM
4. VM still exist, but some files damaged or deleted -- Restore via FLR
-
- Chief Product Officer
- Posts: 31807
- Liked: 7300 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: restore image question
Message about "improper OS shutdown" does not mean that VM is in the "crash consistent state". Because backups are "hot", it is to be expected that the OS flag monitoring complete OS shutdown remains up during hot backup (as shutdown never happens), and is reported on the next startup. This Windows functionality simply was not designed with hot image-level backups in mind.mmun wrote: was surprised to see that it started up in a crash consistent state
Actual OS state however will not be crash consistent if you use Veeam VSS, because before creating snapshot, our agent will notify all OS components that the backup is being taken, and they will finish all on-going transactions and suspend all activities.
Try running this line below in the command prompt. Clean Windows 7 install by itself has 10 out of box VSS writers, for all critical system services like registry, file system etc. All of these components are being properly quiesced, so your OS is not really "crash consistent".
Code: Select all
vssadmin list writers
-
- VP, Product Management
- Posts: 6035
- Liked: 2860 times
- Joined: Jun 05, 2009 12:57 pm
- Full Name: Tom Sightler
- Contact:
Re: restore image question
Enable VMware tools quiescence really justs looks for a quiet period and "stuns" the machine to prevent I/O during the snapshot. It's will still be a "crash consistent" backup. You should really consider using Veeam VSS instead of VMware tools quiescence if possible.
Who is online
Users browsing this forum: Bing [Bot], Google [Bot], Majestic-12 [Bot] and 309 guests