Justification for performing lower tier farm refreshes using content database

Stephan Bren 271 Reputation points
2020-11-03T02:36:55.9+00:00

Is there a solid justification for performing content refreshes of lower tier farms using full backups of production content databases rather than using exports of production sites?

SharePoint Server Management
SharePoint Server Management
SharePoint Server: A family of Microsoft on-premises document management and storage systems.Management: The act or process of organizing, handling, directing or controlling something.
2,994 questions
{count} votes

Accepted answer
  1. sco gordo 301 Reputation points
    2020-11-05T01:14:35.37+00:00

    Your list is good. DB refresh is common practice and the most efficient. Export/import is a relatively tedious process with more possibility of some type of mismatch. A few things to consider:

    1. Consult with Developers to make sure you're not stomping over development work in Dev or Stage on its way to Production. Schedule ahead of time to allow your team time to consider/review.
    2. If you have several site collections in each content database, make sure they match up in dev/stage/prod, otherwise you might lose (or gain) something in your lower tier environments you didn't want. For example, in Dev, contoso1_content may contain site collections for Intranet, HR, and Accounting. In Prod, it's possible that contoso1_content contains only Intranet, and contoso2_content contains HR and Accounting, with Intranet in a different contentDB. Note that it SHOULDN'T be that way, but worth verifying beforehand to reduce confusion and fire drills.
    3. If you're apply Best Practice with different service accounts/app pool accounts in dev/stage/prod by environment, you'll need to adjust your 'refresher' database to match the 'refreshee's'. Ideally, there shouldn't be many SQL accounts to worry about.
    4. You may also want to be mindful of exposing PII or other sensitive information in lower environments, as rights in lower environments is often broader than in production. eg: the QA team may have access to certain data in the Staging environment they don't have in Production. QA or etc shouldn't need production PII to verify functionality, so you'll need to communicate with Developers to find out which data is sensitive and shouldn't be exposed in the lower environments, and decide who's responsible for removing it after the refresh.

    Otherwise I think you're good.

    1 person found this answer helpful.

0 additional answers

Sort by: Most helpful

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.