On Wed, 2003-07-30 at 17:22, Leyne, Sean wrote:

> Jim,
>
> > While we're in the area, has anyone given any thought to
> > creating a UID at database creation time that could be
> > stored on the header page and used as the root for the
> > database lock tree? This would be a very nice
> > (though partial) solution to the database alias problem.
>
> Yes, me! ;-)
>
> I thought of this when Nickolay and I were discussing the implementation
> of the new backup scheme, which prompted the whole delta/difference file
> discussion.
>
> The UID came up as a way to ensure that an incremental backup could only
> be applied to the master database with the same UID -- nothing like
> applying the wrong backup to really trash a database!!!
>
> In fact, as UID should probably be used identify the last incremental
> backups made for a database -- with each backup getting a UID. The
> database would then track the UIDs of most recent/valid
> incremental/valid backups.

It could be just as bad to apply a set of incremental restores in the
wrong order or an old set, perhaps a multi-part UIDs one that identifies
the master database, the series and the increment, something like this:

struct backup_id {
unsigned long master_uid; // set from a generator in fbsecurity.fdb
unsigned short backup_id; // increments on each full backup
unsigned short increment_id; // increments on each incremental backup, 0
on full
};


This would assign each backup a unique id, where the backup tool can
make sure that the right set is applied to the right database in the
right order. Can we find 8 bytes on the header page?

As you create databases, the master_uid would get incremented, an old
database that didn't have this set would get an id on the first backup.
Multi-file databases would all have the same master_uid. Initially
backup_id and increment_id would be 0, when you do a full backup we
increment the backup_id, if you do an incremental backup we use the same
backup_id and increment the increment_id. This would allow 65535
increments, 65535 series and 4billion+ unique databases. The backup_id
would simply roll over, it's doubtful that you would keep a backup long
enough for it to be a problem. Realistically you shouldn't need more
then about 31 increments, most people would say more then 5 is enough to
be a pain in the asp. However if someone wants to do a nightly
incremental backup 65534+ times, it should be possible to do it.

A Restore would check the master_id and the backup_id, if they do not
match it fails, unless you use a command line switch to force the
restore. If the incremental_id on the database is not 0, then it asks
for the increments, again you can force it to ignore the remaining
increments at one point. You can not skip one however, and can not
change the order, it's an all or nothing proposition.

PaulS