For an extra full SQL Server backup that should not replace the scheduled differential base, use the native copy-only design after confirming the backup owner's requirements. A copy-only full backup does not become a differential base and does not change the existing one. It can still be restored as a full backup.1
The decision is about recovery dependencies, not the name or location of the file. Copying an ordinary backup to another folder does not make it copy-only, and adding “copy” to a filename does not establish how SQL Server created it.
This guide concerns SQL Server 2022 native backups and ordinary single-base database differentials. It does not execute a backup or provide a production command. Backup-product integration and file/partial backup designs need their own documented assessment.
Why an extra full can matter
A differential backup captures changed extents relative to its base. For an ordinary database differential, that base is the applicable previous full backup, excluding copy-only full backups. Recovery needs that base before the differential can be applied.2
Imagine a scheduled full at the start of the week, followed by daily differentials. An administrator takes an ordinary full midweek for an unrelated task and stores it outside the recovery repository. Later differentials can depend on that newer full. If the recovery team only retains the scheduled full and assumes the old dependency remains, its planned recovery set is incomplete.
The fault is not that differential backups have stopped being valid. It is that the team has changed a dependency without including the new base in its custody and restore plan. The remedy must address both the backup type and the ownership record.
A copy-only full avoids changing the differential bitmap/base relationship described by Microsoft.1, 2 That makes it useful for a deliberate ad hoc full copy, but it does not remove the need to preserve keys, all media components and an authorised restore destination.
Decide what the extra backup is for
Write down the purpose before choosing an option. Is the copy for a test restore, migration staging, supplier investigation or long-term retention? Who may access the data? How long must the copy remain usable, and what failure should it survive?
Then identify the current backup design. Record recovery model, scheduled full/differential/log ownership, any application-aware backup product and where recovery metadata is maintained. Do not assume every product exposing a “full” button uses the same native SQL mechanism. Confirm its documented interaction with SQL backup history and differential bases.
Distinguish a one-off database copy from a planned change in the protection strategy. If the intent is to establish a new scheduled base, a copy-only full is the wrong way to represent that intent because it cannot serve as the differential base.1 If the intent is a non-disruptive ad hoc full, an ordinary full may introduce an unnecessary dependency change.
No generic backup is operationally free. A copy-only operation still reads data, writes output and uses storage and other resources. Its preservation of the base relationship is not a promise of zero workload impact.
Keep full and log copy-only semantics separate
Microsoft supports copy-only full backups across recovery models. Copy-only log backups apply to full and bulk-logged recovery models. They preserve the existing log archive point and do not alter the sequencing of regular log backups; the log is not truncated after the copy-only backup.1
Those facts make a copy-only log different from a routine log backup used by an established protection process. Do not add copy-only log backups as a cure for log growth or assume they replace the scheduled log-backup owner. Microsoft notes that copy-only log backups are typically unnecessary, with specific uses such as some online-restore workflows.1
The COPY_ONLY option also has no effect when combined with DIFFERENTIAL.1 There is no independent differential copy that avoids needing the correct base simply because both words appear in a backup request.
Use this distinction when reviewing a proposed operation:
| Intended outcome | Design question |
|---|---|
| Extra full copy without changing scheduled differential base | Is a native copy-only full the supported method for this environment? |
| Establish a new differential base | How will the new ordinary full enter custody, retention and restore plans? |
| Continue routine log protection | Which process owns the normal log sequence and archive? |
| Special online restore requiring a copy-only log | Does the exact documented restore workflow justify it? |
Do not turn an emergency tail-log decision into an ad hoc copy-only recipe. Preserving the final log tail before restoration has database-state and availability implications covered separately.
Verify metadata rather than filenames
SQL Server records copy-only status in msdb.dbo.backupset.is_copy_only. The history also records backup type, timing and identity, with differential-base fields for applicable differential backups.1, 3
Ask the authorised DBA to inspect the relevant history around the ad hoc operation. Preserve the exact database identity and backup set, not just a database display name. A file named for one database or one date is not authoritative recovery metadata.
For single-base differentials, differential_base_guid identifies the base and differential_base_lsn records its log-sequence relationship. Microsoft's reference warns that multibased differentials can have null values at this level and need file-level interpretation.3 Do not treat a null base field as permission to attach the differential to any convenient full backup.
History is evidence about an operation recorded on an instance, not proof that its backup media still exists. The recovery owner must reconcile it with the actual files or objects, complete media families and their accessible locations. If history was pruned or the database moved, rely on properly inspected media metadata and the existing chain-verification procedure rather than inventing missing records.
Keep the following acceptance record for the extra copy:
- Exact source database and backup-set identity.
- Native backup type and observed copy-only flag.
- Location and completeness of the output set.
- Encryption/key dependencies and authorised custody.
- Expected effect on the differential base and evidence after creation.
Do not include secret material in that record. Reference the controlled key-custody process instead.
Rehearse the recovery consequences
The key test is not merely that the extra backup finishes. In an authorised disposable environment, demonstrate that the intended scheduled full/differential/log recovery route still works after the ad hoc operation. Separately demonstrate that the ad hoc full is usable for its stated purpose.
These are two different acceptance questions. A copy-only full can restore successfully while a separate scheduled chain is missing required media. Conversely, the scheduled chain may be healthy while the one-off copy lacks a required decryption key or one stripe.
Use known synthetic records and a documented target boundary. Record which backup sets were actually applied and which application checks passed. No restore or media verification was performed for this article, so the described rehearsal is a requirement for future acceptance, not a completed result.
If an ordinary full was already taken accidentally, do not delete it to “undo” the event. Preserve the new base and all potentially dependent backups while the DBA determines the actual chain. Establishing another planned base can be part of a corrected strategy, but it does not retrospectively repair missing media from the interval between them.
Retention and return planning
An ad hoc copy should have an owner and an expiry decision. For a copy-only full, that decision still considers the copy's own use, legal/business retention and any later recovery plan built around it. The option does not grant automatic deletion authority.
If the change is a corrected backup policy, preserve the prior configuration and document the transition in base ownership. Returning a job setting cannot reverse which full a differential already references. Retain both old and new required sets until recovery coverage across the transition is demonstrated.
Read-only databases have additional differential-base metadata considerations described by Microsoft, including dependence on master metadata and consequences of detach/attach or restore.2 Treat those as a separately scoped case, not an exception to be guessed during an incident.
Learning notes
- Copy-only is a creation property, not a filename or second copy of a file.
- A differential remains dependent on its actual base.
- The recovery record must connect backup metadata, retained media and a demonstrated restore.
Acceptance checklist
- [ ] Actual backup metadata establishes copy-only status and the differential base.
- [ ] The base and dependent media are retained, accessible and matched by backup identity.
- [ ] The authorised isolated restore uses the intended sequence and validates application data.
- [ ] Ad hoc backup ownership and future differential expectations are documented.
References
- Copy-Only Backups - SQL Server | Microsoft Learn. Accessed 2026-11-01.
- Differential Backups (SQL Server) - SQL Server | Microsoft Learn. Accessed 2026-11-01.
- backupset (Transact-SQL) - SQL Server | Microsoft Learn. Accessed 2026-11-01.