Be aware that there are many reasons why you won't be able to restore, even
if the backup DID work successfully.  For example:
**
**

   - *Tapes are damaged or unavailable*
   - It's easy to damage tapes when you transport them to your off-site DR
      tests.
   **
   - Critical files are excluded
      - Users (or TSM Admins) can be fooled by the pattern-matching in TSM's
      include-exclude system.
      - *Backups are incomplete*
      - Drive C: may be a standard windows image, drive D: holds the work.
      A user can change DOMAIN ALL_LOCAL to DOMAIN D:\ to skip the needless
      drive-C backups  That works fine until they add drive E, which TSM will
      quietly ignore.
   - *"Rogue" servers never got registered to TSM*
      - Gartner says this problem has escalated lately with VMware machines
      popping up everywhere.
   - *Restore too slow
   *
      - Backups scattered over hundreds of volumes, filesystems with
      millions of files, and use of compression can all result in restores that
      are too slow to be usable.
      - *Poor communication with DBAs*
      - A database admin can break the incremental logging cycle by doing a
      full backup manually on Tuesday.  The TSM admin then doesn't know how to
      recover to Wednesday's backup.

So I'm with Richard (and most storage auditors): you need to test
restorability.

--------------------
Lindsay Morris
CEO, TSMworks
Tel. 1-859-539-9900 <skype:18595399900?call>
lindsay AT tsmworks DOT com


On Fri, Sep 17, 2010 at 7:33 AM, Dwight Cook <cookde AT cox DOT net> wrote:

> In general computing you will want to have your production data center with
> all your production servers and your remote site data center functioning as
> your production fix / test / development / disaster recovery data center.
> Wise processing practice is to perform monthly production fix refreshes
> from
> your production backups.  This type of activity validates the integrity of
> your production backups along with your restoration process and assists in
> being SOX compliant.
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> wesley.introvigne
> Sent: Thursday, September 16, 2010 7:03 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] Validate backup and archives.
>
> Dear friends,
>
> how can I validate that the data from a server have been copied
> successfully. (Backup)
>
> Is there any command to validate tsm backup or archive or in the best way
> to
> validate a backup.
>
>
>
> Best Regards
>