Migrate directly on the server
We recommend running the migration directly on the server and not from a client. This applies to a database on a Windows server. Run the GTR Firebird setup on the server and use the mode Local Database there. This mode also creates the safety copy
<database>_orig. Then switch the INI files on the clients. See Migrating the database configuration.
The GUI application offers two modes for databases on other computers. Use them if a migration on the server is not possible, for example on a Linux server. The command line application supports local databases only.
Network share
Mode: Remote Database (file access via network share)
Use this mode if you can open the database file through a Windows network share, for example \\SERVER\Share\Database.fdb. The Firebird servers on this computer process a local copy. The tool then replaces the database on the share and keeps the previous version there as <database>_orig. Network share mode lists the steps.
Requirements:
- Read and write access to the folder on the share. The tool creates
<database>.newand<database>_origthere. - Enough free space on this computer for a copy of the database and a backup file
- The Firebird servers that the operation needs, on this computer
Before you start, stop all programs and services that use the database on the share. Start them again after the completion dialog.
TCP/IP connection
Mode: Remote Server (TCP/IP - Firebird port only)
Use this mode if you can reach the Firebird server over its network port but cannot access the database file. The server can run on this computer or on another computer, under Windows or Linux.
Required information:
- Server: name or IP address of the server
- Port: Firebird port of the server. The defaults are 3050 for Firebird 2.5 and 3055 for Firebird 5.
- Database path on the server: the path of the database as the server sees it
- User and Password: a Firebird user on the server, usually
SYSDBA
The tool fills in User from FB25_USER or FB50_USER in .env. The passwords in .env belong to the Firebird servers on this computer. For this reason the tool fills in Password only if Server names this computer. For a server on another computer, enter its password. The tool does not save it.
How it works:
- The tool connects to the Firebird server with User and Password of the box. It checks the server that the restore writes to. See Checks before the backup.
- The server backs up the database and sends the backup to this computer. The tool stores it in a temporary folder.
- The tool sends the backup to the server, which restores it. For a vacuum, the restore replaces the database. For a migration, the Firebird 5 target server restores it to the target path.
- The tool deletes the backup file.
No manual copy is needed. The tool makes no _orig safety copy in this mode. A migration to a new target path leaves the Firebird 2.5 database unchanged. Before a vacuum or a migration with Overwrite an existing database at the target, back up the database on the server.
Migration to another server
For Migrate from Firebird 2.5 to 5.x the box Firebird 5 target names the Firebird 5 server and the path of the new database. The target can be the same computer as the source or a different one. The tool copies Server and Database path on the server from the source. Check both values before you start.
The Firebird 2.5 database stays unchanged. ProfDia and other programs keep using it until you change their configuration. For ProfDia and NestCut, see Migrating the database configuration.
Requirements on the server
- This computer reaches the Firebird port of the server. A firewall between them must allow the port.
- User and Password are valid on the server. For Firebird 5 this user must exist in
Legacy_UserManager, because the tool logs in with Legacy_Auth. The GTR Firebird setup creates such a SYSDBA user. - The Firebird service has write access to the database file. Firebird opens the database for writing, also for a backup.
- The Firebird service has write access to the folder of the database, not only to the database file. The restore creates the database file in this folder. For a vacuum this is the folder of the source database. For a migration it is the target folder.
- The database path is allowed by the
DatabaseAccesssetting infirebird.confof the server. - The server has enough free space for the restored database.
For a Firebird server on Linux, Firebird servers on Linux describes the file permissions and a Docker setup.
Checks before the backup
Before the backup, the tool checks the server that the restore writes to:
- For a migration without Overwrite an existing database at the target, the tool creates the target database itself and deletes it again. If any file exists at the target path, the server cannot create the database, and the operation stops with an error. This also applies to a file that is not a Firebird database.
- For a vacuum, or a migration with Overwrite an existing database at the target, the tool creates a small test database
<name>_writecheck_<code>.fdbin the folder of the database and deletes it again. If the server cannot create it, the operation stops with an error.
For a database given as an alias, for example PROFDIA, the tool asks the server for the file path of the database and checks its folder. The tool skips the folder check in two cases, and the log names the reason:
- The server cannot open the database under this alias.
DatabaseAccessinfirebird.confallows the alias but no new file in its folder. The restore by alias works in this case.
If a check fails, the tool transfers no data and the database stays unchanged. See Target database cannot be created and Server cannot create a database in the folder.
Firebird in a Docker container
If the Firebird server runs in a Docker container, enter the path inside the container, for example /var/lib/firebird/data/PROFDIA.FDB. The path on the host computer does not work. The Port is the port that the container publishes on the host, for example 3055.
Firebird 5.0 with Docker Compose describes a complete setup with port 3055 and Legacy_Auth.