A backup is a copy of your data you can restore; disaster recovery is the plan that gets your business running again after a major problem. For a small business: back up the database at least daily, keep uploaded files, code (via GitHub) and domain settings, and hold one copy outside your main platform. Decide how much data you can afford to lose and how long you can be down, write a one-page plan, and actually test a restore every quarter.
- how to back up my website or online store
- disaster recovery plan for small business
- how often should i back up my app data
- how to restore deleted data in my app
- backup vs rollback
What is the difference between backups and disaster recovery?
A backup means you have a copy of your data stored safely that can be restored. Disaster recovery is the full plan that gets your business running after a major problem: who does what, in what order, and within how many hours. A backup is part of the plan, but on its own it is not enough if you do not know how to use it under pressure.
When a small business owner hears disaster, they picture a fire in a data center. Most incidents are simpler and closer to home: an employee deletes the product list by mistake, a new change breaks pricing on White Friday night, a hacked email account leads to changed domain settings, or a third-party provider suddenly goes down. A good plan gets you back in business in all of these cases.
Two numbers that shape your plan
- How much data can you afford to lose? (Specialists call it RPO.) With daily backups, you could lose a full day of orders in the worst case. Is that acceptable for your store?
- How long can you be down? (RTO.) An hour? Half a day? A clinic without its booking system on Sunday morning is different from a blog offline for a day.
A backup you have never restored is not a backup; it is a wish.
What to back up: more than the database
Many people stop at the database and discover during an incident that product photos, domain settings or gateway access were never saved. Here are the assets your business needs to come back:
| Asset | Where it usually lives | How often | Note |
|---|---|---|---|
| Database (orders, customers, bookings) | The platform or hosting provider | At least daily, more for busy stores | The most important by far |
| Uploaded files (images, invoices, documents) | File storage | Daily or on every upload | Often forgotten |
| Code | GitHub or the platform | On every change | Turn on GitHub sync |
| Domain and DNS settings | Your registrar | On every change | A screenshot or file of current records |
| Payment and messaging settings | Provider dashboards | On every change | Who has access? Where are the keys? |
| Invoices and accounting records | Accounting system or the app | Monthly export | May need to be kept for long periods |
| Accounts and access list | A password manager | On every change | Without it, no backup is usable |
The 3-2-1 rule, adapted for a small business
The classic rule says: three copies of your data, on two different types of storage, with one copy somewhere separate. For a small business on a cloud platform, it translates like this:
- The live copy: your data in the database while you operate.
- The platform's automatic backups: daily snapshots kept for several days, plus the ability to roll back a bad deploy.
- An external copy you own: a regular export (weekly, for example) of orders, customers and products to separate storage you control, with your code on GitHub.
Protect the external copy as you protect the original: encryption, access limited to the owner, and two-factor login on the account that holds it. An exposed backup is worse than none.
How often should you back up? It depends on your business
| Business type | Acceptable data loss | Acceptable downtime | Practical suggestion |
|---|---|---|---|
| Busy online store in peak season | Minutes to an hour | Under an hour | Frequent backups during the day, a change freeze before the season, a ready rollback plan |
| Clinic or salon with bookings | A few hours | Before the next opening | Daily backups, and print tomorrow's schedule every evening as a fallback |
| Internal tool for a small team | One day | One working day | Daily backups and a weekly export |
| Brochure site or landing page | One week | One day | Code on GitHub is usually enough |
Seasons change the math. An hour of downtime on the 27th night of Ramadan, on White Friday or two days before Eid costs far more than an hour on an ordinary day. Plan backups and rollback for the worst day of your year, not an average one.
Write a one-page recovery plan
You do not need a fifty-page document. You need one page that anyone on your team can read under pressure and know what to do:
- 1List the scenarios
Accidental deletion, a bad deploy, a hacked account, a payment or messaging provider outage, a hosting outage.
- 2Name an owner for each
A person and their phone number, plus a backup person if they do not answer.
- 3Define the first action
Bad deploy: roll back to the previous version. Deleted data: pause changes, then restore. Hack: change passwords and revoke keys.
- 4Say where backups are and how to restore
Where each copy lives, who has access, and the restore steps in plain words.
- 5Prepare customer messages
A ready message in Arabic and English for WhatsApp and social media, and a simple status page if possible.
- 6Review afterwards
What happened, why, and what you will change so it does not repeat. If personal data leaked, review notification obligations with the relevant authority.
Test a restore before you need one
The worst time to discover a backup is incomplete, or nobody knows the password, is during the incident itself. Make a restore test a fixed appointment every three months:
- Restore yesterday's backup to a separate test environment, never over production data.
- Check that orders, customers and images are there and match what you expect.
- Time the restore and compare it with your acceptable downtime.
- Try rolling back a deploy in the test environment and note how many minutes it takes.
- Update your one-page plan with any missing step you discovered.
How Fanann helps with backups and recovery
Apps built on Fanann run on in-region hosting with daily backups, instant rollback of any deploy, and code you can sync to GitHub or export whenever you like. That covers the first two copies of the 3-2-1 rule. What remains with you: the external data copy, the one-page plan and the restore test. For uptime monitoring and outage alerts, read uptime, monitoring and SLAs.
Add a Backups page to the admin panel, visible only to the owner. It should have a button to export orders, customers, products and bookings as CSV files with images in a zip file, an automatic weekly export every Sunday at dawn that emails the owner a temporary download link, and a log showing the date of each export and who requested it. Never include card numbers in any export. Also add a simple public status page in Arabic and English that I can update with a short message during an outage.
Try it in FanannKey takeaways
- Backups protect you from human error far more often than from big disasters.
- Set two numbers: how many hours of data you can lose and how many hours of downtime you can bear.
- Back up more than the database: files, code, domain settings and access to your services.
- Keep at least one copy outside your main platform, respecting where data is allowed to live.
- A backup you have never restored is a hope; test every quarter.
Frequently asked questions
How do I back up my website or online store?
How often should I back up my app data?
How do I restore data I deleted by mistake?
Can I keep backups outside Saudi Arabia or the UAE?
What is the difference between a backup and a rollback?
Ask your AI assistant about this
Copy this prompt into the AI assistant you use, then add the details of your own case.
I am reading this guide: “Backups and disaster recovery for small businesses” https://fanann.com/en/blog/backups-disaster-recovery/ My question: how to back up my website or online store Use that page as a source and explain the answer step by step for my situation, tell me what to check before I start, and cite the page link.