I have a TDE protected database which I want to extend to Azure using replication. My question is, do I have to restore certificate on the Azure database before I start setting up the database as the subscriber?
do I have to restore certificate on the Azure database before I start setting up the database as the subscriber?
No. Per docs:
"Replication does not automatically replicate data from a TDE-enabled database in an encrypted form. You must separately enable TDE if you want to protect the distribution and subscriber databases. Snapshot replication, as well as the initial distribution of data for transactional and merge replication, can store data in unencrypted intermediate files; for example, the bcp files. "
Transparent Data Encryption and Replication
Related
The RDS User Guide says there are two ways to enable encryption of an RDS instance:
When you create it
You do it through (not shared) snapshot:
you can create a snapshot of your DB instance, and then create an encrypted copy of that snapshot. You can then restore a DB instance from the encrypted snapshot, and thus you have an encrypted copy of your original DB instance.
I want to understand what level this encryption is applied to.
My guess is that the encryption only applies to each cell in the table. Otherwise, if the entire database is encrypted as a whole, then the schema, the table name, the column name cannot be seen, then how can an instance be restored from it?
Is my understanding correct?
only applies to each cell in the table
It does not. Its the entire EBS snapshot that is encrypted.
then how can an instance be restored from it
AWS will use your or AWS managed keys from KMS (AWS Key Managment Service) to decrypt your snapshot. This happens in the background and you don't see it. If you use your own KMS key, and you delete it, then your snapshots can't be decrypted and you loose all your data.
More on the EBS encryption is in How Amazon Elastic Block Store (Amazon EBS) uses AWS KMS
I'm very new to Azure so please don't judge me too harshly.
So, in this project, I've got SQL Server on-premises 'production' database which is the 'master' data. I'm writing a small .NET application that is published on Azure and it is using tables and stored procedures on Azure database. My idea is to have the data in the tables on Azure database up-to-date with the on-premises 'production' database tables.
I've created Sync Group and Sync Agent and it looks like data is flowing accurately from the on-premises Sql Server tables to Azure database tables.
The only problem I have is that when some records on 'prodution' are deleted these records will not be deleted from the Azure tables.
I guess the questions are: What am I missing in synchronization and is it even the right approach to update the Azure database tables using the 'Sync to other databases' tool?
Thanks in advance!
Make sure you have elected the Azure SQL Database as the Hub in your sync group and the on-premise as a member database.
For the Conflict Resolution Policy of the Sync Group, make sure you have selected "Member wins".
According your problem description, since your Azure SQL Data Sync group has be created, we can get that:
Your on-premise SQL server DB is member database.
The Azure SQL database is Hub database.
The Sync Direction of your Sync must be "Member to Hub" or "Bi-directional Sync",
The only problem I have is that when some records on 'production' are deleted these records will not be deleted from the Azure tables.
For your question, I don't think Conflict Resolution Policy can help you solve it.
There isn't a good solution now, I only can give two suggestions for you:
Set Automatic Sync: Off. Sync the data from on-premises SQL
server to Azure manually. This can help your keep
the data in Azure SQL DB for a long time.
Create a new table in Azure SQL database, don't add the new table to
sync group. Copy the data from your synced table to new table. Using the new
table for test.
Hope this helps.
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).
I'm new to SQL Server replication options.
I want to set up a system such that a backup database at a remote location is used for data analysis over some large set of data in the primary database. The analysis does not need to have access to live data, and I want to run this analysis daily.
I don't have access to transaction logging on the primary SQL Server 2008 database.
What is the best way to synchronize a primary database to a secondary one in SQL Server without using transaction logging?
Is there maybe another option I'm not seeing?
Thanks,
You could do one of the following:
Some sort of automated backup, copy and restore.
Use a SSIS job to transfer the data from one to the other.
Use a linked SQL Server, and copy/update as appropriate.
The best solution though, is to use log shipping, scheduled once a day, if you can sort out your access to the primary database.