MDM backup strategy

[Former Member]

Hi,

We are running CE 7.2 and MDM 7.1 for central master data management. Also, PI and ERP are in the MDM landscape.

[Here|http://help.sap.com/saphelp_nwmdm71/helpdata/en/49/ba4a1e57f1551de10000000a42189c/frameset.htm], SAP suggests that for a complete backup, the MDM system components have to be stopped. I understand that if the archive/unarchive approach is used to create a backup, the repository has to be unloaded, resulting in system downtime. However, what I wanted to understand is whether a hot backup at DB/file level results in a consistent MDM system or not? This means the server keeps running but a snapshot of database/file system will be created.

So the question is: will a hot backup of MDM system give a consistent backup which can be used for a recovery? Or do we need system downtime to ensure a consistent backup?

Thanks and regards,

Shehryar

[Former Member · Accepted solution]

Archiving the repository in 7.1 SP06 should not require the repository be down. It will put a lock on the repository during the archive, preventing any updates, but it will technically be available.

Also, we noticed a HUGE performance boost with SP06 on archive times. Our archive went from 45 minutes to 4 minutes with the upgrade from SP05. We now can do archive mid-day with limited user impact.

Hope this helps,

Steve Monaghan

[bglobee]

Hi Shehryar,

few options that can be considered as you say that the system is 24*7 critical.

Is the MDM system running on a dedicated host or on shared host?

As far MDM 7.1 SP07 and above, system performance is not so sensitive to archiving. If system is sized properly (sufficient enough to handle the spike in MDS process), then you can choose the time window where the activity will be less.

Avoid mass syndications or imports when the archiving or backup is scheduled.

1. Schedule the normal DB backup and Filesystem backup fr everyday

     Advantage: It doesnt have any serious impact on the repository performance.

     Disadvantage: If any specific repository is corrupt and if you are planning to restore the repository, then you cannot restore the specific repository. Instead, you will have to restore the full DB. The Business data in other repositories are also lost.

2. In addition to above, schedule the weekly archiving of repositories (as a fall back option).

     Advantage: Not so much. But if a repository gets corrupted, still you can take a call of reverting the repository to 1 week earlier state and then do a synchronization of data with connected ECC systems.

     Disadvantage: backup overhead but comes in handy if one of the repositories are corrupt.

3. Check for the option of Master - Slave repository setup.

Regards,

Balaji S

[Former Member]

i agree with the last post pf master slave

the idea of having these are for 24x7 availabilty of the repo

make a couple of slaves (5+5 min)

synch slaves (a few seconds for upto a lakh records)

then have the end users access the slaves instead of the master (slaves have read only properties)

bring master down (make sure no bodys uploadiing data then)

and do archive/unarchive

once done back to normal

mix and match the best strategy as per ur business needs but this concept is SAP recommened - that works for a change!

thanks

-Adrivit

[Former Member]

Hi,

Thanks for the response. Much appreciated.

Master/Slave configuration, in our case, won't add much value. We have a Central MDM system with multiple repositories containing several million records. Most of the operations on the MDM are data maintainence (create/update/delete) operations which I can't do through Slave any way. Master/slave works fine when your reads/searches on the data are significantly more than the writes. Please correct me if I am wrong.

Thanks and regards,

Shehryar

[former_member189669]

Hi Shehryar,

We have a similar CMDM landscape without PI and CE.

We are using DB backup instead of archiving process. We are not facing any performance degradation.

Regards,

Vinay.

[Former Member]

Thanks Vinay. Can you please confirm if you take hot or cold backups? If hot, have you tried restoring the server from backup to ensure it remains consistent?

Thanks and regards,

Shehryar

[Former Member]

Hi All,

Thanks for the information. I would like to add:

MDM works much like other systems , as example SAP ERP and ESB (middleware).

For 24x7 operation you can take

1. Oracle/DB backup - hot backup eg rman

2. File system backup (snapshots eg every hr) - the /usr/sap or specifically the distribution folder.

Your 1. and 2. needs to be as close as possible to rollback the import server activities before the downtime. If your 2. is far aprt from 1. then you will lose the imports even though DB is intact.

You will still have to work with the functional team to see what was lost during that time and reconcile.

Thanks,

Naren

[Former Member]

Hello Shehryar

You can make hot backup(archiving) for SAP MDM repository but you should be absolutly sure that nobody don't modify repository data during your archiving process.(if somebody modify repository data during your archiving process you just don't get actual backup- nothing more)

In additional - archiving process using a lot mds resources and mds sometime stay in hold.

And sure you can use your backup for recovery.

Regards

Kanstantsin Chernichenka

[Former Member]

Hi,

Thanks for the response. Much appreciated.

I am looking to use a database specific backup approach rather than archiving facility provided by SAP in MDM. As I understand, archiving requires the repository to be unloaded so there is downtime for the customer.

However, if a hot backup is taken, like a snapshot of database and file system, even when the system is online, is that good enough to restore from the backup? Or is it absolutely necessary for a consistent backup of MDM to have downtime?

Thanks

Shehryar

[Former Member]

Hello Shehryar

Stop mds before backup(when you stop mds database still working on your DBMS server but nobody can change data) so as Stop DBMS(unload databases) before backup garantee that you get actual copy of databases.

Make hot backup DBMS where working sap mdm and make hot backup DBMS where working somebody(i mean user) is identical

That two backup's have the same risk to lost database data.

if you going to do hot backup DBMS - that is not a problem you can do it, but if somebody modify records during your backup operation - your copy will be not actual and if you then repair database from that copy you may lost some latest changes in your data.

According mdm:

If you want to do backup on time in automatic mode you can use CLIX (that is console application for managing MDM)

CLIX can start stop mdm server and it repositories, checking repositories, archiving ,ets.

Regards

Kanstantsin Chernichenka

[Former Member]

Hi Kanstantsin,

Thanks for the response.

We are designing a landscape with 24/7 availability so downtime is not acceptable. Stopping the MDS server will mean we can't offer 24/7 availability. Usually, SAP application databases, other than MDM, can be backed up along with database logs without downtime. In case of a recovery, the database logs can be rolled forward up to the point when snapshot was taken. So a hot backup of these applications can give a consistent state when recovered.

In case of MDM, I want to confirm if the daily hot backups, even when the users are online, are good enough to restore MDM to consistent state?

Thanks

[madasamy_arunachalam]

Hi Shehryar,

In Production environment, there will/should be a Master and Slave repositories and this ensure that high availability of MDM repositories.

Master Repositories

It will be used only (only 2 or 3 times on weekly basis) by Core functional Team (not by end user), for DATA upload or core DATA modification activities for the respective repositories, which can be scheduled other than scheduled backup time.

No End user (SRM or EP) connected to this repository.

Slave Repositories

Slave get synchronized from Master, this will also based on the frequency of the Master repositoriesu2019 changes and performed by the core functional/Business team.

End users (via UI/EP) are connected to this repository on a regular basis.

These repositories are get created within Database of the instance (SID of java stack) as schema.

For the backup strategy, we can follow the same method of other SAP instances (or SAP environment).

Please revert, if any more details are required.