mvgfr Posted April 15, 2002 Report Share Posted April 15, 2002 Folks - I've looked in my list archives, through the forums here and via Google - I can't find anything about an issue I've seen for a long time, but have never been able to figure out. I've been working around the problem, but my workaround is no longer feasible. If the clock on my Win 2K servers changes (ex: due to Daylight Savings Time or just a nudge to account for drift) the next Retrospect backup (normal/incremental) will back up most of the files, not just those that have changed. (Strangely enough, it doesn't look like it's backing them all up. I think.) This occurs whether I'm backing up something as a mounted volume (server is running EZIP and not SFM) or via the Retro client (server is running FirstClass). The Retro machine is a B&W G3 running Mac OS 9.2.2 (same problem with prior Mac OS releases to 8.6) Retro V5.0 (same problem with V4.3) and the one Windows client (the FirstClass machine) is V5.1.0.0. The version of EZIP (on volumes backed up via AFP mounts) is V2.0.4, but the same problem existed with V1.1.3. Is there some fundamental incompatibility? (We use the Win 2K servers virtually exclusively for Macs, so I don't care about any Win-specific info on them; just the files the Macs are trading.) I've been loathe to try having Retro sync clocks or having the Win 2K servers sync via NTP (because my backup media is not capable of a full backup on a single tape), but could that be the solution? Any ideas would be most appreciated! Thanks, Marc Link to comment Share on other sites More sharing options...
ZakB Posted April 17, 2002 Report Share Posted April 17, 2002 Please refer to the following technote: Tech Note NO. 304 VOLUME CREATION DATE/APPLESHARE TIME TRANSLATION Description During an operation Retrospect may indicate a mounted file server volume was not found, or Retrospect may want to back up files on a mounted file server even though the files have not changed since the previous backup. This problem is usually seen after a change of the system clock on either the Backup Macintosh or the mounted volume, which often occurs during a switch between standard time and daylight savings time. Reason Retrospect relies on a volume's creation date and the volume's name to identify it as a unique volume. If the system clock on either the network volume's computer or the Backup Macintosh is changed outside a certain range, AppleShare will compare the two system clock times and perform a time translation based on the differences. This AppleShare feature is enabled to facilitate sharing of data between workstations located in time zones different than that of the server. Unfortunately, this feature also interferes with Retrospect's proper recognition of volumes and its incremental backups since all times on the server are different due to the time translation. Note: AppleShare performs a time translation when the network volume's computer system clock time is 13 minutes greater or 17 minutes less than the local computer's time setting. Solution Synchronize both the Backup Macintosh's clock and the network volume's computer clock to within the acceptable margin. Make sure that the Retrospect script in question uses the correct volume. Apple Support references these time changes at the following website: http://til.info.apple.com/techinfo.nsf/artnum/n7203 Link to comment Share on other sites More sharing options...
mvgfr Posted April 18, 2002 Author Report Share Posted April 18, 2002 >refer to TN 304 Yep; like I said, I read that (from way back - I've been using Retro sinceÉwell, about the late 80's! , but this seemed to be a different problem; it seemed more complex. I say "seemed" because, as a test, I'm running TrueTime WinSync on the servers now, and all seems well - perhaps adjusting the clock frequently, only a second or two at a time, is the ticket. (BTW: WinSync seemed about the best app for time synching on Windows (esp. since we're using them outside the normal MS domain system); if anyone has any tips or recommendations here, I'm all ears!) Thanks, Marc Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.