Jump to content

Majority of files on volume are not backed-up for one particular Mac client (others are fine)


Recommended Posts

Hello,

 

Hopefully, I've posted this in the correct forum. I don't know whether the problem is with the server (Windows) or the client (Mac).

 

We have several Mac clients that are backed-up to a Windows machine. Three of the Mac clients are backed-up as expected. However, with one particular Mac client, only a small subset of the files on the specified source volume are backed-up. (The source volume is the computer's boot volume, e.g., the volume that the OS names "Macintosh HD" by default.)

 

I have looked for disrepencies in the Mac clients, such as disk format, and don't see any obvious differences.

 

The backup script employs "Selecting [All Files]", and no files or directories have been added to the "Privacy" list within the Mac Retrospect client.

 

All versions of Retrospect are up-to-date (both server and clients).

 

There seems to be no rhyme or reason to what is included in the backup and what is not. Please see attached screenshot for details. (Basically, only the Applications directory is backed-up.)

 

I have run the script several times and each time Retrospect sees only the files pictured in the screenshot, and the job completes without warnings or errors.

 

Any ideas as to why the rest of the volume is not being included in the backup?

 

Thanks for any pointers!

post-16558-0-39290800-1344888577_thumb.png

Link to comment
Share on other sites

Thank you for the suggestion, Lennart.

 

We ran Disk Repair on the client (while booted from OS X installation media) and the utility did not report any problems.

 

Running the backup script subsequently produced the very same result.

 

One curious observation is that the files that are backed-up seem to be in alphabetical order; the backup begins with several hidden dot-files, and then proceeds into the A's (but doesn't get far).

 

Might you have any other thoughts or suggestions?

 

Thanks again.

Link to comment
Share on other sites

I thought to try adding the "Applications" directory to the Privacy list, on the client, in case Retrospect was "getting stuck" on some file or directory therein. After this change, Retrospect backs-up nothing. (Well, it attempts to backup just the few hidden files at the root of the disk, per the screenshot in my original post.)

Link to comment
Share on other sites

Have you created a "subvolume"?

Specifying Subvolumes

 

In a volume list, select a volume, then click Make Subvolume from the toolbar or click the Subvolume button in the window. A dialog appears, listing folders at the top level of the selected volume.

You can specify any folder on the selected volume as a Subvolume, including folders nested deep within the folder hierarchy. Select the folder you want to specify as a Subvolume and click Define. (To define the folder name currently displayed in the list box as a Subvolume, click Use.) The Subvolume folder, identified by the icon, then appears with the volumes in the volume list.

If you specify both a Subvolume and its parent volume as Sources, they will be treated as separate objects. However, operations involving the parent volume will include the contents of the folder designated as a Subvolume.

To discard a defined Subvolume:

  1. Select the Subvolume from the Volumes Database window.
  2. Click Forget from the toolbar or press the Delete key.

  3. Forgetting a Subvolume does not affect the contents of the original folder or any files you may have already backed up from it.

Link to comment
Share on other sites

That's a good idea. Thanks, Lennart.

 

When I went to select a subvolume, I was somewhat surprised to see that only the ".vol" and "Applications" directories appear in the list. Please see attached screenshot.

 

If I descend into the Applications directory, the subdirectories that appear are the exact same ones that make it into the backup.

 

Hmm, what could be preventing Retrospect from seeing the rest of the filesystem? Is there a detailed log somewhere, or a verbose debugging mode that could be enabled?

 

For what it's worth, when we performed the Repair Disk operation, we also ran Repair Permissions, and while a handful of entries were corrected, nothing unusual came up.

post-16558-0-46453800-1344957082_thumb.png

Link to comment
Share on other sites

Same result; just the ".vol" and "Applications" directories appear in the subvolume list after forgetting and re-adding the client.

 

There is another volume on the same client, and when I browse for a subvolume on that disk, I can see all of the directories, so the problem seems to be specific to the "Hub" volume.

Link to comment
Share on other sites

  • 3 weeks later...

I can confirm that this problem occurs regardless of whether the Retrospect server is running on Mac OS or Windows. (I have reproduced the issue with the latest version of the Retrospect Server and Client, as of this writing.)

 

This seems to indicate that the problem is with the Retrospect client/agent on the Mac in question.

 

Do the developers read these threads?

Link to comment
Share on other sites

  • 3 weeks later...

Well, I finally have a solution to this issue. Unfortunately, I don't know the root cause, but it seems to be a combination of two factors: a bug with Mac OS itself, and poor (or no) handling of that bug in the Retrospect Client.

 

As suspected, the problem is with the client (not the server). Specifically, this issue occurs when the symbolic link for the source volume that normally exists within "/Volumes/Volume Name", which Retrospect uses as the source moint-point, is replaced with an actual directory by the same name. This exact problem is described at greater length at http://tidbits.com/article/9620 , and, apparently, the problem is quite widespread and problematic for many applications (including Mac OS X itself).

 

Once I realized that Retrospect was reading the source data from "/Volumes/Volume Name", I peeked into the "/Volumes" directory and noticed that "/Volumes/Volume Name" was a real directory (not a symbolic link), and further, that a new symbolic link had been created, but with a different name, so as to avoid the obvious naming conflict (the new link was named "/Volumes/Volume Name 1").

 

I don't know how or when this symbolic link was replaced with a real directory. Given that backups from this client never worked correctly from the time the client was installed, it seems likely that this problem existed before the Retrospect Client was installed. A curious fact is that this directory contained 6GB of duplicate data from the filesystem root (/). How the data was copied to this location is anybody's guess; perhaps during a Time Machine restore gone wrong.

 

In any event, the solution was to:

 

1.) Stop the Retrospect client on the source computer. (I'm not sure if this is necessary or not, but doing so seems prudent.)

 

2.) Delete the real directory (and its contents) from the /Volumes directory.

 

3.) Delete the alternately-named symbolic link from /Volumes. (This could have unknown/unintended consequences if other applications are using the alternate link path and it is deleted.)

 

4.) Create a new symbolic link that points to the correct, corresponding location on the filesystem.

 

I performed this step in the Terminal, e.g.:

 

$ sudo ln -s / "/Volumes/Volume Name"

 

I didn't try creating a "regular alias" via the Finder, so I don't know if that approach would work or not. This approach seems more elegant, though, especially if the "GUI method" via the Finder creates aliases with different ownership and permissions than does a direct call to the "ln" executable with the "-s" switch. The bottom line is that this approach creates the symbolic link with root:admin ownership, which is how Mac OS creates these links under normal circumstances.

 

Perhaps the Retrospect developers already have ideas as to how to solve this problem, but it seems clear that the Retrospect Server should ignore "real directories" in the /Volumes directory on the client/source. Rather, the Server should read only symbolic links that point to other locations on the filesystem.

 

Perhaps this post should be moved to the Retrospect 9 bug reports forum.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...