TL;DR: I want cloud backups to be identifiable by site name, date and readable file names instead of only site IDs and snapshot IDs, so I can see what belongs where directly in the bucket. Right now the bucket only shows numbered folders like 62/1/ (site ID and snapshot ID) with hashed chunk names. I can’t tell which website or which date a backup belongs to without looking it up in the MainWP Dashboard. The filename tokens I configure for the backup name don’t show up in the bucket at all, because they only apply to the local copy (which I personally do not even want to have). Please add: Site name (or domain) in the folder name, in addition to the ID Backup date in the folder or file name The configured naming convention and tokens applied to the cloud copy too This makes it much easier to manage storage, check that backups exist for each client site, and clean up old ones, without relying on the Dashboard. Example EXPECTED Website-folder-A 2026-10-30-websitenameA-fullbackup-01.zip (depending on the backup name and used tokens for the naming convention) 2026-10-30-websitenameA-fullbackup-02.zip 2026-10-30-websitenameA-fullbackup-03.zip Website-folder-B 2026-10-30-websitenameB-fullbackup-01.zip 2026-10-30-websitenameB-fullbackup-02.zip 2026-10-30-websitenameB-fullbackup-03.zip RIGHT NOW 62 1 chunks 8f723e46d1dee557f4128abeb7e9564e.bin d2d6027cd2613e567d9b2c2fcb16bfd2.bin … manifest.json 65 2 chunks … … manifest.json
TL;DR: I want to download remote-only cloud backups as a standard ZIP file, that includes the full WP structure and SQL file, so I can recover my data without the MainWP Dashboard. Right now, backups stored in cloud storage (S3, Backblaze, Hetzner and others) are split into .bin chunk files plus a manifest.json. I can't do anything with these files without the MainWP Dashboard. Remote-only backups can be restored but not downloaded, so I depend on MainWP to get my own data back. With other backup solutions like UpdraftPlus or WPvivid, I can download a normal ZIP file with the WordPress folder structure and the .sql file. I can open it anywhere, check it myself, or hand it to a client or colleague. That makes me feel independent and safe, because a ZIP file is universal. Please add: A Download button for remote-only backups that rebuilds and delivers one standard ZIP (or tar.gz) file, ideally including the .sql file Optionally, a documented way to reassemble the chunks manually if the Dashboard is ever unavailable (first version preferred though) In the worst case, with a broken Dashboard or a lost server, I want to be able to get my backups and use them without MainWP. That confidence would make it much easier to trust the built-in backups with client sites.
Please add a "Back up & Update" option for updates started from the Dashboard, similar to what UpdraftPlus does with "Automatically backup before updating". UpdraftPlus only backs up what the update touches: the plugins for a plugin update, the themes for a theme update, plus the database. That's quick enough to do before every update. With MainWP I envision a button per site (with additional global option) “Back up & Update”. The way I could see this working is: Click the back up & update button in the dashboard This triggers an update search on the child site List of available updates is updated for the dashboard Dashboard knows the scope and can back up the relevant parts Backup finishes & update runs With the Built-in Backups this would tie in with backup scopes (DB + plugins, DB + themes, DB + core). https://voice.mainwp.com/p/built-in-backups-backup-scopes-and-restore If the update breaks the site, restoring that snapshot rolls back just the update, easy and from the dashboard. I have been a MainWP user for many years. If you asked me for the ONE thing missing from MainWP, this is it. As far as maintenance goes, it's the core business: backups and updates, because my clients can't or won't do them. Past related requests: UpDraftPlus Backup Before Updates (https://voice.mainwp.com/p/updraftplus-backup-before-updates-2) Update from dashboard trigger backup before update (https://voice.mainwp.com/p/update-from-dashboard-tigger-backup-auto-before-update-feature-wpvividwp-2)
Let backup tasks cover only part of a site: DB + core, DB + themes, or DB + plugins. When I update one or two plugins, I don't necessarily need a full backup including a large media library. A scoped backup would be faster, smaller, and restore only what the update changed. Possibly related: https://voice.mainwp.com/p/allow-backup-to-replace-certain-files-or-db-only
Download is greyed out for snapshots that only exist on the remote destination (SFTP in my case). With "Remove local archives after upload" on, that's every snapshot. A backup I can't get at (it’s stored in .bin pieces) is only useful while the site and the Dashboard both work. Sometimes I need a file, a plugin folder or the database to solve a problem or to set up a local copy of a broken/inaccessible site. Please allow downloading these snapshots as a normal archive (files + database).
The new backup system looks great! I’d love to see Google Drive added as a backup storage destination, alongside Google Cloud Storage. I already use Google Drive for my website backups. Being able to connect it directly to MainWP would let me manage backups centrally and replace my current UpdraftPlus setup, without having to switch storage services. Ideally, I’d like to select a destination folder in Google Drive and configure scheduled backups and retention settings within MainWP. Thanks for considering this!
Now that I’m setting up the built-in backups, I’m wondering if scheduling could be simpler as the number of sites grows. Daily database and weekly full backups across 20 sites could mean maintaining 40 separate tasks. When several sites share a server, manually staggering start times also doesn’t guarantee they won’t overlap if a backup takes longer than expected. Would either of these options be possible? Automatic staggering: Select sites and a backup window, then let MainWP spread their start times across it. Sequential processing: Select sites and a starting time, then back them up one at a time, similar in concept to Sync, with an optional delay between sites. For sequential processing, it would be useful to choose whether the next site starts after backup creation or after the remote upload is verified and local files are cleaned up. Ideally, the limit would also cover separate tasks targeting the same server. The goal is less manual scheduling and better control over server load and temporary storage. Is there already a recommended way to achieve this?
Sometimes I just want to restore certain files (i.e., a plugin or the whole plugin directory) or maybe even just the database to quickly revert back if something went wrong.
TL;DR: Please add an optional "Full Wipe & Clean Restore" mode that completely deletes existing WordPress files and database tables before restoring a backup, rather than overwriting them. As discussed in this community thread, the current restore process doesn't necessarily remove all existing files and database tables. This is particularly problematic when recovering hacked or malware-infected WordPress sites, where leftover files, backdoors, or database entries may survive the restore. Suggested feature: Keep the current restore behavior as the default. Add an optional "Full Wipe & Clean Restore" mode. Completely delete existing WordPress files and database tables before restoring the backup. Include clear warnings and safeguards for this destructive operation. WPvivid already offers similar functionality. While a clean restore cannot guarantee complete malware removal, it would significantly improve MainWP's usefulness for recovering compromised websites.
I'd like to make more use of the Time Tracker extension, particularly its integration with Pro Reports, but the inability to backdate tasks is proving quite limiting. Often, I'll complete work on a client's website but won't get around to recording it until the following day, or sometimes several days later. Currently, when creating or editing a task, the date picker only allows the current date. Previous and future dates are unavailable. It would be really useful to be able to: Create tasks retrospectively, specifying the actual date the work was completed. Change the date of an existing task. Have those tasks appear under the correct dates in monthly Pro Reports. For those of us managing multiple client websites, it's not always practical to record every task as it's completed. Being able to add entries retrospectively would make Time Tracker considerably more useful as a record of work carried out and for client reporting.
Your “not installed” status in the dropdown there in the plugins area is useless as it is, does absolutely nothing… We need to be able to see which sites a plugin, that we DO have installed on one or more sites, is NOT on, and THEN be able to selectively install THAT same plugin on one or more select sites that it is not on…
In the uptime monitor area... The Uptime Monitor bottom button to also be green, until there is one or more sites down, and only then it turn red...???
When selecting Sites and choosing a Tag then clicking back on Sites, have it checked those sites from the chosen Tag. I don’t always trust that the tabs are correct and this would provide a way to double check what’s checked.
I would like a monitor or test that tells me if the retention is working and not simply what date the last successful backup was. Before I do any bulk updates I want to make sure backups are happening. The only thing I have on the main sites list is the date of the last backup. This is nice but doesn’t tell me if my retention settings are working. For example, if I have retention such as saving 2 weeks of daily backups, I want to know if there are 14 daily backups successful or not. If there was one backup yesterday but then a gap of 8 missing backups, I want to know this is happening. I want to see at least 3 or more successful daily backups before I bulk update, not just that there is one single latest one. The only way I see to help with this is if the Updraft plugin verifies retention settings against all the saved backups logged. This way I can get at least a warning that the backup doesn’t appear complete. Even a small marker or counter showing how many daily backups are seen, for example “Latest Backup m/d/y [5]” where the 5 is just a count of consecutive days based on retention. If I had incremental backups every 4 hours, then it would be consecutive 4 hours backups. All I want to know is if “create backup every XX time” is working by counting or checking if that is happening and if there are breaks or missing recent backups. Ultimately I will not bulk update websites unless I know backup retention is happening more than just seeing there is one recent backup on the sites table listing. I am checking every site one by one to at least make sure I have many days of successful backups first and that my retention appears to be happening properly. This is a long process that gets old but it’s important to stay safe. It is not uncommon to have at least one website with a odd backup issue almost every time I go to bulk update. Or I find gaps in the expected retention. Another bug I’ll find is when backup zips get stuck and the backup size becomes large, many gigs or 10s of gigs I’ve seen. I can only verify this by opening the sites one by one and looking at the backup settings to see the total size. For me, I send all backups to S3 and don’t save them locally so my total backup size is typically less than 10MB which is just the size of log files really. Just today I went to bulk update and found one site with over 1.1GB and another over 6GB of stuck or corrupt or files that didn’t finish processing to S3. I need to know about these before I do bulk updates. Hopefully the Updraft plugin could be improved to give me more warnings if things don’t look right. Which I’m thinking is just a matter of the plugin checking the recorded backups against retention settings. And giving me total backup size for the heck of it.
Currently if multiple sites are disconnected you need to change to the Sites page and use a Bulk Action to reconnect all. If you are on the dashboard you can only reconnect one at a time. It would be nice to add an option to the Dashboard Widget to have an option to Reconnect All Disconnected Sites.
Currently the vulnerability checker requires us to go through all entries and click either on “ignore“ or “ignore globally“ and wait for the request to finish. Ideally we’d have a bulk-option, where we can select multiple entries and then select an action for all of them. This makes it especially easier, for false positives like “Division by zero“ in c-libraries which often matches for the Divi theme.
I really like the Feature Support Form in the Whitel Label Plugin. A great addition would be a “File Upload” Field for the client to be able to attach sc reenshots of his problem.
Hi, I have a fairly big feature request: MainWP integration with xCloud. What do I mean by integration? Automatically add new WordPress sites created in xCloud to MainWP. Show xCloud backup information and backup status directly inside MainWP. Share relevant site data between xCloud and MainWP, so the two platforms stay synchronized. Why would this be useful? xCloud is excellent for server and hosting management, but its WordPress management features are still far behind what MainWP offers today. A native integration between the two platforms could create a much more powerful ecosystem: xCloud for infrastructure and hosting management, MainWP for WordPress management. I think this would be extremely useful for agencies managing many WordPress websites.
It would be very useful to have the ability to manually define whether a site is a Production or Staging site in MainWP. Currently, the MainWP Staging extension creates a “Staging Sites” tag, and sites can be manually added to that tag. However, this does not affect the Production / Staging filter in the Updates section. A site manually added to the Staging Sites tag still does not appear when selecting Staging from the Updates page dropdown. I manage several staging sites that are not created through WP Staging or another staging integration, so MainWP cannot automatically detect them as staging environments. It would be helpful to have a setting in each site's configuration, for example: Site type Production Staging Automatic detection could remain the default, while this setting could allow users to manually override or define the site type when needed. The manually selected type should then be respected throughout MainWP, particularly by the Production / Staging filters on the Updates page. This would make the Production/Staging functionality useful for staging environments regardless of how they were created.