TDE is not enabled on MI by default. I had manually enabled TDE by setting the encryption to true in the db properties. Encryption of the DB took around 20 mins and below is the output from the sys.dm_database_encryption_keys table.
How do we verify if TDE is enabled in Managed instance or not? As neither Azure provides access to automated backups of MI nor i can manually take the backup when the TDE is turned on in MI.
Would like to access the automated backups (7day backup feature) and verify the files can be restored or not. Provide the procedure.
Hoping the backups are encrypted as TDE is enabled on my DB, so how can these be decrypted as Azure is not providing any keys to decrypt.
Use the following query to find encrypted database:
select name, is_encrypted from sys.databases
You cannot directly access backup files; however, you can run point-in-time restore to verify that any previous backup can be restored as a new database (you have restore button on the portal for each database or you can use PowerShell see - https://blogs.msdn.microsoft.com/sqlserverstorageengine/2018/06/28/point-in-time-restore-of-a-database-on-azure-sql-managed-instance-using-azurerm-sql-powershell-library/)
Point-in-time restore is the only way to restore encrypted automatic backups and Azure automatically de-crypts the backup on restore. You cannot restore backup from MI on SQL Server because MI is always higher version than SQL server. Therefore, even if you de-crpt the backup file you cannot use it on SQL Server, and if you want to restore it on Managed Instance, MI will find the key.
Related
I need to be able restore Azure SQL Server databases from one subscription to another (example: Prod to Dev environments that exist in different subscriptions). The databases will have TDE enabled. What is the implication with respect to TDE for the following two scenarios:
Azure SQL databases (PaaS)
SQL databases hosted on Azure VMS (IaaS)
TDE is enabled by default for Azure SQL databases.
We plan to enable TDE on the SQL databases hosted on Azure VMs.
Will there be any issues?
If any issues, how can we mitigate such that the data in the restored data is accessible in the form that it was in on the source servers (and is not in some encrypted state that is not useable).
Similarly, what is the implication with respect to PaaS and IaaS databases that have TDE enabled with DR scenarios where data needs to be accessed in a secondary region.
Thank you.
To restore a TDE-encrypted database to another SQL Server, you need to first restore the certificate to the destination server.
When moving a TDE protected database, you must also move the certificate or asymmetric key that is used to open the DEK. The certificate or asymmetric key must be installed in the master database of the destination server, so that SQL Server can access the database files. For more information, see Transparent Data Encryption (TDE).
You must retain copies of both the certificate file and the private key file in order to recover the certificate. The password for the private key does not have to be the same as the database master key password.
To restore, you need the following permissions:
Backup Operator permissions in the vault where you're doing the restore.
Contributor (write) access to the source VM that's backed up.
Contributor (write) access to the target VM:
If you're restoring to the same VM, this is the source VM.
If you're restoring to an alternate location, this is the new target VM.
For more details and step-by-step implementation, refer Restore SQL Server databases on Azure VMs
I've got a handful of databases running on a SQL Server instance. I don't have access to be able to install the Azure Backup agent but I do have connection details and credentials to access the database and perform backups in SQL Server Management Studio.
What I want to do is be able to perform and schedule these backups and save them in to Azure Blob Storage. I could have this schedule running on my local computer but that's not an ideal solution.
I've got a powershell script that will perform this action for me but it relies on SQL Server assemblies to run. I've tried running this as a devops build task but am unable to do so without the assemblies it requires.
Does anybody know a way of setting this up? In azure for example? Is there a resource that will allow me to connect and backup a sql instance via connections string and save down to blob storage. Or an azure function perhaps?
Is there a resource that will allow me to connect and backup a sql instance via connections string and save down to blob storage?
I'm afraid the answer is no.
We can't find any API support in Azure to help you achieve that.
I think the SQL Server Management Studio and powershell script is more suitable for you.
Maybe you can think about using third-party tool SQL Backup and FTP, it can help you schedule backup the SQL Server to Azure Blob Storage.
Hope this helps.
We use Azure as infrastructure for our app and its SQL DBs.
Currently Azure provides automatic backups for all tiers (Basic to Premium), but these settings are individual per DB.
How can I set backup for the entire server, with all DBs inside?
Actually, backups are configured on database level. When you backup all of your databases, the database server is considered backed up. More information on the topic: Azure SQL Database Backup and Restore
I have a large database in an AWS instance running SQL Server 2008 on a Windows Server 2008 R2.
The database is constantly changing and writing information, and its size is about ~100GB
I wish to migrate from our Amazon services to Microsoft Azure.
But I cannot afford any lost of information more them for more than 20-30 minutes
I don't mind using the Azure SQL or running a SQL Server under a VM in Azure Cloud, but I must keep the databases live and updated, there are few main tables that information is being added to them constantly
What would be the best way to do so ?
if you are using an AWS instance and not RDS and you are going to an Azure instance and not "Azure SQL Database" you can use log-shipping or something similar to get the downtime down to a few seconds: http://msdn.microsoft.com/en-us/library/ms187103.aspx
The steps you need to take:
Take full backup on AWS
restore full backup without recovery on Azure
take log backup on AWS
restore log backup without recovery on Azure
repeat 3 and 4 until the time it takes is short enough (you probably want to script this out)
take app offline
take another log backup on AWS
restore that log backup WITH recovery on Azure
repoint App to Azure
bring App online again.
3, 4 and 5 is what log-shipping would automate, but you could just write a powershell script too.
Asking this question for a friend of mine.
My client had send me a Back up file of a database in SQL Server 2008.
I installed SQL Server 2008 Express Edition.
Then i tried to Restore the given Back file with this but unfortunately its throwing an error
"The media family on device is incorrectly formed . SQL Server can not process this media family.RESTORE HEADER ONLY is terminating abnormally .(Microsoft SQL Server, Error 3241)"
I searched for this error and evry where they says may be the back up might be corrupted.
But my client is able to restore the same at their end.
Any idea?
Have you applied the latest service packs to your copy of SQL Server 2008? Try that, and then do a RESTORE HEADERONLY command in Sql Enterprise manager. That will give you the properties of the file you're trying to backup. Is your client using Express Edition as well?
It is possible that the backup file became corrupt during transit.
I would suggest that the client either:
re-send the database backup file
or create another one.
It may also be pertinent to suggest to the client that when creating the Database Backup they use the CHECKSUM option to validate the contents of the backup file that is produced.
CHECKSUM
Enables backup checksums, so that BACKUP can do the following:
Prior to writing a page to the
backup media, BACKUP verifies the
page (page checksum or torn page),
if this information is present on
the page.
Regardless of whether page checksums
are present, BACKUP generates a
separate backup checksum for the
backup streams. Restore operations
can optionally use the backup
checksum to validate that the backup
is not corrupted. The backup
checksum is stored on the backup
media, not on the database pages.
The backup checksum can optionally
be used at restore time.
References
SQL Server Books Online - Backup Database