Snapshot and backup

[Former Member]

Hello Experts,

Current Scenario:

There is a daily snapshot of the BW system in nite for our Production server. During this they have to stop any jobs / loads running at that time.

Secondly they take a backup every weekend. They stop any jobs / loads during that time also.

Wondering if you could provide ur experiences, that would very great of you..

1) Is snapshot necessary every day?

2) what is the alternative to daily snapshot?

3) what is the best procedure for daily snapshot ?

4) is there a procedure not to stop the loads / jobs during snapshot ?

5) Is backup necessary every weekend?

6) what is the alternative to weekly backup?

7) what is the best procedure for weekly backup ?

😎 is there a procedure not to stop the loads / jobs during backup ?

9) is there any doc / paper / link / notes for the snapshots and backups for BW production system.

10)what is the typical time taken for snapshot?

11) what is the typical time taken for backup ?

any does please mail to mgmswsol@gmail.com

Thanks,

BWer

Message was edited by: BWer

[edwin_harpino]

dear BWer,

as far as i know, we didn't do such snapshot,

and didn't stop the system for daily backup,

they do such online backup (?).

will check detail or any docs ...

hope this helps.

[edwin_harpino]

hi,

check if helps oss note 731682-Backup in BW and OLTP: Experiences, risks & recommendations

Symptom

Backup in the BW system or OLTP system

Other terms

Backup, recovery, delta

Reason and Prerequisites

You are thinking about importing a backup with an incomplete recovery into your BW system or into a source system connected to your BW system because you do not have the option to fully restore the system or to switch to an identical system. In this case, you must distinguish between a 'hardware problem' and a 'logical error'. If hardware problems occur, you have no other option. If logical errors occur (data inadvertently deleted from the application, for example), we generally advise against importing this type of backup.

Importing a backup with an incomplete recovery into a BW system or into a source system connected to the BW system can result in serious inconsistencies in the delta process. The probability of this occurring increases the further back in time the recovery took place.

Solution

In any case, familiarize yourself with the contents of the Best Practices document, "Backup and Restore for mySAP Business Suite" (see Sapnet, alias "Solutionmanagerbp").

This note describes application-based solutions both as an alternative to the backup and to the procedure that you must follow if you decide to import the backup. Depending on the problem, you must check these solutions again separately with regard to consistency and the time & effort required to implement these solutions.

Furthermore, we would like to draw your attention to the possible risks (these are described in detail below).

1. Alternative to importing the backup

If, for example, you want to restore the data in a table, it may be enough to copy the data in this table from a backup.

Ideally, you have a standby database that you can use to restore the system statuses back to several days previously. To use this function to solve the problem, you may require considerable knowledge of the application. Furthermore, it may take a lot of time and manual work to perform this comparison.

In this case, standby databases are not an independent concept, they merely make the above work faster, easier and more flexible. In principle, however, you can also do this using tape backups. The most important thing here is that, in production, only individual tables, or sometimes only part of these tables, are reset to the status before the error, and that you realize exactly which tables and transactions are affected by the error. We urgently recommend that customers contact SAP for advice.

2. Importing the backup with an incomplete recovery

2.1 Import backup into the BW system

2.1.1 Ensure the consistency of the delta download of the BW system

When you import a backup from a certain time in the past (called the 'backup time' in the following) into the BW system, requests loaded since this time no longer exist in BW. In the delta queue of the source system, however, the data for the last loading process was deleted for each new delta data request. There is no way to restore the status for the 'backup time' of the BW system in the delta queue in the source system.

Therefore, you must usually re-initialize all of the DataSources for which delta data was loaded since the 'backup time'.

Only in the cases in which delta data was loaded exactly once since the 'backup time' do you have a generic option to reload the data again by repeating the delta data request and thus achieving a consistent status. For this, you must set the last data request that occurred in the monitor to the status "red" and repeat once again.

In this case, however, you should bear in mind that this procedure is not transparent in the monitoring. To secure the second last loading process, you should note the times of both the last and second last request before you perform a recovery backup.

If the missing data can be determined explicitly, it is sometimes possible to once again synchronize the dataset in BW with the source system status using a full data extraction independent of the delta download with the relevant selection.

Furthermore, in certain cases, you can allow a consistent delta data request based on the 'backup time' by adjusting the internal delta administration (usually a time stamp) to special extractors. For more exact information, see Section 2.1.2. However, note that this would only be a solution if you are only using a BW system since the time stamp administration is independent of the BW system.

If you have to perform a re-initialization, we recommend that you restrict this to a dataset that cannot be considered to be static (the following are static, for example, the data of the previous year and unchanged data in the delta queue of the source system). This procedure is possible if the DataSource provides a corresponding selection. Procedure:

- Delete the dataset to be re-initialized from all of the data targets.

- Perform a complete or selective re-initialization.

- For a chronological selection, set the upper interval in the InfoPackage to endless.

- Caution: An 'update stop' may be required in the source system.

In addition, the static data should be transferred to BW via a full upload.

2.1.2. Additional notes for specific Business Content DataSources

Logistic Cockpit DataSources: Refer to the information on LO-LIS re-initialization in notes 436393 and 602260.

CO-OM DataSources: In certain cases, you can reset the time stamps in the relevant extractor-specific table. If you require help for the 'Reset the time stamps in the OLTP' action, open a customer message under the BW-BCT-CO-OM component.

CO-PA* up to and including PI 2003.1: You can reset the time stamps in the corresponding extractor-specific table (see note 422173).

CO-PA as of PI 2004.1:

You cannot reset the time stamp.

FI DataSources 0FI_4 and 0FI_6 up to 0FI_10: Specific correction programs exist for 0FI4 DataSources, they permit the customer to specifically write missing or incorrect documents into the separate FI delta queue (BWFI_AEDAT) and to extract them again in this way (see note 616331).

2.1.3 Additional information/general recommendations for preventing problems

With regard to system administration, remember that very few people have authorization to change or delete table contents and in particular, bear the "drop table" database operation in mind.

Use a Data Warehouse layer to store operative data that refers to a specific document. In this context, use PSA and ODS objects for loading. Keep the data in the PSA table until you have made sure that these were successfully updated into the data targets. The Data Warehouse Layer provides you with the option to set up datasets independent of the source system again if, for example, errors occur in the dataset as a result of incorrect update rules.

If, based on a re-initialization, you have critical DataSources, you can avoid the re-initialization (as described above) if you can ensure that no more than one delta data request appears between two backups. Ideally, you should not load delta requests into the BW system any more than every 1.5 2 hours.

As a solution, you can also envisage a system landscape in which two BW systems are connected to an OLTP system. Deltas are loaded into both systems and, if a backup has to be imported into one of these two systems, the second BW should be used as a 'a lifebelt' for the delta method. This type of solution is possible, but it can only be implemented with the help of an experienced consultant. SAP does not provide any support for this type of solution.

2.2 Importing a backup into the source system

This action resets the delta queue in the source system to an old status. Data that was already transferred to BW no longer exists in the source system after the backup.

In many cases, it is possible to detect the requests that were loaded into BW since the 'backup time' and to delete these in all of the data targets. A subsequent delta data request would result in a consistent dataset in BW. However, this action requires a great deal of manual work and it must be performed with extreme caution.

Alternatively, you must re-initialize the delta download as described under 2.1.1.

[Former Member]

Anyone please help...