Jump to content

Retrospect backs up files that have been deleted!


abe

Recommended Posts

Well, this one seems curious. I paused Retrospect 6.5.350 during the "Preparing for Open File Backup" stage, BEFORE it started scanning my data partition. I then opened my file manager (PowerDesk 5) and DELETED several large files that I did not want to back up (unnecessary). Also emptied the Recycle Bin.

 

Yet, Retrospect not only "found" and backed up the files, they all compared correctly AS IF they were still there!

 

Could someone please explain this naughty behavior? I thought briefly that it might have something to do with write caching, but the files were no longer visible in my file manager. (Incidentally, I'm using 2 drives in a RAID 1 config off a Promise controller, and do not have an "enable write caching" option in Device Manager.)

 

Perplexed,

Abe

Link to comment
Share on other sites

  • 3 weeks later...

Sorry, guys, I got real busy and haven't been back to this thread--wanted to confirm. No filesaver utilities like the Norton-protected recycle bin running. And I've definitely excluded the recycle bin from backup. So it is indeed ultra-weird.

 

I just tried it again: Retrospect started automatically, prepped for Open File Backup, scanned files. I then Paused before it began copying, deleted several files from a single folder, emptied the recycle bin, then resumed. R began copying, included the files I had just deleted/emptied, then copied the snapshot, then verified, all without errors.

 

I then proceeded to restore one of the deleted files to confirm that it had actually made it into the backup set--there it was in its original location in the snapshot of my folder hierarchy, as were the other files I had deleted.

 

Now, I'm fairly certain that Retrospect 6.0 and 5.6 were smart enough to error on files that had been deleted before the compare executed.

 

This is a rather serious design flaw, if not a bug. It looks like Retrospect may be caching the files at some point, perhaps during OFB prep--it is of course possible to copy open files and paste them in their original, unsaved form. However, it is imperative that Retrospect check file existence on the disk before copying(!), and certainly when verifying. The disk, not the cache, is the standard to be matched when copying! If these is Dantz/user disagreement on this issue, an option for choosing the method must be added, because this issue has enormous security implications, never mind implications for backup set space.

 

Could someone please confirm this behavior?

 

Abe Hendin

AtYourSpeed Consulting

Link to comment
Share on other sites

Hi

 

 

 

I think I know whats going on here...

 

 

 

This is windows XP and the disk is formatted as NTFS right? Chances are you are using the default Retrospect setting to backup open files. This feature uses the Windows shadow copy API to back up all files on the disk in the state they were in when the scan of the disk started.

 

 

 

Because you have emptied the recycle bin after the open file backup process has started these files will still be included in the backup.

 

 

 

Other than for open file backup Retrospect does not use any caching like you have suggested. If you turn off the open file backup option, files that have been deleted from the disk during a backup operation Retrospect will cause an error 1101 (file not found).

 

 

 

You mentioned that you have excluded the recycle bin from your backup? How did you go about that? It sounds like it isn't working.

 

 

 

Thanks

 

Nate

 

 

 

 

Link to comment
Share on other sites

Quote:

Chances are you are using the default Retrospect setting to backup open files. This feature uses the Windows shadow copy API to back up all files on the disk in the state they were in when the scan of the disk started.

 


 

As I suspected: OFB is the culprit. Thanks for the explanation, Nate. The trouble is that one shouldn't have to give up OFB entirely, on all systems backed up by a script, to avoid backing up files that the user has legitimately deleted. There are very legitimate reasons to back up open files--having to turn the option off would be akin to throwing the baby out with the bathwater.

 

I would submit that there ought to be an option worked in to OFB to exclude deleted files--after all, they are no longer open.

 

Quote:

You mentioned that you have excluded the recycle bin from your backup? How did you go about that? It sounds like it isn't working.

 


 

Always exclude Windows: Special Folders: Recycle Bin. It's working fine: The "Recycler" folder is excluded when I check the selector, and as I said, the file appeared in its original location, not in the recycle bin.

 

Abe

Link to comment
Share on other sites

Hi

 

Quote:

The trouble is that one shouldn't have to give up OFB entirely, on all systems backed up by a script, to avoid backing up files that the user has legitimately deleted.

 


 

You don't need to give up open file backups. This problem _only_ occurs when the user deletes files after the drive has been scanned for backup. Files deleted at any other time will not be included in the backup.

 

Selectors are the way to go if you want to make sure that folders are excluded from backup.

 

Nate

Link to comment
Share on other sites

Quote:

This problem _only_ occurs when the user deletes files after the drive has been scanned for backup.

 


 

Er... right--thanks for the reminder. In truth I'd just like to be able to delete things at the last minute because I sometimes remember those nasty large interim files then. Guess I'll just have to remember something else, that the last minute is the minute before my script is scheduled to execute. No big deal in the end--and it's easier to delete things locally before a script starts on the local machine anyhow.

 

Good thing I'm not Arthur Anderson... ;-)

 

Abe

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...