Welcome! » Log In » Create A New Profile

Influencing order of VM backup.

Posted by Harris, Steven 
Harris, Steven
Influencing order of VM backup.
February 08, 2018 07:59PM
Hi All

Thanks for the input on my recent query about 7 Year VM backups. I'll let you know when I decide something.

Moving on..

TSM Server 7.1.1.300 AIX, Datamovers and Storage Agents on Redhat, writing to Protectier VTL, TSM for VE 7.1.1/2 hybrid.

We can't use the VMware plugin because of separation of duties concerns, so we edit the DOMAIN.VMFULL lines in the dsm.sys stanzas. VMs have a range of different sizes that all back up on the same schedule and we'd prefer not to split this up. The execution order of the VM backups is determined by TSM for VE, somehow, and can be seen when a backup vm -preview is run.

There are some large VMs that take quite a while to back up, but unfortunately run late in the execution order, so we overrun our backup window.

Changing the order of the VMs in the DOMAIN.VMFULL statement does not influence execution order. Is there any way to make the big ones run first?

Thanks

Steve

Steven Harris
TSM Admin/Consultant
Canberra Australia


This message and any attachment is confidential and may be privileged or otherwise protected from disclosure. You should immediately delete the message if you are not the intended recipient. If you have received this email by mistake please delete it from your system; you should not copy the message or disclose its content to anyone.

This electronic communication may contain general financial product advice but should not be relied upon or construed as a recommendation of any financial product. The information has been prepared without taking into account your objectives, financial situation or needs. You should consider the Product Disclosure Statement relating to the financial product and consult your financial adviser before making a decision about whether to acquire, hold or dispose of a financial product.

For further details on the financial product please go to http://www.bt.com.au

Past performance is not a reliable indicator of future performance.
This message was imported via the External PhorumMail Module
Marc Lanteigne
Re: Influencing order of VM backup.
February 09, 2018 03:59AM
Hi,

You could configure a new DataMover to handle that VM.

In the preview, is the order alphabetical? If so, can you rename the VM?

Marc...

Sent from my iPhone using IBM Verse

On Feb 8, 2018, 11:17:20 PM, steven.harris@BTFINANCIALGROUP.COM wrote:

From: steven.harris@BTFINANCIALGROUP.COM
To: ADSM-L@VM.MARIST.EDU
Cc:
Date: Feb 8, 2018, 11:17:20 PM
Subject: [ADSM-L] Influencing order of VM backup.


Hi All
Thanks for the input on my recent query about 7 Year VM backups. I'll let you know when I decide something.
Moving on..
TSM Server 7.1.1.300 AIX, Datamovers and Storage Agents on Redhat, writing to Protectier VTL, TSM for VE 7.1.1/2 hybrid.
We can't use the VMware plugin because of separation of duties concerns, so we edit the DOMAIN.VMFULL lines in the dsm.sys stanzas. VMs have a range of different sizes that all back up on the same schedule and we'd prefer not to split this up. The execution order of the VM backups is determined by TSM for VE, somehow, and can be seen when a backup vm -preview is run.
There are some large VMs that take quite a while to back up, but unfortunately run late in the execution order, so we overrun our backup window.
Changing the order of the VMs in the DOMAIN.VMFULL statement does not influence execution order. Is there any way to make the big ones run first?
Thanks
Steve
Steven Harris
TSM Admin/Consultant
Canberra Australia
This message and any attachment is confidential and may be privileged or otherwise protected from disclosure. You should immediately delete the message if you are not the intended recipient. If you have received this email by mistake please delete it from your system; you should not copy the message or disclose its content to anyone.
This electronic communication may contain general financial product advice but should not be relied upon or construed as a recommendation of any financial product. The information has been prepared without taking into account your objectives, financial situation or needs. You should consider the Product Disclosure Statement relating to the financial product and consult your financial adviser before making a decision about whether to acquire, hold or dispose of a financial product..
For further details on the financial product please go to https://urldefense.proofpoint.com/v2/url?u=http-3A__www.bt.com.au&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=hMBqtRSV0jXgOdXEmlNk_-O9LHkPCGSh9PJBRSlL8Q4&m=DP7DwxCOv4YVWwNQ-mQuUUtEM6b1fb2rRkkXefrXlGA&s=aVJ5Y2IRgiGyROP9MaupUeZM6Y7X6bJW6eHIekbRugI&e=
Past performance is not a reliable indicator of future performance.
This message was imported via the External PhorumMail Module
Ryder, Michael S
Re: Influencing order of VM backup.
February 09, 2018 08:59AM
You can take more control by setting up specific schedules to backup some
VMs first. You might use VM folders to control that as well.

Do you let VMs backup in parallel with "VMMAXParallel" ? It defaults to
1...

You can also have multiple jobs running simultaneously. It's not clear to
me, are you using the "IBM Spectrum Protect for Virtual Environments: Data
Protection for VMware"? If so, in addition you could be running multiple
jobs on multiple datamovers simultaneously.

Enabling #>1 on VMMAXParallel and multiple datamovers helped us to
drastically reduce our backup windows.

Best regards,

Mike

On Fri, Feb 9, 2018 at 6:08 AM, Marc Lanteigne <marclanteigne@ca.ibm.com>
wrote:

> Hi,
>
> You could configure a new DataMover to handle that VM.
>
> In the preview, is the order alphabetical? If so, can you rename the VM?
>
> Marc...
>
> Sent from my iPhone using IBM Verse
>
> On Feb 8, 2018, 11:17:20 PM, steven.harris@BTFINANCIALGROUP.COM wrote:
>
> From: steven.harris@BTFINANCIALGROUP.COM
> To: ADSM-L@VM.MARIST.EDU
> Cc:
> Date: Feb 8, 2018, 11:17:20 PM
> Subject: [ADSM-L] Influencing order of VM backup.
>
>
> Hi All
> Thanks for the input on my recent query about 7 Year VM backups. I'll
> let you know when I decide something.
> Moving on..
> TSM Server 7.1.1.300 AIX, Datamovers and Storage Agents on Redhat,
> writing to Protectier VTL, TSM for VE 7.1.1/2 hybrid.
> We can't use the VMware plugin because of separation of duties concerns,
> so we edit the DOMAIN.VMFULL lines in the dsm.sys stanzas. VMs have a range
> of different sizes that all back up on the same schedule and we'd prefer
> not to split this up. The execution order of the VM backups is determined
> by TSM for VE, somehow, and can be seen when a backup vm -preview is run.
> There are some large VMs that take quite a while to back up, but
> unfortunately run late in the execution order, so we overrun our backup
> window.
> Changing the order of the VMs in the DOMAIN.VMFULL statement does not
> influence execution order. Is there any way to make the big ones run first?
> Thanks
> Steve
> Steven Harris
> TSM Admin/Consultant
> Canberra Australia
> This message and any attachment is confidential and may be privileged or
> otherwise protected from disclosure. You should immediately delete the
> message if you are not the intended recipient. If you have received this
> email by mistake please delete it from your system; you should not copy the
> message or disclose its content to anyone.
> This electronic communication may contain general financial product
> advice but should not be relied upon or construed as a recommendation of
> any financial product. The information has been prepared without taking
> into account your objectives, financial situation or needs. You should
> consider the Product Disclosure Statement relating to the financial product
> and consult your financial adviser before making a decision about whether
> to acquire, hold or dispose of a financial product.
> For further details on the financial product please go to
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.bt.
> com.au&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=hMBqtRSV0jXgOdXEmlNk_-
> O9LHkPCGSh9PJBRSlL8Q4&m=DP7DwxCOv4YVWwNQ-mQuUUtEM6b1fb2rRkkXefrXlGA&s=
> aVJ5Y2IRgiGyROP9MaupUeZM6Y7X6bJW6eHIekbRugI&e=
> Past performance is not a reliable indicator of future performance.
>
>
This message was imported via the External PhorumMail Module
Harris, Steven
Re: Influencing order of VM backup.
February 10, 2018 08:59PM
Hi Mike and Marc

Thanks for your responses.

Order of presentation of VMs seems to be dependent on the order that vCenter provides them to the TSM for VE query. It is certainly not alphabetical or any other obvious ordering (to me at least) and it can change over time. One problem VM was starting at the beginning of the schedule and suddenly moved to late in the order with no changes that we could see.

We are running multiple data movers based on class of VM. There are two separate vCenters and each of those have prod and non-prod backup streams organized by VMWare cluster with a datamover for each. Leaving out unnecessary detail, there is one VBS server for each vCenter/stream and one datamover on each VBS with its own storage agent. Data transport is SAN. All this is controlled through a single TSM Server.

VMMAXSESSIONS is set to 10 in prod... we have been experimenting in non-prod with making this higher, but so far have found that more allowed sessions does not necessarily mean more active sessions: the most we have had in non-prod was 16 active when VMAXSESSIONS was 20, and then only briefly. More sessions also seem to push out the elapsed time: 10 to 20 pushed out the end of backup from 8 to 10 hours.

For non-prod we have therefore now settled at 12 sessions and have started to play with VMLIMITPERDATASTORE and VMLIMITPERHOST which have both been 2 until now.

Yes we have considered multiple datamovers and schedules. As we control things by editing dsm.sys that gets messy very quickly. The level of TSM for VE code we are on means that the automatic exclusion of PRDMs, VMDKs>2TB etc does not work so we have to exclude these individually.

I am really tempted to, but the effort to script an automatic generation process for the dsm.sys stanzas is probably not warranted. There are also issues with having to generate using powershell on Windows and then updating control files on Linux and security implications in our environment or having to teach myself python for this one task (and getting python3 installed and the prereqs for the VMware API etc etc etc).

Looks like I may be stuck until we can at least get a code upgrade. The Spectre/Meltdown security issue will likely force a VMWare upgrade, at which point we can move off our current TSM for VE level and some of the pain will go away, however if anyone has more information on how the TSM for VE VM selection algorithm works and how it can be influenced, I'd be interested to hear it.

Cheers

Steve

Steven Harris
TSM Admin/Consultant
Canberra Australia

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Ryder, Michael S
Sent: Saturday, 10 February 2018 3:07 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Influencing order of VM backup.

You can take more control by setting up specific schedules to backup some VMs first. You might use VM folders to control that as well.

Do you let VMs backup in parallel with "VMMAXParallel" ? It defaults to 1...

You can also have multiple jobs running simultaneously. It's not clear to me, are you using the "IBM Spectrum Protect for Virtual Environments: Data Protection for VMware"? If so, in addition you could be running multiple jobs on multiple datamovers simultaneously.

Enabling #>1 on VMMAXParallel and multiple datamovers helped us to drastically reduce our backup windows.

Best regards,

Mike

On Fri, Feb 9, 2018 at 6:08 AM, Marc Lanteigne <marclanteigne@ca.ibm.com>
wrote:

> Hi,
>
> You could configure a new DataMover to handle that VM.
>
> In the preview, is the order alphabetical? If so, can you rename the VM?
>
> Marc...
>
> Sent from my iPhone using IBM Verse
>
> On Feb 8, 2018, 11:17:20 PM, steven.harris@BTFINANCIALGROUP.COM wrote:
>
> From: steven.harris@BTFINANCIALGROUP.COM
> To: ADSM-L@VM.MARIST.EDU
> Cc:
> Date: Feb 8, 2018, 11:17:20 PM
> Subject: [ADSM-L] Influencing order of VM backup.
>
>
> Hi All
> Thanks for the input on my recent query about 7 Year VM backups.
> I'll let you know when I decide something.
> Moving on..
> TSM Server 7.1.1.300 AIX, Datamovers and Storage Agents on Redhat,
> writing to Protectier VTL, TSM for VE 7.1.1/2 hybrid.
> We can't use the VMware plugin because of separation of duties
> concerns, so we edit the DOMAIN.VMFULL lines in the dsm.sys stanzas.
> VMs have a range of different sizes that all back up on the same
> schedule and we'd prefer not to split this up. The execution order of
> the VM backups is determined by TSM for VE, somehow, and can be seen when a backup vm -preview is run.
> There are some large VMs that take quite a while to back up, but
> unfortunately run late in the execution order, so we overrun our
> backup window.
> Changing the order of the VMs in the DOMAIN.VMFULL statement does
> not influence execution order. Is there any way to make the big ones run first?
> Thanks
> Steve
> Steven Harris
> TSM Admin/Consultant
> Canberra Australia


This message and any attachment is confidential and may be privileged or otherwise protected from disclosure. You should immediately delete the message if you are not the intended recipient. If you have received this email by mistake please delete it from your system; you should not copy the message or disclose its content to anyone.

This electronic communication may contain general financial product advice but should not be relied upon or construed as a recommendation of any financial product. The information has been prepared without taking into account your objectives, financial situation or needs. You should consider the Product Disclosure Statement relating to the financial product and consult your financial adviser before making a decision about whether to acquire, hold or dispose of a financial product.

For further details on the financial product please go to http://www.bt.com.au

Past performance is not a reliable indicator of future performance.
This message was imported via the External PhorumMail Module
Sorry, only registered users may post in this forum.

Click here to login