Join / Log in
Hola Joan Luis,
Did you try setting anything but /dev/null in LTAPEDEV ?
If the engines sees /dev/null in LTAPEDEV, it considers there is no logical logs backup, be it with ontape OR onbar.
So put any other value I LTAPEDEV for instance /tmp/llogsbackup (maybe you have to 'touch' this file, not sure)
And it should work
Eric VercellettoData Management Architect and Owner / Begooden IT ConsultingBoard of Directors, International Informix Users groupIBM Champion 2013,2014,2015,2016,2017,2018,2019,2020
Tel: +33(0) 298 51 3210Mob : +33(0)626 52 50 68skype: begooden-itGoogle Hangout: firstname.lastname@example.orgEmail: email@example.com : http://www.vercelletto.comwww https://kandooerp.org
And did you launch « onbar -r" or more options ?
For me "onbar -r" is what you want
Check the Veritas storage manager logs next.
With ON-Bar, dbspaces are backed up "individually" (and possibly in parallel). The "individually" here means, that each dbspace is backed up by a separate process (and these then can run in parallel). It also means, that each process creates its own "archive timestamp" - for the individual dbspace it has to backup. This "archive timestamp" determines during the backup processing, which records (or their versions) need to be backed up, because they are "from before the archive timestamp", and which records (or their versions) do not need to be backed up, because "they were inserted or changed after the archive timestamp". With that, the dbspace backup itself then contains all the data that is consistent to the time of the "archive timestamp" of the dbspace. Now the problem is, that an ON-Bar backup of a system (normally) contains one "individual" backup of each dbspace, i.e. these backups of the dbspaces have different "archive timestamps". With that, the content of the backup is only consistent within each individual dbspace backup, but across the dbspaces, these individual backups are not consistent. Therefore, it is necessary to use logical log records during the restore to re-establish the consistency across all the individual dbspaces. Without restoring logical logs, it is not possible to restore the system to an overall consistent state. To allow backups and restores to be usable with ON-Bar even without backing up logical logs, there is the concept of a "whole system backup" and corresponding "whole system restore". When doing an ON-Bar "whole system backup", there is only one single "archive timestamp" for the whole system, i.e. for all dbspaces. In addition - in this old version 7.31 at least, I think - this meant that a "whole system backup" was not done in parallel. I.e. all dbspaces were backed up serially. This obviously made a "whole system backup" much slower than a normal (parallel) backup. This was the price to pay for the "luxury" to not need to backup logical logs and still to be able to do a restore of the system. (Basically, an ON-Bar "whole system backup" was done in the same way that was always used for "ontape" - which always was to use just one single "archive timestamp" and backup the dbspaces serially. We later enhanced ON-Bar to be capable of doing "whole system archives" in parallel, but I think that was quite a while after version 7.31.)
It's been a looong time since I've dealt with onbar (never mind 7.31!) but IIRC, running onbar without logical log backups is unsupported. That's because of the differences in how onbar and ontape work. The ontape utility backs up all of the spaces serially, and has a single global start time; when you restore an ontape backup without doing a logical rollforward, the entire engine looks exactly as it did when you started the backup. (Any changes made while the backup is running result in the unchanged pages being copied to temp space; when the backup gets to those modified pages, it backs up the original from temp space instead.)
The onbar utility, OTOH, was designed for much larger systems where this type of backup is impractical, and runs the risk of running you out of temp space. With onbar, spaces are backed up in parallel, and each space is effectively its own independent backup object. When you restore a space without logical rollforward, each space looks as it did when the backup of that space started. If you do a full-system restore that way, your database will be in an inconsistent state, because the different dbspaces will be reflective of different timestamps. The only way to get the system to a consistent state is to roll forward to at least the point in time at which the final dbspace backup began.
Now it's always possible that I'm remembering this incorrectly ( @Art Kagel ? ) or that there was some option to change this behavior that I'm forgetting about, but I don't recall ever being able to successfully restore from onbar backup without doing a logical rollforward. When logical rollforward failed, advanced support had to get in there and hack flags in the dbspaces to make things quasi-consistent again.
Art: That's right. I had forgotten about the –w option. The couple of times I messed with it, in those way early days, I didn't have much luck with it. So you need to do an onbar –b –w before doing an onbar –r –w –p is possible.
Not for nothing, I detested onbar. ;)
Talk about damning with faint praise! J
Fantastic syntax though