Re: External backup/restore - an idea - comments please

Hi, > > I don't think that you need to do anything with the current and > > previous logs. This is because these have been applied to the dbspaces > > that you have just backed up. > > This is exactly what I needed confirmation for. > Martin also suggested it in his reply and it perfectly suits me. > It's because documentation states that logical logs are mandatory for > successful external restore. Right. Of course (and I didn't mention that before, so here it goes), this is true only when you externally backup all your dbspaces at the same time, i.e. within the same frame of "onmode -c block" and "onmode -c unblock". If you backup some dbspaces in one such frame, and other dbspaces in another "-c block/unblock" frame, then you will need log restore as they are needed to bring the dbspaces consistent to each other. However, I don't think that you will do this in your environment and I also (generally) do not recommend this. > > I wonder now if you have backed > > up your logs with ontape can you do an onbar physical restore and then > > an ontape logical restore? If so then do an onbar -r -p -e ... then > > apply the logs that you need using the ontape -l command. It seems like > > you can but I don't actually know. > > For all I know this can't be done because onbar and ontape internals are > different and you can't backup storage spaces with onbar and logical logs > with ontape and have a decent restore with that. > Somebody correct me if I'm wrong, please. You can do that, and it works. However, you only can restore logs either with ON-Bar or with ontape. You cannot restore some logs with ontape and then following logs with ON-Bar (or vice versa). I.e. you can't switch the method inbetween. That's why I would suggest to not mix the log backup either, as that would exactly create the above situation ... I know you understood that already, just to make it clear for everyone here. Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management owner-informix-list@iiug.org wrote on 06.10.2005 10:48:32: > > Is this what you are talking about: > > onmode -c block> > <get permanent copy of chunks in some way> > > onmode -c unblock> > Basically, yes. > I'd use dd, gzip and netcat for dumping all chunks (all of them in raw > devices) to filesystem on a remote host. > > > The onmode -c puts all of the chunks into a consistent state and the > > block keeps them there until you give it the unblock command. During > > the blocked time you can copy every chunk to a file, or tape. If you > > have drives that have a double mirroring scheme you can break one of > > the mirrors for each drive and unblock the server and then backup the > > Yes, I've read about the mirroring, but in this stage I don't consider it. > I'd have to do it manually, or spend years for writing a script to do it. > My idea was to launch a cron script early in the morning, between 3am and > 4am when there's almost no one connected. > > > I don't think that you need to do anything with the current and > > previous logs. This is because these have been applied to the dbspaces > > that you have just backed up. > > This is exactly what I needed confirmation for. > Martin also suggested it in his reply and it perfectly suits me. > It's because documentation states that logical logs are mandatory for > successful external restore. > It seems that I forgot that logs are not only backed up but also reside on > the disk (from which they get backed up) :-) > > > Now this doesn't solve point in time backups using the logs. You can > > Well, at the moment I'm not concerned about point-in-time restores. They > fork fine when using onbar and storage manager that does backups is > available (I tested it, although just on trivial set of data). > I'm thinking about external backups/restores because few days ago I was > frightened with strange backup verification results. "Onbar -v" aka > archecker wasn't able to verifiy neither of many backups in the last month. > So we thought something must be wrong with our backup tape library and/or > storage manager. But, when we restored from the last backup taken (it was > whole system backup) everything was fine, all onchecks I ran were > successful. > > > I wonder now if you have backed > > up your logs with ontape can you do an onbar physical restore and then > > an ontape logical restore? If so then do an onbar -r -p -e ... then > > apply the logs that you need using the ontape -l command. It seems like > > you can but I don't actually know. > > For all I know this can't be done because onbar and ontape internals are > different and you can't backup storage spaces with onbar and logical logs > with ontape and have a decent restore with that. > Somebody correct me if I'm wrong, please. sending to informix-list