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/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com
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 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:storman AT US.IBM DOT COM]
> Sent: June 24, 2004 9:16 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> 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/IBM@IBMUS
> Internet e-mail: storman AT us.ibm DOT com
>
> 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" <TRushforth AT WINNIPEG DOT CA>
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> 06/23/2004 14:22
> Please respond to
> "ADSM: Dist Stor Manager"
>
>
> To
> ADSM-L AT VM.MARIST DOT EDU
> 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
|
