I was told as long as I kept the mode as IFINCR it would not reset CBT info
before I started, but it did. This was on TSM for VE 6.4, VMWare 5.1, and a
6.3.3 server. Perhaps there is another way that would work without resetting
CBT. If so, please share.
I did onetime IFINCR backups to a new datacenter nodename, new stgpool, using a
new datamover during the day for a proof of concept. Since the data went to a
new nodename it triggered a full backup. After switching back to their original
datamover and datacenter node as part of the regular nightly schedule - that
also triggered a full again for those VMs I was using for testing, with these
messages:
ANS9387W Incremental backup unsuccessful for virtual machine 'XXXXXXX'.
Performing Full backup instead.
ANS9384W Unable to get VMware Changed Block Tracking(CBT) data for virtual
machine 'XXXXXX'. Full VM backup continues, and includes both used and unused
areas of the disk.
_______________________________________
John Monahan
Professional Services Consultant
Logicalis, Inc.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Rob Edwards
Sent: Thursday, March 20, 2014 8:42 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: TSM for VE and "monthly fulls"
John,
In TSM 6.4 this behavior was changed so that we do not always reset the CBT on
full backups. This was done, in part, to allow out of band full backups to be
done to a different node / server without interrupting the incremental chain of
the primary backup.
Are you seeing this issue with 6.4?
-----------------------
Rob Edwards
TSM Development
email: rce AT us.ibm DOT com
tieline: 938.2784, external: 720.396.2784
From: John Monahan <John.Monahan AT US.LOGICALIS DOT COM>
To: ADSM-L AT vm.marist DOT edu,
Date: 03/20/2014 01:48 AM
Subject: Re: TSM for VE and "monthly fulls"
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT vm.marist DOT edu>
If you backup to a different nodename you will reset the CBT info. So you can
do that monthly full backup to the different nodename, but when you switch back
to the original, it will also require a full. So in essence you need to do 2
back to back fulls to get this done. I've been down this road.
_______________________________________
John Monahan
Professional Services Consultant
Logicalis, Inc.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Prather, Wanda
Sent: Monday, March 10, 2014 11:43 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: TSM for VE and "monthly fulls"
Would like to know if anyone has solved the conundrum of TSM VE and customers
who want "monthly fulls" in the vault for a year or more.
Now I know that's a bad idea, and it doesn't play well with TSM
incremental-forever. But still there are customers who insist, or have
managers with ill-thought-out pseudo-requirements for it, or parent firms who
insist on it. And I can work those issues with backupsets or exports or
nodename-monthly node owners or sometimes even archives for other types of data.
But I have not been able to do an export on deduped VE filespaces. It takes so
long and puts on so many locks it has to be cancelled.
So I'm pondering the idea of doing a true VM full, to a different datamover
with a different filespace owner. But I don't really like that idea either
because the full will have the snapshot outstanding for a long time, and the
scheduling will be tricky so we don't overlap the incremental snapshots.
SO, anybody else have insight into this particular can of worms?
Thanks
Wanda
**Please note new office phone:
Wanda Prather | Senior Technical Specialist | Wanda.Prather AT icfi DOT com<
mailto:Wanda.Prather AT icfi DOT com> | www.icfi.com<http://www.icfi.com> |
410-868-4872 (m) ICF International | 7125 Thomas Edison Dr., Suite 100,
Columbia, Md |443-718-4900 (o)
|
