Re: Unable to restore directory or multiple files

Hello again,

On Tue, 7 Apr 2026, Emmett Culley wrote:
> On 4/6/26 7:26 AM, G.W. Haywood wrote:
> > On Mon, 6 Apr 2026, Emmett Culley wrote:
> > 
> > ...
> >> ... can only restore one file into an existing directory... both
> >> rsyncd and rsync methods and neither one can restore multiple files.
> 
> >>
> >> ... google ... nothing ...
> >>
> >> Any suggestion would be appreciated.
> > 
> > The place to start is probably the BackupPC documentation:
> > 
> > https://backuppc.github.io/backuppc/BackupPC.html
> > 
> > especially this part:
> > 
> > 8<----------------------------------------------------------------------
> > 
> >  ? * Flexible restore options. Single files can be downloaded from any
> >  ??? backup directly from the CGI interface. Zip or Tar archives for
> >  ??? selected files or directories from any backup can also be downloaded
> >  ??? from the CGI interface. Finally, direct restore to the client
> >  ??? machine (using smb or tar) for selected files or directories is also
> >  ??? supported from the CGI interface.
> > 
> > 8<----------------------------------------------------------------------
> > 
> > It looks to me like things are behaving as documented. ...
> 
> ...
> This used to work flawlessly.  Select a directory to restore, click
> on the restore buttons, files are restored on the host as expected.

Seems like the goal posts just moved - quite a distance.

Your original question was "Why doesn't this work?"

Your question now seems to have changed to "Why did something which
used to work suddenly stop working?"  I'm far from convinced that it
did, but let's look into it.

When I first responded I tried *really* hard not to do the ESR thing
and sound condescending or combative.  I went against my instincts,
which were to ask you exactly what software you're using and how you
configured it.  I wanted to ask you for operating system details and
software version numbers, full copies of your configuration files and
relevant extracts from your logs.  All that does tend to sound, well,
not very welcoming but I'm asking now because there's no better way.

> What changed?

If something changed, it was you who changed it.  You might need some
help in figuring out how the change came about, and that's what we're
all here for.  First you need to tell us exactly what you've done, as
until we have full information we can only guess.  Right now my best
guesses if something really did change are that either you've upgraded
some software or you changed some configuration.  We need you to tell
us what you did.

> Why would the support restore via SMB but not rsync.  Makes no sense
> to me.

When a network share is mounted over SMB on a BackupPC host, the files
can be copied from the remote share to the local (BackupPC) host using
utilities like cp and (plain) tar.  Files can be copied from the local
host to a remote share by the same means.  But without help, utilities
like cp and tar can't copy remote files directly; they don't know how.
That's why 'rcp' amd 'rsh' came about, and later 'rsync'.  The waters
unfortunately are already getting a bit muddy, because 'tar' knows how
to cheat a little and it can use rsh to read/write remote tar archives
but not to read/write remote directories - that's where rsync comes
into its own.

If you use rsync over ssh, the commands you give effectively create a
transparent network connection between the remote host and the local
host *purely for that one connection* so that effectively you're doing
a *local* copy.  The ssh connection just hides the fact that the data,
instead of coming from a local file store is coming from a remote one.

SMB does such remote access stuff for an entire remote directory, and
once mounted it keeps it available for as long as you like so you can
use ordinary operating system tools like 'cp' and 'cat' on the files
in that directory.  That's a complete new level of (persistent) remote
access, not like the z-over-ssh thing (where z can be almost anything.
for example you can run 'cat' over ssh, or run an 'X' server over ssh,
although there it just got a lot more complicated).  NFS has a lot of
the characteristics of SMB.  These aren't always characteristics that
you'd want, but that's another story.  Suffice it to say that you can
copy to/from NFS mounts in much the same way that you can with SMB (if
as always of course you have things like permissions set up properly).

But if you copy using what I'll call 'plain' rsync - that is, rsync
which is *not*running over ssh - then you're not doing the same thing
at all.  You're asking a bit of code which is network aware to do the
data transfer to and from the remote host for you.  The rsync utility
connects to a remote server and asks for permission for a connection.
Simple operating system utilities aren't involved, they don't know how
to do it.  You can tell rsync to go fetch a whole bunch of files from
a remote host, or write them and the entire directory hierarchy to the
remote host.  *Two* rsync programs run.  One of them is on the remote,
and of course is controlled by the remote's administrator.  These two
programs work together, transferring data from one to the other, to do
the copying that needs to be done.  When you use 'cp' for example only
one program is running.  It only knows how to talk to the local OS.

I glossed over a couple of things, but does that make more sense?

In your posts of last July (Github issue #545) you mentioned that
depending on the host being backed up you may use rsync over ssh or
you may use rsyncd.  Does that have a bearing on this?

-- 

73,
Ged.





_______________________________________________
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/