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 <g...@bsu.edu> 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 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 > https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fwww.bt.com.au&data=02%7C01%7Cglee%40BSU.EDU% > 7C736d6aebb2a44bdf858208d52d43d767%7C6fff909f07dc40da9e30fd7549c0 > f494%7C0%7C0%7C636464691759898588&sdata=uvK30DIWrgEJPRqU% > 2Br4oEWcRxlsP9FUQY4ZJ2%2Byaw7U%3D&reserved=0 > > 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 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://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fwww.bt.com.au&data=02%7C01%7Cglee%40BSU.EDU% > 7C736d6aebb2a44bdf858208d52d43d767%7C6fff909f07dc40da9e30fd7549c0 > f494%7C0%7C0%7C636464691759898588&sdata=uvK30DIWrgEJPRqU% > 2Br4oEWcRxlsP9FUQY4ZJ2%2Byaw7U%3D&reserved=0 > > Past performance is not a reliable indicator of future performance. >
