Direkt zum Inhalt

Multiple Unwanted full backups after desired incremental

Thread needs solution

I have attempted a backup scheme for my Windows 7 Pro based Dell M4800 laptop which creates a full backup and then 20 incremental backups, then another full backup and 20 incremental backups, and so forth, and deletes old strings after there are 3 or more full strings on the backup drive.  After 25 or so days it seemed to be working as desired.  1 full and 20 incremental backups, then another full backup and 4 incremental backups.

Day 32 - Today, after creating the 10th incremental backup in the second string, as expected, the program continued to run and create new full backups - two more before I noticed, and it was on a third when I stopped it.  Like it has gone crazy, all by itself.

Has anyone else seen this behavior, or what settings and/or upgrades have I missed?  Any ideas or help would be appreciated.

Thanks, Bob

0 Users found this helpful

Bob,

The most frequent cause of the tasks not performing as expected is the user edits the task and makes a change (maybe minor or major) and the program does not properly recover.  Maybe post us a picture of the storage disk showing what is happening.

The backup scheme should read

Custom (task must read custom)

Incremental

Full after 20 incrementals (Chain length=21 files)

Store no more than 3 recent version chains.( 21 files per chain)

With that setting, the program should create  63 backups

Autu deletion of the oldest chain of first 21 files should occur after 4th full (or after backup #64.

and auto deletion to continue after each full thereafter.

--------------------

If you did make changes, you can wait a few backups and see if the task corrects itself,

or stop using the task and create a new task with a new task name and pointing to a new storage folder or sub-folder.

 

Hello Grover:

Thanks for your response.  I have attached two images - one of the external HDD directory where the backups have been stored, and one of the Backup Scheme.  I believe the HDD directory will show what I am talking about - successful backups, as expected until those created after 2:09 am on 1/29/16.  The Backup Scheme is, I think, just as you described.  I have not changed it since I created it before the first backup.  Something did change, however, between my backup on 1/28 and 1/29.  Specifically, I moved the computer and backup drive from its "office" location, in which it is plugged into a docking station and has a number of different peripherals plugged into it via the docking station, and multiple drives plugged into other USB ports, to a traveling location, where it has only a monitor and the backup HDD, plugged into it directly.

I thought the problem might have something to do with an Acronis software error, perhaps related to this leap year, but it could have something to do with the configuration change brought about by my travel.  However, I was also traveling from 1/5 through 1/20, with a similar configuration to that of 1/29, and noted no similar problems.  The only thing which was different between my previous travel configuration (where all seemed to work fine), and last night's configuration where I saw multiple unwanted full back ups, was the USB port used to connect to the backup HDD.

Any additional thoughts you may have would be much appreciated.

Thanks again, Bob

Anhang Größe
325829-125344.pdf 308.87 KB
325829-125347.pdf 167.29 KB

Whatever happened was after either the 29th or possibly the 28th as the numbering format changed on the 29th from V1 to v1-1 format.

The help file indicates the format changes due an existing file of the same name.  "If you are creating a new backup, and there is already a file with the same name, the program does not delete the old file, but adds to the new file the "-number" suffix, for example, my_documents_inc_b2_s2_v1-2.tib."

Because the target has the drive letter Y assigned, I am assuming that specific drive letter was pre-assigned at time of task creation.  Is that true?

The log file named "service on Jan28 and the service one on the 29th might provide some reason clues.  Log filw located at this link. Is validation done with each backup or some schedule?

c:\programData\Acronis\TrueImageHome\logs\

Would you consider zipping the logs and scripts folder into a zip file and attach.  It would be interesting to see what is disclosed.

If the full backups continue, you may have to stop using the problem task and start over with a new task with a new task name and new storage folder or sub-folder.

Hello again:

Thank you for the comments and information.  In response to your comments:

1) The only change between 1/28, when all worked as intended, and 1/29, when the strangeness started, was the move from a docked configuration to a stand-alone configuration, and the change from one USB port to a different one feeding drive V:.  There were actually a lot of configuration changes associated with that change, but with the exception of the USB port change, none which should have affected the drive being copied (Drive 0 in the machine), nor drive V:.  And it seemed that Acronis created the incremental backup on drive V without problem.

2) Yes, the Target Drive was pre-assigned as Drive V (not Y), at the time of the backup task creation.

3) I have examined the series of log files from 1/28 through 1/30, along with various other files in the log folder intermixed in the sequence.  There are a large number of them, they contain various error messages, some success messages for both the backups that worked and the verifications done with every backup, and a significant amount of non-English language XML information that I cannot interpret.  They also contain a listing of the files which were deleted after the new backups ran, (see below).  I would really like to forward the log information as you suggest, but without better understanding what is embedded in the encoded blocks of letters, I cannot risk compromise of confidential information.  Is there any "reader" software that would allow me to confirm the non-confidential nature of the information in the files?  Short of that, I guess I should just rebuild the task with a new name and new folder as you suggest.

4) The story continues to be even more strange to me - see the attached directory from the backup drive V: this AM, after the backup ran again very early this AM.  After it ran, it also deleted all of the prior backup folders, without cause, from my viewpoint.  The notes on the attached image indicate what I perceive to be problems with what happened very early this AM.

Thanks again, for your comments, suggestions and input,
Bob

Anhang Größe
325977-125368.pdf 201.64 KB

With the deletions, the program must believe it is back on track and exceeded the retention of 4 full requirements.  Only time will tell whether it will now continue correctly.  If at some point in the future, you decide to create a new task, consider adding the option "do not delete the original" and that backup will be outside any rules and deletion--should you want to keep something extra.