Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


anothersmurf last won the day on June 8 2013

anothersmurf had the most liked content!

Profile Information

  • Gender
    Not Telling

anothersmurf's Achievements


Newbie (1/14)



  1. This was an issue in the past, but home directories are no longer protected by FileVault; that changed several years ago. FileVault now protects the entire hard drive. Once the drive has been unlocked, it is accessible, even after logout. If you want a third-party example: FileMaker Server is able to host databases for network access when no user is logged in. Perhaps more on point, FileSharing also works with no user logged in. If I can mount a network volume and copy all of its files to my hard drive, why can't Retrospect back up those same files?
  2. This is a problem which seems new to Retrospect 10.5 Client. (I had updated the server to 10.5 several days before the client; there was no problem until the client had been updated as well.) On the server, under Sources, the client machine shows as having two drives. It has always done so, even though one of those volumes has not existed for several months--there seems no way to delete it. But under Options, Retrospect is set to back up only Selected Volumes. The one volume that actually exists is checked, and the other is not. Now that the client is updated to 10.5, Retrospect attempts to back up the unchecked, nonexistant volume (as well as the checked one). I receive email notifications reporting -1101 error, can't access the nonexistant unchecked volume, and the backup log shows this as well. Expected/desired behaviour would be no make no attempt to access explicitly not-selected volumes. Both client and server are Mac Minis running Mountain Lion, fully up to date. Retrospect server & client are both version 10.5.
  3. Other than having to find them (which I agree is a pain), does updating clients work for you? I'm finding that if I'm on the Retrospect Server console and I update a Mac 10.8.5 client which has its firewall turned on, with Retrospect access explicitly allowed under Advanced, the update changes the firewall preference for "retroclient" to not allow. The update actually succeeds, but the server continues to show the client as using the old version of Retrospect since it can no longer connect to the client. And backups fail of course, because the client's firewall doesn't allow it. (The firewall preference for "Retrospect Client" does not change from allowed; it's just "retroclient" that changes.
  4. I've had the same thing happen to me, OS 10.8.4. In my case, the backup set I was restoring from was also on a hard drive, but USB3 and FileVault-encrypted. The data on the drive had been copied from a different (unencrypted) drive, to which it had been originally backed up. But I maintained the same structure on the new drive, and gave the drive itself the same name, so i was surprised I had to use "Locate" at all. "Locate" silently failed whether I pointed just to the drive or to the specific folder in which the backup resided.
  5. Thanks, that makes sense. Though the label in Retrospect's GUI is GB not GiB.
  6. I have a brand new 750GB USB3 hard drive, with no files on it, that I want to use for backup media. Get Info confirms the amount of free space on the drive. But when I create a new media set and point to that drive, Retrospect says that 100% of the drive's capacity is 697GB. I tried to change the 697 to 740, but it changed back into 697. How can I make Retrospect use the full capacity of the drive?
  7. This might be related to "bug 3692", which was referenced elsewhere in the forum re: a problem with backing up manually selected files? I don't know how to see numbered bugs and there's no link so I can't be sure.
  8. I have noticed this too. Propagating permissions, when I do it, is usually done just for thoroughness, when a user reports he can't access a single file he needs and it turns out to be a permissions issue. So my workaround for Retrospect is to manually fix the individual file, spot check others in the same directory etc., instead of propagating. If permissions change, I do want Retrospect to record that change, back it up. The problem is that it backs up even cases in which nothing was changed. My guess is that at the OS level the metadata gets a new change timestamp (or whatever) when permissions are propogated regardless of whether anything was actually changed. If that's true there's not much Retrospect can do about it.
  9. I am trying to troubleshoot a problem in which Retrospect seems not to be backing up the files it is supposed to according to a rule set. To do this I do the following, which shows the bug: 1. Click the Backup icon at the top left corner of the main Retrospect screen. 2. Click Continue, then select the source and choose a rule set (other than All Files) from the desired dropdown. 3. Click the Browse button beside the selected source, then immediately click Done, without changing anything or expanding anything. 4. Observe the Rules dropdown changes to Manual File Selection, then after a second changes again to All Files. 5. Change the Rules dropdown back to the desired rule set, then Continue. 6. Select the target media set and Continue. 7. Now you're on the Summary page. Confirm that the rule set displayed is the correct one. Click Preview and then Done, again without changing anything. Observe that the rule set is now Manual File Selection. The bugs observed in (4) and (7) make it impossible to preview the result of applying the rule to the media set. (If you do expand things when Previewing, nothing is marked as selected to back up.) Expected behaviour: Preview should show what parts of the selected source will be backed up by the selected rule set. Observed behaviour: Preview shows that nothing will be backed up, and changes which rule set has been selected.
  10. In the second screenshot, click Options. You should see Back up: and a dropdown, below which should be a list of volumes on the selected client. Make sure something is selected. That done, you should see a little triangle to the left of the client name. Expand that, then you should be able to browse a volume. You can't browse a client.
  11. Have you tried this/does it work, or is it just a theory? Can a system-level LaunchDaemon or crontab (run daily) be used to automate this for users?
  12. Just by way of follow-up: The problem here was with a piece of network equipment. I don't have details, but I'm told it was replaced, and I'm not getting 519s anymore.
  13. Yeah, I've been seeing a number of 519 errors, some without the soccRecv message. Trouble is there's no consistency... it's not always the same clients, and I can't see any (other?) evidence that the backup server is losing its network connection. 519 is also the error I see when a client goes to sleep or restarts while the backup is taking place, so it's hard to know (without calling the user, if the user is there) whether the 519 is a client problem or, as it's labelled, a network problem. It'd be helpful if the client could tell the server that it's sleeping or shutting down, so the server could report the issue more accurately. If the network connection is interrupted just for an instant, is that enough to trigger the 519 error? Or does Retrospect wait a few seconds to see if the connection comes back, and if it does proceed? For now, I'll try running a (different) cable across the office to a different ethernet jack, see if that makes a difference. Thanks
  14. I'm seeing the message "soccRecv: recv failed, error 60" in my logs for several clients (but not all of them), followed by error -519 (network communication failed). What does this error message mean, and what's the solution?
  • Create New...