Hi HeLeN

I sounds all very well.
It seems I have to rething our backup rutines.
97 % of our clients closes up the store at 19.00.
The backup runs at 02.00 at night.
Here there is no problem.

The problem occurs at those sites, where they more or less never
closes.

So in short:

1.
Schedule a GBak operation at let say 00.00 instead of the file
system backup. This an be run while users are attached and working
on the DB ?
How does that ensure that the data is valid ?


2.
Do a filesystem backup as usually, BUT excluding GDB files !


Thank you all.

Michael

--- In ib-support@y..., Helen Borrie <helebor@t...> wrote:
> At 06:43 AM 13-08-02 +0000, you wrote:
> >This sound like a good idea.
> >
> >But the problem is, that our program is sold to many people with


> >little or no IT experience.
> >
> >Therefore they don't know what to look for, how to do things etc.
> >So to make things as simpel as posible (as far as the user is
> >concerned) we set up the backup software to do a FULL backup of
they
> >server(s).
> >
> >That way we know, that we have everyting.
>
> Hmm, but a filesystem backup is NOT the way to back up your
> databases. They should be backed up with GBAK - which,
incidentally, can
> be run quite safely whilst users are working in the database.
>
> Let us know if I am telling you something that you already know
and, if so,
> please tell us why you are going ahead with a filesystem backup
regardless
> and are STILL asking us for ways to make that safer?
>
>
> >And in a lot of other products the file doesn't get copied if its
> >open.
>
> Well, that doesn't apply to gbak, since it doesn't perform any
file copying.
>
> It is actually *worse* if your copying software just blunders
ahead and
> copies the database file because
> 1. it will lock the sector of the disk it is copying from and
cause data
> corruption or worse if there are users working in the database
> 2. it will potentially copy "rubbish", since the disk image of
the
> database changes constantly. The backup won't be any use; but
worse, if
> the file-copying processed trashed the database, then you are left
with no
> usable database and no usable backup.
>
> Go figure.
>
> >I then know the backup is usless, but the original file is still
> >valid and the user can continue.
>
> ..unless the file-copying process broke the database. You know
that it
> can, because you have already been visited by that demon.
>
> Listen to Woody's advice.
>
> Helen
>
> All for Open and Open for All
> Firebird Open SQL Database · http://firebirdsql.org ·
> http://users.tpg.com.au/helebor/
>
_____________________________________________________________________
_