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" <[email protected]> wrote on 08/01/2016 05:03:29 AM: > From: "Loon, EJ van (ITOPT3) - KLM" <[email protected]> > To: [email protected] > Date: 08/01/2016 05:04 AM > Subject: Re: Very weird design change SAP HANA client > Sent by: "ADSM: Dist Stor Manager" <[email protected]> > > 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:[email protected]] On > Behalf Of Del Hoobler > Sent: vrijdag 29 juli 2016 19:05 > To: [email protected] > 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" <[email protected]> wrote on 07/29/2016 > 07:23:32 AM: > > > From: "Loon, EJ van (ITOPT3) - KLM" <[email protected]> > > To: [email protected] > > Date: 07/29/2016 07:24 AM > > Subject: Very weird design change SAP HANA client Sent by: "ADSM: Dist > > Stor Manager" <[email protected]> > > > > 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 > ******************************************************** > >
