Alexandre Benson Smith wrote:

> ...
>>
>> BTW:
>> Testing backup and restore of the database with 140.000 images -
>> 7.5GB - which is about 1/40 of the total shows that backup takes
>> about 7-8 minutes (and so did restore). This means that backup (or
>> restore) of the full database will take about 5-6 hours.
>>
>
> Anyway I think NBACKUP would be a very good choice if you can go to FB
> 2.0, the amount of changed data will be quite small compared to a full
> back-up

Currently we use Fb/1.5.4 (SS on Windows).
I could probably get away with a monthly backup, with restore to a
new database on another disk/server. In case of a significant
failure I can switch users to the other database with a change in an
ini-file (a common file placed on the file server, and read by the
applications at start-up). And reloading images for the last month
will just take 10-20 minutes, I guess. We'll see...

> The speed you are talking about was a local gbak ?

Yes.

> Did you backed-up to the same disk/volume ? If so, would your volume has
> enough space to run a full gbak it when the database is in full size ?
> Did you measured backing-up to a different volume/controller/etc ? ( I
> think the speed should be a bit faster reading from one writing to another)

The database and backup were on different drives (sets of mirrored
drives, IIRC).
I'll probably use 2 x 500GB SATA drives (in a SAN box), and have
these mirrored (rather than use RAID-5) - a total of 4 physical disks.


Sean Leyne wrote:
<<
I would recommend page size of 32KB, which would be matched by a disk
cluster size of 32KB -- too truly maximize disk to memory transfer speeds.

>>

Is this possible? FlameRobin/0.7.6 doesn't offer more than 16KB.


--
Aage J.