larrytheo Posted November 16, 2004 Report Share Posted November 16, 2004 For quite a while, through versions of Retrospect from 4.3 through Desktop 6.0, I have endured the problem of going to do an Immedate Backup and having Retrospect want to backup files that have not been changed in a long time and were backed up long before. Unless I allow Retrospect to back those files up again, it will always report them as needing backup. I've even had only one channel of a stereo pair of audio files marked for backup, when the two files are ALWAYS treated identically. Since I do a lot of multichannel audio work, this results in a LOT of tape wasted on duplicate data. With the cost of VXA tape and the data involved regularly running into many Gigabytes, this does not amuse me. Before I even wonder why this is happening, the most important question is: is there any way to tell Retrospect that a file is up to date? Is there a flag in the file that I can change to convince Retrospect that a file does NOT need to be backed up again? And, having answered that, what could be causing this? Is Retrospect going on date modified fields to decide what files need to be backed up? Thanks! Link to comment Share on other sites More sharing options...
Lennart_T Posted November 16, 2004 Report Share Posted November 16, 2004 Historically, there have been a problem when starting or ending Daylight Savings Time. Suddenly ALL files was believed by Retrospect to be changed. Is that what happened? Is this problem still in Retrospect 6? Link to comment Share on other sites More sharing options...
CallMeDave Posted November 17, 2004 Report Share Posted November 17, 2004 Quote: Is this problem still in Retrospect 6? Yes. Nothing has changed in 6.x to address the Apple/Retrospect interaction involving files who's creation date falls on one of the Daylight Savings Time changeover dates. Link to comment Share on other sites More sharing options...
larrytheo Posted November 17, 2004 Author Report Share Posted November 17, 2004 Although we did just change from Daylight Savings Time recently, I've been experiencing this vexing problem for YEARS. Further, it doesn't mark ALL files as needing backup, just some, but often ones I know for a fact have not been touched. Their modification dates haven't changed and are earlier than the last backup, and they show up when I look at the catalog, so Retrospect has the correct information available and is somehow being led to believe otherwise. Though the cause of this problem is of interest to me, my biggest concern is having some way of being able to make Retrospect understand these files haven't changed. Of course, I could manually uncheck those files, but I'd have to do that every time I backup. I could rebuild the catalog from the tapes, but that takes a long time and I would have to do it every time this problem occurs, which is frequently. Link to comment Share on other sites More sharing options...
Lennart_T Posted November 17, 2004 Report Share Posted November 17, 2004 Dantz support article 5922 says: <<<<<start quote TITLE: What matching criteria does Retrospect use on a Macintosh? ------------------------------------------------------------------------ Discussion: Matching is the scheme for comparing file attributes to determine whether files are identical, which then allows intelligent copying to avoid redundancy. Also see incremental backup. If one of the criteria has been changed, Retrospect will back up the file again. On a Mac, Retrospect looks at name, size, type, creator, creation date and time, modify date and time, and label. End quote>>>>>> So, has anything changed? Note the "label" part! Has anyone as a routine changed labels on the files? I'm sorry, but I can't think of anything else causing your problem. Link to comment Share on other sites More sharing options...
CallMeDave Posted November 17, 2004 Report Share Posted November 17, 2004 Quote: Their modification dates haven't changed and are earlier than the last backup, and they show up when I look at the catalog, so Retrospect has the correct information available It will help to compare the information that Retrospect has: Immediate->Backup->Preview Look for one of the suspicioius files that's marked for backup, and Get Info (Command+I) to bring up Retrospect's file information window. Reports->Contents->Browse a Snapshot that contains the file above Find the same file and Get Info Put the windows side by side and see what Retrospect sees as their difference(s). Dave Link to comment Share on other sites More sharing options...
larrytheo Posted November 22, 2004 Author Report Share Posted November 22, 2004 Both excellent information and just the kinds of detail I needed to get further. Thank you both, I'll pursue those suggestions and report back if I still am having problems! larry the o Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.