Subject Re: Major Incident where db rolled back to restore point
Author Milan Babuskov
--- Peter Chaisty wrote:
> 1/ logged in on linux (fedora)

I wouldn't recommend anyone to run Fedora on production system, as it
is a test problems and has some subtle bugs. If you want a RedHat
system, CentOS is a much better option.

> 2/ Closed down all connections
> 3/ ran gbak to a backups sub dir (local gbak)
> 4/ did a restore of the backup to another sub dir
> 5/ renamed original db

At this point you should always check whether some program holds the
file descriptor open, as Linux filesystems allow you to move a file
which is open. Easiest way is with command 'fuser' like this:

fuser /path/to/db/file.fdb

If it doesn't print anything, than it's ok.

BTW, which filesystem do you use?

> 24 hrs later, june 5th
> 8/ closed down connections
> 9/ started a backup on remote windows pc using gbak / closed it
> because it was taking too long

When you 'close' the backup continues - file remains open and firebird
process keeps writing to it. You have to manually kill that process!

> Really I am just trying to work out what I did wrong so that this
> will

Two things to remember (although I haven't seen them anywhere in the
docs) if you are a Linux user:

1. files can get deleted or moved while in use - process using it
knows nothing about it and can keep reading and writing into the void.

Use 'fuser' command to make sure the file is really moved or deleted.

2. When you cancel backup in your application or admin. tool it keeps
running on the server - you have to kill it manually.

Milan Babuskov