Recover a missing PowerDNS zone from a retained PD PowerDNS snapshot. Check that the zone is genuinely absent at the intended server before creating another copy or repeating a timed-out operation.

Confirm what was deleted

Identify the provider, zone name and most recent suitable snapshot. A removed client binding, unreachable API or failed list request is not proof that the provider zone was deleted. Resolve the connection first if its actual state cannot be read.

Keep the intended nameservers and any DNSSEC/parent DS arrangement available for review. A BIND record snapshot is not a backup of secret signing keys or server transfer configuration.

Recover from Backups

1. Open PowerDNS → Backups and select the missing zone’s intended snapshot.
2. Use the available Recover action and confirm the target.
3. Inspect the creation and record-recovery result.
4. Read back the recreated zone’s records and authority information.
5. Verify the client owner, domain/service relationship and allowance.

The released recovery recreates an absent provider zone and restores supported record data. It attempts to restore the remembered owner, but you must verify the binding; it does not promise to reconstruct every previous service relationship. There is no current-zone safety snapshot when the zone was genuinely absent.

Check authority and special settings

Recovery creates an ordinary editable zone. Do not assume a deleted secondary’s transfer role, TSIG arrangement or signing-key state has been reconstructed. Ask the responsible server administrator to review these before treating recovery as complete.

Compare registrar delegation, authoritative answers and actual website/mail behaviour. If recovery stops part-way, retain the exact result and inspect what now exists before repeating it. See the restore guide for the different existing-zone safety behaviour.

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 recovered zone

Your hosting team and PowerDNS administrator should establish that the original zone is absent rather than unbound, hidden by a filter or unreadable because the API failed. Compare the intended snapshot, actual Native zone creation, supported-record result and authoritative answers; verify the remembered owner and domain/service assignment separately. A stopped recovery can leave a recreated zone or earlier changes in place.

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