Dear Maintainer,

if there are sshfs mounts with default options mounted
in the directory to be backed up, Dirvish leaves the
backup incomplete. The new backup directory does not
even have read access for users.

It should not be possible to invalidate the (daily) backup
process of /home by any actions that users might do.

Now the sshfs mounts should be done with "-o allow_root"
to have successful backups also. But it's not realistic to
expect all normal users to respect this rule.

(Or is there an option in Dirvish to overcome this?)

That is because the backup is considered to be failed, and dirvish does
not want to allow users to access such incomplete backups unknowingly.
This is a design decision.

Then you should exclude such mounts from the backup, e.g. by adding
    xdev: 1
to the dirvish.conf for that tree.

The filesystems mounted by sshfs should be backed up at the host where
they originate.


Paul

the moint point, but fails, and the whole backup is considered failed.
I wonder if Dirvish could see that it was just a mounted filesystem
that failed, and ignore the issue, especially when "xdev: 1" has
been specified.

I now checked my failed backup and the only problem in practice seems
to be that there's no access for users to the backup directory. All
the files, except the mount point, still seem to be there, which is
most important.

With sshfs mounts the root problem is with FUSE:
https://www.agwa.name/blog/post/how_fuse_can_break_rsync_backups
http://fuse.996288.n3.nabble.com/force-allow-root-td11417.html

My solution now is to a system-wide alias for Bash:
alias sshfs='sshfs -o allow_root'
So at least sshfs mounts made via command promt don't cause this problem.


 - Harri

You could try excluding those directories, that should help.

Paul