Dropbox Backup of Virtual Servers errors out with HTTP/1.1 409 Conflict

Backup to Dropbox fails

I am trying to backup to Dropbox path Virtualmin/%Y-%m-%d and I get an error of:

 Starting backup of 117 domains to %Y-%m-%d in Dropbox folder Virtualmin ..
 HTTP/1.1 409 Conflict
 Backup failed! See the progress output above for the reason why.

I have tried it with : Virtualmin/%Y-%m-%d

The OS is Ubuntu 16.04.3 LTS.

I test it with and without strftime style time substitutions on file or directory name

strftime style time substitutions work from the command line root@vhosts:~# date +%Y-%m-%d 2017-11-03

Status: 
Active

Comments

Is your backup over-writing existing files? Also, did you select the single-file backup format, or one file per domain?

There are no files currently in this directory of Dropbox. In the screen grab destination.jpeg you can see I selected "One file per server" option.

Starting backup of 117 domains to %Y-%m-%d in Dropbox folder Virtualmin ..
HTTP/1.1 409 Conflict
Backup failed! See the progress output above for the reason why.

Is the backup over-writing an existing folder in this case?

In Dropbox: The folder Virtualmin exists, but there are no date folders created.

I am still having this problem and I am unable to backup to dropbox.

Are you updated to Virtualmin 6.02 ?

Virtualmin version 6.02-2 Pro

Full backup output HTTP/1.1 409 Conflict

Executed via Scheduled backup Run by web user None (scheduled or command line) Started at 24/Jan/2018 00:00 Completed at 24/Jan/2018 00:00 Final backup size 0 bytes Run time 00 minutes, 02 seconds Backup type Full Compression format tar.gz Filename format One file per server Final status Failed From scheduled backup %Y-%m-%d in Dropbox folder Virtualmin Encrypted backup? No

Damn, I thought I fixed that issue. Are you creating a backup that would over-write existing files?

There are currently files in the folder. But "Delete old backups" is set to never. I am clearing the folder out to see if this has any bearing on the results.... nope.

Starting backup of 124 domains to %Y-%m-%d in Dropbox folder Virtualmin .. HTTP/1.1 409 Conflict Backup failed! See the progress output above for the reason why.

Do you want access?

this is the EXACT same issue as what I am having. Can someone PLEASE fix this?

How did you go remoting in please Jamie?

Can we please re-visit this? Back ups still do NOT work - still get error: HTTP/1.1 409 Conflict I've even moved my virtualmin to a new server, new hosting provider - same issues. I really need to have this working please !!

We're about to release Virtualmin 6.10 that includes some fix in Dropbox support ..

great - thanks Jamie. Do you have an ETA please?

Should be out in a matter of days.

any update on this release please?

??

Version 6.10 should be out now

thanks Jamie - how do I update please? I do yum update and there is nothing there to update?

Ilia's picture
Submitted by Ilia on Sat, 07/11/2020 - 05:13

Steve, all is ready. We're all waiting. I've just spoken with Joe, and he said that he is going to do it this weekend!

Sorry for a delay!

great! look forward to the update shortly then

do you know if this has been done yet? I don't see any update?

Ilia's picture
Submitted by Ilia on Mon, 07/13/2020 - 15:49

do you know if this has been done yet? I don't see any update?

Yes, Virtualmin 6.10 and Webmin 1.953 is out. However, install script and few other modules are not yet upgraded. Hopefully today.

Hi,
I just tried to update - however, it failed (see below) - please advise what I am required to do now?

Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
 * base: mirror.ventraip.net.au
 * centos-sclo-rh: mirror.ventraip.net.au
 * centos-sclo-sclo: mirror.ventraip.net.au
 * epel: epel.mirror.digitalpacific.com.au
 * extras: mirror.ventraip.net.au
 * remi-php54: remi.mirror.digitalpacific.com.au
 * remi-php72: remi.mirror.digitalpacific.com.au
 * remi-safe: remi.mirror.digitalpacific.com.au
 * updates: mirror.ventraip.net.au
Resolving Dependencies
--> Running transaction check
---> Package wbm-virtual-server.noarch 3:6.09-3 will be updated
---> Package wbm-virtual-server.noarch 3:6.10-1 will be an update
http://5567145:QroeGTxHWZ@software.virtualmin.com/universal/repodata/2e736219e766cd708d704a59ade14947de4840b2-filelists.sqlite.bz2: [Errno 14] HTTP Error 404 - Not Found
Trying other mirror.
To address this issue please refer to the below wiki article 

https://wiki.centos.org/yum-errors

If above article doesn't help to resolve this issue please use https://bugs.centos.org/.

 One of the configured repositories failed (Virtualmin Distribution Neutral Packages),
 and yum doesn't have enough cached data to continue. At this point the only
 safe thing yum can do is fail. There are a few ways to work "fix" this:

     1. Contact the upstream for the repository and get them to fix the problem.

     2. Reconfigure the baseurl/etc. for the repository, to point to a working
        upstream. This is most often useful if you are using a newer
        distribution release than is supported by the repository (and the
        packages for the previous distribution release still work).

     3. Run the command with the repository temporarily disabled
            yum --disablerepo=virtualmin-universal ...

     4. Disable the repository permanently, so yum won't use it by default. Yum
        will then just ignore the repository until you permanently enable it
        again or use --enablerepo for temporary usage:

            yum-config-manager --disable virtualmin-universal
        or
            subscription-manager repos --disable=virtualmin-universal

     5. Configure the failing repository to be skipped, if it is unavailable.
        Note that yum will try to contact the repo. when it runs most commands,
        so will have to try and fail each time (and thus. yum will be be much
        slower). If it is a very temporary problem though, this is often a nice
        compromise:

            yum-config-manager --save --setopt=virtualmin-universal.skip_if_unavailable=true

failure: repodata/2e736219e766cd708d704a59ade14947de4840b2-filelists.sqlite.bz2 from virtualmin-universal: [Errno 256] No more mirrors to try.
http://5567145:QroeGTxHWZ@software.virtualmin.com/universal/repodata/2e736219e766cd708d704a59ade14947de4840b2-filelists.sqlite.bz2: [Errno 14] HTTP Error 404 - Not Found

ok, I've updated - however, the Dropbox backup STILL fails? Wasn't this update going to fix this? Please advice.

Can i please have an update on this? The back up to Dropbox STILL does NOT work. I really need to have this working. Error:

Starting backup of 2 domains to Dropbox folder webservers ..

HTTP/1.1 409 Conflict

Backup failed! See the progress output above for the reason why.

Ilia's picture
Submitted by Ilia on Mon, 07/20/2020 - 04:57

HTTP/1.1 409 Conflict Backup failed! See the progress output above for the reason why.

Considering that you have awscli package installed, this error doesn't seem to be Virtualmin related. Please be kind posting your question to dropboxforum.com.

Note: I have just tested it and my Amazon S3 backup worked just fine.

Ilia's picture
Submitted by Ilia on Mon, 07/20/2020 - 04:59

HTTP/1.1 409 error

I have an assumption - you need to sync your server's time and use proper TZ set on both ends.

Wait, is this bug about Dropbox backups, or AWS?

Since we can't re-produce this, we may need to actually login to your system to see what's going wrong.

yes, it is about Dropbox. If I completely delete the back up and the folder on dropbox, set the whole thing up from fresh and run it, then it will work. But, it will then fail every time after that. Which is what was happening before as well. By all means, please logon to my system and check for yourself. thanks.

did you logon to the system please Jamie? My dropbox back up still fails.

Did you send me login details? I never received anything..

just resent again then Jamie.

Sorry I took so long to get back to you - I just tried the SSH details you sent, but I wasn't able to login as either user (even on the correct port).

I have additional security on their with authenticator. I can drop this if you can let me know when you're going to logon?

jimr's picture
Submitted by jimr on Wed, 08/26/2020 - 04:42 Pro Licensee

I randomly get this issue but it seems to be related to the size of the backup .. I have a couple of domains where the back up exceeds 3 GB and these are the domains that throw the error all other domains backup as expected. I get this error maybe once or twice a week based on a daily schedule. As a side note I have one of my webmin servers backup up 04:00 BST which has far less failures than the other which starts at 00:00 BST could dropbox be 'at limits' at 00:00 BST ?

jimr - do you have multiple Virtual servers backing up to the same directory on Dropbox?

Just as a note, my system is now backing up multiple domains each as individual files to Dropbox successfully each night. Placing them in a date stamped folder. Thank you.

can I please have an update to this? My back up still fails with same error.

jimr's picture
Submitted by jimr on Sat, 09/19/2020 - 07:00 Pro Licensee

I'm still not sure that this is a virtualmin issue. I have had the same problems as You with a backup starting at 12:00am BST and finishing around 2:30am BST I altered the schedule to start an hour later and since then the backup has worked every time. I also set the following :-

Servers to save = All

Include sub-servers of those selected? = ticked

Any Plan = selected

Backup all features = selected

Backup destinations = Dropbox

Dropbox path = webmin/full/%d-%m-%y alter this to where you save to & date format you want

Delete old backups = selected I have this set to 2 days but set as required

Do strftime-style time substitutions on file or directory name = ticked

Transfer each virtual server after it is backed up = ticked

Backup format = one file per server selected

Create destination directory? = ticked

Action on error = Continue with other features and servers selected

Backup compression format = default selected

Backup level = full selected (I guess this makes no odds as to how it's set)

Email backup report to = your email

Action if destination is in use = cancel this backup selected

Scheduled backup time = set to complex and set to once a day at 1:00am in my time zone (currently BST)

This worked for me