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
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
