TrueCloud Backup fails while pruning

TrueNAS General
1

Hi guys,

I’m using TrueNAS SCALE 25.10.7 and TrueCloud Backup (Storj).

Unfortunately, my Backup jobs are failing sporadically with this error message (from /var/log/jobs/xxx.log)

warning: running prune without a cache, this may be very slow!
loading indexes...
loading all snapshots...
finding data that is still in use for 14 snapshots
[17:04] 100.00%  14 / 14 snapshots

The difference between the request time and the server's time is too large.
ReadFull(<data/5639f4dddc>)
github.com/restic/restic/internal/backend.ReadAt
        /restic/internal/backend/readerat.go:39
github.com/restic/restic/internal/repository.(*Repository).LoadBlob
        /restic/internal/repository/repository.go:297
github.com/restic/restic/internal/restic.LoadTree
        /restic/internal/restic/tree.go:115
github.com/restic/restic/internal/restic.loadTreeWorker
        /restic/internal/restic/tree_stream.go:36
github.com/restic/restic/internal/restic.StreamTrees.func1
        /restic/internal/restic/tree_stream.go:176
golang.org/x/sync/errgroup.(*Group).Go.func1
        /home/build/go/pkg/mod/golang.org/x/sync@v0.5.0/errgroup/errgroup.go:75
runtime.goexit
        /usr/local/go/src/runtime/asm_amd64.s:1650

I don’t think that the problem exists because the time on my TrueNAS is incorrect, because it should be fine:

truenas_admin@nas[~]$ timedatectl                                                                                                                                            
               Local time: Thu 2026-10-29 07:24:21 CET
           Universal time: Thu 2026-10-29 06:24:21 UTC
                 RTC time: Thu 2026-10-29 06:24:21
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

These are the settings for my backup job:

Path: /mnt/tank/data/Andy
Cache Path: -
Credentials: Storj
Bucket: backup
Folder: Andy
Keep Last: 14
Rate Limit: No limit
Transfer Setting: Default
Post Script: -
Pre Script: -

What could be causing this problem?

Clause suggests to run restic without --no-cache, but I guess there is a reason why this parameter is enabled by default for TrueCloud Backups, right?

Thanks!

2

Unfortunately I can’t help you with your issue, but you should probably move off storj anyway, since they are filing for chapter 11.

3

Oh, that’s very unfortunate. Especially because Storj is the only cloud service provider that is compatible with TrueCloud Backup right now? Cloud Sync does not support retention and therefore is no real backup.

Will TrueNAS open up TrueCloud Backup to other services?

4

AFAIK, TureCloud is just restic to storj.

IMHO, retention should be set on the destination, not on TrueNAS. Imagine you getting malwared, in that case the attacker could just change your retention settings.

Just use S3. Backblaze B2 for example is cheap and you can set retention (Object lock) in the webGUI.

5

I don’t know much about how Backblaze B2 works. I understand that with Object Lock enabled, files will not be deleted for e.g. 30 days. Also when files are being overwritten, an older version of the file will be available. But how can I access these files, for example if all my data has been encrypted by ransomware and some of it has been uploaded already?

6

I did now setup Backblaze B2 with Lifecycle Rule (30 days), so I think the backup should be safe in case of a Ransomware attack or data corruption. I was also able to download the backup at a specific point in time to my computer.

7

It is just a S3 provider. You can take any S3 provider. Amazon, Hetzner, Azure, Wasabi…

In the webGUI

AFAIK lifecycle rules don’t make it immutable, but I could be wrong. You would have to read up on the docs.

8

That’s right, but the API Key for TrueNAS has no rights to delete files, it can just mark them as hidden. That’s what rclone does, when a file at the source is deleted. Hidden files are then deleted by the lifecycle rule after 30 days.

Do you use Object Lock or how do you do it? As far as I understood, the Object Lock timer starts at the creation of the file on S3, not when it’s being deleted. That makes it useless for my case.