I just tried to set the location path in dietpi-backup to folder mounted with sshfs. This failed with the following message:
Error:
/mnt/backups/dietpi-backup Has a filesystem of: fuse.sshfs, and is not supported.
The filesystem must be EXT2/3/4 for symlink compatibility.
Why is it important for a backup tool, which filesystem it’s writing to? As far as I understand from the error message, it seems to require symlink compatibility so why is it not just testing for that instead of checking for the mount type and limiting the supported filesystems?
Just tried one more thing, being a bit more explicit and added the option “-o subtype=ext4” to the sshfs mount command (the remote filesystem is ext4). But still no luck…
Error:
/mnt/backups/dietpi-backup Has a filesystem of: fuse.ext4, and is not supported.
The filesystem must be EXT2/3/4 for symlink compatibility.
I guess it’s really only checking for the filesystem type and only allows local filesystems of type EXT2/3/4.
I understand that, so still my question, why not checking for the “compatibility with Unix permissions and sym links”, but not just for the type of the filesystem (I fully understand, it’s much simpler doing this instead of the other, so it’s not criticism but a hint / request for improvement).
Thanks for the hint. I now also had a look at the script and did some more experiments…
The backup functionality is based on rsync and for remote backups (what I’m after) it would make sense to do it nativly with rsync (instead of using a remote filesystem as local target folder).
So as I understand as of now the diet-backup tool is targeted to support local backups only. Are there any plans to extend it for ssh destinations?