>> From: firebird-support@yahoogroups.com
> [mailto:firebird-support@yahoogroups.com] On Behalf Of Dmitry Kuzmenko
>> Sent: Saturday, October 12, 2013 12:36 AM
>> To: firebird-support@yahoogroups.com
>> Subject: Re[2]: [firebird-support] Restore error during unique index
> creation
>>
>>
>> TS> * Running th restore through the Services API/Manager
>>
>> right, this is the fastest way.
>>
>> TS> * Provide a larger page cache upon restore, because especially the
> index
>> TS> creation step loves RAM. Don't forget to set the page buffers value
> back
>> TS> again at database-level after the restore via e.g. gstat. I've seen
>> TS> restore improvements of > 300% for largish indexes this way.
>>
>> This idea is useless. We have done complex restore
>> test, including specifying -bu nnn option, and found no difference
>> for cache size from 1024 to 16384 pages (classic and superserver),
>> for data only (-i) or full restore (data+indices).
>
> Dmitry -
>
> Do you have any other tips for getting the best performance during backup
> and restore? Our current situation is a backup of the production database
> on server1 intiated on server2, with the backup file residing on server2.

I would create the backup file on the same server as the production
database with the -se switch, ideally on a different physical disk.

After backing up, move it to another redundant backup server if you
wish. Also -g for suppressing garbage collection in the production
database might be an option if it is all about backup speed. You
probably do that already.

> Server2 initiates the restore (using service manager), with the database
> being stored on the same disk array as the backup file.

As said. Increasing -buffers while restoring isn't totally useless, but
worth to be tested in your environment, although for a start, possible
not on the 100GB database. ;-)

You could also serve the restore via a dedicated Firebird instance with
increased temporary storage module settings in firebird.conf to suppress
putting fb_sort* files while index creation onto disk and serve most of
the sorting requests via RAM, but as said in a previous post, index
creation is getting CPU bound on a single physical core pretty quickly.
So for that case, you'd better have better single core throughput than
e.g. scaleing up in regard to number of cores, but still, increasing the
page cache and temporary storage module settings are viable options.

> A 113GB production database produces a backup file of 99GB, and a newly
> restored database of 108GB. This entire process takes almost 48 hours.

--
With regards,
Thomas Steinmaurer
http://www.upscene.com/

Professional Tools and Services for Firebird
FB TraceManager, IB LogManager, Database Health Check, Tuning etc.