We didn't have any client encryption, if that's what you mean. But I doubt it would work, in essence it's just dumping data straight off the tape.
On Thu, 16 Apr 2015 12:32 Krzysztof Przygoda <przy...@gmail.com> wrote: > Hi > @ Steven > Is this recovery program available only for systems which don't use any > sort of encryption or something changed in that matter? > @Gregor > If you have such possibility(and still have tsm db backups) I would > recommend to restore tsm db not on production but on some separate machine > with read-only access to copy pools (set primary stg's to unavailable) and > its devices/libraries. In that way you can go on with production and if you > will mess up with copy pool volumes the last thing you will have to do will > be recreation of damaged copy pools. > > Kind regards > Krzysztof > > > 2015-04-14 18:14 GMT+02:00 Gregor van den Boogaart < > gregor.booga...@rz.uni-augsburg.de>: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi Krzysztof, hi Steven, hi Steven, > > > > thanks for all the hints on restoring the DB and commercial > > alternatives! I had the feeling that this would be a supported > > approach, but was not aware of the details. I am now... Due to unlucky > > timing our DB backups are probably expired, but there would be a > > chance the older DB backup tapes could be identified and have not been > > reused. So it would theoretically be possible. > > > > As only a single - although important - object has been lost, the > > decision over here was to focus on preventing this from happening > > again. Restoring the DB and all that would possibly have a to big > > impact on normal TSM operations for us this time. > > > > However I still would like to restore the object. Therefore the last > > question. I came across this > > > > > > > http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/179-reading-tsm-tapes.html > > > > which mentions > > > > http://sourceforge.net/projects/tsmtape/ > > > > as an open source possibility to read TSM written tapes: > > > > "TSMtape allows recovery of files found on TSM v5.x (tested against > > 5.2) tapes." > > > > I wonder whether anybody has used this successfully (we are still > > running TSM 5.5)? > > > > Gregor > > > > > > > > On 04/14/2015 03:14 PM, Steven Langdale wrote: > > > We had a data loss "incident" a couple of years back. There is no > > > way to re-populate the TSM DB from a tape. You have 2 options: 1. > > > Do a DB restore to before the data was deleted from the TSM DB 2. > > > Use a data recovery process to re-read the tapes. > > > > > > We used Option 2, and got most of it back. IBM supplied the > > > program to read the data from tape and put it into a directory > > > structure. > > > > > > Steven > > > > > > On Tue, 14 Apr 2015 at 14:05 Krzysztof Przygoda <przy...@gmail.com> > > > wrote: > > > > > >> Hi I guess its better to disable schedules before you start (by > > >> adding disablescheds yes in dsmserv.opt file) the resorted server > > >> than to do it after start (as some jobs can start just after > > >> startup). > > >> > > >> > > > http://www-01.ibm.com/support/knowledgecenter/SSGSG7_7.1.0/com.ibm.itsm.srv.ref.doc/r_opt_server_disablescheds.html > > >> > > >> > > >> > > Kind Regards > > >> Krzysztof > > >> > > >> 2015-04-14 14:48 GMT+02:00 Steven Harris > > >> <st...@stevenharris.info>: > > >>> Hi Gregor. > > >>> > > >>> IBM used to offer a special service to get data off tape. Not > > >>> sure if it is still available. > > >>> > > >>> Other than that the only way I know is to restore your DB to a > > >>> point before expiration. Start up the restored instance with > > >>> NOMIGRECL and immediately stop your daily schedules, in > > >>> particular stop running expiration. At this point you can > > >>> restore your file. I would tend to mark the primary volumes as > > >>> unavailable and restore from the copypool. That way you if you > > >>> have restored to another instance you can keep your main > > >>> instance running close to normal (except for copypool stuff) > > >>> for however long the restore takes you. But it is a lot of > > >>> work and a lot of fiddling about. > > >>> > > >>> Regards and good luck. > > >>> > > >>> Steve > > >>> > > >>> Steven Harris TSM Admin Canberra Australia. > > >>> > > >>> > > >>> > > >>> > > >>> On 14/04/2015 10:10 PM, Gregor van den Boogaart wrote: > > >>>> Dear List, > > >>>> > > >>>> the retention settings in the copygroup were to strict... The > > >>>> version of the file we would like to restore has already been > > >>>> expired. :-( However it is very likely the desired version of > > >>>> the file is still on tape, as no reclamation has taken place. > > >>>> So my understanding would be: if the file is still on tape, > > >>>> the "only" thing missing is the database entry. Correct? > > >>>> > > >>>> So the question would be: How to restore already expired > > >>>> objects from a tape cartridge? Or: How to generate database > > >>>> entries for all versions of all objects on a tape cartridge? > > >>>> > > >>>> I guess the first step would be to move the respective node > > >>>> to a copygroup, with "better" retention settings. I looked on > > >>>> the documentation for "audit volume", but I did not get the > > >>>> feeling this would understand checking "for inconsistencies > > >>>> between database information and a storage pool volume" in > > >>>> un-expiring previously expired objects... > > >>>> > > >>>> Any tips, pointers, ideas? Perhaps I am just searching for > > >>>> the wrong key words? > > >>>> > > >>>> Gregor > > >>>> > > >>>> > > >>>> > > >> > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1 > > > > iQIcBAEBAgAGBQJVLTzrAAoJEB+PYKvaHDDMG3wP/j5PXx+sm5DFJZygVLmZ+uTV > > Oi6UpIYYaHs7Wxi1tf8zkacHdDoKSdMHoEexRp+1GVExQ4gudJcfXiHyC0O7VQko > > XdOL9KV4nZdGEzRcRCqXgY+eSBTmxZmGMc6W1U5PD22erHV9EpEOOOJxfw5D74l5 > > VZxzDd0ix5pgcRCfAd9XWr3CF5QTkwZPa3OTaRPeQabtY1/wlA0RyPhtmse0n3mW > > Qa/HwDid8gy2+e44YTQYfr4mWKLAVgpSZp8P+N57isRPWCxEQBPicSH45YpACnM7 > > hXlDFHyPKl2hbvSJptw5Sy2Qj4ZgIwm+VpryMPhqqsael7ijSj8TML/47KxL+i2V > > IONBONMo8gBtV7CQy6uw5m+YzALztvRpXBTy0TGL1jujzFvHpi+tw53RllJjeV2g > > c0IdSvkNcs8fSwlaPbjCx2sBQBBvuww29kXec5+aEFAWXukC2NAoIWONaJKvOHaQ > > ZWeLVtNdzKwNjw5EqhULtsOfFiXriU/l7IdqrrfjnwYQP2SaC5VeUMDtelydQyGQ > > 6p8LovYuVAcsRX1kuhhafR4El2+J4O8v4jFqZ2LMj3HyRFWA6szK+l4MFS/rvX69 > > AAOG3jlHJG9d3o/NhNmUJtIvZ1fYBFIUhkLtAwO6Fh8IKtJbIvUPiK4P312CuAaY > > 9zaf1NK0xGmmw0b4GyjE > > =yp3D > > -----END PGP SIGNATURE----- > > >
