>John Drescher wrote:
>
> > Are you sure that the new database is indexed properly? Does it take
> > an unreasonably long time to generate the file list for a restore?
If
> > so this is a sign that the database needs indexed.
>
> The restore time is quite ok. It's the backup that takes extremely
John Drescher wrote:
> Are you sure that the new database is indexed properly? Does it take
> an unreasonably long time to generate the file list for a restore? If
> so this is a sign that the database needs indexed.
The restore time is quite ok. It's the backup that takes extremely long.
/m
On 8/26/06, Marco <[EMAIL PROTECTED]> wrote:
> Just to add more probably relevant info:
>
> The backup medium is an external USB 2.0 disk. It has not changed in the
> time between the high performance with version 1.38.5 and the low
> performance with the current version 1.38.11.
>
> The DB is sqli
Just to add more probably relevant info:
The backup medium is an external USB 2.0 disk. It has not changed in the
time between the high performance with version 1.38.5 and the low
performance with the current version 1.38.11.
The DB is sqlite which served well form months before. I had to create
Marco wrote:
I found out more:
The server internal backup took more than 12 hours (585 KB/s). Before the
upgrade it
was less than 2 hours (4000 KB/s).
During the backup of the client I notice the there is only sporadic short
transfer phases from client to server. Between the transfer there are g
Hello,
I upgraded from 1.38.5 to 1.38.11 on a Debian server. At the same time I
configured FD of the same version on a Kubuntu laptop.
When the laptop was running 1.38.5 under winXP the backup had a rate of
1780KB/s. Now the same laptop does not get over 57KB/s.
I don't have the values for the s
