Safety measures

Security options on the server
Backup
How to corrupt a database

Security options on the server

Firebird 1.5 has a number of new security provisions. Explore them! Many configurable features default to the old, “insecure” behaviour in order not to break existing applications, but you can significantly enhance your system's security if you raise the protection level wherever possible.

Amongst the new and/or changed security features are:

On Posix systems, Firebird now runs as user firebird by default, not as root.
On Windows server platforms, you can also run the Firebird service under a designated user account (e.g. Firebird). The default practice – running the service as the LocalSystem user – poses a security risk if your system is connected to the Internet. Consult README.instsvc in the doc subdir to learn about this setup.
Database aliases shield the client from physical database locations. Using aliases, a client can e.g. connect to “frodo:zappa” without having to know that the real location is frodo:/var/firebird/music/underground/mothers_of_invention.fdb. Aliases also allow you to relocate databases while the clients keep using their existing connection strings.
DatabaseAccess parameter; can be set to Restrict to limit access to explicitly listed filesystem trees, or even to None to allow access to aliased databases only. Default is All, i.e. no restrictions.
ExternalFileAccess parameter, for controlling access to external tables.
UdfAccess parameter; controls the permitted locations for user-defined function libraries.

Database aliases live in the file aliases.conf, configuration parameters in firebird.conf. Please consult the Release Notes of your Firebird version for their exact usage (and some additional well-meant advice).

Backup

Firebird comes with its own utility for backing up and restoring your databases. Its name is gbak and it can be found in the bin subdirectory of your Firebird installation. Firebird databases can be backed up whilst users are connected to the system and going about their normal work. The backup will be taken from a snapshot of the database state at the time the backup began.

Regular backups and occasional restores using gbak should be a scheduled part of your database management activity.

Warning

Do not use external proprietary backup utilities or file-copying tools such as WinZip, tar, copy, xcopy, etc., on a database which is running. Not only will the backup be unreliable, but the disk-level blocking used by these tools can corrupt a running database.

Important

Study the warnings in the next section about database activity during restores!

How to corrupt a database

The following is a list of things not to do if you want to keep your Firebird databases healthy.

Modifying metadata tables yourself

Firebird stores and maintains all of the metadata for its own and your user-defined objects in – a Firebird database! More precisely, it stores them in relations (tables) right in the database itself. The identifiers for the system tables, their columns and several other types of system objects begin with the characters RDB$.

Because these are ordinary database objects, they can be queried and manipulated just like your user-defined objects. However, just because you can does not say you should. The Firebird engine implements a high-level subset of SQL (DDL) for the purpose of defining and operating on metadata objects, typically through CREATE, ALTER and DROP statements.

It cannot be recommended too strongly that you use DDL – not direct SQL operations on the system tables – whenever you need to alter or remove metadata. Defer the “hot fix” stuff until your skills in SQL and your knowledge of the Firebird engine become very advanced. A wrecked database is neither pretty to behold nor cheap to repair.

Disabling forced writes on Windows

Firebird is installed with forced writes (synchronous writes) enabled by default. Changed and new data are written to disk immediately upon posting.

It is possible to configure a database to use asynchronous data writes – whereby modified or new data are held in the memory cache for periodic flushing to disk by the operating system's I/O subsystem. The common term for this configuration is forced writes off (or disabled). It is sometimes resorted to in order to improve performance during large batch operations.

The big warning here is: do not disable forced writes on a Windows server. It has been observed that the Windows server platforms do not flush the write cache until the Firebird service is shut down. Apart from power interruptions, there is just too much that can go wrong on a Windows server. If it should hang, the I/O system goes out of reach and your users' work will be lost in the process of rebooting.

Note

Windows 9x and ME do not support deferred data writes

Disabling Forced Writes on a Linux server

Linux servers are safer for running an operation with forced writes disabled temporarily. Still, do not leave it disabled once your large batch task is completed, unless you have a very robust fall-back power system.

Restoring a backup to a running database

One of the restore options in the gbak utility (gbak -r[eplace]) allows you to restore a gbak file over the top of an existing database. It is possible for this style of restore to proceed without warning while users are logged in to the database. Database corruption is almost certain to be the result.

Warning

Be aware that you will need to design your Admin tools and procedures to prevent any possibility for any user (including SYSDBA) to restore to your active database if any users are logged in.

Note

For gbak instructions see chapter 21, Database Backup and Restore, of Using Firebird.

For instructions about blocking access to users, see chapter 14, Getting exclusive access to a database, of Using Firebird.

If is practicable to do so, it is recommended to restore to spare disk space using the gbak -c[reate] option and test the restored database using isql or your preferred admin tool. If the restored database is good, shut down the server. Make a filesystem copy of the old database and then copy the restored database file (or files) over their existing counterparts.

Allowing users to log in during a restore

If you do not block access to users while performing a restore using gbak -r[eplace] then users may be able to log in and attempt to do operations on data. Corrupted structures will result.