Matt,
Thanks for responding.
Actually, I'm embarassed to admit that the retention parameters in the
copygroup for the AFS policy set were retaining deleted data for a year. So,
I would have had to wait a year before the AFS data was reclaimed from the
tape. I've since updated the retention parameters, and the tape space has
been freed.
I did write a synchronization script for the buta backup data. Unfortunately
the butc backup data is all written to a single filespace. That is another
drawback to the butc dump implementation. The only way that I have found to
see the backup data from TSM output is to execute a 'query occupancy' on each
tape in the AFS storage pool, and then search the output files for the backup
dump ids. This is not a nice implementatoin. The butc convention of
creating a filespace for each dump was much nicer.
I think that I am going to adopt the convention of creating a new TSM node
name with each level 0 backup. That way, when the data is no longer needed,
I can simply remove all of the backup data for the node.
Are you using buta for AFS 3.6? I didn't think that was supported.
- Kent
On Feb 21, 2:42pm, Matthew A. Bacchi wrote:
> Subject: Re: AFS 3.6 butc deletedump
>
> >Is there a synchronization utility to force the synchonization of the TSM
> >data with the AFS backup database?
>
> Kent,
> This is a good question, but I don't think there is. I have used
BUTA
> for 1+ years now, and there is a sync option with the delbuta utility.
When
> doing some testing with BUTC in the last six months I noticed there wasn't
a
> similar function. I'm currently not using BUTC because the 'backup
> diskrestore' function doesn't work with BUTC on afs36, but this problem
could
> be a show stopper as well. Anyway, I assume you have already read the
Release
> Notes
>
>(http://www.transarc.com/Library/documentation/afs/3.6/unix/en_US/HTML/RelNotes/aurns002.htm)
> which describe the new options when using the 'backup deletedump' command,
> such as -dbonly and -force. You might also try writing you own
syncronization
> script, which would consult the AFS backup database, then do ADSM "delete
> filespace" commands for each dump that isn't in AFS anymore. Or as a last
> resort, maybe you want to open a problem with support on this.
>
> Good luck, and let us know what you end up doing, I'd be interested.
>
> -Matt
>
> /**
> **Matt Bacchi [EMAIL PROTECTED]
> **IBM Global ServicesSDC Northeast
> **F6TG; MD Filesystems/Internet (802) 769-4072
> **ADSM & AFS/DFS Backup (tie) 446-4072
> **/
>
>-- End of excerpt from Matthew A. Bacchi
--
Kent JohnsonInternet: [EMAIL PROTECTED]
Unix Systems Programmer (VCC 323) Phone: (518) 276-8175
Rensselaer Polytechnic Institute Fax: (518) 276-2809
