Use PD Cloudflare DNS backups to preserve a zone’s DNS record state before a planned change. Review the selected snapshot carefully before restoring: a restore makes the live record set match that snapshot, rather than simply adding missing records. Provider-owned SOA/nameserver records and protected forwarding-managed records are exceptions; review the actual result rather than assuming every record was replaced.

Configure scheduled backups

1. Open PD Modules → Cloudflare DNS → Settings → Backups.
2. Review Take scheduled zone backups, the backup interval, snapshots retained per zone and any age cap.
3. Save the intended retention policy.
4. Review Maintenance and the backup job’s last result rather than treating a saved schedule as a completed backup.

Count-based and age-based retention can both remove older recovery points. Keep the interval and retention aligned with the changes you need to recover from.

Take and inspect a snapshot

From Zones, open the intended zone’s ⋯ → Back up now. Then use Backups or the zone’s Snapshots action to check the zone name, date and available snapshot. Use Download .zone file when you need a copy outside the module.

A backup of DNS records is not a backup of website files, mailboxes or all Cloudflare features. Preserve any other configuration separately when planning a broader migration.

Restore the intended state

1. Review the live zone and preserve any current changes you still need.
2. Open the correct snapshot and choose Restore snapshot.
3. Read the confirmation: records added since can be removed, changed records restored and missing records re-added. Provider-owned SOA/nameserver records are left alone.
4. Confirm once, then inspect the operation result and final records.
5. Verify affected DNS answers, proxy settings and web/mail services after recovery.

For an existing zone, the module takes a safety snapshot before changing records and refuses the restore if that snapshot cannot be taken. A restore can still stop part-way after removing, adding or updating records. Keep the original operation result and safety-snapshot reference, compare the current zone with the intended state, and choose any recovery action deliberately. There is no automatic rollback merely because an error appeared, and external resolver answers may remain cached after records change.

Recover a missing zone separately

Recover zone on a stored snapshot creates a missing provider zone and restores its records. Zone creation needs appropriate provider account/resource authorisation, and a recreated zone may still need DNS delegation checked. Recovery is not the same operation as restoring records inside an existing live zone. There is no pre-restore live-zone snapshot when that zone no longer exists. Compare the recreated zone’s assigned nameservers with the domain’s current delegation before considering recovery complete.

If the outcome is uncertain, keep the snapshot reference, action time and latest result. Compare the actual live records and any reported added/removed/updated counts using your own Cloudflare access. Do not import an unrelated file or repeat a restore merely to see whether the error disappears.

Check the recovery result

As the hosting team, distinguish a missing snapshot, a refused safety snapshot, a failed zone recreation and a restore that stopped after changing records. Compare the selected snapshot, intended provider/zone, current records and latest Activity using your own access. For a recreated zone, also check delegation separately from record restoration.

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