monoclast Posted May 11, 2010 Report Share Posted May 11, 2010 Ever since I set up Retrospect on a new machine, I've noticed that whenever it is backing up my main work station, something strange happens: It starts the Copy phase of my /Users folder like normal, which takes a while, and then when it gets to the Compare phase, it asks for a previous tape to be inserted. For instance, yesterday, Retrospect asked for tape #4 and started the Copy phase for the Users folder on my Mac Pro. This morning when I looked at Retrospect, the log indicated it was done with the Copy phase, and was about to Compare the Users folder, and Retrospect was asking for tape #2 to be inserted! Why the back-and-forth? What can I do to prevent this? Quote Link to comment Share on other sites More sharing options...
Daniels Posted May 11, 2010 Report Share Posted May 11, 2010 Does it ever ask for additional tapes during the backup? If you have to switch tapes to complete the copy phase then it is normal for it to ask for the previous tape during the compare phase since that is where the data lies. On the other hand if you do not have to switch tapes during the copy phase then have you tried resetting the backup set since it sounds like it is trying to compare old data stored on previous tapes in the backup set. Quote Link to comment Share on other sites More sharing options...
monoclast Posted May 12, 2010 Author Report Share Posted May 12, 2010 Ahhh. I see what you're saying. Yes, it does ask for additional tapes during the copy phase. I guess I'm just copying way more data than I used to be, so it's using multiple tapes for this backup. It's just inconvenient to have to swap back to previous tapes like that! Thanks for the explanation. Quote Link to comment Share on other sites More sharing options...
Daniels Posted May 12, 2010 Report Share Posted May 12, 2010 It might be wise to invest into a library system so you pre-load all the tapes ahead of time. Quote Link to comment Share on other sites More sharing options...
monoclast Posted May 12, 2010 Author Report Share Posted May 12, 2010 Yeah - certainly would make life a bit easier. If this were for an office, I would probably consider a 1U rack-mount tape library, but it's just for home use, so the external Firewire tape drive will have to do! Quote Link to comment Share on other sites More sharing options...
monoclast Posted May 19, 2010 Author Report Share Posted May 19, 2010 I'm still having trouble understanding the backup process. Perhaps someone can help me understand. Here's what I see in the Retrospect log for a sample backup session: Normal backup using macro at 5/17/2010 10:00 PMTo backup set Backup Set A... . . . 5/17/2010 10:46:02 PM: Copying Users on macpro 5/17/2010 11:51:53 PM: Comparing Users on macpro (bunch of files reported with different modification dates, data sizes, and so on) 5/18/2010 12:45:14 AM: 30 execution errors Completed: 7690 files, 9.1 GB Performance: 167.8 MB/minute (162.5 copy, 173.3 compare) Duration: 01:59:12 (00:08:57 idle/loading/preparing) It seems like this is what is happening: 1. Retrospect connects to the network client. 2. Retrospect starts the Copy phase, where it copies files from the client to the server, and writes those files to tape. Often, Retrospect will ask for new tapes during this phase. 3. Retrospect starts the Comparison phase. Often it asks for a previous tape during this phase. Why would Retrospect write files to tape before doing the comparison?? Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted May 19, 2010 Report Share Posted May 19, 2010 I'm still having trouble understanding the backup process.... Why would Retrospect write files to tape before doing the comparison?? First Retrospect writes new new/changed files to tape. Then Retrospect compares what was actually written to the tapes with what is (still) on the source (hard drives). What kind of "comparison" did you expect Retrospect would do? Quote Link to comment Share on other sites More sharing options...
Daniels Posted May 19, 2010 Report Share Posted May 19, 2010 (edited) Retrospect does the compare phase after the copying phase is complete. This is probably done so if a file is split over multiple tapes Retrospect can compare the entire file instead of comparing each half since one half may not have the appropriate data for comparison. I have not heard of any backup system do their compare phase before the copying phase is complete. Edited May 19, 2010 by Guest Quote Link to comment Share on other sites More sharing options...
monoclast Posted May 19, 2010 Author Report Share Posted May 19, 2010 (edited) I'm still having trouble understanding the backup process.... Why would Retrospect write files to tape before doing the comparison?? First Retrospect writes new new/changed files to tape. Then Retrospect compares what was actually written to the tapes with what is (still) on the source (hard drives). What kind of "comparison" did you expect Retrospect would do? In my mind, "compare" means "compare files already in the backup set with files on the client to see what has changed (what needs to be backed up)". It seems like what you are describing is a verification phase, to determine if what was written to tape is valid. I personally think using the term "compare" for that is asking for mis-interpretation. In fact, Retrospect uses the term "verification" elsewhere in the UI and in documentation. At any rate, I've read that the VXA tape drive I am using does its own verification of data written to tape, which seems to indicate Retrospect is doing that extra work for nothing. I've disabled verification in my backup scripts. Edited May 19, 2010 by Guest Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted May 20, 2010 Report Share Posted May 20, 2010 In my mind, "compare" means "compare files already in the backup set with files on the client to see what has changed (what needs to be backed up)".That is called "matching", which you can see in the Retrospect activity monitor. See attached screenshot. "Matching" is not written in the log file. Nor are the steps "Scanning" or "Building snapshot", just to name two more steps in a backup sequence. It seems like what you are describing is a verification phase, to determine if what was written to tape is valid. Exactly. If you look in the manual Index for "compare" it says "see Verification option". But I agree it should say "Verification" in the log. Quote Link to comment Share on other sites More sharing options...
monoclast Posted May 20, 2010 Author Report Share Posted May 20, 2010 I've read that the VXA tape drive I am using does its own verification of data written to tape, which seems to indicate Retrospect is doing that extra work for nothing. I've disabled verification in my backup scripts. Since disabling Verification yesterday, I notice that my system log is no longer full of SCSITaskUserClient - Invalid arguments messages, as mentioned in this forum post! This leads me to believe the two may be related! Quote Link to comment Share on other sites More sharing options...
Daniels Posted May 20, 2010 Report Share Posted May 20, 2010 (edited) The errors were probably occuring because Retrospect was trying to verify the tapes while the tape drive itself was doing its verification and Retrospect was not able to access the device. Since it sounds like you want each tape to be examined after copying then I would go with the devices verification and turn off verification like you did in Retrospect. Edited May 20, 2010 by Guest Quote Link to comment Share on other sites More sharing options...
monoclast Posted May 20, 2010 Author Report Share Posted May 20, 2010 The errors were probably occuring because Retrospect was trying to verify the tapes while the tape drive itself was doing its verification and Retrospect was not able to access the device. Since it sounds like you want each tape to be examined after copying then I would go with the devices verification and turn off verification like you did in Retrospect. Unfortunately, I don't think you're right, because the errors piled up in the system log even while Retrospect was idle (not verifying data). In fact, they started as soon as Retrospect launched, and stopped as son as Retrospect quit. It's certainly very interesting that they appear to have stopped completely since I disabled Verification in each of my backup scripts, but I have to think there's some sort of interesting software flaw at work here. Quote Link to comment Share on other sites More sharing options...
Daniels Posted May 20, 2010 Report Share Posted May 20, 2010 Then that is very interesting however it sounds like Retrospect is having trouble accessing the device. This definitely sounds like a software flaw like you said. I am wondering if having the SCSI device connected by Firewire is causing the problem. Quote Link to comment Share on other sites More sharing options...
monoclast Posted May 21, 2010 Author Report Share Posted May 21, 2010 It seems I spoke too soon. This morning when Retrospect started backing up, the messages are back: May 21 09:44:34 backup kernel[0]: SCSITaskUserClient - Invalid arguments: scatterGatherEntries = 1, requestedTransferCount = 0, transferDirection is 0 May 21 09:45:04: --- last message repeated 2 times --- May 21 09:46:38 backup kernel[0]: SCSITaskUserClient - Invalid arguments: scatterGatherEntries = 1, requestedTransferCount = 0, transferDirection is 0 May 21 09:47:34 backup kernel[0]: SCSITaskUserClient - Invalid arguments: scatterGatherEntries = 1, requestedTransferCount = 0, transferDirection is 0 May 21 09:48:04: --- last message repeated 4 times --- May 21 09:48:30 backup kernel[0]: SCSITaskUserClient - Invalid arguments: scatterGatherEntries = 1, requestedTransferCount = 0, transferDirection is 0 May 21 09:49:00: --- last message repeated 4 times --- May 21 09:49:26 backup kernel[0]: SCSITaskUserClient - Invalid arguments: scatterGatherEntries = 1, requestedTransferCount = 0, transferDirection is 0 May 21 09:49:56: --- last message repeated 4 times --- May 21 09:50:20 backup kernel[0]: SCSITaskUserClient - Invalid arguments: scatterGatherEntries = 1, requestedTransferCount = 0, transferDirection is 0 May 21 09:50:50: --- last message repeated 4 times --- May 21 09:51:28 backup kernel[0]: SCSITaskUserClient - Invalid arguments: scatterGatherEntries = 1, requestedTransferCount = 0, transferDirection is 0 May 21 09:51:58: --- last message repeated 4 times --- May 21 09:52:23 backup kernel[0]: SCSITaskUserClient - Invalid arguments: scatterGatherEntries = 1, requestedTransferCount = 0, transferDirection is 0 May 21 09:52:53: --- last message repeated 4 times --- Quote Link to comment Share on other sites More sharing options...
monoclast Posted May 21, 2010 Author Report Share Posted May 21, 2010 Then that is very interesting however it sounds like Retrospect is having trouble accessing the device. This definitely sounds like a software flaw like you said. I am wondering if having the SCSI device connected by Firewire is causing the problem. Unfortunately I have no control over that. This is a Firewire VXA-2 tape drive! Quote Link to comment Share on other sites More sharing options...
Daniels Posted May 21, 2010 Report Share Posted May 21, 2010 It definitely looks like it is a communication issue between Retrospect and the backup device. Have you tried other Firewire SCSI devices to see if maybe it is the drive itself? I would also make sure that the firewire ports are working correctly. Quote Link to comment Share on other sites More sharing options...
rhwalker Posted May 21, 2010 Report Share Posted May 21, 2010 It definitely looks like it is a communication issue between Retrospect and the backup device. Have you tried other Firewire SCSI devices to see if maybe it is the drive itself? I would also make sure that the firewire ports are working correctly. Respectfully, I don't think you have a clue. I understand that you are trying to be helpful, but the original poster should disregard your posts. There is no such thing as a "Firewire SCSI" device, and the Exabyte VXA drive is certainly no such animal. Russ Quote Link to comment Share on other sites More sharing options...
Daniels Posted May 24, 2010 Report Share Posted May 24, 2010 What I was trying to describe was an external device that connects to the computer via Fireware but the device inside is connected via SCSI interface. If no such device exists or Exabyte VXA drive does not use an internal SCSI interface then the problem lies in that Retrospect is trying to use a SCSI connection that does not exist which would be a bug. Quote Link to comment Share on other sites More sharing options...
rhwalker Posted May 24, 2010 Report Share Posted May 24, 2010 What I was trying to describe was an external device that connects to the computer via Fireware but the device inside is connected via SCSI interface.If no such device exists or Exabyte VXA drive does not use an internal SCSI interface then the problem lies in that Retrospect is trying to use a SCSI connection that does not exist which would be a bug. No, that Retrospect is using specified API calls that just happen, for legacy reasons, to have the prefix SCSI. If you don't have the device in question so that you can test the poster's problem for reproducibility, or if you don't have any relevant experience, don't speculate. It's doesn't help to contribute noise. Russ 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.