Arroz Posted March 3, 2008 Report Share Posted March 3, 2008 Hi! I have a G5 running Tiger and a Powerbook running Leopard. The G5 runs Retrospect and backups up the powerbook via network. When I had tiger on the powerbook, everything was fine. Now, I installed Leopard (from scratch). Every time I try to backup the powerbook, I get the following error: Scanning incomplete, error -43 (file/folder not found) What's this? What is the file/folder that is not being found? I can't find any more info on the logs, it just says that. I upgraded the Retrospect version on the G5 to the latest one (6.1.138) and the client is also the most recent one (6.1.130). Yours Miguel Arroz Link to comment Share on other sites More sharing options...
AntonRang Posted March 8, 2008 Report Share Posted March 8, 2008 Sorry, I can't explain the problem (yet?), but I am seeing the same thing -- but inconsistently. For me, I have a G4 Cube acting as a backup server, and am backing up a G5 iMac across the network. The iMac boot drive always backs up properly. An external drive attached to the iMac, which is used partly for time machine backups and partly for regular data storage (on the same partition), usually -- but not quite always -- fails with the -43 "scanning incomplete" error. I'm running Retrospect 6.1.138 & client 6.1.130. My understanding is that this combination should automatically ignore Time Machine data (and in fact, I get the warning that backing up time machine data is not supported); I'm also excluding it with an enclosing-folder-name selector. I had thought that my failures were perhaps due to Time Machine issues (even though that subfolder is excluded and I'm running 6.1.138), but that wouldn't explain why about 1 out of 10 backups succeeds.... Link to comment Share on other sites More sharing options...
twickland Posted March 10, 2008 Report Share Posted March 10, 2008 Miguel and Anton: What kind of backup are you trying to perform: Immediate or Scripted? Are several source volumes included in the backup script or just the single problematic volume? Does the backup fail just for the problematic volume and then go on to back up the remaining source volumes in the script? When we see -43 errors, they usually appear in the backup or compare phases, not the scanning phase, and are not fatal. Offhand, I would first suspect a problem with the source volume's directory if this error appears during the scanning phase. Have you tried running Disk First Aid on the problematic volume? Link to comment Share on other sites More sharing options...
CallMeDave Posted March 10, 2008 Report Share Posted March 10, 2008 My understanding is that this combination should automatically ignore Time Machine data (and in fact, I get the warning that backing up time machine data is not supported); I have not seen that dialog in the current Retrospect build (as don't have a TM drive connected to my Retrospect machine). What is the _exact_ wording of the warning that is shown? >I'm also excluding it with an enclosing-folder-name selector. Selector excluding requires Retrospect to scan the entire volume before deciding whether or not to copy items contained; if there's an issue with scanning a TimeMachine folder (which wouldn't surprise me) then a selector won't help. If you need to keep data on a Time Machine drive that you want to backup with Retrospect, you should keep it in a folder (or folders) and define that folder (or folders) as a Subvolume. Use that Subvolume as the Source for your backup. Retrospect will only scan the Source, and will totally ignore other folders on the same level of the drive (such as your Time Machine folder). Dave Link to comment Share on other sites More sharing options...
Arroz Posted March 10, 2008 Author Report Share Posted March 10, 2008 Hi! In my case, it's very deterministic. This is what I have done: 1) I totally reformatted my internal drive and installed Leopard. I had cloned the disk to an external one, and used that to migrate my home directory with the migration assistant. 2) I installed Retrospect client a few days later, and started to have that problem. If fails with error -43, always in the same point of the scanning phase. 3) I used Intruments to peek at I/O activity of the retrospect deamon, and found out that it fails always in the same file (/System/something). It's absolutely deterministic. 4) I run Disk Utility several times, even from the system DVD, but no errors were found. I borrowed the problematic files from another Leopard installation and replaced them, and Retrospect started failing on another file. This may indicate that the problem is related to some specific system files, but I find it akward because: - The installation (and the file system itself) had about one or two weeks. - The problem was in system files, that are supposed to remain there without any crazy modifications. - I take much care about the security of my machine, and I only install trusted software from trusted sources. - The hard drive is relatively new, and seems to be in perfect conditions. I have no I/O errors in the system log, as it usually happens when the drive has bad sectors. Anyway, I have found a partial solution. As the problems were only in the /System directory, I'm now backing up the /Users directory only. It will make an eventual recover a lot slower, due to the need of installing everything, but at least my data is safe. On the bright side, Time Machine crashes while backing up by drive, so you are still doing much better than them! EDIT: It happens weather I run the backup from a script or immediately. I'm only backing up that drive. The destination backup set (file backup set) is also freshly created, and the drive also seems to be OK. Yours Miguel Arroz Link to comment Share on other sites More sharing options...
Mayoff Posted March 10, 2008 Report Share Posted March 10, 2008 If Time Machine crashes when doing a backup, I am not surprised Retrospect is also failing. What does Time Machine say about the problem? -43 error during scanning is a directory issue. The finder told us an item was in Location X but nothing was found at that location. Link to comment Share on other sites More sharing options...
CallMeDave Posted March 10, 2008 Report Share Posted March 10, 2008 In my case, it's very deterministic... it fails always in the same file (/System/something). Is there a reason that you omit the actual filename, and substitute a mock name? More information is _always_ better then less. - When Retrospect chokes on /System/something, are you able to use other tools to copy this file? Finder copy, cp, ditto? Dave Link to comment Share on other sites More sharing options...
Arroz Posted March 10, 2008 Author Report Share Posted March 10, 2008 Hi! Yes, there is... I don't recall it! I'm sorry. It was something related to image importer plugins, but honestly I don't remember which one. If you find useful, I can run this again with Instruments sneaking in my system. If you do, please say so, and I'll do it as soon as I have some free time. Also, please tell me any other info you would like (like ls -la output of the offending directory, etc), although it all seemed pretty normal when I checked it. I haven't tried to copy those files, but I replaced them with copies from other mac (again, I don't recall if I used Finder or the shell), and it went fine. Yours Miguel Arroz Link to comment Share on other sites More sharing options...
Arroz Posted March 28, 2008 Author Report Share Posted March 28, 2008 Hi! Just an update on this: please forget this issue. Despite Disk Utility said in multiple tests that everything was OK with the file system, I had some bad crashes a few days later and guess what, the file system was totally screwed up. I don't understand how could a file system corrupt in an internal drive a few days after a reformatting, but oh well. Retrospect is starting to really amaze me by it's reliability. It's the second time in a row that a weird Retrospect problem is actually a problem on hardware or in the file system. It's actually more reliable than Apple's own testing tools! Sure will try the beta as soon as I have time. Yours Miguel Arroz Link to comment Share on other sites More sharing options...
CallMeDave Posted March 28, 2008 Report Share Posted March 28, 2008 Retrospect is starting to really amaze me by it's reliability. It's the second time in a row that a weird Retrospect problem is actually a problem on hardware or in the file system. It's actually more reliable than Apple's own testing tools! It was almost exactly six years ago that Adam Engst wrote in the April 2002 issue of TidBITS: "...years of using Retrospect have taught me that it's often an electronic canary in the digital mines. For those unfamiliar with the analogy, miners used to bring a canary down into the mine shaft as an early warning system - if noxious gases caused the canary to keel over, the miners knew to get out. Because of its need to operate at the highest possible speeds with unusual storage devices, all without losing a single bit of data, it's not unusual to see Retrospect throw an error when everything else appears to work fine." I'd say this is still true today. Dave Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.