rang Posted October 30, 2007 Report Share Posted October 30, 2007 Hi, I periodically run a verification process against my file backup sets. This morning it reported a large number of errors (perhaps due to a crash during backup at some point?), so I thought I'd run a manual backup to ensure that I have a fresh copy of those files. Unfortunately, the manual backup only backed up files which had changed since the last backup. Retrospect seems to have no knowledge that any files had failed verification -- which makes some sense, since a verify really ought not to *change* the catalog, at least without asking first. The Retrospect manual suggests backing up "to a new backup set" in this circumstance. But is there any way to convince it to just go ahead and make fresh copies to my existing backup set? Anton P.S. The Windows version appears to deal with this better. I'm tempted to run it in a VM to back up my Macintosh for that and other reasons (like backup set grooming *sigh*), though it would make the restore process somewhat more painful. But I'd prefer not to send money in MS's direction, and I'm unsure what the future holds for Retrospect on either platform. Quote Link to comment Share on other sites More sharing options...
twickland Posted October 30, 2007 Report Share Posted October 30, 2007 To get Retrospect to copy files without regard to whether they're listed in the catalog, go to Options> Matching in your backup script and deselect "Match source files to catalog." Of course, unless you then perform a manual selection, you'll get a new copy of every file, not just the bad ones, Actually, though, I'd be a bit concerned about getting a significant number of errors when verifying a file backup set. Did you try repairing the catalog? If that didn't succeed, it may indicate hardware problems on the destination drive that are about to get worse. I'd then be inclined to create a new backup set on a different volume and copy the old set's data to the new, using Tools> Copy> Transfer. Only the readable files should be transferred. You could then perform a normal backup to the new backup set to pick up those files that couldn't be copied. Quote Link to comment Share on other sites More sharing options...
Mayoff Posted October 30, 2007 Report Share Posted October 30, 2007 If Retrospect reports verification errors on a file, it will get recopied with the next normal backup operation. The files get a "miscompare" flag. Quote Link to comment Share on other sites More sharing options...
rang Posted October 30, 2007 Author Report Share Posted October 30, 2007 Thanks for both of these answers -- I hadn't thought of disabling matching, and that's a possibility. Mayoff, perhaps what I'm seeing is not a verification error on particular files? The log simply says: "13,765 files were not verified." So it didn't explicitly indicate that there were *errors* found, but it's still an disturbing output. (It brought up a window showing me the files in question, but with no other information.) This was on an explicit verify (Tools/Verify), not the comparison pass of a backup.... Quote Link to comment Share on other sites More sharing options...
Mayoff Posted October 30, 2007 Report Share Posted October 30, 2007 Did you look at Reports>log for the actual error codes? Quote Link to comment Share on other sites More sharing options...
rang Posted October 30, 2007 Author Report Share Posted October 30, 2007 The complete output from the log file: + Executing Verify at 10/30/2007 9:30 AM To backup set Backup to Asia… 13,765 files were not verified. 10/30/2007 11:25:33 AM: 1 execution errors. Remaining: 13765 files, zero KB Completed: 1736736 files, 70.2 GB Performance: 625.7 MB/minute Duration: 01:54:43 Quote Link to comment Share on other sites More sharing options...
Mayoff Posted October 30, 2007 Report Share Posted October 30, 2007 This is the verify from the tools menu. What happened at the time of backup? What did verify say at that time? Retrospect should re-copy those files as far as I know. Just to an Immediate Backup>Preview to see how many files need to be copied. Quote Link to comment Share on other sites More sharing options...
rang Posted October 30, 2007 Author Report Share Posted October 30, 2007 Yep, that was the verify from the tools menu. I don't see any errors at the time of backup. What actually prompted me to do the verify was this: + Normal backup using Backup source code to Asia at 10/30/2007 2:00 AM Can't add to backup set Backup to Asia: The catalog is locked. 10/30/2007 2:00:25 AM: Execution incomplete. 10/30/2007 2:11:38 AM: Comparing Panasas-source… 10/30/2007 2:11:43 AM: Execution completed successfully. Completed: 40 files, 429 KB, with 0% compression Performance: 0.4 MB/minute (0.2 copy, 5.0 compare) Duration: 00:11:24 (00:09:37 idle/loading/preparing) It puzzled me that it would first say that the catalog was locked and then say that a backup had succeeded. (For what it's worth, I hadn't done anything with the catalog -- but this was the first time that an automatic backup had run since a Leopard upgrade on this system.) So when I found the catalog problem reported in the morning, I tried doing an immediate backup: + Executing Immediate Backup at 10/30/2007 9:27 AM To backup set Backup to Asia… - 10/30/2007 9:27:39 AM: Copying Panasas-source… 10/30/2007 9:27:39 AM: No files need to be copied. 10/30/2007 9:29:36 AM: Execution completed successfully. Duration: 00:01:57 (00:01:55 idle/loading/preparing) That made me think that something might be wrong with the catalog, so I ran the verify at that point. Quote Link to comment Share on other sites More sharing options...
CallMeDave Posted October 30, 2007 Report Share Posted October 30, 2007 Note that the catalog locked error can be a symptom of the double-launch bug. Look up-log a bit; does the launch sequence look normal? Quote Link to comment Share on other sites More sharing options...
Mayoff Posted October 31, 2007 Report Share Posted October 31, 2007 It can also happen when the catalog file is corrupted. BTW, we have fixed at least one cause of the double launch bug in the Leopard release we have coming out in the near future. Quote Link to comment Share on other sites More sharing options...
rang Posted October 31, 2007 Author Report Share Posted October 31, 2007 Ah, the double-launch bug! That one had slipped my mind as it had never bit me before: ∆ Retrospect version 6.1.126 automatically launched at 10/30/2007 1:00 AM ∆ Retrospect version 6.1.126 automatically launched at 10/30/2007 1:00 AM + Retrospect Driver Update, version 6.1.12.101 Looks like that's it. It also explains my absolute bafflement at how, if the catalog was locked, Retrospect still managed to complete a comparison pass. On the other hand, I still don't know what the "files were not verified" message really means. (At some point I'll just clear this backup set and let Retrospect start over, but since it's got my most convenient backup of Tiger, I'm holding onto it for now....) Quote Link to comment Share on other sites More sharing options...
CallMeDave Posted October 31, 2007 Report Share Posted October 31, 2007 Quote: It also explains my absolute bafflement at how, if the catalog was locked, Retrospect still managed to complete a comparison pass. It's not clear from the information given that the double-launch at 1:00 am is the same instance of Retrospect that you used at 9:27 am to run the manual Verify. But even if it is, the Verify pass likely accesses the Catalog for reading only, not for writing. It's also possible that the Catalog file is not, in fact, locked at all, but that the message is the closest thing Retrospect can display given that it's from a bug. Quote Link to comment Share on other sites More sharing options...
rhwalker Posted October 31, 2007 Report Share Posted October 31, 2007 Quote: It's also possible that the Catalog file is not, in fact, locked at all, but that the message is the closest thing Retrospect can display given that it's from a bug. I don't have the source for Retrospect, but the verify might be doing an exclusive open on the catalog (to ensure a consistent catalog), in which case the open would fail if another instance had it open. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.