I am using the VMFOLDER option, using one folder per datamover and so
dividing the backups across multiple VM datamovers. Only disadvantage is
that the TDP for VE GUI does not understand that option and is unable to
manage the schedules. Just by putting the VM in the folder and it is being
backed up, no matter on what host it is. You can also create different
folders with a different backup schedules attached, i.e. Backup once a week
for static VMs.
IMHO the best flexible way to do it.
Op vrijdag 29 augustus 2014 heeft David Ehresman <
david.ehresman AT louisville DOT edu> het volgende geschreven:
> 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
> <javascript:;>]
> On Behalf Of Schneider, Jim
> Sent: Friday, August 29, 2014 10:52 AM
> To: ADSM-L AT VM.MARIST DOT EDU <javascript:;>
> 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
> <javascript:;>]
> On Behalf Of Matthew McGeary
> Sent: Friday, August 29, 2014 9:33 AM
> To: ADSM-L AT VM.MARIST DOT EDU <javascript:;>
> 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 <javascript:;>>
> To: ADSM-L AT VM.MARIST DOT EDU <javascript:;>
> 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
> <javascript:;>>
>
>
>
> 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
> <javascript:;>]
> On Behalf Of David Ehresman
> Sent: Friday, August 29, 2014 7:51 AM
> To: ADSM-L AT VM.MARIST DOT EDU <javascript:;>
> 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
> <javascript:;>]
> On Behalf Of Schneider, Jim
> Sent: Thursday, August 28, 2014 4:20 PM
> To: ADSM-L AT VM.MARIST DOT EDU <javascript:;>
> 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
> <javascript:;>]
> On Behalf Of Stefan Folkerts
> Sent: Thursday, August 28, 2014 12:14 PM
> To: ADSM-L AT VM.MARIST DOT EDU <javascript:;>
> 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 <javascript:;>> 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 <javascript:;>>
> > To: ADSM-L AT VM.MARIST DOT EDU <javascript:;>
> > 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
> <javascript:;>>
> >
> >
> >
> > 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.
>
--
Kind Regards, Groetje,
Marcel Anthonijsz
T: +31(0)299-776768
M:+31(0)6-53421341
|
