I share the frustration with everyone else on the changes introduced with version 5.x. However, I’ve found ways to work around the problems and maintain daily backups, the way I want the backups to be run, on the majority of my sites. However, with the 5.1.0 update, all my backup Jobs that save the files to Dropbox, have quit running, and new jobs that are saving the files to “website server” are taking its place.
The whole reason I use this plugin is to save the files to Dropbox. I already pay for server backups through my host. I want/need backups to be saved off-server.
Most of your changes from 5.0.1 to 5.0.9 have slowly reintroduced the functionality that was removed in 5.0. However, this might be the greatest step back that has been taken yet.
How might I turn off the jobs that you’ve introduced, in favor of turning back on the job that I’ve had running for years?
There was contant improvement from 5.0 to 5.0.9, but now 5.1.0 effectively removes a lot of functionality again, which in theory is still there, it just doesn’t work any more.
My old backup jobs from the 4.x days, which ran fine with versions up until 5.0.9, have now been disabled with 5.1.0 and there is no way to enable them again.
Scheduling always creates jobs at 00:00, no matter what time I specify.
Thanks a lot for sharing your thoughts — and we genuinely appreciate your persistence in working through the earlier changes and continuing to rely on BackWPup.
We want to reassure you that nothing has been removed in version 5.1. On the contrary, the update expands flexibility by letting you create unlimited jobs, select storage per job, name jobs, and more. However, we understand that what you’re experiencing with Dropbox and the job behavior feels like a step back — and we’re sorry for the frustration caused.
To clarify:
Scheduled jobs created with v5’s new UI will run as expected and send backups to the selected storage (e.g., Dropbox).
The “Backup Now” button in the main UI currently stores backups only on the local server, regardless of storage selected in the job.
This doesn’t override your scheduled jobs.
We understand how this might look like the Dropbox job stopped working — but it hasn’t been replaced, just visually deprioritized.
That said, your feedback is spot on — and we’re already working to improve this flow in version 5.2, where each job will have its own dedicated “Run Now” button that respects its storage configuration. This will make it much clearer and intuitive.
As a workaround, you can go to Advanced Settings > Jobs > Access to Jobs and click “Run now” on the specific job — this will trigger the backup using the correct job settings and storage.
Regarding the old jobs from version 4.x, they are still preserved but in read-only mode and won’t receive further updates. We recommend recreating your old Dropbox job with the new UI and assigning Dropbox as its storage — that should work consistently going forward.
Also, about the scheduling issue (jobs always triggering at 00:00) — thanks for flagging that. We’re aware that the current interface still defaults to UTC time, and it’s something we plan to address soon to match local time expectations.
Again, we truly appreciate you sticking with us through this transition. BackWPup 5.1 is a major step forward, and 5.2 will continue in that direction. If the new version still doesn’t match your expectations or if Dropbox is still not working as it should, please feel free to reach out — we’re happy to investigate further.
Unfortunately what I’m experiencing on a little over 100 websites does not match what you’re saying.
After upgrading to 5.1.0, my established scheduled jobs are no longer running. Instead, there are new jobs, set to Monthly, 1st day of the month, and 12:00am. That job ran once on the first day after the plugin update (yesterday), and nothing ran today.
My scheduled jobs are set to use a cronjob from the server – so that I can stagger my 100+ jobs throughout the overnight rather than having every single one of them run at the exact same time. Until 5.1.0 I’d been able to keep this functionality working on my sites, with ongoing effort. Those jobs also were set to go to my Dropbox account.
Those jobs have not run at all the last two days. The latest files on Dropbox are now 48+ hours old. And the latest backup for any site is now over 24 hours old and stored on the server.
There are multiple issues at play here, and I’ve spent a lot of time since 5.0 was released, trying to simply maintain the functionality (that I was very happy with) as closely as possible. While I’m not happy about the time I’ve spent on this rather than paying client projects, at least I was able to keep things running, in the hopes that your continued restoration of prior functionality would continue as it had through 5.0.1, .2, .3, etc. But now 5.1.0 renders all that effort useless.
Thank you for listening. It’s just incredibly frustrating. Yours was a trusted plugin that I have installed on all of my sites for over 10 years.
Unfortunately what I’m experiencing on a little over 100 websites does not match what you’re saying. After upgrading to 5.1.0, my established scheduled jobs are no longer running.
Unfortunately, I have to confirm that. In the pop-up of my installations (5 different sites) I get the message “Rest assured, all your old backups remain fully operational”. But this is not true. All old jobs with automatic execution time have been reset to “manual” by the plugin and can no longer be executed as cronjobs.
“We recommend recreating your old job with the new UI.”
BackWPUp Support (@saranshwpm)
Well, in the past I got one single ZIP-file out of my backup jobs, including database, files and plugins. When I see the new interface, a backup can only contain either the database or the WP files. So I have to create two archives for each backup point in time, store them both and restore the correct pair in an emergency? This is error-prone and makes little sense.
This is an example of what all my existing Jobs now look like on all my sites. They have been set to “manually only”, rather than “with a link”, and the job cannot be edited. This is what has been running perfectly – in some cases for nearly 10 years – but now is useless.
I do not have the time, nor the interest, in creating new jobs in the new UI to reauthenticate Dropbox over 100 times. I am willing to log into all 100 sites and change the radio button from “manually only” to “with a link”, should that be necessary, but only if the already-established Dropbox connection is preserved.
This reply was modified 12 months ago by Matt Scheidler.
I also think it would be more convenient if manual backups, just like before, were saved to Dropbox when I’ve selected that option in the scheduled backups.
I’m running into the issue that my scheduled backups are not being saved to my Dropbox. I’ve already removed the plugin, reconfigured it, created a new empty folder on Dropbox, and tested this multiple times. The logs say everything went fine and that the backup was successfully sent to Dropbox, but it can’t be found there.
Is this a known issue on your end? We also have more than 100 websites being backed up using your plugin because it always worked flawless, and it’s becoming quite concerning that we keep running into one issue after another.
Before diving into the full details, I want to take a moment to sincerely thank all of you for your continued feedback and reports. It’s genuinely appreciated and incredibly helpful.
Now, regarding what @matt6303 reported about scheduled jobs no longer running after updating to version 5.1.0, unfortunately, I can confirm this issue as well. You can verify whether your old jobs have been deactivated by visiting: yourdomain.com/wp-admin/admin.php?page=backwpupjobs (just replace “yourdomain.com” with your website’s actual domain).
This issue has been addressed in version 5.1.1, where scheduled jobs are no longer deactivated. So going forward, this should not be a concern. However, since some users have already been affected by the 5.1.0 release, our engineering team is actively working on various solutions to help re-enable these jobs. We’ll be sharing more updates in the coming days, as we finalize the best approaches and prepare clear documentation for all available options.
In the meantime, if you have a backup from before 5.1.0 (e.g., any backup prior to April 7th, such as 5.0.9), restoring it will also restore the old scheduled jobs. You should first update to version 5.1.1 and then apply the database backup. This will restore the old scheduled jobs. Please note: this method should not be used if your site contains newer content (post-5.1.0), as restoring an older backup will result in content loss.
Since this workaround isn’t scalable, especially for users managing multiple websites, we are exploring a CLI-based solution to better serve those needs.
@rickvanleeuwen regarding Dropbox: the “Backup now” button currently only backs up to local storage. Running jobs directly to selected storage destinations like Dropbox is already planned for version 5.2. We appreciate your patience as we work on this.
Thanks again for your support and understanding, and apologies for any frustration caused thus far.
This reply was modified 11 months, 3 weeks ago by BackWPup Support.
Thank you again for all your feedback and patience.
We’re happy to share that BackWPup 5.1.3 is now live and includes a key fix for the issue where old jobs were deactivated after updating to version 5.1.0.
🛠️ You can now restore and reactivate your legacy jobs using the new interface added in this release. 📄 Full instructions are available here: 👉 Restoring Legacy Jobs in BackWPup 5.1.3
If you prefer WP-CLI, the doc also includes commands for reactivating jobs directly via terminal.
This update should help get your setup back on track. Let us know how it goes or if you run into anything—we’re here to help.
Thank you. I followed these steps with one site and appear to have been successful. The cronjob is set for the overnight. Provided a new backup is generated and stored to Dropbox tonight, I’ll proceed with completing these steps for the other ~100 sites.
Question – I have launched a couple of brand new client sites in the past several weeks since 5.0 was released, so I didn’t install BackWPUp at all. I just installed 5.1.3 on one of these sites, and I do not see a way to set up a new Job using server cron. While I appreciate the restoration of the Legacy Jobs, this is still my preferred functionality for new sites also. Is this not possible?
Thank you for your diligence in working with me through all the issues that 5.0 and 5.1 have presented.
I mean the “with a link” option. I want to establish similar links for new websites, that can be triggered by a cronjob on the server. You’ve reenabled this for the Legacy jobs on the sites that previously were running 4.x, but I don’t see it available when I try to create a new job for sites that have 5.x installed in the first place.
