SDL Web8 database restore from Production to QA

Question 1

We have recently upgraded to Web8.1 from 2011, we have been following the process of taking the database backup of CM and restore to lower environments periodically to have the latest data to perform analysis or testing which cannot be done on production.

Now we have done this DB backup-restore process for first time on Web8.x and process followed is for all Tridion databases including Topology Manager and Discovery DB.

Yes, we have identified that if we restore Topology Manager and discovery databases from production to lower environments, then we cannot have it without changes after restoration. Because it has environment specific data within it.

We have reverted the Topology manager and discovery database restore but problem now is that Topology manager database has mappings as well which refers the TCM IDs from CM database. If we keep these from old version from lower environment then the TCM IDs for publications are mismatching and publishing or many other actions are not working for certain publications. (specially for publications which were created recently after the upgrade due to many publications were created on lower environments while testing)

Now that CM is on production version and topology and discovery are on lower environment version let's say QA version few things are not working, and we need to fix this.

Questions:1. How to fix this? do I need to update the mappings or update the environment specific details on QA?2. Is there any standard process followed for restoration of databases from production to QA specifically on or after Web 8.x and onward versions? Note: Already checked with SDL support and they do not have any standard process documented with them for this kind of process.

Thanks in advance, appreciate if someone can share their own experiences.

-Sarang Deshmukh

Question 2

One of the main reasons for the Topology DB was that you wouldn't need to copy it across environments - as long as your purposes match, the mappings should be restored/reset. I'll do some investigation

Question 3

Hi, Thanks Nuno. Appreciate the investigation form your end. Problem is that I will have to create few publications for test purpose on QA, hence the blueprint will never match from production and QA (more publications on QA) and the mismatch on the mapping will always be a problem. This problem is faced only after the upgrade, earlier it was easy to take CM database backup and have production version on lower environments happily. I know we can update the mappings after the DB is restored, just need to standardized the backup/restore process.

Question 4

Hi Nuno, can you provide some leads on mapping should be restored/reset?

Question 5

As Nuno mentioned, one of the reasons for putting infrastructure related info in a separate DB (Topology Manager) was to facilitate synchronizing/porting the CM DB across DTAP environments. The idea is that youdon't port the Topology DB or Discovery DBs across environments.

As long as your DTAP Blueprints are in sync, porting the CM DB should be straight-forward and no TTM changes should be needed. Note that you still have to take care of theQUEUE_CONSUMERS (set them offline) in the CM DB.

Indeed, if your BluePrints are not in sync and you created some mappings in one environment which you don't have in the other, you may have to remove those mappings. You should do thatbefore the CM DB port, because I don't think you can remove a mapping to a non-existent Publication at the moment. On the other hand, such a "dead" mapping should not cause problems.

You can remove mappings from Topology Manager usingRemove-TtmMapping in PowerShell.

Question 6

Thanks Rick. Removing mapping for non-existing publication is required. But updating the mapping is also required of the few existing publications which are common on both but have mismatch in TCM in CM and TCM referred in its mapping. I just need a standard process which can be followed for each DB restore activity.

Question 7

As mentioned, once your DTAP environments are in sync, porting the CM DB should be straight-forward (you should no longer have different Publications with the same ID).

Rick Pannekoek 21.5k1 gold badge19 silver badges31 bronze badges · Answer 1 · 2017-01-18 20:02:22Z

As Nuno mentioned, one of the reasons for putting infrastructure related info in a separate DB (Topology Manager) was to facilitate synchronizing/porting the CM DB across DTAP environments. The idea is that youdon't port the Topology DB or Discovery DBs across environments.

As long as your DTAP Blueprints are in sync, porting the CM DB should be straight-forward and no TTM changes should be needed. Note that you still have to take care of theQUEUE_CONSUMERS (set them offline) in the CM DB.

Indeed, if your BluePrints are not in sync and you created some mappings in one environment which you don't have in the other, you may have to remove those mappings. You should do thatbefore the CM DB port, because I don't think you can remove a mapping to a non-existent Publication at the moment. On the other hand, such a "dead" mapping should not cause problems.

You can remove mappings from Topology Manager usingRemove-TtmMapping in PowerShell.

Thanks Rick. Removing mapping for non-existing publication is required. But updating the mapping is also required of the few existing publications which are common on both but have mismatch in TCM in CM and TCM referred in its mapping. I just need a standard process which can be followed for each DB restore activity.
As mentioned, once your DTAP environments are in sync, porting the CM DB should be straight-forward (you should no longer have different Publications with the same ID).

Movatterモバイル変換

Stack Exchange Network

SDL Web8 database restore from Production to QA

1 Answer1

Your Answer

Sign up orlog in

Post as a guest

Related

Hot Network Questions

Subscribe to RSS