Retrospect 5 Locking files on ASIP 6.3.1 Server

[liai]

Hello,

 

 

 

Since upgrading to Retrospect 5, I've been having problems with Retrospect backing up files off of my AppleShare IP server. The problem seems to be affecting frequently changed files, though it might be happening to others I'm not yet aware of. My best guess as to what is happening is that Retrospect, while backing up files, is marking files as "locked" and "in use," but is not releasing this locking after it's done backing them up. From the information I can gather, the files being corrupted were NOT in use by another user at the time of the backup, as the backups run at night. Consequently, random files on the server are being corrupted on an almost nightly basis. Files affected in this manner will not open properly, nor will they copy to another drive. However, renaming is possible.

 

 

 

Any help in trying to determine what might be causing this problem would be greatly appreciated.

 

 

 

My system configurations are as follows:

 

 

 

AppleShare IP 6.3.1 Server

 

Mac OS 9.0.4

 

Retrospect Client Extension 4.3

 

 

 

Retrospect Backup Server 5.0.205

 

Mac OS 9.2.1

 

512 MB RAM

 

ECRIX AUTOPAK VXA Tapeloader (15-tape)

 

 

 

- Jason

 

jason@liai.org

[IrenaS]

Retrospect does not lock files when backing them up. If you define a small subvolume and use this as a test folder, can you reproduce this?

 

 

 

Are you locking out ASIP users when Retrospect runs?

[liai]

We do not lock users out of the server while Retrospect is backing up. Would that help? As for being able to reproduce the problem; yes, we can reproduce it.

 

 

 

When trying to open an affected Excel document, the error reads: "[Finename] cannot be accessed. The file may be read-only, or you may be trying to access a read-only location. Or, the server the document is stored on may not be responding."

 

 

 

Similarly, when trying to duplicate the same file, I get the error "The operation could not be completed because the file is in use."

 

 

 

However, the files can be moved to a different location on the same disk without problems.

 

 

 

It seems to me like the files are getting locked or otherwise corrupted. Any Ideas?

 

 

 

- Jason

[IrenaS]

Yes, try locking out users. This option is in the options for your script.

 

 

 

So you are able to access a file, the backup runs, and immediately after you are unable to access the file?

[liai]

Irena,

 

 

 

I'm not sure what locking out users would help accomplish. We've never had that problem before, and we frequently have users who stay connected to the server (but idle) overnight during backups, and have never had problems before. I would think that a successful backup should be able to be accomplished without the need to lock out users. Before we go that route, is there anything else you can think of that might help?

 

 

 

- Jason

[IrenaS]

Whan did this start happening?

[liai]

Our users first started reporting the problem several days after we started running our Retrospect 5.0.205 Backup Server under Mac OS 9.2.1 instead of under Mac OS X 10.1.3. This timing also approximately coincides with when we updated to version 5.0.205 from version 5.0.203.

 

 

 

We switched the backup server to 9.2.1 because when we were runing it under OS X, it was reporting abnormally high numbers of bad tapes, was having trouble with large backups (appeared to be a memory leak) and would "forget" the position of all tapes in our ECRIX AutoPak VXA loader each time the program quit (which was after every time it ran,) causing backups to go extremely slowly, and sometimes Retrospect would hang in mid-backup.

 

 

 

- Jason