We recently got a new server, so we tried moving our database over (made a backup of it). I have an encrypted column in one of the tables, however, and when we tried this migration technique the master key was deleted. Is there a way to copy over the database to the new server without losing all the information for my encrypted column? (master key, certificate, symmetric key, etc.).
The master key was not deleted - it is not moved when you move the encrypted database. You need to back it up from your old server and then restore it to the new server. Here are some links to help you backup and restore the master key:
http://msdn.microsoft.com/en-us/library/ms174387.aspx
http://msdn.microsoft.com/en-us/library/ms186336.aspx
Related
I followed digital ocean guide to make my server as master database and my local as secondary databse.
There two problems I see
I can not subscribe to master database if same schema is not present in my local database
For temporary purpose I cloned the schema then subscription worked!!
I got all data and even updating any column reflects in local db as well.
I created new table in master database it stopped replication, not new table copied and new updates to existing data is also not working
I need help in these two issues.
I'm setting up an Azure SQL DB for our Web App. We have enabled Point In Time Retention (PITR) and Long Term Retention (LTR). Our process is to keep backups for 1 year.
Periodically, we need to upgrade the DB by applying SQL scripts. Sometimes there is a problem with the upgrade scripts and the upgrade fails. We need to rollback the database to the previous version.
To rollback the DB I tried the restore feature. However, the restore feature seems to only create new DBs; therein lies the problem. Restoring to a new DB and removing the old one works great, but we lose all our backup history. It appears backups are tied to the DB (probably to the ResourceId).
So, how can I use Azure SQL DB and periodically restore a DB and still maintain all the back up history?
Unfortunately, restoring from a backup in Azure SQL Database always creates a new database. The secret here may be to rename the newly restored database with the name of the original database. You will even see that the restored database once renamed it then shows all the security recommendations, automatic tuning recommendations of the original database.
So delete existing database, restored the database, and rename it as the original database.
You can reference this document Recover an Azure SQL database using automated database backups , it gives the answer that all the recover are creating new database.
By default, SQL Database backups are stored in geo-replicated blob storage (RA-GRS). The following options are available for database recovery using automated database backups:
Create a new database on the same SQL Database server recovered to a specified point in time within the retention period.
Create a database on the same SQL Database server recovered to the
deletion time for a deleted database.
Create a new database on any SQL Database server in the same region
recovered to the point of the most recent backups.
Create a new database on any SQL Database server in any other region
recovered to the point of the most recent replicated backups.
If you configured backup long-term retention, you can also create a new database from any LTR backup on any SQL Database server.
improtant:
You cannot overwrite an existing database during restore.
"So, how can I use Azure SQL DB and periodically restore a DB and still maintain all the back up history?"
You can use Database replacement:
If the restored database is intended as a replacement for the original database, you should specify the original database's compute size and service tier. You can then rename the original database and give the restored database the original name using the ALTER DATABASE command in T-SQL.
Hope this helps.
I have a lack of understanding regarding a particular area of TDE within Microsoft SQL Server (in my case, SQL Server 2016). Specifically what certificates/keys are required to restore an encrypted database on another server.
Microsoft Docs highlight the encryption hierarchy, running from service master key, database master key, certificate and database encryption key. It highlights the necessity of creating backups of the certificate to prevent data loss. It doesn't really mention anything of backing up anything above the certificate in the hierarchy.
However a Redgate article describes backing up the service master key and database master key in addition to the certificate.
In practice I am able to restore an encrypted database on another server using only the saved certificate/private key.. so what am I missing? If the certificate is protected by a master key that is not available, how does it work? Is that part of the encryption 'internal-only' - if so is there any instance where I would need to restore the service master key or database master key from a backup? I suppose keeping a backup of those wouldn't hurt anyway?
Many thanks
I've successfully restored a TDE-encrypted database onto a server that has only the certificate that was used for TDE. Said another way, the destination server had neither matching a matching database master key (DMK) on the master database nor a matching service master key (SMK). So long as the DMK for the master database is encrypted with the SMK on the target and the TDE certificate's private key is loaded into master and encrypted with that DMK, you should be good to go.
But! For something like this, you shouldn't take my (a random guy on the internet) word for it. This fundamentally affects your ability to restore your database. Restore-ability is Job One™ for a DBA, you should try it and convince yourself that not only what I'm saying is true but also that you can do it.
Also, as part of that restore plan, take that certificate (along with its private key), back it up to disconnected media, and put it somewhere for safe keeping (I like to give it to the legal department).
Problem Statement :
We two database server (SQL01 & SQL02). Lets assume SQL01 is my primary server and SQL02 is secondary server. My primary database server contain around 100 databases and SQL02 is connected to SQL01 as the fail over server. For our test we have taken the back up of the physical mdf and ldf file on the primary server. And after every test we reset the database (replacing the mdf and ldf file with the files after teenter code herest).
Now to make them in sync on the secondary server we are doing manually three steps
Remove the databases from HA group from primary server.
Drop the database on Secondary server
Add them back to HA on primary server.
So for the first step we are doing it from SQL server management studio, Windows application and sometime we are using the following script
USE [master]
GO
ALTER AVAILABILITY GROUP [PERFAG02]
REMOVE DATABASE [db1];
GO
can someone help me with procedure which can remove them in one go. Although I am not expert in database.
Im wondering something regarding this article:
https://learn.microsoft.com/en-us/azure/sql-database/sql-database-manage-application-rolling-upgrade
We would like to perform a database upgrade involving ~3 million records in a table. The upgrade will add an extr column to the mentioned table, which can take up to 5 minutes to complete.
In short, Microsoft suggest creating a transactionally consistent database copy of the target database, perform the database upgrade/migration and switch users to that copy using a load balancer.
This seems all and well, but records created in the original database will not be present in the upgraded/migrated database copy.
Turn the primary database to read-write mode and run the upgrade script in the stage slot (5). - is what the article suggest.
If the primary database is read-write mode, won't i be missing data in the upgraded/migrated copy of the primary database once i point everyone to the new database?
For example: would it be possible to sync database records from the primary to the secondary once the secondary is upgraded and front-end users are pointed to the secondary database?