Well, I have tested our restore on a Windows Server that is the exact same hardware that normally runs Fedora release 7. The resulting speed difference is astounding. I was able to restore our database in just over 3 hours vs 36 hours that this exact machine took under Fedora.

If we are able to move all our scripts over into Windows Powershell then we will be making this switch. I am very sad that I have had this problem for so long and have not switched to a different OS earlier.

Still, I would like the flexibility to switch back if ever needed. The length of backup/restore for this is just unworkable atm.

--- In firebird-support@yahoogroups.com, "andreas_kc" <andreas_kc@...> wrote:
>
> We are using a page size of 16384. Backup speed is pretty good. It takes 3 hours to backup a 60GB database. This includes the time needed to send it over CIFS on gigabit Ethernet.
>
> Restore speed on the other hand is awful. Restores take between 28-36 hours. When observing the machine during a restore, it seems real suspicious that CPU/Drive usage is so low during the two tables we use to store large blobs vs the other tables that stream out fast enough to keep CPU/Drives at 100%. About 25GB out of the 60GB Total comes from these two tables and they take about 75% of the restore time.
>
> Machine Specs
>
> Fedora release 7 (Moonshine) Redhat Tikanga 5
> FirebirdSS-2.1.3.18185-0.i686.rpm
> Dell Poweredge Server 1750, Dual P4-Xeon 3.0, 3GB Ram, Direct Attached SCSI U320 RAID10 500GB
>
> It would be great if the restore speed was even twice as long as backup (6 hours), but I could probably live with it around 12-20 hours. I've had a slew of corrupted databases over 4 different machines this year and I am getting very frustrated by that and the downtime required to correct it =(
>
> Regards,
>
> Andy
>
> --- In firebird-support@yahoogroups.com, "Carrell Alex" <Alex.Carrell@> wrote:
> >
> > I have not seen anyone reply.
> >
> > So I wonder what the page size of the database is?
> >
> > We have a database for blobs, specifically files around 2-12mb. It was slow reading / writing long ago. I changed the page size from 2048 through to 16384. I played with 8096, but found 16384 to work well, given the Ram restraints I had at the time. Very noticeable change in performance. The change used more disk space but that did not matter.
> > Backup restore of these tables ~10gb per year is not v slow. about 2 hours, on a 6 year old machine, xeon 1.8ghz x2 (hypethreaded to 4), 3gb ram. On a moderen machine (double everything), the databases restore in is in =< hour, over fibre channel to a san.
> >
> > alex
> > This message and any attachments (the message) are intended solely for the addressees and are
> > confidential. If you receive this message in error, please delete it and immediately notify
> > the sender. Any use not in accordance with its purpose, any dissemination, copying or disclosure,
> > either whole or partial is prohibited without prior formal approval. The internet cannot
> > guarantee the integrity of the message. The companies of Bobst Group do not accept any liability
> > for data corruption, delay, interception or any modification in relation with this message.
> >
>