dbatools 2.8.4 fixed behavior in `Restore-DbaDatabase` involving copy-only point-in-time restore chains. The change is a useful reminder that backup files can be individually valid while an automated restore plan still selects or orders them incorrectly. Recovery confidence comes from exercising the whole chain, not from checking that nightly jobs produced files.
Why it matters in production
Copy-only full backups are designed not to reset the differential base. Copy-only log backups preserve the normal log sequence while serving an independent need. Those properties make them useful for migrations, testing, and ad hoc recovery work, but they also create more metadata for automation to interpret. A restore tool must choose the correct full, differential, and log sequence for the requested `STOPAT` target.
Teams should build a repeatable test set that includes regular full and differential backups, transaction logs, a copy-only full, and recovery targets before and after that file. The test should run with the same repository layout, naming, encryption, credentials, and dbatools version used in production. Record the selected chain and verify data at the target time, not only the final database state of RESTORING or ONLINE.
Module upgrades belong in the recovery change process. Pin approved dbatools versions on automation hosts, review restore-related release notes, and rerun representative chains before promotion. Keep the underlying T-SQL recovery method documented so a module regression does not become the only available operating path during an incident.
Practical takeaway
The practical conclusion is that copy-only semantics must be proven through restore. Validate chain selection, `STOPAT`, encryption, and final data after every meaningful tooling change. Backup validity is necessary, but point-in-time recoverability exists only when the exact combination of files and automation has restored the required state.