Backup issues after WP Workbench 2.0.0 release

But it’s a new feature—we do this only in WP Workbench, not for other backups. What are we breaking here exactly?

And, since we store backups under the domain owner, it makes sense for those backups to be owned by and count against the domain user quota too.

The backups are configured through Virtualmin.

I don’t think backups run as master admin should be included in a user quota.

Just following on from this, we do not store backups on the same server as the virtual servers. The file location where the backup is built is the user’s, so if the backup being created exceeds the quota, it fails. This might make sense from a user perspective, but server admins need to backup outside of these quotas.

Please correct me if I’m wrong, but previously the location was in a tmp folder within the / filesystem.

Aha! Now it makes perfect sense! I’ll take a closer look at it a bit later and update this ticket with progress.

Thanks, Paul!

1 Like

A post was split to a new topic: WP Workbench backup logs cannot be found

After reviewing backup-related issues in the new WP Workbench Manager release, I found three core problems:

  1. The existing ~/wp-workbench-backups directory was included in backups and also written to during internal WP Workbench backups
  2. WP Workbench backup feature wasn’t excluded from scheduled backups when “backup all features” was enabled, causing redundant backups of the WordPress directory and database basically doubling the backup size
  3. Disk quota exceeded errors weren’t handled clearly

We will address it all in the upcoming WP Workbench 2.0.1.

Yet, this is a separate issue and a bit harder to address cleanly. The obstacle is that we always run internal backup commands as domain user. We simply cannot do it otherwise—because we use WP-CLI command to do the job, that a user has write access to—this command can and should only and always be called as domain user, never as root.

So, to address the quota issue when the master admin triggers a backup, the simplest solution would be to disable domain quotas before making the backup, then change permissions for the produced backup and re-enable quotas back.

I know we do disable/re-enable quotas in similar situations, however I’m not confident if that is something we should do for WP Workbench backups. To my mind, it is not a big deal to configure WordPress domain and its quota in a way it can handle extra disk space for a backup and configure specifically created scheduled backup in WP Workbench Manager to delete old backups in some time.

And, I just don’t like having files under user home owned by root user to work-around disk quota issue.

@Jamie, what do you think about it? I know other features ignore user quotas when a backup is made by the master admin—what do you think we should do here for WP Workbench?

Yes, I think that would be the right thing to do. There’s even a function in Virtualmin for this already.

After a detailed discussion with Jamie, we agreed on the following:

  • If a scheduled backup is created via “WP Workbench Manager”, regardless of who does it, the files will always be stored either in ~/wp-workbench-backups or on remote storage; files stored in ~/wp-workbench-backups must be owned by the domain owner and as a result will count against the domain user’s quota.
  • If a scheduled backup is created via “Backup and Restore ⇾ Backup Virtual Servers” by the master administrator, and the destination is not locked to the domain home, then the files will not be owned by the domain user and will not count against their quota.
1 Like

This makes perfect sense. Even though we push as much responsibility to our clients to take their own backups, we always keep some form of a back up too for DR purposes. We also do take on backup management jobs too, so this fits all use cases nicely.

Thanks for all of your hard work on this @Ilia.

1 Like

You’re welcome, @pixel_paul! Please run more tests and let me know if everything works the way it should. Thanks!

Both the manual backups and scheduled backups that ran over the weekend all completed successfully.

1 Like

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.