Re: Backup with Dump very slow

From: Ryoko (ryoko_at_-no-spam-.talk21.com)
Date: 10/18/04

  • Next message: David Bernard: "Re: Backup with Dump very slow"
    Date: 18 Oct 2004 07:50:43 GMT
    
    

    "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#


  • Next message: David Bernard: "Re: Backup with Dump very slow"

    Relevant Pages

    • Re: Backup advice
      ... methodology but the restore methodology. ... Some backup solutions will copy the files as separate files. ... Dump seems to be the best at doing what I'm looking to do. ... Try dropping one of those drives on a hard floor ...
      (freebsd-questions)
    • Linux backup
      ... the Linux and 'dump' don't play well together. ... backup system that uses 'dump' for our unix machines. ...
      (RedHat)
    • FW: Ufsdump to remote tape device
      ... Ufsdump to remote tape device ... but for the last 4 days 1 particular filesystem always fails ... The backup script has about 20 different local mount points that get ... DUMP: Writing 32 Kilobyte records ...
      (SunManagers)
    • Secure backups with GPG: local SCSI tape with DUMP, two remote streaming backups using MKISOFS and T
      ... I have tested using GnuPG to encrypt and decrypt a filesystem backup using ... INTERACTIVE restore function always failed due to the way that UFSRESTORE ... Unix DUMP) and later decrypt and restore this encrypted backup. ...
      (comp.unix.bsd.freebsd.misc)
    • Re: dump(8), incremental backups, Tower of Hanoi sequence, dont get it
      ... >>meaning of that modified Tower of Hanoi algorithm descibed in the ... Try to figure out for each backup whether the same files will ... > starting dump. ... You'll see that wherever you stop in that sequence, ...
      (freebsd-questions)