SQL Server 2016 TDE跨服务器恢复：需备份哪些密钥/证书？

Great question—this is a common point of confusion with SQL Server TDE, so let’s break down the key hierarchy and your specific questions one by one.

Why You Can Restore a TDE Database with Just a Certificate Backup #

First, let’s recap the TDE encryption chain quickly:
Service Master Key (SMK) → Database Master Key (DMK) → Certificate → Database Encryption Key (DEK)

The critical thing to realize here is that your certificate’s exported backup is independent of the source server’s SMK and DMK. When you back up the TDE certificate with its private key (using BACKUP CERTIFICATE... WITH PRIVATE KEY), you’re encrypting the private key with a password you specify—not with the source server’s DMK or SMK.

On the target server, when you import this certificate (using CREATE CERTIFICATE... FROM FILE... WITH PRIVATE KEY), you only need that password to unlock the private key. Once the certificate is installed, SQL Server uses it to decrypt the DEK (which is stored in the restored database), and you’re good to go. The source server’s SMK/DMK never come into play here because the certificate backup breaks free of that local protection chain.

What About When the Certificate Was Protected by Unavailable Master Keys? #

You’re right that on the source server, the certificate is typically protected by the DMK (which in turn is protected by the SMK). But this is just the source server’s internal security mechanism to prevent unauthorized access to the certificate on that server.

When you export the certificate, you’re creating a standalone copy of the certificate and its private key, secured by your own password. This copy doesn’t rely on the source server’s DMK/SMK at all—so even if those master keys are lost or unavailable, the exported certificate backup still works for cross-server restores. That internal encryption layer (SMK→DMK→certificate) is indeed server-internal protection for the source environment, but it doesn’t restrict the portability of the certificate itself when you back it up properly.

When Would You Need to Restore the SMK or DMK? #

While TDE cross-server restores don’t require these, there are scenarios where restoring SMK or DMK is necessary:

• Restoring the Service Master Key (SMK):
  • If the source server’s SMK is corrupted or lost, you’ll need its backup to regain access to all server-level encrypted assets (like DMKs, encrypted credentials, linked server passwords, or other non-TDE certificates).
  • If you’re migrating an entire server’s encrypted ecosystem (not just a single TDE database) to a new server, restoring the SMK can simplify reusing all existing encrypted objects without reconfiguring them.
• Restoring the Database Master Key (DMK):
  • If your database uses additional encryption beyond TDE (e.g., column-level encryption with keys protected by the DMK), you’ll need the DMK backup to access those encrypted columns after restoring the database.
  • If the source database’s DMK was lost or became unavailable, restoring its backup is required to access any database-level encrypted objects it protected.

Is Backing Up SMK and DMK Necessary? #

Absolutely—even if you don’t need them for TDE restores, they’re critical for overall encryption resilience:

• The SMK is the root of all server-level encryption. Losing it means losing access to every encrypted asset on the server, which can be catastrophic.
• The DMK protects database-level encryption objects beyond TDE. If you ever add column-level encryption, encrypted stored procedure credentials, or other database-specific encrypted items, the DMK backup will be essential.
• It’s a best practice to back these up immediately after creating them, and store the backups in a secure, offline location separate from your server.

内容的提问来源于stack exchange，提问作者Tabloo Quijico