ADSM-L

Re: [ADSM-L] VCB backups and systemstate

2010-07-29 10:46:40
Subject: Re: [ADSM-L] VCB backups and systemstate
From: "Prather, Wanda" <wPrather AT ICFI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 29 Jul 2010 14:44:11 +0000
>>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:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of Steven Harris
> Sent: Tuesday, July 27, 2010 7:56 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> 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
>
>

<Prev in Thread] Current Thread [Next in Thread>