Re: Monthly backups of VMs

2017-11-18 Thread Stefan Folkerts
Steven,

It's probably not the reply you are looking for but Spectrum Protect Plus
can do this, you can have multiple SLA's attached to a VM and have one SLA
do a backup every day and retain it for say a month and have another SLA
create a backup every year and retain it for 7 years.

With Spectrum Protect I don't think it's a problem to make multiple
incremental backups of a VM to different datacenter nodes, I've seen people
do incremental forever backups via VE and also use other solutions on the
same VM to do the exact same without issues during backup or restore.

I haven't implemented it myself but the way CBT works with change ID's on
blocks it shouldn't be a problem.
So you can just "hack" the datamovers, create extra .opt files, schedulers
and schedule these backups from the Spectrum Protect server directly (not
using the VE webgui).
So that should open up the solution to create two incremental forever
backups using VE, just be sure you don't use tape. ;-)

Regards,
   Stefan (the Dutch Steven I guess :-) )


On Fri, Nov 17, 2017 at 1:20 PM, Lee, Gary  wrote:

> I assume that the data stored in the SQL databases is the primary
> retention target.
> If that is the case, how about a flat file dump to a central storage, then
> use another client to scoop that up monthly.
> Use resourceutilization to give it several sessions, and back up to the
> VTL.
>
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
> Harris, Steven
> Sent: Thursday, November 16, 2017 5:43 PM
> To: ADSM-L@VM.MARIST.EDU
> Subject: Re: [ADSM-L] Monthly backups of VMs
>
> Thanks for the reply Richard
>
> Backupsets apply only to BA client data.  Theoretically exports are
> possible. I've had issues with backupsets in the past and even if it were
> not possible would be loath to go there again (e.g. backupset is
> essentially a restore so it would take a drive to start, but then not have
> priority to take another drive to write its data and fail, so I didn't get
> a good backupset and whatever was interrupted also failed).
>
> Management of exports is also less than ideal. And they are slow, hmmm,
> unless an active pool was used.
>
> The problem with mixing monthlies and dailies is that they both use the
> same-named snapshots and so if one is running and the other starts it
> causes the existing snapshot to be deleted and the running backup fails.
> If there were a way to alter the snapshot name for the monthlies, that
> might help, but afaik there is not.  Without that then we need to
> manipulate the domain.vmfull (or any alternatives) on a daily basis to
> exclude that day's monthlies from daily backups and include into that day's
> monthlies.  Not simple.
>
> Thanks for making me explain this.  Active pool and exports may be the way
> to go.  Define the export volumes explicitly with a name that identifies
> their contents, then back them up with the BA client.
>
> Cheers
>
> Steve
>
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
> Richard Cowen
> Sent: Friday, 17 November 2017 9:06 AM
> To: ADSM-L@VM.MARIST.EDU
> Subject: Re: [ADSM-L] Monthly backups of VMs
>
> Can you use backupsets or export nodes to real tape (no client impact.) Or
> full restores to a dummy node and then archive those to real tape  (once a
> month), again no direct client impact.
> Can the "monthlles" be spread over 30 days?
>
> Richard
>
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
> Harris, Steven
> Sent: Thursday, November 16, 2017 4:51 PM
> To: ADSM-L@VM.MARIST.EDU
> Subject: [ADSM-L] Monthly backups of VMs
>
> HI All
>
> Environment is
> TSM 7.1.1 server on AIX. 7.1.1 Storage agents on Linux,  7.1.1  BA
> clients, 7.1.1 VE clients,  VMWare 5.5.  The VMware backups are via the SAN
> to a Protectier VTL.
>
> My Client is an international financial organization so we have lots or
> regulatory requirements including SARBOX.  All of these require a monthly
> backup retained 7 years.  Recent trends in application design have resulted
> in multiple large MSSQL databases - up to 10 TB that never delete their
> data.  Never mind the logic, the hard requirement is that these be backed
> up monthly and kept for 7 years, and that no variation will be made to the
> application design.
>
> Standard process has been a daily VE incremental backup to a daily node
> and monthly full to a separate node.  The fulls are becoming untenable on
> several grounds.  The VBS Servers need to run a scsi rescan on weekdays to
> pick up any changed disk allocations, and this interrupts any running
> backups.  The individual throughput of the Virtual tape drives is limited
> so sessions run for a long time and there is not enough real tape to use
> that.   Long running backups cause issues with the storage on the back end
> because the snapshots are held so long.
>
> Does anyone have any practical 

Re: Monthly backups of VMs

2017-11-17 Thread Lee, Gary
I assume that the data stored in the SQL databases is the primary retention 
target.
If that is the case, how about a flat file dump to a central storage, then use 
another client to scoop that up monthly.
Use resourceutilization to give it several sessions, and back up to the VTL.

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Harris, Steven
Sent: Thursday, November 16, 2017 5:43 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Monthly backups of VMs

Thanks for the reply Richard

Backupsets apply only to BA client data.  Theoretically exports are possible. 
I've had issues with backupsets in the past and even if it were not possible 
would be loath to go there again (e.g. backupset is essentially a restore so it 
would take a drive to start, but then not have priority to take another drive 
to write its data and fail, so I didn't get a good backupset and whatever was 
interrupted also failed).

Management of exports is also less than ideal. And they are slow, hmmm, unless 
an active pool was used.

The problem with mixing monthlies and dailies is that they both use the 
same-named snapshots and so if one is running and the other starts it causes 
the existing snapshot to be deleted and the running backup fails.  If there 
were a way to alter the snapshot name for the monthlies, that might help, but 
afaik there is not.  Without that then we need to manipulate the domain.vmfull 
(or any alternatives) on a daily basis to exclude that day's monthlies from 
daily backups and include into that day's monthlies.  Not simple.

Thanks for making me explain this.  Active pool and exports may be the way to 
go.  Define the export volumes explicitly with a name that identifies their 
contents, then back them up with the BA client.

Cheers

Steve

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Richard Cowen
Sent: Friday, 17 November 2017 9:06 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Monthly backups of VMs

Can you use backupsets or export nodes to real tape (no client impact.) Or full 
restores to a dummy node and then archive those to real tape  (once a month), 
again no direct client impact.
Can the "monthlles" be spread over 30 days?

Richard

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Harris, Steven
Sent: Thursday, November 16, 2017 4:51 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Monthly backups of VMs

HI All

Environment is
TSM 7.1.1 server on AIX. 7.1.1 Storage agents on Linux,  7.1.1  BA clients, 
7.1.1 VE clients,  VMWare 5.5.  The VMware backups are via the SAN to a 
Protectier VTL.

My Client is an international financial organization so we have lots or 
regulatory requirements including SARBOX.  All of these require a monthly 
backup retained 7 years.  Recent trends in application design have resulted in 
multiple large MSSQL databases - up to 10 TB that never delete their data.  
Never mind the logic, the hard requirement is that these be backed up monthly 
and kept for 7 years, and that no variation will be made to the application 
design.

Standard process has been a daily VE incremental backup to a daily node  and 
monthly full to a separate node.  The fulls are becoming untenable on several 
grounds.  The VBS Servers need to run a scsi rescan on weekdays to pick up any 
changed disk allocations, and this interrupts any running backups.  The 
individual throughput of the Virtual tape drives is limited so sessions run for 
a long time and there is not enough real tape to use that.   Long running 
backups cause issues with the storage on the back end because the snapshots are 
held so long.

Does anyone have any practical alternate approaches for taking a monthly VMware 
backup for long term retention?

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 

Re: Monthly backups of VMs

2017-11-16 Thread Harris, Steven
Thanks for the reply Richard

Backupsets apply only to BA client data.  Theoretically exports are possible. 
I've had issues with backupsets in the past and even if it were not possible 
would be loath to go there again (e.g. backupset is essentially a restore so it 
would take a drive to start, but then not have priority to take another drive 
to write its data and fail, so I didn't get a good backupset and whatever was 
interrupted also failed).

Management of exports is also less than ideal. And they are slow, hmmm, unless 
an active pool was used.

The problem with mixing monthlies and dailies is that they both use the 
same-named snapshots and so if one is running and the other starts it causes 
the existing snapshot to be deleted and the running backup fails.  If there 
were a way to alter the snapshot name for the monthlies, that might help, but 
afaik there is not.  Without that then we need to manipulate the domain.vmfull 
(or any alternatives) on a daily basis to exclude that day's monthlies from 
daily backups and include into that day's monthlies.  Not simple.

Thanks for making me explain this.  Active pool and exports may be the way to 
go.  Define the export volumes explicitly with a name that identifies their 
contents, then back them up with the BA client.

Cheers

Steve

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Richard Cowen
Sent: Friday, 17 November 2017 9:06 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Monthly backups of VMs

Can you use backupsets or export nodes to real tape (no client impact.) Or full 
restores to a dummy node and then archive those to real tape  (once a month), 
again no direct client impact.
Can the "monthlles" be spread over 30 days?

Richard

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Harris, Steven
Sent: Thursday, November 16, 2017 4:51 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Monthly backups of VMs

HI All

Environment is
TSM 7.1.1 server on AIX. 7.1.1 Storage agents on Linux,  7.1.1  BA clients, 
7.1.1 VE clients,  VMWare 5.5.  The VMware backups are via the SAN to a 
Protectier VTL.

My Client is an international financial organization so we have lots or 
regulatory requirements including SARBOX.  All of these require a monthly 
backup retained 7 years.  Recent trends in application design have resulted in 
multiple large MSSQL databases - up to 10 TB that never delete their data.  
Never mind the logic, the hard requirement is that these be backed up monthly 
and kept for 7 years, and that no variation will be made to the application 
design.

Standard process has been a daily VE incremental backup to a daily node  and 
monthly full to a separate node.  The fulls are becoming untenable on several 
grounds.  The VBS Servers need to run a scsi rescan on weekdays to pick up any 
changed disk allocations, and this interrupts any running backups.  The 
individual throughput of the Virtual tape drives is limited so sessions run for 
a long time and there is not enough real tape to use that.   Long running 
backups cause issues with the storage on the back end because the snapshots are 
held so long.

Does anyone have any practical alternate approaches for taking a monthly VMware 
backup for long term retention?

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 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 

Re: Monthly backups of VMs

2017-11-16 Thread Richard Cowen
Can you use backupsets or export nodes to real tape (no client impact.)
Or full restores to a dummy node and then archive those to real tape  (once a 
month), again no direct client impact.
Can the "monthlles" be spread over 30 days?

Richard

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Harris, Steven
Sent: Thursday, November 16, 2017 4:51 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Monthly backups of VMs

HI All

Environment is
TSM 7.1.1 server on AIX. 7.1.1 Storage agents on Linux,  7.1.1  BA clients, 
7.1.1 VE clients,  VMWare 5.5.  The VMware backups are via the SAN to a 
Protectier VTL.

My Client is an international financial organization so we have lots or 
regulatory requirements including SARBOX.  All of these require a monthly 
backup retained 7 years.  Recent trends in application design have resulted in 
multiple large MSSQL databases - up to 10 TB that never delete their data.  
Never mind the logic, the hard requirement is that these be backed up monthly 
and kept for 7 years, and that no variation will be made to the application 
design.

Standard process has been a daily VE incremental backup to a daily node  and 
monthly full to a separate node.  The fulls are becoming untenable on several 
grounds.  The VBS Servers need to run a scsi rescan on weekdays to pick up any 
changed disk allocations, and this interrupts any running backups.  The 
individual throughput of the Virtual tape drives is limited so sessions run for 
a long time and there is not enough real tape to use that.   Long running 
backups cause issues with the storage on the back end because the snapshots are 
held so long.

Does anyone have any practical alternate approaches for taking a monthly VMware 
backup for long term retention?

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.