Re: [BackupPC-users] Vanished file

2021-01-09 Thread Alexander Moisseev via BackupPC-users

Seems the same as https://github.com/backuppc/rsync-bpc/issues/18


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


Re: [BackupPC-users] Vanished file

2021-01-09 Thread Craig Barratt via BackupPC-users
Pete,

Also, it would be good to see if that attrib file exists or has some
problem.  What happens when you look in that directory on a full (filled)
backup?  There should be a single file there with the name attrib_DIGEST,
where DIGEST is the 32 hex digits of the md5 digest.  What happens when you
run these commands:

BackupPC_zcat DIGEST | wc
BackupPC_attribPrint path_to_attrib_file


Craig

On Sun, Jan 10, 2021 at 2:38 PM Craig Barratt <
cbarr...@users.sourceforge.net> wrote:

> Peter,
>
> Ok, those are all the latest versions.  The next step is to increase the
> debug level (eg, XferLogLevel to 7 and "-vv" to rsync-bpc args) and send me
> a healthy portion of the log (eg, a couple of thousand lines up until the
> error, and a few hundred lines after the error).
>
> Craig
>
>
>
> On Sat, Jan 9, 2021 at 11:10 PM Pete Geenhuizen 
> wrote:
>
>> Craig,
>> Thanks for the response, these are the versions that I'm running
>> BackupPC4-4.4.0-2.el7.fws.x86_64
>> BackupPC-XS-0.62-2.el7.fws.x86_64
>> rsync-bpc-3.1.3.0-2.el7.fws.x86_64
>>
>> Pete
>>
>>
>> On 1/8/21 9:08 PM, Craig Barratt wrote:
>>
>> This should be fixed in the latest version of rsync-bpc.  What versions
>> are you using (BackupPC, rsync-bpc and backuppc-xs)?
>>
>> Craig
>>
>> On Sat, Jan 9, 2021 at 8:08 AM Pete Geenhuizen 
>> wrote:
>>
>>> After a recent kernel update for Centos 7 I started seeing the following
>>> error on 2 hosts.  I didn't give it much thought figuring that it
>>> probably would disappear when the next level 0 backup was done, but nope
>>> the error persists.
>>> file has vanished: "/etc/alternatives/froot/fetc/falternatives/attrib"
>>> I have no idea how to resolve this error other than simply deleting the
>>> entire pool which seems like a pretty drastic way to solve the problem.
>>> So other than that is there a better way to handle this problem?
>>> Thanks
>>> Pete
>>>
>>> --
>>> Unencumbered by the thought process.
>>>   -- Click and Clack the Tappet brothers
>>>
>>>
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>>
>>>
>>>
>>> ___
>>> BackupPC-users mailing list
>>> BackupPC-users@lists.sourceforge.net
>>> List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
>>> Wiki:https://github.com/backuppc/backuppc/wiki
>>> Project: https://backuppc.github.io/backuppc/
>>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by *MailScanner* , and
>> is
>> believed to be clean.
>>
>>
>> --
>> Unencumbered by the thought process.
>>  -- Click and Clack the Tappet brothers
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by *MailScanner* , and
>> is
>> believed to be clean.
>>
>
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/


Re: [BackupPC-users] Vanished file

2021-01-09 Thread Craig Barratt via BackupPC-users
Peter,

Ok, those are all the latest versions.  The next step is to increase the
debug level (eg, XferLogLevel to 7 and "-vv" to rsync-bpc args) and send me
a healthy portion of the log (eg, a couple of thousand lines up until the
error, and a few hundred lines after the error).

Craig



On Sat, Jan 9, 2021 at 11:10 PM Pete Geenhuizen 
wrote:

> Craig,
> Thanks for the response, these are the versions that I'm running
> BackupPC4-4.4.0-2.el7.fws.x86_64
> BackupPC-XS-0.62-2.el7.fws.x86_64
> rsync-bpc-3.1.3.0-2.el7.fws.x86_64
>
> Pete
>
>
> On 1/8/21 9:08 PM, Craig Barratt wrote:
>
> This should be fixed in the latest version of rsync-bpc.  What versions
> are you using (BackupPC, rsync-bpc and backuppc-xs)?
>
> Craig
>
> On Sat, Jan 9, 2021 at 8:08 AM Pete Geenhuizen 
> wrote:
>
>> After a recent kernel update for Centos 7 I started seeing the following
>> error on 2 hosts.  I didn't give it much thought figuring that it
>> probably would disappear when the next level 0 backup was done, but nope
>> the error persists.
>> file has vanished: "/etc/alternatives/froot/fetc/falternatives/attrib"
>> I have no idea how to resolve this error other than simply deleting the
>> entire pool which seems like a pretty drastic way to solve the problem.
>> So other than that is there a better way to handle this problem?
>> Thanks
>> Pete
>>
>> --
>> Unencumbered by the thought process.
>>   -- Click and Clack the Tappet brothers
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>>
>>
>> ___
>> BackupPC-users mailing list
>> BackupPC-users@lists.sourceforge.net
>> List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
>> Wiki:https://github.com/backuppc/backuppc/wiki
>> Project: https://backuppc.github.io/backuppc/
>>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* , and is
> believed to be clean.
>
>
> --
> Unencumbered by the thought process.
>  -- Click and Clack the Tappet brothers
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* , and is
> believed to be clean.
>
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/


Re: [BackupPC-users] Return to BackupPC

2021-01-09 Thread backuppc
Raoul Bhatia wrote at about 20:37:59 +0100 on Saturday, January 9, 2021:
 > On 2021-01-07 12:39, Sorin Srbu wrote:
 > > On Tue, 2021-01-05 at 10:05 -0500, backu...@kosowsky.org wrote:
 > >>  > I don't want top build my own for now, at least not until I get up 
 > >> to speed
 > >>  > again with BPC.
 > >>  > 
 > >> https://kifarunix.com/install-and-setup-backuppc-server-on-ubuntu-20-04/
 > >>  >
 > >>  > Are there any well-known, if untrusted, PPA's known here on the 
 > >> list, in use
 > >>  > for BPC v4?
 > >>  >
 > >>  > Hints appreciated and as usual thanks in advance!
 > >>  > Feels kinda' good to be back with BPC. :-)
 > > 
 > > Slow day at work, so opted to run through the above guide.
 > > After a few glitches I now have BPC 4.4.0 running.
 > > 
 > > One thing stands out though.
 > > The pretty pool graphs from BPC 3.3 are missing in BPC 4.4.0.
 > > Is this expected or will they show up when a few backups have been 
 > > done?
 > 
 > One thing that always puzzles me:
 > Why do people like to install from source instead from packages?
 > As a long-time sysadmin, I normally make damn sure that my systems are 
 > not dirty.
 > Therefore, manually installing software via the basic "configure; make; 
 > make install" would be the very last resort.  From my experience, there 
 > is always more risk that some artifacts are left behind when upgrading 
 > such installations, that will cause unexpected issues.
 > 
 > I understand that packages can also be done badly, but if I do not trust 
 > pre-packaged software, there are normally easy ways to package myself.
 > 
 > Anybody care to share their perspective?
 > 

I agree!
I am OCD about keeping even my personal systems clean... and I hate
the idea that random files could be installed anywhere without any
easy way to track, update or remove them as necessary...

If for some reason there is no package and I just want to "play" with
some software, I make sure to install it only locally (and usually
manually) without root privileges so I can be sure that nothing gets
stuck somewhere that I don't know about and that I can't later remove.


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


Re: [BackupPC-users] Return to BackupPC

2021-01-09 Thread Les Mikesell
On Sat, Jan 9, 2021 at 3:19 PM Richard Shaw  wrote:

> I don't think it's practical for upstream to manage all of this across all 
> distros. Some will be similar, others may be very different.

Perhaps - but anything that is not practical for an expert to maintain
is certainly going to be too complicated for most casual users to
tackle on their own.

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


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


Re: [BackupPC-users] Return to BackupPC

2021-01-09 Thread Richard Shaw
On Sat, Jan 9, 2021 at 2:01 PM Les Mikesell  wrote:

> On Sat, Jan 9, 2021 at 1:39 PM Raoul Bhatia  wrote:
> >
> >> I understand that packages can also be done badly, but if I do not trust
> > pre-packaged software, there are normally easy ways to package myself.
> >
> > Anybody care to share their perspective?
>
> "Well maintained" packages are always great, but they can leave you
> stranded if you need some quick fix and there is some problem with the
> maintainer or getting the repository updated.  In my opinion, the
> 'best of all worlds' is where the source package includes the
> packaging script so you don't really need to know anything to build
> your own package if that is ever necessary.
>

I think it really depends on what you're packaging. Some packages are quite
simple and upstream could account for most of the packaging guidelines, but
keep in mind, even among distros that use the same packaging (RPM or DEB,
etc) that the packaging guidelines can vary significantly.

Also, in the specific case of BackupPC there are a lot of things that need
to be taken care of. If you take a look at the source files[1] used to
package BPC on Fedora/EPEL you'll see things like:

1. The Spec file of course, and it takes care of a bunch of things
including setting proper SELinux contexts.
2. Apache htaccess file so apache is ready "out of the box"
3. Logrotate config
4. tmpfile config
5. C wrapper so BackupPC_Admin which is perl based can run setuid/setgid.
6. SystemD service file

I don't think it's practical for upstream to manage all of this across all
distros. Some will be similar, others may be very different.

Thanks,
Richard

[1] https://src.fedoraproject.org/rpms/BackupPC/tree/master
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/


Re: [BackupPC-users] Return to BackupPC

2021-01-09 Thread Raoul Bhatia

Hi Les,

On 2021-01-09 21:00, Les Mikesell wrote:

On Sat, Jan 9, 2021 at 1:39 PM Raoul Bhatia  wrote:


I understand that packages can also be done badly, but if I do not 
trust

pre-packaged software, there are normally easy ways to package myself.

Anybody care to share their perspective?


"Well maintained" packages are always great, but they can leave you
stranded if you need some quick fix and there is some problem with the
maintainer or getting the repository updated.  In my opinion, the
'best of all worlds' is where the source package includes the
packaging script so you don't really need to know anything to build
your own package if that is ever necessary.


I personally agree to the approach of adding packaging scripts/metadata 
to upstream.


However, at least the Debian project seems to have a strong opinion on 
how this should be done,

see https://wiki.debian.org/UpstreamGuide#Pristine_Upstream_Source :

Some projects include a rough /debian directory among source files 
to

[...]
While this is a good effort, it is better to leave it out of the 
final

tarball as it can interfere with debian's own packaging effort.
[...]
Keeping it only in your VCS repository is usually a much saner 
default

if it lives in a specific packaging branch, which mimics what Debian
package maintainers do using git-buildpackage.
[...]

I suppose other distros have their own opinions as well.
As an upstream author, I would not know how to handle all these distro 
specifics...


Raoul
--
DI (FH) Raoul Bhatia MSc
E-Mail. ra...@bhatia.at
Tel. +43 699 10132530


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


[BackupPC-users] libbackuppc-xs-perl 0.62-1 for Debian/Ubuntu (was: Re: Return to BackupPC)

2021-01-09 Thread Raoul Bhatia

On 2021-01-09 20:57, Raoul Bhatia wrote:
[...]

1. You say on your webpage "libbackuppc-xs-perl Package ATTN Currently
   broken!"
   In what way is it broken?
   I haven't noticed any problems in building (or using) my own
   updated version of this based on your original 'debian'


Mhm, good question. I do not recall the specifics anymore.
For one thing,
https://github.com/raoulbhatia/libbackuppc-xs-perl/blob/master/debian/changelog
still wants to build version 0.59.
I will try to update tonight and report back.

[...]

Update: I reviewed my repository,
updated to the latest Debian upstream from 
https://salsa.debian.org/debian/libbackuppc-xs-perl

and reduced debhelper-compat to allow a "backport" build.
(Perhaps not in the best way, but it should work)

Cheers,
Raoul
--
DI (FH) Raoul Bhatia MSc
E-Mail. ra...@bhatia.at
Tel. +43 699 10132530


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


Re: [BackupPC-users] Return to BackupPC

2021-01-09 Thread Les Mikesell
On Sat, Jan 9, 2021 at 1:39 PM Raoul Bhatia  wrote:
>
>> I understand that packages can also be done badly, but if I do not trust
> pre-packaged software, there are normally easy ways to package myself.
>
> Anybody care to share their perspective?

"Well maintained" packages are always great, but they can leave you
stranded if you need some quick fix and there is some problem with the
maintainer or getting the repository updated.  In my opinion, the
'best of all worlds' is where the source package includes the
packaging script so you don't really need to know anything to build
your own package if that is ever necessary.

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


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


Re: [BackupPC-users] Return to BackupPC

2021-01-09 Thread Raoul Bhatia

Hi Jeff,

On 2021-01-06 15:57, backu...@kosowsky.org wrote:

Thanks Raoul - very helpful information -- and without your webpage,
I would never have been able to get started myself...

Couple of questions:
1. You say on your webpage "libbackuppc-xs-perl Package ATTN Currently
   broken!"
   In what way is it broken?
   I haven't noticed any problems in building (or using) my own
   updated version of this based on your original 'debian'


Mhm, good question. I do not recall the specifics anymore.
For one thing, 
https://github.com/raoulbhatia/libbackuppc-xs-perl/blob/master/debian/changelog 
still wants to build version 0.59.

I will try to update tonight and report back.


2. Is there a reason that you use rsync-3.0.9 vs 3.1.3 supported by
   Craig upstream?  I know that previously I had trouble compiling
   >=3.1.12 using your 'debian' but I didn't really explore that
   further
I consider rsync-bpc to be part of the very core functionality of my 
backups.
I always wanted to wait for 3.1.x to be more widely used, tested, 
bug-free.

Then, I never got the time to update ;-)


3. Other than pulling in new upstream source and updating the version
   numbering, have you made any notable changes to the 'debian'
   directories on any of these packages over the past say 18 months.

I did minor tweaks here and there, and included some pull requests.
Best to review 
https://github.com/raoulbhatia/backuppc/commits/DEBIAN/debian for the 
details.



4. When do you expect to switch over to the emerging 'official' debian
   4.x packages which just migrated over to 'testing' from 'unstable'?
   It would be good for all of us to consolide around a stable
   (semi)official package for Ubuntu (note I am still using 18.04).
Once I get more time to cross-check the differences between my and the 
official builds. ;-)

i.e. I want to be sure that there are no "regressions".


Thanks Raoul for all your contributions!
Thanks to you as well - you are much more active in the community than I 
am.


Raoul
--
DI (FH) Raoul Bhatia MSc
E-Mail. ra...@bhatia.at
Tel. +43 699 10132530


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


Re: [BackupPC-users] Return to BackupPC

2021-01-09 Thread Raoul Bhatia

On 2021-01-07 12:39, Sorin Srbu wrote:

On Tue, 2021-01-05 at 10:05 -0500, backu...@kosowsky.org wrote:
 > I don't want top build my own for now, at least not until I get up 
to speed

 > again with BPC.
 > 
https://kifarunix.com/install-and-setup-backuppc-server-on-ubuntu-20-04/

 >
 > Are there any well-known, if untrusted, PPA's known here on the 
list, in use

 > for BPC v4?
 >
 > Hints appreciated and as usual thanks in advance!
 > Feels kinda' good to be back with BPC. :-)


Slow day at work, so opted to run through the above guide.
After a few glitches I now have BPC 4.4.0 running.

One thing stands out though.
The pretty pool graphs from BPC 3.3 are missing in BPC 4.4.0.
Is this expected or will they show up when a few backups have been 
done?


One thing that always puzzles me:
Why do people like to install from source instead from packages?
As a long-time sysadmin, I normally make damn sure that my systems are 
not dirty.
Therefore, manually installing software via the basic "configure; make; 
make install" would be the very last resort.  From my experience, there 
is always more risk that some artifacts are left behind when upgrading 
such installations, that will cause unexpected issues.


I understand that packages can also be done badly, but if I do not trust 
pre-packaged software, there are normally easy ways to package myself.


Anybody care to share their perspective?

Thanks,
Raoul
--
DI (FH) Raoul Bhatia MSc
E-Mail. ra...@bhatia.at
Tel. +43 699 10132530


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


Re: [BackupPC-users] Imnproving backup speed

2021-01-09 Thread Alexander Kobel

Hi all,

On 1/7/21 8:56 PM, Michael Stowe wrote:

On 2021-01-07 00:39, Sorin Srbu wrote:

Hello all!

Trying to improve the backup speed with BPC and looked into setting 
noatime in fstab. [...]


What will BPC in particular do if noatime is set?


In short, it depends on your transport methods.  Rsync will be fine. 
Tar/smb?  Not so much for incrementals, but fulls (of course) will be fine.


On the *client* side that's a more interesting question. As mentioned 
before in this thread and as documented in the BackupPC docs, the 
*server* side is okay with noatime as far as the BackupPC pool is concerned.


For clients, I have no idea about smb, but a vague one about tar. 
Disclaimer: I don't use tar myself.


The GNU tar manpage is fairly explicit about atime issues, but the 
subject is distributed in different sections:
In 
https://www.gnu.org/software/tar/manual/html_section/tar_22.html#SEC42, 
it recommends --atime-preserve=system for incremental backups, if 
supported by the OS. This gently asks the system for not modifying 
atimes; essentially a noatime request for an individual read.
In https://www.gnu.org/software/tar/manual/html_section/tar_69.html 
however, the --atime-preserve=replace (which happens to be the default 
variant for --atime-preserve) is documented to *not* play nicely with 
incremental backups. This one resets the file stats after reading, but 
the reset itself counts as metadata change, and accordingly the file 
will be re-read on the next run. I'm not 100% sure where the timestamp 
of the change is recorded, though. Also, in my tests, I could not 
confirm that --atime-preserve=replace causes issues with incrementals; 
but that's based on rather ad-hoc manual tests, not via BackupPC.


In any case, tar recommends an entirely different approach for 
incremental dumps 
(https://www.gnu.org/software/tar/manual/html_section/tar_39.html#SEC96), but 
this is not feasible with BackupPC.


Also, note that --newer does not consider atime, but only ctime and 
mtime 
(https://www.gnu.org/software/tar/manual/html_section/tar_52.html#SEC116).


BackupPC by default uses --newer (aka --after-date) on incremental dumps 
(see $Conf{TarIncrArgs} around 
https://github.com/backuppc/backuppc/blob/master/conf/config.pl#L1136), 
and accordingly has a warning in the config about not using 
--atime-preserve[=replace]. However, it is questionable whether the same 
warning also applies for --atime-preserve=system (assuming it's 
supported on the client).


So from what I understand, the combination of --newer and 
--atime-preserve=system (or noatime mounts) should be almost optimal.
And --newer-mtime + noatime should work, too, but with the usual 
downside of --newer-mtime that metadata updates are not caught (e.g., 
permission changes).


Of course, that's assuming that there no other issues with using noatime 
unrelated to the backups.



P.S.: https://backuppc.github.io/backuppc/BackupPC.html#Backup-basics is 
not 100% accurate, claiming that incremental backups with tar rely on 
mtime only; actually, the use of --newer implies that mtime *and* ctime 
are relevant.



Cheers,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/


Re: [BackupPC-users] Imnproving backup speed

2021-01-09 Thread Sorin Srbu
On Thu, 2021-01-07 at 20:30 +0100, Alexander Kobel wrote:
> Hi Sorin,
> 
> On 1/7/21 9:39 AM, Sorin Srbu wrote:
> > Hello all!
> > 
> > Trying to improve the backup speed with BPC and looked into setting noatime
> > in fstab.
> > 
> > But this article states some backup programs may bork if noatime is set.
> > https://lonesysadmin.net/2013/12/08/gain-30-linux-disk-performance-noatime-nodiratime-relatime/
> > 
> > What will BPC in particular do if noatime is set?
> 
> exactly what it's supposed to do. noatime or at least relatime (or 
> perhaps recently lazytime) is the recommended setting:
> https://backuppc.github.io/backuppc/BackupPC.html#Optimizations


A _general_, although related, question:
Would tuned do me some good?

I see that tuned-adm recommends using the profile virtual-guest, but would
maybe performance-throughput be any better?

Do any of you using BackupPC tweak your BPC-servers anything at all with
tuned?


-- 

Kind regards,
Sorin Srbu

Find my OpenPGP public key here:
https://cloud.srbu.se/index.php/s/KeEsCCDsG7PZG7N





signature.asc
Description: This is a digitally signed message part
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/


Re: [BackupPC-users] Return to BackupPC

2021-01-09 Thread Sorin Srbu
On Fri, 2021-01-08 at 10:10 +0300, Alexander Moisseev via BackupPC-users
wrote:
> 07.01.2021 14:39, Sorin Srbu пишет:
> > The pretty pool graphs from BPC 3.3 are missing in BPC 4.4.0.
> > Is this expected or will they show up when a few backups have been done?
> > 
> It is handled by BackupPC_nightly, just wait for a couple of days.

Wonderful, thanks. They are indeed back now!

-- 

Kind regards,
Sorin Srbu

Find my OpenPGP public key here:
https://cloud.srbu.se/index.php/s/KeEsCCDsG7PZG7N


signature.asc
Description: This is a digitally signed message part
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/


Re: [BackupPC-users] Imnproving backup speed

2021-01-09 Thread Sorin Srbu
On Fri, 2021-01-08 at 12:07 +1100, Adam Goryachev via BackupPC-users wrote:
> On 8/1/21 06:30, Alexander Kobel wrote:
> > On 1/7/21 9:39 AM, Sorin Srbu wrote:
> > > What will BPC in particular do if noatime is set?
> > 
> > exactly what it's supposed to do. noatime or at least relatime (or 
> > perhaps recently lazytime) is the recommended setting:
> > https://backuppc.github.io/backuppc/BackupPC.html#Optimizations 
> 
> I think it depends on whether you are applying this setting change on 
> the BPC server, and specifically the BPC pool drive, or if you are 
> applying it to the clients and/or root FS of the BPC server.
> 
> If you have a separate filesystem for the BPC pool, then using this 
> setting on that filesystem will not have any adverse impact, but will 
> likely reduce overhead. Changing this setting elsewhere will have the 
> documented impacts (and you would need to assess the results of those 
> impacts based on your own personal requirements (or provide a lot more 
> information for anyone else to comment on).

The BPC server uses a separate drive for the backup pool, so is pretty much
a schoolbook example.
I went ahead and set relatime for the pool-drive.

Thanks all for the hints!


-- 

Kind regards,
Sorin Srbu

Find my OpenPGP public key here:
https://cloud.srbu.se/index.php/s/KeEsCCDsG7PZG7N



signature.asc
Description: This is a digitally signed message part
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/


Re: [BackupPC-users] Vanished file

2021-01-09 Thread Pete Geenhuizen

Craig,
Thanks for the response, these are the versions that I'm running
BackupPC4-4.4.0-2.el7.fws.x86_64
BackupPC-XS-0.62-2.el7.fws.x86_64
rsync-bpc-3.1.3.0-2.el7.fws.x86_64

Pete


On 1/8/21 9:08 PM, Craig Barratt wrote:
This should be fixed in the latest version of rsync-bpc.  What 
versions are you using (BackupPC, rsync-bpc and backuppc-xs)?


Craig

On Sat, Jan 9, 2021 at 8:08 AM Pete Geenhuizen > wrote:


After a recent kernel update for Centos 7 I started seeing the
following
error on 2 hosts.  I didn't give it much thought figuring that it
probably would disappear when the next level 0 backup was done,
but nope
the error persists.
file has vanished: "/etc/alternatives/froot/fetc/falternatives/attrib"
I have no idea how to resolve this error other than simply
deleting the
entire pool which seems like a pretty drastic way to solve the
problem.
So other than that is there a better way to handle this problem?
Thanks
Pete

-- 
Unencumbered by the thought process.

  -- Click and Clack the Tappet brothers


-- 
This message has been scanned for viruses and

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



___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net

List: https://lists.sourceforge.net/lists/listinfo/backuppc-users

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

Project: https://backuppc.github.io/backuppc/



--
This message has been scanned for viruses and
dangerous content by *MailScanner* , and is
believed to be clean. 


--
Unencumbered by the thought process.
 -- Click and Clack the Tappet brothers


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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