Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!PAN.SSEC.HONEYWELL.COM!thompson From: thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) Newsgroups: comp.sys.apollo Subject: re: Omniback Message-ID: <9005251516.AA11219@umix.cc.umich.edu> Date: 25 May 90 15:09:35 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 87 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