Cannot recreate jobs (bugs?)


#1

Hello!

I had a rather big backup which was not worth keeping anymore. I have exported the configuration and removed all backup files.
Now when I add new task (import the config) and try to repair the database I can see only the error message: "No files were found at the remote location, perhaps the target url is incorrect?"
What can I do to re-start this job from scratch without necessity to recreate the task?

Very similar problem. I also had another backup that I’d like to start from scratch. Name of the job is “VM”. Important: I have a number of similar jobs with prefixes like “VM X”, “VM Y”, “VM Z”. They are all keep backup files in the same folder!
Now when I try to re-create the task and recreate the database I can see only the error message: "Found 212 parse-able files (of 212 files) with different prefixes: VM X, VM Y, VM Z, did you forget to set the backup prefix?"
No, I did not forget to set the backup prefix, I imported the same old config.
I also tried to change prefix from “VM” to “VM Other”. Same result. It looks like Duplicati just don’t take prefix into account.

MacOS, Duplicati 2.0.2.1_beta_2017-08-01

Thanks,
Haron


#2

Hi Haron!

It sounds like you’ve got two separate issues here which might be better handled as separate posts, so I’m going to try and split them out for you.

Based on the “no files were found” message, I’m guessing you had both of these boxes checked when you deleted the job - is that correct?
image


#3

Can you log into your destination and manually check for the expected pre-fixed files?

Note that changing the --prefix setting on an existing backup can cause as mentioned in this short topic - did you try running a Database Repair on any of these backups?


Found parse-able files with different prefixes, did you forget to set the backup prefix?
#4
  1. “Delete the local database” - most probably yes, I can’t be 100% sure.
  2. “Delete remove files” - no for sure as Duplicati doesn’t manage proper removing files (one more bug that I’d better not speak about for now). Thus I’ve removed files manually.

#5

A post was split to a new topic: Found parse-able files with different prefixes, did you forget to set the backup prefix?


#6

OK, then it sounds like there may be a problem aligning the new job with the old custom-named backup files.

If you can manually confirm that the destination has a set of correctly prefixed files, then we’ll have to look at the imported job to see if perhaps it didn’t import the --prefix value correctly.

Regarding the other bug, is it this one ?


#7

I’m not sure we are on the same page. Let me re-explain the issue.

  1. Create a number of tasks with prefixes like “VM”, “VM X”, “VM Y” and set as a destination the same folder.
  2. Run them all and wait till they finish.
  3. Export a task config where prefix = “VM”
  4. Delete the task “VM” & its backup files
  5. Add a task using the configuration from the step 3
  6. Try to run the task.
    It won’t work complaining that there are backup files with prefixes “VM X”, “VM Y”… That’s right, those are backup files of other tasks (with their own prefixes “VM X” and “VM Y”.). “Rebuild database” doesn’t help with the same error message.

Right, though I use SMB. The same problem.


#8

That’s good then as it’s already been fixed in a canary version.

Thanks walking me through the numbers, that makes it easier for me to dummy up a similar scenario and try to replicate the error.

It’s suggested (at least in the forum) to have different folders for each backup job rather than using a prefix so it’s possible your specific scenario hasn’t been correctly tested.

I’ll try to get back to you shortly.


#9

That’s right, I came to the same conclusion, taking into account the bug with backups removal. Which means that prefix is/was useless so far. Please explain, what are the future plans regarding this feature? Remove prefixes support or debug related functionality?


#10

Here’s what I did:

  1. create two tasks “VM1” and “VM2” with prefixes “VM1” and “VM2” both pointing to the same destination folder
  2. ran both jobs with out issue
  3. exported job “VM1”
  4. deleted job “VM1” with “Delete the local database” only selected (NOT “Delete remote files”)
  5. imported “VM1” from the export file
  6. ran it and got the following erro message:

Found 3 remote files that are not recorded in local storage, please run repair

  1. ran the “Database…” -> “Repair” job without issue
  2. ran the job without issue
  3. manually deleted the VM1-* files from the destination
  4. ran the job and got the following error message:

Found 3 files that are missing from the remote storage, and no files with the backup prefix VM1, but found the following backup prefixes: VM2

  1. ran “Database…” -> “Recreate (delete and repair)” and got the following error message:

Found 3 parse-able files with the prefix VM2, did you forget to set the backup prefix?

So the only way I’ve so far managed to replicate your error message (which, granted, should know that --prefix has NOT been forgotten) is to actually delete dlist.zip, dblock.zip, and dindex.zip destination files for this job’s prefix.

Can you manually confirm that you have VM-* files still showing in your destination? Because without those destination files, there’s nothing from which Duplicati can rebuild the local database.


#11

So the only way I’ve so far managed to replicate your error message (which, granted, should know that --prefix has NOT been forgotten) is to actually delete dlist.zip, dblock.zip, and dindex.zip destination files for this job’s prefix.

Right, that’s what I did (in the first message: “I have exported the configuration and removed all backup files.”)

Can you manually confirm that you have VM-* files still showing in your destination?

100% sure they are not there :slight_smile:

Because without those destination files, there’s nothing from which Duplicati can rebuild the local database.

Right, I just want to “re-start” the task from nothing. I got your idea! Database repair WON’T work in this case and this is quite right.

I’ve re-imported the task again, removed the database and ran the task. It’s all good now, showing the first backup!
Thank you for the experiment and an exhaustive explanation!


#12

Glad to hear it’s working now! :smiley:

…And that I finally got it through my thick skull what you were explaining from the start. :skull: -> :brain: