ADSM-L

Re: Disk Only backups

2005-12-06 11:58:02
Subject: Re: Disk Only backups
From: William Boyer <bjdboyer AT COMCAST DOT NET>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 6 Dec 2005 11:58:01 -0500
If you collocate you run the risk of not being able to use the multi-session 
restore capability of the client. As for the n-servers
backing up you will have N-files open...what if you're running a 
RESOURCEUTILIZATION higher than 2 on the client? You can have more
that N files open if the clients have more than 1 data backup session running. 
On either collocation or not. You will just have to
make sure your MOUNTLIMIT is set high enough on the device class.

As for the size, I would make it a managable number and a multiple of the 
filesystem size and pre-allocate the files using DSMFMT
and define them to the stgpool. You could then define either a spacetrigger or 
a nextpool for your tape in case you run out of
space. Pre-allocating the filesize let's you fill up the filesystem without 
having to figure out a MAXSCRATCH value. Should probably
figure out what the "N" is above and allocate that many.


Bill Boyer
"Some days you're the bug, some days you're the windshield" - ??

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Allen S. Rout
Sent: Tuesday, December 06, 2005 10:46 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Disk Only backups

==> On Mon, 5 Dec 2005 16:33:43 -0500, "Spearman, Wayne" <wmspearman AT 
NOVANTHEALTH DOT ORG> said:


> We are planning to move a large number of our nodes to "disk only"
> backups and eliminate tape for them. The diskpools will be
> devtype=file.  I struggle with whether to collocate these disk volumes
> or not and how large to make them. I've had some discussions with IBM,
> but would like to ask others to share their experiences with me.


For collocation, my question would be 'Why ever not?'  If you've got N machines 
backing up simultaneously, you'll have N files open;
I'd say pick the "correct" N.

As for size, My aesthetic opinion on this is that they should be substantially 
smaller than 1% of the enclosing capacity.  So if
you've got a 1TB of space, I think a 10GB volume is too big.

The last time I actually picked a number, we had ~8TB of space, and I picked a 
5GB volume size.  This meant that my reclamation was
happening in what felt like manageable chunks, and if I wanted to actually move 
things around I could do so on a sane granularity.

The other force on volume size is "I don't want to have too many to manage".
I'll assert that once you get into disk-only backups, you're going to have a 
volume count which you will -need- to manage in an
automated fashion.  So you _will_ be writing scripts to do things, instead of 
typing e.g. "move data"
commands at the TSM> prompt.  SO since you've already lost the manual-operation 
battle, you may as well go for the "reasonaby small"
win.


Keep in the back of your mind that backupsets are portable; if you write a 
backupset to disk, and then copy it somewhere else, you
can use it indefinitely. So the FILE storage might be accessed from somewhere 
other than thru TSM.



- Allen S. Rout

<Prev in Thread] Current Thread [Next in Thread>