Here are some commonly used extensions:. N N-th file of multi-file database. Backup: Creates the backup file on the database server, using the Service Manager. Non-transportable format use only when you know you will restore on same platform and database version. Creates a transportable backup transportable between platforms and server versions. Does not restore validity constraints. Restores one table at a time.
When you restore a database, the BLR is not recreated: the same BLR is used until next time you recreate or alter the object. Historically, the engine did not do the right thing regarding the transliteration of strings embedded in the source and the BLR. A side effect of this was that everything that was read from data and meta data became subject to "well-formedness" checks.
Hence, on restoring, those previously stored source and BLR objects are throwing "malformed string" errors when gbak tries to read and write the data in these system table records. This very old bug affects user blobs, too, if they have been stored using character set NONE and the client is configured to read a specified character set to which the stored data could not be transliterated.
The repair switches were added to the gbak restore code in v. The restoration of a database, from a backup, can be made to execute quicker if the -se[rvice] option is used.
Although this is used to perform remote restores, it can be used locally as well. It simply avoids the data being copied over the TCP network which can slow down the actions of the restore.
As you have seen above anyone, with a valid username and password, can restore a gbak database dump file provided that they are not overwriting an existing database. This means that your precious data can be stolen and used by nefarious characters on their own servers, to create a copy of your database and see what your sales figures, for example, are like.
To try and prevent this from happening, you are advised to take precautions. You should also try and prevent backups from being accidentally overwritten before they have expired. Some precautions you can take are:. Always set the dump file to be read-only after the backup is complete.
This helps prevent the file from being overwritten. Keep backups in a safe location on the server. Storing backups in a location with restricted access helps reduce the chances of your backup files 'escaping' into the wild. Keep tape copies of your backups very secure. A locked safe or off-site location with good security is advisable.
The off-site location will also be of use after a total disaster as the backups are stored in a separate location to the server they are required on. In Firebird 2. This new feature automatically hides the password if it is supplied on the command line using the -password switch.
This prevents other users on the system, who could run the ps command and view your command line and parameters, from viewing any supplied password. In this manner, unauthorised users are unable to obtain the supplied password. This does mean that it is possible for someone to work out how long the password could be and that might be enough of a clue to a dedicated cracker.
Knowing the length of the required password does make things a little easier, so for best results use a random number of spaces between -passw and the actual password. The more difficult you make things for the bad people on your network, the better. The following recipes show examples of backup and restore tasks using gbak. These are probably the commonest cases that you will encounter as a DBA.
All the examples use the employee database supplied with Firebird and the actual location is correctly configured in aliases. If you replace an open and running database, there is a good chance that you will corrupt it. For best results and minimal chance of corrupting a database, you should close it before replacing it. To close a database, use gfix as follows:. The example above prevents any new transaction from being started which prevents new queries being executed or new sessions connecting to the database.
It will wait for up to 60 seconds for everyone to logout and for all current transactions to complete before shutting down the database. If any long running transactions have not completed by the end of 60 seconds, the shutdown will timeout and the database will remain open. After the restore of the database has completed, the database will automatically be opened again for use. This example takes a backup, then immediately overwrites the original database using the new backup.
This is not normally a good idea as the first action of a restore is to wipe out the database. It is possible to use gbak to recreate an empty database containing only the various domains , tables , indices and so on, of the original database but none of the data. This can be useful when you have finished testing your application in a test environment and wish to migrate the system to a production environment, for example, but starting afresh with none of your test data.
When the above dump file is restored on the production server, only the metadata will be present. There is another way to create a database with no data and only the metadata.
The database will be restored but none of the original data will be present. This filter was supplied with old versions of InterBase and Firebird to allow large database backups to be split over a number of files so that file system limits could be met. Gbak allows the dump files to be split into various sizes with a minimum of bytes and will only create files it needs.
The sizes after each filename indicate how large that particular file is allowed to be. The default size is bytes, but you can specify a suffix of k , m or g to use units of kilo, mega or gigabytes. If the dump completes before writing to some files, then those files are not created.
A dump file is only ever created when it must be. The size of the final dump file will be quietly ignored if the database has grown too large to allow a truncated backup to complete. If, in the example above, the backup needs a total of M, then the last file would be written to a final size of m rather than the m specified.
To restore such a multi-file backup requires that you specify all of the filenames in the dump and in the correct order. The following example shows the employee database above being restored from the two files dumped above:.
Normally the ODS used is the one in force by the version of Firebird used to restore the database. So, the examples above will actually change the ODS when the database is restored.
The restore should be carried out using gbak from the newer version of Firebird. After the above, the old 2. The default database cache is created when the database is created, or subsequently by using gfix. Gbak can restore a database and reset the default cache size as well. The process is as follows:. The default cache size is used when the number of buffers is zero, as in the first example above. Gbak allows this to be changed if desired.
Gbak , however, cannot set the cache size back to zero. You must use gfix to do this. Similar to the example above to change the default database cache size, the database page size can also be changed using gbak. Sometimes you do not want your reporting staff running intensive queries against your production database.
To this end, you can quite easily create a clone of your production database on a daily basis, and make it read-only. This allows the reporting team to run as many intensive reports as they wish with no ill effects on the production database and it prevents them from inadvertently making changes. First on the production tux server:. You may use gbak to create a clone of a database, on the same server, without needing to create a potentially large dump file.
To do this, you pipe the output of a gbak backup directly to the input of a gbak restore, as follows. You will notice that the output file name for the backup is stdout and the input file name for the restore is stdin. This ability to pipe standard output of one process to the standard input of another, is how you can avoid creating an intermediate dump file. If not, you will need to supply the full path to the two databases rather than the alias.
You may also use the -recreate overwrite option as an alternative. Both have the same result. Further examples of backing up and restoring remote databases over ssh, using the stdin and stdout file names, can be seen below. Databases can have shadow files attached in normal use. Gbak happily backs up and restores those as well and in normal use, shadow files will be recreated. Should you wish to restore the database only and ignore the shadows, gbak can do that for you as the following example shows.
I use isql in the above examples as gstat -h seems to get confused about how many shadows there are on a database. Every backup process including zipping is executed in a separate thread. It's main feature is to preserve the required number of backups to allow data recovery from previous days. GBAK Scheduler keeps several backups on your disks for example 4 a day for 30 days so you can solve a possible database problem with the preferred copy not always the latest.
It can run in automatic loaded and started at startup or manual mode and can run your backup tasks whenever you want with the Execute now! Incremental backups are multi-level. That means if you do a Level 2 backup every day and a Level 3 backup every hour, each Level 3 backup contains all pages changed from the beginning of the day till the hour when the Level 3 backup is made. Stream database pages having SCN larger than was found at step 2 to the backup file. Write the GUID of the previous-level backup to the header, to enable the consistency of the backup chain to be checked during restore.
In the Firebird 2. This improvement was backported to V. Tracker reference CORE
0コメント