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

good backups gone bad

Expand Messages
  • seekinshome
    I have noticed two bugs with the backups: (1) if the backup fails for an aborted cause (e.g. Maximum errors occur in job Basement G , job is aborted. ).
    Message 1 of 2 , Sep 28, 2004
      I have noticed two bugs with the backups:

      (1) if the backup fails for an "aborted" cause (e.g. "Maximum errors
      occur in job 'Basement G', job is aborted."). The job will not
      restart at the next scheduled time. Also, it cannot be edited,
      deleted, or manually restarted. The only way around this is to soft-
      power cycle the unit. Also, any new backups that use the same folder
      cannot be scheduled, and will not start if already scheduled. Bummer.
      Anyone confirm?

      (2) Every once in a while, I get a strange error (or multiple) in an
      otherwise normal backup. For example:
      "Error occurs in job 'Basement G', cannot access source
      file '//Seekins/basement_g/OLD_H_DRIVE/Pictures/Noah/121499/DSC00003.j
      pg'. " Even though it backed up all the new files on the drive, this
      old file had a problem? I verified that the source file is present,
      and readable. The machine it is backing up is an old P3 1.4G running
      Windows 98. Anyone else?

      I'm going to try to see what happens when the target PC is not
      powered up when the NSLU2 starts a scheduled backup to/from it.
      Hopefully it will not result in scenario #1 above.

      Does anyone from Linksys monitor this forum? Do they even care about
      all these bugs we see?
    • Ian White
      Yep, I can confirm problem (1) I had three backups aborted last night because they ended up running concurrently due to slow network access to backup target
      Message 2 of 2 , Oct 7, 2004
        Yep, I can confirm problem (1)
        I had three backups "aborted" last night
        because they ended up running concurrently
        due to slow network access to backup target share

        I could not edit or restart or delete them
        And because I am running unslung 1.11-beta
        a soft or hard power-cycle did not clear the problem

        So I telnet'd-in and grubbed around to find
        /share/hdd/conf/etc/mnt/backup to discover
        a directory named after each backup job and
        a file called <backup>.pid which appeared to hold
        the process ID of the /usr/sbin/backup (I think) process
        that failed

        I deleted the direcory + file and lo-and-behold
        my backup jobs were editable again

        I can *NOT* confirm the latter problem because
        I'm running 3 x XP Pro and 1 x XP Home
        (XP Home replaced Win98SE)

        Cheers
        Ian W.

        --- In nslu2-general@yahoogroups.com, "seekinshome" <dlseek@h...>
        wrote:
        >
        > I have noticed two bugs with the backups:
        >
        > (1) if the backup fails for an "aborted" cause (e.g. "Maximum
        errors
        > occur in job 'Basement G', job is aborted."). The job will not
        > restart at the next scheduled time. Also, it cannot be edited,
        > deleted, or manually restarted. The only way around this is to soft-
        > power cycle the unit. Also, any new backups that use the same
        folder
        > cannot be scheduled, and will not start if already scheduled.
        Bummer.
        > Anyone confirm?
        >
        > (2) Every once in a while, I get a strange error (or multiple) in
        an
        > otherwise normal backup. For example:
        > "Error occurs in job 'Basement G', cannot access source
        >
        file '//Seekins/basement_g/OLD_H_DRIVE/Pictures/Noah/121499/DSC00003.j
        > pg'. " Even though it backed up all the new files on the drive,
        this
        > old file had a problem? I verified that the source file is present,
        > and readable. The machine it is backing up is an old P3 1.4G
        running
        > Windows 98. Anyone else?
        >
        > I'm going to try to see what happens when the target PC is not
        > powered up when the NSLU2 starts a scheduled backup to/from it.
        > Hopefully it will not result in scenario #1 above.
        >
        > Does anyone from Linksys monitor this forum? Do they even care
        about
        > all these bugs we see?
      Your message has been successfully submitted and would be delivered to recipients shortly.