Hi Helen,

Thanks for your input.

I do admit the backup and immediate restore sequence seems a bit
strange, but I don't have any other reliable way of finding out what
data is actually in the backup snapshot. I need to know because I have
to synchronize other non-database files as well between a primary and
backup system, each of which are running on different servers and/or
platforms.
Sometimes I need to make addtional changes to the backup database as well.

I also must use the -R option to restore the backup file on the server
because I need to ensure that any existing file is replaced (-C fails
if file exists). With files residing on remote servers (and usually in
non-shared locations) I cannot delete or test these from an
application running on a different server or workstation.

I'm quite sure there's nothing wrong with the supplied paths to the
backup files or target database. Else the restore process would fail
each time and not just every now and then. The same thing applies to
security rights on the server. After the last error reported by my
backup tool there have been another 60+ successful backups with
exactly the same parameters and user account.

The reported error indeed indicates the underlying problem is some
basic file I/O error. I'm currently taking a closer look at the backup
thread and properties I provide to the IBORestoreservice component.
Inside a routine for restoring backup files I use a simple loop which
calls IsServiceBusy to detect the completion of the restore process.
Maybe the body of the loop is exited too soon. Could just be a
compiler setting causing more optimization than desired.

BTW, I do use try..except contructions to catch any exceptions thrown
by the backup and restore components. This would also tell me if there
any problems with the backup snapshot created from the live database.
If any error occurs, the complete backup-restore sequence is canceled.
So far any errors with failing backup, restore or copy procedures have
never resulted in a crippled backup system.


Thanks anyway for your help.


Lucas

--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:
>
> At 09:20 PM 8/12/2005 +0000, you wrote:
> >Using the IBOAdmin components to backup and restore databases, I
> >sometimes get an error while restoring a backup (*.fbk) database.
> >
> >On linux: I/O error for file "/tmp/0"
> >and on Windows XP Pro: I/O error for file "C:\Windows\System32\0"
> >
> >I'm running the superserver on linux (LI-V1.5.1.4481)
> >and windows (WI-V1.5.2.4731).
> >
> >The error occurs both on remote and local systems and different
> >databases. To rule out the backup process introducing the problem,
> >I have tested both with and without clients attached to the databases
>
> I doubt that. If your tests are running from your application or
from the
> IDE, it's very unlikely that you won't have at least one client
attachment
> alive unless you specifically coded and post-checked an explicit
Disconnect.
>
>
> >It seems like some sort of timing problem... I've already inserted
> >a 2 second hold-off time bewteen backup and restore procedures and can
> >increase this value, but I'd like to know why the error occurs before
> >doing this.
> >
> >One final piece of info: the backup and restore procedures run from
> >whithin a thread in the delphi application.
> >
> >Any thoughts are welcome
>
> Too much is unsaid here.
>
> Are you really backing up a database and then immediately restoring it
> without testing whether you have a restorable backup?
>
> I/o errors from gbak (which, be assured, is what you are using
through the
> service components, despite your misleading statement in your
cross-post to
> the support list...) are literally file i/o errors. Like any other
failed
> attempt to access a file, it will be caused by one or more of the
following:
>
> 1. the file isn't where you said it was. Usual reason: you didn't
supply
> the full path to the file; or you supplied an invalid path. For
> restoring, gbak is interested in either two or three files,
depending on
> whether you set the -R switch (for Replace Database) or the -C
switch (for
> Create Database).
>
> *** The -R switch needs file access because, before it can begin
restoring,
> it has to delete the old database file and create a new, empty file
of the
> same name.
> *** The -C switch needs file access because it has to create a new
database
> file.
> *** And of course the backup file (your fbk file, which is not a
database
> at all, just a file).
>
> Relative paths won't work. If you didn't supply full file specs,
each of
> the servers has default places where it will go looking. That looks
like
> what's happening here (for which I think you need to be grateful....)
>
> 2. On Linux, the service_manager (the firebird user) has to have the
> appropriate filesystem permissions to the files and *also* execute
> permission for the directories where it has to do anything. On
Windows,
> the service_manager will have totally destructive rights if Firebird is
> running as a service and you haven't done anything since
installation to
> change that; or the rights of the user that started the server, if
running
> as an application.
>
> 3. If you use the ReplaceDatabase switch (not recommended, except
when you
> don't care whether your database survives or not), gbak won't be
able to
> delete the database file if there is a connection to it. You can't
delete
> files that are open.
>
> Also note that a gbak restore is not an atomic operation. Even if the
> restore falls over, anything that happened before the new database
file was
> created will not be undone - specifically, if gbak deletes your
database
> and then can't find the backup file, it's all over. The database
file is
> gone. You'd better hope that, when you finally give the right info to
> gbak, you actually have a restorable backup.
>
> gbak -R is a fully-loaded high-velocity firearm pointed directly at
your foot.
>
> Helen
>