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 <steve AT STEVENHARRIS DOT INFO>
To:
ADSM-L AT VM.MARIST DOT EDU
Date:
07/27/2010 10:08 PM
Subject:
Re: [ADSM-L] VCB backups and systemstate
Sent by:
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
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: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
>
>
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.
---------------------------------------------------------------------
|
