What a WordPress Site Is Made Of โ Both Parts Are Non-Negotiable
A lot of people back up their files but forget the database, or the reverse. Both are required simultaneously โ restore from just one of them and what comes back is broken.
Site files: the WordPress core installation, themes, plugins, all uploaded images and attachments (the wp-content/uploads directory), and wp-config.php which contains database connection credentials. These typically live in the server's public_html or htdocs directory.
Database: every piece of content, data, and setting lives here โ posts, pages, WooCommerce products and orders, user accounts, site settings, menus, comments, and transaction records. Files can be perfectly intact, but without the database the site opens to nothing.
Recommended Setup: UpdraftPlus for Automated Backups
UpdraftPlus is the most widely used WordPress backup plugin, and the free version covers most sites adequately. After installing and activating, go to Settings โ UpdraftPlus Backups โ Settings and work through the following:
Backup frequency: calibrate to your site type. A corporate site that's mostly static content works fine on weekly backups. A blog with ongoing content updates should run two to three times per week. A WooCommerce store needs at minimum daily database backups โ high-volume stores should consider multiple database backups per day. Files change less frequently than the database, so these can be set independently, with the database scheduled more aggressively.
Remote storage destination: select one or more cloud storage locations for backups to be pushed to automatically. Google Drive, Dropbox, OneDrive, and Amazon S3 are all supported. The free version supports connecting to any of these; the Premium version can push to multiple destinations simultaneously. After configuring authorization, click Test to confirm a test file uploads successfully โ that's the connection verified.
Number of backups to retain: keeping 7โ14 backup sets balances storage cost against recovery flexibility. Too few and you may find that all retained backups are already corrupted versions if a problem was introduced several days ago.
The 3-2-1 Backup Rule: Don't Store Backups Only on the Server
A common mistake: backups exist, but they live on the same server as the site. If the server goes down, the backups go with it โ effectively no backup at all.
The 3-2-1 rule: maintain at least 3 copies of the data, across 2 different storage types, with at least 1 copy stored offsite (at a separate location or provider).
In practice: automatic snapshots from Cloudways or your hosting provider count as one copy. UpdraftPlus pushing to Google Drive is the second. For high-stakes large stores, periodically downloading a copy to a local computer or NAS provides a third. Distributed across different locations, any single point of failure leaves the other copies intact.
The Step Most People Skip: Verifying That Backups Actually Work
A completed backup isn't the same as a functional backup. Common false security: UpdraftPlus reports success but files are incomplete on restore; the backup file reached Google Drive but the downloaded archive is corrupted; the database export only captured some tables.
Run a real restore test every one to two months. No need to do this in production โ set up a local WordPress environment using Local by Flywheel or XAMPP, restore from your backup files, and confirm the site opens correctly with all content intact, WooCommerce products present, and order data complete. Seeing a daily "backup successful" notification is not a substitute for actually testing the restore.
How to Restore: Full Walkthrough
Option One: Restore via UpdraftPlus (recommended)
Go to Settings โ UpdraftPlus Backups โ Existing Backups, locate the version you need, choose what to restore (Plugins, Themes, Uploads, Database โ typically select all), and click Restore. UpdraftPlus handles moving files and the database back to their correct locations. After the restore completes, go to Settings โ Permalinks and click Save โ no changes needed, this just regenerates the .htaccess rewrite rules and resolves some 404 errors that can appear after a restore.
Option Two: Manual restore
If the WordPress admin panel is inaccessible, manual restoration is required: upload the Themes, Plugins, and Uploads directories to their correct locations via SFTP or the hosting control panel's file manager; import the previously exported .sql database file through phpMyAdmin; check that wp-config.php contains the correct database credentials (name, username, password, host) matching the current server; and save the Permalinks settings as described above.
Changing Hosts: Migration Process
The full process for migrating to Cloudways using the official migration plugin is covered in the WooCommerce migration guide โ no need to repeat it here. A few critical checkpoints worth emphasizing:
After migration is complete but before switching DNS, test all critical site functions using the new server's temporary URL: homepage, product pages, cart, checkout, payment processing, and order confirmation emails. This window is the only safe opportunity to find problems. Once DNS switches and real users start arriving, addressing issues becomes considerably more complicated.
Twenty-four hours before the DNS switch, lower the TTL on your DNS records (from 3600 seconds down to 300 seconds). This reduces the propagation window from an hour to about five minutes, giving you the ability to quickly revert to the old server if needed.
If using Cloudflare, set the proxy to DNS-only mode (the grey cloud) during the DNS switch so traffic hits the new server directly. Once the new server has been running stably for a day or two, re-enable the Cloudflare proxy.
Changing Domains: More Involved Than Changing Hosts
Switching domains isn't just updating an address. The database contains the old domain name throughout โ in image URLs, page links, and various settings. Without replacing these, images will fail to load and pages will return 404 errors.
Step one: update the WordPress addresses. Go to Settings โ General and change both the WordPress Address and Site Address to the new domain with https.
Step two: bulk replace the old domain in the database. Install Better Search Replace, enter the old domain (e.g. https://old.com) in the Search field and the new domain (https://new.com) in the Replace field, select all database tables, run a Dry Run first to preview how many records will be affected, then uncheck Dry Run and execute the replacement. This updates image links, page links, and stored settings throughout the database.
Step three: configure 301 redirects on the old domain. Set up redirects on the old server pointing all old URLs to the corresponding new URLs โ a wildcard redirect (https://old.com/* โ https://new.com/$1) handles the full mapping โ signaling to Google and users that the move is permanent.
Step four: update Search Console and Analytics. Add the new domain as a new property in Google Search Console and use the Change of Address tool to notify Google; update the data stream domain in Google Analytics.
Step five: update external links. Anywhere you control: social media profiles, email signatures, advertising account destination URLs, affiliate platform promotion links โ update these manually to the new domain.
Additional Checks for WooCommerce Store Migrations
Beyond the standard migration steps, WooCommerce stores need a few specific verifications:
Check payment webhooks โ confirm that Stripe and PayPal webhook endpoints point to the correct new domain. If the domain hasn't changed, these usually don't need updating, but verify the webhook status in each platform's dashboard. Run a test order through the full checkout flow and confirm that order confirmation emails are sending correctly and SMTP configuration is still working. If the domain changed, verify that the SSL certificate was issued for the new domain and all resources are loading over HTTPS with no Mixed Content warnings. Shipping rate and tax settings typically survive migration intact, but confirm they're displaying correctly.
Backup Frequency Reference
| Site Type | File Backup | Database Backup |
|---|---|---|
| Personal blog | Weekly | Weekly |
| Corporate website | Weekly | 2โ3 times per week |
| WooCommerce store | Weekly | Daily |
| High-volume store | Weekly | Multiple times daily |
Files change far less frequently than the database โ content updates go to the database, not the file system โ so setting different schedules for each reduces storage consumption without compromising data protection.