C C Posted July 3, 2009 Report Share Posted July 3, 2009 Retrospect 6.1.230 on an Intel Xserve, with OS X 10.5.7 Server and an AIT-5 SCSI autoloader. It's backing up several share points, which are each defined as subvolumes...along with a separate script for the entire server startup volume. There are MWF scripts and TTh scripts, which back up to separate backup sets for those days of the week. Recently one of those TTh scripts was supposed include over 500GB which had just been added to a large share point called "TCS Archives". As shown by the log below, I stopped it with 472.7GB done and 64.4GB left. But for some reason those 64.4GB files which haven't yet been backed to this set have apparently been wrongly marked or flagged so that they would NOT be included on subsequent backups: * The first log excerpt below shows that I stopped it with the 64.4GB of new files not yet backed up. The next two excerpts show the subsequent incremental backups for that share point; same backup set. Of course I'd expect it to get the 64.4GB then: But on the first subsequent backup it just got some other small just-added/edited files (plus a bunch of .DS_Store files), totaling only 566MB, and the next time it was just a single .DS_Store file. So those 64.4GB just aren't going to get backed up to this set. I've been using Retrospect for years at several different locations but haven't seen this happen before. * I went to the "Restore" options and did some previews, to confirm how much data that it sees in those backup sets, for this share point. The whole "TCS Archives" share is 1.79TB. When doing previews for full restores of that set, it shows a smaller number of files for the TTh set. MWF: 157,879 files, 1.8TB TTh: 149,378 files, 1.7TB * Originally in the options for backup, under "Matching", the box for the setting "Use attribute modification date when matching" was checked -- the default setting. Recently, but before ANY of these backups were done, I UNCHECKED that, after making a small change to the ACLs and propagating permissions in OS X Server, for several share points. I didn't want it to back up everything again on otherwise unchanged files. I don't know if this problem would have happened if I left this matching option on the default setting, but doing that would add about 2TB to the next round of incremental backups for TTh and 2TB for MWF. Ouch! From the log (other completely different subvolume backups in-between omitted for brevity/clarity): + Normal backup using TTh — Shorter-Term at 7/2/2009 3:20 AM To backup set 2009-03 Shorter-Trm TTh… - 7/2/2009 3:26:04 AM: Copying TCS Archives on External RAID… 7/2/2009 8:15:07 AM: Execution stopped by operator. Remaining: 1260 files, 64.4 GB Completed: 22774 files, 472.7 GB Performance: 1697.4 MB/minute Duration: 04:49:03 (00:03:55 idle/loading/preparing) - - - - - - - + Normal backup using TTh — Shorter-Term at 7/2/2009 8:26 AM To backup set 2009-03 Shorter-Trm TTh… - 7/2/2009 8:26:35 AM: Copying TCS Archives on External RAID… 7/2/2009 8:32:41 AM: Comparing TCS Archives on External RAID… 7/2/2009 8:33:50 AM: Execution completed successfully. Completed: 167 files, 566.0 MB Performance: 575.5 MB/minute (369.0 copy, 1305.9 compare) Duration: 00:07:15 (00:05:17 idle/loading/preparing) - - - - - - - ∆ Retrospect version 6.1.230 launched at 7/3/2009 4:02 PM + Retrospect Driver Update, version 6.1.15.101 + Normal backup using TTh — Shorter-Term TEMP at 7/3/2009 4:14 PM To backup set 2009-03 Shorter-Trm TTh… - 7/3/2009 4:14:13 PM: Copying TCS Archives on External RAID… 7/3/2009 4:20:11 PM: Comparing TCS Archives on External RAID… 7/3/2009 4:21:44 PM: Execution completed successfully. Completed: 1 files, 6 KB Performance: 0.1 MB/minute (0.1 copy, 0.1 compare) Duration: 00:07:31 (00:07:04 idle/loading/preparing) Quit at 7/3/2009 4:44 PM Sorry if this was overly verbose. Thanks for any suggestions / thoughts! I can send the whole log to EMC tech support of that helps. Quote Link to comment Share on other sites More sharing options...
C C Posted July 4, 2009 Author Report Share Posted July 4, 2009 I did try updating the file (not rebuilding from tapes yet), and then ran an incremental backup preview: No files to back up, so updating didn't make a difference. My main concern is that this is the first time that I've stopped a backup after changing the "Use attribute modification date when matching"setting from the default, AND it is the first time that I've seen Retrospect incorrectly mark files so that all of the files in a source aren't being backed up. I hope this isn't a bug which will cause this problem to occur in the future, but I'm afraid it might be...maybe it's just a fluke, but if so it's an incredible coincidence that it happened just after changing that setting. I can add some files to another share point in this set, and try stopping its backup and see if it has the same problem omitting the not-yet-backed-up files from future backups. And I can see if the other backup set (MWF) has the same problem. I'll be able to do that tomorrow or Monday. I could rebuild the catalog from tapes and see if it "unmarks" the 64.4Gb of files so that they do get backed up. But rebuilding the catalog from 6 AIT5 tapes will probably take more than a day. Quote Link to comment Share on other sites More sharing options...
C C Posted July 4, 2009 Author Report Share Posted July 4, 2009 Sorry, I meant to type "I did try updating the *catalog* file" in the first sentence of that follow-up... Thanks, and happy July 4! Time for beer, tailgating, baseball, and fireworks-watching... Quote Link to comment Share on other sites More sharing options...
C C Posted July 24, 2009 Author Report Share Posted July 24, 2009 I tried this again with another backup set, and it didn't have the problem: After I stopped the backup, the next time it picked up all of the files which hadn't been done yet. So for now I've done a recycle backup for the set which had the problem before, and will keep an eye on it. And hopefully I won't have to stop backups very often at all, anyway. (And we expect to upgrade to version 8 after more testing and updates. Glad to finally see the consistent progress from EMC there!) 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.