4

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

Improve this question
3
  • 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
    – Nuno Linhares ♦
    Commented Jan 18, 2017 at 11:36
  • 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.
    – Sarang Deshmukh
    Commented Jan 19, 2017 at 8:14
  • Hi Nuno, can you provide some leads on mapping should be restored/reset?
    – Sarang Deshmukh
    Commented Jan 24, 2017 at 9:54

1 Answer 1

Reset to default
3

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 you don'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 the QUEUE_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 that before 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 using Remove-TtmMapping in PowerShell.

Improve this answer
2
  • 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.
    – Sarang Deshmukh
    Commented Jan 19, 2017 at 8:32
  • 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
    Commented Jan 19, 2017 at 18:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.