See below for my replies...
>In your experience is restore actually faster with collocation?
That depends (I hate saying that!) The data will not be transferred
faster, if that's what you mean. If you're comparing a restore from a
non-collocated storage pool that contains 50 nodes, vs. a restore from a
collocated storage pool, you'll probably have fewer tape mounts with the
collocated pool.
Fewer tape mounts = less media wait = faster restore. And that is how
collocation is supposed to work.
>The strategy I am considering is to use TSM for mostly short term storage
>for the bulk of my data and to use a different system for monthly backups.
I'm guessing you want to keep a month's worth of daily backups, and a
year's worth of monthly backups, or some variation on that theme. That's a
typical "traditional" backup scenario. I suggest you avoid it if possible
(although we do that in some cases). The main reason to do that is
everyone is afraid of having to buy and track and store thousands of tape
cartridges. The problem with it is, after that month of dailies is gone,
you only have the state of the client as it was on the day when the monthly
was taken. If you do your monthly on the 30th, and someone needs a file
that was created last January 10th, then deleted on January 20th, you can't
help them. That kind of request is really an archive/retrieve situation.
TSM's backup/restore is really intended to bring a
file/filesystem/drive/machine back after some loss (hardware, accidental
delete, etc.) and usually you want the latest version, which TSM is very
good at handling with daily incrementals.
This could turn into a political/philosophical debate, but really, the
owner of the data (the end user) is responsible for archiving it for long
term storage. You as the TSM admin can facilitate that for them, but
policy needs to be set regarding how much to archive, how frequently, and
for how long, and the data owner should foot the bill for the media.
(Soap box mode off)
>Alternatively I am considering using Archives for my long term.
That's what we do for our Domino servers, for the reason stated above (too
many tapes). I had lengthy discussions with the Domino admins about it,
and they accept that they only have monthly snapshots, and probably will
have to say "I'm sorry" someday when someone needs that email they lost on
January 15th. But, you know what? It'll probably never happen ;)
>Previously ADSM was not very good for Point in time or "snapshots".
It is cumbersome at times. In the past we have done PIT restores in
Disaster Recovery tests. We have one coming up next week, and this time
we're opting for a straight restore (active versions). That's probably
what we would do in a real disaster anyway.
>Even if there was a way to move all data from a node to a storage pool,
>this may be able to do the defragmentation.
I've never tried it, but maybe an export/import would do the trick?
>I would also like to have a way to see where the data from a file space is
>(i.e. storage pools, tapes).
You can get some of that with "q contents", "q backups", and "q
volumeusage", but they take a real long time to run. What you can't get
(at least I haven't found a way) is "What tape is version #5 of file
xyz.txt on?". TSM can get this of course, because it always knows
immediately what tape to mount when you restore that file. As many have
said before, what we need is a way to preview what tapes will be needed for
a restore, like the "restore volume" command has.
Robin Sharpe
Berlex Laboratories
|
