Restore a saved PD BIND 9 DNS snapshot when ordinary records in an existing editable zone need to return towards an earlier state. The operation can remove later values and change TTLs; it is not the same as additive import.

Review the intended recovery point

Identify the correct provider, zone and snapshot time. Compare subsequent website, mail and verification changes and confirm which should be undone. Have the server administrator available if activation or special zone arrangements are involved.

Restore and inspect the result

1. Open BIND 9 DNS → Backups and select the intended snapshot.
2. Review its target and use the restore action deliberately.
3. Confirm the existing-zone safety snapshot succeeds.
4. Inspect reported additions, removals, TTL changes, skips and failures.
5. Read back current records and confirm authoritative service state.

The released restore first takes a safety snapshot and refuses an existing-zone restore if that fails. It compares saved and live ordinary records, removes extra values, adds missing ones and adjusts relevant TTLs, preserving provider SOA/apex NS and protected managed records. Unsupported types can be skipped.

Each BIND record mutation is validated before its candidate data is promoted, but the entire restore is a sequence of changes. Do not treat it as one indivisible operation: a later failure can leave earlier changes applied. A reload error may also follow a validated file write.

Handle partial recovery deliberately

Keep the original snapshot, safety-snapshot reference, exact result and action time. Inspect what now exists before repeating a write or choosing a recovery point. The safety snapshot enables a further recovery decision; it is not automatic rollback.

Snapshots do not recreate signing private keys, transfer arrangements or server activation. Use the deleted-zone guide if the editable zone data itself is absent; do not restore over a live transferred secondary.

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