Backup
Takes a copy of the site now, or on a schedule, and sends it somewhere that is not the server it is backing up. Full site, database only, or files only. Destinations are your own storage — MetaWrench never receives a backup.
Settings
- What to back up
- Full Backup is database and files: everything. Database Only is posts, pages, settings and users, and is small and quick. Files Only is themes, plugins and uploads.
- Save to — Server
- Saves to
wp-content/mw-backups/on this server. Fine as a quick copy before a change, but a backup on the same server as the site is lost with it. Download it from the history to keep a copy elsewhere. - Save to — Google Drive
- Needs a Google OAuth Client ID and Secret, made once in Google Cloud Console; the Setup guide link walks through it. Save credentials, then Connect. Backups go to a MetaWrench folder in your Drive.
- Save to — Dropbox
- Create a Dropbox app, add the redirect URI the tab shows, paste the App key and App secret, save, then Connect. Backups go to a folder inside the app’s own Dropbox folder. Works on hosts that block FTP.
- Save to — Amazon S3
- Bucket, region, access key ID, secret access key, optional folder. Test Connection confirms before you rely on it.
- Save to — FTP / SFTP (advanced)
- For pushing to a server you control: a backup box, a NAS, a second hosting account. SFTP needs the ssh2 PHP extension; plain FTP works without it but sends the password unencrypted. Most people are better served by Dropbox or Google Drive.
- Scheduled Backups
- Enable, then frequency (Daily, Weekly, Monthly), time, type, and destination. Next scheduled backup shows below. Scheduled backups run in chunks, so they work on sites too large for a single manual backup.
When something looks wrong
- A manual backup times out
- The site is too large for one request on this host. Use the schedule, which runs in chunks, or do Database Only and Files Only separately.
- Google Drive: connect fails or says redirect mismatch
- The redirect URI in Google Cloud Console must exactly match the one shown on the tab, including https and trailing path. Fix it there and try again.
- Dropbox: rejected the App key or App secret
- Copy them again from the Dropbox App Console; a trailing space is the usual cause. Make sure the app has the files.content.write permission.
- FTP / SFTP shows unavailable
- The server lacks the PHP extension for it. The tab says which. Use a cloud destination instead; there is nothing to change on your side.
- Scheduled backups are not running
- WordPress cron only runs when someone visits the site. On a quiet site, ask your host to set up a real cron job hitting
wp-cron.phpevery 15 minutes. Next scheduled backup on the tab tells you if it is overdue. - Backups are filling my storage
- Delete old ones from the Restore tab, or keep fewer by backing up weekly instead of daily. A full backup is typically the size of your uploads folder.
Restore
Every backup listed with its size and date, and a Restore button beside it. A full restore replaces the database and files; a database-only restore leaves files alone. Before anything is overwritten, a rollback copy of the current site is taken, so a restore that fails partway can be undone.
Settings
- Available Backups
- File, size, date, and three buttons: Restore, Download, Delete.
- Restore options
- After pressing Restore: Full Restore, Database Only, or Files Only, then confirm. Progress shows on the page; do not close it.
- Download
- Saves the zip to your computer. Do this for any backup you want to keep beyond the server.
When something looks wrong
- No backups found
- None have been taken yet, or they were sent to a cloud destination and the server copy was not kept. Take one on the Backup tab, or download from your cloud storage and upload on the Migrate tab.
- Restore failed partway
- The page shows what to do and a details block for support. The rollback copy has already put the site back as it was before you started. Read the error, fix the cause (usually disk space or a permission), and try again.
- I restored and now I am logged out
- Expected. A database restore replaces the users table with the one from the backup. Log in with the credentials that existed when the backup was taken.
- The site address is wrong after restore
- You restored a backup from a different address. That is a migration, not a restore; use the Migrate tab, which rewrites the address.
- I need to restore one page, not the whole site
- Not supported directly. Restore Database Only to a staging copy of the site, copy the page content out, and paste it into the live site.
Migrate
Moves a site to a new host or a new domain using the same archive a normal backup produces. On the old site, take a full backup and download it. On the new site, install WordPress and MetaWrench, then upload the archive here. Files are copied first, resumably; the database is swapped last; the site address is rewritten to the new one; and a rollback copy of the current site is taken before anything is touched.
Works on hosts that lock wp-config.php (WP Engine, Flywheel): tables are renamed to match rather than the prefix changed.
Settings
- Drop your backup ZIP here
- Or click to choose. Large archives upload in chunks.
- Before you import
- Read it. A full backup contains the other site’s database, so this site becomes that site, including every user account. Your current username and password will no longer exist here; afterwards you sign in with the other site’s login. Passwords cannot be read from a backup, so if you do not know those details, stop.
- The confirmation tick box
- You must confirm you have the other site’s login and want to replace this one. Then Upload & Import.
When something looks wrong
- Logged out after import
- Expected. The database was replaced. Log in with the old site’s credentials.
- Import stopped partway
- Files copy resumably; run it again with the same archive and it continues. If the database step failed, the rollback has already restored the site you had; read the error details and try again.
- Images are broken after migrating to a new domain
- Hard-refresh first; the old domain is in browser cache. If still broken, the address rewrite missed them because they were stored with the old domain in a serialised option by a page builder. Most page builders have a “replace URL” tool in their settings; run it.
- The upload fails at a certain size
- Your host’s upload limit. The uploader chunks, but some hosts cap the total. Ask the host to raise
upload_max_filesizeandpost_max_size, or use Database Only and Files Only archives separately. - I migrated to a subfolder and links point to the root
- The address rewrite uses the new site’s address as set at install time. Check Settings → General on the new site shows the subfolder address before importing.