Upgrade - restore backup to post-processing phase

[bdumbell]

Hi,

A few days ago I successfully upgraded our BI Dev instance to Netweaver 7.4 and completed post-processing to the point where SUM has completed.

I've subsequently installed a support pack for the BPC 7.54 component which is now stopping me from installing the SAINT installation package for the BPC 10.1 release we want to upgrade to - essentially SAINT is saying that SP05 of BPC 10.1 is required for equivalency to the existing BPC 7.54 version.  My issue is that BPC 10.1 SP05 is not yet released so I'm unable to include that patch for equivalency and am at a standstill.

So, I'm now looking at having to restore a backup to roll the system back to a point before the BPC 7.54 support pack was installed.

I took a database backup at the beginning of downtime when prompted (along with the full SUM directory and other paths as directed by the prompts) and also another backup of the database only at the end of the upgrade process when prompted (not the SUM dir).  Unfortunately I did not take a backup prior to installing the BPC 7.54 support pack as it was not seen as a major change - isn't hindsight wonderful!

So, my question is if I restore the database backup I took at the end of the upgrade aren't you prompted to take this backup before post-processing has completed?  Looking at timestamps this appears to be the case, I'm can't see in the guide mention of when the backup prompt would have been.

I do not have a backup of the SUM directory at this point so I'm not sure how I can continue & complete post processing once the restore is completed?

Appreciate any advice.

Thanks,

Blair

[Reagan · Accepted solution]

Blair,

Was the backup taken at the end of the "Execution" phase where it states "The end of Downtime"? The tool prompts for the database backup with the "Backup Request" just before the above screen. Once you continue from here the tool starts the SAP system post upgrade and there are few sub tasks executed (if required) and I am not sure whether there are modifications done at the DB level. if they aren't any critical then I wouldn't bother.

If you have taken a backup after the downtime phase in SUM then restore than and continue with the tasks like SGEN, SPAU and the old tablespace drop and other things which you have done.

As you have not taken a backup of the SUM tool just before the downtime then there is no point in doing a downtime execution again as this is not possible.

After the backup has been completed check whether the system is functioning as expected.

If the database is Oracle and in archive log then it possible to restore the full backup and apply the archive logs until the start of the Add-on installation.

As this is a Dev system I would try to restore and seek the support of an ABAP'er if in need.

Good Luck

RB

[bdumbell · Accepted solution]

Thank you both for your replies.

The database is MSSQL and unfortunately is in simple mode so I can't take the approach of restoring and then replaying transaction logs to a point in time before the add-on installation.

Reagan, yes, I think the stage you mention must be where I took the post upgrade backup.  I do have a backup of both the database and SUM directory at the point before the downtime commenced, it's after the downtime that I don't have a backup of the SUM directory.

With this in mind I'm wondering if restoring the database and SUM to the point before downtime is the better approach?  I'll have to go through downtime processing again as I'm restoring to a point further back however doing so will ensure that postprocessing runs - skipping which is my concern with restoring to the post upgrade backup as I don't know how critical the tasks it runs are.

With resoring to a backup before the downtime commenced, can you continue from that point or do you actually need to reset the upgrade and then start again?  To my thinking the DB will contain all the shadow tables and the SUM directory will be correct but the shadow instance service won't actually exist on the server.....

Thanks again.

[Reagan · Accepted solution]

Blair,

If you have taken a backup of the database before you started the database and also the SUM directory then you can easily start the downtime phase again.

You need to restore the database backup and delete or rename the current SUM directory and put the one you have backed up and start the downtime again.

Remember, you will also need to put the old profiles and kernel used by the system before the downtime. You will isolate the CI before starting the downtime as mentioned in the upgrade guide and start the downtime phase.

Cheers

RB

[bdumbell · Accepted solution]

Hi Reagan,

Apologies for my late reply.

I ended up taking a slightly different approach and am now comfortable that this issue is resolved.  Instead of reverting to a previous backup and then repeating the upgrade as I was originally suggesting I've examined which notes are contained in the 7.54 support pack that didn't yet have an equivalent SP on 10.1.  Thankfully there were only a small number of notes in the SP and of those only a few were also relevant to the 10.1 version.

So, I've continued with the BPC 10.1 installation (it is possible to continue past the equivalency error that SAINT gives) and then patched the BPC component to the latest SP available before reapplying the individual notes that were in the other SP and relevant to 10.1.  I'm confident that this should have resulted in equivalency between the two versions and I'll apply 10.1 SP5 once it's available to be certain.

Thanks again for your help & suggestions.

Cheers,

Blair

[manumohandas82]

In case you are considering the restore option

1 ) Take a full offline backup backu

2 ) Restore the backup  you have taken during the upgrade and roll forward the DB until the time you have updated the BPC 7.54 .( You can find the  time from the import logs )

It is always a good practice , after any upgrade has completed , to  take a full backup  before going live . If you are constrained by time  you should  consider snapshot or other quick backup technologies  or atleast note the archive log number

Thanks ,

Manu