Jump to content
billraab

Backing up on-modified files

Recommended Posts

I am in danger of being driven insane by Retrospect.

 

Our main file server which has several TB of data needing backed up has been backed up, in its entirety, by two of two scripts. One of which seems to forget what has already been backed up and backs up the whole darn thing again. This happened in version 9 as well and with a different script. I am happy to provide any further details if someone has some ideas. I don't want to keep burning through tapes for no reason.

 

This machine has been backed up in completion on more than one occasion and I have watched as the snaphot is created as well so I know the process is completing properly. This does not happen with the other three dozen or so machines backed up on the same script it is just this one machine.

Share this post


Link to post
Share on other sites

Thank you Lennart and why I have not seen that is beyond me. I have been searching and trying to figure this out since January. Just when I think I got it licked it happens again.

 

I am confused though as now I feel like I am taking a chance on some data not being backed up.

 

I will run things with this setting disabled and see how things work out for me... and report back.

 

Again, thank you. You are a huge help to these forums.

Share this post


Link to post
Share on other sites

I'm sorry but that doesn't help me since 1 year ago. When this Sh** happens I usually recycle a new media set and start over

Share this post


Link to post
Share on other sites

Unfortunately it seems to have made no difference. I wish I could figure this out... I have another set running parallel to the problematic one and it does not exhibit the same issue. I love a challenge but this one is driving me nuts.

 

I may just try the new set option which stinks as it sets me back... and then if it does not help I will be setback even further.

  • Like 1

Share this post


Link to post
Share on other sites

In fact disabling that option has made things worse for my other set that had been fine. I will re-enable it. <edited>

Share this post


Link to post
Share on other sites

This is just a user-to-user discussion. It is not Retrospect support.

 

Lennart IMHO you usually work harder than retro support...

Share this post


Link to post
Share on other sites

Lennart IMHO you usually work harder than retro support...

Thank you.

It looks that way because I only answer questions I have some knowledge about. A support department must investigate and answer EVERY question. This, of course, takes a lot of time for them.

Share this post


Link to post
Share on other sites
This does not happen with the other three dozen or so machines backed up on the same script it is just this one machine.

 

Perhaps some detail about the machine at issue would help.

What OS? What client version?

What is the Source being used for the backup?

 

 

I don't want to keep burning through tapes for no reason.

 

Have you tried testing with a smaller source volume on the same client machine? Or using a Favorite Folder on whatever source volume is misbehaving, to limit your tests to a smaller data set?

Share this post


Link to post
Share on other sites

Our main file server... has been backed up in completion on more than one occasion and I have watched as the snaphot is created as well so I know the process is completing properly. This does not happen with the other three dozen or so machines backed up on the same script it is just this one machine.

 

Is that one machine being redundantly backed up via Retrospect Client? Windows / Mac / Linux?

Are the relevant volume(s) local to that machine using a file system native to that machine's OS? If remotely mounted on that machine, what is the protocol and the actual underlying file system used by the file server?

Share this post


Link to post
Share on other sites

If the backup source is Mac OS with a Mac HFS volume, the issue may be due to file attribute modification date changing even when file creation date and file modification date haven't. In that case, if file attributes (listed by "ls -l@" or "xattr -lv") aren't important to you, you can disable your script's Options > Source > Macintosh > Use attribute modification date when matching.

 

More info at:

- Search for "Use attribute modification date when matching" at http://retrospect.com/en/documentation/user_guide/mac10/operations#creating-a-backup-script-manually

- http://forums.retrospect.com/index.php?/topic/147494-copyoverwrite-entire-volume-still-copying-far-too-much-in-retrospect-9/page__st__20

Share this post


Link to post
Share on other sites

CallmeDave: This is a Mac Server version 10.4.7. The source is an X Serve RAID. Retrospect 10. I backup many different machines... this one is the only problem.

 

DavidWLee: I have disabled the script's Use Attribute Modification date = no difference.

 

I have disabled RetroISA to no avail.

 

I have since reverted to Retrospect 9 and it looks like things are falling back into place. I need a bit more time to make sure operation is consistent. I changed nothing but the Retrospect versions. Same scripts, same catalogs... only the version has changed to protect the frustrated. :-)

Share this post


Link to post
Share on other sites

This is a Mac Server version 10.4.7. The source is an X Serve RAID. Retrospect 10. I backup many different machines... this one is the only problem.

 

When determining if a file on an HFS volume has changed since it was last backed up, Retrospect considers:

- file name (case sensitive)

- creation date

- modification date

- file size

- resource fork size (shown by: ls -l yourFileName/..namedfork/rsrc)

- attribute modification date (if that option is enabled)

Share this post


Link to post
Share on other sites

Thanks David... can you explain why retrospect 9 performs backups without my issue and why 10 does not? I guess that would be a better clue to defining the problem.

What I am asking is what does 10 do that 9 does not in respect to file modification determination (sans attribute modification date as it was disabled)... or what does 9 do better than 10? Either works for me.

Thanks

Share this post


Link to post
Share on other sites

CallmeDave: This is a Mac Server version 10.4.7.

 

Retrospect 10 is supported under Mac OS X Server 10.6.8 and later

http://www.retrospec...ac/requirements

 

The source is an X Serve RAID.

"XServe RAID" isn't a computer, it's an accessory.

 

Retrospect 10

We still don't know the version of Mac OS being used with the Retrospect OS X Client software.

 

I backup many different machines... this one is the only problem.

"This one" is presumably the XServe controlling the XServe RAID?

Share this post


Link to post
Share on other sites

can you explain why retrospect 9 performs backups without my issue and why 10 does not?

 

We have found any related change so far between 9 and 10. In an earlier post (quoted below) you mentioned the same issue also happened on Retrospect 9, right?

 

 

 

Our main file server which has several TB of data needing backed up has been backed up, in its entirety, by two of two scripts. One of which seems to forget what has already been backed up and backs up the whole darn thing again. This happened in version 9 as well and with a different script.

 

To CallMeDave's points:

- We don't support Mac OS 10.4.7 any more.

- Is XServe RAID connected to Retrospect Server/Client locally as an HFS volume, or as a network share via AFP? That changes the file metadata available to Retrospect for determining if a file matches the ones in the media set.

Share this post


Link to post
Share on other sites

Yes, it had happened in one of my two scripts for Retrospect 9. I started a new script with my update to 10. All I know is that in version 9 it works fine... albeit slower... but speed is not as important as getting complete and consistent backups. My upgrade to 10 was without cost so I am out nothing.

 

The server (File server) is running 10.4.7, not the Retrospect Server which is on 10.7.5.

The XServe RAID is connected to the Apple File Server locally. The Retrospect system backs it up just as any other client... at least in Retrospect 9 anyways.

 

I'd love to return to 10 but at this point things will stay as they are on 9.

Share this post


Link to post
Share on other sites

The server (File server) is running 10.4.7, not the Retrospect Server which is on 10.7.5.

The XServe RAID is connected to the Apple File Server locally. The Retrospect system backs it up just as any other client...

 

Is the Retrospect engine (running on Mac OS 10.7.5) directly backing up the file server as a network share, or via a Retrospect Client running on the file server (Mac OS 10.4.7 which Retrospect no longer supports)? As mentioned, that distinction helps narrow down what (AFP vs. HFS+) metadata are available to Retrospect for determining if a file matches the ones in the media set.

Share this post


Link to post
Share on other sites

Just saw this last post David... my apology in delay of response. It is backing up the server via the Retrospect Client software.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×