| Subject | Re: [firebird-support] problem with gbak |
|---|---|
| Author | Helen Borrie |
| Post date | 2009-09-27T13:57:19Z |
At 09:44 PM 27/09/2009, you wrote:
However, you have done at least two highly risky things:
1) you used the -replace_database switch, apparently without first checking whether the backup was good.
2) you did this risky thing while your application was possibly logged in to the old database. If you didn't get an i/o error on starting the restore, then the application probably wasn't logged in. If it had been, gbak would not have been able to delete the database file and would have stopped.
You also apparently thought it was a good idea to log into a database that is in the process of being restored. It's not. In fact, it is a VERY BAD idea.
Once you have checked that the restore is finished, make a fresh connection to the database using whatever tool you use to inspect data and check again. If the backup was good, the data should be there. If it is missing then there's something else you haven't mentioned about this escapade. In that case, you might like to see whether you can retrieve the deleted database file from the Recycle bin.
In future, use the -create_database to restore the backup as a database file with a different name. If you're happy with it, then rename the old database. If that succeeds, then rename the restored database to the proper name. And use the logging options!!
>hi all,Well, if you are lucky, and you did not also terminate gbak during the restore, then the restore would have completed successfully and the data will be there now.
>
>i was performing back up/restore with gbak as follows
>
>backup:-
>gbak -b -t -user "username" -pas "password" "source file" "destination file"
>
>restore:-
>gbak -rep -t -user "username" -pas "password" "source file" "destination file"
>
>during these two activities i terminated my application using ctrl+alt+del
>
>and i noticed that the data from all the tables got deleted.
>
>can anybody help me with this....
However, you have done at least two highly risky things:
1) you used the -replace_database switch, apparently without first checking whether the backup was good.
2) you did this risky thing while your application was possibly logged in to the old database. If you didn't get an i/o error on starting the restore, then the application probably wasn't logged in. If it had been, gbak would not have been able to delete the database file and would have stopped.
You also apparently thought it was a good idea to log into a database that is in the process of being restored. It's not. In fact, it is a VERY BAD idea.
Once you have checked that the restore is finished, make a fresh connection to the database using whatever tool you use to inspect data and check again. If the backup was good, the data should be there. If it is missing then there's something else you haven't mentioned about this escapade. In that case, you might like to see whether you can retrieve the deleted database file from the Recycle bin.
In future, use the -create_database to restore the backup as a database file with a different name. If you're happy with it, then rename the old database. If that succeeds, then rename the restored database to the proper name. And use the logging options!!