ADSM-L

Re: [ADSM-L] tsm for ve DR config question

2014-08-29 09:17:48
Subject: Re: [ADSM-L] tsm for ve DR config question
From: "Schneider, Jim" <jschneider AT USSCO DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 29 Aug 2014 13:15:42 +0000
David,

I'm still using the defaults.  I've seen occasional spikes in backup duration 
and had not considered that it might be caused by a megablock being backed up 
again.  Most of our backups run in about 10 minutes, but occasionally take 1.5 
hours.

The only way I've found to get a list of backed-up VMs is query occupancy for 
the data mover node, and parsing the file space name.  Has anybody found a 
better way?

Jim Schneider


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
David Ehresman
Sent: Friday, August 29, 2014 7:51 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] tsm for ve DR config question

Jim,

Are you using the default of 50 for mbobjrefreshthresh or have you adjusted 
that value?  If so, how did you determine what to change it to?

David Ehresman-

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Schneider, Jim
Sent: Thursday, August 28, 2014 4:20 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] tsm for ve DR config question

I back up both the VM and CNTL data to separate file device storage pools on a 
Data Domain.  I restore from a snapshot of replicated data.

I was under the impression that the mbobjrefreshthresh parameter triggered 
additional (megablock) backups and substituted for periodic fulls.  It's my 
fervent hope that recoverin from file-based storage will not be slower than 
standard incremental restore.

Jim

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Stefan Folkerts
Sent: Thursday, August 28, 2014 12:14 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] tsm for ve DR config question

>The documentation isn't kidding around when it recommends that a 
>periodic
full
strategy is best for tape copypools.

This and make sure you restore your VE metadata to disk first, this only works 
if you place this metadata in a seperate copypool.



On Thu, Aug 28, 2014 at 5:35 PM, Matthew McGeary < Matthew.McGeary AT 
potashcorp DOT com> wrote:

> TSM for VE will connect to any VCenter server you specify.  When we 
> did our test, the VMWare team built a new VCenter instance and I built 
> a new datamover, connected it to the fresh VCenter and started restoring VMs.
>
> A word of caution, however, if your data is on tape and you don't have 
> any fulls to restore you should be prepared to wait a very long time.
> We were doing IFincr backups and saw restore speeds in the KB/s.  The 
> documentation isn't kidding around when it recommends that a periodic 
> full strategy is best for tape copypools.
>
> Matthew McGeary
> Technical Specialist
> PotashCorp - Saskatoon
> 306.933.8921
>
>
>
> From:   "Schneider, Jim" <jschneider AT USSCO DOT COM>
> To:     ADSM-L AT VM.MARIST DOT EDU
> Date:   08/27/2014 11:51 AM
> Subject:        [ADSM-L] tsm for ve DR config question
> Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
>
>
> Hi, folks;
>
> I have an upcoming disaster recovery test and will be asked to restore 
> VE data for the first time.  I can't run tests because the 
> hardware/network is not in place.  Will the DR VE backup proxy server 
> have to connect to a duplicate of the current production vCenter 
> server, or just A vCenter server on the correct network?
>
> Are there any other quirks recovering VE during a DR?
>
> Thanks in advance,
> Jim Schneider
> United Stationers
>
> **********************************************************************
> Information contained in this e-mail message and in any attachments 
> thereto is confidential. If you are not the intended recipient, please 
> destroy this message, delete any copies held on your systems, notify 
> the sender immediately, and refrain from using or disclosing all or 
> any part of its content to any other person.
>

**********************************************************************
Information contained in this e-mail message and in any attachments thereto is 
confidential. If you are not the intended recipient, please destroy this 
message, delete any copies held on your systems, notify the sender immediately, 
and refrain from using or disclosing all or any part of its content to any 
other person.