Back up server volume, incrementals aren't working

[fregnergstrom]

I'm running Retrospect Server 6.0.178 on OSX, backing up (among other things) a mounted server volume. I have to back up the volume this way because it is a published Appleshare IP volume on a NAS box. The NAS is running Linux, but OS is in firmware, so I can't install the Retrospect Linux client.

 

Using Dantz recommendations for setting up backup of a server volume (entering the user and password) the backup is working fine, except that I get a FULL backup each day. Currently that means 11 GB per day, and it's going to get worse. That means my backup media fills up after two days, instead of the five days it should last. Since this is a remote site, it's a big deal to have to switch tapes mid-week.

 

I'm guessing Retrospect is not able to set a backup flag on the files from the NAS. Is there some way to tell Retrospect to use another method to determine if a file is already on the backup set?

 

[natew]

Hi

 

This happens due to a couple of reasons:

 

The nas may be keeping time differently so all the files show up as changed.

 

Or

 

When OSX mounts a network volume it can push the create/modify date/time on files off by 1 second or 1 minute. AS a result Retrospect sees the files as changed and backs them up again. For its part, Retrospect is running properly - reacting to the time change and backing up the files.

 

To get around the time change you can set up a selector based on the modify/create/backup time. I would urge caution with this though as selectors are interpreted literaly and can exclude more than you expected them to. Best to triple check that it is backing up the way you expected it to.

 

Nate

[fregnergstrom]

I tried turning on these options for my script:

 

"Set source folders' backup time"

"Set source files' backup time"

 

Now I get the following error for what I believe is every file on the mounted volume. (The following is a typical entry. Obviously they vary slightly.)

 

File "Group Presentation.ppt": different creation date/time (set: 6/19/2003 10:59:01 AM, vol: 6/19/2003 9:59.01 AM), path: "Server_Backup/Username/...etc."

 

I checked, and the clocks on the backup server and file server are on the same time zone. They were off about three minutes. Is Retrospect that sensitive?

[AmyJ]

It's not actually a question of sensitivity. Retrospect is reporting that the file dates/times are different then the original dates/time. Retrospect has no way of knowing how or why the differences occured.

 

Getting deeper into the issue, the time difference noted is not 3 minutes, but actually an exact hour (to the second). In my experience this typically indicates the system is doing some kind of time translation on the files.

 

You didn't mention which version of OS X you're running, but I do recall these types of issues with mounted volumes in the earlier builds of X.

[fregnergstrom]

Good point: the machine in question is running 10.1.5. This is a server, so upgrading is trucky. Having said that, clearly this is worth doing, and it's on the table for other reasons. We'll proceed and see if the problem improves after the upgrade.

 

Thanks for your help.

[CallMeDave]

Quote:

---

the machine in question is running 10.1.5.

 

---

 

OS X 10.1 had a bug in the time reported for mounted AFP volumes, that Apple fixed in 10.2.

 

But the offset was usually in the seconds, not whole hours as in your example. Still, updating to a more current version of OS X will yield benefits far beyond those enjoyed with Retrospect.