Lesson Learned #108: How the data is purged or destroyed in Azure Database for MySQL.

This post has been republished via RSS; it originally appeared at: Azure Database Support Blog articles.

First of all, in both platforms, PaaS (Azure Database MySQL, Azure SQL Database, Azure Database for PostgreSQL, Azure Database for MariaDB, etc..) and IaaS (Virtual Machine, for example), these services are using an Azure Storage account.

 

All storage accounts are encrypted using Storage Service Encryption (SEE) for data at rest, as you could see in this URL.

 

Additional, you could use Disk Encryption for your Virtual Machine on top of Storage Encryption as we have explained in these two URLs and Azure SQL Database and Azure SQL Managed Instance are using TDE too. 

 

 

When you deleted a storage account there is not possible to restore/recover it that we have explained on these following URLs:

 

 

Besides that the storage account is encrypted, please, review this URL that contains the answer of the about how the data is deleted:

 

"To understand how Azure handles data when it is deleted, let’s first review how data is stored within Azure. For durability and high availability, data within Azure Storage accounts is replicated. Locally redundant storage (LRS) replicates data three times within a single facility within a single region for durability; geo-redundant storage (GRS) is replicated an additional three times in a secondary region. In Azure Storage, all disk writes are sequential. This minimizes the number of disk “seeks,” but requires updating the pointers to data objects every time they are written. A side effect of this design is that data cannot be deleted by overwriting with other data. The original data will remain on the disk, and the new data will be written sequentially. When a customer deletes a storage object (e.g., blob, file, queue, table), the pointer to this object is immediately deleted from the storage index used to locate and access the data. This operation is replicated asynchronously for GRS. With the storage index updated, the data is immediately unavailable. The sectors on the disk associated with the deleted data become immediately available for reuse and are overwritten when the associated storage block is reused for storing other data. The time to overwrite varies depending on disk utilization and activity, but is rarely more than two days. This is consistent with the operation of a log-structured file system. Azure Storage interfaces do not permit direct disk reads, mitigating the risk of another customer (or even the same customer) from accessing the deleted data before it is overwritten."

 

Enjoy!

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.