>>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
>
>
|