We are not doing it that way because when new VMs are created, the maintainer
of the schedule or script has to first learn there is a new VM and second
update the schedule/script. We use VMHOST=hostmachine to automatically back up
all VMs on a host. Actucal we use a -NB suffix on VM names that we do not want
to back up and a -vm=*-NB to exclude those.
Schedule parameters like you listed in your email are like the ones the VME GUI
will generate if you ask it to build a schedule.
David Ehresman
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Schneider, Jim
Sent: Friday, August 29, 2014 10:52 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] tsm for ve DR config question
I've seen the complex backup commands people are using to schedule backups.
A previous email showed command
-vmfulltype=vstor -vmbackuptype=fullvm -asnodename=<nodename
that owns the backupdata> -domain.vmfull="VM=<list with virtual machines, comma
separated>" -MODE=IFIncremental
My current method is to create a .bat file and execute it as a scheduled
command script.
The script CDs to the baclient directory and executes:
dsmc backup vm server1,server2,server3,etc.
The filespace name for the backup is \VMFULL-servername
The activity log message generated is:
08/28/14 20:00:22 ANE4172I (Session: 206882, Node: SCSWPBKPXY_DM)
Starting
Full VM backup of VMware Virtual Machine 'MSNLRSOLR2'
mode: 'Incremental
Forever -
Incremental' target node name:
'SCSWPBKPXY_DM' data mover node name:
'SCSWPBKPXY_DM' application protection type:
'VMware'
application(s) protected: 'n/a'
(SESSION:
206882)
It's a really easy way to back up VMs.
Is anybody else doing this?
Jim Schneider
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Matthew McGeary
Sent: Friday, August 29, 2014 9:33 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] tsm for ve DR config question
We typically see VM restore speeds at 2/3 or 1/2 the rate of standard
file-level incremental restores. That's from a FILE devclass with a 50GB
volume size. We're still offsiting to tape, however, so we do monthly fulls of
the production VMs so we have a relatively recent full copy for DR purposes.
Between the fulls and restoring the VM metadata back to a disk storage pool
before restoring VM's, we should see decent speed.
That said, we haven't done a test with the new backup strategy yet. So I could
be wrong.
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/29/2014 07:16 AM
Subject: Re: [ADSM-L] tsm for ve DR config question
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
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.
|
