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 AT VM.MARIST DOT EDU] On Behalf Of
Harris, Steven
Sent: Thursday, November 16, 2017 5:43 PM
To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU] On Behalf Of
Richard Cowen
Sent: Friday, 17 November 2017 9:06 AM
To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU] On Behalf Of
Harris, Steven
Sent: Thursday, November 16, 2017 4:51 PM
To: ADSM-L AT VM.MARIST DOT 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%7C6fff909f07dc40da9e30fd7549c0f494%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%7C6fff909f07dc40da9e30fd7549c0f494%7C0%7C0%7C636464691759898588&sdata=uvK30DIWrgEJPRqU%2Br4oEWcRxlsP9FUQY4ZJ2%2Byaw7U%3D&reserved=0
Past performance is not a reliable indicator of future performance.
|
