Loading ...
Sorry, an error occurred while loading the content.
 

Re:PC backup: slow as a slug? [was: rsync does not log files transfered

Expand Messages
  • Dave Hrynkiw
    I ve been using rdiff-backup for a few months on my Slug to mirror my office files. My office server is a 800MHz POS with 120G on hardware RAID. The initial
    Message 1 of 5 , Apr 3, 2007
      I've been using rdiff-backup for a few months on my Slug to mirror my
      office files. My office server is a 800MHz POS with 120G on hardware
      RAID. The initial backup took forever (even when as part of the local
      network), and my remote backups are long, but not unmanagable.

      I time my backups, and a quick scan shows anywhere from 60 to 141
      minutes to do the incremental this week, and that's over a 50kB/s line.
      Lessee... More specifically, here's a sample of my output file from my
      last backup:

      > --------------[ Session statistics ]--------------
      > StartTime 1175587809.00 (Tue Apr 3 02:10:09 2007)
      > EndTime 1175590775.44 (Tue Apr 3 02:59:35 2007)
      > ElapsedTime 2966.44 (49 minutes 26.44 seconds)
      > SourceFiles 159093
      > SourceFileSize 94561243772 (88.1 GB)
      > MirrorFiles 159062
      > MirrorFileSize 94539721814 (88.0 GB)
      > NewFiles 97
      > NewFileSize 32308215 (30.8 MB)
      > DeletedFiles 66
      > DeletedFileSize 11631215 (11.1 MB)
      > ChangedFiles 66
      > ChangedSourceSize 108254171 (103 MB)
      > ChangedMirrorSize 107409213 (102 MB)
      > IncrementFiles 230
      > IncrementFileSize 10946266 (10.4 MB)
      > TotalDestinationSizeChange 32468224 (31.0 MB)
      > Errors 0
      > --------------------------------------------------
      Sure, the PC/Slug spend a fair amount of time chugging on the calcs, but
      at 2am, I don't care. rdiff-backup does a pretty good job at
      automatically archiving everything on my 320G backup drive, which is
      only 54% full from October 6 '06.

      Works quite well.

      Regards,
      Dave
    • John
      Dave, Interesting. According to its web description, rdiff-backup avoids the painfully slow cp -a --link step that bogs down rsnapshot on my slug. How long
      Message 2 of 5 , Apr 3, 2007
        Dave,

        Interesting. According to its web description, rdiff-backup
        avoids the painfully slow "cp -a --link" step that bogs down rsnapshot
        on my slug.

        How long does e2fsck take on your slug?

        John
      • tim_higgins13
        Hi there I just got Rsnapshot working on my SLUG for incremental backups but I have also read that rdiff is better (more efficient?)..... With rdiff only parts
        Message 3 of 5 , Apr 4, 2007
          Hi there

          I just got Rsnapshot working on my SLUG for incremental backups but I
          have also read that rdiff is better (more efficient?).....

          With rdiff only parts of a modified file are transferred, however with
          rsync the entire modified files are transferred correct?

          Are there any instructions for getting a backup process setup using
          rdiff on the NSLU2 or is rsnapshot the best approach for now?

          Tim



          --- In nslu2-linux@yahoogroups.com, Dave Hrynkiw <dave@...> wrote:
          >
          > I've been using rdiff-backup for a few months on my Slug to mirror my
          > office files. My office server is a 800MHz POS with 120G on hardware
          > RAID. The initial backup took forever (even when as part of the local
          > network), and my remote backups are long, but not unmanagable.
          >
          > I time my backups, and a quick scan shows anywhere from 60 to 141
          > minutes to do the incremental this week, and that's over a 50kB/s line.
          > Lessee... More specifically, here's a sample of my output file from my
          > last backup:
          >
          > > --------------[ Session statistics ]--------------
          > > StartTime 1175587809.00 (Tue Apr 3 02:10:09 2007)
          > > EndTime 1175590775.44 (Tue Apr 3 02:59:35 2007)
          > > ElapsedTime 2966.44 (49 minutes 26.44 seconds)
          > > SourceFiles 159093
          > > SourceFileSize 94561243772 (88.1 GB)
          > > MirrorFiles 159062
          > > MirrorFileSize 94539721814 (88.0 GB)
          > > NewFiles 97
          > > NewFileSize 32308215 (30.8 MB)
          > > DeletedFiles 66
          > > DeletedFileSize 11631215 (11.1 MB)
          > > ChangedFiles 66
          > > ChangedSourceSize 108254171 (103 MB)
          > > ChangedMirrorSize 107409213 (102 MB)
          > > IncrementFiles 230
          > > IncrementFileSize 10946266 (10.4 MB)
          > > TotalDestinationSizeChange 32468224 (31.0 MB)
          > > Errors 0
          > > --------------------------------------------------
          > Sure, the PC/Slug spend a fair amount of time chugging on the calcs,
          but
          > at 2am, I don't care. rdiff-backup does a pretty good job at
          > automatically archiving everything on my 320G backup drive, which is
          > only 54% full from October 6 '06.
          >
          > Works quite well.
          >
          > Regards,
          > Dave
          >
        • Phil Endecott
          ... Incorrect. The whole point of rsync is that it will identify portions of the new file that were also present in the old file and not transmit them. Phil.
          Message 4 of 5 , Apr 4, 2007
            Tim wrote:
            > with rsync the entire modified files are transferred correct?

            Incorrect. The whole point of rsync is that it will identify portions
            of the new file that were also present in the old file and not transmit them.


            Phil.
          • Dave_Hrynkiw
            ... 320G in about 1/2 an hour. It s live, so I ran it with -n . Here s the output: slug:/mnt/320g# time e2fsck -n /dev/sda3 e2fsck 1.40-WIP (14-Nov-2006)
            Message 5 of 5 , Apr 4, 2007
              --- In nslu2-linux@yahoogroups.com, John <jl.050877@...> wrote:
              >
              > Dave,
              >
              > Interesting. According to its web description, rdiff-backup
              > avoids the painfully slow "cp -a --link" step that bogs down rsnapshot
              > on my slug.
              >
              > How long does e2fsck take on your slug?

              320G in about 1/2 an hour. It's live, so I ran it with "-n". Here's
              the output:

              slug:/mnt/320g# time e2fsck -n /dev/sda3
              e2fsck 1.40-WIP (14-Nov-2006)
              Warning! /dev/sda3 is mounted.
              Warning: skipping journal recovery because doing a read-only
              filesystem check.
              /dev/sda3 contains a file system with errors, check forced.
              Pass 1: Checking inodes, blocks, and sizes
              Pass 2: Checking directory structure
              Pass 3: Checking directory connectivity
              /lost+found not found. Create? no

              Pass 4: Checking reference counts
              Pass 5: Checking group summary information
              Free blocks count wrong (39320982, counted=37929442).
              Fix? no

              Free inodes count wrong (38622333, counted=38575121).
              Fix? no


              /dev/sda3: ********** WARNING: Filesystem still has errors **********

              /dev/sda3: 306051/38928384 files (3.1% non-contiguous),
              38513943/77834925 blocks

              real 31m49.403s
              user 5m21.800s
              sys 7m44.290s
            Your message has been successfully submitted and would be delivered to recipients shortly.