If your store broke after a theme or plugin update, check whether a web-files-only restore will fix it. On Cloudways Flexible, that option keeps your current order database. If you need to restore the database too, pause sales and save every order created or changed since the backup. Youâll need those records to bring the store up to date.
If you found this guide while searching for âmanaged cloud hosting Philadelphia,â check which Cloudways product your store uses. The steps below cover Flexible.
Some links on this page are affiliate links. If you buy through one, I may earn a small commission. Your price stays the same.
| Cloudways Flexible restore option | What goes back to the backup time? | What happens to recent orders? |
|---|---|---|
| Web Files | The appâs web files | The current order database stays in place. Check that the restored code still works with it. |
| Database | The appâs database | New orders and recent changes to older orders can disappear from the store. |
| Complete Restore | Both web files and the database | The same order risk applies. Save a current copy before you start. |
1. Will restoring a Cloudways backup erase my recent WooCommerce orders?
Yes, if you restore a database from before those orders arrived. The backup holds the storeâs state at a point in time. WooCommerce wonât add the later sales back for you.
The risk goes beyond missing order numbers. An order can still be there with the wrong status. A customer who already received a refund might appear to have paid in full.
Understand what Cloudways backs up and what you are restoring
On Cloudways Flexible, scheduled backups run at the server level. You can also take an on-demand backup of one application [one site hosted on your server]. That backup includes the appâs database and web files.
Check the target before you act. An application restore affects the app you select. A whole-server recovery can roll back several sites to the same time. If one shop has a broken theme, start with that shopâs restore options.
Draw the order window before choosing a restore point
Say your backup is from 10:00 UTC [a shared global time standard]. A shopper buys a shirt at 10:15. At 10:20, you refund a sale from yesterday. You close checkout at 10:30.
Restoring the 10:00 database puts both changes at risk. An export filtered by order creation time will catch the shirt sale. It can miss the refund because you created that order yesterday. Write down the restore time and the time store activity stopped. Use both when you gather records.
Match the instructions to the Cloudways product
The table above covers Flexible. If you use Autonomous, check which choices your restore screen offers before you proceed. Cloudwaysâ published instructions conflict on whether that product supports partial restores. Ask support to confirm the scope if the screen is unclear.
Unsure which service you use? Compare Cloudways Flexible and Autonomous before choosing a restore method.
Velocity also has its own backup and restore workflow. Whichever product you use, read the last confirmation screen. If it includes Database, preserve your recent orders first.
2. The staging experiment: place an order after the backup, then restore
A staging store is a private copy where you can test a fix. This experiment follows one sale across four places: your store, your payment provider, your stock records, and your inbox.
The test results below are open. Fill them in from your own run. That gives you a record for your store, gateway, and plugins.
Step 1. Prepare a staging store where the test cannot reach customers
Check the app name and address. Sign in to staging and make sure you can tell it apart from the live shop at a glance.
Before placing an order, set up these checks:
- Switch the payment gateway [service that handles payments] to its sandbox [test mode]. Check that staging uses test keys.
- Send all store emails to a test inbox. Use a made-up customer and an email address you control.
- Disconnect live shipping, warehouse, and marketing tools. Point each test webhook [a message sent between apps] to a test receiver.
- Pick one product with stock tracking turned on. Record its SKU [stock code], variation, and exact stock count.
- Note one existing order number. Youâll use it to check that you restored the right store.
For a broader look at staging tools, see our WordPress hosting comparison.
Record your WooCommerce version and order storage setting. If High-Performance Order Storage is active, WooCommerce uses dedicated order tables [database lists that hold order data]. This matters if you later need help recovering records.
Step 2. Back up staging and record the restore point
Open the staging app in Cloudways Flexible. Go to Backup and Restore and take an on-demand backup. Wait for it to finish, then check that its time appears among the available restore points.
Save a screenshot with the app name and UTC time in view. Take a second screenshot of the productâs stock count. Keep both outside the staging site so you can still see them after the restore.
Step 3. Place one traceable order after the backup
Open staging in a private browser window. Buy one unit of the test product and create a customer account during checkout. Use your gatewayâs test payment method.
Write down the order number and the gatewayâs transaction reference. Open the order in WooCommerce and record its status, notes, total, and customer link. Then check the SKU again. Enter the stock count you see, even if it hasnât changed.
Open the test inbox and gateway dashboard. Save the emails that arrived and the payment state shown there. If you sent a webhook, record its event ID and the response from the receiving app.
Step 4. Restore the staging application to the earlier point
Go back to the staging appâs Backup and Restore screen. Select the UTC restore point from Step 2. Choose Restore Application Now, then Complete Restore. This test needs to include the database so you can see what a rollback means for an order.
Capture the app name, time, and scope before you confirm. Once Cloudways finishes, sign back in. Search for both order numbers, check the exact variation, and look up the test customer.
Step 5. Publish the before-and-after evidence
Use the same screens for each check. If the sample order seems to be missing, clear your order filters and look up the control order. If both are missing, confirm the app and restore point before drawing a conclusion.
| What you checked | Before backup | After checkout | After restore |
|---|---|---|---|
| Control order and sample order | [CONTROL ORDER] | [SAMPLE ID, STATUS, NOTES] | [INSERT STAGING RESULT] |
| Stock for the exact SKU | [QUANTITY] | [QUANTITY] | [INSERT STAGING RESULT] |
| Customer account, billing details, and order history | [BASELINE] | [ACCOUNT AND ORDER LINK] | [INSERT STAGING RESULT] |
| Payment in the gateway dashboard | [BASELINE] | [REFERENCE AND STATE] | [INSERT STAGING RESULT] |
| Customer and admin emails in the test inbox | [BASELINE] | [MESSAGES RECEIVED] | [INSERT STAGING RESULT] |
| Webhook at the test receiver | [BASELINE] | [EVENT AND RESPONSE] | [INSERT STAGING RESULT] |
[INSERT PAIRED STAGING SCREENSHOTS HERE. Use test details and hide keys and private links.]
Observed result: After restoring [SCOPE] to [UTC TIME], WooCommerce showed [INSERT STAGING RESULT]. The gateway showed [INSERT STAGING RESULT], and the test inbox contained [INSERT STAGING RESULT].
3. Pre-restore checklist for a live WooCommerce store
Before you restore the live shop, make sure you could answer one question for each recent sale: What did the customer buy, what did they pay, and what still needs to happen? A list of order numbers alone wonât tell you that.
Close checkout and account for writes still in flight
- Put the storefront in maintenance mode. Open a private window and confirm a shopper canât complete checkout.
- Tell staff when to stop editing orders. Note the time in UTC.
- Check for payments already in progress, scheduled renewals, marketplace orders, and warehouse updates. These can reach the store after checkout closes.
- Record pending events and who will check them. If you pause a connection, confirm how youâll retrieve missed events or resume delivery.
A maintenance page can also block a gateway callback [the payment providerâs update to your store]. Watch the gateway dashboard during the pause. Record any payment that clears after your first export.
Export both new orders and changes to older orders
- Export orders created or changed since the chosen backup. If your tool filters only by creation date, check refund, status, and fulfillment logs separately.
- Include item quantities, SKUs, variations, discounts, shipping, tax, currency, and totals.
- Keep customer links, addresses, transaction references, refund records, order notes, and tracking details.
- Check fields added by plugins. A subscription may need its next renewal date. A booking may need its reserved time slot.
Open the export and read one order from start to finish. Could you tell which size shirt to ship and whether the buyer already paid? If a field is missing, get it while you can still open the order.
Take a fresh backup and verify independent records
- Take a fresh backup of the current live app. Wait for it to finish. Label its UTC time separately from the older point you intend to restore.
- Keep the export in a secure place outside the site. Limit access because it contains customer details.
- Compare WooCommerce records with the gateway and warehouse. Mark pending payments, captures [completed charges], refunds, and shipments.
- Make one last check for activity since the export. Save those changes too.
If you canât read the export or account for a confirmed payment, keep checkout closed while you resolve the gap. The live database may still hold the detail you need.
4. Choose how to preserve or recover recent orders
Use the smallest restore that fixes the fault. Your choice depends on what broke, how much current data you still have, and whether anyone placed orders after an earlier recovery attempt.
| Your situation | What to do | What to check |
|---|---|---|
| A theme or plugin file broke the store | Try a web-files-only restore on staging. | Test checkout with the restored code and the current database. A plugin update may also have changed the database. |
| You must roll back the database | Restore the older point on an isolated copy. Import the missing changes there first. | Match new orders, changes to older orders, refunds, customer links, and stock. |
| You already restored the wrong backup | Save the current state. Look for a newer backup or the Flexible rollback option. | Preserve sales from both sides of the mistaken restore before another rollback. |
| You have no usable newer backup | Rebuild individual orders from verified gateway, inbox, and warehouse records. | Match each payment once. Leave unknown items or addresses open until you can verify them. |
On Flexible, Cloudways offers a temporary rollback after an application restore. It reverses the scope of the last restore, and its backup is removed after 24 hours. Check promptly. If checkout has reopened, save the new activity before using it.
Rehearse the import with representative orders
Try a guest purchase, a customer account, a product variation, and a refunded order. Use the same import tool and settings you plan to use on the live site. A successful import message tells you the tool ran. Open the records to see what it did.
Check how your tool matches orders. For example, WooCommerceâs Customer / Coupon / Order CSV Import Suite checks order ID and then order number when merging. If an ID now belongs to another sale, a merge can change the wrong order. Verify the customer, transaction reference, and items first.
Load any customer records the orders depend on. Check that each SKU points to the right product or variation. If you sell subscriptions or bookings, test an actual renewal or booking record from the affected period.
Check what the recovery process might trigger a second time
A restored order can reach more than your order list. Watch for another stock deduction, receipt, warehouse request, or payment action. Keep external actions isolated during rehearsal and check the receiving systems.
On live recovery, record which actions already happened. If a paid order needs rebuilding, enter its existing payment reference. Donât run the buyerâs payment again. If the warehouse shipped it, preserve that state before you resume fulfillment.
5. Verify checkout before reopening the store
Use two checks. First, trace a recovered order that someone already paid for. Then place a fresh order to make sure a new shopper can get through checkout.
Trace one recovered order across systems
Start with the gateway reference. Match the orderâs currency, amount, tax, shipping, customer, and items. Check its place in the customerâs order history and its state at the warehouse.
Now inspect an older order that changed during the recovery window. A good choice is a refunded order. Confirm the refund in both systems without issuing it again. When you compare totals, group them by currency and payment state.
Run one controlled checkout from payment to email
- Buy one known SKU using a test method suited to your environment. Record the starting stock count.
- Check the order confirmation and gateway result. Match their amount and transaction reference.
- Confirm that the gatewayâs update reached WooCommerce. Check the order notes and the status your payment method should produce.
- Check the exact SKUâs stock. Follow the order through its next expected status and watch for a second deduction.
- Open the customer and admin inboxes. Check the recipient, order number, and total in each expected message.
Write down which checks ran on staging and which ran on production. If you use test mode on the closed live store, restore the intended live settings and verify the gateway connection before admitting shoppers.
Reopen and monitor the first real orders
Resume paused jobs and integrations in a known order. Check their pending work before releasing it, especially if staff handled shipments by hand during the outage.
Assign one person to watch the first live sales. Have them match each payment to one store order and one fulfillment request. Keep the recovery records until youâve cleared any gaps.
6. Common restore mistakes and troubleshooting
Start with the system that owns the fact you need. The gateway can tell you whether money moved. The warehouse can tell you whether a parcel left. An order screen alone canât settle either question after a rollback.
âThe gateway shows a payment, but the order is missingâ
Look up the transaction reference, timestamp, amount, and currency. Check whether the gateway shows an authorization [a hold on funds], a completed charge, or a refund. Then compare that time with your restore point.
Search your recent export and check callback delivery. If you find the paid order, recover it with its original payment reference. If the gateway shows only a hold, verify its current state before marking the order paid or asking the buyer to try again.
âThe order is back, but stock, emails, or fulfillment are wrongâ
For stock, check the exact variation. Compare its saved quantity with sales, returns, and warehouse records since the backup. A second manual deduction can make an accurate count wrong.
For email, check the sending log and test inbox where available. For shipping, look up the order at the warehouse before replaying a webhook. A failed response in WooCommerce can leave you unsure whether the receiver already acted.
âThe import finished, but orders are missing or linked to the wrong customerâ
Check your UTC cutoff, order status filters, and guest purchases. Then review the import toolâs match rules. An existing order number or reused ID may have sent an update to the wrong record.
If a developer is recovering data directly, confirm which storage mode is active. A copy of the WordPress posts tables can miss orders held in HPOS tables. Check the affected orders through WooCommerce and compare them with the export before changing more data.
7. What should you budget for Cloudways backups and staging?
Point readers to the pricing guide
For backup and staging costs, see our Cloudways pricing breakdown.
8. Frequently asked questions
Can I restore a WooCommerce plugin or theme without rolling back orders?
Yes, if restoring web files fixes the fault. Flexibleâs Web Files option restores the appâs backed-up web files, so its scope extends beyond a single plugin or theme. Check for other file edits or uploads you need to preserve.
Try the restore on staging first. Open a recent order and place a new one. If the older plugin expects a different database structure, investigate that mismatch before restoring the live app.
Is an order CSV enough to recover everything?
Only if the export contains what you need and the importer can restore it. A spreadsheet may show the right order total yet lack the refund reference, customer link, or booking date.
Pick a complex order and check those fields after a trial import. If a plugin stores related records separately, use a recovery method that handles them too.
Does restoring the store reverse a payment or recall an email?
Restoring WooCommerce does not itself undo a completed charge at your payment provider. It also canât recall a message already delivered to someoneâs inbox. The storeâs own payment notes or email logs can roll back with its database.
Staging evidence: [INSERT VERIFIED GATEWAY AND INBOX RESULT]. For a live sale, check the gateway before issuing a refund. Check prior delivery before sending another receipt.
What if I already restored yesterdayâs backup and new orders are coming in?
Close checkout and save the database you have now. Export the sales placed after the mistaken restore. Those orders may exist only in the current store.
Next, locate the last copy from before the mistaken restore. Compare both sets on an isolated copy, using transaction references as well as order numbers. Reopen once you can account for both sets and verify a fresh checkout.
9. Conclusion: rehearse one order before restoring the live store
Give the reader one concrete next step
If your search for âmanaged cloud hosting Philadelphiaâ has turned into an urgent store repair, start with one small task. Write down the UTC time of the backup you plan to use. Find the first sale or order change after it. Thatâs the first record your recovery plan needs to protect.
Staging finding: [INSERT VERIFIED ONE-SENTENCE RESULT]. Before touching the live database, run the one-order test on staging and fill in the table. Youâll have a concrete record of what your restore changes and what you need to put back.