Open firebird-automations opened 11 years ago
Commented by: @aafemt
Database restore is an emergence action, not a part of ordinary maintenance by any meaning. There is no need to perform it remotely.
Commented by: michalk1 (michalk1)
Well, it depends on. When you develop an in-house application in a company with experienced network administrators, there is no problem to restore the backup on the server's machine. On the other hand, most of our uses are not experienced in IT, they rely entirely on features of the client application that we provide, so we must find ways how to backup and restore databases remotely. The application we develop runs on Windows only, but some client prefere Linux servers, etc. I think FB is often used in such "low admin cost" scenarios, as a replacement of former dbf, access etc. applications, where it's not possible to call administrator every time users need to restore a backup.
Furthermore, there are more cases where such a feature would be helpfull, ie. "data pump" migration into new database structure (after which I want to replace the original database), making a working copy of a database to test some substantial data deletion / import etc.
Commented by: Sean Leyne (seanleyne)
It seems that you are looking for the engine to provide functionality which is outside of it's scope -- it is not a deployment/install manager.
The functions you are looking for should be provided by a management service which you would develop and deploy to meet your unique requirements.
Submitted by: michalk1 (michalk1)
Votes: 1
The recommended way to restore a database file is to restore it under temporary filename, and only when it's succesfully created, replace the original database file. However, the engine currently doesn't offer any support for this action (file rename or copy operation), that could be controlled from an application running at a remote client station. Such a feature would simplify database restoration process and other database actions, that must be executed on a database copy.
Studying archives, I found several workarounds, none of them being perfect:
- Write a udf library with that functionality - requires every developer to maintain and install several versions of such a library (Win/Linux, 32bit/64bit, ...). Customers can't run Firebird out of the box. Such a udfs may be also prone to errors, because developers may not be aware of FB file locking etc.
- Server-side backup and restore (through services API) of the database to "rename" it - works, but is slow and requires fallback plan (in case of a power failure during restore process etc.).
- Server-side backup and restore by the new nbackup services API in FB2.5. Much faster than gbak, but still not as fast as a simple file rename or copy. Furthermore, nbackup doesn't allow to overwrite the intermediary nbk file. Every run must be executed with a different temporary filename, which causes the nbk files to pile up, and there is no way to delete them from the client station.