BTW: A good way of showing your appreciation for a post is to like it: just press the button under the post. If you asked the original question, you can also mark an answer as the accepted answer which solved your problem using the tick-box button under esch reply. All of this also helps the forum software distinguish interesting from less interesting posts when compiling summary emails.
It’s been running since my last post, I selected a delete and repair on the database, I hope that was right, as it’s whats mentioned above
Im monitoring the database files, their ATime is changibg(updating) every few mins, so something is happening. The disks are all healthy, the process (mono) is alive( fluctuations in cup and ram allocated to it. The free space on relevant volumes is consistently non zero by the order of gigabytes, overall cpu and ram are available in acceptable quantities (never hitting the end-stops). I noticed that swap was low so I added another 20Gig to the existing 5. Network traffic to the destination back end is active ( packets are flowing, tcp session is established, send and receive flow rates are at expected levels (non zero to maxing out periodically)
Which all makes me wonder, what is it actually doing? What does a delete and repair actually do? Ian it downloading each and every chunk and processing it before sending it back again? Is there any way to get more detailed statistics from duplicati?
Bearing in mind I’m trying to seed a migrated backup set from crashplan, I’m wondering if I would be best places to wipe the back end and start I’ve ? I’m keen to understand more.
I have nothing for logs, except a droplist saying “Disabled”.
Where would I look to find files that it has downloaded from the backend to see what size they are and how many there are ? ( I see in the job-specific logs that it has downloaded “17517 volumes for blocklists” and is currently processing all of them.
is “blocklist” here the dblock files ? (I have only 2 dlist files on the backend, these are the ones I modified to correct the file paths.
I’m just wondering if I should cancel the database rebuild and start the backup from scratch. I’m worried that if I lose connection on my flaky ADSL broadband, or the SSH tunnel drops or something, that I would have to restart the rebuild from scratch… in which case a fresh backup might be preferable as at least it will pick up where it left off ?
I feel getting ETA is difficult because in case of backup operation it depends on the file types, how fast they can get processed. ETA will keep fluctuating other things are bandwidth speed system performance etc
It sounds like you’re in the right place - does the droplist not show other options (such as Profiling)?
For a rebuild that could happen, but if all the files have already downloaded or the connection drops then reconnects between downloads then it shouldn’t be an issue.
The way I see it, if you cancel the repair you can be 100% sure it won’t work - letting it run improves those odds quite a bit.
As for an ETA, on a database repair that’s very hard to pin down. I personally haven’t had any long (to me) rebuild times but we’ve heard from other users who have waited a week or two for the repair to finish.
I don’t know that we’ve pinned down yet why there’s such a huge difference in repair times, so we can’t really say whether yours is likely to be fast or slow.
The “Profiling” view in the “Log data from the server” shown above should give you a step-by-step list of what is going on. If you’re not seeing anything other than “Disabled” try refreshing (F5 or Ctrl-F5) your browser window.