dear GK,
i can just report you my experience with firebird. i've used it since the
days 0.9.4 was out. i've never lost ANY data in a firebird database since
then. i think if you really lose data with firebird it is 99% a hardware
problem. we are running internet servers 24/7 without crashes or restarts
for many months. if forced writes are on, you can even pull the plug of your
server without losing your database.
i only had problems restoring a database when i once created a not-null
column and did not fill all rows with data. you can still restore your
database with some commandline switch, turning off checks. it then comes in
handy having a metadata script to restore all checks, foreign keys and so
on.
i suggest to do a backup and a restore every time you change the metadata of
your database. i've used this with success for a long time.

regards
mw

-----Original Message-----
From: gkrishna63 [mailto:gkrishna@...]
Sent: Tuesday, August 13, 2002 12:15 PM
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
>




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



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/