map@cscosl.ncsu.edu (Mark Parris) (02/20/90)
Hardware & Software: Ultrix 3.0 MicroVaxII Background: We currently do remote dumps across the network using the rdump command to backup our system. This works fine, but it seems to be wasting a lot of tape. We're using 6250cpi tapes and dumping one filesystem/tape. There's usually about 75% of the tape left unused after each dump. MY QUESTION: Is there anyway to get dump to dump multiple filesystems to a single tape? Of course we would want standard recovery to work. I've heard some kind rumor of an undocumented switch on dump that allows one to do this but that's all of the info I have. Please e-mail. I will summarize. ***************************************************************************** --Explanations, suggestions, clarifying comments, and constructive criticism welcome and encouraged. /------------------------------------------- --Flames ignored. |-----------/ Mark Parris map@cscosl.ncsu.edu
map@cscosl.ncsu.edu (Mark Parris) (02/21/90)
First of all, thanks to all of those who replied to my question. It's nice to be able to post a question and receive 9 (so far) answers which are in agreement, try them, and be able to summarize within 24 hours. Thanks. For the summary: The key to dumping multiple filesystems to a single tape is to use the no rewind tape device instead of the rewind one. In my case, this meant using /dev/nrmt8 instead of /dev/rmt8. That's the only thing that had to be changed regarding dumping. I was able to dump 3 filesystems and restore from each using this method. To restore dumps of this type, use the s switch on restore (or rrestore as in my case.) This option allows you to specify which dump image to restore from. If I had dumped /usr, /usr/var, and /local to the tape in that order and I wanted to restore from local I would use s with an argument of 3 to specify the image of /local. The main thing to look out for is a filesystem that spans multiple tapes. Such filesystems should have tapes for themselves, or at least that seemed to be the consensus. I have no filesystems big enough to try it out. Be sure you have enough room left on the tape for the next filesystem. (The S option on dump is handy for this.) Someone mentioned using mt rewind to rewind the tape after all of the dumps were made. I was unable to test this because there seemed to be no equivalent for remote dumps. I simply rewound using the tape drive rewind button. Thanks to all who replied. ***************************************************************************** --Explanations, suggestions, clarifying comments, and constructive criticism welcome and encouraged. /------------------------------------------- --Flames ignored. |-----------/ Mark Parris map@cscosl.ncsu.edu
davew@gvgpsa.GVG.TEK.COM (David C. White) (02/22/90)
In article <1990Feb21.051622.10343@ncsuvx.ncsu.edu> map@cscosl.ncsu.edu (Mark Parris) writes: [deleted text about using the nrmt device] >Someone mentioned using mt rewind to rewind the tape after all of the >dumps were made. I was unable to test this because there seemed to be no >equivalent for remote dumps. I simply rewound using the tape drive rewind >button. There is an easy workaround for this one. For your last dump use the rewind device and the tape will rewind automatically when the dump is complete. -- Dave White Grass Valley Group, Inc. VOICE: +1 916.478.3052 P.O. Box 1114 Grass Valley, CA 95945 FAX: +1 916.478.3887 Internet: davew@gvgpsa.gvg.tek.com UUCP: ...!tektronix!gvgpsa!davew
khaw@parcplace.com (Mike Khaw) (02/24/90)
davew@gvgpsa.GVG.TEK.COM (David C. White) writes: +In article <1990Feb21.051622.10343@ncsuvx.ncsu.edu> map@cscosl.ncsu.edu (Mark Parris) writes: + +[deleted text about using the nrmt device] + +>Someone mentioned using mt rewind to rewind the tape after all of the +>dumps were made. I was unable to test this because there seemed to be no +>equivalent for remote dumps. I simply rewound using the tape drive rewind +>button. +There is an easy workaround for this one. For your last dump use +the rewind device and the tape will rewind automatically when +the dump is complete. If dump behaves like tar, then this will cause the tape to rewind to BOT *before* dumping the last filesystem, thus destroying your earlier dump(s). -- Mike Khaw ParcPlace Systems, Inc., 1550 Plymouth St., Mountain View, CA 94043 Domain=khaw@parcplace.com, UUCP=...!{uunet,sun,decwrl}!parcplace!khaw
wyatt@cfa.HARVARD.EDU (Bill Wyatt) (02/26/90)
|> There is an easy workaround for this one. For your last dump use |> the rewind device and the tape will rewind automatically when |> the dump is complete. > If dump behaves like tar, then this will cause the tape to rewind to > BOT *before* dumping the last filesystem, thus destroying your earlier > dump(s). WHAT??? If your tar does this, it's broken, broken, BROKEN! Bill Wyatt, Smithsonian Astrophysical Observatory (Cambridge, MA, USA) UUCP : {husc6,cmcl2,mit-eddie}!harvard!cfa!wyatt Internet: wyatt@cfa.harvard.edu SPAN: cfa::wyatt BITNET: wyatt@cfa
davew@gvgpsa.GVG.TEK.COM (David C. White) (02/27/90)
In article <671@parcplace.com> khaw@parcplace.com (Mike Khaw) writes: >+In article <1990Feb21.051622.10343@ncsuvx.ncsu.edu> map@cscosl.ncsu.edu (Mark Parris) writes: >+There is an easy workaround for this one. For your last dump use >+the rewind device and the tape will rewind automatically when >+the dump is complete. > >If dump behaves like tar, then this will cause the tape to rewind to >BOT *before* dumping the last filesystem, thus destroying your earlier >dump(s). Haven't really tried it with tar, but it works as it should with dump. The tape should not rewind until after the current operation. You want to the the norewind device for all but the last dump. From mtio(4): The special files ``rmt0l, ..., rmt31l'' are low density, ``rmt0m, ..., rmt31m'' are medium density (when a drive is ``triple density''), and ``rmt0h, ..., rmt31h'' are high density. All these special files cause a loaded and on-line tape to automatically rewind to the beginning-of-tape (BOT) when closed. ^^^^^^^^^^^ -- Dave White Grass Valley Group, Inc. VOICE: +1 916.478.3052 P.O. Box 1114 Grass Valley, CA 95945 FAX: +1 916.478.3887 Internet: davew@gvgpsa.gvg.tek.com UUCP: ...!tektronix!gvgpsa!davew