If you are running Active Directory (a domain controller) in a VM and you want
to backup AD you have two options:
1. System state
2. Turn off the VM and backup the entire set of VMDK files etc that
comprise that VM.
Neither Microsoft nor VMware support snapshot backups (VCBs) of a running
Active Directory VM.
I should mention, however, that without a system state backup it is impossible
to perform an authoritative restore of your Active Directory. So, I would
*strongly* recommend a system state backup of your Active Directory server.
And, if your DNS is Active Directory integrated, I'd recommend exporting your
DNS configuration, zones, etc. to files and backing that up too.
Ray
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Prather, Wanda
Sent: Wednesday, July 28, 2010 12:46 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] VCB backups and systemstate
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
CONFIDENTIALITY NOTICE: This email and any attachments are for the
exclusive and confidential use of the intended recipient. If you are not
the intended recipient, please do not read, distribute or take action in
reliance upon this message. If you have received this in error, please
notify us immediately by return email and promptly delete this message
and its attachments from your computer system. We do not waive
attorney-client or work product privilege by the transmission of this
message.
|
