Re: Client backup verification
Dwight, there is only one problem with this, SELECTIVE does not update these fields in the database. There was a long discussion about this. The sum of it all was these fields are to support incrbydate. However, I do the same thing you do because we do not use selective backups. Paul D. Seay, Jr. Technical Specialist Naptheon Inc. 757-688-8180 -Original Message- From: Cook, Dwight E [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 2:04 PM To: [EMAIL PROTECTED] Subject: Re: Client backup verification A lot of people will say a lot of different things in response to your question BUT... If you schedule a nightly incremental backup, (annd if you retain event status long enough) you can do things like q event * * begind=-7 endd=today from a "dsmadmc" admin session and see the results (as reported by the clients) for all the scheduled events over the last week. A "missed" is a big problem but often times a "failed" can be OK, dependes on what exactly failed... (file might have changed during backup and/or deleted between when tsm built its list of files to backup and actually got around to backing up that specific file...) BUT I like: select node_name,filespace_name as "Filespace Name ",cast((backup_end) as varchar(10)) as "Date" from adsm.filespaces where (cast((current_timestamp-backup_end)day as decimal(18,0))>3 ) The above query command, if issued from a "dsmadmc" session will show you each file space for each client that hasn't ~backed up~ in the last 3 days (may adjust the # ov days by that last ...>3) Now what does this really tell you ? It points out file spaces/systems that have been removed from a client. (tsm won't EVER automatically purge that data, you must with a ~del file ~ command) It points out a lot of things that might not be pointed out in other places... like when, for some odd reason, all other things report successes YET there is still some sort of failure ??? just my 2 cents worth... Dwight E. Cook Software Application Engineer III Science Applications International Corporation 509 S. Boston Ave. Suite 220 Tulsa, Oklahoma 74103-4606 Office (918) 732-7109 -Original Message- From: Spearman, Wayne [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 12:51 PM To: [EMAIL PROTECTED] Subject: Client backup verification Hi all, New to TSM. Would like to know how others are verifying client backups are ending normally. Running on AIX. Please share macros,command, and/or scripts. Thanks in advance Wayne This message and any included attachments are from NOVANT HEALTH INC. and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail. Thank you.
Re: Client backup verification
A lot of people will say a lot of different things in response to your question BUT... If you schedule a nightly incremental backup, (annd if you retain event status long enough) you can do things like q event * * begind=-7 endd=today from a "dsmadmc" admin session and see the results (as reported by the clients) for all the scheduled events over the last week. A "missed" is a big problem but often times a "failed" can be OK, dependes on what exactly failed... (file might have changed during backup and/or deleted between when tsm built its list of files to backup and actually got around to backing up that specific file...) BUT I like: select node_name,filespace_name as "Filespace Name ",cast((backup_end) as varchar(10)) as "Date" from adsm.filespaces where (cast((current_timestamp-backup_end)day as decimal(18,0))>3 ) The above query command, if issued from a "dsmadmc" session will show you each file space for each client that hasn't ~backed up~ in the last 3 days (may adjust the # ov days by that last ...>3) Now what does this really tell you ? It points out file spaces/systems that have been removed from a client. (tsm won't EVER automatically purge that data, you must with a ~del file ~ command) It points out a lot of things that might not be pointed out in other places... like when, for some odd reason, all other things report successes YET there is still some sort of failure ??? just my 2 cents worth... Dwight E. Cook Software Application Engineer III Science Applications International Corporation 509 S. Boston Ave. Suite 220 Tulsa, Oklahoma 74103-4606 Office (918) 732-7109 -Original Message- From: Spearman, Wayne [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 12:51 PM To: [EMAIL PROTECTED] Subject: Client backup verification Hi all, New to TSM. Would like to know how others are verifying client backups are ending normally. Running on AIX. Please share macros,command, and/or scripts. Thanks in advance Wayne This message and any included attachments are from NOVANT HEALTH INC. and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail. Thank you.
Client backup verification
Hi all, New to TSM. Would like to know how others are verifying client backups are ending normally. Running on AIX. Please share macros,command, and/or scripts. Thanks in advance Wayne This message and any included attachments are from NOVANT HEALTH INC. and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail. Thank you.