Keep a Fujairah business website resilient:backups, restores and outages

A resilient website for a Fujairah business is one that can survive a bad plugin update, a deleted page, a hacked account or a server outage and be back online quickly. You get there with five habits: keep backups using the 3-2-1 idea, send copies off the server automatically, actually test a restore, monitor uptime so you hear about problems first, and prepare the extras that soften an outage, such as a CDN, a proper maintenance page and sensible DNS settings. Write it all into a one-page outage playbook.

A made-up story that plays out somewhere every week. A dive centre in Fujairah updates a plugin on a Thursday evening at the start of the busy season. The site shows a blank white page. The host keeps backups, but nobody at the centre has ever restored one, the developer is travelling, and the booking enquiries quietly stop for two days. The backup was never the problem. Nobody had practised using it.

By the end of this guide you will have automatic off-site backups, a tested restore process, uptime alerts, an outage-friendly CDN setup, a correct maintenance page, DNS settings that let you recover fast, and a printed playbook your team can follow.

What resilience actually means

Think of a car's spare tyre. Having one is good. Having one that is inflated, a jack that works, and knowing how to change the tyre is what actually gets you home. For a website, backups are the spare tyre, the restore test is the practice, monitoring is the warning light on the dashboard, and the playbook is the instructions in the glovebox.

A resilient site is not one that never fails. It is one that fails gracefully and recovers quickly.

Before you start

• WordPress administrator access and your hosting control panel login.
• A cloud storage account for off-site backups, such as Google Drive, Dropbox or an S3-compatible service, ideally owned by the business.
• Two-factor authentication switched on for that storage account, because it will hold a complete copy of your site.
• A free afternoon, plus about an hour every three months for restore tests.

Part 1: Plan backups with the 3-2-1 idea

The 3-2-1 idea is a widely used rule of thumb for backups: keep three copies of your data, on two different types of storage, with one copy somewhere else entirely. For a small website, that can look like this:

• Copy 1: the live site on your hosting server.
• Copy 2: your host's own backups, if your plan includes them.
• Copy 3: an automatic backup sent to cloud storage that you control, plus a monthly download to a computer or external drive.

What needs backing up:

• Files: themes, plugins and especially uploads (images and documents).
• The database: posts, pages, settings, users, orders and form entries.
• Email, if your mailboxes live on the hosting account.
• A note of your DNS records, so you can rebuild them if needed.

How often depends on how often things change. A brochure site that changes monthly can back up weekly. A shop or booking site that takes orders daily should back up the database at least daily.

Part 2: Set up automatic off-site backups

Option A: UpdraftPlus to cloud storage

UpdraftPlus is a WordPress backup plugin with a free version. At the time of writing (3 October 2026), its WordPress.org page says it is used on more than 3 million websites and tested up to WordPress 7.1.2. The free version can schedule backups every 2, 4, 8 or 12 hours, daily, weekly, fortnightly or monthly, and send them to Dropbox, Google Drive, Amazon S3 or S3-compatible storage, FTP, email and a few other destinations. Automatic backups before updates and incremental backups are Premium features.

1. Install and activate UpdraftPlus from Plugins > Add New Plugin.
2. Open UpdraftPlus from the dashboard and go to its Settings tab.
3. Set the File backup schedule, for example weekly, and choose how many backups to keep.
4. Set the Database backup schedule, for example daily, and how many to keep.
5. Choose your remote storage, such as Google Drive, and follow the prompts to authorise it.
6. Save the changes.
7. Run the first backup manually from the plugin's backup tab, then check the files appear in your cloud storage.

Quick tip: keep at least a week of daily database backups and several weekly file backups, so you can go back to a point before a problem that went unnoticed for a few days.

Option B: a full cPanel backup to a remote server

cPanel can create a complete account backup, including files, databases and email. According to cPanel's documentation, go to cPanel > Files > Backup, click Download a Full Account Backup, and choose a Backup Destination. Choosing Remote FTP Server or Secure Copy (SCP) sends the backup off the server instead of leaving it in your home directory. Then click Generate Backup.

This is a manual job, so put a monthly reminder in your calendar. Many hosts also run their own scheduled backup tools for cPanel accounts; ask yours what is available on your plan and how far back you can restore.

Heads up: a backup contains everything, including customer data and the database password in wp-config.php. Protect the storage account with two-factor authentication and do not share its login.

Part 3: Test a restore

A backup you have never restored is a hope, not a plan. Test at two levels.

Level 1: check the backup looks complete (monthly, 10 minutes)

Open your cloud storage and check that the latest backup is from when you expect, and that its size is similar to last month's. A backup that is suddenly much smaller usually means something was skipped.

For a downloaded cPanel full backup, this command lists the first files inside the archive without extracting it (use your real file name):

tar -tzf backup-file.tar.gz | head -20

You should see your site's files and database files listed, not an error.

Level 2: a full restore to a staging copy (every three months, about an hour)

Restore the backup somewhere that is not your live site, then check it works:

1. Create a staging site on a subdomain such as staging.example.com, either with your host's staging tool or with a fresh WordPress install through Softaculous (our Softaculous install guide shows the steps).
2. Restore your backup into it. With UpdraftPlus, install the plugin on the staging site, add the backup files and restore them; the plugin's free version includes a search-and-replace step for migrating to a new address.
3. Block search engines and visitors from the staging copy, for example with password protection from your host.
4. Click through it: the homepage, a few inner pages, an image-heavy page, the contact form and the admin login.
5. Time the whole process. That number is your realistic recovery time.
6. Delete the staging copy when you are done, or keep it protected.

If you are comfortable with the command line, the same restore can be done with WP-CLI on the staging site. This imports a database dump:

wp db import example-backup.sql

Then this replaces the live address with the staging address throughout the database, leaving the guid column alone:

wp search-replace 'https://example.com' 'https://staging.example.com' --skip-columns=guid

Our WordPress migration guide covers moving a site in more detail.

Part 4: Set up uptime monitoring

You want to hear about an outage from a monitor, not from a customer.

UptimeRobot's free plan includes 50 monitors with a 5-minute check interval and email alerts, plus keyword, SSL expiry and domain expiry monitoring. Its pricing page describes the free plan as good for hobby and non-profit projects, so consider a paid plan or another service for a business. A sensible set of monitors:

• An HTTP monitor on your homepage, which alerts when the site stops responding.
• A keyword monitor on your most important page, such as the booking or contact page, which alerts if a phrase like "Send enquiry" disappears. This catches white screens and broken pages that still return a response.
• SSL and domain expiry monitoring, which warns you before a certificate or the domain itself lapses.

Send alerts to an address more than one person reads, so an alert is not missed when someone is on leave.

Part 5: Use caching and a CDN to absorb spikes

A sudden rush of visitors, from a holiday weekend or a social media post, can overload a small hosting plan. Caching lets the server answer most requests without rebuilding each page.

• Page caching on the server: a caching plugin such as LiteSpeed Cache on LiteSpeed hosting stores ready-made pages. Our LiteSpeed Cache guide covers the setup.
• A CDN in front of the site: Cloudflare's documentation says its CDN caches static files such as images, CSS and JavaScript by default, but does not cache HTML by default. You can cache HTML with Cache Rules, but Cloudflare warns to be careful, because HTML often contains personalised or dynamic content.
• Request collapsing: Cloudflare's documentation also explains that when many requests for the same uncached file arrive at once at one of its data centres, it forwards only the first to your server and serves the result to the rest.

Always Online: a safety net with limits

Cloudflare's Always Online feature, available on the free plan, can show visitors an archived copy of popular pages when your server is unreachable. Its documentation is clear about the limits:

• It only activates when Cloudflare cannot reach your server, not when your server is up but returning errors.
• It uses the Internet Archive, and turning it on shares your hostname and popular page addresses with the archive's crawler. On the free plan, pages are crawled every 30 days.
• Visitors see a banner saying they are viewing an archived version.
• Dynamic features such as carts and forms do not work while your server is offline.

To switch it on, go to the Caching > Configuration page for your domain in the Cloudflare dashboard and set Always Online to On.

Part 6: Use a proper maintenance page

When you take the site down on purpose, for a big update or a restore, show visitors a friendly message and tell search engines the outage is temporary. The HTTP standard, RFC 9110, defines the 503 (Service Unavailable) status for exactly this: the server is temporarily unable to handle requests because of overload or scheduled maintenance. It also says the server may send a Retry-After header suggesting when to try again.

WordPress already shows a short maintenance message while core, plugin and theme updates run. For longer planned work, use a maintenance mode plugin that returns a 503 status, and check it from the command line while maintenance mode is on:

curl -sI https://example.com/ | head -5

The first line should show 503. If it shows 200, search engines are being told your maintenance page is the real content.

Part 7: Plan your DNS for fast recovery

If you ever need to move your site to a different server in a hurry, such as a standby server or a restored copy at another host, DNS decides how fast visitors follow.

Every DNS record has a TTL (time to live), the number of seconds other networks may cache it. This command shows your domain's records with their TTL in the second column:

dig +noall +answer example.com

• Keep a moderate TTL on the records you might change in an emergency, such as an hour, rather than a day.
• Lower the TTL a day or two before planned moves, then raise it again afterwards.
• Remember the limits: changing nameservers at your registrar follows the registry's own timing, which your TTL does not control. Our DNS propagation guide explains what you can and cannot speed up.
• Keep the domain on auto-renew, with a payment card that will not expire unnoticed, and let your monitor warn you before expiry.

Your outage playbook

Print this, fill in the blanks for your business, and keep it with your logins.

1. Confirm the outage. Check your uptime monitor and open the site on mobile data. Our UAE hosting pillar guide shows how to test from Dubai with Globalping if you are elsewhere.
2. Check your host's status page and open a support ticket if the server is down.
3. Check the basics: has the domain expired, has the SSL certificate lapsed, has DNS changed?
4. Ask what changed recently. If a plugin, theme or setting changed just before the outage, undo it or restore the last good backup.
5. Tell customers. Post a short update on your social channels and keep answering on WhatsApp or phone.
6. Restore if needed, using the process you practised in Part 3.
7. Review afterwards. Write down the cause, the fix, how long it took, and one thing to change.

Full disclosure: Hostlelo runs this blog. If you host with Hostlelo, its server status page is at panel.hostlelo.com/serverstatus.php and tickets go through its client area.

How to check your resilience setup

• Backups: the newest backup in your cloud storage is from the last scheduled run.
• Restore: you completed a staging restore in the last three months and know how long it took.
• Monitoring: pausing and resuming a monitor, or changing its keyword, produces an alert email.
• CDN: response headers for an image include Cloudflare's cf-cache-status header after a couple of requests, if you use Cloudflare.
• Maintenance page: curl -sI returns 503 while maintenance mode is on.
• DNS: dig +noall +answer example.com shows the TTL you planned.

Troubleshooting

Backups stop or time out on a large site

Large uploads folders can exceed time or size limits. Back up files less often than the database, exclude folders you do not need (such as old cache folders), or ask your host whether a server-side backup tool suits your site better.

Backups stopped reaching cloud storage

The connection to the storage account has usually expired or lost permission. Re-authorise the remote storage in the backup plugin's settings and run a manual backup to confirm.

The restored staging site loads the live site or shows broken links

Old addresses are still in the database. Run the search-and-replace step for the staging address, then clear any caches.

The site is stuck on "Briefly unavailable for scheduled maintenance"

An update was interrupted. Delete the .maintenance file in the WordPress root folder using your host's file manager, then re-run the update.

Cloudflare shows a 52x error page

Cloudflare's documentation says errors in the 520 to 527 range mean it cannot reach your origin server properly. Check your host's status and your server, because the problem is behind Cloudflare, not in it.

The uptime monitor alerts but the site looks fine

Check from mobile data as well as office Wi-Fi, and check whether the keyword on the page changed. Adjust the keyword monitor if you edited that text.

The one message worth forwarding

Send this to whoever manages your website:

"Please set up daily database and weekly file backups to our own cloud storage, run a full restore test to a protected staging site every three months and tell us how long it takes, add uptime, keyword, SSL and domain-expiry monitoring with alerts to a shared inbox, make sure maintenance mode returns a 503, keep our DNS TTL moderate, and fill in our outage playbook with names and numbers."

The takeaway: a Fujairah business site stays dependable when backups leave the server automatically, restores are practised, monitors raise the alarm first, and everyone knows the playbook before the bad day arrives.