We just got TSM and have been testing and preparing to deploy it. Our new backup strategy is to eliminate tapes and make use of the node replication and deduplication features in TSM 6.3. While attempting to restore a DB from to a different node from the target replicated node, the restore results in a failure. Both TSM servers are 6.3.2 and all nodes are using the BA client 6.3 and TDP SQL 6.3. Below are the results from the tdpsql.log of the attempted restore from the target replicated node to a different SQL server.
11/07/2012 08:39:59 ACO5456W The backup is corrupt and is not fully restorable.
11/07/2012 08:39:59 Processing will continue.
11/07/2012 08:40:00 Restore of PERFORMANCELOGS failed.
11/07/2012 08:40:00 An exception occurred while executing a Transact-SQL statement or batch.
11/07/2012 08:40:00 The volume on device 'TDPSQL-00000E4C-0000' is empty.
11/07/2012 08:40:00 RESTORE DATABASE is terminating abnormally.
11/07/2012 08:40:00 Changed database context to 'master'. (HRESULT:0x80131501)
11/07/2012 08:40:00 Total database backups inspected: 1
11/07/2012 08:40:00 Total database backups requested for restore: 1
11/07/2012 08:40:00 Total database backups restored: 0
11/07/2012 08:40:00 Total database skipped: 0
11/07/2012 08:40:00 Throughput rate: 0.00 Kb/Sec
11/07/2012 08:40:00 Total bytes transferred: 0
11/07/2012 08:40:00 Total LanFree bytes transferred: 0
11/07/2012 08:40:00 Elapsed processing time: 1.40 Secs
11/07/2012 08:40:00 ACO0151E Errors occurred while processing the request.
11/07/2012 08:40:00 ACO0151E Errors occurred while processing the request.
We contacted IBM with this and were surprised to hear that this is a known issue. Is this indicative of this product? What is the average turn around time on these kinds of issues? It kind of shoots a big hole in our recovery strategy if we can't restore from a replicated node.
As a side note, I know you're not suppose to be able to restore VSS backups of DB's to a different target SQL server, but I have been able to do it. And, from the target replicated node, no less. Although, the DB does not attached after the restore and this has to be done manually. Has anyone else noticed this behavior? Or, am I reading the docs wrong and this is something you can do?
11/07/2012 08:39:59 ACO5456W The backup is corrupt and is not fully restorable.
11/07/2012 08:39:59 Processing will continue.
11/07/2012 08:40:00 Restore of PERFORMANCELOGS failed.
11/07/2012 08:40:00 An exception occurred while executing a Transact-SQL statement or batch.
11/07/2012 08:40:00 The volume on device 'TDPSQL-00000E4C-0000' is empty.
11/07/2012 08:40:00 RESTORE DATABASE is terminating abnormally.
11/07/2012 08:40:00 Changed database context to 'master'. (HRESULT:0x80131501)
11/07/2012 08:40:00 Total database backups inspected: 1
11/07/2012 08:40:00 Total database backups requested for restore: 1
11/07/2012 08:40:00 Total database backups restored: 0
11/07/2012 08:40:00 Total database skipped: 0
11/07/2012 08:40:00 Throughput rate: 0.00 Kb/Sec
11/07/2012 08:40:00 Total bytes transferred: 0
11/07/2012 08:40:00 Total LanFree bytes transferred: 0
11/07/2012 08:40:00 Elapsed processing time: 1.40 Secs
11/07/2012 08:40:00 ACO0151E Errors occurred while processing the request.
11/07/2012 08:40:00 ACO0151E Errors occurred while processing the request.
We contacted IBM with this and were surprised to hear that this is a known issue. Is this indicative of this product? What is the average turn around time on these kinds of issues? It kind of shoots a big hole in our recovery strategy if we can't restore from a replicated node.
As a side note, I know you're not suppose to be able to restore VSS backups of DB's to a different target SQL server, but I have been able to do it. And, from the target replicated node, no less. Although, the DB does not attached after the restore and this has to be done manually. Has anyone else noticed this behavior? Or, am I reading the docs wrong and this is something you can do?
