What kind of feedback are you looking for?

I use this product daily, and what you want to do is theoretically
feasible. I do not consider ISM difficult to administer by any stretch
of the imagination.

The only caveat to keep in mind when using onbar / ISM with XPS is that
if you use external tables to load raw or operational tables (where the
database uses light appends), you should either be able to re-create the
data in those tables in case of failure, or take a backup after each
load. Light appends, as their name suggests, append data to the end of
the table, rather than performing row-by-row inserts. This is a very
fast way to insert data into the table, but since it bypasses the buffer
pool, the inserts do not get logged. Thus you cannot restore from last
week's level 0 and expect the logical log roll-forward to bring the data
in these tables up to date.

ISM allows only four devices to be defined, and all devices must be
directly attached to the server. It does not allow the backup to be
written to a backup server or a tape drive on another server. Since you
are planning on backup to disk, you can write to an NFS file system.

You don't mention your operating system, but with UNIX (Solaris in my
case), if root performs the backup, onbar / ISM will also create the
bootstrap (ISM catalog backup) automatically. If you define a printer to
ISM via the PRINTER environment variable, it will print a report after
the backup of the SSIDs written to which volume. I'm not sure if there
is a limitation to the number SSIDs stored on any one volume - which
could be a factor in your case, if you back up to file system, write to
tape, then delete the save sets so you can continue reusing the same
file system / volume.

HTH
mjv