Azure VM Backup Considerations (part 2)

 


To read part 1 please click here 



SQL Server Backup

SQL server can be backed up by using the following:
  • Performing conventional SQL Server backups onto direct attached Azure disks- Through this approach you can easily have the backups available swiftly for system refreshes and build up of new systems as copies of existing SAP systems. You should either use Azur Backup Services or another third party backup/recovery tool that includes access and retention management for your backups.

  • SQL Server backup to URL- Starting with SQL server 2012 CU4, the native SQL Server backup can designate an Azure storage URL and its destination.

  • Automated backup v2 for Azure VMs- This one uses SQL IaaS Agent Extension to automatically configure Managed Backup to Azure storage for all existing and new databases on an Azure VM running SQL server 2016/2017 Standard, Enterprise or Developer editions.

  • SQL Server backup in Azure VMs- It extensively uses AzureBackupWindowsWorkload VM extension, which leverages the SQL native APIs to backup of your SQL databases into Azure Site Recovery Vault.

  • File-Snapshot backup for Database Files in Azure Blob Storage- This method only works when your SQL Server Data and log files are located on Azure Blob storage while offering nearly instantaneous backups and restores for database files stored using the Azure Blob storage service which in turn allows you to simplify your backup and restore policies as well as supporting point in time restore. This feature is readily available in SQL Server 2016 or later. 

SQL Server File-snapshot Backups

A file-snapshot backup consists of a set of Azure snapshots of the blobs containing the database files plus a backup file containing pointers to these file-snapshots. This approach can be used for both full database and transaction log backups:
  • Full database backup- It creates an Azure snapshot of each data and log file comprising the database, establishing the transaction log backup chain, and writes the location of the file-snapshots into backup file.

  • Transaction log backup- It creates a file-snapshot of each database file (not just the transaction log),records the file-snapshot location information into the backup file, and truncates the transaction log file.

Considerations & Limitations

  • Premium storage- The following limitations apply while using this one-

  1. The backup file itself cannot be stored using premium storage.
  2. The frequency of backups should be no shorter than 10 minutes.
  3. The maximum number of snapshots that you can store is 100.
  4. RESTORE WITH MOVE is required.

  • Single storage account- The file-snapshot and destination blobs must use the same storage account.

  • Bulk recovery model- You cannot use a log restore using the transaction log backup while using bulk-logged recovery mode and working with a transaction log backup consisting of minimally logged transactions, instead, you can perform a database restore to time of the file-snapshot backup set. This limitation is identical to the limitation with streaming backup.

  • Online restore- When using file-snapshot backup, you cannot perform an Online Restore.

  • Billing- Additional charges will be incurred as the data changes while using the SQL Server file-snapshot backup.

Oracle Backup

The SAP BR*Tools for Oracle are supported in the same way as they are in on-premises scenarios for backup/re store functionality while also supporting the Oracle Recovery Manager (RMAN) for backups to disk and restore from disk.

The Oracle DBMS releases that are supported on Azure by SAP can leverage the VSS functionality for backups.


To read part 1 please click here 

Comments

Popular posts from this blog

Query, Visualize, & Monitor Data in Azure Sentinel

Work with String Data Using KQL Statements

Threat Hunting in Microsoft Sentinel (part 1)