Website Backup Recovery for a Small Business Site

Website backup recovery is a restore you have actually performed, not a backup you have actually taken. Most small businesses in Dubai have the second and not the first, and they find out the difference on the morning the site is gone. The work below closes that gap: what has to be inside the copy, how recent it needs to be, where the copies live, how long you keep them, and the rehearsal that proves any of it works.

Every figure here comes from the documentation that governs the piece it describes. NIST defines the two recovery targets. The WordPress and WooCommerce handbooks define what actually sits inside a site. Google’s crawling documentation says what an outage costs you in search. UAE federal law sets how long some of that data has to survive, and it is longer than any hosting plan keeps it.

Key takeaways

• A website is two separate things, the files and the database, and a copy of only one restores nothing.
• Set a recovery point objective and a recovery time objective in hours before choosing a tool. NIST SP 800-34 Rev. 1 defines the first as the point in time data must be recovered to, and the second as how long recovery can run before the business is damaged.
• WordPress guidance is 3 to 5 recent copies kept in different places, which rules out holding every copy inside the hosting account.
• A WooCommerce store running High-Performance Order Storage keeps orders in four custom database tables, so a files-only backup loses every order.
• Article 56 of Federal Decree-Law No. 47 of 2022 requires records supporting a tax return to be kept for seven years after the tax period, which outlasts any hosting plan’s backup window.
• Serve a 503 while you restore. Google slows crawling on server errors and drops URLs that keep returning them.

What has to be in the copy before it counts

The WordPress administration handbook is blunt about this: “There are two parts to backing up your WordPress site: Database and Files. You need both to be able to fully restore a typical WordPress site.” The files are the WordPress core, the theme, the plugins, the uploads folder, wp-config.php and .htaccess. The database is a separate MySQL or MariaDB system that the file backup does not touch.

That split catches people out because the two change at different speeds. On a law firm site in DIFC the files might not change for three months while the database collects a contact form entry every afternoon.

The sharpest version of the problem is WooCommerce. Since version 8.2, released in October 2023, High-Performance Order Storage is the default for new installations, and it puts orders into four custom tables: wc_orders, wc_order_addresses, wc_order_operational_data and wc_orders_meta. A backup plugin configured to copy the wp-content directory and nothing else will produce a file that looks healthy, weighs several gigabytes, and contains not one order.

One issue we often see on lead generation sites is the opposite assumption: the owner believes enquiries are safe because they arrive by email. Some contact form plugins only send mail and store nothing, others write every submission into the database. Check which one you have before deciding the database matters less than the uploads folder.

Decide how much data you can afford to lose

NIST SP 800-34 Rev. 1 defines a recovery point objective as “the point in time to which data must be recovered after an outage”. In plain terms it is the size of the hole you are willing to live with. A nightly backup at 02:00 and a failure at 17:00 is a fifteen hour hole.

Do the arithmetic with your own numbers rather than accepting a plugin default. A recruitment firm in Business Bay taking twelve enquiries on a working day loses roughly eleven of them in that fifteen hour window, with no record of who they were. A trading company in Deira raising thirty invoices a week loses at most a day of entries, which is irritating but reconstructable from the bank statement. Same backup schedule, two very different consequences.

This is the point where the files and the database should stop sharing a schedule. There is no reason to copy four gigabytes of product images every hour when they last changed in March. There is every reason to copy a database that is collecting orders. Hourly database snapshots with weekly file snapshots is a normal, cheap arrangement, and it is far better than one nightly job that is too heavy to run more often.

Decide how long you can afford to be down

The companion target, the recovery time objective, is “the overall length of time an information system’s components can be in the recovery phase before negatively impacting the organization’s mission or mission/business processes”. Small businesses almost always underestimate it, because they time the restore and forget everything around it.

Count the whole sequence. Someone has to notice. If you have uptime monitoring that is five minutes; if you are relying on a customer to phone, the site can be down from Friday evening until Sunday morning. Someone has to decide what broke, because restoring over a live hack reinstates the hack. Then you find the backup, restore it, check it, and wait for DNS or the edge cache to catch up. The restore itself is often the shortest part.

Write the target down as a number. Four hours is achievable for most small sites with a credible host and a recent copy; fifteen minutes is a different budget and a different architecture. Decide it on a calm day, not while a client waits.

Three copies, and why a host snapshot is not three of them

The WordPress handbook recommends keeping “at least 3 to 5 recent WordPress backups”, with copies in different locations: one on the hosting server, one in cloud storage, one downloaded to a local machine. The reasoning matters more than the number. Copies that share a failure share a fate.

A hosting snapshot sits inside the hosting account. If that account is suspended for a missed renewal, compromised by stolen credentials, or deleted by someone cleaning up what they thought was a staging site, the backups go with the site. We have seen all three. A copy you can download and open on a laptop in your Dubai office survives that class of event, and it is the one nobody remembers to take.

Two practical details. Do not keep backup archives inside wp-content, because they are then served over the web and included in the next backup of themselves. And if you hold patient records or financial data, confirm the storage region with your own adviser before picking a provider, not with the provider’s marketing page. Your hosting setup decides most of this by default.

How long to keep a copy, and the rule that outlasts your plan

Backup rotation and record retention are two different jobs, and small businesses in the UAE routinely solve the first and assume it covered the second. Article 56 of Federal Decree-Law No. 47 of 2022 on the taxation of corporations and businesses requires a taxable person to “maintain all records and documents for a period of (7) seven years following the end of the Tax Period to which they relate” where those records support the information in a tax return or let the authority establish taxable income.

If your website is the system that issued the invoice, that sentence reaches into your database. An online store’s order table is part of the evidence for revenue. Most shared hosting plans keep a rolling window of recent snapshots and overwrite the oldest, so check the exact number of days in your own plan’s terms rather than assuming it is generous. Nothing in that window is designed to still exist in 2033.

The fix takes an hour. Export orders, invoices and customer records to a separate archive on a schedule, keep that archive outside the rotation that overwrites itself, and store it where your accountant can reach it. For a WooCommerce store that can be a scheduled CSV export.

The restore test almost nobody runs

A backup that has never been restored is an untested assumption with a file size. The rehearsal is simple: once a quarter, restore the most recent copy onto a staging environment, click through the five pages that matter, and write down how long it took and what broke. Thirty minutes, four times a year.

From doing this on client sites, the same handful of things break:

• The siteurl and home values in the options table still point at the old address. The WordPress migration documentation notes these are stored as option names in the database, and a restore to a different host brings them along unchanged.
• The same documentation flags wp-config.php: if the database moved, was renamed, or has a different user, the file has to be edited before anything loads.
• The recovery server runs a different PHP version from the one the site was built against, and a plugin throws a fatal error on a page nobody checked.
• File ownership and permissions after extracting an archive leave uploads unwritable, so the site loads but no image can be added.
• The database user exists but has no privileges on the restored database, which produces a connection error that reads like the backup is corrupt when it is not.
• The archive turns out to exclude the uploads directory, because it was excluded eighteen months ago to keep the file small and nobody revisited it.

Keep the result in a one page document with the date, the person, the elapsed time and the failures. That document is what turns a panic into a procedure, and it is usually part of what a maintenance retainer should be paying for.

Keep search out of it while you restore

What the site returns during an outage changes what it costs. Google’s documentation on HTTP and network errors states that 5xx responses prompt its crawlers to slow down, that “the decrease in crawl rate is proportionate to the number of individual URLs that are returning a server error”, and that the indexing pipeline “removes from the index URLs that persistently return a server error”.

That is reassuring for short outages and unforgiving for long ones. A two hour restore behind a 503 Service Unavailable is close to a non-event. A site left for three days returning 404s, or worse a friendly “back soon” page with a 200 status, teaches Google those URLs are fine and empty. Add a Retry-After header, which RFC 9110 defines as telling the client “how long the user agent ought to wait before making a follow-up request”.

Agree this with whoever hosts the site before you need it. On a WordPress site it is a maintenance mode setting; on a custom application it is a line in the server configuration. Two minutes on a calm day, unfindable on a bad one.

What this looks like for three Dubai businesses

These are the arrangements we would usually recommend by site type, not measurements of any particular client.

Two rules cut across all three. Copies live in at least two places that cannot fail together, and one restore is rehearsed every quarter. A business doing both with a basic plugin is in better shape than one paying for a tool it has never tested.

If you want your own backup arrangement reviewed rather than assumed, our team in Dubai can check what is actually being copied, how old the newest usable copy is, and how long a restore would really take. It is short work, and far cheaper before an incident than after one.

Retention periods and tax obligations in this article are indicative, depend on your own registration and financial year, and are not legal, tax or accounting advice; confirm your position with a qualified adviser. Sources read on 4 October 2026: NIST SP 800-34 Rev. 1 via the NIST Computer Security Resource Center glossary; WordPress advanced administration handbook; WooCommerce High-Performance Order Storage documentation; Google Search Central documentation on HTTP and network errors; RFC 9110; UAE Ministry of Finance, Federal Decree-Law No. 47 of 2022, Article 56. Cover photo: Dubai, view from the Burj Khalifa over Financial Centre Road and Business Bay, by Edgar El, via Wikimedia Commons (CC BY 3.0).