[gpfsug-discuss] mmbackup logging issue

[Jez Tucker]

Comments inline...

On 03/03/17 13:05, Ashish Thandavan wrote:
> Hi Jez,
>
>>
>>   This is the primary reason for using snapshots for mmbackup ( -S  
>> snapname ) and making sure that only mmbackup sends data to backup 
>> rather than an oob dsmc:
>>
>> Tue Jan 17 18:07:31 2017 mmbackup:Audit files 
>> /cs/mmbackup.audit.gpfs* contain 0 failed paths but there were 10012 
>> failures.
>> Cannot reconcile shadow database.
>> Unable to compensate for all TSM errors in new shadow database.
>>   Preserving previous shadow database.
>>   Run next mmbackup with -q to synchronize shadow database. exit 12   
>> <------------ ick!
>>
>
> I was going to send a separate email about this, but as you mention it 
> -- I was wondering if the TSM server requires the shadow files to also 
> be backed up? And that reconciliation of the shadow database will fail 
> if they are not?
No, that's not a requirement.

> (Unless of course, you mean above that the shadow database failure is 
> purely on account of the 10012 failures...)
More than likely.  Check the dsmerror.log and the mmbackup logs. There 
are also other possibilities which could exhibit the similar cases.

>
> Re the use of snapshots for mmbackup, are you saying dsmc does not get 
> involved in sending the files to the TSM server? I haven't used 
> snapshots for mmbackup, but will certainly try!
Snapshots provide a consistent dataset to backup.  I.E. no errors from 
'trying to backup a file which has been deleted since I first knew about 
it in the scan phase'.

But as per previous related thread 'Tracking deleted files', YMMV 
depending on your workload and environment.

>
> Regards,
> Ash
>