>>But, aren't there some things that can't be backed up consistently any other >>way? The one that springs to mind is Active Directory, if you have a virtual AD server but I'm sure there must be others.
Ooo, did NOT know that about AD! Thanks for the info. >>Even images might have uncommitted registry changes, or doesn't the registry >>workthat way? Sorry, I'm a unix guy Can't answer anything about how the registry works. I do know that other data bases are an issue (and I hope somebody else with more definitive info will chime in here). I think you have to talk to your backup provider about your particular data base. For example, I talked with a VEEAM SE, they say that products that are VSS-enabled (if that is the proper term) are captured properly when VEEAM does its image backup - that would include MSSQL and Exchange, but not Oracle. My customers are still doing TDP backups of MSSQL and Exchange, which I think is appropriate, because you want the ability to do a point-in-time restore by playing with the logs. >>Also, re bare metal restore differences, doesn't that go away in a virtual >>environment since every machine is running on the same emulated hardware? Yes, if you're talking about moving a whole .vmdk file. Wanda Prather, Wanda wrote: > I'm glad you brought that up. I asked a lot of people that question, > discussed it at our local user group, and we've done some testing. Other > people may have different opinions, as the entire VMWare world is a very > quickly evolving moving target, so I'd be glad of some discussion here. > > First, VCB is going away. It's available in VMWARE 3.x, and 4.0, but will be > gone by VMWARE 4.1 (or 4.2, sorry don't remember which one), which is > supposed to be out THIS year. VMWare starting at 4.0 provides the VStorage > API, which TSM 6.2 uses, so do all the 3rd party VMWare backup products. So > I assume you just mean "in a VMWARE environment". > > There are 3 ways to back up VM's right now (in this context, meaning Virtual > Windows machines running under a version of VMWARE). > > A) you can put a TSM client on the VM and run it like you would on a physical > machine. > > In this case, the TSM client doesn't know it's on a VM. Systemstate is > backed up by default. (You can always turn it off). > This is typically how folks have dealt with test and dev non-critical VM's. > It's easy and doesn't require any retraining for folks. > > I didn't know whether you actually COULD restore systemstate to a running VM, > but we had a customer who needed to do it (because of a failure with their > other VMWare backup software), so they did it. It does work, although as I > recall there was some slight registry tweak that was required afterwards. > It's not something you would normally do (read on). > > B) You can use a 3rd party tool or the TSM client (and a proxy server) to run > file-level backups of a VM > > The way this works is by mounting the image of the virtual drives of the > client to the "proxy" machine across the SAN, and backing them up with the > TSM client (very similar to what happens if you use the TSM client to backup > a network share that resides on another machine). So you only get a backup > of the drives, you don't get a backup of systemstate. > > My customers haven't found this to be very useful yet; it's difficult and > time-consuming to set up at the TSM 6.1 level; haven't worked with the 6.2 > client improvements yet. The benefits of proxy backup is to offload the work > from the VM, but TSM incremental-forever backups aren't usually that > resource-consuming anyway. VDR (the backup tool built into VSphere4 > Enterprise) does file-level backups and dedups them to a disk repository, > which I think is where most of the 3rd party VM products are headed. Again > you don't get a backup of systemstate. (You don't need it, read on.) > > C) You use the TSM VCB client, the TSM 6.2.x client that comes out later > this year, or a 3rd party product to do VM image-level backups. (You can > also just use VMWare to just snap copies of a virtual machine to disk, > without ever moving those copies to your backup media.) There is no separate > backup of systemstate, but it's part of the image. > > This is what customers with VM's of production machines really want and need. > An image-level backup of a VM is essentially a copy of the .vmdk file > containing the VM. It's a wonderful thing to have because it's hardware > independent. Instead of having to go to a DR site and rebuild your Windows > boxen with bare-metal restore and deal with the unlike-hardware issues, you > just take that .vmdk file and plop it onto another ESX server. No more > dealing with unlike hardware. > > A lot of VM admins routinely do snaps to disk of the VM's, say before they do > a software upgrade on a VM. If you have a problem, instead of having to > restore the machine, you just reload the VM. The reload is not instantaneous > by any means, but it's a lot faster than a restore. > If you lose a production VM, the appropriate thing to do (in my opinion) is > to restore from the last vm image backup, and roll files forward from the > incrementals. Much faster and more likely to succeed than a bare-metal > Windows restore. > > > Open questions: > > Third-party image level backups are the way to go, IMHO, at least until we > get a look at the TSM image backup projected for the 4Q TSM 6.2.x client. > > OTOH, third-party VM only file-level backup tools seem to fit in some > environments and not in others. If you do your file-level backups with a > client-less VMWare tool, it pushes all the file-level restores back on the > VMWare administrator. In environments where system owners are accustomed to > doing their own restores as needed, it doesn't seem to fit too well. As a > result I have customers that are keeping the TSM client running for file > level backups, and using a VM specific product for image backups, for now, > knowing that strategy may change in the future. > > Back to System State: > > 1) If your only backup of the VM is with the TSM baclient, then for sure you > need systemstate backups. > 2) If you have VM image backups, and you totally lose the VM, you can reload > the image and roll forward from your incrementals (TSM or other). > Systemstate comes back with the image, you don't need a separate backup of > systemstate. > > SO that leaves the question, if you are doing file-level backups with TSM, > and also have VM image backups, is there ever a case where you would need to > restore systemstate from TSM? > > The only case I've been able to think of, is if you just want to do a quick > registry restore. Used to see frequent cases of that with WinNT and Win2K, > but I don't think I've ever seen anybody need to do that since Win2K3. > > So I'm telling my customers that have both VM image backups, and are still > doing file-level backups with TSM, to exclude systemstate. Greatly reduces > the traffic in the TSM DB, and eliminates all those pesky Windows backup > failures due to VSS errors. > > (Ooh, I hope this generates a LOT of commentary...) > > W > > > > > > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of > Steven Harris > Sent: Tuesday, July 27, 2010 7:56 PM > To: [email protected] > Subject: [ADSM-L] VCB backups and systemstate > > One more from me and then I'll shut up :) > > For years we've been backing up windows systemstate, and until recent > times this was a full backup of the whole schmiel every night, but we > were told this is desparately important and must be done. > > How is systemstate backup handled in the VCB environment? I haven't > been able to find anything about this in IBM docs > > > Regards > > Steve. > > TSM Admin > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.851 / Virus Database: 271.1.1/3032 - Release Date: 07/28/10 > 06:34:00 > >
