| Subject | Re: [firebird-support] nbackup questions |
|---|---|
| Author | Paul Vinkenoog |
| Post date | 2014-01-16T03:04:56Z |
Hello Maury,
- The delta (containing the changes since May last year) will be re-integrated with the main database file (.fdb).
- Upon success, the delta will be deleted and the state flag of the database file set back to normal.
Then, you should make a regular backup with gbak and restore that on your target machine (using gbak on your target machine).
I have no idea how much time re-integrating a 70 MB delta will take. Is it a problem if it takes several hours? (Not that I expect this.)
As for copying the current .fdb and .delta to your target machine:
- Copying the .fdb is safe - IN THIS CASE! - because the file is frozen and closed. (Under normal circumstances, copying an .fdb file is unsafe, unless you take special precautions.)
- Copying the .fdb.delta may be unsafe because its a live database file. Even if no users are connected to it, the 'hidden' user (or SYSDBA) may be connected from within Fishbowl. Can you stop Fishbowl completely? And then check if no process has the .delta file open. Then it may be safe (and even wise) to copy the two files to your target machine, just in case. (Note: if the source and target machine have a different platform architecture, straight file copies may not work on the target machine. If they have different endianness, straight file copies are *guaranteed* not to work.
Cheers,
Paul Vinkenoog
> So a little Google-fu was all that took. Now armed with the credentials, what would be the next steps at this point?If you connect to the database and issue ALTER DATABASE END BACKUP:
>
> I suspect the next step is to END BACKUP. However, I wish to tread carefully... I don't have a backup newer than last May, the existing FDB is not a usable file as far as the new machine is concerned, etc.
>
> So, what exactly happens when you do the END BACKUP? Does the server have to fold the delta into the original FDB? If so, I suspect this is a long-running task given the size of the file? Or is this a much simpler task, simply renaming the files or such?
>
> If I first copy the original FDB and delta, if something goes wrong during END BACKUP will those files be useful to me? It does not appear the original FDB is a working database (at least I cannot connect to it), and I suspect the name "delta" is accurate so it is not a usable file by itself either. This seems to suggest (I know I know, ASSuME) that simply copying these files to offline storage gets me basically nothing?
- The delta (containing the changes since May last year) will be re-integrated with the main database file (.fdb).
- Upon success, the delta will be deleted and the state flag of the database file set back to normal.
Then, you should make a regular backup with gbak and restore that on your target machine (using gbak on your target machine).
I have no idea how much time re-integrating a 70 MB delta will take. Is it a problem if it takes several hours? (Not that I expect this.)
As for copying the current .fdb and .delta to your target machine:
- Copying the .fdb is safe - IN THIS CASE! - because the file is frozen and closed. (Under normal circumstances, copying an .fdb file is unsafe, unless you take special precautions.)
- Copying the .fdb.delta may be unsafe because its a live database file. Even if no users are connected to it, the 'hidden' user (or SYSDBA) may be connected from within Fishbowl. Can you stop Fishbowl completely? And then check if no process has the .delta file open. Then it may be safe (and even wise) to copy the two files to your target machine, just in case. (Note: if the source and target machine have a different platform architecture, straight file copies may not work on the target machine. If they have different endianness, straight file copies are *guaranteed* not to work.
Cheers,
Paul Vinkenoog