Rclone backups from TrueNAS to Jottacloud

Help and Support
1

What is the problem you are having with rclone?

This is not really a problem with rclone, but rather how to configure rclone in TrueNAS. The thing I'm wondering about is how the authentication to Jottacloud via rclone works, and to what endpoints with what flags, so I would be able to set it up through the TrueNAS UI.

I would like to know what credentials provider I should use from the following list, and what fields needs to be populated with which values? I'm assuming I should use some of the generic ones like WebDAV, FTP, SFTP, or HTTP, but I'm not entirely sure.

I'm open for any input on better ways to set this up, as long as they don't get flushed after reboot, updates, etc.

Run the command 'rclone version' and share the full output of the command.

rclone v1.67.0
- os/version: debian 12.6 (64 bit)
- os/kernel: 6.6.44-production+truenas (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.22.7
- go/linking: dynamic
- go/tags: none

Which cloud storage system are you using? (eg Google Drive)

Jottacloud:

The command you were trying to run (eg rclone copy /tmp remote:tmp)

N/A

Please run 'rclone config redacted' and share the full output. If you get command not found, please make sure to update rclone.

N/A (empty config, as I need help with actually setting up the config itself.)

A log from the command that you were trying to run with the -vv flag

N/A
2

For Jottacloud you should use jottacloud remote.... Here all details how to configure rclone:

How to configure it in TrueNAS is maybe question to their community.

3

This falls under the "unsolicited" category, but once you do get it set up, if this really is a backup, you should make sure to use rclone in a backup-manner.

Below is a copy/paste answer on how to do this I wrote a while ago:

rclone backup examples

A direct rclone sync is not a backup—or at least not a good one—since it will happily propagate accidental modifications and deletions. There are many tools that excel at backups, some even using rclone as a transfer agent, but rclone can act as a backup itself as well with some flags. It isn't as svelte as the other tools, but the beauty is its simplicity.

Basic

Use --backup-dir with date backups

rclone sync source: dest:current --backup-dir dest:backup/<date>

Done automatically

rclone sync source: dest:current --backup-dir dest:backup/`date +"%Y%m%dT%H%M%S%z"`

Alternative Backup to a hidden subdir

rclone sync src: dst: --backup-dir dst:.backups/`date +"%Y%m%dT%H%M%S%z"` --filter "- /.backups/**"

(The former makes two high-level directories: one for the latest and one for backups. The latter embeds the backup directory in the main destination as a "hidden" directory.)

Problems with the basic approach

The basic approach works well but requires rclone to move (or copy+delete) files to the backup-dir. If your remote doesn't support server-side move, it can be slow. Some remotes support server-side copy (e.g., B2, S3) and that works, but it is also kind of slow.

Still, this is better than a plain rclone sync.

Side Note: Backup Classification

There has been some debate as to how to categorize this type of backup. I believe it is best described as "reverse incremental." It is "incremental" in that only changed/modified files get uploaded. It is "reverse" because the main backup is the current state in its full form, and you have to work backwards from the backup-dirs to restore to a previous state (though it is also not particularly easy to do en masse with this approach). Ultimately, it simply doesn't matter what it's called. :slight_smile: