Verify error does not cause failed file to be backed up at next run?

[jhg]

Retrospect 11.5 on Win7x64 Pro.  I ran a verify which found an error on one file

        Backup Set format inconsistency: 5 at 459,277,423,255
        [*] Xca::ArxExec: FASIG_TAIL's nodeid=63,453; expecting fileno=63,443 for 20120623-10775.CR2

I then ran a backup, expecting the file to be re-backed up, but it does not appear in the session contents. 

 

IMHO a file that fails on verify should be marked in the catalog to be re-backed up the next time a backup is run.  How do I force Retrospect to backup the file again?

[DavidHertzberg]

As far as forcing Retrospect to backup the file again, how about trivially renaming the file?  According to Ash7 in this thread, that would cause Retrospect to back it up again.  Then jhg could rename the file back to its original name, which would cause Retrospect to back the file up a second time.

 

IMHO the feature jhg is proposing would require Retrospect to scan the entire Catalog File for each Source drive backup, looking for the "failed on verify" mark.  That would effectively negate the use of Instant Scan, thus slowing down backups.  I don't think many administrators who use Retrospect to backup multiple Source drives within a limited time window would want to make that tradeoff.

[Lennart_T]

I don't think there is any way to know which file it is from just reading the log, so you can't just rename it.

 

I would try to recreate/rebuild the catalog file (not just repair it). The next backup should backup the file in question.

[jhg]

As far as forcing Retrospect to backup the file again, how about trivially renaming the file?  According to Ash7 in this thread, that would cause Retrospect to back it up again.  Then jhg could rename the file back to its original name, which would cause Retrospect to back the file up a second time.

 

IMHO the feature jhg is proposing would require Retrospect to scan the entire Catalog File for each Source drive backup, looking for the "failed on verify" mark.  That would effectively negate the use of Instant Scan, thus slowing down backups.  I don't think many administrators who use Retrospect to backup multiple Source drives within a limited time window would want to make that tradeoff.

 

I'm not sure I understand why this would slow things down.  As it currently operates, Retrospect has to scan the source directory and build a in-memory representation of the state of each file. That model is then matched to the catalog to see which files have changed and need to be backed up.  All the verify has to do is set a flag on the file in the catalog so that next time a backup is run that file is considered "changed".

[DavidHertzberg]

I don't think there is any way to know which file it is from just reading the log, so you can't just rename it.

 

I would try to recreate/rebuild the catalog file (not just repair it). The next backup should backup the file in question.

 

Lennart Thelander, you are of course correct; the error message in post #1 doesn't show a file name.  However "20120623-10775.CR2" in the second line of the error message looks as if it starts with a date.  I suggest jhg, if it's feasible, check the Source disk(s) backed up onto that Backup Set for files created or modified on that date or just earlier, and then trivially rename them—possibly by appending "20120623".  I haven't used Windows for about 13 years, so I'll leave the technicalities to jhg.

 

In addition, Lennart Thelander, back in 2013 you suggested that cgtyoder repeatedly Repair his/her Catalog File rather than Rebuild it to fix a similar error.  At that time you were using Retrospect Windows; has something in the intervening years made you change your recommendation?

 

I'm not sure I understand why this would slow things down.  As it currently operates, Retrospect has to scan the source directory and build a in-memory representation of the state of each file. That model is then matched to the catalog to see which files have changed and need to be backed up.  All the verify has to do is set a flag on the file in the catalog so that next time a backup is run that file is considered "changed".

 

 

The process you are describing, jhg, is the way Retrospect used to operate before Retrospect Windows 8.  Then the Instant Scan option was added; the most-complete description of that I am aware of is in the second paragraph of this review article (which happens to be for Retrospect Mac 10, but—excepting the GUI—that's the same "under the hood/bonnet" as Retrospect Windows 8).  If your Source drive—client or local—is using Instant Scan, a separate Retrospect process will have pre-determined which files and folders have been added or changed since the last backup, so Retrospect itself doesn't have to do any matching against the Catalog File before backing them up.  Instant Scan saves me about 8 minutes on my daily Normal (No Media Action) backup of a single pitiful 700K-file SSD; as the last sentence in the linked-to article's second paragraph says, it is a "really big deal" for administrators with either large networks or large amounts of data to back up.

 

Doing what jhg suggests would IMHO require a Retrospect Verify run to, if it finds an error of the type shown in post #1, at least disable Instant Scan for the Source disk from which the inconsistency resulted.  That, in combination with the enhancement jhg suggested, should cause the problematic file to be backed up again in the next Backup run.  However there is the possibility that the particular Source disk no longer exists on the LAN ("Joe left in 2013, and we junked his machine/drive"), in which case Retrospect would have to do complicated—perhaps impossible—things with the Snapshot in order to re-backup the same file from another machine/disk that contains it.  Even if that possibility didn't materialize, the administrator would be not happy about having to (assuming he/she read the "backup server" message about Instant Scan having been disabled) manually re-establish Instant Scan for the affected Source drive after the problematic file has been re-backed-up.

[Lennart_T]

 

 

In addition, Lennart Thelander, back in 2013 you suggested that cgtyoder repeatedly Repair his/her Catalog File rather than Rebuild it to fix a similar error.  At that time you were using Retrospect Windows; has something in the intervening years made you change your recommendation?

 

Nothing has actually changed, except (perhaps) a failing memory.

I have not seen (or corrected) the error for some years.

 

You might get lucky with "repair". If not recreate/rebuild should do the trick.

[DavidHertzberg]

Upon doing a browser search of the Retrospect Windows 12 User Guide for "Instant Scan", I found that page 572—under the heading "Instant Scan Technology"—says "Starting from Retrospect 8.1.0 (266) for Windows and Retrospect 10.1.0 (221) for Mac, Instant Scan is only used for scheduled script activity, and not any activity manually started by clicking a Run button."

 

So, along with the enhancement jhg proposed in post #1 in this thread, Retrospect could—and probably should in any case—be enhanced to include the file name and backup date and backup Source of the file that produced the error in that error message.  The administrator, reading the enhanced message, could manually Run a Normal Backup for the Source onto the same Backup Set.  That, although it might backup some extra files if the Backup Set were not still in use, would result in a new backup of the file that produced the error.  This assumes, of course, that the Source containing the problematic file is still available; otherwise the administrator would have to do—possibly with help from a further-enhanced error message that accessed the Snapshot for the Source—the alternate-Source search discussed in the third sentence of the last paragraph in post #5.

 

Therefore my next post in this thread will be my boilerplate instructions for creating a Support Case for an enhancement to Retrospect.  jhg can use these instructions to create the Support Case, by copying portions of posts in this thread into the "description of your issue".

[DavidHertzberg]

If you think this is an enhancement that should be made by Retrospect Inc., you will have to submit it as a Support Case.  For English speakers, that is done by going here http://www.retrospect.com/en/support/contact, and filling out the form (sorry, I don't know what the equivalent addresses are for non-English speakers, but they can figure it out from their appropriate Retrospect website address).  IMHO this is quite reasonable; obliging you to fill out the form provides Retrospect Inc. with useful details about your Retrospect installation that they would otherwise have to query you for.

 

As a result, Retrospect Inc. will pay no attention to your post in this forum.  On 12 December 2016, in response to a letter I snail-mailed to Mayoff,  I received an e-mail through a Mayoff account that was signed by JG Heithcock, CEO, Retrospect, Inc. http://www.retrospect.com/en/about#exec.  In it he says "From reading your letter, I think the main issue is that you view the forums as a good place to talk to us, Retrospect, Inc. But we view the audience of the forums as restricted to our customers [my emphasis]. The one caveat we have made on that is for feature requests, largely as we would like to see if other customers also agree on the desirability and feature set for these requests."

 

That means that the only audience for enhancement requests in this forum will be other administrators of Retrospect.  Nevertheless, by posting in this forum you are providing a useful service to us fellow administrator peasants.  Thank you.

 

Please be aware that the "description of your issue" in the Support Case form is IME limited to about 2000 characters by the Support Case software.  If you go over that limit your "description" will be broken up into a "description" plus one or more "additional notes".  The same is true for any additional notes you may later post yourself.  I suggest that, to avoid the appearance of choppiness in your Support Case, you create your case in a post in this forum and then copy it paragraph-by-paragraph to your Support Case. 

 

Note that, despite the new dialogs in the Retrospect Inc. Support Case system urging you to sign up for Annual Support and Maintenance, Mayoff has verbally assured me that you don't need to be signed up for ASM to report a bug—only to get personal assistance with coping with it.

 

If this post sounds formulaic, that's because I intend it to be.  I intend to post it in every enhancement-requesting thread that appears in this forum, unless the OP indicates that he/she has or will open a Support Case for the enhancement that the thread requests.  Of course, Mayoff could take 5 minutes of his time to post a slightly-more-polite version of this post as a  "sticky thread" that will always appear at the top of the forum.  I don't intend to hold my breath until that happens (insert appropriate smiley here).

[DavidHertzberg]

Yesterday jhg started a new thread in this forum, in which he/she described error messages for several (newer?) files similar to those he/she reported for one file in post #1 of this thread.  I chided jhg for not having posted them in this thread, whereupon he/she reported his/her own post—requesting that it be deleted.  As is usual in such cases, Retrospect Support deleted the entire thread.

 

But that belatedly spurred me to think of a new partial solution to jhg's "Backup Set format inconsistency" problem, derived from my further thinking (while taking a post-gym shower ) about what I wrote in the second sentence of the second paragraph of my post in the new thread.  It first occurred to me that, although he/she didn't mention his/her Retrospect version in post #1 in the new thread, he/she might have mentioned it in this thread.  jhg did, and—unless he/she has upgraded since 29 May—it's Retrospect Windows 11.5.  I know that that's not the latest version, and it next occurred to me to do a browser search for "Backup Set format inconsistency" in the cumulative Release Notes for Retrospect Windows 12.1.  Lo and behold, Retrospect Windows 12.0 has a Fixed line for "Clarified error for backup set format inconsistency (#5627)".  I don't know exactly what that Fix is, but it's likely that it at least will tell jhg the names of the files that have the inconsistency.  If it does, he/she can then do the trivial name change I suggested in post #2 in this thread—to cause each file (assuming jhg still has them on a disk somewhere) to be backed up again.

 

jhg can contact Retrospect Sales to get a 45-day trial license for Retrospect Windows 12.1.  I expect him/her to give us other administrators the courtesy of posting the results of his/her trial, at least as to whether Retrospect 12.1 clarifies the message for "Backup Set format inconsistency" by giving the names of the files involved.

 

I apologize to everyone for not having thought of looking in the Release Notes back on 29 May.  There's a reason why Retrospect Inc.'s Support Case form asks for the version of Retrospect the case filer is running; we should all remember—as jhg did in post #1 of this thread—to supply that information when starting a thread in these Forums.

 

P.S.: To use the "new partial solution", jhg would have to (as I said in post #7 in this thread) "manually Run a Normal Backup for the Source onto the same Backup Set.  That, although it might backup some extra files if the Backup Set were not still in use, would result in a new backup of the [name-changed] file that produced the error."