Issue Details (XML | Word | Printable)

Key: CORE-1635
Type: New Feature New Feature
Status: Open Open
Priority: Minor Minor
Assignee: Alexander Peshkov
Reporter: Vinokurov Alexander
Votes: 2
Watchers: 1

If you were logged in you would be able to see more operations.
Firebird Core

Database restore using Services API from client machine

Created: 06/Dec/07 04:12 AM   Updated: 07/Dec/07 04:25 AM
Component/s: API / Client Library
Affects Version/s: None
Fix Version/s: None

Environment: any

 Description  « Hide
We have excellent possibility to backup database from client machine with the help of Services API. But there are problems, when we try to restore database in the same way.
First: we can't close all the connections to the database from client machine if other client machines have active transactions. Of course we can shutdown database and other client machines can't open new transactions, but: a) if some clients opened long read transaction and do nothing, the transaction may be endless and b) we can't see from our client machine if all the connections closed anyway but receiving exception on trying moving or renaming original database file.
Second: We can't rename or move current database file (because we haven't access to the server file system from the client machine by the security reasons). We only can restore database from one of the backup files over current database. It's not safety.
Third: We can't see list of previous backup files to select one of them. Yes, we can make log on the client machine or shared folder and append one name per backup.
- It will be usable to add to the Services API function to close all connection because of SYSDBA request with sending notifying message to clients. It may be usable to add the same functionality to the GFIX utility (and corresponding command line parameter).
- if will be usable to add to the Services API something to make it possible to rename or move original database file. I see it may decrease privacy of the server file system.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Sean Leyne added a comment - 06/Dec/07 11:51 AM
I do not believe that extending the Services API to support *overwriting* an active database is appropriate. This is EXTREMELY DANGEROUS. The current functionality to restore to a new database, remotely, and then to shutdown the current database and replace it, via the server/console operations, is the only appropriate operation which should be supported.

Nor, do I believe that the Services API should provide functionality to change the database name. Again, this operation should be performed via server/console operations.

Vinokurov Alexander added a comment - 07/Dec/07 04:25 AM
Quotation:I do not believe that extending the Services API to support *overwriting* an active database is appropriate.
No, I don't want this. And Yes, I can do all I needed from server console.
The issue was to let somebody do all needed operations WITHOUT ACCESS TO SERVER FILE SYSTEM.

I needed in:
  Backup database - it's possible and I can ceate new file name for backup. Excellent
  Restore database - it's possible ONLY if all connection closed and ONLY over existing file. I can restore database to another file name but I haven't access to server file system, so I can't rename restored file to the original name, so I can't use restored database.

So, what I want:
  Yesterday, I backup my database
  Today I want to restore my yesterday copy. What must I do and what can I do ? First, I must be sure that all connections are closed (how?). Second I want to rename my original database (how?). Third I want to restore database from backup to the original file name.