Jump to content

Incremental Backup Problems


Recommended Posts

Dear Retrospect Users:

 

 

 

We just upgraded from Retrospect 4.3 to 5.0, now running on Mac OS X. Our previous backup strategy, used in 4.3, does not seem to work under 5.0. Does anyone have any ideas as to what it wrong? Here's how things are supposed to work:

 

 

 

1. On the weekends, we do a complete *Recycle* backup on our 300GB server. We are backing up to an HP Ultrium 215 LTO drive. This wipes any previous data from any tape inserted into the drive.

 

 

 

2. On the weekdays, we do a *normal* backup. On 4.3, this backs up only that data which has *changed*. Using this method, we can fit an entire week's worth of backup data on two LTO tapes (we can get about 185GB on a single tape).

 

 

 

Here's where the problem comes up under Retro 5. When doing the *normal* backup, Retrospect does not only back up the data that has changed. Instead, it backs up *everything* again. It does not clear the contents of the tape; it just tacks an entire backup of the whole 300GB server on the tape, requiring a new tape to be inserted. This is a real problem, as we were able to use two tapes per backup. Now, we need, well, a whole gob more. Using a *normal* backup, we need Retro to back up only the data that has changed, and not the entire drive's contents every night.

 

 

 

Any ideas on this?

Link to comment
Share on other sites

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. If this is a mounted volume (it's not quite clear from your post) then it could have to do with OS X not seeing the time/date stamps on the files correctly.

 

 

 

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.

Link to comment
Share on other sites

I got in touch with Dantz on this. The problem lies in the way that Retrospect 5 interacts with AppleShare IP, the server that we are backing up. We are backing it up over a network by mounting the Appleshare volume to the backup station's desktop (we chose not to use the Retro client, as it interfered with IPNet Router running on AppleShare. In any case, Retro 5 sees file modification dates a bit differently than Retro 4 did, and this conflicts with Appleshare. No one knows whose fault it is, but Dantz is aware of the problem. We have been forced to return to Retro 4, and things are just fine now. But, we're out $99. Oh well...live 'n learn :-(

 

 

 

Marc Hoffman

Link to comment
Share on other sites

>I got in touch with Dantz on this. The problem lies in the way that Retrospect 5 interacts with

 

> AppleShare IP, the server that we are backing up. ...

 

 

 

It would have been nice if Dantz would have communicated this to the forum. The thread on the "Incremental backs up too much" discussion has been going along for quite some time.

 

 

 

This is a big problem, as I am unwilling to use the Retro client on our ASIP server (its delicate enough without it), and since Dantz doesn't make a client for Snap Servers (which would be nice if they did), I am, in sense, forced to do full backups every night on them. Swiching back to OS 9 isn't an option.

 

 

 

Perhaps the moderator could give us an idea of how long it will be before a fix will be available?

 

 

 

 

Link to comment
Share on other sites

I got in touch with Dantz on this. The problem lies in the way that Retrospect 5 interacts with AppleShare IP, the server that we are backing up. We are backing it up over a network by mounting the Appleshare volume to the backup station's desktop (we chose not to use the Retro client, as it interfered with IPNet Router running on AppleShare. In any case, Retro 5 sees file modification dates a bit differently than Retro 4 did, and this conflicts with Appleshare. No one knows whose fault it is, but Dantz is aware of the problem. We have been forced to return to Retro 4, and things are just fine now. But, we're out $99. Oh well...live 'n learn :-(

 

 

 

Marc Hoffman

Link to comment
Share on other sites

Its a shame someone had to pay the support fee to have this issue acknowledged. Even so, no one associated with Dantz has chimed in to confirm that they are aware of the problem in any of the threads started about the issue.

 

 

 

I first noticed the problem and addressed it here back on January 24th 2002, that is 4 months ago now. I had assumed that it would be fixed in the shipping version...Since Dantz no longer provides tech support for upgrades (very poor judgement call, as previous users are the ones who are most likely to contact them with real issues, rather than pilot errors), this forum should be the place where we can get real answers. That just doesn't seem to be the case. This is illustrated very well by IrenaS's reply to the first post in this thread... it is the same stock reply that I recieved 4 months ago.

 

 

 

I don't want to seem like i am bashing any of the moderators or frequent posters, I am convinced that they are overwhelmed by the sheer amount of posts since the release of OSX. It's just that if Dantz is going to make this forum a viable source for tech support, they need to know what is not working.

 

 

 

Consider this a bug report for the forum if you will.

 

 

 

I've used other backup programs, both mac and PC, and have no intention of switching from Retrospect - I just want the problems identified and fixed.

 

 

 

Charlie

Link to comment
Share on other sites

  • 4 weeks later...

Imagine my shock!! Here's the reply that Dantz tech support sent to me on this issue. As an aside, Retrospect 4 works fine with Appleshare IP. Why can't Danz simply add an "AppleShareIP compatibility mode" checkbox somewhere? Forcing us to upgrade to Mac OS X server is simply NOT an issue at this time...

 

 

 

Reply from Dantz is as follows:

 

 

 

"Hello Dantz Customer,

 

 

 

Dantz has been investigating several problems that customers have reported

 

when backing up an AppleShare IP server with Retrospect 5.0. Reported

 

problems include:

 

 

 

1) The ASIP server crashes when Retrospect 5.0 autolaunches or

 

is launched from an alias.

 

 

 

2) The ASIP server crashes at the beginning of a backup with the

 

Retrospect 5.0 client.

 

 

 

3) Retrospect returns "error 1 (unknown)" for some files backed

 

up from an ASIP server with the Retrospect 5.0 client.

 

 

 

Our investigation has revealed that these problems result from using Carbon

 

APIs with AppleShare IP software. Problem #1 occurs when any Carbon

 

application is launched from an alias, confirming our contention that it is

 

not a Retrospect issue. Retrospect 5.0 uses HFS+ file system calls, as

 

specified by Apple, which stimulate bugs in the AppleShare IP software,

 

resulting in Problems #2 and #3.

 

 

 

We have reported all of these problems to Apple, but Apple's development

 

efforts are now focused on Mac OS X Server. Without a commitment by Apple to

 

address these problems, we have no choice but to suggest that our customers

 

consider replacing AppleShare IP with Mac OS X Server.

 

 

 

Sincerely,

 

 

 

Dantz Development

 

Technical Support

 

www.dantz.com"

 

 

Link to comment
Share on other sites

First, in case others may have missed the announcement, I've included it at the bottom. This was recently posted to the forum and released to customers on our notify list.

 

 

 

Since the incompatibility is with AppleShare IP, it's not as easy as adding a checkbox for compatibility. 4.3 and 5.0 use many of the same calls, and both stimulate the same ASIP bugs that we've reported.

 

 

 

Thanks,

 

 

 

Irena Solomon

 

Dantz Tech Support

 

 

 

----------

 

 

 

Hello,

 

 

 

Dantz has been investigating several problems that customers have reported when backing up an AppleShare IP server with Retrospect 5.0. Reported problems include:

 

 

 

1) The ASIP server crashes when Retrospect 5.0 autolaunches or is launched

 

from an alias.

 

 

 

2) The ASIP server crashes at the beginning of a backup with the Retrospect

 

5.0 client.

 

 

 

3) Retrospect returns "error 1 (unknown)" for some files backed up from an

 

ASIP server with the Retrospect 5.0 client.

 

 

 

Our investigation has revealed that these problems result from using Carbon APIs with AppleShare IP software. Problem #1 occurs when any Carbon application is launched from an alias, confirming our contention that it is not a Retrospect issue. Retrospect 5.0 uses HFS+ file system calls, as specified by Apple, which stimulate bugs in the AppleShare IP software,

 

resulting in Problems #2 and #3.

 

 

 

We have reported all of these problems to Apple, but Apple's development efforts are now focused on Mac OS X Server. Without a commitment by Apple to address these problems, we have no choice but to suggest that our customers consider replacing AppleShare IP with Mac OS X Server.

 

 

 

Sincerely,

 

 

 

Dantz Development

 

Technical Support

 

www.dantz.com

 

 

 

 

Link to comment
Share on other sites

Hi...

 

 

 

Perhaps these are separate issues. We don't actually have problems with ASIP crashing. We simply have problems with the incremental backups. Retro 5 backs up files that have not changed, and need not be backed up. It's getting the modification dates wrong. We back up our ASIP server by mounting its drive to a backup station. We then back up over the network. This works fine, and has worked for over a year and a half. Adding an ASIP compatibility checkbox could easily fix this issue. The thread link below has nothing to do with unexpected quits or crashes:

 

 

 

http://www.dantz.com/ubbthreads/showflat.php?Cat=&Board=Desktopworkgrupx&Number=

 

7512&page=0&view=collapsed&sb=5&o=0&fpart=

 

 

 

Please let us know!

 

 

 

Marc Hoffman

 

 

Link to comment
Share on other sites

What I have done for incremental backups of our ASIP (without client), and snap servers was to create a selector that excludes files whose modification date is older than the backup date. You need to turn on the "Set File Backup Date" in the options for this to work. This way if a file is modified, then its modification date will be newer than the backup date, and then the file will be backed up.

 

 

 

It's a workaround until someone fixes the problem with Appleshare.

 

 

 

 

Link to comment
Share on other sites

In reply to:

Retro 5 backs up files that have not changed, and need not be backed up. It's getting the modification dates wrong.


 

It's actually not Retrospect that is getting the dates wrong, it's Mac OS X that is telling Retrospect the wrong dates!

 

 

 

You can see this by using the terminal to view the mod dates; you'll find that the very act of unmounting and remounting an AFP volume _sometimes_ changes the dates by 1 second.

 

 

 

pnorton's suggestion below is a great idea; I for one am going to give it a try.

 

 

 

Dave

Link to comment
Share on other sites

  • 2 months later...

Hi...

 

 

 

It's me again. I still have heard nothing from Dantz on this issue :-(. However, after upgrading to Mac OS X 10.2, I thought that perhaps Apple might have taken steps to fix this problem. Unfortunately, things seem to have gotten worse :-( :-( :-(

 

 

 

Retrospect 5 has problems scanning the networked volume. For one thing, it takes a LONG time to scan a volume that Retro 4 took a few seconds to scan. And when I check the operations log, I see that it is overflowing with messages like this:

 

 

 

"Duplicate dirid detected: 0x003a8a42

 

Scanning incomplete, error -127 (volume corrupt?)"

 

 

 

When running the same backup scripts under Retro 4, things are fine. Any ideas??

 

 

 

Marc Hoffman

Link to comment
Share on other sites

>It's me again. I still have heard nothing from Dantz on this issue :-(

 

 

 

Which issue, specifically, are you hoping to hear about?

 

 

 

If it's the issue in your original post, where Mac OS X 10.1.x reports times/dates incorrectly on mounted AFP volumes, that bug was fixed by Apple in Mac OS X 10.2.

 

 

 

>Retrospect 5 has problems scanning the networked volume. For one thing,

 

>it takes a LONG time to scan a volume that Retro 4 took a few seconds to scan.

 

 

 

Is this under Mac OS X or Mac OS 9?

 

 

 

>And when I check the operations log, I see that it is

 

>overflowing with messages like this:

 

 

 

>"Duplicate dirid detected: 0x003a8a42

 

>Scanning incomplete, error -127 (volume corrupt?)"

 

 

 

>When running the same backup scripts under Retro 4, things are fine. Any ideas??

 

 

 

Another poster has reported this error under OS X 10.2 that was not present in 10.1. Perhaps there has been some change in the file system that is reacting with the version of Retrospect that shipped back in January.

 

 

 

Dave

 

 

Link to comment
Share on other sites

>Which issue, specifically, are you hoping to hear about?

 

>If it's the issue in your original post, where Mac OS X 10.1.x reports times/dates incorrectly

 

>on mounted AFP volumes, that bug was fixed by Apple in Mac OS X 10.2.

 

 

 

You're right on this one. It's about the original issue with the dates being incorrectly reported when backing up ASIP via the desktop container. I'm glad to hear that this was fixed.

 

 

 

>>Retrospect 5 has problems scanning the networked volume. For one thing,

 

>>it takes a LONG time to scan a volume that Retro 4 took a few seconds to scan.

 

 

 

>Is this under Mac OS X or Mac OS 9?

 

 

 

This is on the OS X 10.2 computer running Retro 5. This computer is backing up the ASIP server.

 

 

 

>>And when I check the operations log, I see that it is

 

>>overflowing with messages like this:

 

 

 

>>"Duplicate dirid detected: 0x003a8a42

 

>>Scanning incomplete, error -127 (volume corrupt?)"

 

 

 

>>When running the same backup scripts under Retro 4, things are fine. Any ideas??

 

 

 

>Another poster has reported this error under OS X 10.2 that was not present in 10.1. Perhaps there

 

>has been some change in the file system that is reacting with the version of Retrospect that shipped

 

>back in January.

 

 

 

That's what I'm thinking, too. I wonder if we could have a post from Dantz on this to see if there is some kind of update in the works (or until Apple releases a fix for that disaster they called Jaguar....)

 

 

Link to comment
Share on other sites

In reply to:

Retrospect 5 has problems scanning the networked volume. For one thing, it takes a LONG time to scan a volume that Retro 4 took a few seconds to scan ... on the OS X 10.2 computer running Retro 5.


 

So it's not that this operation is faster with Retrospect 4, it's that this operation was faster with Retrospect 4 running in OS 9.

 

 

 

Retrospect 5 runs in OS 9 too; is the scan slower when you test with the same operating system as before?

 

 

 

>> I wonder if we could have a post from Dantz on this to see if there is some kind of update in the works <<

 

 

 

It's been done. Dantz has made public announcements regarding an upcoming update.

 

 

 

Dave

Link to comment
Share on other sites

  • 1 month later...

I continue to get "Duplicate Dirid" and "Volume Corrupt?" messages in the log when backing up my ASIP server as a mounted desktop volume. I have run Diskwarrior and TechTool and nothing has changed.

 

 

 

Specs: Retro 5.0.236, Retro Driver update 3.1.105, Mac OS X 10.2.1

 

 

 

Here is the log:

 

 

 

- 2/11/2002 3:25:49 PM: Copying HBA Server…

 

While scanning volume HBA Server,

 

Folder HBA Server/HBA Archive/OLD One Pagers/Roundhouse Legacy Project/,

 

Duplicate dirid detected: 0x0003452c

 

Folder HBA Server/HBA Archive/OLD One Pagers/,

 

Scanning incomplete, error -127 (volume corrupt?).

 

Folder HBA Server/System Folder/Extensions/Server Modules/,

 

Duplicate dirid detected: 0x0000a6c3

 

Folder HBA Server/System Folder/Extensions/,

 

Scanning incomplete, error -127 (volume corrupt?).

Link to comment
Share on other sites

Unfortunately I cannot run Retro locally. It is a rule of mine (due to past memory issues) that Retro should be installed on a Desktop machine and run using the Client on the Server. HOWEVER, with the Apple ASIP bug I cannot run the Client and thus must auto-mount the volume during backup. Say, is there a way to remove/uninstall the Carbon Libraries? I wonder if ASIP and any other apps I am running were ever carbonized? I guess I could try by turning them off in the Extensions Manager... if only I could bring down the Server!!

 

 

 

ASIDE: Good news though... soon I hope to get enough courage to install Mac OS X 10.2.1 Server... I have just discovered that it is really not that easy as there is very little information about how to configure some of the basic functions (such as DNS) without knowing Terminal.

Link to comment
Share on other sites

  • 3 weeks later...

So I dumped the first few files from the ASIP Server but after Mac OS X 10.2.2 update to my desktop machine, the Retro 5.0.238 update and the Retro Client 5.0.238 update, I am still getting errors...

 

 

 

- 25/11/2002 8:42:22 AM: Copying HBA Server…

 

While scanning volume HBA Server,

 

Folder HBA Server/System Folder/Extensions/Server Modules/,

 

Duplicate dirid detected: 0x0000a6c3

 

Folder HBA Server/System Folder/Extensions/,

 

Scanning incomplete, error -127 (volume corrupt?).

 

25/11/2002 8:46:31 AM: 2 execution errors.

 

Completed: 338 files, 168.0 MB

 

Performance: 41.8 MB/minute

 

Duration: 00:04:09 (00:00:08 idle/loading/preparing)

 

 

 

I am worried about this... is this an issue with the Server that something is going to happen (c-r-a-s-h) or is it Retro?? Has anyone figured out a work-around for the ASIP bug other than by mounting the volume or stopping ASIP and running it as a Client??

 

 

 

 

Link to comment
Share on other sites

In reply to:

I continue to get "Duplicate Dirid" and "Volume Corrupt?" messages in the log when backing up my ASIP server as a mounted desktop volume.


 

 

 

Other threads in this Forum have pointed to folders or files named "." that Retrospect running under OS X sees as the unique directory names used by unix.

 

 

 

You seem to have a head start in finding where the problem files might be, as your log reports some specific paths:

 

 

 

"HBA Server/HBA Archive/OLD One Pagers/Roundhouse Legacy Project/,"

 

 

 

If you define the "Roundhouse Legacy Project" folder as a volume in Retrospect and scan that, do you get the error?

 

 

 

If so, inspect the contents of that folder and look for anything out of the ordinary.

 

 

 

You could continue basic trouble shooting techniques, such as moving all the files out and testing, then moving them back one (or five, or ten, etc) at a time and see if/when the problem reappears.

 

 

 

Dave

Link to comment
Share on other sites

  • 2 weeks later...

I'm afraid after a re-install of ASIP, I continue to get the following log entry after a mounted-volume-backup of my server:

 

 

 

- 4/12/2002 4:44:18 AM: Copying HBA Server…

 

While scanning volume HBA Server,

 

Folder HBA Server/System Folder/Extensions/Server Modules/,

 

Duplicate dirid detected: 0x0000a6c3

 

Folder HBA Server/System Folder/Extensions/,

 

Scanning incomplete, error -127 (volume corrupt?).

 

 

 

I could try a clean install of Mac OS 9.1 but that might be a little bit too much to ask. The Server will have to be down for quite a while...

 

 

 

The only thing I can think of is that these files are active and in use. However, other apps or files that are in use log like this:

 

 

 

Can't read file “System”, error -49 (file busy), path: “HBA Server/System Folder/System”.

 

Then further down the log I read:

 

 

 

Can't read file “ARA Server Module”, error -49 (file busy), path: “HBA Server/System Folder/Extensions/Server Modules/ARA Server Module”.

 

Can't read file “File Server Module”, error -49 (file busy), path: “HBA Server/System Folder/Extensions/Server Modules/File Server Module”.

 

Can't read file “Mail Server Module”, error -49 (file busy), path: “HBA Server/System Folder/Extensions/Server Modules/Mail Server Module”.

 

Can't read file “Privs Server Module”, error -49 (file busy), path: “HBA Server/System Folder/Extensions/Server Modules/Privs Server Module”.

 

Can't read file “Server Info Server Module”, error -49 (file busy), path: “HBA Server/System Folder/Extensions/Server Modules/Server Info Server Module”.

 

Can't read file “U&G Server Module”, error -49 (file busy), path: “HBA Server/System Folder/Extensions/Server Modules/U&G Server Module”.

 

Can't read file “Web Server Module”, error -49 (file busy), path: “HBA Server/System Folder/Extensions/Server Modules/Web Server Module”.

 

 

 

Could this simply be a bug in the way Retro logs a busy file?

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...