Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!aplcen!haven!rutgers!mit-eddie!uw-beaver!ubc-cs!alberta!calgary!xenlink!blender!root From: root@blender.UUCP (Herb Peyerl) Newsgroups: comp.sys.ibm.pc.rt Subject: Re: 6157 tape problems Summary: Same problem. Message-ID: <98@blender.UUCP> Date: 18 Sep 89 03:18:23 GMT References: <213600003@s.cs.uiuc.edu> Organization: Some apartment in downtown Calgary Lines: 40 In article <213600003@s.cs.uiuc.edu>, silver@s.cs.uiuc.edu writes: > > Lately there have been write errors on the drive, and the backup aborts. > Other times the backup stops and just asks to reinsert the same volume > (tape). The backup continues, but gives no clue why (the tape is then > <50% full). I've come across this problem at my old job and left before it was solved. From what I've been told by my replacement, the solution was to get an update to 2.2.1. What would happen was, after having backed up ~50 Mb, 'backup' would come back and say "Backup MEDIUM I/O Error". Once the updates were applied this problem went away. Also, backups were REAL slow for us until we found that by increasing the buffer-size which defaults to 20 blocks to 2000 blocks, it drastically decreased the time involved for backups. ie: The command we used: li -Ra pathname | backup -i -v -r -f /dev/rmt0 -s10000 -d1000 -C2000 -s10000 : 18 tracks * 600 feet yields 10800 feet of tape. I just chopped off 800 for safety. -d1000 : apparently dc600xtd (or the newer dc6150) tapes are rated for 1200bpi. To be safe I used 1000. -C2000 : This is what actually speeds up the backup. Default without the switch is 20. That causes a fair bit of tape movement. ie: slowdown. Just two weeks ago, I timed a backup of 65 meg on a system with 6 active users, and it took 22 minutes. So for 250Meg you'll probably be looking at an hour and a bit. Still pretty good. -- UUCP: herb@blender.UUCP || ...calgary!xenlink!blender!{herb||root} ICBM: 51 03 N / 114 05 W "The other day, I...... No wait... That wasn't me!"