Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backup error: The source folder does not exist, aborting backup #2760

Pectojin opened this Issue Sep 25, 2017 · 6 comments


None yet
3 participants
Copy link

Pectojin commented Sep 25, 2017

  • [x ] I have searched open and closed issues for duplicates.

Environment info

  • Duplicati version:
  • Operating system: Ubuntu 16.04
  • Backend: Local system folder


Backups fail if a source folder has been deleted. This seems inconsistent with what I'd expect when deleting a folder that I'm backing up.

For example a directory test/ containing the directories a/ and b/

Selecting the directory a/ and b/ for backup, backing up, and then removing a/ will cause the error The source folder test/a/ does not exist, aborting backup. Meanwhile if you select test/ as backup source and then remove a/ it will run just fine.

So a clear workaround is to choose source folders that will not be deleted and then excluding subfolders that you don't want to backup. But that can be quite a PITA if you have to unselect 150 folders within a source folder. Not to mention the fact that this "effect" has left me without duplicati backups since Saturday cause I didn't check on it since I deleted one of the source folders.

Steps to reproduce

  1. Create new backup
  2. Select a source folder
  3. Run backup
  4. Remove source folder
  5. Run backup again
  • Actual result:
    Backup exits with error The source folder test/a/ does not exist, aborting backup
  • Expected result:
    Backup gracefully skips the missing source and continues to backup any existing source folders.

@Pectojin Pectojin referenced this issue Sep 26, 2017


Handling of external drives #2768

1 of 1 task complete

This comment has been minimized.

Copy link

NoLooseEnds commented Sep 26, 2017

Is'nt this a good behavior? If a directory I was actively backing up disappeared I would appreciate the error message to give me the heads up.


This comment has been minimized.

Copy link
Member Author

Pectojin commented Sep 26, 2017

I don't think this is good behavior.

It's fair to want a warning message, but fully preventing backups can literally be disastrous.


This comment has been minimized.

Copy link

kenkendk commented Sep 28, 2017

This is intended as @NoLooseEnds suggest.
@Pectojin you can disable it if you like, using --allow-missing-source.
Does this fix the problem?


This comment has been minimized.

Copy link
Member Author

Pectojin commented Sep 28, 2017

--allow-missing-source does resolve my issue, thanks!

As to the more philosophical debate, I still feel strongly about my backup software doing backups - instead of worrying about auditing file changes. If someone deletes half my files I'd rather have backups of the 2nd half of my files than no backups.

In a scenario where a source folder accidentally got deleted over night you lose any ability to back up your files until you correct the problem in the morning... Unless you remembered to add the --allow-missing-source tag during configuration.

That seems like unintuitive backup software behavior to me and brings Duplicati into the domain of filesystem auditing software.


This comment has been minimized.

Copy link

kenkendk commented Sep 29, 2017

I think the problem is that Duplicati does not know why the source folder is missing or if that is acceptable.

The intention with the current default behaviour is that you would be really sad if you have been running backups regularly (configured, tested, and verified), but then suddenly find out that the folder you want to restore has not been backed up. By stopping the backup, Duplicati calls for "attention" saying "things are not working the way you set them up".


This comment has been minimized.

Copy link
Member Author

Pectojin commented Sep 30, 2017

I think we may be at an impasse due to underlying functionality in Duplicati.

Since we can't know why it was deleted it's risky to backup because it may cause the deleted files to drift out of scope (if it's limited to X backups or days) losing the data. Or it may just be difficult to find the files again if you have 168 backups to go through for the last week.

I recognize that it introduces some problems, and maybe now just isn't a good time to discuss changing this behavior because of that.

In any case the optional tag does resolve my issue, so I'll close the issue since it's resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.