MATLEVAN@EKU.BITNET (Jerry LeVan) (10/05/90)
Good Evening Netters, Still can't get tar to create a multitape backup of a filesystem, tcb always croaks on the first write. Is the following possible? use dump.bsd to /dev/rmt/tc to copy a sysv file system. reformat the disk to a ufs. use restore to recover the files from the tape (without remaking the partition back into a sysv filesystem. Is tcb usable/needed/recommended for use with dump.bsd? Jerry ----------------------------------------------------------------------------- | Jerry LeVan | Phone:(606)-622-1931 | | Department of Computer Science | | | Eastern Kentucky University | Email:matlevan@eku.bitnet | | Richmond Ky 40475 | | |---------------------------------------------------------------------------| | "The series converges so slowly that it actually diverges." | -----------------------------------------------------------------------------
rmtodd@uokmax.ecn.uoknor.edu (Richard Michael Todd) (10/05/90)
MATLEVAN@EKU.BITNET (Jerry LeVan) writes: >Is the following possible? > use dump.bsd to /dev/rmt/tc to copy a sysv file system. > reformat the disk to a ufs. > use restore to recover the files from the tape (without > remaking the partition back into a sysv filesystem. Well, modulo the difference that I did it with /dev/rmt/teac4n (using Tony Cooper's beta TEAC tape driver and a TEAC 150M tape drive), that's exactly what I did when upgrading my /u filesystem to UFS. No problems. You do have to make sure that you've told dump.bsd correctly about the expected length of the tape, as it apparently determines when it needs a new tape by counting how much it has written, not by detecting the end of the tape. (I believe dump.bsd has an option for spec'ing the tape length correctly for the Apple tape drive. Yes, it does, option 'c'). >Is tcb usable/needed/recommended for use with dump.bsd? I don't think so. The dump.bsd man page says that the 'c' option tells it to do writes only in 8K chunks, which seems to be the main function of tcb... -- Richard Todd rmtodd@chinet.chi.il.us or rmtodd@uokmax.ecn.uoknor.edu "Never re-invent the wheel unnecessarily; yours may have corners."-henry@utzoo
jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) (10/05/90)
In article <1990Oct5.035047.32209@uokmax.ecn.uoknor.edu> rmtodd@uokmax.ecn.uoknor.edu (Richard Michael Todd) writes: >MATLEVAN@EKU.BITNET (Jerry LeVan) writes: >>Is the following possible? >> use dump.bsd to /dev/rmt/tc to copy a sysv file system. >> reformat the disk to a ufs. >> use restore to recover the files from the tape (without >> remaking the partition back into a sysv filesystem. > > Well, modulo the difference that I did it with /dev/rmt/teac4n (using Tony >Cooper's beta TEAC tape driver and a TEAC 150M tape drive), that's exactly >what I did when upgrading my /u filesystem to UFS. No problems. > As I recall, dump.bsd and restore (when used in the "full" mode) also copy the SuperBlock information, so if a restore -r (or whatever the flag is, I don't use dump/restore) is done, SuperBlock info is also restored. One of the upshots of this is that your new filesystem must be the same size as the old one. One can use cpio instead (assuming all will fit on 1 tape): $ cd /usr2 $ find . -print | cpio -ov | tcb > /dev/rmt/tc1 $ [now do newfs stuff to create BSD file system] $ [dp and pname too if required ] $ [and mount it of course where it was before: assume /usr2] $ cd /usr2 $ tcb < /dev/rmt/tc1 | cpio -idmuv (the above should be run as root to maintain old permissions) -- ======================================================================= #include <std/disclaimer.h> =:^) Jim Jagielski NASA/GSFC, Code 711.1 jim@jagmac2.gsfc.nasa.gov Greenbelt, MD 20771 "Kilimanjaro is a pretty tricky climb. Most of it's up, until you reach the very, very top, and then it tends to slope away rather sharply."
rmtodd@servalan.uucp (Richard Todd) (10/06/90)
jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) writes: >As I recall, dump.bsd and restore (when used in the "full" mode) also copy >the SuperBlock information, so if a restore -r (or whatever the flag is, I >don't use dump/restore) is done, SuperBlock info is also restored. One of the >upshots of this is that your new filesystem must be the same size as the old >one. Nope, I'm sorry, you didn't Beat the Reaper. Restore is smart enough to automatically handle restoring onto filesystems with different numbers of inodes or disk blocks, as long as there are enough inodes/blocks to hold all the files and data that were dumped originally. You can restore onto a filesystem larger or smaller than the original, as long as you have enough room to do it. BSD-style dump and restore have historically been the recommended way to save/restore one's data when enlarging or shrinking a filesystem. I've done it twice to enlarge my /u partition at the expense of the MacOS partition on my external drive, and at uokmax.ecn.uoknor.edu, the Univ. of Oklahoma's Encore Multimax, when they need to shift some disk space from one filesystem to another (which they typically do once a year or so, whenever some FSes are real full and others are real empty or whenever they get a new disk drive), they do full dump/restores to change filesystem sizes. >One can use cpio instead (assuming all will fit on 1 tape): Well, aside from the fact that cpio doesn't save the access time, nor does it correctly handle "holey" files such as are created by dbm, the original poster was complaining that his filesystem *wouldn't* fit on one tape... -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp
jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) (10/09/90)
In article <1990Oct5.212803.11873@servalan.uucp> rmtodd@servalan.uucp (Richard Todd) writes: >jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) writes: > >>As I recall, dump.bsd and restore (when used in the "full" mode) also copy >>the SuperBlock information, so if a restore -r (or whatever the flag is, I >>don't use dump/restore) is done, SuperBlock info is also restored. One of the >>upshots of this is that your new filesystem must be the same size as the old >>one. > > Nope, I'm sorry, you didn't Beat the Reaper. > > Restore is smart enough to automatically handle restoring onto >filesystems with different numbers of inodes or disk blocks I seem to recall somewhere in the documentation for 1.1, that one of the considerations when using dump and restore was that the restored backup had to be the same size file system that was originally dumped. In other words, if your file system was orginally 40 megs and you wanted to "increase" it to 80 megs, the documentation suggested NOT using dump/restore since the file system sizes were different and it would not work. (they also mentioned in there information about the SB being copied also) Now I don't know if this is true or not, but it WAS in the 1.1 documentation set... I recall this because around that time I had upgraded from an 80 MB disk to a 170 one and wanted to: 1) increase the root FS size from 55MB (which was about the size of 1.1) to 70MB as well as 2) make /usr it's own FS. Now maybe the documentation was wrong, or maybe dump/restore was changed/fixed to circumvent this (heck, I remember the days of nightly "dd" backups!) under 2.0. I simply felt the need to relay what I read, even if it IS/WAS wrong :) -- ======================================================================= #include <std/disclaimer.h> =:^) Jim Jagielski NASA/GSFC, Code 711.1 jim@jagmac2.gsfc.nasa.gov Greenbelt, MD 20771 "Kilimanjaro is a pretty tricky climb. Most of it's up, until you reach the very, very top, and then it tends to slope away rather sharply."
rmtodd@servalan.uucp (Richard Todd) (10/10/90)
jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) writes: >I seem to recall somewhere in the documentation for 1.1, that one of the >considerations when using dump and restore was that the restored backup >had to be the same size file system that was originally dumped. In other >words, if your file system was orginally 40 megs and you wanted to "increase" >it to 80 megs, the documentation suggested NOT using dump/restore since the >file system sizes were different and it would not work. (they also mentioned >in there information about the SB being copied also) Well, the documentation was wrong, then. I don't have an A/UX 1.1 manual set, but I do have a set of A/UX 1.0 manuals. (The 1.0 manuals did document dump/restore, even though those programs apparently weren't finished in time for the 1.0 release!) Anyway, the 1.0 man page for restore says: "A dumpfs(1M) followed by a mkfs and a restore is used to change the size of a file system." For some reason, this helpful statement isn't in the online A/UX 2.0 manuals. It obviously should be. Sigh. >Now maybe the documentation was wrong, or maybe dump/restore was changed/fixed >to circumvent this (heck, I remember the days of nightly "dd" backups!) under >2.0. I simply felt the need to relay what I read, even if it IS/WAS wrong :) Quite understandable--it isn't your fault your manual lied to you... My understanding is that dump/restore have worked this way ever since, at the least, some early BSD release. The deal is that while dump has to and does grovel through the raw disk, restore doesn't do so--all the restoring of files is done through normal file I/O calls. Thus restore doesn't control the specific allocation of a file to a specific inode or block number, so restore doesn't really care if the filesystem it's restoring onto has different parameters than the one originally dumped. (I recall hearing that V7 restor (note the spelling) *did* write to the raw fs, but I don't know for sure; in any case, I don't think any version of BSD restore did.) -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp "Cancelling a posted message means posting a cancel message."-Maarten Litmaath
jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) (10/10/90)
In article <1990Oct10.044533.26811@servalan.uucp> rmtodd@servalan.uucp (Richard Todd) writes: >jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) writes: > >> *my comments about dump in 1.1 manuals > > Well, the documentation was wrong, then. I don't have an A/UX 1.1 >manual set, but I do have a set of A/UX 1.0 manuals. (The 1.0 manuals >did document dump/restore, even though those programs apparently >weren't finished in time for the 1.0 release!) Anyway, the 1.0 man >page for restore says: > "A dumpfs(1M) followed by a mkfs and a restore is used to change the size >of a file system." Also, as I recall, the 1.1 manual set didn't include a page (either hardcopy or printed) for dumb.bsd. I think that the documentation refered to dumpfs, so a name change happened somewhere along the line. The file system size/dump/restore comment was made in some obscure place in the manual set, most probably in the Local Sys. Admin Guide... I wish I had kept my 1.1 manual, but I barely have space enuff for my 2.0 manuals :) -- ======================================================================= #include <std/disclaimer.h> =:^) Jim Jagielski NASA/GSFC, Code 711.1 jim@jagmac2.gsfc.nasa.gov Greenbelt, MD 20771 "Kilimanjaro is a pretty tricky climb. Most of it's up, until you reach the very, very top, and then it tends to slope away rather sharply."