Re: [BackupPC-users] Help with monthly schedule configuration

2017-11-16 Thread Ray Frush
The incremental period of 0.97 results in a daily backup, so that's
probably what you want to keep.


My schedule ends up giving you something like this:   ~32 daily backups + a
couple of older ones just in case you need an older file.

Backup# Type Filled Level Start Date Duration/mins Age/days
0 full yes 0 2017-09-20 18:00 0.3 56.9
14 incr yes 1 2017-10-04 19:00 0.1 42.9
26 incr no 1 2017-10-16 19:00 0.1 30.9
27 incr no 1 2017-10-17 19:00 0.1 29.9
28 incr yes 1 2017-10-18 19:00 0.1 28.9
29 incr no 1 2017-10-19 19:00 0.1 27.9
30 incr no 1 2017-10-20 19:00 0.1 26.9
31 incr no 1 2017-10-21 19:00 0.1 25.9
32 incr no 1 2017-10-22 19:00 0.1 24.9
33 incr no 1 2017-10-23 19:00 0.1 23.9
34 incr no 1 2017-10-24 19:00 0.1 22.9
35 incr yes 1 2017-10-25 22:00 0.1 21.8
36 incr no 1 2017-10-26 22:00 0.1 20.8
37 incr no 1 2017-10-27 22:00 0.1 19.8
38 incr no 1 2017-10-28 22:00 0.1 18.8
39 incr no 1 2017-10-29 22:00 0.1 17.8
40 incr no 1 2017-10-30 22:00 0.1 16.8
41 incr no 1 2017-10-31 22:00 0.1 15.8
42 incr yes 1 2017-11-01 22:00 0.1 14.8
43 incr no 1 2017-11-02 22:00 0.1 13.8
44 incr no 1 2017-11-03 22:00 0.1 12.8
45 incr no 1 2017-11-04 22:00 0.1 11.8
46 incr no 1 2017-11-05 21:00 0.1 10.8
47 incr no 1 2017-11-06 21:00 0.1 9.8
48 incr no 1 2017-11-07 21:00 0.1 8.8
49 incr yes 1 2017-11-08 21:00 0.2 7.8
50 incr no 1 2017-11-09 21:00 0.1 6.8
51 incr no 1 2017-11-10 21:00 0.1 5.8
52 incr no 1 2017-11-11 21:00 0.1 4.8
53 incr no 1 2017-11-12 21:00 0.1 3.8
54 incr no 1 2017-11-13 21:00 0.1 2.8
55 incr no 1 2017-11-14 21:00 0.1 1.8
56 incr yes 1 2017-11-15 21:00 0.1 0.8

On Thu, Nov 16, 2017 at 2:16 AM, Jamie Burchell  wrote:

> Thanks Ray
>
>
>
> I’ll be honest, I still don’t understand those settings after re-reading
> several times.
>
>
>
> What should the incremental period be here 0.97
>
>
>
> I’m also only interested in one month’s worth, so can that schedule be
> simplified?
>
>
>
> Jamie
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> BackupPC-users mailing list
> BackupPC-users@lists.sourceforge.net
> List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki:http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
>
>


-- 
Time flies like an arrow, but fruit flies like a banana.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/


[BackupPC-users] problem with samba

2017-11-16 Thread Micha Silver

  
  
About a month ago samba was updated to version 4.6 on my BackupPC
server (version 3.3) and since then I can't do a full backup of Win7
machines. Incrementals work, but not the fulls. I get
NT_STATUS_LOGON_FAILURE, but I think that's bogus. I have an idea
that the problem is the "tarmode" part of the smbclient command. It
seems that "tarmode verbose full" is not supported any longer. The
only tarmode options that the new smbclient recognizes are full,
inc, reset and noreset. 
Any suggestions what the smbclient command should be now with the
newer samba version?
Thanks

-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
+972-523-665918
  


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


Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

2017-11-16 Thread Bzzzz
On Thu, 16 Nov 2017 12:22:00 -0600
Les Mikesell  wrote:

> No, but when doing a restore for any reason other than accidental
> complete deletion of a file or directory I nearly always restore to a
> different location and compare things instead of overwriting the
> existing current versions anyway.

Ok, I clearly see your point and value it as a wise thing to do when you
only have BPC as a safety net.

> Your hypothetical educated user […]

Well, this is relatively different as BPC is shot over night once per
24Hrs. In fact, they only use it for former docs they mess with; current
ones, wrecked during the same day must be addressed by one admin, as
they must be extracted from an hourly FS snapshot.
But surprisingly, this is a very rare operation; which may be tied to
the fact that admins interventions are strictly limited to the morning,
no matter what (except servers breakdown.)

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


Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

2017-11-16 Thread Les Mikesell
On Thu, Nov 16, 2017 at 12:08 PM, B  wrote:
> On Thu, 16 Nov 2017 10:45:40 -0600
> Les Mikesell  wrote:
>
>> Yes, but things have to be very, very screwed up to get to the point
>> where the user can't fix it with a tar download through a browser
>> followed by an appropriate restore command.  When things have been
>> broken that badly it may be time to let someone else fix it.  And if
>> you are restoring a whole system you have to configure that part again
>> anyway.
>
> Well, I can concede this to you, but it is a tiny bit extreme.
> (do you climb mountains free hands with pitch black glasses and a
> chopper waiting for you at the top ?;)

No, but when doing a restore for any reason other than accidental
complete deletion of a file or directory I nearly always restore to a
different location and compare things instead of overwriting the
existing current versions anyway.  And it is not at all difficult to
download a tar image and restore it where you want.  Your hypothetical
educated user that knows enough not to overwrite good data should not
have a problem with it.

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

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


Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

2017-11-16 Thread Bzzzz
On Thu, 16 Nov 2017 17:57:59 +0100
Holger Parplies  wrote:

Whoops, wrong from: (and strange setup), putting this back in the list.

> B wrote on 2017-11-16 00:50:52 +0100 [Re: [BackupPC-users] error
> in rsync protocol data stream (code 12) (Restoring)]:  
> > [...]
> > In short: being root and (especially) removing directories is bad, on
> > the other hand, using root as part of a controlled process doesn't
> > mean that you'll be hacked or whatever - furthermore, doing some
> > stuffs as root is compulsory for some maintenance work.
> 
> wrong. Not understanding a concept and giving advice about it is bad.  

Ok, so develop it, this way I could understand what's so terribly wrong.

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


Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

2017-11-16 Thread Bzzzz
On Thu, 16 Nov 2017 10:45:40 -0600
Les Mikesell  wrote:

> Yes, but things have to be very, very screwed up to get to the point
> where the user can't fix it with a tar download through a browser
> followed by an appropriate restore command.  When things have been
> broken that badly it may be time to let someone else fix it.  And if
> you are restoring a whole system you have to configure that part again
> anyway.

Well, I can concede this to you, but it is a tiny bit extreme.
(do you climb mountains free hands with pitch black glasses and a
chopper waiting for you at the top ?;)

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


Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

2017-11-16 Thread Jamie Burchell
So there's basically no point in having just "--sender" - it doesn't make
anything "more secure"? Even through obscurity? (presumably an attacker
running rsync wouldn't know they needed to have --sender as the first
param)?

The only person who has access to BackupPC and its web UI is me. The
machine it runs on is locked down by IP, only SSH access (web UI is
accessed through the tunnel with port forwarding) and a .htaccess password
is thrown in for good measure. The "clients" in my case are web
application servers rather than end users. Root account access to them is
disabled, only certain users can SSH with their key pairs.

Kind regards,

Jamie

--
Jamie Burchell
Senior Web Developer

01732 449974

ja...@ib3.uk
--
ib3 Limited
2 Lyons Wharf, Lyons Crescent,
Tonbridge TN9 1EX

01732 449970
https://www.ib3.uk/
--

This email and any attachments to it may be confidential and are intended
solely for the use of the individual to whom it is addressed. Any views or
opinions expressed are solely those of the author and do not necessarily
represent those of ib3 Limited.

If you are not the intended recipient of this email, you must neither take
any action based upon its contents, nor copy or show it to anyone.

Please contact the sender if you believe you have received this email in
error.

ib3 is a limited company registered in England and Wales.
Registered number: 3734612.
Registered office: Riverside, 2 Lyons Wharf, Lyons Crescent, Tonbridge,
Kent TN9 1EX, United Kingdom.
-Original Message-
From: Holger Parplies [mailto:wb...@parplies.de]
Sent: 16 November 2017 16:58
To: Jamie Burchell ; B 
Cc: backuppc-users@lists.sourceforge.net
Subject: Re: [BackupPC-users] error in rsync protocol data stream (code
12) (Restoring)

B wrote on 2017-11-16 00:50:52 +0100 [Re: [BackupPC-users] error in
rsync protocol data stream (code 12) (Restoring)]:
> [...]
> In short: being root and (especially) removing directories is bad, on
> the other hand, using root as part of a controlled process doesn't
> mean that you'll be hacked or whatever - furthermore, doing some
> stuffs as root is compulsory for some maintenance work.

wrong. Not understanding a concept and giving advice about it is bad.

Jamie Burchell wrote on 2017-11-15 22:48:01 - [[BackupPC-users] error
in rsync protocol data stream (code 12) (Restoring)]:
> [...]
> I followed the instructions to make a restricted backuppc user on
> client machines with limited sudo permission thus:
>
> backuppc ALL=NOPASSWD: /usr/bin/rsync --server --sender *
>
> This works fine for backing up, but I just discovered I can no longer
> restore directly,

That is by design. I believe this suggestion was originally mine, and the
intention is exactly to disable write access to arbitrary files via the
backuppc user. As you wrote, if you don't want that restriction, leave out
at least the '--sender' parameter. In this case, you might as well leave
out the parameters altogether and just allow /usr/bin/rsync (with any
parameters). In fact, I would even suggest narrowing down the allowed
command further yet, if that wasn't tedious to implement and maintain (and
error-prone, because you will, at some point, forget to adjust it to a
BackupPC configuration change).

The problem is not that BackupPC somehow guarantees that you will be
hacked.
Fact is, if your BackupPC server *is* compromised, the attacker (local or
remote) gets a free passwordless login into all the clients. For B,
that is a free root shell. No problem (not mine, anyway). For you and me,
it's only an unprivileged user shell. With the '--server --sender' above,
all that can be done with that (without a further exploit) is reading all
files (including /etc/shadow -- that is basically why I would want to
further restrict the allowed command). Without '--sender', you get *write*
access to /etc/shadow (and everything else, of course), meaning you can
change the root password.
Well, that obviously gives you a root shell again. There are tons of other
(more subtle) ways to do that, but this is the most obvious.

Also note that you don't even need to be exploited. As Les pointed out,
anyone who can trigger a direct restore can get this root shell. So, the
question is, is everyone who can trigger a direct restore *supposed to*
have root access to the client in question?

Les also mentions that direct restores are more error-prone than, e.g.,
downloading a tar file with the files you want from the backup. In my
experience, I often prefer to compare the current version with the
contents in my backup before overwriting it - it may not be retrievable
afterwards if it was modified after the last backup or turns out to have
failed to be backed up recently for any reason. So I tend to disable
direct restores.
Should I ever need a complete restore, I'll do it from the command line
anyway. Of course, your 

Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

2017-11-16 Thread Holger Parplies
B wrote on 2017-11-16 00:50:52 +0100 [Re: [BackupPC-users] error in rsync 
protocol data stream (code 12) (Restoring)]:
> [...]
> In short: being root and (especially) removing directories is bad, on
> the other hand, using root as part of a controlled process doesn't mean
> that you'll be hacked or whatever - furthermore, doing some stuffs as
> root is compulsory for some maintenance work.

wrong. Not understanding a concept and giving advice about it is bad.

Jamie Burchell wrote on 2017-11-15 22:48:01 - [[BackupPC-users] error in 
rsync protocol data stream (code 12) (Restoring)]:
> [...]
> I followed the instructions to make a restricted backuppc user on client
> machines with limited sudo permission thus:
> 
> backuppc ALL=NOPASSWD: /usr/bin/rsync --server --sender *
> 
> This works fine for backing up, but I just discovered I can no longer
> restore directly,

That is by design. I believe this suggestion was originally mine, and the
intention is exactly to disable write access to arbitrary files via the
backuppc user. As you wrote, if you don't want that restriction, leave out
at least the '--sender' parameter. In this case, you might as well leave
out the parameters altogether and just allow /usr/bin/rsync (with any
parameters). In fact, I would even suggest narrowing down the allowed
command further yet, if that wasn't tedious to implement and maintain (and
error-prone, because you will, at some point, forget to adjust it to a
BackupPC configuration change).

The problem is not that BackupPC somehow guarantees that you will be hacked.
Fact is, if your BackupPC server *is* compromised, the attacker (local or
remote) gets a free passwordless login into all the clients. For B, that
is a free root shell. No problem (not mine, anyway). For you and me, it's only
an unprivileged user shell. With the '--server --sender' above, all that can
be done with that (without a further exploit) is reading all files (including
/etc/shadow -- that is basically why I would want to further restrict the
allowed command). Without '--sender', you get *write* access to /etc/shadow
(and everything else, of course), meaning you can change the root password.
Well, that obviously gives you a root shell again. There are tons of other
(more subtle) ways to do that, but this is the most obvious.

Also note that you don't even need to be exploited. As Les pointed out,
anyone who can trigger a direct restore can get this root shell. So, the
question is, is everyone who can trigger a direct restore *supposed to*
have root access to the client in question?

Les also mentions that direct restores are more error-prone than, e.g.,
downloading a tar file with the files you want from the backup. In my
experience, I often prefer to compare the current version with the contents
in my backup before overwriting it - it may not be retrievable afterwards
if it was modified after the last backup or turns out to have failed to be
backed up recently for any reason. So I tend to disable direct restores.
Should I ever need a complete restore, I'll do it from the command line
anyway. Of course, your mileage may vary.

Hope that helps.

Regards,
Holger

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


Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

2017-11-16 Thread Les Mikesell
On Thu, Nov 16, 2017 at 10:37 AM, B  wrote:
> On Thu, 16 Nov 2017 10:21:49 -0600
> Les Mikesell  wrote:
>
>> damaging) direct restore.  But the admin should know what to tweak if
>> he does need that massive restore.
>
> Yup, and the problem is: in this configuration, you *need* an admin
> intervention to fix a restore,

Yes, but things have to be very, very screwed up to get to the point
where the user can't fix it with a tar download through a browser
followed by an appropriate restore command.  When things have been
broken that badly it may be time to let someone else fix it.  And if
you are restoring a whole system you have to configure that part again
anyway.

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

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


Re: [BackupPC-users] Help with monthly schedule configuration

2017-11-16 Thread Gerald Brandt



On 2017-11-16 03:16 AM, Jamie Burchell wrote:


Thanks Ray

I’ll be honest, I still don’t understand those settings after 
re-reading several times.


What should the incremental period be here 0.97

I’m also only interested in one month’s worth, so can that schedule be 
simplified?


Jamie



Hi,

I  have:

Full Backups

FullPeriod 
 
	
FullKeepCnt 
 
	
FullKeepCntMin 
 
	
FullAgeMax 
 
	

Incremental Backups
IncrPeriod 
 
	
IncrKeepCnt 
 
	
IncrKeepCntMin 
 
	
IncrAgeMax 
 
	
IncrLevels 
 
	
IncrFill 
 
	



And then a few scripts that maintain what I want. Attached.

This gives me full backups every Friday and on the last day of the 
month, and keeps backups for as long as I want (specified in 
prune_backups.sh)


Gerald


Gerald


archive_backups.sh
Description: application/shellscript
#!/bin/bash

# force all hosts in the host file do have a full backup on Friday
# unless that Friday is the last workday of the month
if [ ! $(cal | tr -s '[:blank:]' '\n' |tail -1) = $(date +%d) ]
then
  for HOST in $(cat /etc/backuppc/hosts | grep ^[A-Za-z0-9] | grep -v host | 
grep -v archive | awk '{print $1}')
  do
/usr/share/backuppc/bin/BackupPC_serverMesg backup ${HOST} ${HOST} backuppc 
1
#   echo ${HOST}
  done
fi
#!/bin/bash

# force all hosts in the host file do have a full backup on last day of month
TODAY=`/bin/date +%d`
TOMORROW=`/bin/date +%d -d "1 day"`

#if [ $(cal | tr -s '[:blank:]' '\n' |tail -1) = $(date +%d) ]
if [ $TOMORROW -lt $TODAY ]
then
  for HOST in $(cat /etc/backuppc/hosts | grep ^[A-Za-z0-9] | grep -v host | 
grep -v archive | awk '{print $1}')
  do
/usr/share/backuppc/bin/BackupPC_serverMesg backup ${HOST} ${HOST} backuppc 
1
#   echo ${HOST}
  done
fi


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


Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

2017-11-16 Thread Bzzzz
On Thu, 16 Nov 2017 10:21:49 -0600
Les Mikesell  wrote:

> damaging) direct restore.  But the admin should know what to tweak if
> he does need that massive restore.
 
Yup, and the problem is: in this configuration, you *need* an admin
intervention to fix a restore, when the other solution easily leads
to: user = BPC user <=> each user can backup/restore from 1 file
to his whole $HOME (if needed) without having to ask the admin to do so.
This means informed users, but IMHO the time taken to train them is, by
far, less pain than being disturbed any time.

Of course YMMV as this depends on company policy, some don't want any
direct contact between user and data (well, it also depends on admins,
some want to control everything, others not;-p)

Jiff

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


Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

2017-11-16 Thread Les Mikesell
On Thu, Nov 16, 2017 at 3:19 AM, Jamie Burchell  wrote:
> Running as a restricted user is actually part of the BackupPC
> documentation. It just neglects to mention that doing so as described
> means restores are blocked.
>
> Having a non root user with sudo permissions to just rsync with the
> "--server" param works fine for backup and restore.

Maybe that should be documented more clearly.   I could see where the
read-only version might be useful in typical operation where the host
'owner' could still use the web interface to download copies of old
files or directories but could not do a massive (and potentially
damaging) direct restore.  But the admin should know what to tweak if
he does need that massive restore.

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

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


Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

2017-11-16 Thread Jamie Burchell
Running as a restricted user is actually part of the BackupPC
documentation. It just neglects to mention that doing so as described
means restores are blocked.

Having a non root user with sudo permissions to just rsync with the
"--server" param works fine for backup and restore.

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


Re: [BackupPC-users] Help with monthly schedule configuration

2017-11-16 Thread Jamie Burchell
Thanks Ray



I’ll be honest, I still don’t understand those settings after re-reading
several times.



What should the incremental period be here 0.97



I’m also only interested in one month’s worth, so can that schedule be
simplified?



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


[BackupPC-users] PC Backup Genie message

2017-11-16 Thread infos+backuppc
Hello,

We are using BPC4 on a Gentoo system, with our home-brewed ebuilds for
install. Everything is OK, except a (minor) annoyance with PC Backup Genie.

We "locked" some directories in the ebuilds, meaning that if we
uninstall BPC, those directories will not be destroyed (same idea with
keeping config files : an upgrade means automatically uninstalling the
old version, and some stuff must be kept).

The PC Backup Genie is thus sending a daily message while doing its
normal chores, because it finds a "wrong" file/directory in the BPC/pc
subdir :

The following directories are bogus and are not being used by
BackupPC.  This typically happens when PCs are removed from the
backup list.  If you don't need any old backups from these PCs you
should remove these directories.  If there are machines on this
list that should be backed up then there is a problem with the
hosts file:
  - /home/BackupPC/pc/.keep_app-backup_backuppc-0

Is there any easy way to make PC Backup Genie ignore this file during
its checks ?

Thanks,
-- 
B Consultants

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