> Thanks for input! I prefer tapes also. This process is just in a testing
> phase. My concerns was the recovery process also. I have been able to do
> simple restores but I am very cautious when it comes to having to truncating
> the file when it gets near the disk capacity and start a new one. Will logs
> then be reliable? This has not been tested by me yet.
a certain size
1. stop continuous logging(kill -15 works fine, but you have to do an onmode -l afterwards for the ontape to finish writing to the device)
2. move the file to a different name
3. touch the LTAPEDEV
4. change the permissions on the LTAPEDEV
5. start ontape again
Maybe you could put something in cron to monitor if the instance is up, if itQuote:
> This backup logs to disk was suggested by the system admin crew because they
> perform the backups and quite often forget to restart the continuous log
> backups after an archive. We have two instances on this host so two tape
> drives are already in use. When I asked about putting a third on it, I got
> blank stares from the sysadmin people.
is check if ontape of some type is running, if not alert somebody to the problem.
I am a big ontape fan personally. Nothing like easy to make me happy.Quote:
> Ontape has been very good to us for a long time but we are trying to go to
> onbar as soon as we can figure out how to get the archives and the logs to
> go to two different devices. We use veritas (through SUN) as the storage
> manager and a large SUN DLT jukebox as the backup device.
> > Backing up to disk is pretty well accepted and, perhaps, the preferred
> > method today, but I tend to agree with AH. I have found that ontape is
> > sufficient for my needs and that if you can dedicate two tape devices to
> > using ontape to write to tape is quite effective. I have one tape drive
> > handle the ontape -c and the other ontape -s. I never have to worry about
> > which device is doing what. It's really a "no brainer". Good 'ol ontape to
> > tape is reliable as hell, IF the environment is suited for it. Onbar is
> > great, I just don't need that kind of versatility. Don't dismiss writing
> > tape....disk will be faster...but....
> > --ch
> > > >I would like to backup my logical logs to disk instead of tape. I use
> > > >ontape on IDS 7.31 on SUN server running Solaris 2.4. The disk I am
> > > trying
> > > >to use is a cooked disk with a ufs mount. I have tried the actual
> > > >name and an alias iin the LTAPEDEV and what I think is the correct
> > > >size. The system adminstrator says it is an 8k block size. When run
> > > >ontape -a I get the message "could not write log tape." Any ideas?
> > > Call me old-fashioned, but STICK TO TAPES!
> > > Have you planned out the entire log-scraping ritual and recovery
> > operations?
> > > Are you 100% you understand both processes? Are you 100% sure that your
> > > processes are fault tolerant?
> > > For every person that asks this question on the group, we get one person
> > who
> > > asks how to restore their system, now that they are in an emergency
> > > situation "and I've been writing my logs to disk/no rewind
> > > devices/MIME::Base64 on a line printer".
> > > The tapes are your last refuge in the case of failure. I'm never going
> > > accept f***ing around with the taping rituals. If you want something
> > > automatic or capable of handling very large databases, look into onbar
> > > storage managers.
> > > That's my $0.04AU worth...
> > > --
> > > If you ever reach total enlightenment while drinking
> > > beer, I bet it makes beer shoot out your nose.
> > > - Deep Thought, Jack Handy
> > > .. ... .--. .. - --- -. --- .-. .- -.-. .-.. .