rsteele Posted February 3, 2008 Report Share Posted February 3, 2008 I'm using Retrospect version 6.1.138 on a new intel iMac with system 10.5.1 for backup and duplication of that iMac and two other Macs over a network. The client software is version 6.1.130. One of these networked clients is also a new iMac running OS 10.5.1. The other is an older iBook, running OS 10.4.11. When I try try to "duplicate" the client volumes over the network, the duplication process aborts midway through the process. Here's a typical resulting log entry: "Can't write file "Install LimeWire.bom", error -1 (unknown), path: "Macintosh HD/Library/Receipts/Install LimeWire.pkg/Contents/Resources/Install LimeWire.bom". Trouble writing files, error -1 (unknown). Execution incomplete. Remaining: 176339 files, 15.8 GB Completed: 501755 files, 14.9 GB etc.... For each client the log entry for the failure is always identical, but the problematic file differs on the two computers. This problem first surfaced in December when all Macs had PPC processors, and seems to have coincided with my upgrade to the current version of Retrospect. However, EMC tech support indicates that the problem lies with the client computers, not Retrospect. I'm on the verge of abandoning Retrospect altogether. Any help would be appreciated. Link to comment Share on other sites More sharing options...
CallMeDave Posted February 3, 2008 Report Share Posted February 3, 2008 > When I try try to "duplicate" the client volumes over the network... The description you provide of your setup is unclear. - Please confirm that the Client machine is the Source; but what is the Destination volume? Is it the internal hard drive of the machine running Retrospect? Is it an external drive? Please describe your configuration more completely. "Can't write file "Install LimeWire.bom", error -1 (unknown), path: "Macintosh HD/Library/Receipts/Install LimeWire.pkg/Contents/Resources/Install LimeWire.bom". The error suggests a problem with writing the file, which makes knowing the specifics requested above that much more important. What is the Destination Volume, is it the same physical/logical volume for both problem clients, etc. - Is the problem file always the same (on the same machine)? - If you define /Library/Receipts/Install LimeWire.pkg/Contents/Resources/ as a Subvolume and use that as a Source, will the same file fail? - If you change the Destination volume to some other physical media, does the problem persist? > However, EMC tech support indicates that the problem lies with the client computers, not Retrospect. What other tests did they have you perform? Dave Link to comment Share on other sites More sharing options...
rsteele Posted February 3, 2008 Author Report Share Posted February 3, 2008 Dave, Thank you for responding. Sorry for erring on the side of brevity. Retrospect resides on my principal computer. All volume "duplications" with Retrospect are performed "immediately" for the entire volume. My principal computer, which runs the Retrospect software, is a new 2.8 GHz intel iMac with 4 GB of ram connected to a 1 TB LaCie Firewire 800 external drive partitioned into separate volumes that I use for creating a clone of the iMac's hard drive on one of these partitions and for creating clones of the hard drives of at least two Mac clients (an iBook and a new iMac) and sometimes others over a wired ethernet network. The 1 TB external drive is new, and is intended to replace a couple of smaller external LaCie Firewire 400 drives. These Firewire 400 drives are still connected to my iMac via the Firewire 400 port. The failed duplications for the iBook have been occurring to a destination volume on one of the Firewire 400 drives, but I'll try the iBook duplication tonight using a partition on my new 1 TB drive as the destination. I'm skeptical that this will be of benefit, since the duplication failure for the iMac client is already occurring when another partition of this same drive is used as the destination. I've been using Retrospect successfully for many years in the identical manner, performing duplications and incremental backups of my principle Mac to locally attached Firewire drives, and of two or more clients over the network to these same Firewire drives. The problem in creating the volume duplications seemed to coincide with the latest Retrospect upgrade, said to be necessary for Leopard, and it occurs only and always with the clients. Each failure is accompanied by the same message, indicating that a file cannot be written. It's always the same file that cannot be written on a particular client. Since the duplication process aborts at that point, it is possible that other "problem files" would have been encountered later in the duplication process. In the case of the G3 iBook client, the file that cannot be written doesn't exist at the referenced location when looked for. In the case of the new iMac client, the referenced file that cannot be written (Install Limewire.bom) is an alias, the original for which is a Unix executable file by a different name. I have had no problem performing full or incremental backups of the clients, although I haven't yet tried to backup the new client iMac, concentrating instead on duplicating its hard drive. On two separate calls to EMC tech support, no suggestions have been offered... Personally, I think that if Retrospect cannot write a file during the duplication process, it should report the problem in the log, and then continue to write the other 99.9999% of the files that can be written. Leopard and Retrospect's 6.1.138 update to deal with Leopard are new. It is expected that isolated problems might be encountered. I'm disappointed that so far EMC tech support has simply blamed the Mac OS for the problem, rather than attempting to report, better understand, and address the failed interaction between the Mac OS and Retrospect. Richard Link to comment Share on other sites More sharing options...
CallMeDave Posted February 3, 2008 Report Share Posted February 3, 2008 - If you define /Library/Receipts/Install LimeWire.pkg/Contents/Resources/ as a Subvolume and use that as a Source, will the same file fail? - When the Duplicate fails, is the Destination volume empty? Or is Retrospect Matching files in advance of the Duplicate operation? Dave Link to comment Share on other sites More sharing options...
rsteele Posted February 4, 2008 Author Report Share Posted February 4, 2008 Dave, I don't know how to define a subvolume, but I'll look into it, give it a try, and get back to you on that score if I figure it out. Out of curiosity, how will this help? In most cases, I'm trying to duplicate to a destination volume that has already suffered a failed attempt at duplication. However, in the case of the new client iMac/new 1 TB Firewire drive combination, the failed duplication attempt was to a newly-partitioned, empty volume. Since our last exchange, I attempt once again to duplicate my client iBook hard drive over the network, this time to an empty fresh drive partition. Once again, the duplication attempt failed at the same point, for the same reason, and the duplication process aborted as before. This evening I'll resign myself to a cloning of the iBook with SuperDuper (shame on you, Retrospect, if a bootable copy results), and I'll de-install Limewire from the client iMac to see if drive duplication can then proceed. Richard Link to comment Share on other sites More sharing options...
rhwalker Posted February 4, 2008 Report Share Posted February 4, 2008 Quote: I don't know how to define a subvolume, but I'll look into it, give it a try, and get back to you on that score if I figure it out. Out of curiosity, how will this help? Configure > Volumes, highlight a volume, click the Subvolume button It will limit the source stuff that Retrospect will scan, and will make your testing MUCH faster. Russ Link to comment Share on other sites More sharing options...
rsteele Posted February 4, 2008 Author Report Share Posted February 4, 2008 Dave and Russ, Thank you for the help. Re networked iMac client: When defining "/Library/Receipts/Install LimeWire.pkg/Contents/Resources/ as a subvolume for the duplication source, the same file failed. Re networked iBook client: SuperDuper readily produced a bootable duplicate of the iBook's hard drive that appears to function normally, for whatever that's worth regarding the iBook's Retrospect problems. Richard Link to comment Share on other sites More sharing options...
CallMeDave Posted February 4, 2008 Report Share Posted February 4, 2008 > When defining "/Library/Receipts/Install LimeWire.pkg/Contents/Resources/ as a subvolume for the duplication > source, the same file failed. Good (!). As Russ noted, this allows for easy testing without the agony of scanning an entire OS X volume. - What happens when you attempt to Duplicate that same defined Subvolume to an empty folder, also defined as a Subvolume, on your boot drive? A failure on the above test would help to rule out a problem with the external storage system (drive, bridge board, FireWire bus, etc). Although given the non-randomness of the error (same file every time) it is more likely to be client computer/file/filesytem related, but ruling out stuff is always good when it's easy to do. > SuperDuper readily produced a bootable duplicate of the iBook's hard drive that appears to > function normally, for whatever that's worth regarding the iBook's Retrospect problems. But wasn't the Source volume for the SuperDuper! clone directly attached to the iBook? Seems to be a different situation entirely then troubleshooting Retrospect's Client communication functionality. Russ and I often agree here that other non-Retrospect solutions are good for direct-connect Duplication/Cloning. But Retrospect's client/server model is unavailable to those products, IIRC. Link to comment Share on other sites More sharing options...
rsteele Posted February 4, 2008 Author Report Share Posted February 4, 2008 When trying to duplicate the same defined subvolume on the client iMac to a test folder on the desktop of the host iMac running Retrospect, the same duplication failure occurs. I realize that Retrospect gives me over the network functionality not available with other products, such as SuperDuper. Therefore I'm intent on resolving the issue, if possible. I meant only to imply that perhaps there isn't a problem inherent with system or third party software on my very well maintained clients that should prevent creating a functional clone of their hard drives, and therefore I am not encouraged that going through the considerable time and effort of hard drive reformatting and re-installation of system software, third party software, and personal documents would likely be of benefit in solving the client duplication issue with Retrospect. In my mind, the problem lies with Retrospect until convinced otherwise. Richard Link to comment Share on other sites More sharing options...
Mayoff Posted February 4, 2008 Report Share Posted February 4, 2008 What happens when you make a copy of the problem folder and try to duplicate the copy instead of the original. What happens when using Retrospect to duplicate the problem folder to another folder on the local computer instead of trying to write it over the network? Link to comment Share on other sites More sharing options...
rsteele Posted February 4, 2008 Author Report Share Posted February 4, 2008 >What happens when you make a copy of the problem folder and try to duplicate the copy instead of the original?< >What happens when using Retrospect to duplicate the problem folder to another folder on local computer instead of trying to write it over the network?< When I try to duplicate a copy of the problem folder over the network to a firewire drive destination attached to the host computer running Retrospect, the same failure occurs as with the original folder. When I transfer a copy of the problem folder to the host computer running Retrospect and attempt to duplicate the folder locally from the host computer to the attached Firewire destination, the duplication succeeds. Richard Link to comment Share on other sites More sharing options...
CallMeDave Posted February 4, 2008 Report Share Posted February 4, 2008 Quote: When I try to duplicate a copy of the problem folder over the network to a firewire drive destination attached to the host computer running Retrospect, the same failure occurs as with the original folder. When I transfer a copy of the problem folder to the host computer running Retrospect and attempt to duplicate the folder locally from the host computer to the attached Firewire destination, the duplication succeeds. However these were not the questions Robin asked. What happens when you make a copy of the problem folder and try to duplicate the copy instead of the original? Means make a Finder copy on the remote client machine of the folder containing the problem file. Then, from the host computer running Retrospect, define that newly created duplicate folder as the Subvolume that you'll use as your Source. What happens when using Retrospect to duplicate the problem folder to another folder on local computer instead of trying to write it over the network? Means use the Finder to create a new empty folder on the remote client machine. Then, from the host computer running Retrospect, define that newly created empty folder as a Subvolume, and use that as your Destination, keeping the problematic Subvolume as your Source as before. Link to comment Share on other sites More sharing options...
rsteele Posted February 4, 2008 Author Report Share Posted February 4, 2008 Dave, In the first instance that's what I did...used a finder copy of the problem folder that was on the client desktop as the new source and then tried to duplicate that source across the network to a destination firewire drive. Since Robin did not specify the destination, I assumed it was across the network to a firewire drive attached to the host, and that this exercise was merely to test for any behavioral differences between the original folder and a copy of that folder. In the second instance, just as you interpreted Robin's suggestion regarding "local computer," I tried to use the original file on the client as the source and a temporary folder on the client's computer as the destination. Retrospect won't allow that, because "Error: Source and Destination on the same Backup Client." I think we both misinterpreted Robin. I think that he intended for me to transfer a copy of the problem folder to the host computer running Retrospect, and then see if I can duplicate that problem folder to a temporary folder on the hard drive of the host computer. Retrospect allows that and the duplication was successful. Richard Link to comment Share on other sites More sharing options...
Mayoff Posted February 4, 2008 Report Share Posted February 4, 2008 Actually, I was thinking you could install Retrospect onto the client computer with the problem and run the test local to that computer rather then over the network. Link to comment Share on other sites More sharing options...
CallMeDave Posted February 4, 2008 Report Share Posted February 4, 2008 Quote: Retrospect won't allow that... Oh; I wonder when that was added. I remember doing client-to-itself Duplicates long ago, and marveling at how silly (and slow) it was to suck the data into Retrospect and then spit it back to the originating client. Makes sense that they turned that ability off. Sorry for (my part of) the confusion. But it _is_ noteworthy that a local duplicate, which would have new file identifiers and reside on different physical locations on the drive, still exhibits the problem. Have you run DiskUtility and/or DiskWarror on the client drive? Link to comment Share on other sites More sharing options...
rsteele Posted February 4, 2008 Author Report Share Posted February 4, 2008 <Have you run DiskUtility and/or Diskwarrior on the client drive?> I have run DiskUtility and DiskWarrior on the client iBook. I have run DiskUtility only to repair permissions on the new iMac, but not to verify or repair the disk. The new client iMac is only a week old, and my version 4.0 of DiskWarrior is not Leopard-compatible. I notice that Alsoft has just released Leopard-compatible, version 4.1 of DiskWarrior. A means for owners of version 4.0 to create their own updated version 4.1 CD will soon be made available. http://www.alsoft.com/DiskWarrior/support.html Richard Link to comment Share on other sites More sharing options...
rsteele Posted February 5, 2008 Author Report Share Posted February 5, 2008 Quote: Actually, I was thinking you could install Retrospect onto the client computer with the problem and run the test local to that computer rather then over the network. I'll be glad to do that as well and get back to you, but this all sort of reminds this admitted layman of the Clint Eastwood movie title, "Every Which Way But Loose." It looks like Retrospect, v. 6.1.138, is not going to duplicate this file across the network, and because Retrospect unhandily terminates the entire duplication process because of a single file on both clients, there is no way of telling how many other "problematic" files lie in the path of a successful network duplication. The next logical step might be to install an earlier version of Retrospect on the OS 10.4.11 iBook, connect a Firewire drive to the iBook, and then see if I can successfully clone the new iMac client across the network. If the iMac client volume duplication is successful, the implication might be that my network duplication problem is Retrospect version related. This has been my suspicion from the outset, since the problem roughly coincided with the version update. For that matter maybe it's not absolutely necessary that my OS 10.5.1 intel iMac host run version 6.1.138 of Retrospect. I'll try to call EMC Tech Support again about that, as well as to emphasize that with or without a successful resolution to my network duplication issue, the existence of this problem and the difficulty of trouble-shooting it should be relayed upstairs Richard Link to comment Share on other sites More sharing options...
rsteele Posted February 6, 2008 Author Report Share Posted February 6, 2008 Quote: Actually, I was thinking you could install Retrospect onto the client computer with the problem and run the test local to that computer rather then over the network. Thanks. I have done it. Retrospect when loaded onto and run from the client computer successfully duplicates the problematic folder to a temporary folder on its own desktop. After reviewing the history of what I have done toward trouble-shooting the problem with the guidance of forum contributors, EMC tech support feels that the next step is to run a much more elaborate form of the log on the failed network duplication process. I hope for this to happen over the next few days. If the process works, and I learn something useful, I'll give you guys the feedback. Thanks again. Richard Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.