| Subject | Re: [firebird-support] GBAK and NBAK restore |
|---|---|
| Author | Mark Rotteveel |
| Post date | 2018-09-13T09:38:15Z |
On 13-9-2018 11:14, hugo.larson@... [firebird-support] wrote:
etc) + per table its data), and a restore writes an entirely new
database with the same data, but it can be in a different order and
location than in the original database (eg the rows of a table that were
spread out over the database, are now grouped close together).
On the other hand nbackup creates a physical backup of the data pages
(simplified: just the bytes in the database pages without knowledge of
what those bytes mean). It backs up all data pages changed since the
last backup of the 'higher' backup level. And a restore just writes
those bytes back (first writing the level 0, then overwriting that with
the changed pages in the latest level 1, then with the latest level 2, etc).
These two types of backups are not compatible. A database restored using
gbak has **all** its data pages written as new, so if such a restored
database would retain its nbackup information, any subsequent backup (at
any level) would still be the equivalent of a full backup on level 0.
This would even have the crippling effect that if - for example - you
make a level 1 backup each month, a level 2 each week and a level 3 each
day, that the daily backup (level 3) would be a full backup (level 0)
equivalent each day until a level 2 backup (weekly) would be made, which
would then be a full back each week until a new level 1 backup is made ,
which would then be a full back up until a new level 0 back up is made,
etc. Better to force you to formally create a new backup on level 0,
etc, than to waste space and time like that.
Similarly, a database ODS upgrade by backup and restore can only be done
by gbak, not by nbackup. A database ODS changes the database structure
of both metadata tables and possibly the physical layout of data in
tables and blobs. The way nbackup works is not suitable for that
(because it just deals with data pages and the bytes in them without
assigning further meaning).
And given the above described limitations, you will need to create a new
level 0 backup after upgrading the ODS of the database.
Mark
--
Mark Rotteveel
> We have hundreds of Firebird SQL 2.5 running at customers site (shops)GBAK creates a logical backup (a description of the database (tables
> with limited Internet bandwidth. The application is a POS system.
> For backup we use incremental NBAK and send the N file to a remote host
> which are restored on the server to display sale statistics etc.
>
> When restoring a database with GBAK the backup history in
> RDB$BACKUP_HISTORY is gone.
> Are we forced to restart NBAK or can somehow the N backup files on the
> remote host be reused and continue the incremental backup?
>
> Another thought. We have plan to migrate to FB 4 when it's released.
> To upgrade here also a GBAK has to preformed and restored in FB 4.
> The question here is also if the database files on the remote host can
> be "upgraded" and continue the incremental backup?
>
> The database file on sites is hundreds om MB and we rather not restart
> the incremental backup.
>
> I appreciate any advice on this issue.
etc) + per table its data), and a restore writes an entirely new
database with the same data, but it can be in a different order and
location than in the original database (eg the rows of a table that were
spread out over the database, are now grouped close together).
On the other hand nbackup creates a physical backup of the data pages
(simplified: just the bytes in the database pages without knowledge of
what those bytes mean). It backs up all data pages changed since the
last backup of the 'higher' backup level. And a restore just writes
those bytes back (first writing the level 0, then overwriting that with
the changed pages in the latest level 1, then with the latest level 2, etc).
These two types of backups are not compatible. A database restored using
gbak has **all** its data pages written as new, so if such a restored
database would retain its nbackup information, any subsequent backup (at
any level) would still be the equivalent of a full backup on level 0.
This would even have the crippling effect that if - for example - you
make a level 1 backup each month, a level 2 each week and a level 3 each
day, that the daily backup (level 3) would be a full backup (level 0)
equivalent each day until a level 2 backup (weekly) would be made, which
would then be a full back each week until a new level 1 backup is made ,
which would then be a full back up until a new level 0 back up is made,
etc. Better to force you to formally create a new backup on level 0,
etc, than to waste space and time like that.
Similarly, a database ODS upgrade by backup and restore can only be done
by gbak, not by nbackup. A database ODS changes the database structure
of both metadata tables and possibly the physical layout of data in
tables and blobs. The way nbackup works is not suitable for that
(because it just deals with data pages and the bytes in them without
assigning further meaning).
And given the above described limitations, you will need to create a new
level 0 backup after upgrading the ODS of the database.
Mark
--
Mark Rotteveel