Sessions don't match on copied catalog

[dkatz42]

I use external firewire disks exclusively for backups (using file backup sets), and back up a number of machines across a VPN stretching halfway across the country (so the data rates aren't tremendous.)

 

 

 

The way I manage this is to bring a disk to each machine to do the initial backup, which is fairly quick, and then copy the backup set file onto the remote backup server, and do incremental backups from there. This has proven very effective for me.

 

 

 

However, when trying this with 5.0, it fails to match the previous snapshots, and so attempts to back up the entire machine across the network (which would take days to complete.) This is leaving me in a serious bind.

 

 

 

When I look at the "backup set contents" screen, the sessions created when the backup disk was directly connected say "root" in the second column, whereas the later attempt that was going to copy the whole disk across the Internet has the machine name of the client in that column.

 

 

 

In general, how does session matching work?

 

 

 

 

[IrenaS]

Retrospect uses several matching criteria to compare files that have already been backed up to what is about to be backed up. If one of the following has been changed at all, Retrospect will back up the file again: name, size, type, creator, creation date and time, modify date and time, and label.

 

 

 

If Retrospect is reporting that it is about to back up files you know have not changed since your last backup, take a closer look at a sample file. Choose a file and start a restore by search for that file. When you get to the final window (you don't actually have to do the restore), click Files Chosen and Get Info (type Command-I) on the most recent version of the file on the backup. Print or take a screenshot of this window.

 

 

 

Now, go to the Configure tab from the Retrospect Directory and click Volumes. Choose the volume the file is on and click Browse. Find the file in question and Get Info on it. Put the two windows side by side and look for even the slightest difference in any of the criteria I listed above.

 

 

 

Many things can cause a change in a file, even if the file has not been accessed by the user. The operating system, as well as applications, are constantly making changes to files. Further, whenever you change time zones in the Date & Time control panel, your creation and modify dates are offset. We have also found an issue in Mac OS 8.1 with HFS+ formatted volumes where changing the Daylight Savings Time setting offsets the creation and modify dates of all files.

 

 

 

There is also an issue where AppleShare might make a time translation when connecting to another machine whose time is off by more than a certain number of minutes. This time translation would also offset the creation and modify dates of all files. I have also seen this happen when upgrading operating systems or doing a complete restore of data with Retrospect.

 

 

 

Unfortunately the only known way around this problem is to do a full backup of your data. I know of no way to force file attributes to regress to the way they were before. Either do a full backup or use this time to introduce new media.

 

 

 

You should also look at the Backup Set configuration window. From the Retrospect Directory click Configure, then Backup Sets. Choose the set and click Configure. Click Members. Are any members marked "Missing?" If so, mark them found again. Retrospect will attempt to recopy any files on a member marked as missing.

 

 

 

Irena Solomon

 

Dantz Tech Support

[dkatz42]

I'll take a look at the things you suggest. I note, however, that retrospect is backing up *every* file as if the backup set was empty, not just a few or even some. I'm guessing some kind of incompatibility between backing up under 9.2.2/5.0 and 10.1.2/5.0, but I'll troubleshoot some more.

[pfyfe]

Your exact situation is not clear from the info you have given, but perhaps you are seeing what is described in the Read Me for 5.0, namely:

 

 

 

Backup Sets Created Under OS 9:

 

If you are running under OS X and backing up files to a backup set that was created under OS9, Retrospect will recopy all files the first time that they are backed up to this set. Future normal (incremental) backups will only copy new or changed files. ---end quote.

 

 

[dkatz42]

Hm, I suspect that this is exactly it. On first principles, if an OS 9 machine can successfully back up an OS X machine under 5.0, the catalogs should be identical. Bugger.

[dkatz42]

Hmm, actually this is the opposite; the backup set was created under OS X and is being added to under OS 9, but If there are matching issues it would surprise me if they were reflexive.

 

 

[dkatz42]

OK, I did some experiments. To reiterate, here's the situation:

 

 

 

First I did a full backup under OS 10.1.2 on a locally attached firewire disk. I then moved the backup set file to a machine running OS 9.2.2. I ran an immediate backup on the 9.2.2 machine of the remotely attached 10.1.2 machine, chose "preview", and did an Info request on the previewed file. I also did a "backup set contents" browse for the same file in the backup set (the graphing calculator application.)

 

 

 

In the backup set (which was locally generated) the owner is "dkatz" and the group is "unknown." In the preview, the owner is "501" and the group is "99." I'm sure that 501 is dkatz's UID and 99 is unknown's GID. What it looks like is that the UID/GID was translated on the local machine via /etc/group and wherever users are kept under OS X (not in /etc/passwd like the good old days) and stored in textual form in the catalog, but the remote client is feeding the UID/GID rather than the textual form, and the server cannot resolve the IDs to name (nor should it, since the users are unlikely to have accounts on the server anyhow.)

 

 

 

I'll do some more experiments.

[dkatz42]

Hmm, looks like this one got fixed in 5.0.203 if the catalog was written by OS X under 5.0.203. (If the catalog was written with 5.0.201, running 5.0.203 will try to back everything up.)

 

 

 

So it looks like you can write backups with OS X and add to them with OS 9 so long as you're running the latest stuff, but it is still the case that if you back up with OS 9 and then try to add with OS X, it will re-add everything to the backup set.