SQL Server Backup and Restore - Simple Talk

Chapter 4: Restoring From Full Backup
It would only take one rogue employee to steal a list of all clients and their sensitive
information to sell to a competitor or, worse, a black market party.
If you work at a financial institution, you may be dealing on a daily basis with account
numbers, passwords and financial transaction, as well as sensitive user information
such as social security numbers and addresses. Not only will this data be subject to strict
security measures in order to keep customers' information safe, it will also be the target of
government agencies and their compliance audits.
More generally, while the production servers receive the full focus of attempts to
deter and foil hackers, security can be a little lacking in non-production environments.
This is why development and QA servers are a favorite target of malicious users, and
why having complete customer records on such servers can cause big problems, if a
compromise occurs.
So, what's the solution? Obviously, for development purposes, we need the database
schemas in our development and test servers to be initially identical to the schema that
exists in production, so it's common practice, in such situations, to copy the schema but
not the data. There are several ways to do this.
• Restore the full database backup, but immediately truncate all tables, purging all
sensitive data. You may then need to shrink the development copy of your database;
you don't want to have a 100 GB database shell if that space is never going to be
needed. Note that, after a database shrink, you should always rebuild your indexes, as
they will get fragmented as a result of such an operation.
• Use a schema comparison tool, to synch only the objects of the production and
development databases.
• Wipe the database of all user tables and use SSIS to perform a database object transfer
of all required user objects. This can be set up to transfer objects only and to ignore any
data included in the production system.
119