Kyle, I like your idea and think if we refine it further it can become a fairly good recipe (IMHO). Step 1a. Have separate storage hierarchy for nodes requesting "PIT backups" over same device classes. Let's call it DISK-PIT, FILE-PIT and TAPE-PIT. Steps 2&3 - unchanged. Set Reusedelay=<longest retension period for PIT backups>. How much to raise the reclamation threshold I be sure but think disabled (sorry I have no long term experience as some other people on this list). If retension periods are very disimilar we can have COPY1-PIT and COPY7-PIT for 1 and 7 years respectively. Countinue as you described backing up *-PIT pools to COPY-PIT and making DB snapshots. On restores DBS can be restored to another server or second instance. You do not need to restore *any* primary pool. Just mark all volumes unavailable and restore would take place right from copy pool volumes. The main disadvantage is huge waste of tapes but if the management demands this to be accomplished the old traditional way ... The implementation with any Full/Incremental product would produce same ammount of tape usage/waste.
Zlatko Krastev IT Consultant Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: Point in Time Backups This may be totally unsuitable for your environment, but actually, I had been thinking about the properties of 'REUSEDELAY' and database backups recently, and I think maybe it could be used to create something to this effect for your customers at large; I wouldn't know how to drill it down to individual nodes, however. Also, because of the way it works, it would only really be useful for archival purposes, not for data you anticipate needing to restore on a regular basis. The actual restore would be a severe pain :) The idea goes something like this: 1. Assume you have the following pools -- DISKDATA, TAPEDATA, and COPYTAPE. 2. DISKDATA is obviously a disk pool, TAPEDATA is your primary tape media, and COPYTAPE is your backup storage pool for both DISKDATA and COPYTAPE. 3. Define a third storage pool, COPYPIT -- copy-point-in-time. Do your normal client backup/migration/stgpool backup with DISKDATA, TAPEDATA, COPYTAPE. Whenever you want to do a point in time backup, do _another_ backup of DISKDATA and TAPEDATA onto COPYPIT. Take a database snapshot. Send COPYPIT and the DBSNAPSHOT offsite, and leave them offsite forever (or out of library). Take note of which volumes and database snapshots correspond to which dates -- you might want to store these offsite too. In the future, if you need to restore from one of the point in time backups, recall the tapes and the snapshot you took from the appropriate day, and you should be able to restore to that point in time. Drawbacks: 1. You have to be very, VERY careful about reclamation. The TSM server is going to be expiring these files, and you'll likely have no real way of knowing which volumes to reclaim. More than likely, your best, safest bet is to write off the tapes, and never reclaim them. 2. Restoration is a HUGE, MASSIVE pain. You'll need to recall the tapes, restore the database, then restore the storage pool, etc, before you can even think about restoring the data. This is certainly no help if you need to be able to restore from these PIT backups on a moments notice. You'll also need lots of scratch tapes to do the restoration, and you'll have to take precautions to make sure that you don't accidentally restore over current data -- probably by removing all 'current' tapes from the library, or using a totally different machine and compatible library. 3. I don't think you can easily do this only for a subset of nodes. Advantages: 1. Easier to maintain than doing more than a certain amount of backupsets. Comments? I may need to do something like this in the future, and if anyone has any reasons why this is not really workable, it'd save me a headache having to find it out the hard way. And yes, I know this is a horrible kludge. :) Thanks, Kyle Sparger