Re: [BackupPC-users] Serious error: last backup directory doesn't exist!!! Need to remove back to last filled backup

[backuppc]

gregrwm wrote at about 19:05:18 -0500 on Tuesday, June 14, 2022:
 > offhand i'm not really seeing why an interrupt would result in the loss of
 > a prior backup directory.  i'd be surprised to learn that a prior backup is
 > ever moved or renamed and thus subject to loss if interrupted, but what
 > else could it be?  if an existing backup directory is ever renamed or moved
 > i would consider that a design flaw worth correcting.  i would think it
 > preferable that once a backup directory gets it's number, it keeps it for
 > it's entire lifetime, no renames, no moves.

It's not surprising how it happens...
BackupPC4 (in contrast to BackupPC3) uses forward deltas.
Loosely speaking, one of the first thing it does when making a new backup is to
essentially renumber the old backup as the new backup and then as
files are added/changed/deleted from the new backup, add those as
deltas to the previously newest backup (in turn older backups may be
deltas to that from earlier backups).

So, if the current/new backup is irretrievably corrupted, then all
earlier backups that are deltas to it are non-recoverable as you found
out.

The question in your case (and in rare cases I have encountered myself
when similarly interrupting backups) is why is the newest/current
backup corrupted and/or why can't it be unwound back to the previous
backup when the backup is interrupted.

Hope this helps (without butchering how BackupPC really works :)

Jeff


___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

Re: [BackupPC-users] Serious error: last backup directory doesn't exist!!! Need to remove back to last filled backup

[gregrwm]

On Tue, Jun 14, 2022 at 5:25 PM G.W. Haywood via BackupPC-users <
backuppc-users@lists.sourceforge.net> wrote:

> Hi there,
>
> On Tue, 14 Jun 2022, gregrwm wrote:
> > ... interrupted BackupPC_dump.  on the next invocation i got:
> > 2022-06-12 21:35:02 Serious error: last backup
> > /var/lib/backuppc/pc/avocado/32 directory doesn't exist!!!  Need to
> remove
> > back to last filled backup
> > 2022-06-12 21:35:02 Deleting backup 14
> > 2022-06-12 21:35:08 Deleting backup 15
> > 2022-06-12 21:35:14 Deleting backup 16
> > 2022-06-12 21:35:20 Deleting backup 17
> > 2022-06-12 21:35:27 Deleting backup 18
> > 2022-06-12 21:35:34 Deleting backup 19
> > 2022-06-12 21:35:41 Deleting backup 22
> > 2022-06-12 21:35:47 Deleting backup 30
> > 2022-06-12 21:36:00 Deleting backup 32
> >
> > wow.  not too robust!  doesn't that seem like an inordinate consequence?
>
> Mr. Kosowsky didn't specifically address the robustness issue so I'll
> chime in here about that.  No, it doesn't seem inordinate if you think
> about how BackupPC manages backups.  The non-filled backups are based
> on a filled backup.  If you don't have that, then backups which are
> based on it are useless so there's no point in keeping them.  I think
> the moral of the story is that if you care about your backups, don't
> do what you did (nor anything like it) without taking precautions.
>
> Having said that I don't generally mess with BackupPC (whether it's in
> the middle of doing something or not).  After a couple of false starts
> (which must have been at least partly my fault, while I was migrating
> from V3 to V4) once I got version 4 settled in it has never put a foot
> wrong backing up dozens of machines, which aren't even all in the same
> country, with tens of terabytes of data.  Occasionally I recover files
> and directories from the backups; it's often much easier than fetching
> them from the backed up machines directly.  I've found that doing this
> makes me more confident of BackupPC.  That then makes it more likely
> that when I need to fetch more files I'll grab backups rather than go
> to the originals.  It gives me a warm fuzzy feeling I suppose, to know
> the recovered backed up data is exactly what I expect it to be, so I'm
> that much more confident that if I needed it because I've managed to
> lose the original then it would be there for me.
>
> I have no axe to grind.  I'm not in any way connected with BackupPC
> development nor with the developers, I'm just a very satisfied user
> and I thought that a message which could be seen as critical needed
> something to balance it.  Of course there will be faults to be fixed
> in any even moderately complex software.  BackupPC is probably a bit
> more than just moderately complex, but I've found it very robust if
> treated with reasonable care.
>

we've been using backuppc3 many years now, it's still chugging along and
i'm just getting backuppc4 going.  yes i'm quite happy with it and find it
robust.  but hence my surprise that an interrupt can have this consequence
in backuppc4.  the 'robust' merit is called on the carpet if a power loss
can result in significant loss of backups.

offhand i'm not really seeing why an interrupt would result in the loss of
a prior backup directory.  i'd be surprised to learn that a prior backup is
ever moved or renamed and thus subject to loss if interrupted, but what
else could it be?  if an existing backup directory is ever renamed or moved
i would consider that a design flaw worth correcting.  i would think it
preferable that once a backup directory gets it's number, it keeps it for
it's entire lifetime, no renames, no moves.
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

Re: [BackupPC-users] Serious error: last backup directory doesn't exist!!! Need to remove back to last filled backup

[G.W. Haywood via BackupPC-users]

Hi there,

On Tue, 14 Jun 2022, gregrwm wrote:


... interrupted BackupPC_dump.  on the next invocation i got:
2022-06-12 21:35:02 Serious error: last backup
/var/lib/backuppc/pc/avocado/32 directory doesn't exist!!!  Need to remove
back to last filled backup
2022-06-12 21:35:02 Deleting backup 14
2022-06-12 21:35:08 Deleting backup 15
2022-06-12 21:35:14 Deleting backup 16
2022-06-12 21:35:20 Deleting backup 17
2022-06-12 21:35:27 Deleting backup 18
2022-06-12 21:35:34 Deleting backup 19
2022-06-12 21:35:41 Deleting backup 22
2022-06-12 21:35:47 Deleting backup 30
2022-06-12 21:36:00 Deleting backup 32

wow.  not too robust!  doesn't that seem like an inordinate consequence?


Mr. Kosowsky didn't specifically address the robustness issue so I'll
chime in here about that.  No, it doesn't seem inordinate if you think
about how BackupPC manages backups.  The non-filled backups are based
on a filled backup.  If you don't have that, then backups which are
based on it are useless so there's no point in keeping them.  I think
the moral of the story is that if you care about your backups, don't
do what you did (nor anything like it) without taking precautions.

Having said that I don't generally mess with BackupPC (whether it's in
the middle of doing something or not).  After a couple of false starts
(which must have been at least partly my fault, while I was migrating
from V3 to V4) once I got version 4 settled in it has never put a foot
wrong backing up dozens of machines, which aren't even all in the same
country, with tens of terabytes of data.  Occasionally I recover files
and directories from the backups; it's often much easier than fetching
them from the backed up machines directly.  I've found that doing this
makes me more confident of BackupPC.  That then makes it more likely
that when I need to fetch more files I'll grab backups rather than go
to the originals.  It gives me a warm fuzzy feeling I suppose, to know
the recovered backed up data is exactly what I expect it to be, so I'm
that much more confident that if I needed it because I've managed to
lose the original then it would be there for me.

I have no axe to grind.  I'm not in any way connected with BackupPC
development nor with the developers, I'm just a very satisfied user
and I thought that a message which could be seen as critical needed
something to balance it.  Of course there will be faults to be fixed
in any even moderately complex software.  BackupPC is probably a bit
more than just moderately complex, but I've found it very robust if
treated with reasonable care.  I check the hosts page once a day to
see that the backups are all less than a day old.  That's about it.

If BackupPC hadn't existed I think I'd have had to create it myself.

--

73,
Ged.


___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

Re: [BackupPC-users] Serious error: last backup directory doesn't exist!!! Need to remove back to last filled backup

[backuppc]

gregrwm wrote at about 19:24:17 -0500 on Monday, June 13, 2022:
 > i hadn't prepared my config quite as i'd intended, and expected a rather
 > long wait, so i interrupted BackupPC_dump.
 > on the next invocation i got:
 > 2022-06-12 21:35:02 Serious error: last backup
 > /var/lib/backuppc/pc/avocado/32 directory doesn't exist!!!  Need to remove
 > back to last filled backup
 > 2022-06-12 21:35:02 Deleting backup 14
 > 2022-06-12 21:35:08 Deleting backup 15
 > 2022-06-12 21:35:14 Deleting backup 16
 > 2022-06-12 21:35:20 Deleting backup 17
 > 2022-06-12 21:35:27 Deleting backup 18
 > 2022-06-12 21:35:34 Deleting backup 19
 > 2022-06-12 21:35:41 Deleting backup 22
 > 2022-06-12 21:35:47 Deleting backup 30
 > 2022-06-12 21:36:00 Deleting backup 32
 > 
 > wow.  not too robust!  doesn't that seem like an inordinate consequence?
 > 

I have encountered the same problem a couple of times in the past when
I have interrupted backups.

It seems that what happens is that somehow the reference backup gets
corrupted, necessitating the erasure of all dependent non-filled
backups.

A similar, potentially related problem that I have run into is that
when backups fail (independent of cancellations), the backup number
gets incremented even though no new backup is recorded.

I have reported both problems to Craig but have not been able to
replicate it so no fix has been found.

If you can reliably replicate the problem, then that should help nail
down the problem, allowing for a fix.


___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

[BackupPC-users] Serious error: last backup directory doesn't exist!!! Need to remove back to last filled backup

[gregrwm]

i hadn't prepared my config quite as i'd intended, and expected a rather
long wait, so i interrupted BackupPC_dump.
on the next invocation i got:
2022-06-12 21:35:02 Serious error: last backup
/var/lib/backuppc/pc/avocado/32 directory doesn't exist!!!  Need to remove
back to last filled backup
2022-06-12 21:35:02 Deleting backup 14
2022-06-12 21:35:08 Deleting backup 15
2022-06-12 21:35:14 Deleting backup 16
2022-06-12 21:35:20 Deleting backup 17
2022-06-12 21:35:27 Deleting backup 18
2022-06-12 21:35:34 Deleting backup 19
2022-06-12 21:35:41 Deleting backup 22
2022-06-12 21:35:47 Deleting backup 30
2022-06-12 21:36:00 Deleting backup 32

wow.  not too robust!  doesn't that seem like an inordinate consequence?

(manjaro backuppc 4.4.0-4)
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

Re: [BackupPC-users] Serious error: last backup ... directory doesn't exist!!! - reason found

[fi]

Dear Holger, 

> f...@igh.de wrote on 2018-03-08 16:59:37 +0100 [Re: [BackupPC-users] Serious 
> error: last backup ... directory doesn't exist!!! - reason found]:
> > [...]
> > Meanwhile I found the reason: the partition ran out of inodes. As you
> > wrote under "How much disk space do I need?" one has to have "plenty
> > of inodes". But what does that mean? 
> 
> as has been said, that depends directly on what you are backing up.

yes of course, but there are other signicant influences. I have
counted the number of inodes in the cpool and in the pc
directories. The latter was about 100 times higher. Obviously the
number of kept backups is a factor to consider. It seems, the number
n_i of inodes required is about 

   n_i = n_f (2 n_b + 1), 

where 
  n_b: number of backups kept 
  n_f: number of files to backup
  
could anyone confirm or disconfirm this? 



> > May I ask the following:
> > 
> > - in the "General Server Information" you give some statistical
> >   information about disk usage; would it be a good idea also to give
> >   information about inode consumption? 
> 
> You mean 'df -i'?

yes exactly! 

I have created a post backup notification e-mail which now contains
also the output of "df -i". 

BTW.: such a post backup notification I would recommend as
default. It is not a good idea to conclude a successful backup from a
missing message...


> > - is it possible and would it make sense to separate the "pc" and the
> >   "pool/cpool" directories into different partitions? I just did an
> >   rsync of a BackupPC-directory and found that the files on "pc" are
> >   mostly empty or small. The file sizes in "pool/cpool" are remarkable
> >   bigger - I assume these are the "real" files. So one could create
> >   one partition for "pool/cpool" having about e.g. 64kB per inode and
> >   another partition having a block size of 1 kB and also 1 kB per
> >   inode. Maybe this would reduce disk space consumption and also allow 
> >   rsyncing somewhat faster. 
> 
> My first thought is to avoid the issue altogether by using a file system
> that doesn't statically allocate inodes (e.g. XFS or reiserfs, the latter
> I wouldn't recommend for other reasons, though; I don't know about ext4,
> btrfs and ZFS, but my guess would be that ext4 has static allocation and
> the others dynamic). Why worry about a problem modern file systems simply
> don't have?

I have made several tests with different file systems (xfs, reiserfs,
jfs). After some time of operation I had different kinds of trouble with
all of them; especially xfs seems to be sensitive against power
blackout (I know UPS could help, but this increases the effort of battery
life cycle management; sometimes I found UPS caused more trouble than solved). 

I consider ext[3/4] the far most robust file system. So if I know how
to calculate the required number of inodes it will stay my favorite. 


Best regards


Torsten


-- 

Torsten Finke
f...@igh.de

Ingenieurgemeinschaft IgH
Gesellschaft für Ingenieurleistungen mbH
Heinz-Bäcker-Str. 34
D-45356 Essen



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Re: [BackupPC-users] Serious error: last backup ... directory doesn't exist!!! - reason found

[Michael Stowe]

On 2018-03-13 16:33, Holger Parplies wrote:
My first thought is to avoid the issue altogether by using a file 
system
that doesn't statically allocate inodes (e.g. XFS or reiserfs, the 
latter
I wouldn't recommend for other reasons, though; I don't know about 
ext4,
btrfs and ZFS, but my guess would be that ext4 has static allocation 
and
the others dynamic). Why worry about a problem modern file systems 
simply

don't have?

Regards,
Holger


I happen to have used BackupPC with ext4, xfs, and btrfs.  ext4 (unlike 
ext2 and ext3) does indeed have a way to extend the number of inodes 
beyond the static allocation.  XFS, elegant and well designed, gave me 
no end of trouble, frankly.  Your mileage may vary, but on more than one 
occasion, I found subtle corruption for unknown reasons had caused weird 
ripple effects throughout the file system.  btrfs has, perhaps 
ironically, proven the most reliable of the three.  Again, your mileage 
may vary, and while I can go into considerable detail about my own 
experiences and testing, they are limited in scope and nature.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Re: [BackupPC-users] Serious error: last backup ... directory doesn't exist!!! - reason found

[Holger Parplies]

Hi,

f...@igh.de wrote on 2018-03-08 16:59:37 +0100 [Re: [BackupPC-users] Serious 
error: last backup ... directory doesn't exist!!! - reason found]:
> [...]
> Meanwhile I found the reason: the partition ran out of inodes. As you
> wrote under "How much disk space do I need?" one has to have "plenty
> of inodes". But what does that mean? 

as has been said, that depends directly on what you are backing up.

> May I ask the following:
> 
> - in the "General Server Information" you give some statistical
>   information about disk usage; would it be a good idea also to give
>   information about inode consumption? 

You mean 'df -i'?

> - is it possible and would it make sense to separate the "pc" and the
>   "pool/cpool" directories into different partitions? I just did an
>   rsync of a BackupPC-directory and found that the files on "pc" are
>   mostly empty or small. The file sizes in "pool/cpool" are remarkable
>   bigger - I assume these are the "real" files. So one could create
>   one partition for "pool/cpool" having about e.g. 64kB per inode and
>   another partition having a block size of 1 kB and also 1 kB per
>   inode. Maybe this would reduce disk space consumption and also allow 
>   rsyncing somewhat faster. 

My first thought is to avoid the issue altogether by using a file system
that doesn't statically allocate inodes (e.g. XFS or reiserfs, the latter
I wouldn't recommend for other reasons, though; I don't know about ext4,
btrfs and ZFS, but my guess would be that ext4 has static allocation and
the others dynamic). Why worry about a problem modern file systems simply
don't have?

Regards,
Holger

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Re: [BackupPC-users] Serious error: last backup ... directory doesn't exist!!! - reason found

[frush]

One of the more challenging aspects of this is the number of inodes that 
BackupPC consumes
is directly related to how many inodes you're backing up.   If I recall 
correctly, in
BackupPC 4.x, each 'filled' backup will use 2 inodes per object backed up in 
addition to
the inode consumed by the unique hashed file.
One has to understand well the environment they are backing up in order to make 
a informed
choice about the number of inodes required by BackupPC.   I know I didn't on my 
first
pass!  Our current set of backups (~30 days) uses 93 Million inodes and 4TB of 
space to
backup 126 hosts.   Metadata alone takes up 357MB on our NAS.
--Ray FrushColorado State University.
On Thu, 2018-03-08 at 19:54 +0300, Alexander Moisseev via BackupPC-users wrote:
> On 3/8/2018 6:59 PM, f...@igh.de wrote:
> > Craig,
> > 
> > again I return to my issue "No space left on device".
> > 
> > Meanwhile I found the reason: the partition ran out of inodes. As you
> > wrote under "How much disk space do I need?" one has to have "plenty
> > of inodes". But what does that mean?
> > 
> > May I ask the following:
> > 
> > - in the "General Server Information" you give some statistical
> >information about disk usage; would it be a good idea also to give
> >information about inode consumption?
> > 
> 
> It is a really good idea, but obtaining inode consumption with du command is 
> complicated
> since it returns different sets of columns on different OSes.
> I think the simplest way is to replace CheckFileSystemUsage subroutine with
> Filesys::DiskSpace module.
> 
> Craig, is it ok to introduce another dependency?
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> BackupPC-users mailing list
> BackupPC-users@lists.sourceforge.net
> List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki:http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Re: [BackupPC-users] Serious error: last backup ... directory doesn't exist!!! - reason found

[Alexander Moisseev via BackupPC-users]

On 3/8/2018 6:59 PM, f...@igh.de wrote:

Craig,

again I return to my issue "No space left on device".

Meanwhile I found the reason: the partition ran out of inodes. As you
wrote under "How much disk space do I need?" one has to have "plenty
of inodes". But what does that mean?

May I ask the following:

- in the "General Server Information" you give some statistical
   information about disk usage; would it be a good idea also to give
   information about inode consumption?



It is a really good idea, but obtaining inode consumption with du command is 
complicated since it returns different sets of columns on different OSes.
I think the simplest way is to replace CheckFileSystemUsage subroutine with 
Filesys::DiskSpace module.

Craig, is it ok to introduce another dependency?

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Re: [BackupPC-users] Serious error: last backup ... directory doesn't exist!!! - reason found

[fi]

Craig,

again I return to my issue "No space left on device". 

Meanwhile I found the reason: the partition ran out of inodes. As you
wrote under "How much disk space do I need?" one has to have "plenty
of inodes". But what does that mean? 

May I ask the following:

- in the "General Server Information" you give some statistical
  information about disk usage; would it be a good idea also to give
  information about inode consumption? 

- is it possible and would it make sense to separate the "pc" and the
  "pool/cpool" directories into different partitions? I just did an
  rsync of a BackupPC-directory and found that the files on "pc" are
  mostly empty or small. The file sizes in "pool/cpool" are remarkable
  bigger - I assume these are the "real" files. So one could create
  one partition for "pool/cpool" having about e.g. 64kB per inode and
  another partition having a block size of 1 kB and also 1 kB per
  inode. Maybe this would reduce disk space consumption and also allow 
  rsyncing somewhat faster. 


Best regards


Torsten



> Thanks for the additional info, but I can't explain the behavior your are
> seeing.  Sending to the user-list to see if others have suggestions.
> 
> BackupPC seems to be unable to create directories and files below
> /vol/bpc4/BackupPC.  The "No space left on device" errno seems inconsistent
> with the output of df.
> 
> Although it won't address any of your problems, I pushed a fix
> 
> for the error caused by the failure to open a directory.
> 
> Craig
> 
> On Sat, Feb 3, 2018 at 3:56 AM,  wrote:
> 
> > Dear Craig,
> >
> > On Fri, Feb 02, 2018 at 09:19:02AM -0800, Craig Barratt via BackupPC-users
> > wrote:
> > > Here are a few things to check:
> > >
> > >- can you manually create files and directories below
> > /vol/bpc4/BackupPC
> > >as the backuppc user (eg, "su backuppc; cd /vol/bpc4/BackupPC; mkdir
> > foo;
> > >rmdir foo; touch foobar; rm foobar")
> >
> > yes, works as expected.
> >
> > >- is the file system mounted readonly?
> >
> > no, mount says:
> > ... /vol/bpc4 type ext4 (rw,noatime,data=ordered)
> >
> > >- has the backuppc user lost permissions?
> >
> > in what sense? All BackupPC processes run as user backuppc; all files
> > and directories /vol/bpc4/BackupPC and below are owned by
> > backuppc:backuppc.
> >
> >
> > df says
> > Filesystem Size  Used Avail Use% Mounted on
> > /dev/mapper/data-bpc4  1.6T  955G  535G  65% /vol/bpc4
> >
> > The file system lives on a mirror raid, which seems to be ok:
> >
> > md127 : active raid1 sdb1[1] sdc1[0]
> >   2930266432 blocks [2/2] [UU]
> >
> > There are no SMART errors logged on the disks (even after SMART test).
> >
> > I have copied several GB to the file system and removed them again -
> > no errors.
> >
> > I have launched a forced fsck. It succeeded without any errors:
> > Durchgang 1: Inodes, Blöcke und Größen werden geprüft
> > Durchgang 2: Verzeichnisstruktur wird geprüft
> > Durchgang 3: Verzeichnisverknüpfungen werden geprüft
> > Durchgang 4: Referenzzähler werden überprüft
> > Durchgang 5: Zusammengefasste Gruppeninformation wird geprüft
> > /dev/data/bpc4: 104312919/104505344 Dateien (0.0% nicht
> > zusammenhängend), 256909
> > 738/417993728 Blöcke
> >
> >
> > I went through the logs. There are more error messages from a backup
> > which was presented as "running" in the summary. Rather strange sound
> > the messages "IO error encountered" and "No space left on device "
> > (please see below). I cannot figure out the origin of these messages.
> >
> > ...
> > G bpc_fileReadAll: can't open
> > /vol/bpc4/BackupPC/cpool/20/9a/219b13a5a32e6cd66ab3cf139bd8d35c (from
> > alternatives/pg_config)
> > file has vanished: "alternatives/pg_config"
> > ...
> >
> > ...
> > IO error encountered -- skipping file deletion
> > G bpc_attrib_dirRead: can't open
> > /vol/bpc4/BackupPC/cpool/26/24/27243e59e0d4404f14ddc7ebb0202ce6
> > G bpc_attribCache_loadPath:
> > bpc_attrib_dirRead(/vol/bpc4/BackupPC/pc/zuse/169, fetc/fapache2/attrib)
> > returned -1
> > ...
> >
> > ...
> > R bpc_attrib_dirRead: can't open
> > /vol/bpc4/BackupPC/cpool/1e/aa/1eab8cca5e477b6fe2530e955cca3978
> > R bpc_attribCache_loadPath:
> > bpc_attrib_dirRead(/vol/bpc4/BackupPC/pc/zuse/169,
> > fetc/fcups/fssl/attrib) returned -1
> > [ skipped 6 lines ]
> > ...
> >
> >
> > ...
> > R
> > R
> > bpc_sysCall_checkFileMatch(.cpan/build/DateTime-Locale-1.
> > 05-GcMGii/pm_to_blib):
> > file doesn't exist
> > ...
> >
> > ...
> > R bpc_poolWrite_write: can't open/create
> > /vol/bpc4/BackupPC/cpool/18801.736.0 for writingIOdone: pool
> > .cpan/build/DateTime-Locale-1.05-GcMGii/blib/lib/DateTime/
> > Locale/.en_NR.pod.00
> > ...
> >
> > ...
> > R
> > bpc_poolWrite_unmarkPendingDelete(/vol/bpc4/BackupPC/cpool/50/02/
> > 50032f7b52be451f6a6c396067253906)
> > failed; errno = 2
> > R Couldn't unmark candidate matching file
> > 

Re: [BackupPC-users] Serious error: last backup ... directory doesn't exist!!!

[fi]

Dear Craig, 

> Thanks for the additional info, but I can't explain the behavior your are
> seeing.  Sending to the user-list to see if others have suggestions.
> 
> BackupPC seems to be unable to create directories and files below
> /vol/bpc4/BackupPC.  The "No space left on device" errno seems inconsistent
> with the output of df.

Indeed it sounds crazy. 

I would try to do some kind of roll back to a date before this
trouble. Would it be safe to remove:
- all numbered directories which have been created after the
  first errors,
- the per-host directories "refCnt"
- files: XferLOG.NNN.z, backups, backups.old, LOG., LOCK?

After that I would try to restart BackupPC hoping it would set up on
the state before the error. Could that work? 



> Although it won't address any of your problems, I pushed a fix
> 
> for the error caused by the failure to open a directory.


I am going to set up another Backup server. I will do that with the
newest version available. 



Best regards


Torsten




> On Sat, Feb 3, 2018 at 3:56 AM,  wrote:
> 
> > Dear Craig,
> >
> > On Fri, Feb 02, 2018 at 09:19:02AM -0800, Craig Barratt via BackupPC-users
> > wrote:
> > > Here are a few things to check:
> > >
> > >- can you manually create files and directories below
> > /vol/bpc4/BackupPC
> > >as the backuppc user (eg, "su backuppc; cd /vol/bpc4/BackupPC; mkdir
> > foo;
> > >rmdir foo; touch foobar; rm foobar")
> >
> > yes, works as expected.
> >
> > >- is the file system mounted readonly?
> >
> > no, mount says:
> > ... /vol/bpc4 type ext4 (rw,noatime,data=ordered)
> >
> > >- has the backuppc user lost permissions?
> >
> > in what sense? All BackupPC processes run as user backuppc; all files
> > and directories /vol/bpc4/BackupPC and below are owned by
> > backuppc:backuppc.
> >
> >
> > df says
> > Filesystem Size  Used Avail Use% Mounted on
> > /dev/mapper/data-bpc4  1.6T  955G  535G  65% /vol/bpc4
> >
> > The file system lives on a mirror raid, which seems to be ok:
> >
> > md127 : active raid1 sdb1[1] sdc1[0]
> >   2930266432 blocks [2/2] [UU]
> >
> > There are no SMART errors logged on the disks (even after SMART test).
> >
> > I have copied several GB to the file system and removed them again -
> > no errors.
> >
> > I have launched a forced fsck. It succeeded without any errors:
> > Durchgang 1: Inodes, Blöcke und Größen werden geprüft
> > Durchgang 2: Verzeichnisstruktur wird geprüft
> > Durchgang 3: Verzeichnisverknüpfungen werden geprüft
> > Durchgang 4: Referenzzähler werden überprüft
> > Durchgang 5: Zusammengefasste Gruppeninformation wird geprüft
> > /dev/data/bpc4: 104312919/104505344 Dateien (0.0% nicht
> > zusammenhängend), 256909
> > 738/417993728 Blöcke
> >
> >
> > I went through the logs. There are more error messages from a backup
> > which was presented as "running" in the summary. Rather strange sound
> > the messages "IO error encountered" and "No space left on device "
> > (please see below). I cannot figure out the origin of these messages.
> >
> > ...
> > G bpc_fileReadAll: can't open
> > /vol/bpc4/BackupPC/cpool/20/9a/219b13a5a32e6cd66ab3cf139bd8d35c (from
> > alternatives/pg_config)
> > file has vanished: "alternatives/pg_config"
> > ...
> >
> > ...
> > IO error encountered -- skipping file deletion
> > G bpc_attrib_dirRead: can't open
> > /vol/bpc4/BackupPC/cpool/26/24/27243e59e0d4404f14ddc7ebb0202ce6
> > G bpc_attribCache_loadPath:
> > bpc_attrib_dirRead(/vol/bpc4/BackupPC/pc/zuse/169, fetc/fapache2/attrib)
> > returned -1
> > ...
> >
> > ...
> > R bpc_attrib_dirRead: can't open
> > /vol/bpc4/BackupPC/cpool/1e/aa/1eab8cca5e477b6fe2530e955cca3978
> > R bpc_attribCache_loadPath:
> > bpc_attrib_dirRead(/vol/bpc4/BackupPC/pc/zuse/169,
> > fetc/fcups/fssl/attrib) returned -1
> > [ skipped 6 lines ]
> > ...
> >
> >
> > ...
> > R
> > R
> > bpc_sysCall_checkFileMatch(.cpan/build/DateTime-Locale-1.
> > 05-GcMGii/pm_to_blib):
> > file doesn't exist
> > ...
> >
> > ...
> > R bpc_poolWrite_write: can't open/create
> > /vol/bpc4/BackupPC/cpool/18801.736.0 for writingIOdone: pool
> > .cpan/build/DateTime-Locale-1.05-GcMGii/blib/lib/DateTime/
> > Locale/.en_NR.pod.00
> > ...
> >
> > ...
> > R
> > bpc_poolWrite_unmarkPendingDelete(/vol/bpc4/BackupPC/cpool/50/02/
> > 50032f7b52be451f6a6c396067253906)
> > failed; errno = 2
> > R Couldn't unmark candidate matching file
> > /vol/bpc4/BackupPC/cpool/50/02/50032f7b52be451f6a6c396067253906
> > (skipped; errno = 2)
> > ...
> >
> >
> > The following is very strange:
> > ...
> > rsync_bpc: recv_generator: mkdir
> > "/.cpan/build/Dist-CheckConflicts-0.11-RNgNPa/t/lib" failed: No space
> > left on device (28)
> > ...
> >
> > dumpe2fs says:
> >
> > ...
> > Inode count:  104505344
> > Block count:  417993728
> > Reserved block count: 20899686
> > Free blocks:  243883988
> > Free inodes:

Re: [BackupPC-users] Serious error: last backup ... directory doesn't exist!!!

[Craig Barratt via BackupPC-users]

Torsten,

Thanks for the additional info, but I can't explain the behavior your are
seeing.  Sending to the user-list to see if others have suggestions.

BackupPC seems to be unable to create directories and files below
/vol/bpc4/BackupPC.  The "No space left on device" errno seems inconsistent
with the output of df.

Although it won't address any of your problems, I pushed a fix

for the error caused by the failure to open a directory.

Craig

On Sat, Feb 3, 2018 at 3:56 AM,  wrote:

> Dear Craig,
>
> On Fri, Feb 02, 2018 at 09:19:02AM -0800, Craig Barratt via BackupPC-users
> wrote:
> > Here are a few things to check:
> >
> >- can you manually create files and directories below
> /vol/bpc4/BackupPC
> >as the backuppc user (eg, "su backuppc; cd /vol/bpc4/BackupPC; mkdir
> foo;
> >rmdir foo; touch foobar; rm foobar")
>
> yes, works as expected.
>
> >- is the file system mounted readonly?
>
> no, mount says:
> ... /vol/bpc4 type ext4 (rw,noatime,data=ordered)
>
> >- has the backuppc user lost permissions?
>
> in what sense? All BackupPC processes run as user backuppc; all files
> and directories /vol/bpc4/BackupPC and below are owned by
> backuppc:backuppc.
>
>
> df says
> Filesystem Size  Used Avail Use% Mounted on
> /dev/mapper/data-bpc4  1.6T  955G  535G  65% /vol/bpc4
>
> The file system lives on a mirror raid, which seems to be ok:
>
> md127 : active raid1 sdb1[1] sdc1[0]
>   2930266432 blocks [2/2] [UU]
>
> There are no SMART errors logged on the disks (even after SMART test).
>
> I have copied several GB to the file system and removed them again -
> no errors.
>
> I have launched a forced fsck. It succeeded without any errors:
> Durchgang 1: Inodes, Blöcke und Größen werden geprüft
> Durchgang 2: Verzeichnisstruktur wird geprüft
> Durchgang 3: Verzeichnisverknüpfungen werden geprüft
> Durchgang 4: Referenzzähler werden überprüft
> Durchgang 5: Zusammengefasste Gruppeninformation wird geprüft
> /dev/data/bpc4: 104312919/104505344 Dateien (0.0% nicht
> zusammenhängend), 256909
> 738/417993728 Blöcke
>
>
> I went through the logs. There are more error messages from a backup
> which was presented as "running" in the summary. Rather strange sound
> the messages "IO error encountered" and "No space left on device "
> (please see below). I cannot figure out the origin of these messages.
>
> ...
> G bpc_fileReadAll: can't open
> /vol/bpc4/BackupPC/cpool/20/9a/219b13a5a32e6cd66ab3cf139bd8d35c (from
> alternatives/pg_config)
> file has vanished: "alternatives/pg_config"
> ...
>
> ...
> IO error encountered -- skipping file deletion
> G bpc_attrib_dirRead: can't open
> /vol/bpc4/BackupPC/cpool/26/24/27243e59e0d4404f14ddc7ebb0202ce6
> G bpc_attribCache_loadPath:
> bpc_attrib_dirRead(/vol/bpc4/BackupPC/pc/zuse/169, fetc/fapache2/attrib)
> returned -1
> ...
>
> ...
> R bpc_attrib_dirRead: can't open
> /vol/bpc4/BackupPC/cpool/1e/aa/1eab8cca5e477b6fe2530e955cca3978
> R bpc_attribCache_loadPath:
> bpc_attrib_dirRead(/vol/bpc4/BackupPC/pc/zuse/169,
> fetc/fcups/fssl/attrib) returned -1
> [ skipped 6 lines ]
> ...
>
>
> ...
> R
> R
> bpc_sysCall_checkFileMatch(.cpan/build/DateTime-Locale-1.
> 05-GcMGii/pm_to_blib):
> file doesn't exist
> ...
>
> ...
> R bpc_poolWrite_write: can't open/create
> /vol/bpc4/BackupPC/cpool/18801.736.0 for writingIOdone: pool
> .cpan/build/DateTime-Locale-1.05-GcMGii/blib/lib/DateTime/
> Locale/.en_NR.pod.00
> ...
>
> ...
> R
> bpc_poolWrite_unmarkPendingDelete(/vol/bpc4/BackupPC/cpool/50/02/
> 50032f7b52be451f6a6c396067253906)
> failed; errno = 2
> R Couldn't unmark candidate matching file
> /vol/bpc4/BackupPC/cpool/50/02/50032f7b52be451f6a6c396067253906
> (skipped; errno = 2)
> ...
>
>
> The following is very strange:
> ...
> rsync_bpc: recv_generator: mkdir
> "/.cpan/build/Dist-CheckConflicts-0.11-RNgNPa/t/lib" failed: No space
> left on device (28)
> ...
>
> dumpe2fs says:
>
> ...
> Inode count:  104505344
> Block count:  417993728
> Reserved block count: 20899686
> Free blocks:  243883988
> Free inodes:  97119479
> ...
>
>
>
> Best regards
>
>
> Torsten Finke
>
>
>
>
> > It does look like the failure to update the filesystem exposes a bug
> which
> > I'll fix, but this is secondary to your main issue:
> >
> > Can't use an undefined value as an ARRAY reference at
> > /vol/opt/BackupPC-4.1.3/bin/BackupPC_refCountUpdate line 380
> >
> >
> > Craig
> >
> > On Fri, Feb 2, 2018 at 5:56 AM,  wrote:
> >
> > > Dear BackupPC Users,
> > >
> > >
> > > I am running BackupPC-4.1.3 for several months without problems
> > > (really a great piece of software).
> > >
> > > About a week ago a strange type of error occured and keeps staying,
> > > which I cannot understand. The error messages are like this ("fs" is
> > > the name of one of my systems to be backed up; I did some linebreaks
> > > to 

Re: [BackupPC-users] Serious error: last backup ... directory doesn't exist!!!

[Craig Barratt via BackupPC-users]

Other things to check include:

   - is the file system full? (df) - you did say it was only 65% full, so
   that should be ok
   - have you run out of inodes? (df -i)

If you can't directly see some problem with the file system the next step
is to stop backuppc, unmount the file system and run fsck.

Craig


On Fri, Feb 2, 2018 at 9:19 AM, Craig Barratt <
cbarr...@users.sourceforge.net> wrote:

> Here are a few things to check:
>
>- can you manually create files and directories below
>/vol/bpc4/BackupPC as the backuppc user (eg, "su backuppc; cd
>/vol/bpc4/BackupPC; mkdir foo; rmdir foo; touch foobar; rm foobar")
>- is the file system mounted readonly?
>- has the backuppc user lost permissions?
>
> It does look like the failure to update the filesystem exposes a bug which
> I'll fix, but this is secondary to your main issue:
>
> Can't use an undefined value as an ARRAY reference at
> /vol/opt/BackupPC-4.1.3/bin/BackupPC_refCountUpdate line 380
>
>
> Craig
>
> On Fri, Feb 2, 2018 at 5:56 AM,  wrote:
>
>> Dear BackupPC Users,
>>
>>
>> I am running BackupPC-4.1.3 for several months without problems
>> (really a great piece of software).
>>
>> About a week ago a strange type of error occured and keeps staying,
>> which I cannot understand. The error messages are like this ("fs" is
>> the name of one of my systems to be backed up; I did some linebreaks
>> to increase readability):
>>
>>
>> 2018-01-28 23:43:34 Can't create /vol/bpc4/BackupPC/pc/fs/149/refCnt
>> 2018-01-29 02:09:34 Serious error: last backup
>>   /vol/bpc4/BackupPC/pc/fs/149 directory doesn't exist!!!  Need to
>>   remove back to last filled backup
>> 2018-01-29 02:09:34 Deleting backup 147
>> 2018-01-29 02:09:35 BackupPC_backupDelete: removing #147
>> 2018-01-29 02:09:35 BackupPC_backupDelete: No prior backup for merge
>> 2018-01-29 02:09:52 BackupPC_refCountUpdate: doing fsck on fs #149
>>   since /vol/bpc4/BackupPC/pc/fs/149/refCnt doesn't exist
>> 2018-01-29 02:09:52 Can't use an undefined value as an ARRAY reference
>>   at /vol/opt/BackupPC-4.1.3/bin/BackupPC_refCountUpdate line 380.
>> 2018-01-29 02:09:52 BackupPC_backupDelete: got 1 errors
>> 2018-01-29 02:09:52 Finished BackupPC_backupDelete, status = 256
>>   (running time: 18 sec)
>> 2018-01-29 02:09:52 Deleting backup 148
>> 2018-01-29 02:09:52 BackupPC_backupDelete: removing #148
>> 2018-01-29 02:09:52 BackupPC_backupDelete: No prior backup for merge
>> 2018-01-29 02:09:55 BackupPC_refCountUpdate: doing fsck on fs #149
>>   since /vol/bpc4/BackupPC/pc/fs/149/refCnt doesn't exist
>> 2018-01-29 02:09:55 Can't use an undefined value as an ARRAY reference
>>   at /vol/opt/BackupPC-4.1.3/bin/BackupPC_refCountUpdate line 380.
>> 2018-01-29 02:09:55 BackupPC_backupDelete: got 1 errors
>> 2018-01-29 02:09:55 Finished BackupPC_backupDelete, status = 256
>>   (running time: 3 sec)
>> 2018-01-29 02:09:55 Deleting backup 149
>> 2018-01-29 02:09:56 BackupPC_backupDelete: removing #149
>> 2018-01-29 02:09:56 BackupPC_backupDelete: No prior backup for merge
>> 2018-01-29 02:38:20 BackupPC_refCountUpdate: host fs got 0 errors
>>   (took 1704 secs)
>> 2018-01-29 02:38:20 Finished BackupPC_backupDelete, status = 0
>>   (running time: 1705 sec)
>> 2018-01-29 03:16:29 dump failed: unable to open/create
>>   /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
>> 2018-01-29 03:55:15 dump failed: unable to open/create
>>   /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
>> 2018-01-29 04:15:15 dump failed: unable to open/create
>>   /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
>> 2018-01-29 23:43:54 dump failed: unable to open/create
>>   /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
>> 2018-01-30 01:24:02 dump failed: unable to open/create
>>   /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
>> 2018-01-30 02:36:01 dump failed: unable to open/create
>>   /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
>> 2018-01-30 03:42:01 dump failed: unable to open/create
>>   /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
>> 2018-01-30 04:12:01 dump failed: unable to open/create
>>   /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
>> 2018-01-30 23:57:53 Copying backup #146 to #147
>>
>> 2018-01-31 01:05:38 Can't mkpath
>>   /vol/bpc4/BackupPC/pc/fs/147/./fsysbak/f.../fLocked/f00
>> 2018-01-31 01:05:38 Can't copy
>>   ./fsysbak/f.../fLocked/f00/attrib_dc793dc4650baa1a8cc3b69d211573c1
>>   to /vol/bpc4/BackupPC/pc/fs/147/./fsysbak/f.../fLocked/f00/attr
>> ib_dc793dc4650baa1a8cc3b69d211573c1
>> ...
>>
>> The last pair of messages is then repeated for thousands of files.
>>
>>
>> It seems, that there is an error concerning the sequence.
>>
>> I had checked for several default reasons:
>> - No files or directories have been manipulated manually
>> - BackupPC is almost the only task running on my backup server (there
>>   should be no side effects from other services; no user is normally
>>   working on that machine)
>> - the file system has about 1.6 TB at a usage of 65% (this rate was
>>   never exceeded)
>> - the system had no crash (uptime is 217 days, 

Re: [BackupPC-users] Serious error: last backup ... directory doesn't exist!!!

[Craig Barratt via BackupPC-users]

Here are a few things to check:

   - can you manually create files and directories below /vol/bpc4/BackupPC
   as the backuppc user (eg, "su backuppc; cd /vol/bpc4/BackupPC; mkdir foo;
   rmdir foo; touch foobar; rm foobar")
   - is the file system mounted readonly?
   - has the backuppc user lost permissions?

It does look like the failure to update the filesystem exposes a bug which
I'll fix, but this is secondary to your main issue:

Can't use an undefined value as an ARRAY reference at
/vol/opt/BackupPC-4.1.3/bin/BackupPC_refCountUpdate line 380


Craig

On Fri, Feb 2, 2018 at 5:56 AM,  wrote:

> Dear BackupPC Users,
>
>
> I am running BackupPC-4.1.3 for several months without problems
> (really a great piece of software).
>
> About a week ago a strange type of error occured and keeps staying,
> which I cannot understand. The error messages are like this ("fs" is
> the name of one of my systems to be backed up; I did some linebreaks
> to increase readability):
>
>
> 2018-01-28 23:43:34 Can't create /vol/bpc4/BackupPC/pc/fs/149/refCnt
> 2018-01-29 02:09:34 Serious error: last backup
>   /vol/bpc4/BackupPC/pc/fs/149 directory doesn't exist!!!  Need to
>   remove back to last filled backup
> 2018-01-29 02:09:34 Deleting backup 147
> 2018-01-29 02:09:35 BackupPC_backupDelete: removing #147
> 2018-01-29 02:09:35 BackupPC_backupDelete: No prior backup for merge
> 2018-01-29 02:09:52 BackupPC_refCountUpdate: doing fsck on fs #149
>   since /vol/bpc4/BackupPC/pc/fs/149/refCnt doesn't exist
> 2018-01-29 02:09:52 Can't use an undefined value as an ARRAY reference
>   at /vol/opt/BackupPC-4.1.3/bin/BackupPC_refCountUpdate line 380.
> 2018-01-29 02:09:52 BackupPC_backupDelete: got 1 errors
> 2018-01-29 02:09:52 Finished BackupPC_backupDelete, status = 256
>   (running time: 18 sec)
> 2018-01-29 02:09:52 Deleting backup 148
> 2018-01-29 02:09:52 BackupPC_backupDelete: removing #148
> 2018-01-29 02:09:52 BackupPC_backupDelete: No prior backup for merge
> 2018-01-29 02:09:55 BackupPC_refCountUpdate: doing fsck on fs #149
>   since /vol/bpc4/BackupPC/pc/fs/149/refCnt doesn't exist
> 2018-01-29 02:09:55 Can't use an undefined value as an ARRAY reference
>   at /vol/opt/BackupPC-4.1.3/bin/BackupPC_refCountUpdate line 380.
> 2018-01-29 02:09:55 BackupPC_backupDelete: got 1 errors
> 2018-01-29 02:09:55 Finished BackupPC_backupDelete, status = 256
>   (running time: 3 sec)
> 2018-01-29 02:09:55 Deleting backup 149
> 2018-01-29 02:09:56 BackupPC_backupDelete: removing #149
> 2018-01-29 02:09:56 BackupPC_backupDelete: No prior backup for merge
> 2018-01-29 02:38:20 BackupPC_refCountUpdate: host fs got 0 errors
>   (took 1704 secs)
> 2018-01-29 02:38:20 Finished BackupPC_backupDelete, status = 0
>   (running time: 1705 sec)
> 2018-01-29 03:16:29 dump failed: unable to open/create
>   /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
> 2018-01-29 03:55:15 dump failed: unable to open/create
>   /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
> 2018-01-29 04:15:15 dump failed: unable to open/create
>   /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
> 2018-01-29 23:43:54 dump failed: unable to open/create
>   /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
> 2018-01-30 01:24:02 dump failed: unable to open/create
>   /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
> 2018-01-30 02:36:01 dump failed: unable to open/create
>   /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
> 2018-01-30 03:42:01 dump failed: unable to open/create
>   /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
> 2018-01-30 04:12:01 dump failed: unable to open/create
>   /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
> 2018-01-30 23:57:53 Copying backup #146 to #147
>
> 2018-01-31 01:05:38 Can't mkpath
>   /vol/bpc4/BackupPC/pc/fs/147/./fsysbak/f.../fLocked/f00
> 2018-01-31 01:05:38 Can't copy
>   ./fsysbak/f.../fLocked/f00/attrib_dc793dc4650baa1a8cc3b69d211573c1
>   to /vol/bpc4/BackupPC/pc/fs/147/./fsysbak/f.../fLocked/f00/attrib_
> dc793dc4650baa1a8cc3b69d211573c1
> ...
>
> The last pair of messages is then repeated for thousands of files.
>
>
> It seems, that there is an error concerning the sequence.
>
> I had checked for several default reasons:
> - No files or directories have been manipulated manually
> - BackupPC is almost the only task running on my backup server (there
>   should be no side effects from other services; no user is normally
>   working on that machine)
> - the file system has about 1.6 TB at a usage of 65% (this rate was
>   never exceeded)
> - the system had no crash (uptime is 217 days, since setup of
>   BackupPC).
> - /vol/bpc4 is a mount point of an ext4 file system (normally very
> reliable)
> - Kernel 4.1.39, OpenSuSE 42.1 - not really outdated
>
>
>
>
> Any advice to repair this error is highly appretiated.
>
>
> Best regards
>
>
> Torsten Finke
>
>
>
> --
> 
> Torsten Finke
> f...@igh.de
>
> Ingenieurgemeinschaft IgH
> Gesellschaft für Ingenieurleistungen mbH
> Heinz-Bäcker-Str. 34
> D-45356 Essen
>
> 

[BackupPC-users] Serious error: last backup ... directory doesn't exist!!!

[fi]

Dear BackupPC Users, 
 

I am running BackupPC-4.1.3 for several months without problems
(really a great piece of software).

About a week ago a strange type of error occured and keeps staying,
which I cannot understand. The error messages are like this ("fs" is
the name of one of my systems to be backed up; I did some linebreaks
to increase readability):


2018-01-28 23:43:34 Can't create /vol/bpc4/BackupPC/pc/fs/149/refCnt
2018-01-29 02:09:34 Serious error: last backup
  /vol/bpc4/BackupPC/pc/fs/149 directory doesn't exist!!!  Need to
  remove back to last filled backup
2018-01-29 02:09:34 Deleting backup 147
2018-01-29 02:09:35 BackupPC_backupDelete: removing #147
2018-01-29 02:09:35 BackupPC_backupDelete: No prior backup for merge
2018-01-29 02:09:52 BackupPC_refCountUpdate: doing fsck on fs #149
  since /vol/bpc4/BackupPC/pc/fs/149/refCnt doesn't exist
2018-01-29 02:09:52 Can't use an undefined value as an ARRAY reference
  at /vol/opt/BackupPC-4.1.3/bin/BackupPC_refCountUpdate line 380.
2018-01-29 02:09:52 BackupPC_backupDelete: got 1 errors
2018-01-29 02:09:52 Finished BackupPC_backupDelete, status = 256
  (running time: 18 sec)
2018-01-29 02:09:52 Deleting backup 148
2018-01-29 02:09:52 BackupPC_backupDelete: removing #148
2018-01-29 02:09:52 BackupPC_backupDelete: No prior backup for merge
2018-01-29 02:09:55 BackupPC_refCountUpdate: doing fsck on fs #149
  since /vol/bpc4/BackupPC/pc/fs/149/refCnt doesn't exist
2018-01-29 02:09:55 Can't use an undefined value as an ARRAY reference
  at /vol/opt/BackupPC-4.1.3/bin/BackupPC_refCountUpdate line 380.
2018-01-29 02:09:55 BackupPC_backupDelete: got 1 errors
2018-01-29 02:09:55 Finished BackupPC_backupDelete, status = 256
  (running time: 3 sec)
2018-01-29 02:09:55 Deleting backup 149
2018-01-29 02:09:56 BackupPC_backupDelete: removing #149
2018-01-29 02:09:56 BackupPC_backupDelete: No prior backup for merge
2018-01-29 02:38:20 BackupPC_refCountUpdate: host fs got 0 errors
  (took 1704 secs)
2018-01-29 02:38:20 Finished BackupPC_backupDelete, status = 0
  (running time: 1705 sec)
2018-01-29 03:16:29 dump failed: unable to open/create
  /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
2018-01-29 03:55:15 dump failed: unable to open/create
  /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
2018-01-29 04:15:15 dump failed: unable to open/create
  /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
2018-01-29 23:43:54 dump failed: unable to open/create
  /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
2018-01-30 01:24:02 dump failed: unable to open/create
  /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
2018-01-30 02:36:01 dump failed: unable to open/create
  /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
2018-01-30 03:42:01 dump failed: unable to open/create
  /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
2018-01-30 04:12:01 dump failed: unable to open/create
  /vol/bpc4/BackupPC/pc/fs/XferLOG.147.z
2018-01-30 23:57:53 Copying backup #146 to #147

2018-01-31 01:05:38 Can't mkpath
  /vol/bpc4/BackupPC/pc/fs/147/./fsysbak/f.../fLocked/f00
2018-01-31 01:05:38 Can't copy
  ./fsysbak/f.../fLocked/f00/attrib_dc793dc4650baa1a8cc3b69d211573c1
  to 
/vol/bpc4/BackupPC/pc/fs/147/./fsysbak/f.../fLocked/f00/attrib_dc793dc4650baa1a8cc3b69d211573c1
...

The last pair of messages is then repeated for thousands of files. 


It seems, that there is an error concerning the sequence. 

I had checked for several default reasons:
- No files or directories have been manipulated manually
- BackupPC is almost the only task running on my backup server (there
  should be no side effects from other services; no user is normally
  working on that machine)
- the file system has about 1.6 TB at a usage of 65% (this rate was
  never exceeded)
- the system had no crash (uptime is 217 days, since setup of
  BackupPC). 
- /vol/bpc4 is a mount point of an ext4 file system (normally very reliable)
- Kernel 4.1.39, OpenSuSE 42.1 - not really outdated




Any advice to repair this error is highly appretiated. 


Best regards


Torsten Finke



-- 

Torsten Finke
f...@igh.de

Ingenieurgemeinschaft IgH
Gesellschaft für Ingenieurleistungen mbH
Heinz-Bäcker-Str. 34
D-45356 Essen



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/