sahayman@iuvax.cs.indiana.edu (Steve Hayman) (10/02/89)
We do all of our nightly dumps to an Exabyte tape drive on a Sun and use a variety of formats in the process - dump, tar, cpio and wbak. I wanted to find out some details of the wbak format so that I could run some simple tools on the Sun to give me a table of contents of the tape. So I called Apollo, and their response is that "the rbak/wbak format is unpublished and we don't want to give it out." Thanks a lot. If anyone important at Apollo happens to read this, I hope this policy can be changed. I hate doing something as important as backups without being sure of what I'm writing to the tape. I don't want all the source to wbak, I just want something like "man 5 tar" to tell me about the wbak format. Mind you I suspect that "man 5 tar" doesn't tell you the true story of Apollo's tar format, since it doesn't mention anything about whatever extensions they've added to support Apollo specific information. (see "man 1 tar", description of the "A" option) When can we get HP-UX for these things ? :-) Steve -- Steve Hayman Workstation Manager Computer Science Department Indiana U. sahayman@iuvax.cs.indiana.edu (812) 855-6984
brian@apollo.HP.COM (Brian Holt) (10/03/89)
In article <26979@iuvax.cs.indiana.edu> sahayman@iuvax.cs.indiana.edu (Steve Hayman) writes: > >"the rbak/wbak format is unpublished and we don't want to give it out." I'm afraid I don't know anything about the rbak/wbak format, but if I did I'd send it to you. >Mind you I suspect that "man 5 tar" doesn't >tell you the true story of Apollo's tar format, since it doesn't >mention anything about whatever extensions they've added to support >Apollo specific information. (see "man 1 tar", description of the "A" option) Actually, we specifically did use the standard tar format, so that you can read even -A files on any machine. The solution (how to include more data without changing the tape format) is a bit of a hack, but it works. If you write a tape with the -A format, then tar creates two entries on the tape for every file. One is just the normal tar entry, the second is a dummy file (I think it is /tmp/somethingorother) that contains the extended information. When read by a normal version of tar, this short file will get created multiple times and the tape will restore correctly. When read by tar on DomainOS, tar will notice the shadow file and set the DomainOS attributes according to its contents. I have to confess this hack was my idea, but it was the only solution that allowed us to mantain complete compatibility with everyone's 'tar' and still add extra information. =brian P.S. I haven't worked in that group for a couple years, so that's all I know. -- Internet: brian@apollo.hp.com UUCP: {decvax,mit-eddie,umix}!apollo!brian
conliffe@caen.engin.umich.edu (Darryl C. Conliffe) (10/05/89)
In article <26979@iuvax.cs.indiana.edu>, sahayman@iuvax.cs.indiana.edu (Steve Hayman) writes: > > We do all of our nightly dumps to an Exabyte tape drive on a Sun and > use a variety of formats in the process - dump, tar, cpio and wbak. > I wanted to find out some details of the wbak format so that I could > run some simple tools on the Sun to give me a table of contents > of the tape. So I called Apollo, and their response is that > "the rbak/wbak format is unpublished and we don't want to give it out." > Is knowledge of the internal format necessary? Why not index the tape for a TOC? How do you gen the tape in the first place? -- ___________________ Darryl C. Conliffe conliffe@caen.engin.umich.edu (313) 721-6069 -------------------
conliffe@caen.engin.umich.edu (Darryl C. Conliffe) (10/05/89)
In article <27200@iuvax.cs.indiana.edu>, sahayman@iuvax.cs.indiana.edu (Steve Hayman) writes: > >Is knowledge of the internal format necessary? Why > >not index the tape for a TOC? How do you gen > >the tape in the first place? > > Our Exabyte tape drive is attached to a Sun. > Right now I'm doing > > wbak -stdout ... | rsh sun-with-exabyte-drive dd of=/the/tape > > You can't do > > wbak -l -stdout ... | rsh sun ... > > because the list-of-files-saved is written to stdout, > and vanishes down the pipe getting mixed in with the wbak stuff. > Try this approach: wbak <target> -to <wbak.result> -l > <wbak.result.index> Then copy the <wbak.result> to be tar'ed, and you also have the artifact of the index in <wbak.result.index>
sahayman@iuvax.cs.indiana.edu (Steve Hayman) (10/05/89)
>Is knowledge of the internal format necessary? Why >not index the tape for a TOC? How do you gen >the tape in the first place? Our Exabyte tape drive is attached to a Sun. Right now I'm doing wbak -stdout ... | rsh sun-with-exabyte-drive dd of=/the/tape You can't do wbak -l -stdout ... | rsh sun ... because the list-of-files-saved is written to stdout, and vanishes down the pipe getting mixed in with the wbak stuff. Also I don't want to create the tape over the network and then do rsh sun dd if=/the/tape | rbak -stdin -index even though it would produce the index I want, because I don't want to send all the backed-up data over the network twice (once from Apollo to Sun to write the tape, once from Sun to Apollo to read it again and make the index.) This process is slow enough as it is ... I want to run a program on the sun that will read the tape and produce a TOC. Basically I want to do the equivalent of "rbak -stdin -index" on the Sun itself. Is there some obvious way to do this that I'm missing? Anyway, I don't see why the rbak format should be a big secret. Steve P.S. Thank you to Brian Holt for describing how "tar -A" works.
sahayman@iuvax.cs.indiana.edu (Steve Hayman) (10/06/89)
>Try this approach: >wbak <target> -to <wbak.result> -l > <wbak.result.index> > >Then copy the <wbak.result> to be tar'ed, and you also >have the artifact of the index in <wbak.result.index> Hmmm ... That'd work, except that we usually don't have enough disk space to do our backups to disk and then copy them to tape. Thanks anyway. I think I'm going to switch to tar. wbak is just too inconvenient in a mixed-OS environment. Steve
abair@turbinia.oakhill.uucp (Alan Bair) (10/07/89)
I have been following this discussion and seem to remember that one of the problems had to do with the index and wbak data being mixed on the stdout. Well I just finished some monthly backups from our Apollos to Sun 8mm tape. Remebering this problem I checked the tapes and they are fine. Now I need to qualify what I did. The latest version of SR10 states in the release notes that you can use the '-remote node:device' option to write to a remote tape device. Well on our DN4000, SR10.1.1.2, it accepts this option, but fails the login. I gave up after several ideas, need to call Apollo. Our DN10000, SR10.1, does not even recognize this option. So I used a PD rmt package to write two cat-like routines to go from stdin -> remote tape and remote tape -> stdout. So on the 10000 I made the monthly backups as follows. 1. In a script I do a little book keeping and then invoke wbak: wbak //node_id -ld -pdtu -nhi -full -stdout | rmtwrt sun:/dev/rst0 2. The script is run manualy :( as follows: backup-script |& tee month-log From this setup, I get the wbak data written on the Sun 8mm drive and the wbak index in the month-log file. To check that this worked, I reversed the process like so: rmtrd sun:/dev/rst0 | rbak -index -all -stdin Which gave me a nice index as would be expected. Now the catch! When I try this from the DN4000, it fails badly. The tape seems to end up with either the index or bad data, which may be what the previous complaint was about. Apparently the wbak option -stdout does not work, again I need to call Apollo. To confirm this, I just tried running wbak -stdout with no piping, which I would expect to dump bits all over my lap, but it just said it was dumping the files. I have no idea where the binary data was going. On the 10000 this did what I expected, bits in my lap. Now you may start wondering why the tape is not messed up, so was I. However, I think what happens is that wbak writes its messages to stderr and the data to stdout if the -stdout option is used. If anyone from Apollo would like to help enlighten us further, please do so. I'll probably give them a call next week anyway. Alan Bair SPS CAD Motorola, Inc. UUCP cs.utexas.edu!oakhill!turbinia!abair