Azure Local 2609 Scheduled Backups: PowerShell Setup, Limits and Control Plane Coverage

What changed in Azure Local 2609​

Microsoft's "What's new" page for disconnected operations lists the 2609 additions plainly: "Added support for scheduled backups." The same release also lists usability improvements in OperationsModule, plus support for specifying a template name on certificate generation to override the default template name.

The scheduler builds on backup and restore features that arrived earlier. The "What's new" history shows the restore implementation landing in the Operations Module in 2604. Restore cmdlets and logic were also listed under business continuity and disaster recovery in 2603. Disconnected operations reached general availability in 2602.

In its Tech Community announcement, Microsoft's Azure Arc team says the goal is to reduce reliance on manual backups. A backup that depends on someone remembering to run it can be late or skipped. A schedule means backups happen as part of normal platform operations. Operators can still take extra on-demand backups whenever they want another recovery point.

A note on version labels​

The Microsoft Learn backup how-to ends with a line saying the feature is available only in Azure Local 2602 or later. That can look like it conflicts with the 2609 announcement. It isn't a scheduling-specific claim, though. The same 2602 line appears at the bottom of many disconnected-operations pages, including the update guide, the acquisition guide and the billing page. It marks when disconnected operations as a whole became available. Scheduling itself is listed as a 2609 addition. Before you plan a rollout, check the documentation for the version you actually run.

Section summary: Scheduling is new in 2609. On-demand backup and restore came earlier, and the "2602 or later" line in the docs refers to disconnected operations overall.

What is backed up, and what isn't​

Microsoft Learn says the backup feature currently captures only the control plane virtual machine data. It does not include associated workloads or configured clusters.

The control plane still matters a great deal. The Learn page describes the disconnected-operations VM as the authoritative store of metadata for subscriptions, resource groups, policies and connected Azure Local resources. If it is corrupted or lost, the whole environment is affected. You could think of it as the building's directory and keycard system. Losing it doesn't destroy the offices, but nobody can easily reach them.

A scheduled control-plane backup does not protect your workload VMs or cluster data. Those still need their own backup plan.

Prerequisites​

Microsoft Learn lists these requirements before any backup work:

• Operator access: an identity with the OperatorRP RBAC role in the Operator subscription.
• SMB share: a backup target that the disconnected-operations VM can reach.
• Encryption certificate: stored outside the environment and supplied during backup. Microsoft recommends Azure Key Vault in global Azure, in the same subscription as the disconnected-operations instance registration.
• Backup module: import Azure.Local.Backup.psm1 from the Operations Module using its full path.
• Client context: run az cloud set --name Azure.Local, sign in with az login, and select the Operator subscription with az account set. Then run Set-ApplianceClientContext with the ManagementEndpointClientAuth.pfx certificate, its password and the management endpoint IP.

One 2609 issue may come up while you prepare certificates. Microsoft's known-issues page says that generating certificates with the Operations Module causes issues when the CA common name contains a space. The listed mitigation is to open a support case from the Azure portal to get a fix.

Step 1: Choose or create a backup configuration​

A backup configuration sets two things: the destination SMB share and the encryption certificate. There are two kinds:

You create or update a configuration with Set-ApplianceBackupConfiguration. Its required inputs are -Path (a UNC path such as \\server\share), -UserName, -Password as a SecureString, and -EncryptionCertBase64. Configuration names may contain letters, digits, periods, underscores and hyphens, but no spaces. Microsoft says you can create as many named configurations as you need, for example one per destination share.

Watch the reserved name. default is the single global configuration. If you change it, you also change where every on-demand backup goes. For that reason, a separate named configuration for scheduled backups is usually the safer choice.

You can review configurations with Get-ApplianceBackupConfiguration, adding -Name for a named one. You remove them with Remove-ApplianceBackupConfiguration -Name "nightly".

Step 2: Create the schedule​

Set-ApplianceBackupSchedule takes these parameters:

• -Enabled: $true to run the schedule, or $false to keep it configured but paused.
• -Frequency: TwiceDaily, Daily, Weekly or Monthly.
• -TimeOfDayUtc: a 24-hour TimeSpan such as "02:00:00", within [00:00:00, 24:00:00).
• -DayOfWeek: required for Weekly and valid only with it.
• -DayOfMonth: an integer from 1 to 31, required for Monthly and valid only with it.
• -BackupConfigurationRef: default or a named configuration.

Microsoft's documented examples:

Set-ApplianceBackupSchedule -Enabled $true -Frequency Daily -TimeOfDayUtc "02:00:00" -BackupConfigurationRef "nightly"
Set-ApplianceBackupSchedule -Enabled $true -Frequency Weekly -DayOfWeek Sunday -TimeOfDayUtc "02:00:00" -BackupConfigurationRef "nightly"
Set-ApplianceBackupSchedule -Enabled $true -Frequency Monthly -DayOfMonth 1 -TimeOfDayUtc "02:00:00" -BackupConfigurationRef "nightly"

All times are in UTC. If you enter "02:00" thinking of local time, the backup may run in the middle of your workday.

Each system has one schedule, and running the cmdlet again replaces it. You cannot have a daily schedule and a separate monthly schedule side by side.

What success looks like: the cmdlet returns the saved schedule with provisioningState: Succeeded and a nextPlannedRunAtUtc value. That value tells you when the next backup will run. It does not confirm that any backup has completed.

Step 3: Manage the schedule​

• Get-ApplianceBackupSchedule shows the current schedule and its next planned run.
• Disable-ApplianceBackupSchedule pauses the schedule but keeps its definition. enabled becomes false and nextPlannedRunAtUtc is cleared.
• Enable-ApplianceBackupSchedule resumes it and recalculates the next run.
• Remove-ApplianceBackupSchedule deletes it.

Step 4: Check that backups actually complete​

Backups run in the background. Get-ApplianceBackupOperationList lists backup operations, and scheduled runs appear in the same list as manual ones. Each entry has an isScheduledBackup property: true means the scheduler started it, and false means someone ran Start-ApplianceBackup. Wait-ApplianceBackupOperationComplete follows a specific operation until it finishes. Get-ApplianceBackup -BackupId <ID> shows the details of a single backup.

On-demand backups are still useful for a known recovery point before an update or configuration change. Microsoft recommends backing up regularly and before making changes. A manual backup with Start-ApplianceBackup always goes to the default configuration, wherever the schedule points.

Troubleshooting​

If a backup command returns "Unable to connect to the remote server," Microsoft's documented fix is to run the command again with -ExternalDomainSuffix set to your external domain suffix. The documentation's example value is autonomous.aldo.private. Use this only when you see that error. It is not a general requirement.

Limits to keep in mind​

Microsoft's materials do not cover several things operators will want to know:

• Retention: the documentation doesn't say how long backups are kept or whether old ones are pruned. Plan for SMB share capacity yourself.
• Alerting: nothing is documented about notifications when a scheduled run fails. Someone needs to check the operations list.
• RPO guarantees: a twice-daily schedule caps how frequent your recovery points can be, but it is not a service-level guarantee.
• Restore testing: restore is covered in its own Microsoft Learn article, along with a post-restore rehydration overview. A backup you've never restored is still unproven.

Bottom line​

For sovereign and air-gapped Azure Local deployments, scheduled backups add something the platform needed: regular control-plane recovery points that don't depend on someone remembering a manual task. The main points:

• It's one UTC schedule per system, managed in PowerShell.
• A named configuration keeps scheduled backups separate from the default used by manual backups.
• Only the control plane is covered. Workloads and clusters need separate protection.

Before you rely on it, check your deployed version, set up and secure the SMB share and encryption certificate, monitor that backups finish, and run a test restore.