Never say "never", but for what it's worth, because the server is 5.1 and
thus out of support, IBM support might not accept a call on this.
The problems in the past have affected *all* files, not a subset, so I
have to wonder if there is something else going on. Do you manually set
your clocks back, or do you let Windows do the adjustment? What kind of
file system are you using? If NTFS, is it Windows native NTFS (sounds like
it might be, but never assume...)? Are the affected files limited to a
single file system? Are they a local file system?
Also take a look at the management classes to which the files are bound.
For example, if MODE=ABSOLUTE is set, then those files will back up
regardless of whether they have changed. Also look for a nonzero FREQUENCY
setting.
Too bad you aren't using 5.3, you could just use the dsmtrace utility to
enable and disable tracing without stopping the client (assuming you can
identify its process number). But if you can stop the backup, then restart
with the client configured to take an FIOATTRIBS trace, you'll have
something a little more concrete to look at, as that should show you what
changes the client is detecting.
You can configure the client for the trace by adding the following to your
dsm.opt file:
* tracefile can point to any valid file name
tracefile c:\tsmtrace.txt
traceflags fioattribs
My recommendation would be to specify a tracefile that resides on the disk
with the most amount of space.
Once the backup operation finishes, review the trace file, looking for
files that you suspect haven't changed.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com
IBM Tivoli Storage Manager support web page:
http://www-306.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2005-10-31
08:21:21:
> Farren
>
> There definitely was a client(s) that suffered from this problem and we
> logged in over the weekend to ensure that none of our current clients
> suffered from the problem. (To be on the safe side)
>
> My recollection was that the clients that suffered were only Windows and
> the 2 fix patches were as follows
>
> Ver 3.7.2.17
> Ver 4.1.1.16
>
> Looking at the ftp site, your client (5.2.0.6) was released in early
> 2003, therefore you would think that through 6 clock changes, albeit
> only 3 going backwards, somebody would have noticed it if the bug had
> been re-introduced, even though it may be specific to your config (ie
> W2K3 and NAS). We have a wide range of version 5 clients in existence
> and none of them exhibited the bug at the weekend. However, we don't
> have 5.2.0.6. Maybe it's worth making a support call to IBM.
>
> If it's any help, I have pasted the text from the original alert readme
> from the version 4 client below, it does have some tips on circumvention
> or workaround.
>
>
>
> A problem with the switch between Daylight Savings Time (DST)
>
> and Standard Time (STD) has just been discovered for the
>
> Windows TSM clients.
>
>
>
>
>
> BACKGROUND
>
>
>
> When Windows NT and 2000 systems automatically switch between
>
> DST and STD, the time attributes for files stored on NTFS file
>
> systems will be shifted by one hour. This is because NTFS
>
> displays time information as an offset from Greenwich Mean Time (GMT).
>
> Thus when the DST change is made, the offset from GMT is changed,
>
> causing the timestamps on your NTFS files to also change.(Note: Time
>
> information for Event Viewer events is affected in the same manner,
>
> but that is not pertinent to this discussion.) Further information on
>
> this subject is available in the Microsoft Knowledge Base, item Q129574.
>
> If you point your web browser to Microsoft's MSDN site,
> http://msdn.microsoft.com,
>
> and search on "Q129574" (without the quotes), you will find the
> information.
>
>
>
>
>
> THE PROBLEM
>
>
>
> When the system automatically adjusts between DST and STD, the TSM 3.7.2
>
> (and higher) clients will see that the modification time has changed for
>
> all files on NTFS systems, and will proceed to back everything up
> accordingly,
>
> even if the file has not really changed. This will occur only once after
> the
>
> time change, and thereafter incremental backups will proceed as normal.
>
> However, this will almost certainly affect the amount of data backed up
>
> by each client, effectively causing a full backup on all NTFS file
> systems.
>
> This could have a large impact on network and TSM server resources.
>
>
>
> The following bullets summarize the conditions under which this problem
> can occur:
>
>
>
> - TSM client is running on Windows NT 4.0 or Windows 2000. TSM clients
> running
>
> on Windows 9x-based operating systems (Windows 95, 98) are not
> affected.
>
>
>
> - The TSM client level is 3.7.2.x or higher (including all 4.1.x
> levels). TSM
>
> client levels below 3.7.2.x are not affected, as the problem was
> introduced
>
> in the 3.7.2.x code.
>
>
>
> - The file systems are formatted for NTFS. FAT and FAT32 file systems
> are
>
> unaffected by this problem.
>
>
>
> - The operating system's time zone settings are configured to
> automatically
>
> adjust for DST. You can check this by right-clicking on the Windows
> task
>
> bar and selecting the "Adjust Date/Time" item in the pop-up menu.
>
> (Alternatively, you can double-click on the clock display in the task
> bar.)
>
> Either of these actions will bring up the "Date/Time Properties"
> dialog.
>
> Click on the "Time Zone" tab and you should see the "Automatically
> adjust
>
> clock for daylight saving changes" checkbox. If the box is checked
> (the
>
> default installation setting), then your system is configured to
>
> automatically adjust for DST. Users in regions that do not observe DST
>
> (such as Arizona) will be unaffected by this problem, provided that
> the
>
> system's time zone settings are similarly configured to not observe
> DST.
>
>
>
>
>
> WHAT IBM/TIVOLI IS DOING ABOUT THIS
>
>
>
> Here are the actions that we are taking or have taken to date:
>
>
>
> 1) We have opened a severity 1 APAR, IC28544, to address this problem.
>
>
>
> 2) We have designed and built fixtests for the 3.7.2 and 4.1.1 Windows
>
> clients. The fixtest version numbers are 3.7.2.17 and 4.1.1.17. The
>
> fixtests should be available in a little while. They will be posted
>
> to the anonymous FTP server ftp.software.ibm.com in the following
> locations:
>
>
>
> Version 4.1.1.17:
>
>
>
> Directory
> /storage/tivoli-storage-management/patches/client/v4r1/Windows/v411/sing
> le
>
>
>
> Package name start with: IP22088_17
>
>
>
>
>
> V3.7 PTF 2:
>
>
>
> Directory
> /storage/tivoli-storage-management/patches/client/v3r7/Windows/v372/i386
> /single
>
>
>
> Package name starts with: IP21933_17
>
>
>
>
>
> A follow-up note will be posted when the fixtests are actually
> available for download.
>
>
>
> 3) Even with the availability of a fixtest, most customers
>
> will be unable to roll it out in time for the time change.
>
> We have documented circumventions for this problem (see below),
>
> as the DST to STD switch is this weekend.
>
>
>
> 4) We are working on notifying all of our customers in the
>
> most expedient manner possible.
>
>
>
> 5) We are continuing our escape and root-cause analyses in
>
> order to prevent this kind of problem from happening again.
>
>
>
>
>
> CIRCUMVENTIONS
>
>
>
> Here are the known circumventions available thus far:
>
>
>
> 1) Lock all client nodes to prevent access to the TSM server.
>
> After the fixtest has been applied to each system, unlock
>
> that system's node(s). Since many nodes may be affected,
>
> a batch script may be helpful in facilitating the locking
>
> and unlocking of the nodes.
>
>
>
> 2) If the fixtest can not yet be applied, consider using
>
> the -INCRBYDATE option to back up the clients. The easiest
>
> way to do this is to add it to existing schedules' options
>
> setting via the UPDATE SCHEDULE administrator command.
>
>
>
> Example:
>
>
>
> UPDATE SCHEDULE STANDARD DAILY OPTIONS="-INCRBYDATE"
>
>
>
> or if your schedule already contains options, such as -SUBDIR=YES:
>
>
>
> UPDATE SCHEDULE STANDARD DAILY OPTIONS="-INCRBYDATE -SUBDIR=YES"
>
>
>
> Please refer to the Tivoli Storage Manager Administrator's
>
> Reference for further information on the UPDATE SCHEDULE command.
>
>
>
> Please refer to the Tivoli Storage Manager for Windows Using
>
> the Windows Backup-Archive Client for further information on
>
> the -INCRBYDATE option.
>
>
>
> 3) Same as #1 above, except instead of locking each node,
>
> disable all client sessions on the TSM server. This is easier
>
> than having to lock and unlock each node, but would require that
>
> all affected systems have the fixtest applied before re-enabling
>
> the server for client sessions.
>
>
>
> 4) Shut down your TSM server(s) until all affected systems can
>
> have the fixtest applied.
>
>
>
> 5) If the additional network and TSM server overhead is not a
>
> concern, you can just let the backups run to completion. However,
>
> because this can cause unchanged files to be backed up, the
>
> oldest version of each affected file will be expired. In order to
>
> avoid premature expiration, you may wish to add '1' to each
>
> backup copygroup's VEREXISTS setting. For example, if VEREXISTS
>
> is currently set to '15', you may wish to change it to '16'. Use
>
> the UPDATE COPYGROUP and ACTIVATE POLICYSET commands to implement
>
> this change. Example:
>
>
>
> UPDATE COPYGROUP STANDARD STANDARD STANDARD STANDARD VEREXISTS=16
>
> ACTIVATE POLICYSET STANDARD STANDARD
>
>
>
> Please refer to the Tivoli Storage Manager Administrator's
>
> Reference for further information on the UPDATE COPYGROUP
>
> and ACTIVATE POLICYSET commands.
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Farren Minns
> Sent: 31 October 2005 14:40
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] Problem after time change
>
> Hi All
>
> I'm sure this has been covered before and I've been looking on adsm.org
> but
> haven't found a decent answer yet.
>
> Basically, I'm running TSM Server 5.1.6.2 on Solaris.
>
> The problem client node in question is a Windows Server 2003 Standard
> Edition NAS with TSM client 5.2.0.6 running on it. After the clocks went
> back at the weekend it has started backing up files that as far as I can
> tell have not changed (although I'm not a Windows admin so I may be
> missing
> something). It doesn't appear to be doing a backup of absolutely
> everything
> (it managed to check 500,000 files before backing any up), but sadly the
> dir it is currently backing up is full of ghost images and is going to
> take
> a while.
>
> Has anyone else had any similar problems in the past?
>
> Many thanks
>
> Farren Minns
> Solaris System Admin / Oracle DBA
> IT - Hosting Services
>
>
> ######################################################################
> The information contained in this e-mail and any subsequent
> correspondence is private and confidential and intended solely
> for the named recipient(s). If you are not a named recipient,
> you must not copy, distribute, or disseminate the information,
> open any attachment, or take any action in reliance on it. If you
> have received the e-mail in error, please notify the sender and delete
> the e-mail.
>
> Any views or opinions expressed in this e-mail are those of the
> individual sender, unless otherwise stated. Although this e-mail has
> been scanned for viruses you should rely on your own virus check, as
> the sender accepts no liability for any damage arising out of any bug
> or virus infection.
> ######################################################################
|
