Direkt zum Inhalt

Differential Backup chains not continuing from last Full version

Thread needs solution

I recently did a differential backup after a full version was made three days earlier. Instead of continuing with the last full version (b11) it continued from a much older version (b8). Why did it choose b8? That version is two months old. Why not b9 or b10 or even the recent b11?
It means the differential is huge with two months of changes. I haven't made any changes to any tasks or restored the system. If it's created a full version only three days earlier there must be a serious reason why it's not continuing with it.
I tried backing up again and it did the same thing continuing with b8. Should I try copying the backup task, renaming the old to keep the old archives and simply make a fresh backup with the new task?

Anhang Größe
backups.jpg 221.02 KB
0 Users found this helpful

Shane,
To make it easier to view and to see date and times, would you modify your screen and repost.
Open Windows Exploerer again to this scren.
In upper left menu,
Click View
Click Details
Click Sort by
Click Date Modified
Click Ascending
This change view should place the file names in the date and time c reat ed and most recent last.

To me, your only fix is to cease to use the old task and start a new task pointing to a new empty sub-folder.

How are these backups being c reated? From within Windows or CD? Schedule or manually or both?

I've already ordered the Windows explorer backups screen into date order with the most recent last.

You can see the b11 followed by b8.

All I could do is clone backup settings of the task, rename old task and cancel auto schedule, then start again with fresh backup with new task.

The backups are created from within Windows on an automatic schedule.

If backups are missed they are run manually.

Shane, My suggestion for the DETAIL view was the detail view shows date and time and in sequence--in a single glance. Illustration below. My instruction in preceding post would only apply to the existing storage folder. For whatever reason, it would appear that your database has become corrupt so starting over is the easiest and quickest workaround. From past postings, we believe that editing or changing a task causes unexpected results. Also, a restore of a prior backup can be a cause as backups exists of which the program is not aware of their existance.

My suggestion is to cease to use the existing task. Create a new one and point the new task to a new emtpy sub-folder with no intemixing of backups. Set the task to automatic cleanup as per illutrration.

Curious: Do you know whether the rogue backups were created via the schedule or from clicking the Backup now or by clicking a desktop shortcut?