dbfunk@ICAEN.UIOWA.EDU (David B Funk) (09/08/89)
WRT posting from achille%cernvax%mcvax.uucp@uunet.uu.net (achille petrilli) > On a, more or less, related argument, I'd like to know if somebody has tested/used > the new backup facility from Apollo, NBS Omniback. I'm interested in hearing any > quirks/problems you had and about its performance. Here's my first pass opinion of Omniback: Its fast, its neat, but its a little rough around the edges. Specifics: OS: sr10.1, Omniback v1.0, Exabyte attached to DN3500 SCSI port. Up side: The concept seems sound. The "work list" and scheduler are usefull powerfull tools. The dialog interface provides usefull progress information. It is fast, doing a "-conc 3" from a bunch of DN3500s with 348 Meg disks, I saw about a 100Kbyte/sec backup rate. Down side: It doesn't have some of the nice features that Workstation Solutions "tbs" product has, such as the index listing depth control. It seems rather fragile. Due to simple problems, that wouldn't have caused wbak to even pause, the Omnibackup of a complete disk crashed. IE the data reader process on the node died so that the backup of that disk was aborted. The backup of the other disks in progress wasn't affected, but the offending disk wasn't backed up. But, out of 8 disks in my backup test, the backup failed on 3 of them. Simple things like an abandoned floppy disk mount point caused the failures. These were things that would cause wbak to report an "object not found" error, but it would continue to back up the rest of the disk. When a backup on a disk failed, it would leave behind a "data reader" process that would then go into an infinite loop and eat up all spare CPU cycles until killed by hand. This is a brand new product and the first version, so a few bugs are to be expected. I've only given it a few tests and havn't tried all modes of operation. In non-concurrent mode it may work better. Once enough bugs are worked out so that it's more reliable, it'll be a good tool. For now though, we are still using wbak. Dave Funk
mth@cci632.UUCP (Michael Hickman) (01/06/90)
I have convinced my boss that we must have OmniBack to effectively do our backups. He is also interested in the possiblity of (in the future) porting NCS to our 6/32 Tahoes so that OmniBack can back them up as well as the Suns our software engineers are getting. (3/80's - smart investment. But that's another issue..) But before he buys anything, my boss's boss wants to know how well Omniback REALLY works - not the Apollo hype... Anyone out there want to comment?? Also - anyone using Omniback to backup systems other than Apollo? If so, what is needed and how well does it work? Thanks in advance.. Michael Hickman CAD/CAE Systems Administrator Computer Consoles, Inc. Rochester, NY
bep@quintro.uucp (Bryan Province) (05/25/90)
I have been using Omniback for a couple of months now and I am NOT a happy
camper 8( (flame on)
First of all it takes FFFOOOOORRREEEVVVEEERRR to restore something from an 8mm
tape. This is apparently due to the fact that Omniback writes the whole backup
(in our case, 12 nodes) to one file on the tape. In order to restore even one
file Omniback must search through the whole backup. The few times that I have
tried to restore something it has taken ALL DAY! This to me makes the backup
almost useless. I read in the release notes that it is possible to make
Omniback write several files to one tape. Although the way it is worded it
sounds like they don't recommend it and it will also make backups and restores
more complicated. Has anyone tried this? Does it improve or degrade speed on
backups and restores? Please send me mail on this. Inquiring minds want to know.
Also the reliability is questionable. I was getting some errors on backups so I
did an index of the tape and it looked like everything was there. I found out
from Apollo that the index is misleading! Omniback puts an index of the files
it is going to ATTEMPT to backup at the beginning of the tape. So getting an
index does not confirm that it was able to backup the contents of the file. If
this is common in most tape schemes I appollogize for my stupidity :^) I just
recently tried to restore a file from a backup that reported no errors in
relation to backing up this disk or file. The file I got back was empty. This
does NOT give me a warm fuzzy feelling about the reliability of my backups. I
could try to have it -list_all as it does the backup but that would be HUGE and
impossible to look through since we do a full backup every night.
Is anyone out there having better, the same, or worse luck than I with using
Omniback? I am seriously considering getting the backup software from Workstation
Solutions if I continue to have problems and if I can use the software with my
current Apollo hardware. Here's a good sales opportunity WS guys.
--
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
Bryan Province Glenayre Corp. quintro!bep@lll-winken.llnl.gov
Quincy, IL tiamat!quintro!bep@uunet
"Surf Kansas, There's no place like home, Dude."thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (05/25/90)
Bryan -- > I have been using Omniback for a couple of months now and I am NOT a happy > camper 8( (flame on) Sorry to hear that. > First of all it takes FFFOOOOORRREEEVVVEEERRR to restore something from an 8mm > tape. This is apparently due to the fact that Omniback writes the whole backup > (in our case, 12 nodes) to one file on the tape. True. That is why backups are so much faster. You can multiplex data-writing to be from up to 5 nodes simultaneously > In order to restore even one file Omniback must search through the whole > backup. Well, it only needs to search until it either finds it, or finds the block in the tape-file that specifies end-of-volume for the disk that had the info you're restoring. > The few times that I have tried to restore something it has taken ALL DAY! I just had to restore a directory that was backed up on an 8mm tape. The writing of that disk-volume pretty much spanned an entire tape (we back up ~ 10 GB with a full backup). Restoring it took a couple hours, spinning off a DN4500, with the data-reader on a DN3000, restoring to a DSP90's FSD. > This to me makes the backup almost useless. I consider the backups to be catastrophe insurance, not a "please restore me .cshrc file for me" type operation. Therefore, to me they're not worthless. > I read in the release notes that it is possible to make > Omniback write several files to one tape. Although the way it is worded it > sounds like they don't recommend it and it will also make backups and restores > more complicated. Has anyone tried this? Does it improve or degrade speed on > backups and restores? True. Also true. Yes. We are currently using this method to put two incr backups on a single 8mm tape. For backups, just use the non-rewinding device (rmts12 or 13, instead of rmts8 or 9). For restores, you need to position the tape using the new_mt program. It works, but.... I assume that you'd be using it to back up a single disk-volume to each 'file' on the tape. This'll slow down your backups, because you'll only be backing up 1 disk at a time. Restores will probably be a little faster, since you can quickly skip past all the files that aren't for the to-be-restored volume. > Also the reliability is questionable. I was getting some errors on backups so I > did an index of the tape and it looked like everything was there. Are you using version 1.1 or 1.2? O/S 10.1 or 10.2? The best results are with version 1.2 (a LOT fewer time-out problems) and with O/S 10.2 (even with the PSK4(?), I'm not thrilled -- we had a lot of problems until we moved the tape drives on to a 10.2 node). > Omniback puts an index of the files it is going to ATTEMPT to backup at the > beginning of the tape. So getting an > index does not confirm that it was able to backup the contents of the file. I was under the impression that the index mode still scanned through the tape. Obviously, it can't really verify much more than the name and type of the object, but I don't think that it uses the initial "attempt" list for the index. If it does, that's a BUG, or else we need a 4TH nbsrestore mode called really_index. > ... we do a full backup every night. Why? I think that this may be the source of a lot of your long-restore woes. You might consider doing a full weekly (bi-weekly / monthly) with an incr on every other day. The incr backups save everything since the last FULL backup (not a-la wbak (thank you Apollo!)), so at worst, you'd need to perform 2 restores to find something -- the full, and the latest incr. You'd also see a decrease in backup times on the incrs, and would probably see a drop in volume such that you could justify a list_all on the incr days. With that, you could directly check incr backups for the file(s) that were requested. If they weren't backed up, then restore using the full, knowing that no changes occurred since then. > Is anyone out there having better, the same, or worse luck than I with using > Omniback? I am seriously considering getting the backup software from Workstation > Solutions if I continue to have problems and if I can use the software with my > current Apollo hardware. Here's a good sales opportunity WS guys. I am overjoyed with Omniback. Yes, I will admit that there are shortfalls, which I hope/assume will be corrected in the future. However, Omniback has made my backups faster and more painless than ever before (partly due to 8mm technology, admittedly). I also have a lot more confidence in HP/Apollo than I do in a 3rd-party supplier to keep up with O/S and hardware changes that HP/Apollo makes. Perhaps this is unfounded, but I'll continue with Omniback at least until I get convinced that I'm wrong. John Thompson Honeywell SSEC Plymouth, MN thompson@pan.ssec.honeywell.com thompson@pan.ssec.honeywell.com@cim-vax.honeywell.com thompson@animal.ssec.honeywell.com
achille@cernvax.UUCP (achille petrilli) (05/26/90)
Here I am, ready to throw in my 2 cents worth ... In article <9005251516.AA11219@umix.cc.umich.edu> thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) writes: >Bryan -- > >> First of all it takes FFFOOOOORRREEEVVVEEERRR to restore something from an 8mm >> tape. This is apparently due to the fact that Omniback writes the whole backup >> (in our case, 12 nodes) to one file on the tape. >True. That is why backups are so much faster. You can multiplex data-writing >to be from up to 5 nodes simultaneously In my experience, I do not see a big advantage in the accrued speed. The tests I did showed not a very big improvement with respect to 'wbak | dd', yes it goes faster, but: 1) a 2 GB Exabyte takes just over 2 hours to fill up at full blast, 2) I got 100KB/sec almost always from wbak, say 1/3 the full speed of an 8mm, so it takes 7 hours to fill a cassette, 3) a night consists at least of 8 hours then I don't see a difference between wbak/omniback. >> In order to restore even one file Omniback must search through the whole >> backup. >Well, it only needs to search until it either finds it, or finds the block >in the tape-file that specifies end-of-volume for the disk that had the info >you're restoring. As it is advised to run similarly sized disks together with Omniback, probably all disks backups will end more or less at the same time, i.e. at the end of the tape, I guess. >> This to me makes the backup almost useless. >I consider the backups to be catastrophe insurance, not a "please restore me >.cshrc file for me" type operation. Therefore, to me they're not worthless. I think backups serve 2 purposes, one is the insurance-type operation, the other is archiving. I found wbak enough for insurance (at 10.2), but still, Omniback is no better for archiving. >> ... we do a full backup every night. >Why? I think that this may be the source of a lot of your long-restore woes. I also did full backups only on some machines. The reason being, it's very easy to reconstruct a disk if you lose it. Also if a user asks to reload the .cshrc file s/he just clobbered, you don't have to think, just put on the last tape and off you go. >You might consider doing a full weekly (bi-weekly / monthly) with an incr >on every other day. The incr backups save everything since the last FULL >backup (not a-la wbak (thank you Apollo!)), so at worst, you'd need to perform I consider omniback a step backward as wbak was able to do the two (incr with respect to last full and incr with respect to last backup, full or incr) type of incrementals, while omniback only does incr with respect to full (by the way, you do incr WRT full with the '-incr -nhi' flags). I don't think reducing the functionality is ever a good idea. >> Is anyone out there having better, the same, or worse luck than I with using >> Omniback? I am seriously considering getting the backup software from Workstation >> Solutions if I continue to have problems and if I can use the software with my >> current Apollo hardware. Here's a good sales opportunity WS guys. >I am overjoyed with Omniback. Yes, I will admit that there are shortfalls, >which I hope/assume will be corrected in the future. However, Omniback has >made my backups faster and more painless than ever before (partly due to 8mm >technology, admittedly). I also have a lot more confidence in HP/Apollo than >I do in a 3rd-party supplier to keep up with O/S and hardware changes that >HP/Apollo makes. Perhaps this is unfounded, but I'll continue with Omniback >at least until I get convinced that I'm wrong. I agree, I wouldn't like to depend from a 3rd party for my backups, on the other I either do not like to depend from a layered product for my backups ! >John Thompson Achille Petrilli Management Information Systems CERN
pha@CAEN.ENGIN.UMICH.EDU (Paul H. Anderson) (05/30/90)
> >> This to me makes the backup almost useless. >I consider the backups to be catastrophe insurance, not a "please restore me >.cshrc file for me" type operation. Therefore, to me they're not worthless. I think backups serve 2 purposes, one is the insurance-type operation, the other is archiving. I found wbak enough for insurance (at 10.2), but still, Omniback is no better for archiving. >> ... we do a full backup every night. >Why? I think that this may be the source of a lot of your long-restore woes. I also did full backups only on some machines. The reason being, it's very easy to reconstruct a disk if you lose it. Also if a user asks to reload the .cshrc file s/he just clobbered, you don't have to think, just put on the last tape and off you go. >You might consider doing a full weekly (bi-weekly / monthly) with an incr >on every other day. The incr backups save everything since the last FULL >backup (not a-la wbak (thank you Apollo!)), so at worst, you'd need to perform I consider omniback a step backward as wbak was able to do the two (incr with respect to last full and incr with respect to last backup, full or incr) type of incrementals, while omniback only does incr with respect to full (by the way, you do incr WRT full with the '-incr -nhi' flags). I don't think reducing the functionality is ever a good idea. >> Is anyone out there having better, the same, or worse luck than I with using >> Omniback? I am seriously considering getting the backup software from Workstation >> Solutions if I continue to have problems and if I can use the software with my >> current Apollo hardware. Here's a good sales opportunity WS guys. >I am overjoyed with Omniback. Yes, I will admit that there are shortfalls, >which I hope/assume will be corrected in the future. However, Omniback has >made my backups faster and more painless than ever before (partly due to 8mm >technology, admittedly). I also have a lot more confidence in HP/Apollo than >I do in a 3rd-party supplier to keep up with O/S and hardware changes that >HP/Apollo makes. Perhaps this is unfounded, but I'll continue with Omniback >at least until I get convinced that I'm wrong. I agree, I wouldn't like to depend from a 3rd party for my backups, on the other I either do not like to depend from a layered product for my backups ! >John Thompson Achille Petrilli Management Information Systems CERN The big problem that we have with Omniback is, as you've mentioned, that it is the only Apollo software that supports the 8mm tape unit. Our options are severely restricted when faced with Omniback, because we already built a backup logging system similar to that provided by Omniback, but based it on wbak, instead. So, if we wish to stay with our handy dandy tape software, we are stuck with either 6250 BPI tapes, or with using 3rd party wbak support for the 8mm units, both options are poor. 6250 tapes are bad news, because with 75-100 gigs of data to do full backups for, the physical storage of all those tapes becomes a big problem. 3rd party stuff is bad news, because I'd really rather not have to rely on 3rd party support of such critical services such as backups. Word processing packages, I can understand, software to run tape drives, I don't. The people in charge of the technical side of omniback are generally doing the right thing. The marketting people who are handling the large capacity storage devices are generally screwing up. Part of the screwup is not their fault, since the merger made 8mm vs 4mm support more confusing (since HP makes 4mm tape units, but not 8mm units). Still, the continued problems with marginal 8mm tape support are a big black eye for HP/Apollo. I hope they can get their act together, because things like this are so basic and fundamental to the smooth operation of a network that even little slip ups get translated into really big problems. Add up enough slips like this, and it gets awfully hard to support large networks of these machines. Paul Anderson CAEN Systems Programmer University of Michigan