The problem has resolved itself.
It looks like the root cause was that the portion of BPC which generates the
graphs (and also supplies the "Pool is XXXGiB comprising YYY files and ZZZ
directories" text in the General Server Information) does not update its
information regarding the physical fi
This is primarily a cosmetic issue rather than a functional one, but I'd like
to resolve it anyhow.
My BPC server has the backup pool stored on a zfs (raidz2) filesystem. After a
couple years of usage, the pool fs was over 90% full, so I copied the backups
elsewhere, destroyed the original rai
By default, rsync will only copy new files to the destination and update
existing ones, but it does not delete files which are not present in the source
unless it receives the --delete parameter. Sounds like you're probably missing
that.
From: Kirby
Sent: Monda
When I was debugging an issue some time ago, I added a setting to RsyngArgs
which caused all files to be listed in the XferLOGs. I believe the relevant
setting was:
--log-format=log: %o %i %B %8U,%8G %9l %f%L
but I can't find documentation to confirm that. In any case, I now get entries
in X
Beyond the safety precaution you mentioned, rsync doesn't delete files
at all unless your RsyncArgs include "--delete". There have been a few
previous people mailing the list who didn't have --delete in there, so I
wonder whether that might be the problem here.
On 11/15/23 12:42, Guillermo Ro
By default, the RsyncArgs for BPC4 includes --one-file-system, which
tells it not to descend into mounted filesystems. To include other
filesystems in your backups, you can either add a second "share" to the
machine for /var/files so that it's explicitly backed up, or you can
remove --one-file
111 = 37 * 3
Presumably it made three attempts to back up each host, but all three
attempts (per host, 111 attempts total) were skipped due to insufficient
space to store the backups. And, for simplicity, the code just counted
the attempts without attempting to deduplicate multiple attempts f
On 6/29/23 15:11, Guillermo Rozas wrote:
*I* don't do it, simply because there's little practical difference
between rsync'ing directories that don't change and not rsync'ing
them.
Just to give reason *I* use it:
- the cost/benefit of doing full backups for different folders is
di
Ah, thanks - adding --super appears to have resolved the problem. Ran
another full of the test system, and backuppcfs now shows correct file
ownerships.
I'm still missing --protect-args, --delete-excluded, and --partial from
the defaults, so I'll probably also add those after checking the man
: recv >f.s... rw-r--r-- 6, DEFAULT 1081344
var/cache/man/index.db
when using "--log-format=log: %o %i %B %8U,%8G %9l %f%L" as suggested by
Kris Lou.
On 11/18/22 14:17, backu...@kosowsky.org wrote:
The former which might help with the latter...
Dave Sherohman via B
?
On 11/16/22 20:56, backu...@kosowsky.org wrote:
'backuppcfs' is a (read-only) FUSE fileystem that allows you to see
the contents/ownership/perms/dates/Xattrs etc. of any file in your
backup.
It is great for troubleshooting as well as for partial restores...
Dave Sherohman via Back
Thanks, that did get me additional information. With those settings, my
XferLOG now shows, for example:
log: recv >f.s... rw-r--r-- 6, DEFAULT 1081344
var/cache/man/index.db
However, when I get a tar archive of /var/cache/man, `tar tvf` shows:
-rw-r--r-- root/root 1081344 202
I've just encountered the same problem from issue #171 on github, "on
restore all files owner root"
https://github.com/backuppc/backuppc/issues/171
My RsyncRestoreArgs are the same as reported there, with the exception
that I don't have --ignore-times. I have done the tar restore check
there
While there may be a better way, my first thought would be to check the
backup summary page for each host and look at backup durations (longer
time should correlate with more data transferred) and/or the "new files"
columns in the "File Size/Count Reuse Summary" section.
On 9/22/22 11:03, mart
On 8/4/22 07:44, backu...@kosowsky.org wrote:
On Wed, Aug 3, 2022 at 2:31 PM backuppc--- via BackupPC-users <
backuppc-users@lists.sourceforge.net> wrote:
I pulled a V3 pool off an old hard disk that I had wrongly assumed was
broken. Now I would like to import as much data as possible into my c
Since you mentioned different versions of rsync, I assume you already
checked this, but, just in case: Double-check that rsync is still
installed on the deb11 system. I upgraded a ton of systems from deb9 to
deb11 earlier in the summer, and apt decided to uninstall rsync during
the upgrades o
On 4/11/22 18:22, G.W. Haywood via BackupPC-users wrote:
Looking at
https://metacpan.org/dist/File-RsyncP/changes
it seems that there is only one later version (0.76) so your options
seem to be somewhat limited. :)
Is it even still being used? My BPC server is running 4.4.0, installed
from
The first thing I'd try is adding it as \@Recycle. Much (all?) of the
BPC code is written in Perl, which will (in some contexts) interpret
"@Recycle" to mean "an array named Recycle" rather than the literal text
"@Recycle". Adding the backslash prevents the @ from being interpreted
as an arra
This is basically what I've done, with the addition (which may have been
an unstated assumption) that the backuppclogin user on each client
machine has a disabled password, so that it can only be accessed via ssh
public key login, or by "sudo su [user]" on the local machine.
This is, IMO, "sec
On 3/5/22 14:36, G.W. Haywood via BackupPC-users wrote:
On Sat, 5 Mar 2022, Les Mikesell wrote:
Unix/Linux has something calle 'sparse' files used by some types of
databases where you can seek far into a file and write without
using/allocating any space up to that point. The file as stored may
In the directory where config.pl lives, there should be a pc/
subdirectory. The per-host config files go in that subdirectory. (Note
that, on debian, pc/ is a symlink back to the same directory, so the
global config.pl and the per-host configs are all in the same place.)
The per-host config
What file transfer method are you using with the Windows hosts? I've
seen a couple mentions on the mailing list that BPC4 added
--one-file-system to the default set of flags for rsync file transfers,
which would prevent rsync from crossing over onto a remotely-mounted
filesystem, such as an SMB
What seems suspicious to you about it? It's not currently in the
process of backing up files or doing anything with the host right this
minute; it is idle.
On 11/2/21 7:47 AM, Norman Goldstein wrote:
My question is in the last line of this email.
I was having errors backing up, so I decided
23 matches
Mail list logo
