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

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

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

Hi there,

On Mon, 8 Dec 2025, klxout wrote:
> G.W. Haywood wrote:
>>
>> Is the current value of seven days causing problems for you?  I can
>> only imagine that it would be a problem if you are backing up a large
>> number of large files of which most change frequently.
>>
>> Backing up the files underlying the tables in a database system for
>> example might be expected to cause issues.  In my view BackupPC is not
>> particularly suitable for that kind of backup.  My own database
>> servers are backed up using the Postgress dump utility via cron jobs.
> 
> Correcte in my case I have many big files, postres backups,
> why is restricted to 7 days on v4?

Short answer: nobody seems to be sure.

Long answer: Read the comments in the Github issues.  In

https://github.com/backuppc/backuppc/issues/310

BackupPC's author says he doesn't know.

There's more in

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

> It is possible to recover v3 feature que keep less days? Now?

Yes.  See

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

But none of this changes the fact that BackupPC is not a good choice
for backing up typical large database files.  BackupPC's pooling will
have no effect on a file in which even a single bit changes, so if you
have large files with few but frequent changes, BackupPC must store a
new copy of the file every time it's backed up.

For my own Postgres backups I use the dump utility and cron.

-- 

73,
Ged.

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

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

Hi,

Correcte in my case I have many big files, postres backups,
why is restricted to 7 days on v4?

It is possible to recover v3 feature que keep less days? Now?

Thanks

El dg., 7 de des. 2025, 14:18, G.W. Haywood <ba...@ju...> va
escriure:

> Hi there,
>
> On Sun, 7 Dec 2025, klxout wrote:
>
> > El dc., 19 de nov. 2025, 9:28, G.W. Haywood va escriure:
> >>
> >> There's been a suggestion that seven days might be a bit long. ...
> >
> > Thanks, after some daus seria fusta after reinstall now purged , bit
> seria
> > that only as Min 7 daus, us possible to restrict to less than days, For
> > example  5 days?
>
> My guess is that there should be no problems if you reduce the timeout
> for example from seven days to five.  It is just a guess based on what I
> read in the Github issue to which you originally contributed.
>
> Is the current value of seven days causing problems for you?  I can
> only imagine that it would be a problem if you are backing up a large
> number of large files of which most change frequently.
>
> Backing up the files underlying the tables in a database system for
> example might be expected to cause issues.  In my view BackupPC is not
> particularly suitable for that kind of backup.  My own database
> servers are backed up using the Postgress dump utility via cron jobs.
>
> Your translation utility seems to need work. ;)
>
> --
>
> 73,
> Ged.
>
>
> _______________________________________________
> 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] Problems disk usage after migrated/reinstalled from 3.3 to 4.4

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

Hi there,

On Sun, 7 Dec 2025, klxout wrote:

> El dc., 19 de nov. 2025, 9:28, G.W. Haywood va escriure:
>>
>> There's been a suggestion that seven days might be a bit long. ...
> 
> Thanks, after some daus seria fusta after reinstall now purged , bit seria
> that only as Min 7 daus, us possible to restrict to less than days, For
> example  5 days?

My guess is that there should be no problems if you reduce the timeout
for example from seven days to five.  It is just a guess based on what I
read in the Github issue to which you originally contributed.

Is the current value of seven days causing problems for you?  I can
only imagine that it would be a problem if you are backing up a large
number of large files of which most change frequently.

Backing up the files underlying the tables in a database system for
example might be expected to cause issues.  In my view BackupPC is not
particularly suitable for that kind of backup.  My own database
servers are backed up using the Postgress dump utility via cron jobs.

Your translation utility seems to need work. ;)

-- 

73,
Ged.

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

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

Hi,

Thanks, after some daus seria fusta after reinstall now purged , bit seria
that only as Min 7 daus, us possible to restrict to less than days, For
example  5 days?

Thanks

El dc., 19 de nov. 2025, 9:28, G.W. Haywood <ba...@ju...> va
escriure:

> Hi there,
>
> On Sun, 16 Nov 2025, klxout wrote:
> > On Tue, 11 Nov 2025, G.W. Haywood wrote:
> > > On Tue, 11 Nov 2025, klxout wrote:
> > > >
> > > >> I have similar issues described in
> > > >> https://github.com/backuppc/backuppc/issues/418
> > > >> ...
> > > >> ...
> > > >> Any suggestion to solve this problems?
> > >
> > > First let's make sure that there *is* a problem. ...
> > > ...
> > > 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?
> > > ...
> >
> > I have forced executed multiples times changing time, and now after
> > 7 day seems that some files were purged but not all because I have a
> > retention full 2 days and incremental 1 day
>
> I'm sure that BackupPC is working just fine.
>
> Over on Github I've just comitted b343cb5 to add a bit more logging to
> BackupPC_nightly.  Now if $Conf{XferLogLevel}>=3 in the configuration,
> then the log shows how many files - otherwise eligible for deletion -
> were skipped because their mtime was more recent than the hard-coded
> value of 7 days prior to the time of the nightly run.  It also logs
> the number of blocks occupied by those files.
>
> From the most recent BackupPC_nightly run here:
>
>
> 8<--------------------------------------------------------------------------
> 2025-11-19 01:00:01 Running 1 BackupPC_nightly jobs from 0..15 (out of
> 0..15)
> 2025-11-19 01:00:01 Running BackupPC_nightly -m -P 13 0 255 (pid=29902)
> 2025-11-19 01:00:01 Next wakeup is 2025-11-19 02:00:00
> 2025-11-19 01:00:02 BackupPC_nightly now running BackupPC_refCountUpdate
> -m -s -c -P 13 -r 0-255
> 2025-11-19 01:00:02  admin : __bpc_pidStart__ 29907
> 2025-11-19 01:00:20 Started incr backup on ...
> ...
> ...
> ...
> 2025-11-19 01:27:17 Started incr backup on ...
> 2025-11-19 01:46:01 Finished incr backup on ...
> 2025-11-19 02:00:13 Next wakeup is 2025-11-19 03:00:00
> 2025-11-19 02:10:28  admin : BackupPC_refCountUpdate total errors: 0
> 2025-11-19 02:10:28  admin : BackupPC_refCountUpdate skipped deleting 557
> unused files which currently occupy a total of 16048 blocks
> 2025-11-19 02:10:28  admin : __bpc_pidEnd__ 29907
> 2025-11-19 02:10:29 BackupPC_nightly now running BackupPC_sendEmail
>
> 8<--------------------------------------------------------------------------
>
> There's been a suggestion that seven days might be a bit long.  At the
> moment I'm in no hurry to change it, or to make it a configuration
> option, but I'd consider PRs for the latter.  Note that EditConfig.pl
> is (not to put too fine a point on it) a nightmare.  If anyone wants
> to take up the gauntlet there's a debug version of sorts here.
>
> --
>
> 73,
> Ged.
>
>
> _______________________________________________
> 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] BackupPC and EPEL10

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

On 12/1/25 7:19 AM, Richard Shaw wrote:
> On Mon, Dec 1, 2025 at 6:03 AM jbk <jb...@kj...> wrote:
>
>     On 11/20/25 6:00 PM, Richard Shaw wrote:
>>     On Wed, Nov 19, 2025 at 7:06 AM Jamie Burchell via
>>     BackupPC-users <bac...@li...>
>>     wrote:
>>
>>         Is the current bad karma due to the build
>>         failing? I still see this:
>>
>>         Error: Problem: conflicting requests - nothing
>>         provides perl(Net::FTP::AutoReconnect) needed by
>>         BackupPC-4.4.0-20.el10_2.x86_64 from
>>         brew-139020571 - nothing provides
>>         perl(Net::FTP::RetrHandle) needed by
>>         BackupPC-4.4.0-20.el10_2.x86_64 from
>>         brew-139020571 (try to add '--skip-broken' to
>>         skip uninstallable packages or '--nobest' to use
>>         not only best candidate packages) Installation of
>>         BackupPC-0:4.4.0-20.el10_2.x86_64 failed. See
>>         dnf-3 command output above for more information.
>>
>>
>>     Those are run time dependencies not build time
>>     dependencies so I didn't see the issue when building.
>>     Those will need to be built for EPEL 10 as well but
>>     I'm not the maintainer.
>>
>>     It looks like perl-libnet needs to be built for EPEL
>>     10...
>>
>>     Thanks,
>>     Richard
>     I'm looking to build for RL10.1 using mock on a local
>     install of 10.1. To do so I would like to download the
>     BackupPC-4.4.0-20.el10_2.src.rpm from koji along with
>     the BackupPC_XS source rpm of the same build target.
>     Is this likely to succeed?
>
>     I've built backuppc for RL9 using mock so I know the
>     process. I can look back through my notes to see what
>     other sources were required.
>
>
> You also need rsync-bpc.
>
> Thanks,
> Richard
I also needed par2cmdline and the two perl-NET dependencies. 
I used F40 sources for the perl items. Now that I've done 
this the order matters in the mock build process. Once I 
made my user a member of the mock group I cd'd to the 
directory containing my sources. First build mock 
BackupPC-XS...srpm then run mock --install 
/var/lib..../results/BackupPC-XS-...x86_64.rpm this installs 
it in the mock chroot environment. For building all the 
remaining sources you have to use the --no-clean option to 
mock or you'll loose all your prior work.
I installed the six packages w/o issue in my RL10.1 vm. You 
should create the backuppc user first before doing the 
install. I didn't so wil have to mess around with that 
before I can configure it.

-- 
Jim KR

Re: [BackupPC-users] BackupPC and EPEL10

[Richard S. <hob...@gm...>]

On Mon, Dec 1, 2025 at 6:03 AM jbk <jb...@kj...> wrote:

> On 11/20/25 6:00 PM, Richard Shaw wrote:
>
> On Wed, Nov 19, 2025 at 7:06 AM Jamie Burchell via BackupPC-users <
> bac...@li...> wrote:
>
>> Is the current bad karma due to the build failing? I still see this:
>>
>>
>>
>> Error: Problem: conflicting requests - nothing provides
>> perl(Net::FTP::AutoReconnect) needed by BackupPC-4.4.0-20.el10_2.x86_64
>> from brew-139020571 - nothing provides perl(Net::FTP::RetrHandle) needed by
>> BackupPC-4.4.0-20.el10_2.x86_64 from brew-139020571 (try to add
>> '--skip-broken' to skip uninstallable packages or '--nobest' to use not
>> only best candidate packages) Installation of
>> BackupPC-0:4.4.0-20.el10_2.x86_64 failed. See dnf-3 command output above
>> for more information.
>>
>
> Those are run time dependencies not build time dependencies so I didn't
> see the issue when building. Those will need to be built for EPEL 10 as
> well but I'm not the maintainer.
>
> It looks like perl-libnet needs to be built for EPEL 10...
>
> Thanks,
> Richard
>
> I'm looking to build for RL10.1 using mock on a local install of 10.1. To
> do so I would like to download the BackupPC-4.4.0-20.el10_2.src.rpm from
> koji along with the BackupPC_XS source rpm of the same build target. Is
> this likely to succeed?
>
> I've built backuppc for RL9 using mock so I know the process. I can look
> back through my notes to see what other sources were required.
>

You also need rsync-bpc.

Thanks,
Richard

Re: [BackupPC-users] BackupPC and EPEL10

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

On 11/20/25 6:00 PM, Richard Shaw wrote:
> On Wed, Nov 19, 2025 at 7:06 AM Jamie Burchell via 
> BackupPC-users <bac...@li...> wrote:
>
>     Is the current bad karma due to the build failing? I
>     still see this:
>
>     Error: Problem: conflicting requests - nothing
>     provides perl(Net::FTP::AutoReconnect) needed by
>     BackupPC-4.4.0-20.el10_2.x86_64 from brew-139020571 -
>     nothing provides perl(Net::FTP::RetrHandle) needed by
>     BackupPC-4.4.0-20.el10_2.x86_64 from brew-139020571
>     (try to add '--skip-broken' to skip uninstallable
>     packages or '--nobest' to use not only best candidate
>     packages) Installation of
>     BackupPC-0:4.4.0-20.el10_2.x86_64 failed. See dnf-3
>     command output above for more information.
>
>
> Those are run time dependencies not build time 
> dependencies so I didn't see the issue when building. 
> Those will need to be built for EPEL 10 as well but I'm 
> not the maintainer.
>
> It looks like perl-libnet needs to be built for EPEL 10...
>
> Thanks,
> Richard
I'm looking to build for RL10.1 using mock on a local 
install of 10.1. To do so I would like to download the 
BackupPC-4.4.0-20.el10_2.src.rpm from koji along with the 
BackupPC_XS source rpm of the same build target. Is this 
likely to succeed?

I've built backuppc for RL9 using mock so I know the 
process. I can look back through my notes to see what other 
sources were required.

-- 
Jim KR

Re: [BackupPC-users] BackupPC and EPEL10

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

Thanks Richard. I went down that particular learning journey (rabbit hole?)
earlier, reading about how EPEL 10 works now. It’s great if everyone can be
on the latest version of EL…



*From:* Richard Shaw <hob...@gm...>
*Sent:* 26 November 2025 13:38
*To:* General list for user discussion, questions and support <
bac...@li...>
*Cc:* Jamie Burchell <ja...@ib...>
*Subject:* Re: [BackupPC-users] BackupPC and EPEL10



On Wed, Nov 26, 2025 at 3:10 AM Jamie Burchell via BackupPC-users <
bac...@li...> wrote:

I see that BackupPC is now available in EPEL 10 – which is great. Is there
a reason why it targets a specific minor version of EL10 (10.2)? The EL9
and EL8 packages are available for any 9.x and 8.x release I think? Rocky
Linux has only just released 10.1. What happens when 10.3 is released?



Because of the way EPEL works "these days" I would have to specifically
request branches for 10.1, so they would essentially be a different branch.
I don't mind doing so if there's sufficient demand for it but I'm still
concerned that there may be non-BackupPC dependencies which are
unavailable, notably the perl-net-ftp-retrHandle package which I do not
maintain.



Thanks,

Richard

Re: [BackupPC-users] BackupPC and EPEL10

[Richard S. <hob...@gm...>]

On Wed, Nov 26, 2025 at 3:10 AM Jamie Burchell via BackupPC-users <
bac...@li...> wrote:

> I see that BackupPC is now available in EPEL 10 – which is great. Is there
> a reason why it targets a specific minor version of EL10 (10.2)? The EL9
> and EL8 packages are available for any 9.x and 8.x release I think? Rocky
> Linux has only just released 10.1. What happens when 10.3 is released?
>

Because of the way EPEL works "these days" I would have to specifically
request branches for 10.1, so they would essentially be a different branch.
I don't mind doing so if there's sufficient demand for it but I'm still
concerned that there may be non-BackupPC dependencies which are
unavailable, notably the perl-net-ftp-retrHandle package which I do not
maintain.

Thanks,
Richard

Re: [BackupPC-users] BackupPC and EPEL10

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

I see that BackupPC is now available in EPEL 10 – which is great. Is there
a reason why it targets a specific minor version of EL10 (10.2)? The EL9
and EL8 packages are available for any 9.x and 8.x release I think? Rocky
Linux has only just released 10.1. What happens when 10.3 is released?



*From:* jbk <jb...@kj...>
*Sent:* 21 November 2025 13:22
*To:* bac...@li...
*Subject:* Re: [BackupPC-users] BackupPC and EPEL10



On 11/20/25 6:05 PM, Richard Shaw wrote:

Let me amend, it looks like we need perl-Net-FTP-RetrHandle but it may yet
have other deps...



On Thu, Nov 20, 2025 at 5:00 PM Richard Shaw <hob...@gm...> wrote:

On Wed, Nov 19, 2025 at 7:06 AM Jamie Burchell via BackupPC-users <
bac...@li...> wrote:

Is the current bad karma due to the build failing? I still see this:



Error: Problem: conflicting requests - nothing provides
perl(Net::FTP::AutoReconnect) needed by BackupPC-4.4.0-20.el10_2.x86_64
from brew-139020571 - nothing provides perl(Net::FTP::RetrHandle) needed by
BackupPC-4.4.0-20.el10_2.x86_64 from brew-139020571 (try to add
'--skip-broken' to skip uninstallable packages or '--nobest' to use not
only best candidate packages) Installation of
BackupPC-0:4.4.0-20.el10_2.x86_64 failed. See dnf-3 command output above
for more information.



Those are run time dependencies not build time dependencies so I didn't see
the issue when building. Those will need to be built for EPEL 10 as well
but I'm not the maintainer.



It looks like perl-libnet needs to be built for EPEL 10...



Thanks,

Richard

Correct me if I'm wrong but I think you can skip this dependency if you
don't use the FTP protocol in your backups.


-- 

Jim KR

Re: [BackupPC-users] Debian packaging

[Adam G. <mai...@we...>]

You could also modify the /etc/passwd files to manually configure the uid/gid to match the old system.... 

Too late now, but there is usually more than one way to solve a problem.

Regards
Adam

On 24 November 2025 9:06:26 am AEDT, Kenneth Porter <sh...@se...> wrote:
>I'm migrating from CentOS (an RHEL clone) to Debian. I moved my external BackupPC drive to it (mounted at /var/lib/BackupPC) and copied the /etc/BackupPC directory over. (I actually keep that directory on the root of the external drive and mount it when the rest of the drive is mounted, so the config stays with the drive.)
>
>The first issue I ran into was needing to rename the BackupPC directories to backuppc, all lowercase. A couple of symlinks took care of that.
>
>I then chowned all the directories to backuppc:www-data. Doing that for the external drive took over a day. There's got to be a better way for Linux to handle removable media with millions of files. I'd read that bindfs can change the effective owner of a drive but it's a FUSE filesystem so there's a performance cost.
>
>The trickiest bit was that BackupPC was ignoring my per-host configs in /etc/BackupPC/pc. Digging into the code, I found that Text.pm had been patched (by the Debian packager?) to not look there. It disables useFHS and then removes the line to fall back to looking in the pc subdirectory. Why?
>
>Now I have my backups working again.
>
>
>
>_______________________________________________
>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 packaging

[<bac...@ma...>]

On Sun, 23 Nov 2025 14:06:26 -0800
Kenneth Porter <sh...@se...> wrote:

> I then chowned all the directories to backuppc:www-data. Doing that
> for the external drive took over a day. There's got to be a better
> way for Linux to handle removable media with millions of files. I'd
> read that bindfs can change the effective owner of a drive but it's a
> FUSE filesystem so there's a performance cost.

Since Linux kernel 5.12 you can use ID mapping in mounts:
https://unix.stackexchange.com/a/705331

BR,
Fabian

[BackupPC-users] Debian packaging

[Kenneth P. <sh...@se...>]

I'm migrating from CentOS (an RHEL clone) to Debian. I moved my external 
BackupPC drive to it (mounted at /var/lib/BackupPC) and copied the 
/etc/BackupPC directory over. (I actually keep that directory on the root 
of the external drive and mount it when the rest of the drive is mounted, 
so the config stays with the drive.)

The first issue I ran into was needing to rename the BackupPC directories 
to backuppc, all lowercase. A couple of symlinks took care of that.

I then chowned all the directories to backuppc:www-data. Doing that for the 
external drive took over a day. There's got to be a better way for Linux to 
handle removable media with millions of files. I'd read that bindfs can 
change the effective owner of a drive but it's a FUSE filesystem so there's 
a performance cost.

The trickiest bit was that BackupPC was ignoring my per-host configs in 
/etc/BackupPC/pc. Digging into the code, I found that Text.pm had been 
patched (by the Debian packager?) to not look there. It disables useFHS and 
then removes the line to fall back to looking in the pc subdirectory. Why?

Now I have my backups working again.

Re: [BackupPC-users] unable to build backuppc from source

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

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Greetings,</div>

<div>
<div>&nbsp;</div>

<div>my apologies for top posting but I get the mail in html form and it doesn&#39;t work properly nor conversion to text.</div>

<div>I&#39;m using vm so no need for a docker container</div>

<div>&nbsp;</div>

<div>Thanks for the suggestion thought.</div>

<div>&nbsp;</div>

<div>&nbsp;</div>

<div>
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Sent:</b>&nbsp;Saturday, November 22, 2025 at 11:38 PM<br/>
<b>From:</b>&nbsp;&quot;Adam Goryachev via BackupPC-users&quot; &lt;bac...@li...&gt;<br/>
<b>To:</b>&nbsp;&quot;General list for user discussion, questions and support&quot; &lt;bac...@li...&gt;<br/>
<b>Cc:</b>&nbsp;&quot;Adam Goryachev&quot; &lt;mai...@we...&gt;<br/>
<b>Subject:</b>&nbsp;Re: [BackupPC-users] unable to build backuppc from source</div>

<div name="quoted-content">
<div>Jumping in late here...<br/>
You might like to look at the BackupPC docker container, I recall it runs as non-root, and also will isolate itself from the rest of the os.<br/>
If nothing else, it should have some helpful scripts, since also from memory,it is based on alpine linux....<br/>
I&#39;ve been running it that way on two servers for a year or so with no issues so far.<br/>
<br/>
Regards,<br/>
Adam</div>
&nbsp;

<div class="gmail_quote">
<div>On 23 November 2025 3:57:49&#8239;am AEDT, &quot;G.W. Haywood&quot; &lt;ba...@ju...&gt; wrote:</div>

<blockquote class="gmail_quote" style="margin: 0.0pt 0.0pt 0.0pt 0.8ex;border-left: 1.0px solid rgb(204,204,204);padding-left: 1.0ex;">
<pre class="k9mail">&nbsp;</pre>

<div>Hello again,<br/>
<br/>
On Sat, 22 Nov 2025, daggs wrote:</div>

<blockquote class="gmail_quote" style="margin: 0.0pt 0.0pt 1.0ex 0.8ex;border-left: 1.0px solid rgb(114,159,207);padding-left: 1.0ex;">
<div>On Sun, 16 Nov 2025, G.W. Haywood wrote:</div>

<blockquote class="gmail_quote" style="margin: 0.0pt 0.0pt 1.0ex 0.8ex;border-left: 1.0px solid rgb(173,127,168);padding-left: 1.0ex;">
<div>On Sun, 16 Nov 2025, daggs via BackupPC-users wrote:</div>

<blockquote class="gmail_quote" style="margin: 0.0pt 0.0pt 1.0ex 0.8ex;border-left: 1.0px solid rgb(138,226,52);padding-left: 1.0ex;">
<blockquote class="gmail_quote" style="margin: 0.0pt 0.0pt 1.0ex 0.8ex;border-left: 1.0px solid rgb(252,175,62);padding-left: 1.0ex;">
<div>I&#39;m working on building backuppc from source on alpine linux on the</div>
</blockquote>

<div>home folder of a user ...</div>
</blockquote>

<div>...<br/>
I&#39;ve just committed a change to makeDist which adds the &#39;--verbose&#39;<br/>
option. If you grab the new version and run that with --verbose added<br/>
to the command line you will probably see what&#39;s missing ...<br/>
...<br/>
Please let me know how you get on. So far, you&#39;re doing famously!</div>
</blockquote>

<div><br/>
With the new feature, I was able to compile it and install it on the<br/>
home folder of the user I want to run it.</div>
</blockquote>

<div><br/>
:)<br/>
&nbsp;</div>

<blockquote class="gmail_quote" style="margin: 0.0pt 0.0pt 1.0ex 0.8ex;border-left: 1.0px solid rgb(114,159,207);padding-left: 1.0ex;">
<div>two question if I may:</div>
</blockquote>

<div><br/>
It&#39;s what we&#39;re here for.<br/>
&nbsp;</div>

<blockquote class="gmail_quote" style="margin: 0.0pt 0.0pt 1.0ex 0.8ex;border-left: 1.0px solid rgb(114,159,207);padding-left: 1.0ex;">
<div>1. Is there a way to run the perl configuration silently? so the<br/>
installation can be automated?</div>
</blockquote>

<div><br/>
Firstly I&#39;m not sure that it&#39;s necessary for something to be silent<br/>
just so that it can be automated. But secondly, yes, in fact several<br/>
ways. The simplest is probably to send the output to the bit-bucket,<br/>
or &#39;/dev/null&#39; as it&#39;s known in the Unix world. If, when you run a<br/>
command in a shell script (or at the command prompt), you put at the<br/>
end of the command line in the script (or the command at the prompt)<br/>
the characters &#39; 1&gt;/dev/null 2&gt;&amp;1&#39; (excluding the quotes that I&#39;ve<br/>
used there) then the output from the script (or command) will be sent<br/>
to a device whose only real job is to discard all its input. This is<br/>
one example of what we call &#39;redirection&#39;. In this case redirecting<br/>
the standard output and standard error output &#39;streams&#39;. Standard<br/>
output is &#39;1&gt;&#39; (for the &#39;bash&#39; shell and some others, just &#39;&gt;&#39; on its<br/>
own means the same thing) and standard error is &#39;2&gt;&#39;. The part that<br/>
reads &#39;2&gt;&amp;1&#39; means &quot;send the output from standard error to the same<br/>
place that standard output will go&quot;.<br/>
<br/>
There are other ways to use redirection. You can send the output to a<br/>
file (or files, for example &#39;&gt;./stdout.log 2&gt;./stderr.log&#39;). That&#39;s<br/>
what I usually do if I don&#39;t want to see reams of verbose output on<br/>
the screen, but I want to be able to look back later at what it said.<br/>
<br/>
You might remember that I suggested in an earlier mail that you could<br/>
delete some text from the &#39;makeDist&#39; script, to make its output more<br/>
verbose. That was exactly the same thing in reverse. But I digress.<br/>
&nbsp;</div>

<blockquote class="gmail_quote" style="margin: 0.0pt 0.0pt 1.0ex 0.8ex;border-left: 1.0px solid rgb(114,159,207);padding-left: 1.0ex;">
<div>2. As I use alpine linux, I&#39;ve opted not to use systemd, ...</div>
</blockquote>

<div><br/>
I understand perfectly. ;)<br/>
&nbsp;</div>

<blockquote class="gmail_quote" style="margin: 0.0pt 0.0pt 1.0ex 0.8ex;border-left: 1.0px solid rgb(114,159,207);padding-left: 1.0ex;">
<div>which file from .../src/init.d should I select?</div>
</blockquote>

<div><br/>
Using a search engine I searched for &quot;alpine linux&quot; &quot;init scripts&quot;.<br/>
Here are a few of pages that I found with a few clicks. I haven&#39;t<br/>
spent a lot of time on them but they look to be useful documentation.<br/>
<br/>
<a href="https://wiki.alpinelinux.org/wiki/Writing_Init_Scripts" target="_blank">https://wiki.alpinelinux.org/wiki/Writing_Init_Scripts</a><br/>
<a href="https://wiki.alpinelinux.org/wiki/OpenRC" target="_blank">https://wiki.alpinelinux.org/wiki/OpenRC</a><br/>
<a href="https://github.com/OpenRC/openrc" target="_blank">https://github.com/OpenRC/openrc</a><br/>
<br/>
Typical startup/shutdown scripts will do things like checking that the<br/>
resources which need to be available *are* available so that the thing<br/>
which is being started can, when started, do its job. For BackupPC,<br/>
for example, you&#39;d normally expect at least all the filesystems to be<br/>
accessible - so that BackupPC can find its configuration files, write<br/>
backup data to the pool and so on - and the network to be functioning<br/>
so it can fetch from other systems the data that you want to back up.<br/>
The &#39;shutdown&#39; part of the startup/shutdown scripts generally means a<br/>
way of stopping the thing that was started in a &#39;graceful&#39; way. Some<br/>
processes are a little fussy about that, they may for example need to<br/>
close files in a particular way or make sure that when the files are<br/>
closed there&#39;s something written to the file which marks it as having<br/>
been &#39;safely&#39; closed, whatever &#39;safely&#39; means. BackupPC isn&#39;t fussy.<br/>
<br/>
Because you&#39;re running BackupPC in a user home directory I&#39;m guessing<br/>
that things like that will already have been taken care of, so I&#39;m not<br/>
sure that any of the init-style scripts will be exactly what you want.<br/>
Perhaps all you&#39;d really need to do is type the command<br/>
<br/>
/path/to/your/BackupPC/bin/BackupPC -d<br/>
<br/>
or alternatively have a cron job check that BackupPC is running, and<br/>
if it isn&#39;t, start it (using that same command). Once it&#39;s started,<br/>
the BackupPC daemon will run until something stops it. Around here,<br/>
it will typically run for many months at a time without interruption.<br/>
<br/>
Anyway after all that it seems to me after a quick look at the docs<br/>
above that people have taken Gentoo scripts and used them as a basis<br/>
for something on Alpine. That might be a good place to start as it&#39;s<br/>
stuff you will probably want to be familiar with in future anyway. In<br/>
addition to starting the BackupPC backup server itself you might also<br/>
want the same script to start a Web server (probably Apache) or maybe<br/>
at least check that it&#39;s running, and if not warn you. If BackupPC is<br/>
configured to use an SCGI process as an intermediary between it and a<br/>
Web server, it will start it (and stop it) itself.<br/>
<br/>
Note that although a full-bells-n-whistles BackupPC installation will<br/>
run a Web server, BackupPC will run fine without one. It will still<br/>
back things up. The Web server is primarily needed for point&#39;n&#39;shoot<br/>
monitoring and control. After you start BackupPC you *can* control it<br/>
and get information from it by sending messages to it from the command<br/>
line. There are scripts in the archives of this Mailing List (also on<br/>
the BackupPC Wiki) which show you how you can do that sort of thing.<br/>
You might for example run a cron job which queries BackupPC each day -<br/>
perhaps at a time when you expect all the backups to be finished - and<br/>
sends you an email with the results.<br/>
<br/>
HTH<br/>
&nbsp;</div>
</blockquote>
</div>
_______________________________________________ BackupPC-users mailing list Bac...@li... List: <a href="https://lists.sourceforge.net/lists/listinfo/backuppc-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/backuppc-users</a> Wiki: <a href="https://github.com/backuppc/backuppc/wiki" target="_blank">https://github.com/backuppc/backuppc/wiki</a> Project: <a href="https://backuppc.github.io/backuppc/" target="_blank">https://backuppc.github.io/backuppc/</a></div>
</div>
</div>
</div></div></body></html>

Re: [BackupPC-users] unable to build backuppc from source

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

Greetings,

> Sent: Saturday, November 22, 2025 at 6:57 PM
> From: "G.W. Haywood" <ba...@ju...>
> To: bac...@li...
> Subject: Re: [BackupPC-users] unable to build backuppc from source
>
> Hello again,
> 
> On Sat, 22 Nov 2025, daggs wrote:
> > On Sun, 16 Nov 2025, G.W. Haywood wrote:
> > > On Sun, 16 Nov 2025, daggs via BackupPC-users wrote:
> > > 
> > > > I'm working on building backuppc from source on alpine linux on the
> > > > home folder of a user ...
> > > ...
> > > I've just committed a change to makeDist which adds the '--verbose'
> > > option.  If you grab the new version and run that with --verbose added
> > > to the command line you will probably see what's missing ...
> > > ...
> > > Please let me know how you get on.  So far, you're doing famously!
> > 
> > With the new feature, I was able to compile it and install it on the
> > home folder of the user I want to run it.
> 
> :)
> 
> > two question if I may:
> 
> It's what we're here for.
> 
> > 1. Is there a way to run the perl configuration silently? so the
> > installation can be automated?
> 
> Firstly I'm not sure that it's necessary for something to be silent
> just so that it can be automated.  But secondly, yes, in fact several
> ways.  The simplest is probably to send the output to the bit-bucket,
> or '/dev/null' as it's known in the Unix world.  If, when you run a
> command in a shell script (or at the command prompt), you put at the
> end of the command line in the script (or the command at the prompt)
> the characters ' 1>/dev/null 2>&1' (excluding the quotes that I've
> used there) then the output from the script (or command) will be sent
> to a device whose only real job is to discard all its input.  This is
> one example of what we call 'redirection'.  In this case redirecting
> the standard output and standard error output 'streams'.  Standard
> output is '1>' (for the 'bash' shell and some others, just '>' on its
> own means the same thing) and standard error is '2>'.  The part that
> reads '2>&1' means "send the output from standard error to the same
> place that standard output will go".
> 
> There are other ways to use redirection.  You can send the output to a
> file (or files, for example '>./stdout.log 2>./stderr.log').  That's
> what I usually do if I don't want to see reams of verbose output on
> the screen, but I want to be able to look back later at what it said.
> 
> You might remember that I suggested in an earlier mail that you could
> delete some text from the 'makeDist' script, to make its output more
> verbose.  That was exactly the same thing in reverse.  But I digress.
> 
> > 2. As I use alpine linux, I've opted not to use systemd, ...
> 
> I understand perfectly. ;)
> 
> > which file from .../src/init.d should I select?
> 
> Using a search engine I searched for "alpine linux" "init scripts".
> Here are a few of pages that I found with a few clicks.  I haven't
> spent a lot of time on them but they look to be useful documentation.
> 
> https://wiki.alpinelinux.org/wiki/Writing_Init_Scripts
> https://wiki.alpinelinux.org/wiki/OpenRC
> https://github.com/OpenRC/openrc
> 
> Typical startup/shutdown scripts will do things like checking that the
> resources which need to be available *are* available so that the thing
> which is being started can, when started, do its job.  For BackupPC,
> for example, you'd normally expect at least all the filesystems to be
> accessible - so that BackupPC can find its configuration files, write
> backup data to the pool and so on - and the network to be functioning
> so it can fetch from other systems the data that you want to back up.
> The 'shutdown' part of the startup/shutdown scripts generally means a
> way of stopping the thing that was started in a 'graceful' way.  Some
> processes are a little fussy about that, they may for example need to
> close files in a particular way or make sure that when the files are
> closed there's something written to the file which marks it as having
> been 'safely' closed, whatever 'safely' means.  BackupPC isn't fussy.
> 
> Because you're running BackupPC in a user home directory I'm guessing
> that things like that will already have been taken care of, so I'm not
> sure that any of the init-style scripts will be exactly what you want.
> Perhaps all you'd really need to do is type the command
> 
> /path/to/your/BackupPC/bin/BackupPC -d
> 
> or alternatively have a cron job check that BackupPC is running, and
> if it isn't, start it (using that same command).  Once it's started,
> the BackupPC daemon will run until something stops it.  Around here,
> it will typically run for many months at a time without interruption.
> 
> Anyway after all that it seems to me after a quick look at the docs
> above that people have taken Gentoo scripts and used them as a basis
> for something on Alpine.  That might be a good place to start as it's
> stuff you will probably want to be familiar with in future anyway.  In
> addition to starting the BackupPC backup server itself you might also
> want the same script to start a Web server (probably Apache) or maybe
> at least check that it's running, and if not warn you.  If BackupPC is
> configured to use an SCGI process as an intermediary between it and a
> Web server, it will start it (and stop it) itself.
> 
> Note that although a full-bells-n-whistles BackupPC installation will
> run a Web server, BackupPC will run fine without one.  It will still
> back things up.  The Web server is primarily needed for point'n'shoot
> monitoring and control.  After you start BackupPC you *can* control it
> and get information from it by sending messages to it from the command
> line.  There are scripts in the archives of this Mailing List (also on
> the BackupPC Wiki) which show you how you can do that sort of thing.
> You might for example run a cron job which queries BackupPC each day -
> perhaps at a time when you expect all the backups to be finished - and
> sends you an email with the results.
> 
> HTH

I've managed to get backuppc installed and started up.
I need to see how I can test the web-service as the machine is a vm
if needed, I can share the script I'm using.
as I'm using openrc, I used the gentoo's scripts

> 
> -- 
> 
> 73,
> Ged.
> 
> 
> _______________________________________________
> 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] unable to build backuppc from source

[Adam G. <mai...@we...>]

Jumping in late here...
You might like to look at the BackupPC docker container, I recall it runs as non-root, and also will isolate itself from the rest of the os. 
If nothing else, it should have some helpful scripts, since also from memory,it is based on alpine linux....
I've been running it that way on two servers for a year or so with no issues so far.

Regards,
Adam

On 23 November 2025 3:57:49 am AEDT, "G.W. Haywood" <ba...@ju...> wrote:
>Hello again,
>
>On Sat, 22 Nov 2025, daggs wrote:
>> On Sun, 16 Nov 2025, G.W. Haywood wrote:
>> > On Sun, 16 Nov 2025, daggs via BackupPC-users wrote:
>> > > > I'm working on building backuppc from source on alpine linux on the
>> > > home folder of a user ...
>> > ...
>> > I've just committed a change to makeDist which adds the '--verbose'
>> > option.  If you grab the new version and run that with --verbose added
>> > to the command line you will probably see what's missing ...
>> > ...
>> > Please let me know how you get on.  So far, you're doing famously!
>> 
>> With the new feature, I was able to compile it and install it on the
>> home folder of the user I want to run it.
>
>:)
>
>> two question if I may:
>
>It's what we're here for.
>
>> 1. Is there a way to run the perl configuration silently? so the
>> installation can be automated?
>
>Firstly I'm not sure that it's necessary for something to be silent
>just so that it can be automated.  But secondly, yes, in fact several
>ways.  The simplest is probably to send the output to the bit-bucket,
>or '/dev/null' as it's known in the Unix world.  If, when you run a
>command in a shell script (or at the command prompt), you put at the
>end of the command line in the script (or the command at the prompt)
>the characters ' 1>/dev/null 2>&1' (excluding the quotes that I've
>used there) then the output from the script (or command) will be sent
>to a device whose only real job is to discard all its input.  This is
>one example of what we call 'redirection'.  In this case redirecting
>the standard output and standard error output 'streams'.  Standard
>output is '1>' (for the 'bash' shell and some others, just '>' on its
>own means the same thing) and standard error is '2>'.  The part that
>reads '2>&1' means "send the output from standard error to the same
>place that standard output will go".
>
>There are other ways to use redirection.  You can send the output to a
>file (or files, for example '>./stdout.log 2>./stderr.log').  That's
>what I usually do if I don't want to see reams of verbose output on
>the screen, but I want to be able to look back later at what it said.
>
>You might remember that I suggested in an earlier mail that you could
>delete some text from the 'makeDist' script, to make its output more
>verbose.  That was exactly the same thing in reverse.  But I digress.
>
>> 2. As I use alpine linux, I've opted not to use systemd, ...
>
>I understand perfectly. ;)
>
>> which file from .../src/init.d should I select?
>
>Using a search engine I searched for "alpine linux" "init scripts".
>Here are a few of pages that I found with a few clicks.  I haven't
>spent a lot of time on them but they look to be useful documentation.
>
>https://wiki.alpinelinux.org/wiki/Writing_Init_Scripts
>https://wiki.alpinelinux.org/wiki/OpenRC
>https://github.com/OpenRC/openrc
>
>Typical startup/shutdown scripts will do things like checking that the
>resources which need to be available *are* available so that the thing
>which is being started can, when started, do its job.  For BackupPC,
>for example, you'd normally expect at least all the filesystems to be
>accessible - so that BackupPC can find its configuration files, write
>backup data to the pool and so on - and the network to be functioning
>so it can fetch from other systems the data that you want to back up.
>The 'shutdown' part of the startup/shutdown scripts generally means a
>way of stopping the thing that was started in a 'graceful' way.  Some
>processes are a little fussy about that, they may for example need to
>close files in a particular way or make sure that when the files are
>closed there's something written to the file which marks it as having
>been 'safely' closed, whatever 'safely' means.  BackupPC isn't fussy.
>
>Because you're running BackupPC in a user home directory I'm guessing
>that things like that will already have been taken care of, so I'm not
>sure that any of the init-style scripts will be exactly what you want.
>Perhaps all you'd really need to do is type the command
>
>/path/to/your/BackupPC/bin/BackupPC -d
>
>or alternatively have a cron job check that BackupPC is running, and
>if it isn't, start it (using that same command).  Once it's started,
>the BackupPC daemon will run until something stops it.  Around here,
>it will typically run for many months at a time without interruption.
>
>Anyway after all that it seems to me after a quick look at the docs
>above that people have taken Gentoo scripts and used them as a basis
>for something on Alpine.  That might be a good place to start as it's
>stuff you will probably want to be familiar with in future anyway.  In
>addition to starting the BackupPC backup server itself you might also
>want the same script to start a Web server (probably Apache) or maybe
>at least check that it's running, and if not warn you.  If BackupPC is
>configured to use an SCGI process as an intermediary between it and a
>Web server, it will start it (and stop it) itself.
>
>Note that although a full-bells-n-whistles BackupPC installation will
>run a Web server, BackupPC will run fine without one.  It will still
>back things up.  The Web server is primarily needed for point'n'shoot
>monitoring and control.  After you start BackupPC you *can* control it
>and get information from it by sending messages to it from the command
>line.  There are scripts in the archives of this Mailing List (also on
>the BackupPC Wiki) which show you how you can do that sort of thing.
>You might for example run a cron job which queries BackupPC each day -
>perhaps at a time when you expect all the backups to be finished - and
>sends you an email with the results.
>
>HTH
>
>-- 
>
>73,
>Ged.
>
>
>_______________________________________________
>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] unable to build backuppc from source

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

Hello again,

On Sat, 22 Nov 2025, daggs wrote:
> On Sun, 16 Nov 2025, G.W. Haywood wrote:
> > On Sun, 16 Nov 2025, daggs via BackupPC-users wrote:
> > 
> > > I'm working on building backuppc from source on alpine linux on the
> > > home folder of a user ...
> > ...
> > I've just committed a change to makeDist which adds the '--verbose'
> > option.  If you grab the new version and run that with --verbose added
> > to the command line you will probably see what's missing ...
> > ...
> > Please let me know how you get on.  So far, you're doing famously!
> 
> With the new feature, I was able to compile it and install it on the
> home folder of the user I want to run it.

:)

> two question if I may:

It's what we're here for.

> 1. Is there a way to run the perl configuration silently? so the
> installation can be automated?

Firstly I'm not sure that it's necessary for something to be silent
just so that it can be automated.  But secondly, yes, in fact several
ways.  The simplest is probably to send the output to the bit-bucket,
or '/dev/null' as it's known in the Unix world.  If, when you run a
command in a shell script (or at the command prompt), you put at the
end of the command line in the script (or the command at the prompt)
the characters ' 1>/dev/null 2>&1' (excluding the quotes that I've
used there) then the output from the script (or command) will be sent
to a device whose only real job is to discard all its input.  This is
one example of what we call 'redirection'.  In this case redirecting
the standard output and standard error output 'streams'.  Standard
output is '1>' (for the 'bash' shell and some others, just '>' on its
own means the same thing) and standard error is '2>'.  The part that
reads '2>&1' means "send the output from standard error to the same
place that standard output will go".

There are other ways to use redirection.  You can send the output to a
file (or files, for example '>./stdout.log 2>./stderr.log').  That's
what I usually do if I don't want to see reams of verbose output on
the screen, but I want to be able to look back later at what it said.

You might remember that I suggested in an earlier mail that you could
delete some text from the 'makeDist' script, to make its output more
verbose.  That was exactly the same thing in reverse.  But I digress.

> 2. As I use alpine linux, I've opted not to use systemd, ...

I understand perfectly. ;)

> which file from .../src/init.d should I select?

Using a search engine I searched for "alpine linux" "init scripts".
Here are a few of pages that I found with a few clicks.  I haven't
spent a lot of time on them but they look to be useful documentation.

https://wiki.alpinelinux.org/wiki/Writing_Init_Scripts
https://wiki.alpinelinux.org/wiki/OpenRC
https://github.com/OpenRC/openrc

Typical startup/shutdown scripts will do things like checking that the
resources which need to be available *are* available so that the thing
which is being started can, when started, do its job.  For BackupPC,
for example, you'd normally expect at least all the filesystems to be
accessible - so that BackupPC can find its configuration files, write
backup data to the pool and so on - and the network to be functioning
so it can fetch from other systems the data that you want to back up.
The 'shutdown' part of the startup/shutdown scripts generally means a
way of stopping the thing that was started in a 'graceful' way.  Some
processes are a little fussy about that, they may for example need to
close files in a particular way or make sure that when the files are
closed there's something written to the file which marks it as having
been 'safely' closed, whatever 'safely' means.  BackupPC isn't fussy.

Because you're running BackupPC in a user home directory I'm guessing
that things like that will already have been taken care of, so I'm not
sure that any of the init-style scripts will be exactly what you want.
Perhaps all you'd really need to do is type the command

/path/to/your/BackupPC/bin/BackupPC -d

or alternatively have a cron job check that BackupPC is running, and
if it isn't, start it (using that same command).  Once it's started,
the BackupPC daemon will run until something stops it.  Around here,
it will typically run for many months at a time without interruption.

Anyway after all that it seems to me after a quick look at the docs
above that people have taken Gentoo scripts and used them as a basis
for something on Alpine.  That might be a good place to start as it's
stuff you will probably want to be familiar with in future anyway.  In
addition to starting the BackupPC backup server itself you might also
want the same script to start a Web server (probably Apache) or maybe
at least check that it's running, and if not warn you.  If BackupPC is
configured to use an SCGI process as an intermediary between it and a
Web server, it will start it (and stop it) itself.

Note that although a full-bells-n-whistles BackupPC installation will
run a Web server, BackupPC will run fine without one.  It will still
back things up.  The Web server is primarily needed for point'n'shoot
monitoring and control.  After you start BackupPC you *can* control it
and get information from it by sending messages to it from the command
line.  There are scripts in the archives of this Mailing List (also on
the BackupPC Wiki) which show you how you can do that sort of thing.
You might for example run a cron job which queries BackupPC each day -
perhaps at a time when you expect all the backups to be finished - and
sends you an email with the results.

HTH

-- 

73,
Ged.

Re: [BackupPC-users] unable to build backuppc from source

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

Greetings,

> Sent: Sunday, November 16, 2025 at 5:28 PM
> From: "G.W. Haywood" <ba...@ju...>
> To: bac...@li...
> Subject: Re: [BackupPC-users] unable to build backuppc from source
>
> Hello again,
> 
> On Sun, 16 Nov 2025, daggs via BackupPC-users wrote:
> 
> > I'm working on building backuppc from source on alpine linux on the
> > home folder of a user and I've encountered an issue.  when I clone
> > the main backuppc repo to my home folder and run perl configure.pl
> > inside it like the readme states the build fails stating that I need
> > to install from a tarball or run makeDist.  So I've extracted the
> > latest tag name for the tags list ad used it as version, now I'm
> > getting this:
> > 
> > $ ./makeDist --version 4.4.1rc1
> > ./makeDist: bin/BackupPC_Admin_SCGI contains an error (or someone killed me)
> > 
> > any idea what am I missing or how to fix  this issue?
> 
> Alpine Linux leans toward the minimalist end of the spectrum so you're
> probably just missing a few Perl modules.  The makeDist script checks
> that the BackupPC scripts which it's packaging can be compiled by Perl
> before it makes the package.  To do that it runs 'perl -c scriptName'
> where scriptName is any of the BackupPC scripts.  When a module needed
> by a BackupPC script can't be loaded by the system, you see the error
> message which you quoted.  Might be you need at least the SCGI module.
> 
> I've just committed a change to makeDist which adds the '--verbose'
> option.  If you grab the new version and run that with --verbose added
> to the command line you will probably see what's missing from your
> kit.  As makeDist is a Perl script you could edit it.  You'd get most
> of the verbosity I've added by editing one line in your existing copy.
> Just remove the string '2> /dev/null' from the *last* of the three
> occurrences of that string in the file.  It looks like the first two
> tests ran OK, so you don't need to worry about them, but each tests
> only one script.  The third test is in a loop and tests dozens.
> 
> When you find which modules you need you might be able to install them
> from an Alpine package using 'apk'; if they aren't packaged for Alpine
> you can grab them from e.g. CPAN.  You can install them to a location
> under your home directory if you wish, but it's unusual to do that and
> you'd need to make sure that Perl could then find them when needed by
> adding the correct path(s) to Perl's environment at runtime.
> 
> Please let me know how you get on.  So far, you're doing famously!
> 
> -- 

With the new feature, I was able to compile it and install it on the home folder of the user I want to run it.
two question if I may:
1. Is there a way to run the perl configuration silently? so the installation can be automated?
2. As I use alpine linux, I've opted not to use systemd, which file from https://github.com/backuppc/backuppc/tree/4.4.0/systemd/src/init.d should I select? also, what changes I need to preform in order to have it working on my instance?

Thanks,
Dagg

> 
> 73,
> Ged.
> 
> 
> _______________________________________________
> 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

[Adam G. <mai...@we...>]

I would really really like this, the whole concept of having a single file from the maintainer which is so big and then sprinkle a handful of changes is pretty bad.
In fact, I'd ideally like to see a directory of config files config.d, where the files are read in alpha/numerical order. We can still have a single web config file 00-web-config.pl. This makes it clear where the config changes are made, and also helps to use other systems to manage and push out config files/changes. 

This should make upgrades really easy to manage as well.

Don't currently have time to work on it either, but if we are dreaming of a better system, then might as well make it as flexible as possible. 

On 22 November 2025 7:39:24 am AEDT, bac...@ko... wrote:
>I *like* this idea along with creating timestamped backups of older
>versions of site-config.pl even though I never have used the web UI to
>write configs (for all the reasons that have been sited, including
>that it clobbers ones otherwise pristine or carefully edited config.pl)
>
>Do we really need both site-config.pl and localconfig.pl?
>Is one for web-editing and one for manual editing?
>I don't have a strong opinion but just wanted to think through this.
>
>
>G.W. Haywood wrote at about 13:34:58 +0000 on Friday, November 21, 2025:
> > Hi there,
> > 
> > On Thu, 20 Nov 2025, Paul Fox wrote:
> > 
> > > ...
> > > it seems that backuppc issue #486 is moot, and can be closed ...
> > 
> > It's closed.
> > 
> > There might be an easy way to do something like what could have been
> > intended by the Debian patch.  My idea is to have the Web UI editor
> > write to a new file (called 'site-config.pl' for example, so there's
> > no confusion with any 'localconfig.pl' that's still lying around).
> > 
> > The Web UI would only write to 'site-config.pl' those configuration
> > elements which are changed from the defaults installed in 'config.pl'.
> > (The main pain in coding would be that part, but it's fairly easily
> > doable.)  The Web UI would no longer change the existing 'config.pl'.
> > Ever.
> > 
> > The config in 'site-config.pl' would take precedence over the existing
> > 'config.pl'.  So there'd be no need to make any changes at all to the
> > configuration file which was provided when BackupPC was installed.
> > 
> > It wouldn't be too difficult also to look for any 'localconfig.pl' and
> > to do something with it if something in 'site-config.pl' permitted it.
> > 
> > So everybody would be happy.  I think.
> > 
> > It seems like not a big job, but I don't have time to actually do any
> > of this at the moment.  I throw this out for discussion in case there
> > are interested parties who can see pitfalls or suggest improvements to
> > the ideas.  Please keep the discussion here on the Mailing List until
> > there's some sort of a consensus on best the way forward.  After that,
> > if anyone would like to provide a PR I'd be very grateful.
> > 
> > When the Web UI writes a new configuration, at present it will rename
> > the old configuration file with the extension '.old' before writing a
> > new file.  I'd much prefer to write 'site-config.pl.old.$timestamp' or
> > something like that [*] (emacs does something similar here, for almost
> > everything that I edit with a text editor).
> > 
> > -- 
> > 
> > 73,
> > Ged.
> > 
> > [*] See Mr. Mikesell's post:
> > https://sourceforge.net/p/backuppc/mailman/message/59260402/
> > 
> > 
> > _______________________________________________
> > 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] debian patch for localconfig.pl

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

I *like* this idea along with creating timestamped backups of older
versions of site-config.pl even though I never have used the web UI to
write configs (for all the reasons that have been sited, including
that it clobbers ones otherwise pristine or carefully edited config.pl)

Do we really need both site-config.pl and localconfig.pl?
Is one for web-editing and one for manual editing?
I don't have a strong opinion but just wanted to think through this.


G.W. Haywood wrote at about 13:34:58 +0000 on Friday, November 21, 2025:
 > Hi there,
 > 
 > On Thu, 20 Nov 2025, Paul Fox wrote:
 > 
 > > ...
 > > it seems that backuppc issue #486 is moot, and can be closed ...
 > 
 > It's closed.
 > 
 > There might be an easy way to do something like what could have been
 > intended by the Debian patch.  My idea is to have the Web UI editor
 > write to a new file (called 'site-config.pl' for example, so there's
 > no confusion with any 'localconfig.pl' that's still lying around).
 > 
 > The Web UI would only write to 'site-config.pl' those configuration
 > elements which are changed from the defaults installed in 'config.pl'.
 > (The main pain in coding would be that part, but it's fairly easily
 > doable.)  The Web UI would no longer change the existing 'config.pl'.
 > Ever.
 > 
 > The config in 'site-config.pl' would take precedence over the existing
 > 'config.pl'.  So there'd be no need to make any changes at all to the
 > configuration file which was provided when BackupPC was installed.
 > 
 > It wouldn't be too difficult also to look for any 'localconfig.pl' and
 > to do something with it if something in 'site-config.pl' permitted it.
 > 
 > So everybody would be happy.  I think.
 > 
 > It seems like not a big job, but I don't have time to actually do any
 > of this at the moment.  I throw this out for discussion in case there
 > are interested parties who can see pitfalls or suggest improvements to
 > the ideas.  Please keep the discussion here on the Mailing List until
 > there's some sort of a consensus on best the way forward.  After that,
 > if anyone would like to provide a PR I'd be very grateful.
 > 
 > When the Web UI writes a new configuration, at present it will rename
 > the old configuration file with the extension '.old' before writing a
 > new file.  I'd much prefer to write 'site-config.pl.old.$timestamp' or
 > something like that [*] (emacs does something similar here, for almost
 > everything that I edit with a text editor).
 > 
 > -- 
 > 
 > 73,
 > Ged.
 > 
 > [*] See Mr. Mikesell's post:
 > https://sourceforge.net/p/backuppc/mailman/message/59260402/
 > 
 > 
 > _______________________________________________
 > 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

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

Hi there,

On Thu, 20 Nov 2025, Paul Fox wrote:

> ...
> it seems that backuppc issue #486 is moot, and can be closed ...

It's closed.

There might be an easy way to do something like what could have been
intended by the Debian patch.  My idea is to have the Web UI editor
write to a new file (called 'site-config.pl' for example, so there's
no confusion with any 'localconfig.pl' that's still lying around).

The Web UI would only write to 'site-config.pl' those configuration
elements which are changed from the defaults installed in 'config.pl'.
(The main pain in coding would be that part, but it's fairly easily
doable.)  The Web UI would no longer change the existing 'config.pl'.
Ever.

The config in 'site-config.pl' would take precedence over the existing
'config.pl'.  So there'd be no need to make any changes at all to the
configuration file which was provided when BackupPC was installed.

It wouldn't be too difficult also to look for any 'localconfig.pl' and
to do something with it if something in 'site-config.pl' permitted it.

So everybody would be happy.  I think.

It seems like not a big job, but I don't have time to actually do any
of this at the moment.  I throw this out for discussion in case there
are interested parties who can see pitfalls or suggest improvements to
the ideas.  Please keep the discussion here on the Mailing List until
there's some sort of a consensus on best the way forward.  After that,
if anyone would like to provide a PR I'd be very grateful.

When the Web UI writes a new configuration, at present it will rename
the old configuration file with the extension '.old' before writing a
new file.  I'd much prefer to write 'site-config.pl.old.$timestamp' or
something like that [*] (emacs does something similar here, for almost
everything that I edit with a text editor).

-- 

73,
Ged.

[*] See Mr. Mikesell's post:
https://sourceforge.net/p/backuppc/mailman/message/59260402/

Re: [BackupPC-users] BackupPC and EPEL10

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

On 11/20/25 6:05 PM, Richard Shaw wrote:
> Let me amend, it looks like we need 
> perl-Net-FTP-RetrHandle but it may yet have other deps...
>
> On Thu, Nov 20, 2025 at 5:00 PM Richard Shaw 
> <hob...@gm...> wrote:
>
>     On Wed, Nov 19, 2025 at 7:06 AM Jamie Burchell via
>     BackupPC-users <bac...@li...>
>     wrote:
>
>         Is the current bad karma due to the build failing?
>         I still see this:
>
>         Error: Problem: conflicting requests - nothing
>         provides perl(Net::FTP::AutoReconnect) needed by
>         BackupPC-4.4.0-20.el10_2.x86_64 from
>         brew-139020571 - nothing provides
>         perl(Net::FTP::RetrHandle) needed by
>         BackupPC-4.4.0-20.el10_2.x86_64 from
>         brew-139020571 (try to add '--skip-broken' to skip
>         uninstallable packages or '--nobest' to use not
>         only best candidate packages) Installation of
>         BackupPC-0:4.4.0-20.el10_2.x86_64 failed. See
>         dnf-3 command output above for more information.
>
>
>     Those are run time dependencies not build time
>     dependencies so I didn't see the issue when building.
>     Those will need to be built for EPEL 10 as well but
>     I'm not the maintainer.
>
>     It looks like perl-libnet needs to be built for EPEL 10...
>
>     Thanks,
>     Richard
>
Correct me if I'm wrong but I think you can skip this 
dependency if you don't use the FTP protocol in your backups.

-- 
Jim KR

Re: [BackupPC-users] backuppc virtual machine vmware free

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

Hi there,

On Fri, 21 Nov 2025, Mia Mia wrote:

> ... I've been using BackupPC installed on Debian 5 for a long time,

Are you sure that you still want to use 'Lenny' for your backups?
According to

https://wiki.debian.org/DebianReleases

Debian 5 End Of Life was over 13 years ago.

> and it works great with shared folder backups. I wanted to ask, is
> it possible to back up entire VMware free virtual machines?

Yes, it is *possible*, but BackupPC works best when it is used to back
up files which are treated as files by the system on which they live.
Although a VM image may appear to be a file in your filesystem, it is
treated by the VM as an image of a mass storage device.  If you mean
to back up images of mass storage devices then my advice would be that
there are better ways of doing it than to use BackupPC.

-- 

73,
Ged.

Re: [BackupPC-users] BackupPC and EPEL10

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

Hi there,

On Fri, 21 Nov 2025, Richard Shaw wrote:
> On Wed, Nov 19, 2025 Jamie Burchell via BackupPC-users wrote:
>> ...
>> ... nothing provides perl(Net::FTP::AutoReconnect) ...
>> ... nothing provides perl(Net::FTP::RetrHandle) ...
>> ...
>
> Those are run time dependencies not build time dependencies so I
> didn't see the issue when building. ...

BackupPC's 'makeDist' script specifically excludes a check for modules
from .../lib/Net/FTP/.  Would it help if they were *not* excluded?  It
would be a trivial change.  Obviously those modules won't be needed if
the configuration doesn't use FTP transfers; the test output could say
that (if the new makeDist '--verbose' option is given :) and build the
dist files despite those particular test results.

-- 

73,
Ged.

Re: [BackupPC-users] BackupPC and EPEL10

[Richard S. <hob...@gm...>]

I would rather have direct EPEL support but as a stop-gap I have refreshed
my COPR for EPEL 8, 9, and 10.

https://copr.fedorainfracloud.org/coprs/hobbes1069/BackupPC/

If someone could test if this is installable and report any issues it would
be helpful. We may yet be missing a few perl dependencies.

Thanks,
Richard