"no files need to be copied" since Leopard

[reggoboy]

Hello folks.

 

Around 11/24, my backups started showing a "successful" backup which completed very rapidly and said "no files need to be copied". However, there are definitely files that need backing up, so I don't understand what's going on.

 

Around 11/24 was when I upgraded the client machine to Leopard (server is still running Tiger). I don't know if that has anything to do with it. Both clocks are in sync. I did notice that I was getting "client is not visible on network" which led me to realize the Client configuration was broken on the server. Going in to Retrospect to Configure the Client seemed to fix that.

 

I also noticed that I started getting "incompatible version" messages which led me to remember that my server didn't have the latest Retrospect update, so then I installed it (6.1.138).

 

But now I'm getting this "no files need to be copied" message. I tried Rebuilding the Catalog last night which took about 2 hours and completed successfully. But the regular backup which followed still had "no files need to be copied".

 

Any suggestions?

 

Thanks!

 

Dave

[Mayoff]

What does "selecting" say in your script?

[twickland]

If you go to Configure> Volumes, can you browse the contents of the client volume? Can you see everything on the volume?

 

What Selector or section criteria are you using for your backup? Is it possible that anything was changed here?

 

If you go to Configure> Clients> [name of client], what is configured to be backed up? Desktop, Startup Volume, Selected Volumes? If the latter, are the correct volumes highlighted in the "Volumes" tab?

 

Do you get the same results when running an Immediate Backup of this client using the selector "All Files?" (Try this on a subvolume to save time if your normal selector is significantly more restrictive.)

[rhwalker]

I'm wondering if the client might have been upgraded to Leopard by an "erase and install", in which case the volume ID would have changed, making Retrospect think that there is a different volume that might not be in the backup list (depending on what client settings you have on Retrospect for the volumes to be backed up - I usually choose "Startup Volume" rather than a specific volume just to handle this case).

 

Twickland's suggestions for investigation seems like the right ones.

 

Russ

[reggoboy]

Quote:

---

I'm wondering if the client might have been upgraded to Leopard by an "erase and install", in which case the volume ID would have changed, making Retrospect think that there is a different volume that might not be in the backup list

 

 

---

 

Thanks for the idea. No, I upgraded to Leopard via Archive and Install. However, I did have the problem you describe about a month ago when I did, in fact, replace the hard disk in question with a new, bigger one. But I resolved that and got things working again prior to this situation.

 

Dave

[reggoboy]

Quote:

---

If you go to Configure> Volumes, can you browse the contents of the client volume? Can you see everything on the volume?

 

---

 

Oh dear. When I click Browse, the volume does open, but it says there are 0 files! This is my home directory, so I think you're onto something!

 

Quote:

---

What Selector or section criteria are you using for your backup? Is it possible that anything was changed here?

 

---

 

Just All Files Except Cache Files.

 

Quote:

---

If you go to Configure> Clients> [name of client], what is configured to be backed up? Desktop, Startup Volume, Selected Volumes? If the latter, are the correct volumes highlighted in the "Volumes" tab?

 

---

 

Hmm. It says Desktop. What does that popup do? Does that mean, in spite of the fact that my script says to use the home directory subvolume on the client machine as my source, is this going to try to just backup the desktop?

 

However, even if I change this to Selected Volumes, the Browsing issue you asked about first still shows Zero files.

 

Quote:

---

Do you get the same results when running an Immediate Backup of this client using the selector "All Files?" (Try this on a subvolume to save time if your normal selector is significantly more restrictive.)

 

---

 

Interesting idea. I just tried it and, yes, I get the same result of "no files need to be copied", and this is even though I changed the client popup to be Selected Volumes.

 

So what next? Do I have to delete that subvolume and add it again? Why did this happen?

 

Thanks again,

 

Dave

[rhwalker]

Quote:

---

Does that mean, in spite of the fact that my script says to use the home directory subvolume on the client machine as my source, is this going to try to just backup the desktop?

 

---

No, see page 97 of the Retrospect 6.x Users Guide:

 

Quote:

---

Volumes to Access:

...

Client Desktop

resolves to all volumes local to the client computer, except for floppy disks, shared volumes (such as file servers), read-only volumes (such as CD-ROMs), and empty volumes.

 

---

There are also some tables in the Users Guide to explain things more.

 

Quote:

---

Do I have to delete that subvolume and add it again?

 

---

Nah, it's harmless, but you could delete it if you want. It only has meaning if used in a script as a source or destination. It's purely a Retrospect abstraction. But see also "man 2 chroot", which is how I suspect that Retrospect implements subvolumes.

 

But I'm a bit baffled by what you are reporting.

 

Quote:

---

When I click Browse, the volume does open, but it says there are 0 files!

 

---

If you are talking about the line in the upper right corner of the window (0 files, zero K), that's simply the number of files that are selected. Do you see any files listed? That's what matters.

 

Immediately after clicking Browse, a little "Scanning..." window should pop up while the client scans the filesystem tree. Do the number of folders and number of files increment up from zero while this is happening?

 

You know, if your browser doesn't show any listing of files, I'm starting to wonder whether your Retrospect Client is running as "setuid root" as it should. Perhaps it doesn't have permission to see the files if that's the case. Does the browser list any files?

 

If it doesn't, then do the following:

 

In Terminal, please do the following on the client computer:

Code:

---

ls -al /Applications/Retrospect\ Client.app/Contents/Resources/pitond

---

I suggest you copy and paste that line so that you get it right. Please report the results. You should get one line of output. I'm most interested in the six characters of permissions that are listed, plus the owner and group that are listed.

 

Also, with the Retrospect client running (doesn't have to be backing up), in Terminal, please do the following on the client computer (open your terminal window up very wide so that the line is not cut off):

Code:

---

ps axlwww | fgrep pitond

---

again, I suggest you copy and paste that line so that you get it right. Please report the results. You should get two lines of output; I'm most interested in the first number on the pitond line.

 

Russ

[CallMeDave]

So many tantalizing hints:

 

> When I click Browse, the volume does open, but it says there are 0 files! This is my home directory

 

> my script says to use the home directory subvolume on the client machine as my source

 

 

Go to Configure->Volumes

In the Volumes Database window, you have your client listed under the Backup Clients container, with your defined subvolume under that.

Click on your subvloume, and then click on the Subvolume... button in the upper right.

- In the resulting non-standard (custom retrospect) file dialog box, is the name of the folder correct in the center pop-up menu?

- If you click and hold on this pop-up menu, is the path to your expected folder correct?

 

 

> Do I have to delete that subvolume and add it again?

 

Probably yes.

 

> Why did this happen?

 

> I upgraded to Leopard via Archive and Install

 

You may have answered your own question here. Perhaps, during the Archive and Install routines, Apple does something with the directories such as /Users/Foo/

[rhwalker]

Quote:

---

> Do I have to delete that subvolume and add it again?

 

Probably yes.

 

---

(CallMe)Dave, I think that you and I interpreted Dave (Kitabjian)'s question differently. I thought that his question was in response to twickland's testing suggestion to create a subvolume to shorten the testing cycle:

 

Quote:

---

Do you get the same results when running an Immediate Backup of this client using the selector "All Files?" (Try this on a subvolume to save time if your normal selector is significantly more restrictive.)

 

---

and that he was inquiring whether he had to delete this temporary subvolume used to shorten the testing cycle.

 

Russ

[CallMeDave]

Well, as is often the case online, communication needs to be specific to avoid incorrect assumptions and interpretations.

 

Twickland suggested:

 

"If you go to Configure> Volumes, can you browse the contents of the client volume? "

 

To which (the other) Dave answered:

 

"When I click Browse, the volume does open, but it says there are 0 files! This is my home directory,..."

 

 

 

When Twickland gave his suggestion there had yet to be any indication that Dave was discussing a defined subvolume, not the root of his hard drive.

 

Dave interpreted Twickland's use of "the client volume" to mean "the defined subvolume." That's the subvolume he wonders if he'll have to recreate.

 

Also, the client configuration settings are a red herring, as they are only valid for Containers, not for specific source volumes.

 

Dave has a defined subvolume that shows nothing in the Retrospect Browser, even though that volume actually contains many files and folders. Retrospect is doing something wrong, and my gut tells me that the volume ID that was valid for his home directory is now (after the archive and install) being used for some other directory (one that contains no files). Giving Retrospect a chance to display its assumed path seems like a logical first step.

 

Dave

[reggoboy]

Quote:

---

So many tantalizing hints:

 

> When I click Browse, the volume does open, but it says there are 0 files! This is my home directory

 

> my script says to use the home directory subvolume on the client machine as my source

 

 

Go to Configure->Volumes

In the Volumes Database window, you have your client listed under the Backup Clients container, with your defined subvolume under that.

Click on your subvloume, and then click on the Subvolume... button in the upper right.

- In the resulting non-standard (custom retrospect) file dialog box, is the name of the folder correct in the center pop-up menu?

- If you click and hold on this pop-up menu, is the path to your expected folder correct?

 

 

---

 

Holy stink!! I think you're on to something here! The path it shows is:

 

Macintosh HD -> Previous Systems.localized -> 2007-11-24_2105 -> Users -> Foo

 

Looks like you're right: Archive & Install probably sent Retro headed down the wrong "path". Perhaps Retro is using inodes or somesuch to id "Volumes".

 

Quote:

---

> Do I have to delete that subvolume and add it again?

 

Probably yes.

 

 

---

 

Okay, I'll do it. But what a chore, especially after just redoing everything due to a HD replacement a month ago resulting in a similar confusion to Retro. Let me ask this: if Retro is trying to be smart by tracking inodes rather than filenames, is it smart enough to avoid backing up a large directory (say, a backup of my Photo Library) if I simply rename it?

 

Guys, thanks a bundle. You've been great. If I have any more issues, you'll be sure to hear from me ;-)

 

Dave

(Call Me Dave K, just to be clear)

[reggoboy]

To be complete, let me answer some of your questions...

 

Quote:

---

 

 

Quote:

---

When I click Browse, the volume does open, but it says there are 0 files!

 

---

If you are talking about the line in the upper right corner of the window (

0 files, zero K

), that's simply the number of files that are selected. Do you see any files listed? That's what matters.

 

 

---

 

No, none. When I spin the triangle, nothing's in there.

 

Quote:

---

Immediately after clicking Browse, a little "Scanning..." window should pop up while the client scans the filesystem tree. Do the number of folders and number of files increment up from zero while this is happening?

 

---

Happens so fast you can't read what's in that popup.

 

Quote:

---

You know, if your browser doesn't show any listing of files, I'm starting to wonder whether your Retrospect Client is running as "setuid root" as it should. Perhaps it doesn't have permission to see the files if that's the case. Does the browser list any files?

 

If it doesn't

, then do the following:

 

In Terminal, please do the following on the client computer:

Code:

---

ls -al /Applications/Retrospect\ Client.app/Contents/Resources/pitond

---

I suggest you copy and paste that line so that you get it right. Please report the results. You should get one line of output. I'm most interested in the six characters of permissions that are listed, plus the owner and group that are listed.

 

 

---

 

Yep, you've got setuid on there:

 

-rwsrwxr-x 1 root wheel 490336 Apr 6 2006 /Applications/Retrospect Client.app/Contents/Resources/pitond

 

Quote:

---

Also, with the Retrospect client running (doesn't have to be backing up), in Terminal, please do the following on the client computer (open your terminal window up very wide so that the line is not cut off):

Code:

---

ps axlwww | fgrep pitond

---

again, I suggest you copy and paste that line so that you get it right. Please report the results. You should get two lines of output; I'm most interested in the first number on the pitond line.

 

 

---

 

I only show one process, but it is running as root:

 

0 4274 1 0 31 0 79020 896 - Ss ?? 4:25.55 /Applications/Retrospect Client.app/Contents/Resources/pitond

 

Dave K

[rhwalker]

Ok, then you and CallMeDave are on the right path for investigation.

 

Russ

[CallMeDave]

Quote:

---

if Retro is trying to be smart by tracking inodes rather than filenames, is it smart enough to avoid backing up a large directory (say, a backup of my Photo Library) if I simply rename it?

 

---

 

Retrospect has always tracked volumes by their unique file ID. This was true long before Macs had inode information in files.

 

I'm not sure what you think is the "smart" behavior. If I have identified a folder as a subvolume (on a client, let's say) and am backing that up regularly, then the user of that machine accidentally adds a space to the end of the name, or modifies the name in some other way, do you think that the smart behavior would be for Retrospect to suddenly fail to find and backup that folder's contents?

 

I was remiss when I suggested earlier that Retrospect was doing something wrong, other then providing an unexpected user experience. Apple moved all your files out of /Users/Foo/ and moved that entire directory into a new location. Retrospect correctly kept track of your defined subvloume, even though it was now empty and alone in a new place (so sad...).

 

An Archive and Install is not a non-intrusive system modification. It broke your backup configuration, but Retrospect wasn't at fault.

 

Note also that your client software might have to be refreshed/reinstalled, if /Library/StartupItems/RetroClient/ wasn't carried over to the new active system.

 

 

Dave

[reggoboy]

Quote:

---

Quote:

---

if Retro is trying to be smart by tracking inodes rather than filenames, is it smart enough to avoid backing up a large directory (say, a backup of my Photo Library) if I simply rename it?

 

---

 

Retrospect has always tracked volumes by their unique file ID. This was true long before Macs had inode information in files.

 

I'm not sure what you think is the "smart" behavior. If I have identified a folder as a subvolume (on a client, let's say) and am backing that up regularly, then the user of that machine accidentally adds a space to the end of the name, or modifies the name in some other way, do you think that the smart behavior would be for Retrospect to suddenly fail to find and backup that folder's contents?

 

---

 

No, I guess not. I'm just trying to give Retro the benefit of the doubt that it has a good reason for its behavior, and perhaps I'm striking out.

 

Quote:

---

I was remiss when I suggested earlier that Retrospect was doing something wrong, other then providing an unexpected user experience. Apple moved all your files out of /Users/Foo/ and moved that entire directory into a new location. Retrospect correctly kept track of your defined subvloume, even though it was now empty and alone in a new place (so sad...).

 

An Archive and Install is not a non-intrusive system modification. It broke your backup configuration, but Retrospect wasn't at fault.

 

---

 

Sorry, I can't grant you that one. Retro was instructed to backup /Users/Foo. It was backing it up prior to the Archive and Install. And after the A&I, /Users/Foo was still present (and essentially unmodified) and Retro should have picked up where it left off, but it did not. I don't consider this a bug, but rather a poor software design. Retro's inability to gracefully handle the replacement of a hard drive with a new drive with the same name and contents is, likewise, bad design. If someone under my management made a software design decision like that, he'd be under the spotlight answering to our investors the first time a customer complained about that type of experience.

 

You're not really trying to defend the fact that Retro leaves you up a creek in these situations, forced to redefine all your backup configs, are you? That's the way it sounds.

 

Dave

[CallMeDave]

Quote:

---

're not really trying to defend the fact that Retro leaves you up a creek in these situations, forced to redefine all your backup configs, are you?

 

---

 

Actually what I'm attempting to do is describe the behavior, provide some historical context, and suggest that any particular design decision might not be the best under all situations.

 

Retrospect's method for tracking volumes (both logical device volumes and custom defined subvolumes) had been in place for a decade before Apple introduced paths to Mac OS. That was the design decision made by the original programmer, who happened to be the co-owner of the company at the time.

 

The version of Retrospect we use today on OS X is basically the same code that was used for version 4.3, carbonized to take advantage of the APIs Apple provided to developers when OS X shipped. Retrospect was not completely re-written to handle volumes differently then the way that had been working for the life of the product.

 

But even today, the tenacity with which Retrospect tracks volumes is, IMHO, better then paths. As I tried to suggest above, imagine a user who has identified /Users/Foo/Documents/CriticalDocumentsForDailyBackups/ as a subvolume, and scripted a nightly backup to run.

 

At some point, the user moves the folder to their Desktop, perhaps to make it easier to drop in all those critical files. As it stands, Retrospect will continue to backup the contents without user interaction. Isn't that better then having to reconfigure Retrospect to follow the new path?

 

Is it a drag to have to reconfigure Retrospect after _major_ system reconfigurations (such as when replacing hardware or running installer routines that transparently rename folders and move files), but this is offset by the safety of not having to make any configuration changes after the more common sort of name changes or location moving that users are likely to do at any time.

[Mayoff]

Retrospect for Macintosh and Windows track disks in almost the same way.

 

While tracking by path is helpful in some cases, the path of "Macintosh HD/Users/Bob/Documents" could exist on multiple computers and could cause nasty confusion for Retrospect.

 

Retrospect has features to DELETE original files from the hard disk. It is 100% critical that Retrospect can correctly identify the folders to be deleted and not get confused, because that would result in dataloss.

 

What would happen if you had 2 external hard disks with identical paths, but you accidentally forgot to switch drives before an archive operation?

 

If you change drives and give it the same name, we treat it as a different disk, because it is a different disk.

 

Retrospect uses criteria like the Volume Creation Date, Total size, Block Allocation size, Name to identify different identically named disks.