"Ryoko" <ryoko@-no-spam-.talk21.com> wrote in message
news:Xns95865A31F7376ryokosan@195.129.110.67...
> "David Bernard" <jerrydav@hotmail.com> wrote in
> news:NPFcd.23985$H45.616896@weber.videotron.net:
>
> > I have a small personnal server running OpenBSD 3.4 and tried for the
> > first time the "dump" utility to backup a 4 GB partition towards a
> > local network share (mounted with sharity-light). The backup
> > throughput is extremely slow, around 80 MB per hour!! Is there a way
> > to speed things up even if "dump" has been designed to use tape
> > drives? Do you think "rsync" will be faster?
>
> I don't think that dump is the bit that is being slow - but there are
> many factors.
>
> On a faily new pc (i.e. 1GHz + loads of ram ...) I've successfully used
> dump 0f - (.....) | gzip | ssh remote_machine "dd
> of=backed_up_filesystem.dump.gz"
> to backup much larger disks than that
>
> What is your network connection ... and how efficient do you think
> sharity-light is? Is the server the bottle neck ...?
>
> break down what you are doing and time the steps.
> e.g. dump -0af /dev/null /dev/rd0g
>
> that will tell you how fast the dump is with no file creation ...
> then look at just copying 2 Gig or wahtever to your server via different
> mechanisms
>
> e.g. a dump of about 2 Gig completed in 7 mins
>
> naru# date; dump -0af /dev/null /dev/rwd0g; date
> Mon Oct 18 09:43:34 BST 2004
> DUMP: Date of this level 0 dump: Mon Oct 18 09:43:34 2004
> DUMP: Date of last level 0 dump: the epoch
> DUMP: Dumping /dev/rwd0g (/usr) to /dev/null
> DUMP: mapping (Pass I) [regular files]
> DUMP: mapping (Pass II) [directories]
> DUMP: estimated 2990343 tape blocks.
> DUMP: Volume 1 started at: Mon Oct 18 09:43:41 2004
> DUMP: dumping (Pass III) [directories]
> DUMP: dumping (Pass IV) [regular files]
> DUMP: 67.39% done, finished in 0:02
> DUMP: 3183113 tape blocks on 1 volume
> DUMP: Volume 1 completed at: Mon Oct 18 09:50:56 2004
> DUMP: Volume 1 took 0:07:15
> DUMP: Volume 1 transfer rate: 7317 KB/s
> DUMP: Date of this level 0 dump: Mon Oct 18 09:43:34 2004
> DUMP: Date this dump completed: Mon Oct 18 09:50:56 2004
> DUMP: Average transfer rate: 7317 KB/s
> DUMP: Closing /dev/null
> DUMP: DUMP IS DONE
> Mon Oct 18 09:50:56 BST 2004
> naru#


I broke down the whole process as you proposed, and realized the problem was
sharity-light who's doing really poor job and even freeze when transferring
huge files. I'll try to stabilize sharity-light and if it doesn't work, I'll
use something else. Thanks for you help!

David