Re: On-Archie or OnBar ??
Derek,
The onarchive program works fine on a variety of platforms
with one exception. Have you ever tried to restore what you've
backed up using onarchive? On some platforms the backup
is great, the restore doesn't work.
Unless you can restore from your backups, your backups are worthless.
I tend to think that onbar is equally worthless. I've done a
complete set of tests with it, and find it does not have the
features necessary for real-world recovery. For example, the
infamous point-in-time restore applies to the WHOLE INSTANCE
without the option to restore either a data base , dbspace,
table, dbslice if you use 8.x, or any combination of these.
Here's a great test for your recovery: A user drops a table.
Recover the table using onbar. Oh, uhm, fortunately for you
the table was in its own dbspace. Right. Well, the logs come
back with the restore and redelete the table for you. Oh, ok
let's restore using point-in-time. Bring the engine down,
remove the links to the raw device, bring the engine up, engine
thinks the dbspace is hosed, marks it offline. Now you can
restore it using point-in-time restore. Uh, well that applies
to the whole instance, sorry. What if you didn't want to
bring the whole damn instance back? The good folks who created
onbar really don't think like the real world.
You have to really build your system around onbar if you
choose to use it. I can point to site after site who ignored
onbar until after they built a system only to find that because
of onbar the system had to be redesigned around onbar's limited
feature set, or they abandon onbar because of its limitations.
Unless you can restore from your backups, your backups are worthless.
The only benefit I see to onbar is that it tells the engine
things are backed up so that new logs can be brought online,
or other situations where onbar is needed to tell the engine
things are ok. But as to a backup strategy, I still tell people
to buy as much disk for table dumps-to-disk as the data base.
We had onbar working great with ADSM and it will continue to work
great, but what good is it for me to attempt a restore? Only when
I would want to restore the whole damn instance. This is all its
good for.
Is this crazy? No, there is no table-level restore in onbar. You
get all or nothing. And if the last onbar backup is hosed you are hosed.
You are at the mercy of also needing the logical logs. For shops who
have onbar working with their heavy OLTP, and can honestly say they
can restore, these are shops where they have probably been through a
certain amount of pain getting this to work.
I still challenge anyone out there to tell me that a table level dump
to disk and UNIX backup is less than onbar. Even on NT using cooked
files and a tape drive, simply restoring the dbspaces with NT backup
is better than relying on the limitations of onbar.
Onbar should scare the living daylights out of you for restore.
Thanks,
Tim
Derek Runstadler wrote:
>
> We have been using Onarchive successfully and happily
> for about 2 years on 15 instances. I'm not sure why
> almost all the posts on Onarchive flame it, as it
> doesn't appear to be any more complicated than Onbar
> to me. We do plan to migrate to Onbar.
> --
> Derek Runstadler
>
> Informix@wor.tvp.com.pl wrote in message <7g94ko$f3d$1@news.xmission.com>...
> >
> >Hi,
> >
> > We are going to migrate from 5.x to 7.3 ( Digital UNIX )
> > I went through manuals and more or less know functionality.
> > I am interested in opinions based on experience (stability and
> reliability)
--
-
--
--- Tim Schaefer
---- tschaefe@mindspring.com
--- http://www.inxutil.com
--
-
In article <372EDD2F.787A80C7@mindspring.com>,
Tim Schaefer <tschaefe@mindspring.com> wrote:
> Derek,
>
> The onarchive program works fine on a variety of platforms
> with one exception. Have you ever tried to restore what you've
> backed up using onarchive? On some platforms the backup
> is great, the restore doesn't work.
>
> Unless you can restore from your backups, your backups are worthless.
>
> I tend to think that onbar is equally worthless. I've done a
> complete set of tests with it, and find it does not have the
> features necessary for real-world recovery. For example, the
> infamous point-in-time restore applies to the WHOLE INSTANCE
> without the option to restore either a data base , dbspace,
> table, dbslice if you use 8.x, or any combination of these.
>
> Here's a great test for your recovery: A user drops a table.
> Recover the table using onbar. Oh, uhm, fortunately for you
> the table was in its own dbspace. Right. Well, the logs come
> back with the restore and redelete the table for you. Oh, ok
> let's restore using point-in-time. Bring the engine down,
> remove the links to the raw device, bring the engine up, engine
> thinks the dbspace is hosed, marks it offline. Now you can
> restore it using point-in-time restore. Uh, well that applies
> to the whole instance, sorry. What if you didn't want to
> bring the whole damn instance back? The good folks who created
> onbar really don't think like the real world.
>
> You have to really build your system around onbar if you
> choose to use it. I can point to site after site who ignored
> onbar until after they built a system only to find that because
> of onbar the system had to be redesigned around onbar's limited
> feature set, or they abandon onbar because of its limitations.
>
> Unless you can restore from your backups, your backups are worthless.
>
> The only benefit I see to onbar is that it tells the engine
> things are backed up so that new logs can be brought online,
> or other situations where onbar is needed to tell the engine
> things are ok. But as to a backup strategy, I still tell people
> to buy as much disk for table dumps-to-disk as the data base.
>
> We had onbar working great with ADSM and it will continue to work
> great, but what good is it for me to attempt a restore? Only when
> I would want to restore the whole damn instance. This is all its
> good for.
>
> Is this crazy? No, there is no table-level restore in onbar. You
> get all or nothing. And if the last onbar backup is hosed you are hosed.
> You are at the mercy of also needing the logical logs. For shops who
> have onbar working with their heavy OLTP, and can honestly say they
> can restore, these are shops where they have probably been through a
> certain amount of pain getting this to work.
>
> I still challenge anyone out there to tell me that a table level dump
> to disk and UNIX backup is less than onbar. Even on NT using cooked
> files and a tape drive, simply restoring the dbspaces with NT backup
> is better than relying on the limitations of onbar.
>
> Onbar should scare the living daylights out of you for restore.
>
> Thanks,
>
> Tim
>
> Derek Runstadler wrote:
> >
> > We have been using Onarchive successfully and happily
> > for about 2 years on 15 instances. I'm not sure why
> > almost all the posts on Onarchive flame it, as it
> > doesn't appear to be any more complicated than Onbar
> > to me. We do plan to migrate to Onbar.
> > --
> > Derek Runstadler
> >
> > Informix@wor.tvp.com.pl wrote in message <7g94ko$f3d$1@news.xmission.com>...
> > >
> > >Hi,
> > >
> > > We are going to migrate from 5.x to 7.3 ( Digital UNIX )
> > > I went through manuals and more or less know functionality.
> > > I am interested in opinions based on experience (stability and
> > reliability)
>
> --
> -
> --
> --- Tim Schaefer
> ---- tschaefe@mindspring.com
> --- http://www.inxutil.com
> --
> -
>
Currently we're running:
AIX 421
Informix 730 UC 5
We chose to use Onarchive (before Onbar was available)
because it satisfied a few requirements at our shop:
- archive to disk
(and we get past the 2gB output file limit)
- backup logs to disk (continuously)
- unattended operations of archives and backups
- catalog management of archives and backups
- reliability
Each entire instance is archived, and daily
exports are done for any table level restores.
We have restored to a different system to extract
a lost table.
We have had occasions to do whole system restores
(sometimes to a point in time). This does require
operator intervention.
Each Unix box is backed up as well, with images
going to off-site storage.
We plan to migrate to Onbar if and when we get
a storage manager. ISM doesn't cut it for us.
--
Derek Runstadler
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own