Hi Eric,
I don't have much else to offer other than monitoring the SAP HANA backups
to ensure any failures are caught and corrected promptly. If you have a
two week retention period, you should be able to detect failed backups and
react well before all backups have expired.
It may also help if you placed a requirement against SAP directly to
provide the enhancement as well. If they see more heat on this, it could
motivate them to release this sooner and specify a target date.
Thank you,
Del
----------------------------------------------------
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 08/01/2016
05:03:29 AM:
> From: "Loon, EJ van (ITOPT3) - KLM" <Eric-van.Loon AT KLM DOT COM>
> To: ADSM-L AT VM.MARIST DOT EDU
> Date: 08/01/2016 05:04 AM
> Subject: Re: Very weird design change SAP HANA client
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
> Hi Del!
> Thank you very much for your explanation. And sorry for blaming IBM
> for this. I'm really puzzled over what to do next. Like I said,
> implementing policy based expiration introduces the risk of losing
> all your backups when a client stops backing up for a certain amount
> of time. The option of deleting backup data through SAP HANA Studio
> is also not very attractive: I know the customer will do this in the
> beginning, but over time they will become sloppy or just forget...
> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
> Behalf Of Del Hoobler
> Sent: vrijdag 29 juli 2016 19:05
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Very weird design change SAP HANA client
>
> Eric,
>
> This "design change" is a "change" from the Data Protection for ERP
> perspective, but not from the Data Protection for ERP for SAP HANA
> perspective, which has always worked this way.
>
> This design "change" is a result of a current limitation in the SAP
> HANA BACKINT API and is expected to be temporary. This backup API
> streams the backup data to the DP for SAP HANA client via named
> pipes and today it gives no indication whether the data stream was
> complete or the pipe was closed prematurely due to some error.
>
> We don't want to expire a prior/older backup version unless we know
> we have a successful new backup version so we do not currently offer
> expiration of backups based on version limit. However, we do plan
> to provide that capability once SAP implements the enhancement to
> the backup API we have requested (to indicate whether or not all the
> data was streamed successfully). SAP did indicate they plan to
> provide that enhancement but we do not yet have a target date for that.
>
>
> Thank you,
>
> Del
>
> ----------------------------------------------------
>
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 07/29/2016
> 07:23:32 AM:
>
> > From: "Loon, EJ van (ITOPT3) - KLM" <Eric-van.Loon AT KLM DOT COM>
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Date: 07/29/2016 07:24 AM
> > Subject: Very weird design change SAP HANA client Sent by: "ADSM: Dist
> > Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> >
> > Hello all!
> > Recently we started to use the Data Protection for SAP HANA client.
> > I created a TSM node identical to the already existing Data Protection
> > for SAP node and now customer reported that he received the following
> > error message after a successful backup:
> >
> > BKI8649E: The automatic deletion of backups is not supported. Change
> > the value of the MAX_VERSIONS parameter to 0
> >
> > I googled for the BKI8649E and stumbled across technote IT11810 which
> > explains that versioning through the MAX_VERSIONS parameter is no
> > longer supported. You now have to use TSM to control the retention for
> > your SAP backups. That would be very nice if the TDP client was
> > creating backup files on TSM and was working like the Oracle client
> > (active files are kept forever until they are marked inactive by
> > RMAN/TDP for Oracle). But the DP for SAP client creates archive files,
> > so when you backup your SAP database, the files are kept for the
> > amount of time set in the archive copy group. This means that if you
> > have a copygroup setting of 14 days and you do not backup your
> > database for 14 days for some reason, on day 15 you no longer have any
> > backup available for recovery!!!
> > I think this is absolutely unacceptable and I really don't understand
> > why IBM has decided to change this.
> > The only work around one has is to set retver to unlimited and delete
> > the obsolete backup versions through HANA Studio. This is also
> > unacceptable I think, this is moving a design flaw to the customer
> side.
> > Am I the only one struggling with this issue?
> > Kind regards,
> > Eric van Loon
> > Air France/KLM Storage Engineering
> > ********************************************************
> > For information, services and offers, please visit our web site:
> > http://www.klm.com. This e-mail and any attachment may contain
> > confidential and privileged material intended for the addressee only.
> > If you are not the addressee, you are notified that no part of the
> > e-mail or any attachment may be disclosed, copied or distributed, and
> > that any other action related to this e-mail or attachment is strictly
> > prohibited, and may be unlawful. If you have received this e-mail by
> > error, please notify the sender immediately by return e-mail, and
> > delete this message.
> >
> > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/ or
> > its employees shall not be liable for the incorrect or incomplete
> > transmission of this e-mail or any attachments, nor responsible for
> > any delay in receipt.
> > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
> > Dutch Airlines) is registered in Amstelveen, The Netherlands, with
> > registered number 33014286
> > ********************************************************
> >
> ********************************************************
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee
> only. If you are not the addressee, you are notified that no part of
> the e-mail or any attachment may be disclosed, copied or
> distributed, and that any other action related to this e-mail or
> attachment is strictly prohibited, and may be unlawful. If you have
> received this e-mail by error, please notify the sender immediately
> by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/
> or its employees shall not be liable for the incorrect or incomplete
> transmission of this e-mail or any attachments, nor responsible for
> any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
> Dutch Airlines) is registered in Amstelveen, The Netherlands, with
> registered number 33014286
> ********************************************************
>
>
|
