Many business owners assume their website or web platform is well protected because their hosting provider has a checkbox somewhere for "daily backups." Only when an update fails, a database gets corrupted, or a server physically goes down does it become clear what that checkbox is actually worth. A backup on paper is no guarantee. A backup is only functional once you've successfully run the restore process at least once.
Infrastructure and reliability largely determine your clients' trust. Recent research from Search Engine Journal showed, for example, that alternative domain extensions such as .org sometimes generate up to 34 percent more e-commerce revenue than traditional .com domains. The explanation behind this is logical: visitors unconsciously opt for demonstrable reliability and authority. The same logic applies to the technical back end of your platform. If your system is unreachable or loses client data, that built-up trust disappears instantly.
In this article, we compare two concrete approaches to backups for SME websites and web applications: the built-in hosting backup versus the isolated off-site backup structure. At the end, you'll find a clear decision guide to determine which option fits your business's risk profile.
Why a backup strategy is more than a daily copy
Setting up a backup environment isn't just about whether a copy of your files exists. It comes down to two crucial factors from the IT world: recovery time (Recovery Time Objective, or RTO) and acceptable data loss (Recovery Point Objective, or RPO).
Recovery time determines how long your platform may be offline after something serious goes wrong. Is that ten minutes, two hours, or three business days? Acceptable data loss determines how much data you're allowed to lose. If you make a backup at midnight and the system crashes at eleven at night, you lose 23 hours' worth of new client orders, quotes, or account creations. For a simple brochure website that's manageable, but for a custom web app or online store with continuous transactions, that's unacceptable.
Moreover, problems rarely arise from a total server crash alone. Far more often, it's human error, a faulty database migration, corrupted media files, or an unnoticed injection of malicious code that's already been sitting in your system for weeks. If your backup strategy consists solely of overwriting yesterday with today, at some point you'll also be backing up the corrupted data or the malware.
Option 1: The built-in hosting or plugin backup
The first option is the approach most commonly found at SMEs. This is the backup facility that comes standard with a hosting package or runs via an automated plugin in a CMS. The hosting provider, for example, takes a snapshot of the server every night, or a script on the server packages up the database and files and stores them in a specific folder on the same disk.
How this option works
In practice, this method works entirely in the background. You set it up via a control panel so the system makes a backup every night at 2:00 AM. These files are usually kept for seven to thirty days on the provider's server. With a single click, you can restore a previous state in the hosting dashboard.
The advantages
- Low barrier to entry: It takes almost no time to set up and requires no in-depth technical knowledge of infrastructure.
- No extra infrastructure costs: Storage is usually included in your hosting package's monthly price.
- Fast recovery from minor mistakes: If you accidentally delete a file or change the wrong setting, you can quickly restore it via the hosting interface.
The disadvantages
- Single point of failure: If the physical server goes down, the data center suffers a major outage, or your hosting account gets blocked, you can no longer reach your backups either.
- Capacity issues with large databases: Plugins or generic scripts running on the live server consume memory and processing power. With larger databases or lots of media, these processes often time out and get stuck.
- No point-in-time recovery: You can only go back to the exact moment of the snapshot. Anything that happens between two snapshots is permanently gone.
- No automatic verification: There's no check on whether the backup file created is actually complete and usable.
Option 2: Isolated off-site backups with point-in-time recovery
The second option fully separates the recovery mechanism from the live environment. Here, data is exported continuously or at fixed intervals to an independent, secured cloud infrastructure. This is the standard for custom platforms built with modern stacks such as React, TypeScript, and Supabase.
How this option works
With this approach, the database isn't simply copied once a day. Using techniques such as write-ahead logging (WAL) or automated database dumps, changes are recorded continuously. The backup files and media files are sent, encrypted, directly to a physically separate object storage location, such as Supabase Storage or a dedicated AWS S3 bucket in a different data center.
The recovery process is independent of your hosting provider. Should the entire server provider go under, the application can be rebuilt within a short time on a new server using the standalone code repository and the external data storage.
The advantages
- Maximum isolation: A problem on the application server has no effect whatsoever on the safety of the backup data.
- Point-in-time recovery (PITR): You can restore the database to a specific minute before the error or crash occurred. This limits data loss to an absolute minimum.
- No load on the live server: Storage and processing happen externally, guaranteeing the speed of the live website or application.
- Vendor independence: You're not locked into one specific hosting provider. You always retain full control over your own data.
The disadvantages
- Higher setup costs: This requires custom work and correctly configured infrastructure from an experienced developer.
- Separate cloud costs: There are small, recurring costs associated with external storage space and data transfer.
- Maintenance required: The storage and recovery scripts need to be checked and tested periodically.
What actually goes wrong without a well-thought-out plan
In practice, we regularly see where things go wrong for businesses that thought their backup was well arranged. The three scenarios below show how a flawed strategy plays out during an incident.
Scenario A: The corrupted backup
A company runs a major CMS update. The update fails and the website shows nothing but error messages. The developer clicks "Restore yesterday's backup" in the hosting panel. The restore process reports success, but the database turns out to be incomplete because the backup script had been cut off halfway through by a memory limit. Because the file was never automatically checked, the most recent working state of the website is permanently lost.
Scenario B: The server physically fails
Due to a hardware fault in the data center, the server's disk becomes unreadable. The business owner contacts the hosting provider and asks for the latest snapshot to be restored. The hosting provider reports that the snapshots were stored in the same physical server space as the live website. Both the live environment and the backups are irreparably damaged.
Scenario C: The silent data corruption
A malicious script gains access to the database and quietly alters client data and prices in the background. The company doesn't notice the problem until three weeks later. Because the hosting provider only retains seven days of backups, all available backups already contain the corrupted data. Without a long-term archive or advanced logging, there's no clean version left to recover.
Decision guide: which approach fits your organization?
To determine which backup structure is necessary for your SME, you can use the overview below. The choice depends on the type of platform and the impact of any downtime on your business operations.
| Criterion | Option 1: Hosting / Plugin Backup | Option 2: Isolated & Off-site |
|---|---|---|
| Type of platform | Static information pages, simple corporate websites | Webshops, client portals, custom CRMs, SaaS applications |
| Maximum recovery time (RTO) | A few hours to several days | Deployable within an hour |
| Acceptable data loss (RPO) | 24 hours of data loss is acceptable | At most a few minutes to an hour of data loss |
| Dependency on hosting | Fully dependent on one provider | Independent, data sits on separate cloud storage |
| Recovery guarantee | Rarely tested in advance | Periodically verified through automated or manual tests |
| Costs | Included in standard hosting | Requires investment in setup and external storage |
Choose Option 1 if:
Your website serves purely as a digital business card. No transactions are processed, visitors don't create accounts, and the content only changes a few times a year. If the website is offline for a day, this doesn't directly lead to revenue loss or legal issues. In this case, do make sure you occasionally download a manual copy of the files and database and store it in your own secure location.
Choose Option 2 if:
Your platform is an essential part of your business operations. This applies to online stores, custom dashboards, client portals, or applications where new data, orders, or leads come in daily. Losing a day's worth of data means direct financial or reputational damage. With an isolated off-site backup structure and point-in-time recovery, you safeguard your business's continuity, regardless of what happens to the server or provider.
Building a solid web platform doesn't stop at a nice design or fast code. The way you handle data, security, and recovery procedures determines whether your platform is ready for the long term.
Want to check whether your current backup structure and infrastructure offer sufficient protection in an emergency? Feel free to get in touch for a no-obligation, free thirty-minute conversation via ferhat.io/contact.
