Restoration

[pdewouters]

The ability to automatically restore a site from a BackUpWordPress backup.

There are two parts to this:

1. You have access to your site and click the restore button on the manage backups page
2. Your site is down and all you have is one of the backup zip files

In the first case we should have the option to restore just the database/files/both.

In the second case, we'll need an restore.php file inside the backup, the restore process will then be:

1. Upload the files in the zip to the server
2. Hit restore.php in your browser
3. Magic restore process is kicked off

The magic restore process will need to:

1. Restore the database

• Can get the database server details from wp-config in the zip (not if it's a different server)
• Prompt for database server details.
• Test we can connect.
• Does the provided database still contain the old copy of the site?
• Import the database dump file with a custom table prefix and update wp-config with that prefix (means we never overwrite / conflict with existing database tables). Also makes it easy to switch back to old database as we just switch the database prefix in wp-config.
• If we restored from within WordPress then we could offer ability to undo the restore (by doing the table prefix switch).
• Handle errors that can come up during import.

We'd ideally support importing via both mysqldump if CLI access is available, falling back to a PHP import if not, the PHP import will likely need to handle chunking the import so it can handle importing large databases.

2. Restore the files

• Files are already restored if they unzipped the backup and uploaded all the files.
• For restore from within WordPress:
  • Unzip the zip
  • Move the existing files to a directory called "old" or something
  • Move the files that we're unzipped into place

We can probably just use the built in WordPress unzip functions for unzipping.

I broke this into smaller parts:

• https://github.com/humanmade/backupwordpress/issues/471

[pdewouters]

Files are already restored if they unzipped the backup and uploaded all the files

Probably better to upload a zip and unzip on the server

[pdewouters]

When restoring from a script file with no access to WordPress, then obviously we can't depend on core functions. For example copy_dir - we'll still need to write our own

[willmot]

When restoring from a script file with no access to WordPress

Good call!

[willmot]

This is a large undertaking, the very definition of an Epic. We need to figure out a way to take small steps in right direction. Also, restoration isn't a single thing. Users might want to just restore a single file. They might want to just roll the database back, they might still have access to the site and want to go there to initiate a restore or they might no longer have access and need to restore to a fresh server. We need to identify each of those scenarios, break them down, tackle the easiest ones and slowly work towards a point where we have a robust restore solution.

• My pitch would be work on single file / folder restore first as an enhancement to #44.
• database restore triggered from within the site is also fairly straightforward.

Once we have those two then we shouldn't be too far away from being able to completely roll a site back to a previous backup state from within the site itself.

Another consideration, can we enable undo so that users whom accidently restore to the wrong backup can get back to where they were (we probably can).