Ok just to explain a concept
When you first create a backup job definition that has an associated Duplicate job with it, two jobs are created but only 1 selection list as follows:
- Initial backup job with selection list containing data to be backed up
- Duplicate Backup Job BUT NO actual selection list, just a link referencing it to the Initial job
NOTE: If at this point you try to run the duplicate it will give an error as it does not have any selections to backup
When you then run that initial backup the status changes to
- Initial backup job with selection list containing data to be backed up
- Duplicate Backup Job with selection list based on the catalog of the finished initial job
When the duplicate then runs (assuming it completes with a valid status i.e sucessfully or with exceptions) we remove the selection list of the duplicate from the job, so that the next time the duplicate runs it does NOT try to duplicate the original data from the first instance of it running. If we did not do this then you duplicate job would continue to try to duplicate every previous backup job. This results in the selection list status returning to:
- Initial backup job with selection list containing data to be backed up
- Duplicate Backup Job BUT NO actual selection list, just a link referencing it to the Initial job
Note: Again if you try to run the duplicate at this point (from the job) it will fail as there is no selections for the duplicate to backup.
if something happens to stop the duplicate from running after the initial backup, or if you deliberately schedule your duplicate to run less frequently than your initial backups (and as long as you are not using only duplicate last full) you end up with the following selection list association
- Initial backup job with selection list containing data to be backed up
- Duplicate Backup Job with selection list based on the catalog of the finished initial job from first instance of the initial job + selection list form catalog of 2nd instance + selection list from catalog of 3rd instance etc
When the duplicate that runs and completes with a valid status, the selection list for the duplicate is again cleared and again any futher attempts to run the duplicate (from the job) will again fail.
The above is all by design and will hopefully explain your initial problem and depdending on how you tried to do your other manual attempts to run a duplicate might explain some of your other senarios as well.
If however you go to the backup set view and setup a one off duplicate from here, a new duplicate job is created with it's own selection list - hence my earlier recommendation as this should work. If you cannot do a manual duplicate in this way then you should log a formal support case.
Notes:
If using the duplicate only last full option, when a new catalog is added to the duplicate selection list we remove any previous ones
BE2014 has logic to remove any orphan catalogs from the duplicate selections if the backup sets have expired and been deleted before they were duplicated (as otherwise this would also generate an error). BE 2012 did not have this logic and this did cause some issues.
