Replacing a Database

If you’re restoring a database to a new server, use the REPLACE option. The REPLACE option removes the normal restore safety check and lets you overwrite an existing database, even one with a different name from the database that you’re restoring. For instance, suppose that Database D was backed up on Server A and will be restored onto Server B. First, create a “placeholder database” on Server B—the size and name are irrelevant. Next, restore the backup of Database D using the REPLACE option on top of this placeholder database. If you’re restoring a database in place—that is, Database D on Server A was backed up and will be restored back onto Server A, then you don’t need to use the REPLACE option. By default, the restore operation has built-in safety checks; for instance, you can’t restore over an existing database with a backup of another database. Nor can you restore a database that’s been using the full or bulk-logged recovery model if no tail-log backup exists.

If you need to restore a database but you haven’t been able to successfully take a tail-log backup (e.g., if the transaction log file was corrupted), then using the REPLACE option might be your only option for a successful restore. Or if you’ve backed up the production version of a database and you want to restore it on your test and development system, then you must use the REPLACE option. Even though the database name is the same on the production and development instance, they’re different databases to SQL Server.

From the Blogs

The quest for the Golden Record to achieve a single, accurate and complete version of a customer record is worth the pursuit to attain survivorship. Record matching and consolidation are only the beginning. Melissa Data takes a new approach. Learn how to apply intelligent rules based on reference data to make smarter and better decisions for data cleansing....More

On SQL Servers where Availability Groups (or Mirroring) isn’t in play, I typically recommend keeping a combination of on-box backups along with copying said backups off-box as well. Obviously, keeping databases AND backups on the SAME server is the metaphorical equivalent of putting all of your eggs in one basket – and therefore something you should avoid like the plague....More

One of the biggest strengths of AlwaysOn Availability Groups is that they allow DBAs to address both high availability and disaster recovery concerns from a single set of tooling or interfaces. But, this doesn’t mean that you won’t still need backups....More