Thread View: comp.sys.ibm.pc.rt
2 messages
2 total messages
Started by silver
Tue, 12 Sep 1989 19:55
6157 tape problems
Author: silver
Date: Tue, 12 Sep 1989 19:55
Date: Tue, 12 Sep 1989 19:55
37 lines
1691 bytes
1691 bytes
I am having a lot of trouble backing up my 6150. I have a 6157-002 streaming tape drive, but to backup just the 250Meg used so far takes 2 tapes and 3 hours. In addition, some one must be here to change the tape at the mid-way point. Because of this, I only to a whole dump once a month. I will later have 800-900 Meg of disk to backup, and 6-7 tapes and 9-11 hours of down time in unthinkable. 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). Are there any other (better/faster/more efficient) ways to backup the entire system? I have AIX 2.2.1 and some $$ to spend if the tape drive should be changed. The fulldump code looks something like: tctl -f /dev/rmt0 reset tctl -f /dev/rmt0 rewind backup -0qvuf /dev/rmt4 / backup -0qvuf /dev/rmt4 /dev/rhd1 backup -0qvuf /dev/rmt4 /dev/rhd2 backup -0qvuf /dev/rmt4 /dev/rhd3 etc.... Any suggestions are welcome. Edward A. Silverstein Beckman Institute for Advanced Science and Technology University of Illinois at Urbana-Champaign 405 North Mathews Avenue Urbana, Illinois 61801 CSNET, ARPA, BITNET: silver@cs.uiuc.edu
Re: 6157 tape problems
Author: Herb Peyerl
Date: Mon, 18 Sep 1989 03:18
Date: Mon, 18 Sep 1989 03:18
40 lines
2162 bytes
2162 bytes
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!" <Steven Wright>
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads