Incremental failing, too

[djlynch]

I'm having a similar problem to one that was posted about a week ago. We were running 4.3 on a beige G3 OS 9.2 with hot swappable SCSI drives connected to an ATTO Dual SCSI card. We're backing up to Sony DDS4 tapes. Everything was working fine. A few days ago we replaced the G3 with a new 733 G4 OS 9.2 with a new ATTO card and reinstalled Retrospect 4.3. I copied the folder containing all of the StorageSets to the new computer. We started doing our routine backups and retrospect wasn't recognizing that it had already backed up large quanities of files and was asking to back them up again instead of just appending the new/modified files. This same problem applied to several drives and storagesets. I compared the "Get Info" dialogs on the previous backups to what's currently on the drive and I found huge discrepancies in the creation dates and modification dates. The dates recorded in Retrospect are correct as far as I remember while the dates on the drive have somehow been altered to hours that I know the drives were not in use for. Norton didn't encounter any "bad modification date errors" or any errors at all.

 

 

 

Does anyone have an idea what could have caused this?

 

 

 

Also, while trying to restore a session on the same G4 there were a ridiculous amount of execution errors. During the restore I started getting error messages about the source drive being damaged and "data may have been lost." I ran a head cleaner through the tape drive but to no avail. We since moved the whole setup back to the original beige G3 and Retrospect seems to be happy again. It's recognizing the incremental backup, the restore is working fine, and there haven't been any drive errors.

 

 

 

I haven't completely ruled out a bad SCSI card yet, but does anyone think it could have caused Retrospect to experience these kinds of problems? Have there been any reports about incompatabilities between 4.3 and ATTO or the G4 or OS 9.2?

 

 

 

Thanks,

 

 

 

D.J.

 

Oracle Post

 

 

[Guest]

If the dates on the files are changing, then Retrospect can't do anything to prevent that. 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.