From owner-networker@LISTSERV.TEMPLE.EDU Sun Sep 10 16:36:46 2000 Return-Path: Received: from listserv.temple.edu (listserv.temple.edu [155.247.166.105]) by mailhost.nmt.edu (8.10.2/8.10.2) with SMTP id e8AMaZv12074 for ; Sun, 10 Sep 2000 16:36:39 -0600 Received: (qmail 25264 invoked by uid 0); 10 Sep 2000 22:35:29 -0000 Received: from listserv.temple.edu (155.247.166.105) by listserv.temple.edu with SMTP; 10 Sep 2000 22:35:29 -0000 Received: from LISTSERV.TEMPLE.EDU by LISTSERV.TEMPLE.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 731589 for NETWORKER@LISTSERV.TEMPLE.EDU; Sun, 10 Sep 2000 18:35:27 -0400 Delivered-To: NETWORKER@LISTSERV.TEMPLE.EDU Received: (qmail 23697 invoked by uid 0); 10 Sep 2000 22:35:23 -0000 Received: from agora.rdrop.com (0@199.2.210.241) by listserv.temple.edu with SMTP; 10 Sep 2000 22:35:23 -0000 Received: from joan.burling.com (root@ppp-d7.rdrop.com [199.2.212.40]) by agora.rdrop.com (8.8.7/8.8.7) with ESMTP id PAA00648 for ; Sun, 10 Sep 2000 15:33:11 -0700 (PDT) (envelope-from llywrch@agora.rdrop.com) Received: from joan (IDENT:geoff@joan [127.0.0.1]) by joan.burling.com (8.9.3/8.9.3) with ESMTP id LAA08490 for ; Sun, 10 Sep 2000 11:57:32 -0700 X-Sender: llywrch@joan.burling.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Sun, 10 Sep 2000 11:57:32 -0700 Reply-To: Geoff Burling Sender: Legato NetWorker discussion From: Geoff Burling Subject: [Networker] Networker FAQ -- Part 3 of 7 To: NETWORKER@LISTSERV.TEMPLE.EDU Status: RO Content-Length: 20184 Lines: 466 I've been lurking here for the last couple of months, & have noticed quite a few questions that should be answered in the FAQ. I checked with the folks who said they'd carry this chore on, & since they had no objection, & although I'm no longer responsible for it, I'm reposting the FAQ one more time. I hope this answers a few questions & save a little bandwidth. Geoff Burling =============================================================== /nsr/logs/savepnpc.log - If the pre command fails (exit status non-zero), the saves for that client will abort and not be run. It will also not start the post command process, so the post script will never run and the /nsr/tmp/TEST.tmp file will be left. You will need to remove this by hand. - If a savegroup session is manually aborted or stopped on the server, the /nsr/tmp/TEST.tmp file is left. (This is because the server allows you to restart it later.) Also, because an abort does not clear up the work list for the client,the client still thinks there are saves to be completed and the post script will not run. - If a new savegroup session is started and there is an existing /nsr/tmp/TEST.tmp file, it will skip the pre/post commands; however it will run the filesystem save sessions. About a month later, Rodney Wines & W. Curtis Preston discussed savepnpc (15 June 2000). Their discussion went as follows (Preston is quoted with greater than signs to the left of his words; Rodney is quoted as if responding to his remarks): > I thought I'd repost my summary about savepnpc. Does anyone see anything > in here that's no longer valid? (BTW, number 7 would have helped Marianne.) Your summary is the best savepnpc FAQ I've seen, and contains almost every gotcha that ever got me. I've only got a couple of minor comments. > I agree with most that the documentation on how to use savepnpc is > lacking. What follows is a summary of the 'gotchas' for this little > feature. The information below applies to both NT and UNIX clients. > 1. Specify savepncp as the backup command in the client config. > 2. Put the /nsr/res/.res file on the client, not the server. If > you're not sure where it goes, run a group backup and it will create an > example file for you. Check /nsr/res or \nsr\res. > 3. There is a limited path environment with savepnpc. Therefore, you must > use full path names for any commands. > 4. You must escape any '\' characters in the .res file by using > an extra '\' before them. (e.g. c:\dir\command.exe -> > c:\\dir\\command.exe) You DON'T need to do this in the shell script or > batch file that you may be running, just in the .res file. > 5. Savepnpc also doesn't pass arguments well to commands. (Some have > apparently done it, but it doesn't always work.) > 6. The best way around the path and arguments problems is to put all your > commands in a script and put that script's full pathname on the precmd or > postcmd line. Just referring to a script in .res gets around the problem with arguments, but doesn't help the path problem any. You still need to define any environment variables you need (including PATH) on NT, and source any login scripts on Unix (in my experience, at least). > 7. Do not use savepnpc with groups that have a space in their name. > 8. If you believe your setup is correct, and the backup command isn't > running, look for an /nsr/tmp/.tmp. I'd word this one this way: 8. If savepnpc has been running successfully for a while, then the backup starts behaving like a normal backup, look for an /nsr/tmp/.tmp. This is a lock file that is created the first time a savepnpc is run during a backup session, and is normally removed when all savesets for a system have completed. However, if a backup for a client is aborted or the client crashes, the ".../.tmp" file can be left around. The next time savepnpc runs, it will assume that the preprocessing commands have already run and will skip them, and the postprocessing commands will be skipped as well. > 9. On NT, don't use '@ECHO OFF' in the .res file. > 10. The scripts/batch files that you do create do NOT have to be in > /nsr/bin, but you do have to put their full path in the .res file. I'd also add: 11. Anything written to standard output by the preprocessing commands will appear in the savegroup completion notice. If this output is verbose, it'll be a nuisance. You might prefer to direct the output from the commands in your script to a log file for later examination. 12. You won't see the output from the postprocessing commands, because the connection to the server has already dropped when these commands are run. I'd recommend redirecting their output to a log file so you can examine the result if something failed to restart. I have seen postprocessing commands fail when they didn't have someplace to write their standard output, so I recommend always redirecting them to a log. 13. The preprocessing commands MUST return "success" (at least on Unix). If they return a failure code, each saveset backup will be skipped, and you'll get a message like "...! no output" in the completion notice for each saveset on the client. This is my experience. YMMV. Rodney > W. Curtis Preston ----------------------------------------------------------------------- 7. Networks and Firewalls. 7.1 Network tuning. Q. How much bandwidth does Networker use? A. Bruno Voigt posted (27 Dec 1999): These are the hints I got: "Joseph Ortiz" By its very nature, backup software is designed to maximize throughput in order to back up as much data in as short as time as possible. Consequently there are NO provisions to tune the amount of bandwidth a given backup product uses (at least not in Legato or Veritas land) when its backing up clients. In most cases, the backup engine (on enterprise size backup environments at least) has access to a separate segment dedicate to the backup jobs so as not to interfere with regular LAN traffic. The only thing you can do here is control the number of parallel data streams the client generates and the time the backups occur. If you want that type of bandwidth control, you need to look at REPLICATION products like Double Take from NSI Software that let you do that type of tuning and that also can be configured to work in conjunction with products like Networker. You're only other option would be looking into the possibility of a serverless backup SAN using something like the Legato Celestra product. Joseph Ortiz Wayne Chan you can reduce the client parallellism of the IP-WAN client from Networker's client setup page. While the default is 4 but you can reduce this number to fit your needs. It does not directly limit the network bandwidth but it reduces the overall client-to-server traffic/activities in turns it reduces the network traffic accordingly. Wayne Chan "Heiss, Georg (Z-EDV)" : you can try this: (ip-addresse from networker-server) access-list 10 permit 239.1.1.1 0.0.0.0 priority-list 1 protocol ip low list 10 The last hint refers to configure the ip router handling the WAN connection so that it gives the ip traffic from the backup server a lower prio than the other traffic. The above example is for a cisco 36[24]0 router, it gives the ip packets FROM the backup-server a lower priority. Thats not yet what I want because the clients are the machines sending the bulk backup-traffic and the backup-server sends only some ACKs etc?! But the above config seems to help by slowing down the backup ip sessions not to disturb the production ip traffic from the client machines during a backup session. I am still searching for a better way to specifiy a dedicated bandwith eg. 100KB/s in the cisco router for traffic coming from the networker ip ports.. Q. Do I need to install the clients individually on each Solaris machine, or can I install the executables on a single mount point that all the clients would have access to? A. Dave Martini shared (13 June 2000) this summary of responses to his original question: I have successfully done this on both Solaris and SGI hosts. I've remotely started the nsrexecd daemon on the Solaris machines via an NFS mount point. You also have to specify the path to the executables in the client setup screen in nwadmin. There is a field in there called Executable Path where you put the NFS mount point to the nsr executables i.e. save, savefs. An entry in .rhosts for the server is not necessary if the nsrexecd daemon is running correctly. All this has been done without installing the LGTOclnt on the every host. This should make upgrades a breeze. I had many responses from people saying that they've done this as well in one form or another. The main thing people pointed out was that your NFS mount point needs to be reliable and up for everything to work. I plan to mirror this partition for redundency. 7.2 Firewalls. At first glance, the documentation for allowing Networker to back up servers on the other side of a firewall appears to consist of a few pages in the Administrator's Guide (UNIX version, pp. 58-62). However, any project involving Networker with a firewall ought to start with technical bulletin 354, which details how to configure a firewall to work with Networker 5.5 on up. Q. From the client I can ping my Legato server using its translated IP address. From the server I can ping the client using its IP address and its netbios name. But when I try to start a backup from the clients "networker client" it says "no networker servers can be found". A. fg posted (28 April 2000): You also have to have forward and reverse DNS entries for the server and client that resolve accurately and symmetrically. You can use client aliases to help DNS problems but the requirement is strict. You must be successful with DNS in both directions. I always make my Admins do DNS correctly and don't depend on aliases to fix DNS problems so I don't know how far you can bend things with client aliases. The reason I do this is because when I didn't, it would work and then break, get fixed and then break... My rule is clear: pick a name for the A record and have PTR record to match it. After that you can have all the CNAME records you like. You should also be aware that Legato is a TCP application and ping is not. I'd test with telnet or ftp instead of ping. This is verified, in part, by an earlier post by Michael Cole (10 Sept 1999): Also, ports on the clients were restricted (through Networker Admin) to the same range as the firewall ports (keeping in mind that "between" does not include the boundary numbers, i.e. 7936). The things that broke this loose for us was getting the ports on the firewall bi-directional (thanks, Elmar) and restricting the ports on the clients (thanks, Jerry). Q. The manual states that the software requires at least nine designated ports to backup a server. Isn't this large number of ports a security risk? A. James G. Rohrich shared this response (3 May 2000) from the Checkpoint mailing list: 1.) I have a single backup system on the LAN but I put a much smaller backup system in my DMZ's for backing DMZ servers. Additional cost, but worth it. 2.) Spoofing IP addresses is reasonably simple. Someone could in theory, crash your Legato server through DOS attacks spoofing your DMZ servers as source. Just my 2 cents (probably worth less than that) Q. Is there is a way to backup through a firewall doing NAT (Name to Address Translation)? A. Matt Reynolds posted (17 Mar 2000): What I did for this same situation was create a fixed NAT (Network Address Translation) for my backup server. Then I pointed the client to the fixed NAT address of the backup serve. I'm using Firewall-1, so this was easy to do. You can't use a dynamic NAT address because Legato needs a fixed address to connect with. ----------------------------------------------------------------------- 8. Tape drives, backup performance. One command that every Networker administrator will come to know well is nsrjb. Read & reread the man page on this command, which both manages the jukebox & the volumes or devices within the jukebox. While the Jukebox menu within the nwadmin GUI allows access to much of the same functionality, several powerful options -- nsrjb -H & nsrjb -IE -- are not available from the Jukebox menu. This makes it a useful option to senior sysadmins who wish to restrict junior admins to a subset of nsrjb's functionality. Commands found in /etc/LGTOuscsi enable a more fine tuning of the Legato's interface to the tape peripherals than nsrjb permits. The man page describes them. (According to Stein Bjorndal, these commands exist on the NT version of the server.) In a post dated 27 Mar 2000, Joseph Sleigh offered an example of using some of these commands: If you want to check what density a tape is, you can use the msense command, e.g. /etc/LGTOuscsi/msense -a x.x.x -p 0 | /etc/LGTOuscsi/pmode where x.x.x is the scsi address for your drive from the /etc/LGTOuscsi/inquire command. The output you will get looks like Mode Header: mdl=11 mtype=0x85 dparm=0x10 bdlen=8 Block Desc[0]: dens=0x85 nblks=0 blklen=0 8.1 Tape drives. Instructions for configuring the OS settings for DLT 7000s can be found on the Quantum web site at http://www.quantum.com/app_notes/app_notes.htm. For Qualstar tape drives (including AIT drives), the URL is http://www.qualstar.com/146035.htm. I could find no useful information on the Sony web site about AIT drives, and the Exabyte web site limits its information to hardware troubleshooting. Another URL for searching for information on storage devices -- including tape drives and optical disks -- is http://directory.google.com/Top/Computers/Hardware/Storage/. [As elsewhere, better URLs for troubleshooting storage devices are welcome.] Q. Which DLT tape brand is best? A. Florinda McCarthy wrote (7 Mar 2000): Yesterday I asked people to cast their votes for their preferred DLT tape brand - Fuji, Maxell or Quantum. Here's the results - thanks to everyone who replied! All tapes are the same and come from the same factory (just different brands): 7 votes Quantum are the most reliable: 8 Fuji are equally reliable and cheapest: 6 Experienced problems with Fuji: 2 Experience problems with Quantum: 1 Maxell/Sony/Digital are the most reliable: 1 vote for each Taking account of the amount of people who felt that all tapes were equal, it seems like Fuji is the best choice in terms of price and performance. Q. How do I erase a tape? A. The trick is to use a bulk degausser, otherwise known as an industrial strength magnet. Ulrich Oldendorf offered (19 May 2000) these guidelines for selecting a bulk degausser: I found the following by chance at www.dlttape.com: What is the industry standard for degaussing DLT tapes? Media is rated in coercivity, as stated below. Compact III is rated at around 1540 Oersteds (1600 Oe). Compact IV is rated at around 1850 Oersteds (2000 Oe). The rule of thumb with degausses is 2 to 3 times the coercivity of the media. For instance,in our startup manufacturing area we use a degausser that has a rating of around 4000 Oersteds. Tape goes into the degausser 1 pass and then turn it 90 degrees and pass it through again. The manufacturers of degaussers don't specify the exact Oersteds rating of their machines. Rather, they say if you have media with a specific Oersteds rating, then use a specific machine. Erasure depth is measured in DB's, but if you use the rule of thumb above, and use what a manufacturer recommends, you should be safe. Depth of erasure may be called out in the manufacturers spec but they have already figured out which machine to use for you. We do not have a standard degausser that we use. However, the ones we use are: Weircliffe Bulk Eraser Model No. BTE 1910L Weircliffe International LTD. Exeter, England http://www.weircliffe.co.uk/ Garner Eliminator 4000 Model No. 4000 Garner Industries Lincoln Nebraska http://www.garnerindustries.com/ 8.2 Tuning backups. Q. My backup/restore runs slowly. Where do I start troubleshooting? A. Eric C. Schwartz wrote (17 Sept 1999): Slow backups, below are some things to look at and consider: What's the speed of network link between the client and Networker server? faster is better when you're doing Networker backups, are network is currently at 100mb How many hops between the client and the Networker server? Too many hops slows down the data transfers. Is the data going through routers? Are the routers overloaded? Not good if they are. How "clean" is your network data path? To many errors will slow down the data transfer rates. Not sure, maybe do some large file transfers between the client and server and see what kind of throughput you get. analyze the results. What's CPU processor/memory utilization and processor queue length of the client and Networker server system when backups are running? If either or both are overloaded the amount of data being sent to the tape drive is reduced What type of DLT drives are you using. native speeds are for the DLT7000 5mbs, DLT8000 6mbs and DLT4000 1.5 mbs if your data's compressible, you'll see higher transfer rates. What's the client data like, is a fragmented? probably not, but you could check... Albert Moser added in response to the same question: Getting backup throughput of 200 - 300 Kb/s on a 100 Mb LAN typically means you have a network problem. When I see these slow numbers on a Networker client, I check the NIC settings on the client and the settings of the switch port of this particular client. If they don't match, you will get lots of collisions and therefore terrible network throughput. Additionally I make sure NOT to autonegotiate between the NIC and switch. I prefer fixed settings for best network performance. I've also seen switches that do not work very well with Full duplex, even they should. Half Duplex on these switches gave me better through put. When this question was asked again, Marc G. Fournier (23 Mar 2000) wrote: Way back, some of you might recall that I too got a DLT7000 and had atrocious backup speeds compared to what I was hoping to get with it. The problem, in retrospect, was very stupid: I was using the wrong device At least under Solaris, each /dev/rmt/* device has a different meaning, and one of them deals with how compression is handled. On my machine, I needed to use /dev/rmt/0ubn in order for the OS to send the proper codes to the DLT7000 to do its "high capacity/compression" mode ... -- Note: To sign off this list, send a "signoff" command via email to listserv@listserv.temple.edu or visit the list's Web site at http://listserv.temple.edu/archives/networker.html where you can also view and post messages to the list. =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=