ADSM-L

Re: [ADSM-L] VMCTLMC space for a full backup.

2018-02-07 14:23:27
Subject: Re: [ADSM-L] VMCTLMC space for a full backup.
From: Stefan Folkerts <stefan.folkerts AT GMAIL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 7 Feb 2018 20:20:33 +0100
I understand Remco's point but I think TSM can handle 7 years of retention
just fine and that the format is the bigger challenge here...full VM.
I'm sure there are rules that require you to do this but 7 years is crazy
long for full VM backups if it's about a lot of source data.
So far i've always been able to convince the customer that a regular
incremental backup with a B/A node of specific data with 7 years retention
will be just fine and a lot smaller than the whole VM, it also gives you a
better guarantee that you will be able to restore because a VM that's 7
years old might have compatibility issues with the than current vSphere
stack.

I'm sorry I can't help you with your sizing, I would share if I would have
the data but I don't, I give VM backups a maximum of 3 months retention and
that's incremental forever only.
Good luck.


On Wed, Feb 7, 2018 at 9:07 AM, Remco Post <r.post AT plcs DOT nl> wrote:

> > Op 7 feb. 2018, om 03:16 heeft Harris, Steven <steven.harris@
> BTFINANCIALGROUP.COM> het volgende geschreven:
> >
> > Hi Guys
> >
> > There is a really good explanation of VMCTLMC Sizing for incremental VM
> backups at  http://adsm.se/?p=546
> > I run a monthly full for compliance reasons on all the Prod Vms, and am
> trying to understand the implications for   VMCTLMC Sizing.  So far I
> suppose its 8000 megablocks  as well as 8000 control files per TB so
> 8000*(128+73) KB ~= 1.5 MB/TB.
> >
> > As there is a 7 year retention for these I see why I'm running out of
> space.
> >
> > The only option I can see would be a 1 year retention and a monthly
> export to tape for this data.  What do others do?
> >
>
> I just keep on insisting: backups are for disasters (big and small)
> archives are for lawyers (and other nitwits that make up rules). So, 7 year
> retention goes into an archive solution, not TSM. And I can make people
> understand quite simply: so the e-mail I get on the 5th of the month and
> delete the next day is less important to rule makers  than the one I get on
> the day of the month that we happen to take our full backups? I know what
> I’ll do, I won’t do the illegal stuff at the end of the month!
>
> Yes, that doesn’t solve your problem….
>
> > Cheers
> >
> > Steve
> >
> > 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.
>
> --
>
>  Met vriendelijke groeten/Kind Regards,
>
> Remco Post
> r.post AT plcs DOT nl
> +31 6 248 21 622
>

<Prev in Thread] Current Thread [Next in Thread>

ADSM.ORG Privacy and Data Security by KimLaw, PLLC