Using Azure Backup with SQL Server on Azure VM with PSC Dedicated volume
This post details a brief test of Azure Backup for SQL databases. The objective was to evaluate Azure's native backup solution when the SQL Server database, residing on an Azure Virtual Machine, had its data files stored on a Pure Storage Cloud (PSC) Dedicated volume. As a disclaimer, many variations of this test can be done and results may vary, intention here is only to record my recent experience with the technology. The setup I set-up the following environment for the test: PSC Dedicated V20MP2R2 deployed into West Europe region Azure VM Standard D8ds v5 (8 vcpus, 32 GiB memory) running Windows Server 2019 Datacenter gen 2 MS SQL 2019 evaluation edition installed manually on the VM A connection was made between PSC Dedicated and the SQL VM, with MPIO enabled on the VM and one iSCSI session established to each controller. On the PSC Dedicated, I mounted 1TB volume to the host, which I then formatted to NTFS with 64k allocation unit size and mounted as drive F: on the Windows OS. To populate the SQL server with test databases, I made an empty testDB and downloaded 2 sample databases from MS site (AdventureWorks and AdventureWorksLT). The PSC Dedicated volume (F:) was used as the Data Directory of the SQL Server. On the Azure side, Recovery Services Vault (via Backup and Site Recovery from the Marketplace) was created and the VM running the SQL server discovered. The service installs an agent on the VM, enabling it to discover SQL databases instances. Furthermore, an NT Service\AzureWLBackupPluginSvc account used for orchestration of the backup is created on the SQL Server side. The backup For the purpose of the test, I set only a basic policy for all our databases. All three were discovered without issues (along with default ones). Assigning backup policies to databases creates backup items. These can be reviewed on the Azure Portal. Similarly for backup jobs, navigating to the Vault resources allows to review the type of operation (configuration, type of backup etc.) and status. In this case, all completed as scheduled (including an additional manual backup created separately). Another place where it is possible to review the state of the backup is Azure Business Continuity Center. The Restore Testing the restore is a crucial part of any backup, as without that, all we have is a Schrodinger's backup - it might work or it might not. In the testDB I created a small sample table. This only contains a few names as examples. I ran a manual backup of the testDB to capture its current state. Then deleted an item. Bye Bob. Confirmed Bob is gone. Afterwards, I run the restore operation, selecting the manual backup created in the previous step. The restore operation was triggered. And after successful completion, Bob was back. The restore can also be confirmed in the Azure portal. The Summary The testing recorded above indicates the Azures Backup for SQL Server running on Azure VM can be used to discover databases within the SQL instance and help with setting up protection, even if the data resides on an external storage such as Pure Storage Cloud Dedicated. As mentioned in the disclaimer in the beginning of this post however, there may be scenarios that could show different results, so always run tests before committing any decision to production environments.Using Azure Resource Locks with Pure Storage Cloud Dedicated
In any cloud environment, human error is a significant risk to the stability of production systems. A mistaken click in the portal or a misconfigured script can lead to the accidental deletion of critical infrastructure, causing downtime and potential data loss. This is the exact problem that Azure Resource Locks are designed to solve. Think of them as a simple but powerful safety net for your most important Azure resources. When applied to a Pure Storage Cloud Dedicated (PSC Dedicated) managed application, these locks are an essential governance tool. A PSC Dedicated array isn't a single resource but rather a collection of virtual machines, managed disks, and network components working together. Accidentally deleting or altering any part of this managed application could compromise the entire storage array and the applications that rely on it. By applying a lock, you create an intentional barrier, forcing administrators to consciously remove it before making a destructive change. This simple step helps safeguard your mission-critical data, prevent service interruptions, and ensure the operational integrity of your storage environment. Understanding Azure Resource Locks A resource lock prevents users from accidentally deleting or modifying your Azure resources. Even users with the Owner role for a subscription cannot delete or modify a resource if it has a lock applied. There are two main types of resource locks: CanNotDelete (often shown as Delete in the Azure Portal): This lock means that authorized users can still read and modify a resource, but they can't delete it. This is the recommended lock level for the PSC Dedicated managed application. ReadOnly: This lock is more restrictive. Authorized users can only read a resource; they cannot modify or delete it. This lock is generally not recommended for PSC Dedicated, as it can interfere with normal management and scaling operations performed by the Pure Storage support team or by automated processes. Please refer to the Microsoft Learn documentation for more information. How to Apply a Lock to Your PSC Dedicated Managed Application While you can apply locks to individual resources, the best practice for PSC Dedicated is to apply the lock to the entire managed resource group. This ensures all components are protected. Method 1: Using the Azure Portal (The Easiest Way) Navigate to your PSC Dedicated Managed Application: In the Azure Portal, search for and select your Pure Storage Cloud Dedicated instance. Go to the Locks Blade: In the left-hand menu for your PSC Dedicated resource, find and click on Locks. Add a New Lock: Click the + Add button at the top of the Locks blade. Configure the Lock: Lock name: Give your lock a descriptive name (e.g., PSCDedicated-DoNotDelete-Lock). Lock type: Select Delete. Notes: It's a good practice to add a note explaining why the lock is in place. Save the Lock: Click OK to apply the lock to your managed application. Review the Lock is in place Try to delete the PSC Dedicated managed application See that an error message appears, confirming the Lock is in place and does prevent accidental deletion of the Managed application of the PSC Dedicated array Method 2: Using Azure PowerShell For those who prefer a command-line interface, Azure PowerShell provides a straightforward way to manage locks. To apply the lock using Azure PowerShell, use the New-AzResourceLock cmdlet. You will need the following information: New-AzResourceLock -LockName "PSCDedicatedLock" ` -LockLevel CanNotDelete ` -ResourceName "YourPSCDedicatedInstanceName" ` -ResourceType "Microsoft.Solutions/applications" ` -ResourceGroupName "YourApplicationResourceGroup" To remove the lock later, you can use the Remove-AzResourceLock command. Method 3: Using Azure CLI The Azure Command-Line Interface (CLI) is another popular method for managing Azure resources. The process here would be: az lock create --name "PSCDedicatedLock" \ --lock-type "CanNotDelete" \ --resource-group "YourApplicationResourceGroup" \ --resource-name "YourPSCDedicatedInstanceName" \ --resource-type "Microsoft.Solutions/applications" \ --notes "Prevent accidental deletion of PSC Dedicated Managed Application" To remove the lock, you would use the az lock delete command. Final Thoughts Applying an Azure Resource Lock is a simple, no-cost action that adds a powerful layer of protection to your Pure Storage Cloud Dedicated deployment. It's a fundamental step in good cloud governance that helps ensure your critical storage infrastructure remains secure and available. By taking a few moments to configure a CanNotDelete lock, you can prevent a costly mistake and maintain the operational integrity of your environment.Pure Cloud Block Store is now Pure Storage Cloud Dedicated (PSC Dedicated)
Pure Storage Cloud Dedicated: Name Change, Same Enterprise-Grade Experience Pure Storage Cloud is an enterprise-grade block storage delivered as a service in the public cloud. It extends the data services and evergreen architecture of the Purity operating system and can be deployed in: Azure as a fully managed native service or a customer-managed service integrated with Azure VMware Solution (AVS) AWS as a customer-managed service integrated with Elastic VMware Service (EVS) What’s New? Pure Cloud Block Store, the customer-managed service, is being renamed Pure Storage Cloud Dedicated (PSC Dedicated). This change reflects its integration into the Pure Storage Cloud family and alignment with the Enterprise Data Cloud strategy. What’s Not Changing? Everything That Matters Your experience, performance, and features remain the same. Pure Storage Cloud Dedicated continues to provide: Enterprise Data Services: Purity software in Azure and AWS, with data reduction, thin provisioning, and snapshots. Cost Efficiency: Optimized storage usage and reduced footprint through data reduction. Reliability & Resilience: Built-in redundancy, high availability, and cyber resilience. Hybrid & Multi-Cloud Mobility: Consistent APIs and replication across FlashArrays and PSC Dedicated for migration, DR, and data mobility. Disaster Recovery & Backup: Asynchronous and near-synchronous replication, plus snapshots for cost-effective backup and rapid recovery. VMware Workload Support: Enterprise-grade storage for VMware in AVS and EVS environments. Why This Matters The shift from Pure Cloud Block Store to Pure Storage Cloud Dedicated unifies offerings under the Pure Storage Cloud umbrella while advancing the broader Enterprise Data Cloud strategy.
