Jump to content

Verify successful but many files remaining?


amkassir

Recommended Posts

When doing a backup of my boot partition, the backup completes successfully. The verification is reported as successful, but there are 439 files "remaining." Does this mean my verification didn't succeed for 439 of the files? Or did the verification succeed but is incorrectly reporting 439 files remaining?

 

I've read this thread in the Retrospect 8 bug reports forum on the same issue, but it's still not clear to me whether the files were verified or not, and why many files are still "remaining."

 

I'm using media (not thorough) verification.

 

Here's the log:

 

Normal backup using Backup iMac HD at 10/26/10

To Media Set Media Set A...

- 10/26/10 9:50:27 PM: Copying iMac HD

10/26/10 9:59:42 PM: Snapshot stored, 177.1 MB

10/26/10 9:59:54 PM: Execution completed successfully

Completed: 1649 files, 5.8 GB

Performance: 1,628.7 MB/minute

Duration: 00:09:26 (00:05:48 idle/loading/preparing)

 

- 10/26/10 9:59:58 PM: Verifying Media Set A

10/26/10 10:02:23 PM: Execution completed successfully

Remaining: 439 files, 3.9 MB

Completed: 1210 files, 5.8 GB

Performance: 2,590.9 MB/minute

Duration: 00:02:25 (00:00:07 idle/loading/preparing)

 

 

I hope I get some resolution to this question soon, because I'm halfway through the 30-day trial period for Retrospect 8.2. I'll upgrade from version 6.1 if I'm comfortable with 8.2, but until I understand what's going on here, I'm not comfortable with the integrity of the verification process. BTW, I submitted this same question to tech support 9 days ago--7 business days--but haven't received a reply so I thought to post it here.

 

Thanks for any insight you can offer.

Edited by Guest
Link to comment
Share on other sites

I received a welcome response from Roxio Support on this issue:

Although your backup completed successfully, the final report shows several files remaining because you are using Media verification. If you use Thorough Verification there shouldn't be any files left over after the backup completes and you can ignore the "remaining file" reported by Media Verification.

 

I hope to have a chance to test this over the next few days and will report back here.

 

Can anyone else confirm the quoted material above?

Link to comment
Share on other sites

Hello amkassir,

 

the real reason for the remaining files during media verification is that files with "/" in the filename are not verified or correctly counted as verified. May be more files are affected, but this like searching a needle in the haystack, if you don't have a clue what to search for. It was pure luck to find the "/" file clue. Roxio (formerly Iomega) was absolutely no support in this case.

 

Normally the files are save, but without an automatic verification, you can't trust what's on your backup media or not.

 

Roxio support (formerly Iomega) knows about this problem since January 2010, but for them it is not important enough to fix it. May be next year in a new version...

 

Roxio only provides workarounds like switching to Thorough Verification, but this is not an option if you backup files which changes often during the backup/verification task.

 

The next argument of Roxio is that "/" filenames are not allowed on all operation systems. But on OSX they are very common, even system files have "/" filenames. And it is possible to rename files with "/" using Finder and other applications without error message. Retrospect should backup, verify and restore all valid files on any supported system. With version 6 it has been no problem as well.

 

Link to comment
Share on other sites

I would probably argue that "/" in OSX file names will probably become less common than you think.

 

Office 2011 (as a recent example) won't let you open files with a "/" in the name -- and this was not changed in yesterdays 14.0.1 patch, either.

 

Whether or not this is a good or bad thing, is debatable.

Link to comment
Share on other sites

The next argument of Roxio is that "/" filenames are not allowed on all operation systems. But on OSX they are very common, even system files have "/" filenames.

 

Uh, no. "/" is not a permissible character for OS X's underlying BSD subsystem.

 

 

And it is possible to rename files with "/" using Finder and other applications without error message.

 

Yes, but the Finder is lying to you. If you inspect such a file using tools other then Finder, you'll find the actual character in the name is ":"

 

Retrospect should backup, verify and restore all valid files on any supported system.

 

Agreed. Which leads to the logical conclusion that files with "/" in their name should fail.

 

With version 6 it has been no problem as well.

Retrospect "Classic" was blind to OS X filesytem realities; it was simply a Carbonized version of Retrospect 4. The fact that it didn't choke is not related.

Link to comment
Share on other sites

Uh, no. "/" is not a permissible character for OS X's underlying BSD subsystem.

 

Yes, but the Finder is lying to you. If you inspect such a file using tools other then Finder, you'll find the actual character in the name is ":"

 

Retrospect "Classic" was blind to OS X filesytem realities; it was simply a Carbonized version of Retrospect 4. The fact that it didn't choke is not related.

Consider the case of a terabyte of historical files brought forward from MacOS 7, 8, 9 and ASIP 4.x into MacOS 10.x, with historical backups from Retrospect 2.0, 4.x, 6.x, etc. I've got that existence proof with such oddly-named files. No, a script can't do a search and replace for legal reasons - the files have to retain their names.

 

Agreed, it's a dilemma.

 

Russ

Link to comment
Share on other sites

The point is, I can't change the names. Many files are linked with the file name as reference. Or they are received from clients and we are not allowed to change the file names.

 

 

So then the ":" in the BSD filenames would be the real reason, depending which library retrospect uses to access directories and files.

I think until OS9 ":" has been the folder character and "/" has been a valid filename character.

 

Failing handling this files would be consequent, but this would upset users, because the software doesn't do what the user think it does:

- securely backup ALL files on the system irrespective of the "beauty" of their file names

- files can be automatically verified

- files can be later restored to the same status as before.

 

Otherwise this backup application is no secure way to backup your files.

Link to comment
Share on other sites

So then the ":" in the BSD filenames would be the real reason.

 

I dunno; that's not what I said.

 

I replied to:

"... it is possible to rename files with "/" using Finder..."

in the present tense. Today's Finder will allow the user to use "/" and display it as such, while the file's actual name uses ":"

 

For legacy files (such as Russ notes above) I don't know what a shell sees.

Link to comment
Share on other sites

The point is, I can't change the names. Many files are linked with the file name as reference. Or they are received from clients and we are not allowed to change the file names.

Agreed. I'm in the same boat.

 

So then the ":" in the BSD filenames would be the real reason, depending which library retrospect uses to access directories and files.

I think until OS9 ":" has been the folder character and "/" has been a valid filename character.

 

Failing handling this files would be consequent, but this would upset users, because the software doesn't do what the user think it does:

- securely backup ALL files on the system irrespective of the "beauty" of their file names

- files can be automatically verified

- files can be later restored to the same status as before.

 

Otherwise this backup application is no secure way to backup your files.

Agreed. It's a bug. One of many. Perhaps someday some of the outstanding bugs will be fixed.

 

I suggest that you file an incident report to make sure that this gets on the list and prioritized. These forums are user-to-user support. The official bug reporting page is here:

File a support request

 

Russ

Link to comment
Share on other sites

Just out of curiosity I did a simple test. I made a backup of a folder containing 3 files. One file had a "/" in the name. The first time I did a media verification. The verification was successful with 1 file remaining.

 

Then I did the same backup (recycling the media) with thorough verification. The verification was successful with no files remaining.

 

Finally, I changed the name of the file, replacing the "/" with a dash "-". I did the same backup (recycling) with media verification. The verification completed successfully with 0 files remaining.

 

Bottom line is I was able to reproduce the reported behavior of the media verification process when files containing the character "/" are backed up.

 

What remains unknown is this:

(1) Are the affected files (ones with the name containing a "/") properly verified or not, when using media verification?

(2) Do other special characters in file names cause similar behavior?

 

In my original post, I reported 439 files were remaining. I seriously doubt I have 439 files containing a "/" in their names. I typically make a point of NOT naming files with a "/" in the name. This leads me to suspect that other files are involved too.

 

Unless Retrospect support can answer these concerns definitively, how can one be sure all these files are backed up properly and can be counted on to restore correctly?

Link to comment
Share on other sites

Bad news. When files are "remaining" after a "successful" media verification, those files were NOT verified.

 

I have received a response from our escalations team. That the files are not being properly verified when they contain special characters.

 

/ is the only character we have identified so far that causes the issue. We have a bug open for this, and Engineering will be reviewing it to identify any other characters that cause the problem.

 

This means that only thorough verification works for these files.

Link to comment
Share on other sites

  • 3 weeks later...

A few months ago Robin replied to another thread, just about this issue, that this is a "cosmetic bug" and it shouldn't be worried about, and he said that one could be confident that verification was OK. I would be more confident if Retrospect put up a KB saying that such files were DEFINITELY verfied, and that the bug is only in the *reporting8 of same. I agree that Retrospect reporting a large x number of files as not being verified using media verification is a confidence-reducing issue. If it truly is not verifying files starting with /, then they should post a KB about this, offer a workaround other than the time-consuming full verification, or find a way to fix the issue of backing up and/or reporting of / files.

-baweeks

-baweeks

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...