Domain Nexus zone backups preserve DNS records for recovery. They complement, but do not replace, full WHMCS database, application and secrets backups. Configure retention according to the service you offer and verify that snapshots can actually be restored.
IN THIS ARTICLE
01 Set the backup policy
Review package backup limits and customer controls. A retention limit of zero disables retained backups in the package controls. Decide whether customers can take manual snapshots, download them and restore them, and keep administrator recovery responsibilities clear.
- Open DNS Manager > Zone backups to inspect the snapshot inventory.
- Find the required customer and zone. Check the snapshot time, scope and source so you do not confuse two similarly named zones or a pre-migration copy.
- Take a fresh backup before a significant import, bulk edit, provider migration or restoration, when the current state is readable.
- Verify the backup job completed and that the expected records are present. A queued backup is not yet a usable recovery point.
02 Restore carefully
Open the zone's backup workflow and preview the proposed restore. Compare the snapshot with the current records, paying particular attention to MX, TXT verification, newly added subdomains and records created after the snapshot.
Apply the reviewed restoration through the supported changeset workflow. Protected records, provider capabilities and current ownership still apply. Follow the job to completion and verify the result on every authoritative server involved.
What does a DNS snapshot restore leave outside its scope?
A DNS snapshot does not contain website files, databases, email messages, registrar registration, parent nameserver delegation or a complete portable set of provider signing keys. Restoring old DNS can point visitors to an obsolete service, so confirm the referenced addresses and hosts still operate.
Provider-specific metadata may not round-trip through a portable zone export. Keep separate documentation for proxy settings, DNSSEC and forwarding infrastructure when those matter to recovery.
03 Plan a real recovery exercise
Use a test zone to make a harmless change and restore it from a snapshot. Verify both the module state and direct authoritative answers. This reveals permission or provider compatibility problems before a production incident.
For a deleted zone, use the dedicated deleted-zone recovery process and confirm the backend binding and ownership before restoration. If a snapshot is missing, check retention, failed backup jobs and whether the customer ever had backup entitlement. Do not imply that an unavailable recovery point can be reconstructed automatically.