David A. Chapa wrote, in part:
>                        ...  I'm intrigued by the response to #1, I always
> thought you were stuck after you allocated your DB volume size...its been
> sometime since I looked at this product.

Brian's quite correct. You can add a new chunk of disk space by 
formatting it with a supplied utility, and then invoking 2 (online) 
commands, one to tell *SM the chunk is now DB space and the other to 
allow *SM to expand its use to the new space (you can reserve part of 
your DB space for a rainy day).  This method works perfectly for *SM DB 
space and its mirror (or 2), if you have a mirror.

Disk spaces for backup data, called disk storage pools, may be defined, 
  expanded and contracted online in a similar fashion.

On another topic of your comparison: "incremental forever"... This is 
perhaps the biggest difference between NBU and *SM. If you use *SM, NBU 
looks crude; if you use NBU, *SM looks eclectic at best.

"Incremental forever" has been renamed "progressive incremental" by IBM 
marketing.  It does mean that only one copy of a file is ever backed up. 
*SM uses fewer tapes and backs up less data because of this, but it 
means that tape "reclamation" is an integral part of *SM, and a 
substantial part of *SM tape processing.

*SM has an archiving function that might be compared to NBU's user backups.

"Progressive incremental" means that large restores of many files 
created over time may require many tape mounts on *SM, especially for 
"non collated" tape pools where several or many clients data get written 
to any given tape.  Collated tape pools minimize this by putting 1 or a 
few clients' data on each tape.  Collocation can be by file space, 
allowing "n" file spaces of a client to be restored at the same time 
from "n" tapes on "n" drives.

An oddity (from NBU standpoint) is that static files on a file system 
never expire.  If you stop doing backups, the last image *SM had of the 
file system will be kept forever (unless manually deleted).  The only 
manual deletion is at the file space level.

As NBU has features not in *SM, the reverse is also true. For example, 
an integral part of *SM is the ability to create a "backupset" ... 
basically an image that can be restored to a client w/o backup server 
involvement. Another is "journaled" backups. With Journaled backups, 
only file system changes (as reported by Windows) are sent. Subfile 
backups allow changed portions of files to be sent, useful on mobile 
machines or bandwidth-limited clients.  Because *SM backs up only 
changed files, I can backup a mobile or home system, because a "full" 
backup is only done once.  For example, I've backed up 20G of stuff off 
my home system.  When I started, I'd just let the backup go for hours. 
Kill the backup whenever I needed TCP/IP performance ... and just start 
again later. *SM just skips files already backed up.

I especially miss 2 features of *SM on NBU. First is that all clients, 
whether GA or MP or patch are available as single file downloads from 
the vendor. None of this CD ordering crap (I still don't have FP3 
because of this).  New clients don't install the GA, then patch ... just 
install the patch file ... it's complete.  *SM also leads in the ability 
to easily see what code level each client has from the client or server.

Second is that an ad-hoc Full or Incremental NBU backup appears not 
possible from the client.  I'm considering building an INET daemon on my 
master server to listen for a poke by one of my client machines.  The 
client end would have a tiny widget that would say "I'm client c; gimme 
a backup using policy p and schedule s now, please". The daemon would 
run the appropriate bpbackup command.  Is there an easier way that I'm 
missing?

*SM and NBU logging are much different, but each serves its purpose.

*SMs syntax for Include/Exclude is superior, but each OK.

Enough for now. Hope this helps!  cheers, wayne
-- 
Wayne T. Smith -- WTSmith AT Maine DOT edu -- Systems Software Analyst
University of Maine System (UNET)