rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] --check-destination-dir taking a very long time


From: Walt Mankowski
Subject: Re: [rdiff-backup-users] --check-destination-dir taking a very long time
Date: Mon, 9 Sep 2019 19:47:29 -0400
User-agent: Mutt/1.10.1 (2018-07-13)

On Mon, Sep 09, 2019 at 07:38:52PM -0400, Patrik Dufresne wrote:
> Hum, this is strange. It should not fail with a "no space left on device".

Agreed! That's why I originally thought it must have been some sort of
USB glitch.

> Could you provide the log generate with -v9 ? Plz provide the full command
> line you used.

So kill the run with -v8?

> What is the filesystem of your USB drive ?

ext4

> If you try to run the backup again do you have an error?

In fact that happened last night. My normal nightly backup kicked in
while a previous attempt at running --check-destination-dir was still
running. The cronjob reported:

  Previous backup seems to have failed, regressing destination now.
  Fatal Error: Killed with signal 15

The latter was when I killed it when I woke up and saw that both of
them were running.

Walt

> On Mon, Sep 9, 2019, 7:33 PM Walt Mankowski, <address@hidden> wrote:
> 
> > Good idea! But unfortunately it doesn't seem to be the problem:
> >
> > % df -hi /backup
> > Filesystem     Inodes IUsed IFree IUse% Mounted on
> > /dev/sde1        117M   19M   98M   17% /backup
> >
> >
> > On Mon, Sep 09, 2019 at 07:23:14PM -0400, Patrik Dufresne wrote:
> > > Hello Walt, could you double check the disk space. Especially the number
> > of
> > > inode ? It's probably the root cause of your issue.
> > >
> > > On Mon, Sep 9, 2019, 7:19 PM Walt Mankowski, <address@hidden> wrote:
> > >
> > > > I've been running rdiff-backup to an external USB drive for years
> > > > without any problems. Over the weekend my backup failed with
> > > >
> > > >   Exception '[Errno 28] No space left on device
> > > >
> > > > This is odd, since there is 1.2 TB free on the drive. I didn't see any
> > > > errors in syslog, and I was able to create a new file on the drive
> > > > without any problem.
> > > >
> > > > Thinking it might have been a USB glitch I rebooted the machine and
> > > > now I'm running
> > > >
> > > >   rdiff-backup --check-destination-dir
> > > >
> > > > to recover the backup directory. It was taking a very long time, and I
> > > > restarted it with the -v8 hoping I might get some clue as to what it
> > > > was doing. Unfortunately after spitting out some routine-looking
> > > > output in the first few seconds it's now been running in silence for
> > > > nearly 12 hours.
> > > >
> > > > It's getting CPU time and I don't see any errors in syslog, so I'm
> > > > assuming that it's doing something. But I don't have any idea what
> > > > it's doing, if it's working correctly, or how much longer it's likely
> > > > to take.
> > > >
> > > > Is it normal that a regression takes this long? /backup is currently
> > > > at 527 GB.
> > > >
> > > > Thanks.
> > > >
> > > > Walt
> > > >
> > > > _______________________________________________
> > > > rdiff-backup-users mailing list at address@hidden
> > > > https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
> > > > Wiki URL:
> > > > http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
> >
> > _______________________________________________
> > rdiff-backup-users mailing list at address@hidden
> > https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
> > Wiki URL:
> > http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki



reply via email to

[Prev in Thread] Current Thread [Next in Thread]