Re: [BackupPC-users] BackupPC 4.x on Raspberry PI?

[backuppc]

So far, I have recompiled my x86 Ubuntu debian packages for 4.0.4 for
the Pi and it seems to be working.
I am using without email or apache for now...

Will keep you all updated if issues arrive...

backu...@kosowsky.org wrote at about 11:19:37 -0500 on Sunday, January 3, 2021:
 > Has anybody had good success running BackupPC 4.x on a Raspberry PI?
 > 
 > I am considering either:
 > 1. (old) Pi 3 - Quad core  ARM Cortex-A53, 1.2GHz.
 >  1GB memory (with 256MB used for video)
 >  USB 2.0
 > 
 > 2. (new) Pi 4 - Quad core Cortex-A72 (ARM v8) 64-bit SoC @ 1.5GHz
 >  8GB memory
 >  USB 3.0
 > 
 > 
 > Note that I was able to get BackupPC 3.x to run reasonably well on a
 > very old plugcompute.
 >   500 MHZ single core ARM cpu
 >   500MB memory
 >   USB 2.0
 > 
 > How does 4.x compare with 3.x in terms of CPU and memory usage?
 > 
 > 
 > ___
 > 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 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] Checking rsync progress/speed/status

[Johan Ehnberg]

On 13.1.2021 0.58, Adam Goryachev via BackupPC-users wrote:


On 13/1/21 09:21, Les Mikesell wrote:
On Tue, Jan 12, 2021 at 4:15 PM Greg Harris 
 wrote:
Yeah, that “if you can interpret it” part gets really hard when it 
looks like:


select(7, [6], [], [6], {tv_sec=60, tv_usec=0}) = 1 (in [6], left 
{tv_sec=59, tv_usec=99})
read(6, 
"\0\200\0\0\4\200\0\7\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
32768) = 27748


Scrolling at 32756 lines in around 30 seconds.

That tells you it is not hung up.  You could grep some 'open's out of
the stream to see what files it is examining.  Sometimes the client
side will do a whole lot of reading before it finds something that
doesn't match what the server already has.


I tend to use something like:

strace -e open -p 

Also:

ls -l /proc//fd

Regards,
Adam



Here's another one to run on the host being backed up. It shows the file 
being backed up (read, not necessarily transferred) at any given time. 
You may want to tune the refresh rate; '0.1' is very rapid. '3r' can in 
theory vary between implementations.


sudo watch -n0.1 'lsof -c rsync | grep 3r'


Best regards,
Johan

--
Signature
*Johan Ehnberg*

Founder, CEO

Molnix Oy


jo...@molnix.com 

+358 50 320 96 88

molnix.com 


/The contents of this e-mail and its attachments are for the use of the 
intended recipient only, and are confidential and may contain legally 
privileged information. If you are not the intended recipient or have 
otherwise received the e-mail in error, please notify the sender by 
replying to this e-mail immediately and then delete it immediately from 
your system. Any dissemination, distribution, copying or use of this 
communication without prior and explicit permission of the sender is 
strictly prohibited./


/*Please consider the environment - do not print this e-mail unless you 
really need to.*/


___
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] Change in format of /usr/bin/rsync --server --sender command

Just posting this as a change in the format of the rsync server/sender
command tripped me up when I upgraded from rsync-bpc 3.0.9 to 3.1.2.

Specifically, I use my /etc/sudoers file to restrict the scope of the
backuppc and backuppc-client users as narrowly as possible.

For rsync_bpc < 3.1.x, the following worked:
 backuppc,backuppc-clientALL=NOPASSWD: /usr/bin/rsync 
--server--sender -slHogDtpAXrxe.iLsf, /usr/bin/rsync --server --sender 
-slHogDtpAXrcxe.iLsf
However, for rsync_bpc >= 3.1.x, the following is required:
 backuppc,backuppc-client   ALL=NOPASSWD: /usr/bin/rsync --server 
--sender -slHogDtpAXrxe.iLsfxC, /usr/bin/rsync --server --sender 
-slHogDtpAXrcxe.iLsfxC
where the extra characters 'xC' have been added.

Perhaps Craig can explain what additional options they signal...

Note the absence/presence of 'c' before the period corresponds to
incremental/full backups respectively.

Anyway, for the life of me, I couldn't figure out why rsync_bpc >3.1.x
wasn't working for me... until I figured this out... lots of wasted
time :(



___
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] Unexpected backup renumbering after failed backup

After a failed incremental backup, my last *old* *good* backup was
renumbered.

Specifically before the failed backup:

   484   incr   yes 1  2021-01-12 01:00 3.5 0.9
   482   incr   no  1  2021-01-11 01:02 8.1 1.9
   481   full   yes 0  2021-01-10 01:00 33.82.9

After failed backup:
   484   incr   yes 1  2021-01-12 01:00 3.5 0.9
   483   incr   no  1  2021-01-11 01:02 8.1 1.9
   481   full   yes 0  2021-01-10 01:00 33.82.9


The log shows the following:
2021-01-12 01:03:32 incr backup 483 complete, 309199 files, 25749468485 
bytes, 0 xferErrs (0 bad files, 0 bad shares, 0 other)
2021-01-12 01:03:32 Removing unfilled backup 466
2021-01-12 01:03:32 BackupPC_backupDelete: removing #466
2021-01-12 01:03:32 BackupPC_backupDelete: No prior backup for merge
2021-01-12 01:03:38 BackupPC_refCountUpdate: host consult got 0 errors 
(took 5 secs)
2021-01-12 01:03:38 Finished BackupPC_backupDelete, status = 0 (running 
time: 6 sec)
2021-01-12 20:42:40 incr backup started for directory root (client path 
/mnt/btrfs-root/@_snapshot-backuppc-20210112-204239)
2021-01-12 20:42:41 Got fatal error during xfer (rsync error: error in 
rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.2.2])
2021-01-12 20:42:46 Backup aborted (rsync error: error in rsync protocol 
data stream (code 12) at io.c(226) [Receiver=3.1.2.2])
2021-01-12 20:42:46 Removing empty backup #483
2021-01-12 20:42:46 BackupPC_backupDelete: removing #483
2021-01-12 20:42:46 BackupPC_backupDelete: Merge into backup 482
2021-01-12 20:43:01 BackupPC_refCountUpdate: host consult got 0 errors 
(took 15 secs)
2021-01-12 20:43:01 Finished BackupPC_backupDelete, status = 0 (running 
time: 15 sec)

where #466 was an expiring (incremental) - note it was created ~2 weeks
earlier per the following log line:
   2020-12-26 01:02:51 incr backup 466 complete, 309576 files, 25813786934 
bytes, 0 xferErrs (0 bad files, 0 bad shares, 0 other)

So, why does an aborted backup cause the old (good) backup #483 to
jump to #484, leaving an empty backup in #483.

I assume this is due to how backups are merged forward -- but it would
be nice, if this were undone, when a backup is aborted -- if only to
keep the backup history tight and consistent. Indeed, this
renumbering, can make it hard to "track" backups as their numbers can
change.


___
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] Backup renumbering after failed backup

[backuppc]

After a failed incremental backup, my last *old* *good* backup was
renumbered.

Specifically before the failed backup:

   484   incr   yes 1  2021-01-12 01:00 3.5 0.9
   482   incr   no  1  2021-01-11 01:02 8.1 1.9
   481   full   yes 0  2021-01-10 01:00 33.82.9

After failed backup:
   484   incr   yes 1  2021-01-12 01:00 3.5 0.9
   483   incr   no  1  2021-01-11 01:02 8.1 1.9
   481   full   yes 0  2021-01-10 01:00 33.82.9


The log shows the following:
2021-01-12 01:03:32 incr backup 483 complete, 309199 files, 25749468485 
bytes, 0 xferErrs (0 bad files, 0 bad shares, 0 other)
2021-01-12 01:03:32 Removing unfilled backup 466
2021-01-12 01:03:32 BackupPC_backupDelete: removing #466
2021-01-12 01:03:32 BackupPC_backupDelete: No prior backup for merge
2021-01-12 01:03:38 BackupPC_refCountUpdate: host consult got 0 errors 
(took 5 secs)
2021-01-12 01:03:38 Finished BackupPC_backupDelete, status = 0 (running 
time: 6 sec)
2021-01-12 20:42:40 incr backup started for directory root (client path 
/mnt/btrfs-root/@_snapshot-backuppc-20210112-204239)
2021-01-12 20:42:41 Got fatal error during xfer (rsync error: error in 
rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.2.2])
2021-01-12 20:42:46 Backup aborted (rsync error: error in rsync protocol 
data stream (code 12) at io.c(226) [Receiver=3.1.2.2])
2021-01-12 20:42:46 Removing empty backup #483
2021-01-12 20:42:46 BackupPC_backupDelete: removing #483
2021-01-12 20:42:46 BackupPC_backupDelete: Merge into backup 482
2021-01-12 20:43:01 BackupPC_refCountUpdate: host consult got 0 errors 
(took 15 secs)
2021-01-12 20:43:01 Finished BackupPC_backupDelete, status = 0 (running 
time: 15 sec)

where #466 was an expiring (incremental) - note it was created ~2 weeks
earlier per the following log line:
   2020-12-26 01:02:51 incr backup 466 complete, 309576 files, 25813786934 
bytes, 0 xferErrs (0 bad files, 0 bad shares, 0 other)

So, why does an aborted backup cause the old (good) backup #483 to
jump to #484, leaving an empty backup in #483.

I assume this is due to how backups are merged forward -- but it would
be nice, if this were undone, when a backup is aborted -- if only to
keep the backup history tight and consistent. Indeed, this
renumbering, can make it hard to "track" backups as their numbers can
change.


___
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] Checking rsync progress/speed/status

[Adam Goryachev via BackupPC-users]

On 13/1/21 09:21, Les Mikesell wrote:

On Tue, Jan 12, 2021 at 4:15 PM Greg Harris  wrote:

Yeah, that “if you can interpret it” part gets really hard when it looks like:

select(7, [6], [], [6], {tv_sec=60, tv_usec=0}) = 1 (in [6], left {tv_sec=59, 
tv_usec=99})
read(6, 
"\0\200\0\0\4\200\0\7\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
32768) = 27748

Scrolling at 32756 lines in around 30 seconds.

That tells you it is not hung up.  You could grep some 'open's out of
the stream to see what files it is examining.  Sometimes the client
side will do a whole lot of reading before it finds something that
doesn't match what the server already has.


I tend to use something like:

strace -e open -p 

Also:

ls -l /proc//fd

Regards,
Adam



___
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] Checking rsync progress/speed/status

[backuppc]

Additionally, 'top' only tells you what is happening now (or in the
last few second sampling period).

What I really want to know is when was the last time data was
successfully transferred across the rsync/ssh pipe which generally
would signal that the backup is progressing vs. being stalled on a
yet-to-happen timeout.

The challenge of course is that you want to set the rsync timeout long
enough so that backups don't get inadvertently interrupted, but still
you may want to check on what is happening in case you suspect
something has broken the connection rather than waiting for rsync to
officially time out many minutes or hours later...

Would be very nice to get a better picture of this :)

Greg Harris wrote at about 20:08:33 + on Tuesday, January 12, 2021:
 > While all of that is true, the answers so far still seem to be kind of like 
 > looking at the parking lot outside the ice hockey arena.  (Well, at least, 
 > pre-Covid days anyways.)  Is there a game going on or is it a pre-game show 
 > listing players?  Is the zamboni on the ice?  Which game is in which rink?  
 > Are there injuries? How much time is left?  Who’s being penalized and why?  
 > I’ve yet to find a solid way to peer into the arena of BackupPC and find 
 > answers to these types of questions.
 > 
 > Thanks,
 > 
 > Greg Harris
 > 
 > On Jan 12, 2021, at 2:09 PM, Doug Lytle 
 > mailto:supp...@drdos.info>> wrote:
 > 
 > I tend to look in the top, if rsync is in progres, it its some CPU. It
 > 
 > iotop would be another method
 > 
 > You could also try following the rsync process with strace
 > 
 > Doug
 > 
 > 
 > ___
 > 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 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 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] Checking rsync progress/speed/status

[Les Mikesell]

On Tue, Jan 12, 2021 at 4:15 PM Greg Harris  wrote:
>
> Yeah, that “if you can interpret it” part gets really hard when it looks like:
>
> select(7, [6], [], [6], {tv_sec=60, tv_usec=0}) = 1 (in [6], left {tv_sec=59, 
> tv_usec=99})
> read(6, 
> "\0\200\0\0\4\200\0\7\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
> 32768) = 27748
>
> Scrolling at 32756 lines in around 30 seconds.

That tells you it is not hung up.  You could grep some 'open's out of
the stream to see what files it is examining.  Sometimes the client
side will do a whole lot of reading before it finds something that
doesn't match what the server already has.
-- 
  Les Mikesell
lesmikes...@gmail.com


___
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] Checking rsync progress/speed/status

[Greg Harris]

Yeah, that “if you can interpret it” part gets really hard when it looks like:

select(7, [6], [], [6], {tv_sec=60, tv_usec=0}) = 1 (in [6], left {tv_sec=59, 
tv_usec=99})
read(6, 
"\0\200\0\0\4\200\0\7\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
32768) = 27748

Scrolling at 32756 lines in around 30 seconds.

Thanks,

Greg Harris

On Jan 12, 2021, at 5:02 PM, Les Mikesell 
mailto:lesmikes...@gmail.com>> wrote:

On Tue, Jan 12, 2021 at 2:24 PM Greg Harris 
mailto:ghar...@teamexpansion.org>> wrote:

I’ve yet to find a solid way to peer into the arena of BackupPC and
find answers to these types of questions.

Strace'ing the rsync process - possibly at both ends - gives you a
pretty detailed view of what is happening if you can interpret it.

--
   Les Mikesell
lesmikes...@gmail.com


___
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 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] Checking rsync progress/speed/status

[Les Mikesell]

On Tue, Jan 12, 2021 at 2:24 PM Greg Harris  wrote:
>
 I’ve yet to find a solid way to peer into the arena of BackupPC and
find answers to these types of questions.

Strace'ing the rsync process - possibly at both ends - gives you a
pretty detailed view of what is happening if you can interpret it.

-- 
Les Mikesell
 lesmikes...@gmail.com


___
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] No backup seeding

[Jan Stransky]

Any ideas? Sorry, it is bugging me... I tried many different things...
Command from the log below. Notice the lastBkupNUm = and last Bkup Idx =
It works on every other client. The bad think is, that this is the 
biggest one...

Help would be much appreciated.

XferLOG file /data/backuppc/pc/edita/XferLOG.1558.z created 2021-01-12 
20:46:11
Backup prep: type = incr, case = 5, inPlace = 1, doDuplicate = 0, 
newBkupNum = 1558, newBkupIdx = 38, lastBkupNum = , lastBkupIdx = 
(FillCycle = 0, noFillCnt = 4)
Running: /usr/local/bin/rsync_bpc --bpc-top-dir /data/backuppc 
--bpc-host-name edita --bpc-share-name /home --bpc-bkup-num 1558 
--bpc-bkup-comp 3 --bpc-bkup-prevnum -1 --bpc-bkup-prevcomp -1 
--bpc-bkup-inode0 21038920 --bpc-log-level


On 1/11/21 7:04 PM, Jan Stransky wrote:

I just found, that the issue occurs only with one client, another was fine.

On 1/11/21 6:36 PM, Jan Stransky wrote:

Hi,
sorry for another one, but I did not have a need to ask questions here 
for couple years by now :-D


Under which circumstances the backup proces does not use earlier 
backups as seed (e.g. rsync_bpc --bpc-bkup-prevnum -1 
--bpc-bkup-prevcomp -1)


I have moved my instance and the data to a new HW, the instance sees 
old backup, I can recover the old files, and even the backup process 
sees the pool (based on log entries for individual files), but none of 
the backups used the previous ones to start with. The backups are 
incremental, but from older logs I noticed, that the reference to the 
older backup was set for full too.


Jan



___
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] Checking rsync progress/speed/status

[Greg Harris]

While all of that is true, the answers so far still seem to be kind of like 
looking at the parking lot outside the ice hockey arena.  (Well, at least, 
pre-Covid days anyways.)  Is there a game going on or is it a pre-game show 
listing players?  Is the zamboni on the ice?  Which game is in which rink?  Are 
there injuries? How much time is left?  Who’s being penalized and why?  I’ve 
yet to find a solid way to peer into the arena of BackupPC and find answers to 
these types of questions.

Thanks,

Greg Harris

On Jan 12, 2021, at 2:09 PM, Doug Lytle 
mailto:supp...@drdos.info>> wrote:

I tend to look in the top, if rsync is in progres, it its some CPU. It

iotop would be another method

You could also try following the rsync process with strace

Doug


___
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 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] Checking rsync progress/speed/status

[Doug Lytle]

>>> I tend to look in the top, if rsync is in progres, it its some CPU. It

iotop would be another method

You could also try following the rsync process with strace

Doug


___
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] Checking rsync progress/speed/status

[Jan Stransky]

I tend to look in the top, if rsync is in progres, it its some CPU. It 
does not, if it hangs.

Jan

On 1/12/21 6:04 PM, backu...@kosowsky.org wrote:

Short of waiting for 'rsync' to timeout, is there any way to see the
current status of an rsync backuppc backup, such as:
- Current average 'transfer rate'
- Time last byte was transferred

Sometimes, especially when backing up laptops, it's hard to know if
the ssh connection has been disrupted and whether rsync is hanging or
not.

I know there are kluges such as looking at
   watch "lsof -nw -u backuppc | egrep ' (REG|DIR) ' | awk '{print $9}'"
Or one can watch the logs...

But it would be good if there were a way to see the actual status of
rsync transfers...


___
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 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] Checking rsync progress/speed/status

[backuppc]

Short of waiting for 'rsync' to timeout, is there any way to see the
current status of an rsync backuppc backup, such as:
- Current average 'transfer rate'
- Time last byte was transferred

Sometimes, especially when backing up laptops, it's hard to know if
the ssh connection has been disrupted and whether rsync is hanging or
not.

I know there are kluges such as looking at
  watch "lsof -nw -u backuppc | egrep ' (REG|DIR) ' | awk '{print $9}'"
Or one can watch the logs...

But it would be good if there were a way to see the actual status of
rsync transfers...


___
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] Vanished file

[Pete Geenhuizen]

Craig,
Thanks for looking into this been using BackupPC for many years and have 
been very happy with the way it has performed.
I'm glad that the info I provided was of some use and hopefully it helps 
in resolving the bug.  Other than a bit annoying to see the error this 
issue isn't affecting me in any way.

If you need any more info please let me know.
Pete

On 1/11/21 11:32 PM, Craig Barratt wrote:

Pete,

Thanks for the additional information.  It's definitely a bug (same 
one reported by Alexander), and it's certainly due to the significant 
rewrite I did between rsync-bpc 3.1.2 and 3.1.3 on how long strings 
(used in many places for file names, paths etc) are handled.  Somehow 
the file name (which should be "alt-java.1.gz") added to the 
attributes for that directory is incorrectly set to a mangled attrib 
directory path instead.


A secondary issue is why it doesn't recover on a subsequent full 
backup (likely because the incorrectly added file name contains "/", 
so an attempt to unlink (remove) that file causes it to refer to a 
deeper directory, which fails).


I've been looking at the code for how symlinks are handled, but 
haven't yet found the bug.


Craig

On Tue, Jan 12, 2021 at 10:01 AM Pete Geenhuizen 
mailto:pgeenhui...@gmail.com>> wrote:


Craig,
# su -m backuppc -c '/usr/share/BackupPC/bin/BackupPC_zcat
9dea1ea7cd900fa4fcd3e24f86ad0be8'

/usr/share/man/man1/alt-java-java-1.8.0-openjdk-1.8.0.275.b01-0.el7_9.x86_64.1.gz

Not sure if this is useful but
$ ls -l /usr/share/man/man1/alt-java*
lrwxrwxrwx 1 root root    31 Dec 18 08:08
/usr/share/man/man1/alt-java.1.gz -> /etc/alternatives/alt-java.1.gz
-rw-r--r-- 1 root root 25788 Dec 16 12:29

/usr/share/man/man1/alt-java-java-1.8.0-openjdk-1.8.0.275.b01-0.el7_9.x86_64.1.gz

$ ls -l /etc/alternatives/alt-java*
lrwxrwxrwx 1 root root 77 Dec 18 08:08 /etc/alternatives/alt-java
->

/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.275.b01-0.el7_9.x86_64/jre/bin/alt-java
lrwxrwxrwx 1 root root 81 Dec 18 08:08
/etc/alternatives/alt-java.1.gz ->

/usr/share/man/man1/alt-java-java-1.8.0-openjdk-1.8.0.275.b01-0.el7_9.x86_64.1.gz

Pete

On 1/11/21 5:15 PM, Craig Barratt wrote:

Pete,

Thanks for that.  Yes, this is exactly the same issue that
Alexander reported:
https://github.com/backuppc/rsync-bpc/issues/18


One more step: what's the output from:

BackupPC_zcat 9dea1ea7cd900fa4fcd3e24f86ad0be8

Thanks,
Craig

On Mon, Jan 11, 2021 at 10:32 PM Pete Geenhuizen
mailto:pgeenhui...@gmail.com>> wrote:

Thank you for the correct syntax here's what I get now.

  'froot/fetc/falternatives/attrib' => {
    'compress' => 3,
    'digest' => '9dea1ea7cd900fa4fcd3e24f86ad0be8',
    'gid' => 0,
    'inode' => 562108,
    'mode' => 511,
    'mtime' => 0,
    'name' => 'froot/fetc/falternatives/attrib',
    'nlinks' => 0,
    'size' => 81,
    'type' => 2,
    'uid' => 0
  },
  'print-lprman' => {


On 1/11/21 3:33 AM, Alexander Moisseev via BackupPC-users wrote:

11.01.2021 3:07, backu...@kosowsky.org
 пишет:

Pete Geenhuizen wrote at about 14:38:17 -0500 on Sunday,
January 10, 2021:
  >
  > /usr/share/BackupPC/bin/BackupPC_zcat
  > ./attrib_d4c95788f1e2e67ddadd2e2ff26e0fc6 |wc
  >    0   0   0
  >
  > /usr/share/BackupPC/bin/BackupPC_attribPrint
  > /etc/alternatives/froot/fetc/falternatives/attrib
  > $attrib = {
  > };
  > All the attrib_ files that I find are 0 length.

They all should be 0 length - they just reference a pool
file where
the data is stored.



You should use BackupPC_attribPrint utility to get the
metadata:

# su -m backuppc -c 'BackupPC_attribPrint
./attrib_d4c95788f1e2e67ddadd2e2ff26e0fc6' | grep -A 6 /attrib


___
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/




-- 
Unencumbered by the thought process.

  -- Click and Clack the Tappet brothers


-- 
This message has been scanned for viruses and

dangerous content by *MailScanner*
, and is
believed to be clean.
 

Re: [BackupPC-users] Vanished file

[Craig Barratt via BackupPC-users]

It should only affect rsync-bpc 3.1.3+.  3.1.2 and 3.0.9 use the original
style of handling long path and filename strings (just a large fixed size
is used).

Craig

On Tue, Jan 12, 2021 at 5:28 PM  wrote:

> Craig Barratt via BackupPC-users wrote at about 15:32:27 +1100 on Tuesday,
> January 12, 2021:
>  > Pete,
>  >
>  > Thanks for the additional information.  It's definitely a bug (same one
>  > reported by Alexander), and it's certainly due to the significant
> rewrite I
>  > did between rsync-bpc 3.1.2 and 3.1.3 on how long strings (used in many
>  > places for file names, paths etc) are handled.
>
> Ahhh, I am still on 3.09 -- in part, because I had trouble compiling
> 3.1.2 and 3.1.3 (a blessing maybe in disguise).
>
> So just confirming that this bug only affects 3.1.2+???
>
> 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/
>
___
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/