Use PD Azure DNS snapshots to keep a point-in-time record copy before changes. Choose deliberately between a targeted record edit and restoring the snapshot’s supported records; a record snapshot does not capture every Azure setting.

Configure and verify snapshots

1. Open Azure DNS → Settings and review scheduled zone backups.
2. Enable Take scheduled zone backups when required.
3. Choose the interval and retained snapshot count, plus any age-pruning limit.
4. Confirm the normal WHMCS cron is running.
5. Review Backups and the maintenance result to confirm a due snapshot completed.

A saved schedule does not prove the latest edit is captured. Retention can remove older manual or scheduled copies, so review the date you actually need.

Take a current copy

Use the zone’s Back up now action before a significant change. Open its snapshots and check the zone, timestamp and record count. Download the BIND file where useful.

A record snapshot is not a backup of the website, mailbox, app registration, signing keys or registrar delegation. Keep those operational responsibilities separate.

Review the released recovery behaviour

The current restore workflow compares the snapshot’s supported ordinary records with the live zone. It removes later values absent from the snapshot, adds missing values and corrects differing TTLs. Azure’s own SOA and apex nameservers remain provider-owned; review unsupported types and protected managed records instead of treating the file as a copy of every Azure setting.

For an existing zone, restore first requires a successful safety snapshot of its current records. If that snapshot fails, restore stops before changing them. A later write can still fail part-way. Review the removed, added and updated counts and actual live records before retrying or restoring the safety copy.

For a zone confirmed missing in the intended subscription and group, Recover zone on a retained snapshot can recreate the public zone and restore its supported records. There is no current-zone safety copy when no zone exists. Confirm the intended provider/group and zone-create permission first; a missing resource group can require separate preparation by your Azure administrator.

After recovery, check the customer assignment and the recreated zone’s own assigned nameservers. Recreating records does not restore registrar delegation, signing keys, parent DS, websites or mailboxes. Review those separately before returning the domain to service. If the snapshot controls differ on your installation, review available module updates through PD Modules before following the current recovery workflow.

Choose and verify the intended repair

For an isolated mistake, compare the snapshot with the live record and use a reviewed edit in the record editor where appropriate. For broader recovery, your hosting team should review the chosen snapshot, safety copy, intended changes and actual partial result before deciding the next action.

Read back important record sets and verify authoritative DNS, signing/delegation and website/mail operation separately. See the import/export guide for explicit ordinary-record migration.

Check the recovery result

Your hosting team and Azure administrator should compare the chosen snapshot’s provider, subscription/group, domain, time and record count with the intended recovery point. Identify whether restore stopped before changes or after removing, adding or updating records. Check the saved pre-restore snapshot and actual live result before choosing an undo; another restore still needs working provider reads and writes. For missing-zone recovery, verify the intended group, permissions, customer assignment and resulting nameservers.

See the PD Azure DNS WHMCS guide for related tasks, or explore the module.