Stuck on "Starting …"

[kenkendk]

@NoLooseEnds

I got an error message saying that it failed due to disk space [Insertion failed because the database is full

database or disk is full] (I have a few gb available on the Ubuntu VM), but I googled and read that it could be the /tmp that became full, so I used the advanced option and moved the tmp directory to the same NAS that is backing up (via NFS, VM network – all on the same machine).

Please note that SQLite does not honor the hint to use a new tempfolder from the options. You need to set the environment variable TMPDIR to change the temporary folder.

@NoLooseEnds

So in summary, it takes around 4 hours from it starts till it starts backing up. Any thing I can do to debug/speed it up?

From what I can see in the code, the query you reported as taking 2 hours (wow!) is rebuilding missing index file(s). Do you have any idea why it would recreate the index file? Was it deleted? Any error messages?

@NoLooseEnds

Also, before the “out of disk space error” it was around 1,5 TB left. Now it says 3.5 TB – and are uploading. Some files should be new, but not 2+ TB worth. Should this worry me?

No worry, it just scans the files before it finds that they are not changed. It is also discussed here:

Rework "size remaining" indicator in the running backup status bar

…If possible? The issue I’ve noticed is that when new data is added to a backup set, and a job is run to get that new data uploaded (especially if there’s a lot), the backup engine isn’t especially thorough at figuring out in advance just how much of the pending job is already uploaded. I’m not sure it’s necessarily possible (though forgive me in advance for saying “but crashplan…”) - but it’s a tiny bit frustrating to add 10 GB more data to my backup set of ~400, and for the hour or so it tak…