Yes, that is the way it works. And it becomes even worse, because as an
ADSM admin you do not even know, whether a files space is dead or not,
since the "Last Backup Date" yielded by "query filespace" does not reflect
selective backups done by the client.
The way I am handling this situation is:
- export the filespace into a file
- archive this file
- delete the filespace (type=backup !!!)
The filespace now does not occupy database space any more; it still
occupies pool space, but we can afford that.
Beach Shelby writes:
> We have had several of our OS/2 clients re-label volumes which were being
> backed up by ADSM. The result of this, as might be expected, is that ADSM
> creates a new file space for the "new" volume and begins backing it up.
> The question is, what happens with the files in the old file space (i.e.
> the file space corresponding to the prior volume label). One would hope
> that over time, based on the management class associated with those files,
> that they would eventually expire. The longest retention period we have
> specified for a backup copy group when the file is deleted is 60 days. Yet
> we have had files which stick around in these "orphaned" file spaces for
> over 200 days. It's as though the original files are not actually
> considered deleted and hence the clock to expire them never starts
> running.
>
> Our solution, of course, was to delete the file spaces. Is this the way it
> is supposed to work? It seems a little bit nasty that our clients can
> consume considerable backup pool space as well as database space simply
> because they have re-labeled a volume. We can tell them not to do it, but
> it doesn't mean that they won't.
--
Reinhard Mersch Westfaelische Wilhelms-Universitaet
Reinhard Mersch Westfaelische Wilhelms-Universitaet
Universitaetsrechenzentrum, Einsteinstrasse 60, 48149 Muenster, Germany
E-Mail: mersch AT uni-muenster DOT de Phone: +49(251)83-31583
|