Clone Refresh, Snapshot Management, and Data Copy
What the exam tests
This domain separates clone refresh from backup restore and tests snapshot lifecycle decisions.
Core rules
- Clone refresh updates an existing clone from a newer source snapshot. It is destructive to the clone data and local changes.
- Refresh requires a valid source snapshot and enough capacity for the clone operation. The clone keeps its identity, network, and project unless changed.
- Snapshot management includes on-demand snapshots, SLA-driven snapshots, retention, and deletion. Deleting a snapshot used by a clone or restore chain can break dependent operations.
- Data copy is a deliberate copy operation for moving data between databases or locations; it is not the same as a thin clone or a refresh.
- Document clone ownership so refreshes do not destroy work that users expected to keep.
Worked example
A QA clone was created from a production snapshot last week. Production has a new snapshot, and QA wants current data. The administrator warns QA that local test data will be lost, selects the new snapshot, and runs clone refresh. NDB re-provisions the clone from the snapshot and reapplies the clone profile. If QA needs to keep local changes, export them first or create a separate clone instead of refreshing.
Traps
Do not refresh a clone and then look for the old local changes; they are gone. Do not treat refresh as PITR; it uses a snapshot, not log replay. Do not delete snapshots merely because the source database is healthy; check clone and restore dependencies. Do not use data copy when a thin clone is intended, or vice versa.