If you are working on Azure, as a standard practice for governance and security, your cloud team may require you to create and maintain separate Azure subscriptions for production, development, and test environments. Separate Azure subscriptions provide optimal isolation and control between environments to ensure that administrators or operations team members restrict access to production environments while developers get the freedom to create, delete, and break things at their will in their own contained environment without any risk of impacting production. This strategy works very well and is widely adopted by Azure customers.
A challenge our customers often encounter with this approach is the inability to restore production databases in different Azure subscription. Restoring production database on developer subscriptions may be required for troubleshooting production issues or simulating a production-like environment in testing. Most Azure data services, including Azure Database for MySQL, don’t allow for restoring database backups across Azure subscriptions. This is an intentional choice made by our engineering team to ensure data security, as subscriptions are strongly honored as tenant boundary. To address this, many of our customers rely on logical backup solutions such as mysqldump to extract data from a production server and restore it in the developer environment, but the process is time- and resource-intensive, and it cannot scale. The good news is that there is better way to accomplish this that can save you time and additional compute resources as you leverage built in automatic backups and resource movement across subscriptions.
To achieve this, you can use the following process.
Perform a Point-in-time Restore of the server in the same Azure subscription – You can restore from the automatic backups of the production server in the same Azure subscription but in a separate resource group by using the Azure portal or Azure CLI.
Prepare the restored server for developer access – Your production database may contain sensitive customer information or business data that for security reasons you may not want to expose to developers. In this scenario, you can run your custom data masking script on the restored database to delete, hide, or obfuscate sensitive data. In addition, the production server may not have developer logins, so you may want to create logins to allow developers to connect to the restored server and delete any unwanted logins that may not need access to this server. In summary, in this step, you would prepare the server before opening it for developer access. While this step is recommended it may not be generally required and can be omitted.
Move the restored Azure Database for MySQL server to developer subscriptions – Azure Resource Manager (ARM) allows you to move resources to a new subscription or resource group. You can leverage this feature to move the restored Azure Database for MySQL server to your intended Azure subscription using the interface shown below:
After you complete the move of restored server, the server will be ready and available for developers’ use.
While using this approach might require a few additional steps, it helps to provide an additional layer of security and governance than do providing production access to your developers. You can also script the additional steps using Azure CLI if this a recurring operation in your environment and you periodically need to restore your production databases in developer environments.
We hope you find this approach useful should you have to go through this drill!!!
Special thanks to Sundeep Kambhampati, Sunil Agarwal, and Jim Toland for their contributions to this posting.