I refer to an application running circa 60 users each in four separate
locations. The data replicates on the hour between these four servers. It's
been running since 1997 (that's 20 server years). I've had to "rescue" one
of the databases maybe three times (not the same DB - so that's once every 7
server years and three of the servers are 1997 models - not something I
recommend but some clients must save money somehow). Since they are
replicated, I don't have a lot at stake since if really pushed, I could
restore from one site to another (minus the generator adjustments).
That's not a lot to do considering the traffic these servers get.
I always suspect hardware as my first port of call but even then it may be
some other cause.
One thing I would love to see as an improvement, is when I do a backup and
see that there's an error in e.g. a blob field, there's never any indication
as to what record in what table is lost. Out of millions of records, all I
get is "blob error" in the backup output. So there's no way to replace it
since I have no idea what record it relates to.
The servers are all NT4.0 sp6 (now)
The clients are all Delphi 4.0 running against BDE to IB5.6 (started with
4.0)
The clients are running at four sites.
I would never have lost more than a few records, if that, in all this time.
I used to run shadows but with replication, there's no need since every
database is no more than one hour old from the other sources. It would be
another means of backup if you wanted it. There's also the added advantage
of being totally disjointed from the source other than a socket connection.

I do not consider (nor do my clients) that the data loss is unacceptable.
Alan
-----Original Message-----
From: gkrishna63 [mailto:gkrishna@...]
Sent: Tuesday, 13 August 2002 20:15
To: ib-support@yahoogroups.com
Subject: [ib-support] Re: How to assure backup is OK


Alan,
Interesting information. As I said I am new to Firebird. I do not
have databases in production, still under development.

How often does this kind of thing happen? Umm and Why???? <That's a
stupid question if you knew why, I am sure you would have taken steps
to prevent it happenning.>
What I am more interested is things like OS where the database is
running. What development environment for the client applications.
What libraries for connecting to firebird.

My application will be installed at multiple client sites and the
kind of thing you are describing is just not possible in my case.

That is why I am curious to the frequency of such occurences and the
environment. I will be forced to tell them "sorry guys you just lost
2 days of work" if the last good backup is two days old. If this
happens very often I guess I am going to lose quite a few of my
client.

This is one of the reasons that I have an autobackup and the client
can configure how often that takes place.

Curious
GK

--- In ib-support@y..., "Alan McDonald" <alan@m...> wrote:
> agreed - very good - but restoring is yet another interesting topic
> you mention that you need to ensure noone is connected when
restoring.
> well there's more to it than that
> of course, if you stop everyone who is connected, then restore,
everyone
> will loose what they were doing between the time of your last
backup and the
> time of your restore. This can be several hours of work if your
scheduled
> backup was "last night some time"
> When I have been forced to restore a database from a backup, I have
raced to
> stop all activity and disconnect everyone as the first step. I
usually stop
> the service, rename the database and then start the service. Anyone
who has
> ignored (not received) the message to not use the application will
be rudely
> aware of the application not working.
> I have restored to an alternative file name. (now I have the
original
> "corrupt" version and a restored "good" version.
> I have then set about examining the existing database (sometimes
this is not
> possible because of gross corruption). Usually, though, you can at
worst,
> backup the existing database and restore it using the ignore
checksums etc
> options. You now have a restored copy of the database which is
workable but
> may not be complete. Your restored database from last night or
previously
> backed up copy a la the four versions of backups comes in handy.
This is
> where my inclusion of a datecreated and lastupdate field(s)
(updated by
> triggers) on all tables comes in very handy.
> I separate all records which have been created and/or updated post
the date
> of my last backup.
> I can then insert/update these records into the restored backup
version and
> finally I will have restored version of the database which is
mighty close
> to the version before the "crash" or corruption.
> When I bring the database back to live operation, I announce the
date/times
> of disruption and ask everyone to examine their most recent data to
check if
> they finally have to redo some of their edits/entries.
> That's the best I've been able to do. In my experience, people
cannot
> tolerate even an hour's worth of lost data. They don't understand
why, in
> the 21st century, with backup technology, there should be any lost
time at
> all. They already lose the time it takes me to carry out these
operations.
> Sometimes it's taken me all night to do it.
> hope this helps
> Alan
> PS - that backup batch file is very good
>



Yahoo! Groups Sponsor
ADVERTISEMENT



To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



[Non-text portions of this message have been removed]