WordPress Backups

Virtuozzo Application Platform for WordPress provides a fully automated backup solution (based on the Restic software) for all the supported topologies. The platform lets you set up the process based on your needs via a clear and intuitive user interface.

The order of operation is the following:

Refer to the linked section if you are interested in the backup process flow and specifics.

Deploying Backup Storage

Before backing up the WordPress instances, you need to install dedicated storage that will preserve and manage all the backups separately from your WordPress environments.

Click the New Environment button at the top of the dashboard and install the dedicated Backup Storage package from the Extra section. It allows you to choose between two storage types and allocate the required disk size:

  • Standalone - a single Shared Storage node
  • Cluster - the GlusterFS based cluster
    • Number of nodes - configures the number of nodes within the storage cluster (3, 5, or 7 containers)
  • Storage Size - sets the total disk space size for the backup storage (5 GB minimum)

WordPress Backup Storage wizard

Additionally, you can configure the region (should be the same as the WordPress instance that will be backed up) and the preferred environment name.

After clicking on the Install button, the platform will automatically deploy storage according to the specified settings and install the Restic utility required for the backup processes. The storage environment will be placed in the dedicated “WP Backupenvironment group (or the amae-named subgroup if installed within a group).

WordPress Backup Storage dashboard

Depending on the requirements, just one backup storage can be created for all the WordPress installations on the account. If needed, you can have several storage environments to handle different WordPress instances.

Installing Backup Add-On

The Backup/Restore add-on is available for all of the WordPress topologies available for installation under the Virtuozzo Application Platform for WordPress.

WordPress Backup Restore add-on

During the add-on installation, you are able to configure the following parameters:

  • Scheduling Options:
    • Pre-defined - some standard Backup scheduling rules (Daily, Weekly, Hourly, Monthly)
    • Custom - a human-friendly interface to configure scheduling (Time, Days, Time Zone) WordPress custom backup scheduling
    • Manual (crontab) - a cron rule for scheduling (e.g. 0 */12 * * *, to create a backup every 12 hours) WordPress crontab backup scheduling
  • Backup storage - select storage from the drop-down list (environments from the “WP Backup” group) to keep backups for the current WordPress instance
  • Number of backups - sets the number of backups for the current environment to keep on the storage node (the oldest one is automatically removed upon exceeding the value)

Click Install and wait for the platform to set up everything for you.

Managing Backup Add-On

After installation, the Backup/Restore add-on can be found and managed at the dedicated section alongside any other available or installed add-on for the environment. The following options are available:

  • Backup Now - makes a backup at any time (not scheduled)
  • Configure - changes the settings defined during the installation (schedule, backup count, backup node for storing the backups)
  • Restore - chooses a backup to restore from the automatically gathered drop-down list of backups created for this environment

manage Backup Restore add-on

If needed, you can find an option to Uninstall the add-on in the menu at the top-right corner of the panel.

Backup Process Specifics

Below, you can find information on the backup and restoration processes flow and specifics:

  • the backup storage node is mounted to the WordPress instances only during the backup and restore processes (and unmounted afterward)
  • during the backup operation, the Restic creates a snapshot that includes data from the /var/www/webroot/ROOT folder and the full database dump (made with the mysqldump utility)
  • backups on the storage node have timestamps to make them easier to manage during restoration; also, snapshots are automatically rotated based on the backup number configured by the user - only the specified number of the latest backups is kept
  • during the backup operation, the following directories are connected:
    • on the backup storage node - all the backups are stored under the /data folder (every environment has its own subdirectory - /data/${env.name})
    • on the compute node (application server) layer - the /opt/backup/ directory is used for backups
  • during the restoration operation, the following directories are connected:
    • on the backup storage node - the /data/${env.name} directory with backups of the appropriate environment
    • on the compute node (application server) layer - the /tmp/restore directory is used to store initially restored data
  • once data from the snapshot is restored to the application server, the corresponding environment is temporarily stopped to perform database restoration and webroot folder substitution

What’s next?