Use a saved PD PowerDNS snapshot to restore an existing editable zone’s ordinary records. This operation can remove later records and change TTLs, unlike an additive BIND import.

Review the recovery point

Identify the correct provider, zone and snapshot time. Compare changes made since that point and confirm which ones should be undone. Consider website, mail and verification dependencies before restoring a live zone.

Restore and inspect

1. Open PowerDNS → Backups and choose the intended snapshot.
2. Review its target and use the restore action deliberately.
3. Confirm that the current-zone safety snapshot succeeds.
4. Inspect the reported additions, removals, TTL updates and any skipped or failed work.
5. Read back the actual zone and check the affected public services.

For an existing zone, the module first takes a safety snapshot and refuses the restore if that fails. It then compares saved and live records, removes extra ordinary values, adds missing values and corrects relevant TTLs. Provider SOA/apex NS and protected managed records are preserved; unsupported record types can be skipped.

This restores supported record data, not server replication settings, signing keys, registrar delegation or every external dependency. Do not use a transferred secondary as an ordinary editable recovery target.

Handle a partial result

A provider error can stop the restore part-way. Review the actual result and current records before doing anything else. The safety snapshot provides an earlier recovery point; it does not mean the module automatically rolled back a failed restore.

Retain both snapshot references, original action time and redacted error while your hosting team checks the actual recovery outcome. Use the deleted-zone guide when the provider zone itself is absent.

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 the restored records

Your hosting team should compare the intended provider/zone and original recovery point with the successful safety-snapshot reference, restore counts and actual current record sets. The restore can remove later values, change shared TTLs and stop after earlier mutations; a safety snapshot is a further recovery choice, not automatic reversal. Read back an uncertain API result before another change.

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