backuppc-users — General list for user discussion, questions and support

Re: [BackupPC-users] installing backuppc-xs locally

[daggs <da...@gm...>]

Greetings Michael,

> Sent: Friday, November 14, 2025 at 6:00 PM
> From: "Michael Stowe" <ms...@ba...>
> To: "General list for user discussion, questions and support" <bac...@li...>
> Cc: "daggs" <da...@gm...>
> Subject: Re: [BackupPC-users] installing backuppc-xs locally
>
> On 2025-11-14 06:03, daggs via BackupPC-users wrote:
> > Greetings,
> > 
> > as alpine linux doesn't provide backuppc, I'd like to build it, but I 
> > don't want the installation to be to the /, I want it locally under my 
> > home folder, rsync-bpc works, now I'm
> > tackling backuppc-xs, is there a way to install it locally?
> > 
> > Thanks
> > 
> > Dagg
> 
> 
> It would seem harder to install remotely.  Isn't anything you install, 
> installed locally?
> 
> It's Linux.  Install things wherever you want.  Not that this is a best 
> practice, but it would be very hard for any software to prevent you from 
> doing so.
> 

as usual, I didn't explained myself properly, by locally I means locally to the user, e.g. inside his home folder and not the default location at /
my apologies for not being clear.

Dagg

Re: [BackupPC-users] debian patch for localconfig.pl

[<bac...@ko...>]

+++ I like the feature.
I too get by now with sprinkled edits in the config file as well as
per host backups and links (but those need to be copied to each
host or host class (when using links).
Would be great to have local config that cleanly overrides general
setting that I want to apply across my setup.

Paul Fox wrote at about 14:31:03 -0500 on Thursday, November 13, 2025:
 > A couple of years ago I filed a backuppc issue on github
 > (https://github.com/backuppc/backuppc/issues/486) complaining that
 > localconfig.pl wasn't documented.  It turns out that it's a Debian
 > addition, courtesy of their patches when packaging backuppc.  I had
 > learned this a while ago, and I apologize to Ged for not updating the
 > github issue (which I confess I'd forgotten about).
 > 
 > Anyway, Ged just asked whether it's useful, and whether the
 > functionality should move into backuppc proper.
 > 
 > Well, at some point, when I wasn't sure whether localconfig.pl was a
 > feature I should be relying on, I decided to simply move all of my
 > local config onto the tail of config.pl.  (Previously it had been
 > sprinkled throughout, with bits of comment here and there telling me
 > why I'd changed something or other.)   Putting it all at the end isn't
 > quite as clean, management-wise, as having local changes in a separate
 > file, but at least it keeps the release-to-release diffs clean(er), which
 > is important at system upgrade time.
 > 
 > So I'm not going to champion the feature too hard, even though I think
 > it's a good idea.  I have an adequate workaround.  But if anyone else
 > uses it, and/or thinks it should become permanent in all packages, I
 > can't imagine it would be a lot of work for it to be implemented.  And
 > I'd probably start using it again in that case.
 > 
 > paul
 > =----------------------
 >  paul fox, pg...@fo... (arlington, ma, where it's 48.6 degrees)
 > 
 > 
 > 
 > _______________________________________________
 > BackupPC-users mailing list
 > Bac...@li...
 > 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] debian patch for localconfig.pl

[Paul F. <pg...@fo...>]

jbk wrote:
 > Unless I'm misunderstanding this, is the localconfig.pl to 
 > define a backup schedule for the server?

No, not specifically.  It holds any configuration you might otherwise
put in config.pl, which is read prior to localconfig.pl.  All it
really does is let you segregate local changes from distributed
changes, if that's useful to the administrator.

Honestly, now that we're talking about it, I can't see why this shouldn't
just be added to backuppc as a permanent feature.  It's pretty lightweight,
and useful.  So I guess I'm championing it after all.

paul
=----------------------
paul fox, pg...@fo... (arlington, ma, where it's 43.6 degrees)

Re: [BackupPC-users] debian patch for localconfig.pl

[jbk <jb...@kj...>]

On 11/13/25 2:31 PM, Paul Fox wrote:
> A couple of years ago I filed a backuppc issue on github
> (https://github.com/backuppc/backuppc/issues/486) complaining that
> localconfig.pl wasn't documented.  It turns out that it's a Debian
> addition, courtesy of their patches when packaging backuppc.  I had
> learned this a while ago, and I apologize to Ged for not updating the
> github issue (which I confess I'd forgotten about).
>
> Anyway, Ged just asked whether it's useful, and whether the
> functionality should move into backuppc proper.
>
> Well, at some point, when I wasn't sure whether localconfig.pl was a
> feature I should be relying on, I decided to simply move all of my
> local config onto the tail of config.pl.  (Previously it had been
> sprinkled throughout, with bits of comment here and there telling me
> why I'd changed something or other.)   Putting it all at the end isn't
> quite as clean, management-wise, as having local changes in a separate
> file, but at least it keeps the release-to-release diffs clean(er), which
> is important at system upgrade time.
>
> So I'm not going to champion the feature too hard, even though I think
> it's a good idea.  I have an adequate workaround.  But if anyone else
> uses it, and/or thinks it should become permanent in all packages, I
> can't imagine it would be a lot of work for it to be implemented.  And
> I'd probably start using it again in that case.
>
> paul
> =----------------------
>   paul fox, pg...@fo... (arlington, ma, where it's 48.6 degrees)
>
>
>

Unless I'm misunderstanding this, is the localconfig.pl to 
define a backup schedule for the server?
I eventually accomplished this by identifying the server as 
a named host <servername.pl> in the list of hosts to backup. 
It took a bit of trial and error to set it up and help from 
this list many years ago. So yes it would be helpful to have 
a sample script to achieve this since it is not part of the 
documentation.

-- 
Jim KR

[BackupPC-users] installing backuppc-xs locally

[daggs <da...@gm...>]

Greetings,

as alpine linux doesn't provide backuppc, I'd like to build it, but I don't want the installation to be to the /, I want it locally under my home folder, rsync-bpc works, now I'm
tackling backuppc-xs, is there a way to install it locally?

Thanks

Dagg

Re: [BackupPC-users] Backups are performed but are empty

[G.W. H. <ba...@ju...>]

Hi there,

On Fri, 14 Nov 2025, J?rg Ehrchen wrote:

> As is so often the case, the problem was ... me. :-(

Around here somewhere there's a tee-shirt...

> ... Without you, I would probably still be searching.

Well, thank *you*!  Suddenly it all seems worth-while. :)

-- 

73,
Ged.

Re: [BackupPC-users] Backups are performed but are empty

[Jörg E. <j.e...@un...>]

I can now rule out that we were hacked or caught a virus.
As is so often the case, the problem was sitting right in front of the 
monitor and keyboard: me. :-(
I was able to trace it using the backups from the backuppc server. By 
default, /etc is backed up.
We use a Univention Corporate Server as a domain controller with a Samba 
server for the AD domain.
When the change to config.pl took place, I tried to configure backuppc 
to back up /etc of the domain controller.
It is not possible to change the ssh port on the domain controller, as 
otherwise the Linux domain would not function properly.
Since it was not possible to back up the domain controller using either 
tar or rsync, I had the "brilliant" idea of trying rsyncd.
In doing so, I accidentally saved the change in config.pl instead of 
saving it in the domain controller's config files.
Before the change, config.pl contained $Conf{XferMethod}=rsync and 
$Conf{RsyncClientPath}= "c:\\Program Files\\OpenSSH\\vss.exe".
Afterwards, $Conf{XferMethod}=rsyncd and 
$Conf{RsyncClientPath}=/usr/bin/rsync. Of course, /usr/bin/rsync does 
not exist on Windows clients.
Small change, big impact.
Thanks again for your help. Without you, I would probably still be 
searching.

Greetings

Jörg

-- 
Unrast Verlag
Jörg Ehrchen
Fuggerstr. 13a
48165 Münster

Email:j.e...@un...

Tel: 02581/4580083

Re: [BackupPC-users] Nightly routine running at the same time as backups

[Jamie B. <ja...@ib...>]

Hi



I thought that the blackout period meant that no _*backups*_ would take
place. So in my example, backuppc wakes up every hour but doesn’t backup
between 6-23 but the nightly would run at 8?



Best regards

Jamie



*From:* Christian Völker via BackupPC-users <
bac...@li...>
*Sent:* 14 November 2025 10:56
*To:* bac...@li...
*Cc:* Christian Völker <cvo...@kn...>
*Subject:* Re: [BackupPC-users] Nightly routine running at the same time as
backups



Hi,

as you worded: it is not critical. Obviously, it might affect performance.
No curruption in case they run in parallel.

You should schedule it to a time when backups only run rarely. Possibly not
at the same time when most backups start. So for your case with the
blackout period from 6-23 I would prefer to have the BackupPC_nightly run
at 5 (when most backups are done through the night). So your first entry
there should be "5".

I am unsure how the WackeupSchedule and the blackout periods work together.
>From my point your current settings do not match each other... I guess the
blackout period overwrites the wakeups...

However, set it to 5 and in most cases there should be no backup in
parallel (as long as your backup windows has enough slots to backup all
scheduled hosts).

/Christian



Am 14.11.25 um 11:35 schrieb Jamie Burchell via BackupPC-users:

Hi



>From the way that is worded, it sounds like having BackupPC_nightly running
at the same time as backups is not a critical issue but possibly
undesirable. Maybe due to performance reasons? Or is my data silently being
corrupted? Maybe it would explain why I’m sometimes getting missing pool
files?



I have a blackout period between “6 – 23”, so I have now set my wakeup
schedule to “8, 1, 2, 3, 4, 5, 6, 7, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18,
19, 20, 21, 22, 23”.



I’m assuming this is the approach I need to take?



Thanks

Jamie





*From:* Christian Völker via BackupPC-users <
bac...@li...>
*Sent:* 14 November 2025 09:38
*To:* bac...@li...
*Cc:* Christian Völker <cvo...@kn...>
*Subject:* Re: [BackupPC-users] Nightly routine running at the same time as
backups



Hi,

from documentation:

The first entry of $Conf{WakeupSchedule}
<https://backuppc42.knebb.de/backuppc/index.cgi?action=view&type=docs#_conf_wakeupschedule_>
is when BackupPC_nightly is run. You might want to re-arrange the entries
in $Conf{WakeupSchedule}
<https://backuppc42.knebb.de/backuppc/index.cgi?action=view&type=docs#_conf_wakeupschedule_>
(they don't have to be ascending) so that the first entry is when you want
BackupPC_nightly to run (eg: when you don't expect a lot of regular backups
to run).

So there is your solution...

Greetings

/Christian

Am 14.11.25 um 08:25 schrieb Jamie Burchell via BackupPC-users:

Hi all



According to the status page at 01:00, the two nightly jobs ran at the same
time as a handful of backups. Is it safe/normal for the nightly routine to
run at the same time as backups?



Thanks in advance

Jamie



_______________________________________________

BackupPC-users mailing list

Bac...@li...

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

Bac...@li...

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] Nightly routine running at the same time as backups

[Christian V. <cvo...@kn...>]

Hi,

as you worded: it is not critical. Obviously, it might affect 
performance. No curruption in case they run in parallel.

You should schedule it to a time when backups only run rarely. Possibly 
not at the same time when most backups start. So for your case with the 
blackout period from 6-23 I would prefer to have the BackupPC_nightly 
run at 5 (when most backups are done through the night). So your first 
entry there should be "5".

I am unsure how the WackeupSchedule and the blackout periods work 
together. From my point your current settings do not match each other... 
I guess the blackout period overwrites the wakeups...

However, set it to 5 and in most cases there should be no backup in 
parallel (as long as your backup windows has enough slots to backup all 
scheduled hosts).

/Christian




Am 14.11.25 um 11:35 schrieb Jamie Burchell via BackupPC-users:
>
> Hi
>
> From the way that is worded, it sounds like having BackupPC_nightly 
> running at the same time as backups is not a critical issue but 
> possibly undesirable. Maybe due to performance reasons? Or is my data 
> silently being corrupted? Maybe it would explain why I’m sometimes 
> getting missing pool files?
>
> I have a blackout period between “6 – 23”, so I have now set my wakeup 
> schedule to “8, 1, 2, 3, 4, 5, 6, 7, 9, 10, 11, 12, 13, 14, 15, 16, 
> 17, 18, 19, 20, 21, 22, 23”.
>
> I’m assuming this is the approach I need to take?
>
> Thanks
>
> Jamie
>
> *From:*Christian Völker via BackupPC-users 
> <bac...@li...>
> *Sent:* 14 November 2025 09:38
> *To:* bac...@li...
> *Cc:* Christian Völker <cvo...@kn...>
> *Subject:* Re: [BackupPC-users] Nightly routine running at the same 
> time as backups
>
> Hi,
>
> from documentation:
>
> The first entry of $Conf{WakeupSchedule} 
> <https://backuppc42.knebb.de/backuppc/index.cgi?action=view&type=docs#_conf_wakeupschedule_> 
> is when BackupPC_nightly is run. You might want to re-arrange the 
> entries in $Conf{WakeupSchedule} 
> <https://backuppc42.knebb.de/backuppc/index.cgi?action=view&type=docs#_conf_wakeupschedule_> 
> (they don't have to be ascending) so that the first entry is when you 
> want BackupPC_nightly to run (eg: when you don't expect a lot of 
> regular backups to run).
>
> So there is your solution...
>
> Greetings
>
> /Christian
>
> Am 14.11.25 um 08:25 schrieb Jamie Burchell via BackupPC-users:
>
>     Hi all
>
>     According to the status page at 01:00, the two nightly jobs ran at
>     the same time as a handful of backups. Is it safe/normal for the
>     nightly routine to run at the same time as backups?
>
>     Thanks in advance
>
>     Jamie
>
>
>
>
>     _______________________________________________
>
>     BackupPC-users mailing list
>
>     Bac...@li...
>
>     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
> Bac...@li...
> 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] Nightly routine running at the same time as backups

[Jamie B. <ja...@ib...>]

Hi



>From the way that is worded, it sounds like having BackupPC_nightly running
at the same time as backups is not a critical issue but possibly
undesirable. Maybe due to performance reasons? Or is my data silently being
corrupted? Maybe it would explain why I’m sometimes getting missing pool
files?



I have a blackout period between “6 – 23”, so I have now set my wakeup
schedule to “8, 1, 2, 3, 4, 5, 6, 7, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18,
19, 20, 21, 22, 23”.



I’m assuming this is the approach I need to take?



Thanks

Jamie





*From:* Christian Völker via BackupPC-users <
bac...@li...>
*Sent:* 14 November 2025 09:38
*To:* bac...@li...
*Cc:* Christian Völker <cvo...@kn...>
*Subject:* Re: [BackupPC-users] Nightly routine running at the same time as
backups



Hi,

from documentation:

The first entry of $Conf{WakeupSchedule}
<https://backuppc42.knebb.de/backuppc/index.cgi?action=view&type=docs#_conf_wakeupschedule_>
is when BackupPC_nightly is run. You might want to re-arrange the entries
in $Conf{WakeupSchedule}
<https://backuppc42.knebb.de/backuppc/index.cgi?action=view&type=docs#_conf_wakeupschedule_>
(they don't have to be ascending) so that the first entry is when you want
BackupPC_nightly to run (eg: when you don't expect a lot of regular backups
to run).

So there is your solution...

Greetings

/Christian

Am 14.11.25 um 08:25 schrieb Jamie Burchell via BackupPC-users:

Hi all



According to the status page at 01:00, the two nightly jobs ran at the same
time as a handful of backups. Is it safe/normal for the nightly routine to
run at the same time as backups?



Thanks in advance

Jamie




_______________________________________________

BackupPC-users mailing list

Bac...@li...

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] Nightly routine running at the same time as backups

[Christian V. <cvo...@kn...>]

Hi,

from documentation:

The first entry of $Conf{WakeupSchedule} 
<https://backuppc42.knebb.de/backuppc/index.cgi?action=view&type=docs#_conf_wakeupschedule_> 
is when BackupPC_nightly is run. You might want to re-arrange the 
entries in $Conf{WakeupSchedule} 
<https://backuppc42.knebb.de/backuppc/index.cgi?action=view&type=docs#_conf_wakeupschedule_> 
(they don't have to be ascending) so that the first entry is when you 
want BackupPC_nightly to run (eg: when you don't expect a lot of regular 
backups to run).

So there is your solution...

Greetings

/Christian


Am 14.11.25 um 08:25 schrieb Jamie Burchell via BackupPC-users:
>
> Hi all
>
> According to the status page at 01:00, the two nightly jobs ran at the 
> same time as a handful of backups. Is it safe/normal for the nightly 
> routine to run at the same time as backups?
>
> Thanks in advance
>
> Jamie
>
>
>
> _______________________________________________
> BackupPC-users mailing list
> Bac...@li...
> List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki:https://github.com/backuppc/backuppc/wiki
> Project:https://backuppc.github.io/backuppc/

[BackupPC-users] Nightly routine running at the same time as backups

[Jamie B. <ja...@ib...>]

Hi all



According to the status page at 01:00, the two nightly jobs ran at the same
time as a handful of backups. Is it safe/normal for the nightly routine to
run at the same time as backups?



Thanks in advance

Jamie

Re: [BackupPC-users] debian patch for localconfig.pl

[<to...@tu...>]

On Thu, Nov 13, 2025 at 02:31:03PM -0500, Paul Fox wrote:
> A couple of years ago I filed a backuppc issue on github
> (https://github.com/backuppc/backuppc/issues/486) complaining that
> localconfig.pl wasn't documented.  It turns out that it's a Debian
> addition, courtesy of their patches when packaging backuppc.  I had
> learned this a while ago, and I apologize to Ged for not updating the
> github issue (which I confess I'd forgotten about).

Perhaps then it would be a good idea to CC Debian's maintainer
team for backuppc: <tea...@tr...>?

Cheers
-- 
tomás

Re: [BackupPC-users] BackupPC in a commercial setting / support status

[G.W. H. <ba...@ju...>]

Hi there,

On Tue, 3 Jun 2025, Steven Benbow wrote:

> ... if something can be put in place we would be interested to
> participate further with some minor developments (UI tweaks etc.)
> that we've been considering.  But in the first instance a new
> release, just so that we can point to a 2025 version, would
> certainly help!

Yesterday I released version 0.63 of BackupPC-XS on Github.

This evening I also released version 4.4.1rc1 of BackupPC itself.

You can get them both by downloading the master branch 'Zip' file, or
by cloning with git.

The new version of BackupPC requires the new version of BackupPC-XS,
although you can use version 0.62 if you make a one-character change
to the .../bin/BackupPC Perl script which specifies 0.63.

Although I'm running them here on a production server, please consider
them experimental at this stage.  As - obviously - they have not been
packaged by any distribution, if you want to test them they will need
to be installed from source.  I expect BackupPC-XS 0.63 builds to be a
source of entertainment for quite some time.

These releases are completely compatible with backups made by V4.4.0,
there is no need for any change to any previously backed up data.

At this stage there is no change to rsync-bpc, which together with the
smbclient interface is where the bulk of what I (jokingly) describe as
my free time will be spent for very probably the rest of this year.

At least I hope so.  I'm here to help.

-- 

73,
Ged.

[BackupPC-users] debian patch for localconfig.pl

[Paul F. <pg...@fo...>]

A couple of years ago I filed a backuppc issue on github
(https://github.com/backuppc/backuppc/issues/486) complaining that
localconfig.pl wasn't documented.  It turns out that it's a Debian
addition, courtesy of their patches when packaging backuppc.  I had
learned this a while ago, and I apologize to Ged for not updating the
github issue (which I confess I'd forgotten about).

Anyway, Ged just asked whether it's useful, and whether the
functionality should move into backuppc proper.

Well, at some point, when I wasn't sure whether localconfig.pl was a
feature I should be relying on, I decided to simply move all of my
local config onto the tail of config.pl.  (Previously it had been
sprinkled throughout, with bits of comment here and there telling me
why I'd changed something or other.)   Putting it all at the end isn't
quite as clean, management-wise, as having local changes in a separate
file, but at least it keeps the release-to-release diffs clean(er), which
is important at system upgrade time.

So I'm not going to champion the feature too hard, even though I think
it's a good idea.  I have an adequate workaround.  But if anyone else
uses it, and/or thinks it should become permanent in all packages, I
can't imagine it would be a lot of work for it to be implemented.  And
I'd probably start using it again in that case.

paul
=----------------------
 paul fox, pg...@fo... (arlington, ma, where it's 48.6 degrees)

Re: [BackupPC-users] Backups are performed but are empty

[G.W. H. <ba...@ju...>]

Hi there,

On Thu, 13 Nov 2025, J?rg Ehrchen wrote:
> ...
> It was indeed due to the missing rsync client path.  I saved it with
> the correct entry in the config, initiated a backup, and it is
> working as it should. :)

:)

> Now I just have to figure out, why the rsync client path was deleted
> from the config files.  It definitely wasn't me.

I hope I'm wrong, but...

That's rather worrying.  To my eyes, the change looks very much more
like an intentional edit than some side-effect of a process going off
the reservation and writing random rubbish to random files.  So I have
to wonder if it was deliberate and unauthorized.

Assuming that you'd have told us if anyone else had the ability (and
permission) to make such a change, to me this smells like ransomware.

For obvious reasons, the first things that an attacker will do if he's
any good (and some of them are *very* good) will be to kill your virus
detection and clobber your backups.  Scrambling all your files isn't
much use to him if you can just recover them from your backups.

If I were you I'd want to make sure that my backup server wasn't under
attack.  My Windows boxes would be amongst the first suspects.  If I
had Windows boxes on the same network segment as my backup server they
would not be allowed to make changes to the backup configuration, nor
would they be allowed to delete backups.  There's a case for copying
the backup pool to offline storage - after verifying that it's good.

-- 

73,
Ged.

Re: [BackupPC-users] Backups are performed but are empty

[Jörg E. <j.e...@un...>]

First of all, thank you for your quick reply. Sometimes I am blind to 
the obvious.
It was indeed due to the missing rsync client path.
I saved it with the correct entry in the config, initiated a backup, and 
it is working as it should. :)

Now I just have to figure out, why the rsync client path was deleted 
from the config files.
It definitely wasn't me.

The entry under --filter refers to a text file, that contains the paths 
and files, that are excluded from the backup.
https://github.com/backuppc/backuppc/issues/259

Greetings
Jörg


-- 
Unrast Verlag
Jörg Ehrchen
Fuggerstr. 13a
48165 Münster

Email:j.e...@un...

Tel: 02581/4580083

Re: [BackupPC-users] Backups are performed but are empty

[G.W. H. <ba...@ju...>]

Hi there,
41;366;0c
On Wed, 12 Nov 2025, J?rg Ehrchen wrote:

> ...
> ... Before the error ...
> ...
> Running:
> /usr/libexec/backuppc-rsync/rsync_bpc --bpc-top-dir /var/lib/backuppc
> --bpc-host-name desktop-xxx
> --bpc-share-name \"/\|cygpath=true\|tmp-drive=b\|rsync=c:/r.exe\|c:\"
> --bpc-bkup-num 150 --bpc-bkup-comp 3 --bpc-bkup-prevnum 149
> --bpc-bkup-prevcomp 3 --bpc-bkup-inode0 14381388 --bpc-log-level 9 --bpc-attrib-new
> -e /usr/bin/ssh --rsync-path=\"c:\\Program\ Files\\OpenSSH\\vss.exe\" -8tOJrlH --no-p --no-g --no-o
> --delete --delete-excluded --partial --log-format=log:\ %o\ %i\ %B\ %8U,%8G\ %9l\ %f%L --stats
> --iconv=utf8,cp1252 desktop-xxx:\"/\|cygpath=true\|tmp-drive=b\|rsync=c:/r.exe\|c:\"/ /
> ...
> ...
> Since the error ...
> ...
> Running:
> /usr/libexec/backuppc-rsync/rsync_bpc --bpc-top-dir /var/lib/backuppc
> --bpc-host-name desktop-xxx
> --bpc-share-name \"/\|cygpath=true\|tmp-drive=b\|rsync=c:/r.exe\|c:\"
> --bpc-bkup-num 163 --bpc-bkup-comp 3 --bpc-bkup-prevnum 162
> --bpc-bkup-prevcomp 3 --bpc-bkup-inode0 14429672 --bpc-log-level 2 --bpc-attrib-new
> -e /usr/bin/ssh\  -8tOJrlH --no-p --no-g --no-o
> --ignore-errors
> --delete --delete-excluded --partial --log-format=log:\ %o\ %i\ %B\ %8U,%8G\ %9l\ %f%L --stats
> --filter=.\ /etc/rsync/winex/vss.ex
> --filter=:,n-\ .rsync-filter-094961fbaf9f6e310946b5f4f9dbc7c8
> --checksum --acls --xattrs
> --iconv=utf8,cp1252 desktop-xxx:\"/\|cygpath=true\|tmp-drive=b\|rsync=c:/r.exe\|c:\"/ /

There may be other issues, but it looks like there's something wrong
on the server and I think you need to fix that first.

The above extracts from your mail are each just a single line in the
extracts from your log, which I've broken into pieces so you can more
easily see the individual parts of the single (but very long) command.

Are you sure that your logs extracts have been faithfully rendered in
your mail?  If so it's clear that there have been some changes to the
"ssh" command template in your BackupPC server configuration (which
will be in /etc/BackupPC/config.pl or something like that, depending
on how BackupPC was installed on your server).

How were the changes made?

Did you keep a backup of the original working configuration?

At least the part in the second set which begins with "-e /usr/bin/ssh"
seems to be broken.  The "--rsync-path=" part is missing.  I don't know
if the (added) parts which begin "--filter=" make sense or not, but the
backslash-escaped space and the name "vss.ex" don't look right to me.

Four other options were added but that won't be the immediate problem.

There are some useful scripts in the section of the BackupPC wiki:

https://github.com/backuppc/backuppc/wiki

which might help alert you to things like this in future, for example

https://github.com/moisseev/BackupPC_report

HTH

PS: You may want to check your mail for sensitive information.

-- 

73,
Ged.

[BackupPC-users] Backups are performed but are empty

[Jörg E. <j.e...@un...>]

Hi,
we backup eight Windows clients in an AD domain using BackupPC and
tb-rsync-vss. This has worked flawlessly so far.
The only problems occurred, when the clients did not wake up via
Wake-on-LAN and were therefore unavailable. In this case, restarting the affected clients helped.
Yesterday, I was completely taken aback, when I realised that the backups appeared to be running smoothly but were empty.

I then took a look at the XferLog files.

Before the error, the XferLog files looked like this.

XferLOG file /var/lib/backuppc/pc/desktop-xxx/XferLOG.150.z created 2025-09-12 16:00:11
Backup prep: type = incr, case = 4, inPlace = 0, doDuplicate = 0, newBkupNum = 150, newBkupIdx = 21, lastBkupNum = 149, lastBkupIdx = 20 (FillCycle = 0, noFillCnt = 3)
Running: /usr/libexec/backuppc-rsync/rsync_bpc --bpc-top-dir /var/lib/backuppc --bpc-host-name desktop-xxx --bpc-share-name \"/\|cygpath=true\|tmp-drive=b\|rsync=c:/r.exe\|c:\" --bpc-bkup-num 150 --bpc-bkup-comp 3 --bpc-bkup-prevnum 149 --bpc-bkup-prevcomp 3 --bpc-bkup-inode0 14381388 --bpc-log-level 9 --bpc-attrib-new -e /usr/bin/ssh --rsync-path=\"c:\\Program\ Files\\OpenSSH\\vss.exe\" -8tOJrlH --no-p --no-g --no-o --delete --delete-excluded --partial --log-format=log:\ %o\ %i\ %B\ %8U,%8G\ %9l\ %f%L --stats --iconv=utf8,cp1252 desktop-xxx:\"/\|cygpath=true\|tmp-drive=b\|rsync=c:/r.exe\|c:\"/ /
incr backup started for directory "/|cygpath=true|tmp-drive=b|rsync=c:/r.exe|c:"
Xfer PIDs are now 252383
This is the rsync child about to exec /usr/libexec/backuppc-rsync/rsync_bpc
bpc_lib_conf_init: topDir = /var/lib/backuppc, logLevel = 9
bpc_path_create(/var/lib/backuppc/pc/desktop-xxx/150)
bpc_path_create(/var/lib/backuppc/pc/desktop-xxx/149)
bpc_attrib_backwardCompat: WriteOldStyleAttribFile = 0, KeepOldAttribFiles = 0
Fri Sep 12 16:00:12 2025 0: c:\Program Files\OpenSSH\vss.exe
Fri Sep 12 16:00:12 2025 1: --server
Fri Sep 12 16:00:12 2025 2: --sender
Fri Sep 12 16:00:12 2025 3: -lHtre.iLsfxC
Fri Sep 12 16:00:12 2025 4: --iconv=cp1252
Fri Sep 12 16:00:12 2025 5: .
Fri Sep 12 16:00:12 2025 6: /|cygpath=true|tmp-drive=b|rsync=c:/r.exe|c:/
Fri Sep 12 16:00:12 2025 startup
Fri Sep 12 16:00:17 2025 mapping \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy7 to b:
Fri Sep 12 16:00:17 2025 executing: ''c:/r.exe' '--server' '--sender' '-lHtre.iLsfxC' '--iconv=cp1252' '.' '/cygdrive/b/''
bpc_stat(/)
splitPath: trimming path = ''
splitPath: returning dir = '/', fileName = '"/|cygpath=true|tmp-drive=b|rsync=c:/r.exe|c:"', attrib = '/attrib' from path = ''
bpc_attribCache_loadPath: path = / -> dir = /, fileName = В^, attribPath = /attrib
bpc_attrib_dirRead(/var/lib/backuppc/pc/desktop-xxx/150//attrib); dirPath = /var/lib/backuppc/pc/desktop-xxx/150, attribFilePath = /attrib, attribFileName = attrib
bpc_attrib_dirRead: Got attrib file attrib_a4c94bcc5a6ef9418c89fdaaaad5a883: digest = a4c94bcc5a6ef9418c89fdaaaad5a883, len = 16

bpc_fileZIO_open(/var/lib/backuppc/cpool/a4/c8/a4c94bcc5a6ef9418c89fdaaaad5a883, 0, 3) -> 3
bpc_attrib_dirRead(/var/lib/backuppc/cpool/a4/c8/a4c94bcc5a6ef9418c89fdaaaad5a883): Got file "/|cygpath=true|tmp-drive=b|rsync=c:/r.exe|c:": type = 5, mode = 0755, uid/gid = 0/0, size = 0
bpc_attrib_dirRead(/var/lib/backuppc/cpool/a4/c8/a4c94bcc5a6ef9418c89fdaaaad5a883): Got file "/|cygpath=true|tmp-drive=b|rsync=c:/r.exe|d:": type = 5, mode = 0755, uid/gid = 0/0, size = 0
bpc_fileZIO_close(3)
bpc_lstat(/) and so on

Since the error occurred, it has been recorded in the Xferlogs.

XferLOG file /var/lib/backuppc/pc/desktop-xxx/XferLOG.163.z created 2025-09-25 14:26:31
Backup prep: type = full, case = 4, inPlace = 0, doDuplicate = 0, newBkupNum = 163, newBkupIdx = 22, lastBkupNum = 162, lastBkupIdx = 21 (FillCycle = 0, noFillCnt = 3)
Running: /usr/libexec/backuppc-rsync/rsync_bpc --bpc-top-dir /var/lib/backuppc --bpc-host-name desktop-xxx --bpc-share-name \"/\|cygpath=true\|tmp-drive=b\|rsync=c:/r.exe\|c:\" --bpc-bkup-num 163 --bpc-bkup-comp 3 --bpc-bkup-prevnum 162 --bpc-bkup-prevcomp 3 --bpc-bkup-inode0 14429672 --bpc-log-level 2 --bpc-attrib-new -e /usr/bin/ssh\  -8tOJrlH --no-p --no-g --no-o --ignore-errors --delete --delete-excluded --partial --log-format=log:\ %o\ %i\ %B\ %8U,%8G\ %9l\ %f%L --stats --filter=.\ /etc/rsync/winex/vss.ex --filter=:,n-\ .rsync-filter-094961fbaf9f6e310946b5f4f9dbc7c8 --checksum --acls --xattrs --iconv=utf8,cp1252 desktop-xxx:\"/\|cygpath=true\|tmp-drive=b\|rsync=c:/r.exe\|c:\"/ /
full backup started for directory "/|cygpath=true|tmp-drive=b|rsync=c:/r.exe|c:"
Xfer PIDs are now 324607
This is the rsync child about to exec /usr/libexec/backuppc-rsync/rsync_bpc
rsync: [sender] change_dir "/|cygpath=true|tmp-drive=b|rsync=c:/r.exe|c:" failed: No such file or directory (2)
Number of files: 0
Number of created files: 0
Number of deleted files: 0
Number of regular files transferred: 0
Total file size: 0 bytes
Total transferred file size: 0 bytes
Literal data: 0 bytes
Matched data: 0 bytes
File list size: 7
Total bytes sent: 3,225
Total bytes received: 7
sent 3,225 bytes  received 7 bytes  1,292.80 bytes/sec
total size is 0  speedup is 0.00
Done: 0 errors, 0 filesExist, 0 sizeExist, 0 sizeExistComp, 0 filesTotal, 0 sizeTotal, 0 filesNew, 0 sizeNew, 0 sizeNewComp, 14429672 inode
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1685) [Receiver=3.1.3.0]

It appears that the link c:\r.exe can no longer be found.
The link is no longer displayed in Explorer or on the command line. When
  I switch to c:\ on the command line, enter r, and complete the command
with TAB, r.exe is displayed. So the link still seems to exist.
Nevertheless, it is not displayed in DIR or Explorer.
Running install.cmd again in openssh creates the link, but it is not displayed in DIR or Explorer.
Do you have any idea what the problem could be?

Unrast Verlag
Jörg Ehrchen
Fuggerstr. 13a
48165 Münster

Email:j.e...@un...

Tel: 02581/4580083

Re: [BackupPC-users] Problems disk usage after migrated/reinstalled from 3.3 to 4.4

[G.W. H. <ba...@ju...>]

Hi there,

On Tue, 11 Nov 2025, klxout wrote:

> I have similar issues described in
> https://github.com/backuppc/backuppc/issues/418
> 
> I have the same problem recently upgraded debian with 3.3 backuppc to
> debian 13 with latest backuppc 4.4 from debian repositories and space is
> increasing.... seems files are never purged
> 
> Now I have reinstalled backuppc with a fresh install using apt-get remove
> --purge backuppc* and I'm evaluating the results
> 
> in the logs appears always 0 space recovered from v4 pool (only v4 is
> enabled as it was a default install)
> 
> 2025-11-10 18:00:00 Running 2 BackupPC_nightly jobs from 0..15 (out of 0..15)
> 2025-11-10 18:00:00 Running BackupPC_nightly -m -P 11 0 127 (pid=50769)
> 2025-11-10 18:00:00 Running BackupPC_nightly -P 11 128 255 (pid=50770)
> 2025-11-10 18:00:00 Next wakeup is 2025-11-11 04:00:00
> 2025-11-10 18:00:01 BackupPC_nightly now running BackupPC_refCountUpdate -m -s -c -P 11 -r 128-255
> 2025-11-10 18:00:01 BackupPC_nightly now running BackupPC_refCountUpdate -m -s -c -P 11 -r 0-127
> 2025-11-10 18:00:01  admin : __bpc_pidStart__ 50783
> 2025-11-10 18:00:01  admin1 : __bpc_pidStart__ 50782
> 2025-11-10 18:00:16  admin : __bpc_pidEnd__ 50783
> 2025-11-10 18:00:16 BackupPC_nightly now running BackupPC_sendEmail
> 2025-11-10 18:00:16 Finished  admin  (BackupPC_nightly -m -P 11 0 127)
> 2025-11-10 18:00:37  admin1 : __bpc_pidEnd__ 50782
> 2025-11-10 18:00:37 Finished  admin1  (BackupPC_nightly -P 11 128
> 255)*2025-11-10 18:00:37 Pool nightly clean removed 0 files of size 0.00GB
> 2025-11-10 18:00:37 Pool is 0.00GB, 0 files (0 repeated, 0 max chain, 0 max links), 0 directories
> 2025-11-10 18:00:37 Cpool nightly clean removed 0 files of size 0.00GB
> 2025-11-10 18:00:37 Cpool is 0.00GB, 0 files (0 repeated, 0 max chain, 0 max links), 0 directories
> 2025-11-10 18:00:37 Pool4 nightly clean removed 0 files of size 0.00GB
> 2025-11-10 18:00:37 Pool4 is 0.00GB, 0 files (0 repeated, 0 max chain, 0 max links), 0 directories
> 2025-11-10 18:00:37 Cpool4 nightly clean removed 0 files of size 0.00GB*
> 2025-11-10 18:00:37 Cpool4 is 782.54GB, 92649 files (0 repeated, 0 max chain, 1632 max links), 16452 directories
> 2025-11-10 18:00:37 Running BackupPC_rrdUpdate (pid=50797)
> 2025-11-10 18:00:38  admin-1 : skipping repeated RRD update for the same day: last update time is 1762819200
> 2025-11-10 18:00:38 Finished  admin-1  (BackupPC_rrdUpdate)
> 
> Any suggestion to solve this problems?

First let's make sure that there *is* a problem.  In some commands
below you may need to change the logged-in user ID to one which can
read the necessary files (often, for example, to user 'backuppc').

1.

Did you run BackupPC_nightly by hand?

How many times has it been run on the nightly backup schedule since
your most recent install of BackupPC version 4?

2.

In the Github issue (#418) on which you commented, did you read
Craig's post of Feb 25, 2021 at

https://github.com/backuppc/backuppc/issues/418#issuecomment-785825325

in which he talks about the mtimes of pool files?  Did you try any of
Craig's suggestions there?

Does your filesystem properly set the 'x' bit in file metadata?

Do you know roughly how old (looking at mtimes of the files) is the
oldest file in your 'cpool'?

If not, what's the output of

   find /POOLDIR/ -type f -mtime +9 | head

where /POOLDIR/ is the full path to your cpool ?  (For example on a
system *here*, that would be

   find /var/lib/BackupPC/cpool/ -type f -mtime +9 | head

because the cpool directory *here* is in /var/lib/BackupPC/ - but note
that your cpool directory might not be in the same place as mine).

3.

What's the output of

   grep 'my $minMtime' /path/to/BackupPC_refCountUpdate

where /path/to/ is the path to your BackupPC Perl scripts.

-- 

73,
Ged.

[BackupPC-users] Problems disk usage after migrated/reinstalled from 3.3 to 4.4

[klxout <kl...@gm...>]

hi

I have similar issues described in
https://github.com/backuppc/backuppc/issues/418

I have the same problem recently upgraded debian with 3.3 backuppc to
debian 13 with latest backuppc 4.4 from debian repositories and space is
increasing.... seems files are never purged

Now I have reinstalled backuppc with a fresh install using apt-get remove
--purge backuppc* and I'm evaluating the results

in the logs appears always 0 space recovered from v4 pool (only v4 is
enabled as it was a default install)

2025-11-10 18:00:00 Running 2 BackupPC_nightly jobs from 0..15 (out of 0..15)
2025-11-10 18:00:00 Running BackupPC_nightly -m -P 11 0 127 (pid=50769)
2025-11-10 18:00:00 Running BackupPC_nightly -P 11 128 255 (pid=50770)
2025-11-10 18:00:00 Next wakeup is 2025-11-11 04:00:00
2025-11-10 18:00:01 BackupPC_nightly now running
BackupPC_refCountUpdate -m -s -c -P 11 -r 128-255
2025-11-10 18:00:01 BackupPC_nightly now running
BackupPC_refCountUpdate -m -s -c -P 11 -r 0-127
2025-11-10 18:00:01  admin : __bpc_pidStart__ 50783
2025-11-10 18:00:01  admin1 : __bpc_pidStart__ 50782
2025-11-10 18:00:16  admin : __bpc_pidEnd__ 50783
2025-11-10 18:00:16 BackupPC_nightly now running BackupPC_sendEmail
2025-11-10 18:00:16 Finished  admin  (BackupPC_nightly -m -P 11 0 127)
2025-11-10 18:00:37  admin1 : __bpc_pidEnd__ 50782
2025-11-10 18:00:37 Finished  admin1  (BackupPC_nightly -P 11 128
255)*2025-11-10 18:00:37 Pool nightly clean removed 0 files of size
0.00GB
2025-11-10 18:00:37 Pool is 0.00GB, 0 files (0 repeated, 0 max chain,
0 max links), 0 directories
2025-11-10 18:00:37 Cpool nightly clean removed 0 files of size 0.00GB
2025-11-10 18:00:37 Cpool is 0.00GB, 0 files (0 repeated, 0 max chain,
0 max links), 0 directories
2025-11-10 18:00:37 Pool4 nightly clean removed 0 files of size 0.00GB
2025-11-10 18:00:37 Pool4 is 0.00GB, 0 files (0 repeated, 0 max chain,
0 max links), 0 directories
2025-11-10 18:00:37 Cpool4 nightly clean removed 0 files of size 0.00GB*
2025-11-10 18:00:37 Cpool4 is 782.54GB, 92649 files (0 repeated, 0 max
chain, 1632 max links), 16452 directories
2025-11-10 18:00:37 Running BackupPC_rrdUpdate (pid=50797)
2025-11-10 18:00:38  admin-1 : skipping repeated RRD update for the
same day: last update time is 1762819200
2025-11-10 18:00:38 Finished  admin-1  (BackupPC_rrdUpdate)

Any suggestion to solve this problems?

Thanks

[BackupPC-users] BackupPC-XS, zlib and Autotools.

[G.W. H. <ba...@ju...>]

Hi there,

It's taken a bit longer than I'd hoped but I'm now in a position to
publish the first Release Candidate for BackupPC-XS version 0.63.

There are two main reasons for needing to do this now.

(1) Since its creation, BackupPC-XS has bundled a version of the zlib
library.  The bundling was I *think* originally done because of issues
with the upstream zlib which were not being addressed.  Things seem to
be different now.  The bundled version is now terribly out of date and
has known security issues.

(2) The build scripts for BackupPC-XS were originally cobbled together
from the build scripts for rsync.  There was never any source included
with the BackupPC-CS distribution which a user could hand to Autotools
to produce the build scripts.  This violated the GNU terms of use, and
made the package maintainers at Red Hat (and probably others) unhappy.

I'm not altogether happy with continuing work on Autotools builds, I'd
much prefer to move e.g. to CMake but in the short term there's really
no way that's going to happen, I don't have the time.  It could be a
self-contained little project for someone to get their teeth into and
would be a valuable contribution.

If anyone would like to take rc1 for a spin we can proceed in several
different ways:

1. Send a tarball to interested parties by email.
2. Post it here (but it's just under 350kbytes).
3. Create e.g. a 'testing' branch on Github.
4. Something else?

Because of the large number of changes I'd be really pleased to have
as many people as possible test this on different architectures etc..
It can be installed in a home directory, you don't have to install it
for the whole system - that could still provide very useful feedback.

-- 

73,
Ged.

[BackupPC-users] UTF-8 and the BackupPC configuration file editor.

[G.W. H. <ba...@ju...>]

Hi there,

The long-standing Github issue #426 refers to mishandling of UTF-8 in
the configuration editor of the BackupPC Web user interface.  The OP
in that issue was having trouble with UTF-8 in share names but I guess
it could happen elsewhere.

In the past few days I've been digging into this and I think have it
under control now.  The fix takes the form of a replacement for the
script 'EditConfig.pl' in directory '.../BackupPC/lib/BackupPC/CGI'.

The only changes for this fix are in that one script, so if you are
running version 4.4.0 of BackupPC it will just drop right in.

If anyone would like to take it for a spin we can proceed in several
different ways:

1. Send the script to interested parties by email.
2. Post the script here.
3. Create e.g. a 'testing' branch on Github.
4. Something else?

Option 3 would beg the question of which branch to base it on.

If you already have UTF-8 in existing share names I wouldn't recommend
actually saving the configuration edited by the Web interface (neither
the old version nor the 'fixed' version) without being sure things are
behaving as expected.  Of course it's easy to save the working configs
and restore them if necessary.

Anyone interested?

-- 

73,
Ged.

Re: [BackupPC-users] BackupPC and Prometheus.

[G.W. H. <ba...@ju...>]

Hi there,

On Fri, 24 Oct 2025, Matthew Pounsett wrote:
> On Tue, Oct 21, 2025 at 1:42?PM G.W. Haywood wrote:
>
>> It doesn't look like there will be a lot of work involved, but there
>> seem to be conflicts in the suggestions which may need to be resolved.
>> ...
> ...
> Prometheus records data in a time series database ...
> ...
> BackupPC_Admin?action=metrics?format=prometheus implements an exporter 
> ...
> "fix this problem by fixing the value" is a better approach than
> "fix this problem by removing the value."  ...

That was very helpful, thank you.  I've now pushed some changes, and
will await developments.  AFAICT the people who are using this stuff
know what they need to do, and this is more about avoiding patches in
packaged distributions than about fixing things in the "experimental"
metrics feature.

The Github Web interface continues to cause multiple problems for me.
If anyone has comments or requests about metrics or their presentation
via JSON, Prometheus or RSS please reply in this thread rather than in
any of the Github issues/PRs.

It seems to me that it might be useful to extend the discussion to the
more general topic of APIs (see Github issue #365), perhaps including
the use of BackupPC_serverMesg and BackupPC_report (which can be found
in .../BackupPC/bin/ and on BackupPC's Github Wiki respectively).

-- 

73,
Ged.

Re: [BackupPC-users] BackupPC and Prometheus.

[Matthew P. <ma...@co...>]

On Tue, Oct 21, 2025 at 1:42 PM G.W. Haywood <ba...@ju...>
wrote:

> It doesn't look like there will be a lot of work involved, but there
> seem to be conflicts in the suggestions which may need to be resolved.
> I've never met Prometheus, but I do use Icinga extensively so I guess
> it won't be terribly unfamiliar.  Can anyone here help me with this?
>

Prometheus and Incus have very little in common. :)  Prometheus has more in
common with something like MRTG (in that it implements the polling and data
storage components).

Prometheus records data in a time series database, and provides a query
language for retrieving that data in ways that make it easily graphable and
easy to generate alerts from.   It's commonly paired with Graphite and
various other tools that feed into push notification (alerting) software.

Prometheus operates by having an "exporter" run on remote systems that
provides an HTTP(s) endpoint that dumps current statistics counters
(key/value).  Exporters are not dissimilar to SNMPD, just with a different
interface and security profile.   Prometheus scrapes the data from whatever
exporters it's configured to access, at regular intervals, and stores the
retrieved statistics in its time series database to be looked at later by
some other process (e.g. Graphite).

Some software comes with an exporter built in (for full circularity,
Graphite provides a Prometheus exporter endpoint, and then provides its own
Dashboard showing its own performance based on the data stored in
Prometheus).  For other software there may be an additional process that
collects and collates data into statistics and provides the endpoint (e.g.,
see the "Node Exporter", which provides system statistics for an OS... this
is really the only place there is overlap with Icinga/Nagios).
BackupPC_Admin?action=metrics?format=prometheus
implements an exporter for Backup PC.


I have only done a very brief review of the issues you mention... It looks
like the conflicts come from different people trying to solve the same
ongoing issue in different ways, depending on their personal needs.  My
personal opinion is that "fix this problem by fixing the value" is a better
approach than "fix this problem by removing the value."   Beyond that any
conflicts arising in what is considered "fixing" a broken statistic is
probably going to require some more knowledge of internals than I have time
to dig into right now.