If the file is of size A (1,272,979,456 bytes in your case) when the backup starts, and in the middle of the backup, changes to size B ( 1,278,222,336 bytes), then TSM only backs up size A bytes of the file. Note that the output shows that size B bytes were backed up; that output is wrong.
Upon restore, the file is of size A, not size B (i.e. the difference between A and B is lost). But the data should still be good, up to size A. Whether it is usable by the application is another matter. For instance, if there are multiple files involved, some > 10 MB and others smaller (files less than 10 MB are unaffected by this problem) then as a group, the files may be out of sync with each other. Without discounting this problem, I will add that you run this risk using dynamic serialization even without this problem. Unless the truncation of data is acceptable, I would strongly discourage the use of dynamic serialization, shared or not. Regards, Andy Andy Raibeck IBM Software Group Tivoli Storage Manager Client Development Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED] Internet e-mail: [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> wrote on 06/24/2004 07:33:31: > Thanks, Andy that sounds like it could be it! > > The APAR states: > > "If the TSM client inspection phase examines a file which changes > shortly afer the inspection occurs, but before the actual data > is sent to the TSM server, an improper file backup of the object > will exist on the TSM server. This can cause subsequent restore > actions of the object to restore the improper file size of the > object, which could prevent associated applications from using > the data correctly." > > Is this saying that the restore is not actually restoring all of the data?!! > > > -----Original Message----- > From: Andrew Raibeck [mailto:[EMAIL PROTECTED] > Sent: June 24, 2004 9:16 AM > To: [EMAIL PROTECTED] > Subject: Re: Size of backed up file does not match size of restored file > > Hi Tim, > > This might be APAR IC40702. > > Regards, > > Andy > > Andy Raibeck > IBM Software Group > Tivoli Storage Manager Client Development > Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED] > Internet e-mail: [EMAIL PROTECTED] > > The only dumb question is the one that goes unasked. > The command line is your friend. > "Good enough" is the enemy of excellence. > > > > "Rushforth, Tim" <[EMAIL PROTECTED]> > Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > 06/23/2004 14:22 > Please respond to > "ADSM: Dist Stor Manager" > > > To > [EMAIL PROTECTED] > cc > > Subject > Size of backed up file does not match size of restored file > > > > > > > Can anyone tell me what TSM uses as the size of file as reported by > scheduled backup (Dsmsched.log) and a command line restore. > > > > We have a case where a file is backed up using a dynamic mgmt class. This > file changes during backup. > > > > The file size as reported by backup is: > > > > 06/21/2004 22:51:08 Normal File--> 1,278,222,336 \\xxxxxxxxxxx [Sent] > > > > The file as reported by restore is: > > > > Restoring 1,272,979,456 xxxxxxxxxxxxxxxxxx [Done] > > > > The file restored has a modified date of 06/21/2004 22:34. The backup of > the server started at 06/21/2004 at 22:30. There were no other backups of > this file after this backup. The active file was restored. > > > > So the size of the file as reported by restore does not match the size of > the file as reported by backup. > > > > > > Thanks, > > > > Tim Rushforth > > City of Winnipeg