I would rather disagree.
1. Zero on-site skills: from our experience even a clerical end-user can
sign a Fed-Ex delivery, unplug power and LAN cords from failed system, and
plug them back in the replacement server.
2. Limited on-site skills: Most often available - people with limited
knowledge of Windows, some have done hard-disk replacement (or can easily
be taught how to replace hot-swap disk). With unified hardware you can
send only pre-built disk instead of whole server.

The advanced part can be handed successfully to central site:
- with very inexpesive disks a local diskpool to hold all backups is not a
problem, copypool over WAN;
- enterprise-wide management products are common in big enterprises;
- TSM itself has very good enterprise management features (and I prefer
CLI which is WAN-friendly vs. WebAdmin)
- many of the restores are not BMR ones but for single file/directory;
- restores still can be performed through Web client using browser at
central site;
- TSM server can be rebuilt at central site and sent to satelite site for
replacement;
- BMR restore also can be performed at the central site and
workstation/disk be sent to satelite site.

Thus if I am the IT manager, instead of hiring or outsourcing people for
tens of remote sites, I can manage this with existing staff at central
site or no more than one-two persons in addition to TSM admin.
For me TSM scales down to 0 tape drives. Of course, if total occupied
space on the remote site machines is going to become beyond 100 GB, an
autoloader or library is a must. But for office workstations using TSM
prograssive backup, sub-file backups and having MP3/AVI/DivX/etc.
excluded, the tape-less server is fine. Such offices usually do not
utilize the WAN during the night.

Zlatko Krastev
IT Consultant






Richard Sims <rbs AT BU DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
21.10.2003 18:50
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: TSM Downward Scaleability


>The organization that I work for deploys TSM quite
>sucessfully at its large main sites that serve some
>+4000 nodes. It is very apparent that TSM scales
>upwardly very well but I believe that scaling down is
>something else. MY question is this:How can similar
>services be delivered to sites where there are less
>than ten nodes, limited bandwidth, no system
>administrators and, most importantly, tiny budgets.

It's not realistic to have server systems of any kind at a site where
there is
no technical administration: someone has to be knowledgeable about the
systems
in order to minimally inspect them visually when there is a problem.
Clerical
people simply can't serve in that capacity.  Remote administration is a
feasible
concept, but when hardware stops working, knowledgable eyes and
experienced
hands must be at the site.  Such a responsibility might be contracted to
an
outside company, which can feasibly attend to disparate physical sites.
Consider also that while unattended backup, by various means by products
of
different scales, is not difficult, the backups are done because of the
prospect
of the need for a restoral, which can involve a full-down computer, and
that is
beyond the capabilities of clerical people to address: someone has to know
what
to do, particularly where a collection of office computers will seldom be
uniform.

TSM is an enterprise product, intended for larger installations, which is
to say
those where there are concentrated server facilities and network access.
As
Wanda suggests, backup by remote offices over a WAN is the method of
choice
where TSM or like backup/restore product are involved.  Again, the backup
is
easy, but restoral can be problematic.  Advanced planning is necessary to
cover
all aspects of backup/restoral needs, which in turn is just a part of a
company's larger disaster recovery plan.

   Richard Sims, BU