Hello, Bob! Sunday, October 13, 2013, 8:21:12 AM, you wrote:
BM> Do you have any other tips for getting the best performance during backup BM> and restore? Our current situation is a backup of the production database BM> on server1 intiated on server2, with the backup file residing on server2. BM> Server2 initiates the restore (using service manager), with the database BM> being stored on the same disk array as the backup file. BM> A 113GB production database produces a backup file of 99GB, and a newly BM> restored database of 108GB. This entire process takes almost 48 hours. oops. As I know (from our test), backup and restore are disk bound, and does not depend on Firebird cache size or db page size, etc. First, yes, the fastest way to backup and restore is to use Services API (gbak -se ...). On Linux same results will be using local protocol (db name and path without server name). Second, you need to have all timings to understand how much time these processes takes. I mean backup restore restore with -i. Usually restore takes 3-5 times longer than backup. Third, when making backup over network (as I understood), you need to be sure that network is faster than making backup to disk. Otherwise you are wasting time. restore with -i option is needed to understand: - how fast data is being restored. I can't find data right now, but seems that this must be close to the backup time. - how fast/slow indices are being created during restore. Here maybe you need to reconfigure TEMP settings (point it to fast disk), to check (and maybe delete) indices with very bad selectivity, etc. And, the last one - to compare this with other results. For example, one system I have data right now makes backup 30 minutes and restore 4 hours on 36gb database. These numbers are for single-user mode, and worse for "online" - backup takes 2 hours. Something like this. :-) -- Dmitry Kuzmenko, www.ib-aid.com
