PD DNS Manager can keep BIND-format snapshots of a zone’s records. Use them to preserve a known record set before changes, while treating DNS recovery separately from a website, mailbox, provider-account or security-settings backup.

Before a change, confirm the provider connection and the actual zone it resolves. With Route 53, name-based operations resolve the first matching hosted-zone name; selecting a familiar domain is not sufficient when AWS holds multiple zones with that name. Have your AWS administrator compare the hosted-zone ID, records and assigned nameservers before proceeding. With Google Cloud DNS, the current connection derives the managed-zone name from the domain. An existing zone with a different native name can appear in a list yet fail to open correctly; establish that mapping with your Google Cloud administrator instead of creating a duplicate zone.

For a PowerDNS backend, module reads and zone-file snapshots omit disabled native record values. Editing an affected record set can rebuild it from the enabled values. If your hosting team uses disabled records, preserve and review the native record set with your DNS administrator before module changes; use your established native management process where those values must be retained. A module export is not a complete backup of those disabled values or other provider settings.

Configure scheduled snapshots

1. Open DNS → Settings and enable Take scheduled zone backups if required.
2. Choose Back up each zone every (hours).
3. Set Snapshots to keep per zone and the optional age-pruning setting.
4. Check that the normal Blesta cron is running.
5. Review DNS → Maintenance and Backups to confirm a due snapshot actually completed.

A schedule is not evidence that the latest change was captured. Retention can remove older snapshots, including ones you might otherwise want for recovery.

Take and inspect a copy

Under DNS → Backups, use Back up now for the intended zone or Back up all zones now when that is the intended scope. Open the resulting snapshot and check its zone, date, source and record count. Download a copy where useful.

Customers can have their own Backups page when the backend and client-backup setting allow it. Check ownership and the available controls before asking a customer to restore anything.

Restore records or recover a missing zone

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. Provider-owned SOA and apex nameservers remain separate; review skipped unsupported types and protected managed records rather than treating the snapshot as a copy of every provider setting.

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

For a zone confirmed missing at the intended provider, Recover zone on a retained snapshot can recreate the zone and restore supported records. There is no current-zone safety copy when no zone exists. Check zone-creation permission and the backend’s prerequisites first; a control-panel backend may need an address or account configuration that a DNS-only provider does not.

After recovery, verify the customer assignment and the recreated zone’s own nameservers. Records alone do not restore registrar delegation, signing keys, parent DS, websites or mailboxes. If your installation shows older snapshot controls, review available module updates through PD Modules before following this recovery workflow.

Verify the service after recovery

Check important website, mail and verification records, delegation and any signing state. Restore of record data does not prove a proxy, forwarding service or HTTPS certificate was recovered. Keep the safety copy until the intended service is verified, and use the import guide when the required operation is an explicit record import.

Check the snapshot and restored records

Your hosting team should compare the snapshot’s provider, zone, time and record count with the intended recovery point. Identify whether restore stopped before changes or after removing, adding or updating records. Compare the safety copy with the live result before choosing an undo. For a missing zone, confirm the correct provider, creation prerequisites, customer binding and resulting nameservers.

See the PD DNS Manager Blesta guide for related tasks, or explore the module.