Firebird - Check backup integrity #7932
-
|
We are using Firebird 2.5.* and we use the GBAK.exe command to Backup and Restore the databases. A case of backup restoration occurred, where the user selected an incorrect file to restore from the backup (an XML file, for example) - an error occurred in GBAK, but it corrupted the database. I didn't find in the Firebird/GBAK documentation a parameter to check the integrity of the Backup (without performing the restore). I would like to know if there is any way to check if the Firebird backup file "is valid", without actually restoring the backup. Use the GBAK.exe command to check the integrity of the backup, without having to restore. This way we can validate that the backup file is valid, before proceeding with the restoration. |
Beta Was this translation helpful? Give feedback.
Replies: 10 comments 12 replies
-
|
No, there is no way to check backup file validity. What "database corruption" did you see? Target database during restore is created from scratch, it is a brand-new database. gbak doesn't overwrite existing database file unless explicitly asked for it. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the informations. When you said "corrupted database" that's exactly why you explained it. We are using the -REP option of GBAK, to overwrite an existing database - and when the backup file is invalid (in the case of the example I mentioned about XML) this new, zeroed-out database is invalid... "Destroyed", so to speak, the original database... This is why I would like to verify that the backup file is a valid file. |
Beta Was this translation helpful? Give feedback.
-
|
Using -REP option is the way to suicide. Just don't do it. Even if Firebird team fix problem with XML files delaying creation of database till the moment when backup file is parsed up to header at least - any problem with disk, network or electricity in the middle of restore will leave you without database. |
Beta Was this translation helpful? Give feedback.
-
|
Okay... What would be the guidance then? For context - we are restoring a backup of a database of our system, on top of the existing database. The idea is to overwrite the data from the current database with the backup. That's why we are using the -REP option |
Beta Was this translation helpful? Give feedback.
-
|
As I said on Stack Overflow, use |
Beta Was this translation helpful? Give feedback.
-
As I said: just don't do it. If all you need is "to overwrite data in database" then you don't care about data so its corruption should not bother you. Teach the person who type gbak command to check that they chose a right file next time. Or fire them and automate the process. |
Beta Was this translation helpful? Give feedback.
-
|
NB: cross-posted on https://stackoverflow.com/questions/77691542/how-to-check-backup-integrity |
Beta Was this translation helpful? Give feedback.
-
Gbak could be more intelligent if asked to replace overwrite the database:
|
Beta Was this translation helpful? Give feedback.
-
|
(@aafemt) |
Beta Was this translation helpful? Give feedback.
-
|
That would double the use of disk space. |
Beta Was this translation helpful? Give feedback.
-
|
Yes it would, but it will protect against this specific scenario. Currently, we have |
Beta Was this translation helpful? Give feedback.
-
|
On 12/20/23 17:54, Mark Rotteveel wrote:
Using -REP option is the way to suicide. Just don't do it.
Even if Firebird team fix problem with XML files delaying creation
of database till the moment when backup file is parsed up to
header at least - any problem with disk, network or electricity in
the middle of restore will leave you without database.
Gbak could be more intelligent if asked to replace overwrite the database:
1. Connect to the database and shut it down to single connection mode
2. Restore the backup to a temporary filename in the same directory
as the original database (could be problematic when restoring to
an alias though)
3. When the restore completes successfully, drop the original
database and rename the temporary filename to the permanent filename
Suppose we solved issues with alias, disk space, etc. How do you suggest
to rename a file on remote server? (which normally should not provide
file-level access to remote cliens)
|
Beta Was this translation helpful? Give feedback.
-
|
I see two potential options:
|
Beta Was this translation helpful? Give feedback.
-
|
Mark, may be I was not enough explicit. While windows typically has (or
at least had earlier - not sure for current versions) always present
shared like C$, D$, etc. linux normally does not provide file-level
access at all. And even if it does - what type of share is present? SMB
or may be NFS or DavFS or something else? I doubt auto-renaming file
makes sense except probably windows, but even in that last case server
may be out of direct reach for SMB for very many reasons.
The only way to make something useful is separate API call (closing DB
attachment) which safely renames current database to another name and
closes attachment to it.
|
Beta Was this translation helpful? Give feedback.
-
|
That's IMHO not relevant. If you do a remote restore, you're connecting to the server, and the server can take care of renaming the file. And if you handle it through the service API, which was my other suggestion, then the server is entirely in control, including deciding on the temporary filename and the rename or move operation. In neither case would you need remote filesystem access to achieve this, so I'm not sure why you're bringing it up. |
Beta Was this translation helpful? Give feedback.
-
|
Yep, I've answered you previous suggestion :) Why I've told about API call? Use of services only certainly will work but is very limited solution. SQL statement to rename primary DB file is possible but we have a number of dependencies from primary file name (like shared memory files' names) that I'm much afraid keeping SQL access to renamed on the fly database is a can of worms - someone will try to use it outside gbak... That's why API call forcefully closing DB is IMO preferred here. |
Beta Was this translation helpful? Give feedback.
-
|
I'm brainstorming potential ways to implement it, I'm not saying it is the way it should ultimately be implemented. And yes, maybe this feature is not that important (most of it can be solved with a carefully written shell script or batch file). And IMHO, the SQL statement could below the surface, server-side close the DB, rename the file, reopen the new DB while preserving the connection/DB handle itself (though all transaction, statement, blob, etc. handles of the connection will now be invalid, so as if there is a new connection), or it could close the DB, (try) to rename it and report error or success and then close the connection. The client executing the statement will then have to establish a new connection to continue. |
Beta Was this translation helpful? Give feedback.
-
|
However, more important might be that before the old database is dropped, at least a token effort should be made to check if the backup file is actually a backup file. Sure, there will still be failure scenarios that might result in an unusable database, but at minimum checking if the backup at least has the right backup header could prevent the very simple and basic failure scenario presented in the TS. |
Beta Was this translation helpful? Give feedback.
-
What limitation do you see? Client-side backup must die anyway because of its slowness and problem with verbose output can be solved with multi-stream service output that we discussed earlier. |
Beta Was this translation helpful? Give feedback.
-
|
On 12/20/23 19:10, Dimitry Sibiryakov wrote:
Use of services only certainly will work but is very limited solution.
What limitation do you see? Client-side backup must die anyway
What about downgrading ODS?
because of its slowness
Have you checked speed of restore over the wire in FB4?
… and problem with verbose output can be solved with multi-stream
service output that we discussed earlier.
—
Reply to this email directly, view it on GitHub
<#7932 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA44OUMMS3F7IPSIOS5PD2TYKMEY7AVCNFSM6AAAAABA4XZKCSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TSMBZHE3TI>.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
It never worked reliably.
It is good but still slower that fbsvcmgr with stdout/in. |
Beta Was this translation helpful? Give feedback.
-
|
I'm closing this discussion as resolved, because my main question about "How to check backup integrity" has been resolved.
I would like to thank everyone for their attention and their commitment to helping. |
Beta Was this translation helpful? Give feedback.
No, there is no way to check backup file validity. What "database corruption" did you see? Target database during restore is created from scratch, it is a brand-new database. gbak doesn't overwrite existing database file unless explicitly asked for it.