BA6990: Reverse-incremental restore point recovered in a degraded state¶
| Error code | Product | Applies to |
|---|---|---|
| BA6990 | BackupAssist | For BackupAssist 15.0.5 or later. |
Description¶
System Protection backups can build "reverse-incremental" restore points, where the backup destination always holds the latest backup as a full image and older restore points as reverse diffs against it. If a previous backup was interrupted while this reverse-incremental step was running (for example by a power loss, crash, or forced shutdown), the affected restore point can be left in a partially-reverted state, and the next backup automatically attempts to recover it.
In some cases the only data still available to recover the affected restore point is a local Volume Shadow Copy (VSS) snapshot retained from an earlier point in time. A small number of files that Windows itself continuously rewrites can have changed in that snapshot since the restore point was originally created, so the recovered restore point may not be byte-for-byte identical to the original for those specific files. BackupAssist recovers the restore point anyway, using the best data available, and reports BA6990 to flag that it is usable but degraded for those files.
Common causes:
- A previous backup was interrupted (power loss, crash, forced shutdown, or the backup service being stopped) during the reverse-incremental step.
- The only recovery source available was a retained VSS snapshot, and Windows had since rewritten one of a small set of operating-system-maintained files (e.g. the NTFS change journal, boot-related files, or Windows event logs) that the snapshot no longer reflects exactly.
This condition always appears alongside BA6994 ("reverted, retry backup") on the same job - BA6994 confirms the interrupted revision was rolled back and the chain is intact; BA6990 additionally flags that the recovered restore point itself holds best-effort data for the files described above. Neither condition suppresses the other.
Resolution¶
Resolution 1 - No action needed for most environments (recommended)¶
The files affected by this condition are operating-system-maintained files that Windows regenerates automatically (the NTFS change journal, boot sector housekeeping data, and Windows event logs). A restore from the flagged restore point will succeed and boot/run normally; these files simply reflect a slightly different point in time than the rest of the restore point. No corrective action is required in typical use.
Resolution 2 - Verify the affected restore point, or re-seed the chain¶
- If the affected restore point is business-critical, perform a test restore of it to confirm it behaves as expected.
- Check the backup log around the time of the reported job for lines mentioning "RebuildParentIndexAndLogDrift" or "DEGRADED" to see exactly which files/blocks were affected.
- If you want every restore point in the chain to be a byte-for-byte match of its original capture (rather than accepting best-effort data for a small number of OS files on this one restore point), run a new full backup to start a fresh chain.
Note on the backup report¶
This condition appears in the job report as: The previously failed reverse-incremental backup was recovered, but data for a small number of operating-system files could not be preserved exactly and was reconstructed on a best-effort basis. This restore point is usable; verify it before relying on it.
| Last updated | Created | Further assistance |
|---|---|---|
| 6th Aug 2026 | 6th Aug 2026 | BackupAssist Support page |