Re: [ADSM-L] How to restore (already expired) objects from tape?

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 <przygod AT gmail DOT 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.boogaart AT rz.uni-augsburg DOT 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 <przygod AT gmail DOT 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
> > >> <steve AT stevenharris DOT 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-----
> >
>