Azure VM Backup Considerations (part 2)

By Ashwin Venugopal -

 


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

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning...
Read more