Been busy of late, sorry to drop into this mid-thread. In my experience, dmz machines need their own tape drives, one for every host. It's just a place where one can't afford to skimp. While the cost may become high in instances of massive www server-farms, I think the benefits outweigh the cost. Consider that these machines are in your DMZ and so on the drontline of any attack you may experience. Just as one would make a backup of these machines in a known good state (and this is one reason the host should have it's own tape drive/dvdrom/MO disk/cd-writer), before putting them online in production, so too should there be a minimized risk associated with each separate host. Even if they are load-balanced mirrors, each should have it's own internal backup. Consider the scenario where you have 10 hosts in a dmz all connected to a backup server on their subnet. If one of those hosts is compromised, the likelihood of the backup server and the other 9 hosts being compromised increases significantly. The added admin overhead of authentication and monitoring is considerably higher with a networked backup server. It's a case of doing things completely differently than SOP for internal network stuff. It is far simpler to have each host in a dmz with it's own backup system. spiff On Tue, 11 Jan 2000, James R Grinter wrote: > On Mon 10 Jan, 2000, "Ginsberg Rainer (QI/INF4) *" <Rainer.Ginsbergat_private> wrote: > >ADSM uses a TCP connection. The port is configurable, default > >is 1500. TCP connections will be established from both sides. > >First, the server tells the client to do the backup, then the > >client opens another connection and sends all its data. > > Here's my understanding of the current situation with ADSM (TSM). > > As things stand you can't limit where an Admin user can log in from, > the admin client makes a connection to the same port 1500. > > Can someone get an admin client program/binary easily? Yes. > Can someone connect from your system as an Admin? Yes, if they know/can > deduce a user and password > Can someone sit there guessing passwords for an Admin user? If you've > not set an invalid signon limit. > Can an admin user wreak havoc upon your backups? Yes, if they get one > with sufficient privileges. > > You can stop an ADSM client (node) from being able to delete backup > data, though. You've just got to hope that someone doesn't back up > enough sets of data to blow a whole in your data retention policies > (eg. Ten previous sets of files - make 10 backups of corrupted > datafiles) before you notice and get back your off-sites: oh, you'd > probably need to restore the database to match them too because it > would have dropped all the previous backups. I don't think there's > a way around that - talk with your site ADSM expert or try asking > the ADSM-users list. > > (I expect there are similar issues with other backup products.) > > I can think of a few approaches to tackling the above issues. Maybe a > second dedicated server which transfers its data, after the backup > window, directly to another server? Or export filesystems inwards > to a seperate partitioned network and backup from another node. > > James. >
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:57:19 PDT