On 9/30/26 7:35 AM, G.W. Haywood wrote:
Hi there,
On Mon, 28 Sep 2026, Emmett Culley wrote:
I've reported this before ...
Maybe it would have been better to have continued that thread.
Like I mentioned in my original message, I did pursue it, finding noting, then
gave up as I was able to restore from tar.gz and had run out of time to work on
it longer.
... seems to be a UI issue. This is what I found:
If I select only files in any number of directories down from that
share's root the restore works as expected. The selected files are
restored to the host's share in the correct directory. Including
any directories missing on the target needed to restore those files.
If I select any directory to restore only the directory is restored.
It is created by the restore if it didn't exist. None of the files
or sub directories in the selected directory are restored.
First off I'd always be very wary of restoring files directly because
there's very little room for error if you do it that way. In fact my
rsync modules are all read-only; to experiment with doing restores the
way you're doing them I had to tweak some configs (now untweaked:).
You work the way you work and I work the way I work. I Find it convenient to
be able to restore files or a directory of files from a day or three before,
when I mistakenly delete some files. This happens often enough that getting a
tar.gz file and extracting its contents take longer than I want to get it done.
I still do that when I need to restore one or more files directly.
...
When I select a directory and click on "Restore selected files" the
"Restore Options for <host>" page lists all the files selected
directly and only the path to any directory that was selected. No
files under that directory are listed.
I think that's normal operation - it might be a *very* long list.
Yes, I am pretty sure it never did list all files in directories. I only mentioned that as a data point.>
Then clicking on "Start Restore", then from the "Are you sure page",
click on "Restore", only the selected files and the selected
directory are restored. No files or directories in the selected
directory are restored.
That's not what happens here, nor is it what another contributor said
back in April of his experience:
https://sourceforge.net/p/backuppc/mailman/message/59318583/
I'm (still) not sure that this is actual 'intended' behaviour but it
does look like you're outvoted. I'd *almost* suggest that it's some
safety feature that's been included by Red Hat in their patches, but
for the fact that the contributor mentioned above was using Rocky 9.7.
I will definitely look into it further. Especially as you seem to be saying
that I cannot expect to be able to restore a directory.
I'll see if I can get some deeper logs.
I'll be studying the docs on that.
The log tells me the number of files restored is the same as the
number of files I selected directly, and that there were zero
directories restored, even though if the target did not have the
selected directory before the restore, it does after the restore,
and is empty.
Could it be the version of rsync that's causing your problem? I know
there were some regressions around the rsync 3.4 era that were fixed
variously in later rsync 3.4s and rsync 3.5. Seems unlikely, but I'm
not sure what else that's simple might explain it. There might be a
clue in a log somewhere, or you might be able to increase the logging
verbosity to get it to offer more clues.
The BackupPC host is running rsync 3.5 and most of the remote hosts are running
rsync 3.2.5.
So it looks to me like the UI is not "getting" the files and
possibly any sub directories and their contents, of any selected
directory.
Given others' experience it looks to me more like you somehow broke
something. Maybe not your fault of course - a simple upgrade often
causes lots of heartache.
It all worked at one time, and I am not sure when it changed.
Maybe you could narrow it down somehow? Compare it with rsync changes?
I could have been when I upgraded from version 3 to 4. That seems
like a long time ago, however.
Agreed that's probably too long ago to be the explanation.
Did I mention that I think BackupPC is a great software package that
makes mine and others lives and work a whole lot easier.
Quite a lot of people say that. It's good to know. :)
Please let me know if there is anything I can do, or any additional
information I can provide, to help get this resolved.
At this stage I think in your place if extra logging doesn't help I'd
install a copy of BackupPC on some other machine using the upstream
sources for everything, set up a minimal backup on a single machine
and see how it behaves. Assuming it then works - I can't see how it
wouldn't, but anything's possible - then back the parts out to your
current versions of things until you break something. Tedious, yes,
but it will almost certainly lead to the answer to your problem.
Probably my next steps.
Thanks for the response.
Emmett
_______________________________________________
BackupPC-users mailing list
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/
