Keep a known record snapshot before changing a PowerDNS zone. PD PowerDNS supports scheduled and on-demand BIND-format snapshots; check the actual saved result rather than assuming that enabling a schedule created a usable backup.

Take a snapshot now

1. Open PowerDNS → Zones and identify the provider and zone.
2. Use the row’s on-demand backup action.
3. Open Backups and confirm the snapshot’s zone, time and result.
4. Inspect or download the available snapshot data where required.
5. Keep a reference to the intended recovery point before editing records.

For a larger installation, Back up all zones now works through the zone list within a time budget. If its result says there is more to process, use the offered continuation rather than assuming one press finished every zone. Check reported failures in Activity.

Review scheduled work

Review the backup schedule and retention choices in the module’s settings. Confirm the normal WHMCS cron is running, then inspect a recent completed task and actual snapshots. A configured schedule and a successful provider connection are not proof that a particular zone was backed up.

Snapshots preserve record data, not an entire server configuration, secret signing keys or registrar state. Keep those responsibilities with the relevant administrator.

Choose the correct recovery task

Use the existing-zone restore guide to return ordinary records towards a snapshot, including removal of later ordinary values. Use the deleted-zone recovery guide if the provider zone no longer exists.

Download and keep any recovery point your hosting team needs before the configured snapshot count or age policy can prune it. Check the saved copy and review retention before relying on an older snapshot remaining in the module. Deleting a snapshot is separate from deleting live DNS.

Understand the record-data scope

The module reads and exports enabled record members of the types it recognises. Disabled members stored in native PowerDNS are omitted, so a module snapshot or BIND export does not preserve them. Record-set writes rebuild the affected set from enabled members and can remove disabled members of that same set. If your deployment uses disabled records, have your PowerDNS administrator preserve and review the native set through your authorised server process before a module edit, template, import or restore. A module safety snapshot is not a complete native-server backup.

Check snapshot coverage and retention

Your hosting team should compare the intended provider/zone, original backup time, actual stored snapshot and job result with the saved schedule and retention policy. Review normal platform scheduling and any offered bulk continuation; one successful connection or job is not proof that every zone has a snapshot. Preserve a required downloadable recovery point before configured retention can prune it. Do not generate repeated snapshots merely to diagnose an older missing recovery point.

See the PD PowerDNS WHMCS guide for related tasks, or explore PD PowerDNS.