PD Google Cloud DNS can retain point-in-time record snapshots. Use them to preserve a known record set, then choose deliberately between a targeted record edit and restoring the snapshot’s supported records.

Configure and verify snapshots

1. Open Google Cloud DNS → Settings → Backups.
2. Review Take scheduled zone backups and the intended interval.
3. Choose the retained count and optional age-based pruning.
4. Check the normal WHMCS cron.
5. Review completed snapshots and the relevant maintenance result.

A configured schedule is not proof the latest edit was captured. Retention can remove older copies, including ones useful for recovery.

Take a copy before changes

Use the zone’s Back up now action, then inspect the snapshot’s zone, date and record information. Use the available download control where a separate record file is needed.

A DNS file is not a backup of a website, mailbox, project IAM configuration, signing keys or registrar delegation. Keep those responsibilities separate.

Understand the released recovery behaviour

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. Google Cloud’s SOA and apex nameservers remain provider-owned. Review any skipped unsupported types and managed-record protection rather than treating a record snapshot as a copy of every provider setting.

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

For a zone confirmed missing at the provider, Recover zone on a retained snapshot can recreate the provider zone and restore its supported records. There is no current-zone safety copy when no zone exists. Confirm the project and native managed-zone identity first: the module’s derived-name lookup can mistake an existing differently named resource for a missing one. Do not recover into a guessed identity.

After recovery, verify the customer assignment and the recreated zone’s own assigned nameservers. Recovery does not automatically transfer registrar delegation, rebuild signing keys or restore a website or mailbox. If the snapshot controls differ on your installation, review available module updates through PD Modules before following the current recovery workflow.

Choose a targeted repair when appropriate

For an isolated record mistake, compare the snapshot with the live record and use a reviewed edit through the record editor. For a broader recovery, your hosting team should review the selected snapshot, intended changes, safety copy and any partial result before repeating the operation.

Afterwards compare the actual record sets and verify authoritative DNS, delegation and website/mail behaviour. See the ordinary-record import guide for its separate limitations.

Check the recovery result

Your hosting team and Google Cloud administrator should compare the chosen snapshot’s project/provider, domain, time and record count with the intended recovery point. Identify whether restore failed before changes, during comparison or after removing/adding/updating records. Inspect the saved pre-restore snapshot and actual live values before choosing an undo; a second restore still depends on working provider reads and writes. If the module says a zone is missing, establish its native managed-zone identity before allowing recreation.

See the PD Google Cloud DNS WHMCS guide for related tasks, or explore the module.