I'll throw out a local variation that still persists: Running the OS maker's system state backup tool to produce a flat file picked up by the nightly incremental. In some cases this is implemented as a postsched script.
A considerable amount of time has elapsed between Windows 2008 R2 going into use and TSM supporting a reliably working system state backup method? I think some clients are already configured to use wbadmin for this purpose? [RC] From: Steven Harris <[email protected]> To: [email protected] Date: 07/27/2010 10:08 PM Subject: Re: [ADSM-L] VCB backups and systemstate Sent by: "ADSM: Dist Stor Manager" <[email protected]> Comprehensive Wanda! Thanks for taking the time 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. Even images might have uncommitted registry changes, or doesn't the registry work that way? Sorry, I'm a unix guy 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? Appreciatively Steve. TSM Admin 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 > > U.S. BANCORP made the following annotations --------------------------------------------------------------------- Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. ---------------------------------------------------------------------
