none
Copying Content DB's to another farm RRS feed

  • Question

  • I am pretty sure I know the answer to this .. I am just looking for a little assurance.

    We currently have a production and a stage farm that are essentially setup the same way (same web apps though prod uses CNAMES where as stage we are connecting to different ports) Same Content DB's  etc.. however over the course of time and many site collection migrations that weren't put into the same content db's as production .. stage is now considerably messy.  We are looking to refresh via doing the following..

    Take backups of all content dbs in stage

    Remove the content db from stage through ca

    Copy over previous nights SQL backups of the content db's to stage

    Restore over the existing stage content db with the production backup for the same content db

    re-associate that content DB with the web application again via add a content database.

    Is this pretty much the procedure?  I would just rather restore 10-12 db's as opposed to 150 site collections, to get all the data in sync.   Will this create issues if say

    /sites/siteA   is in ContentDBA  in production but because of some deletions and messery /sites/siteA is in ContentDBF  in Stage..

    Thank you for taking the time to ready and reply!

    Wednesday, November 20, 2013 9:26 PM

Answers

  • Yes, that method is appropriate (use Mount-SPContentDatabase in staging to attach the databases).

    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    • Proposed as answer by Scott Brickey Wednesday, November 20, 2013 9:29 PM
    • Marked as answer by Jason Spatz Thursday, November 21, 2013 9:24 PM
    Wednesday, November 20, 2013 9:29 PM
    Moderator

All replies

  • Yes, that method is appropriate (use Mount-SPContentDatabase in staging to attach the databases).

    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    • Proposed as answer by Scott Brickey Wednesday, November 20, 2013 9:29 PM
    • Marked as answer by Jason Spatz Thursday, November 21, 2013 9:24 PM
    Wednesday, November 20, 2013 9:29 PM
    Moderator
  • Thanks Trevor for the quick reply!

    Thursday, November 21, 2013 9:24 PM
  • We've used this same technique with success.

    A few notes from our experience:

    • You should temporarily disable search on the staging environment by removing search indexing schedules prior to dismounting the databases. After everything is remounted, add the search indexing schedules back in, reset the search index, and start a full crawl (assuming you want search to work in your staging environment and don't want to spam your logs with error messages).
    • Similarly, if you have any scheduled tasks that interact with SharePoint on the staging server, you should disable them prior to the refresh and re-enable them after the refresh has completed.
    • If there are feature/solution differences between prod and staging, you should uninstall any solutions from the staging farm that have not been installed in production prior to remounting the databases. And vice versa, any solutions installed only on the prod farm should also be installed in staging. (Although you can have exceptions to this, such as licensed 3rd party solutions that you don't want or can't have in your staging environment.)
    • If you have a second set of service accounts specifically for your staging area, you'll want to ensure they have the necessary access after the database refresh.

    Thursday, November 21, 2013 11:42 PM