A backup register that records the restore check
Track backup filenames, workspace coverage, storage locations, revisions and actual restore-check results with a blank CSV and a clearly fictional example.
A filename is evidence that a copy was named, not that it can be restored. This register records what a backup covers, where it is stored and whether a restore check actually succeeded. It helps distinguish a recent file from a verified recovery point without putting credentials in the log.
The useful part
Record the restore result only after checking a copy. Keep “not checked” distinct from a successful restore.
Your working files
Download blank templateCSV · Column headings only. Add your own records to a copy.Download fictional exampleCSV · Completed sample records in AUD. Use for practice, not a live close.Describe what the backup contains
Name the workspace and period coverage, and record the application version or edition when known. A workspace export and a full application database are different kinds of backup; do not assume either contains the same account, session or configuration information. Use the current backup help to understand the file you are creating before choosing a recovery procedure.
Track a recovery point, not just a file
| Field | What to enter |
|---|---|
| Backup ID / Created at | Local identifier and actual timestamp with timezone when known. |
| Filename / Backup type | Exact name and workspace export, database copy or other documented type. |
| Application version / Workspace | Version or edition and the workspace covered. |
| Period start / Period end | Known coverage dates; do not infer them solely from the filename. |
| Storage location | Controlled path or media reference, without passwords or access tokens. |
| Workspace revision / Closed runs | Observed values when available, not estimates. |
| Restore checked on / Restore result | Actual check date and outcome, or blank date with “not checked”. |
| Next check / Notes | Planned follow-up and any limitations or error details. |
One checked copy, one unchecked copy
The fictional register lists a 20 September workspace export with a recorded successful check, then a newer 27 September export that has not yet been checked. The second record is more recent but has no invented restore date. These are sample records for learning the format; no downloadable backup or claim about your own recoverability is supplied.
| Copy | Coverage ends | Recorded result |
|---|---|---|
| BACKUP-001 | 2026-09-20 | Sample restore checked; expected workspace and run count observed |
| BACKUP-002 | 2026-09-27 | Not checked; next action remains open |
Verify without replacing the only working copy
Do not upload a backup to an unrelated online validator. If a check fails, keep the error and affected filename in the register while preserving the original file for investigation.
- Confirm the saved file exists and identify its documented restore method.
- Preserve the current working data before attempting a restore.
- Use a separate test destination where the supported procedure allows it.
- Inspect the expected workspace, periods and completed records, then record the actual outcome.
Record what syncing does to the location
If you choose an iCloud Drive folder, the files in it may sync through your iCloud account. Syncing a file is different from checking that the application can restore it. Use a location you understand, record any separately retained copy and avoid assuming that a local path means local-only storage. The register itself is a CSV, so protect it according to the workspace information and file locations it reveals.
Sources and further reading
Reviewed 27 September 2026. Check current source guidance when applying it to your own process.
Put it to work.
Use the current product procedure for the type of copy you are keeping.
Read the backup and restore steps