> Marcus: not Steve, but a little bit of knowledge i'd like to share:
> -when storing documents inside the database by using blobs, the only
> real problem is the time a backup or restore of the database needs.
> And the performance depends on several variables, such as what type of
> hard disk, raid - and what type of raid, database and backup on separate
> disks or even on separate engines, network,....
> as you can see - a lot of parameters have influence to that 'problem'.

Thank you for this. As my requirement is to have a store of documents relating to different projects, probably the best thing is to have a separate data file (.fdb) for each project. That will make the files much smaller and also I can have frequent backups for 'active' projects and less frequent backups for archive projects.

> One possible strategie would be to store metadata and only store links
> to the documents.

I would like to avoid this if possible because in a sense I would be using the Firebird database as a container.

>> For example I thought it was possible to shutdown the server and use operating system services (i.e. SCP?) to copy the file?

> That would be a save copy, but you'll never be shure if the database
> structure is fine. A possibility would be to copy the database to
> another server and perform a backup/restore cycle there.

As mentioned above, I think I will get around the problem by splitting the databases into smaller chunks.

However out of interest, would it be possible to do something like a gfix verification and possibly sweep after copying to check the integrity of the copied file or is this just as slow?

>
>
> Many thanks...Mick
>
>
>