Operators: Check RTO, RPO, and site recoverability within 30 days

Site Owners: In 30 Days, Check Your RTO, RPO, and Recoverability

Yes, a website can be recovered quickly and with minimal data loss, if you've defined RTO and RPO in advance, have verified backups, and a clear response plan. A successful recovery means two things: the site is back up within the agreed timeframe, and data loss stays within limits the business is prepared to accept. The first steps are always the same: isolate the affected system, trigger recovery from verified backups, and only then test before bringing the site back into the live environment.

In short:

• For website recovery, a response plan is essential — one that includes verified backups, appropriate RTO and RPO, and testing before going back live.
• For larger online stores, DRaaS services with real-time replication are recommended, since they significantly shorten downtime and improve resilience.
• Regularly testing recovery procedures is mandatory, since an unrecoverable backup isn't a safe backup — full and partial tests need to happen more often than you might think.
• When choosing a disaster recovery partner, it's important to check references, test results, and clear response-time guarantees, with contract transparency also mattering.
• Moxy-web builds recovery and backups into its base hosting, advocating a combination of local and off-site copies following the 3-2-1 principle, and regularly verifies that they can actually be restored.

Table of Contents

• What Disaster Recovery Means for Websites
• Steps for Recovering After a Cyberattack
• Backup Strategies: Methods, Locations, and Schedules
• DRaaS and Cloud Options: Replication Instead of Waiting
• How to Test Restores and Verify a Backup Actually Works
• How to Choose a Website Recovery Partner
• How Moxy-web Approaches Backups and Testing
• What Really Shows Up Only During an Incident
• A Recovery and Hosting Package at Moxy-web
• Sources
• Frequently Asked Questions

What Disaster Recovery Means for Websites

Website disaster recovery is a set of procedures that restore a site's operation within a predefined timeframe and with an acceptable amount of data loss after an outage, attack, or data loss event. Two indicators sit at the core of the strategy: RTO and RPO. RTO (recovery time objective) tells you how long a site can afford to be unavailable. RPO (recovery point objective) tells you how much data between the last backup and the outage is still acceptable to lose.

These values vary significantly depending on the type of site:

• An online store with daily traffic: low RTO and RPO values, since every lost order means lost revenue.
• A content management system (CMS) with articles and posts: moderate RTO and RPO, since losing the latest entry rarely threatens the business.
• A showcase site with no transactions: higher time tolerance for RTO and RPO is often still acceptable.

Set these values by calculating the cost of one hour of downtime and comparing it against the price of more frequent backups and faster infrastructure.

Steps for Recovering After a Cyberattack

When an incident hits, the order of your actions determines whether you recover the site in hours or in days. Improvising at this stage almost always extends the downtime.

1. Activate the response plan and isolate affected systems. Cut off access to the infected server or database to prevent it from spreading to other services.
2. Decide between forensic analysis and parallel recovery. For smaller incidents, trigger recovery from a backup immediately, while a forensic investigator examines the cause of the attack in parallel on a separate copy of the system.
3. Restore from verified backups. Use the last known clean copy, not necessarily the most recent one, if there's a suspicion the infection predates the latest backup.
4. Test the restored system in an isolated environment. Verify that the database, plugins, and payment paths work before bringing the site back to production.
5. Gradually bring the site back into operation and monitor logs for any repeat intrusion attempts.
6. Notify stakeholders and document the incident. Customers, your hosting provider, and, if necessary, CERT Slovenia need to be informed, and the documentation is useful for the next review of your plan.

Expert tip: Never restore directly into the production environment. An intermediate test in a sandbox reveals hidden infections before you expose them to visitors again.

Backup Strategies: Methods, Locations, and Schedules

Your choice of backup method depends on how much data the business can afford to lose. A full backup captures the entire system and is the slowest but most reliable starting point. A differential backup stores all changes since the last full backup, while an incremental backup stores only changes since the last backup of any kind, which is fastest but requires an unbroken chain for restoration.

Backup location determines whether a business survives a fire, a stolen server, or a ransomware attack. The 3-2-1 rule is well established: three copies of data, on two different types of media, with one copy off-site. In practice, this means a combination of:

• local copies on the hosting server for quick recovery of minor errors,
• off-site copies, for example on your own NAS server, which survives a primary data center outage,
• cloud copies with an independent provider, separate from the website's host.

Automation is key here, since manual backups almost always fail exactly when they're needed most. Encrypting backups protects data even if it falls into the wrong hands, and versioning lets you roll back to a point before an infection, not just to the most recent copy.

Adjust your schedule based on the type of site: stores need more frequent database backups, daily backups are enough for CMS sites, and showcase sites can be backed up less often. Regularly testing recoverability matters just as much as the backup schedule itself, since an unrecoverable copy doesn't count as a safe backup.

DRaaS and Cloud Options: Replication Instead of Waiting

Disaster Recovery as a Service (DRaaS) works on a principle of constant, or near-constant, replication. In the background, the system copies changes to a secondary location in real time, so there's no need for lengthy backup restoration during an outage. Managed cloud recovery services shorten recovery time from hours to minutes, and take the burden of manually managing secondary infrastructure off internal IT teams.

Benefits and limitations go hand in hand:

• Faster failover. A replicated copy is already prepared, so failover is a matter of minutes, not hours.
• Less manual work. The provider manages replication, monitoring, and system status reporting.
• Higher cost and complexity. For a smaller showcase site, DRaaS is often overkill relative to the actual risk.
• Growing regulatory pressure. The DORA regulation already pushes financial and critical sectors toward demonstrable resilience, making DRaaS more worthwhile for mid-sized and larger businesses with regular, sales-dependent customers.

For a small showcase site, a good combination of local and cloud backups is enough. For an online store processing hundreds of orders a day, the difference between one hour of downtime and five minutes translates into real money.

How to Test Restores and Verify a Backup Actually Works

A backup that's never been restored is just an assumption about safety. The European Union Agency for Cybersecurity (ENISA) lists regular restore testing among the fundamental elements of cyber resilience.

1. A partial test checks the restoration of a single file or database table, and you should run it monthly.
2. A full test restores the entire site on a test server and reveals whether the backup works as a whole, not just in pieces.
3. A sandboxed failover test simulates an actual outage without endangering your production environment, and should be run at least twice a year for critical sites.

Adjust frequency to your risk level: an online store should run a full test quarterly, while a showcase site can be on an annual cycle. Document every test, including recovery time and any errors found, since the same weakness, left unrecorded, often repeats itself a year later.

Expert tip: The biggest mistake in testing isn't skipping the test — it's testing on the same infrastructure where the original backup was created. If that server goes down, the test goes down with it.

How to Choose a Website Recovery Partner

When choosing a disaster recovery provider, a nice-looking marketing page isn't enough. Check for concrete evidence:

• references and concrete examples of recoveries the provider has already carried out,
• results from their most recent restore tests and how often they run them,
• a guaranteed response time upon incident reporting, written into the contract, not just promised verbally.

Good questions to ask a provider: "When did you last test a full restore, and what was the result?" and "What's your average time from incident report to a working site?" A vague or general answer is a red flag.

Payment models vary: a one-time project fee for building the plan, versus a subscription for ongoing maintenance with regular backups and tests, billed monthly or annually. With managed recovery services, the provider is also responsible for setting up replication and regular reporting, which makes sense for businesses without their own IT team. Bring your partner into your existing site protection process by clearly defining who triggers a recovery, who tests it, and who reports on it to leadership.

How Moxy-web Approaches Backups and Testing

At Moxy-web, disaster recovery isn't a separate add-on — it's part of every web solution we build. Regular backups, encryption, and verified recoverability are built into hosting from the start, not added only after the first incident.

• A combination of local and off-site backups following the 3-2-1 principle, tailored to the type of site.
• Regular checks that backups actually restore, not just that they're saved.
• Clear documentation of RTO and RPO for each client individually, based on their business model.

For further reading on setting up schedules, check out this guide to website backups for businesses and this explanation of why data backups matter for every business model. Advanced data recovery techniques for more severe failures are covered in this practical guide to data recovery.

What Really Shows Up Only During an Incident

The biggest mistake website owners make isn't the absence of a backup — it's the belief that a backup exists without ever having restored it. When an outage happens, that assumption gets exposed at the worst possible moment. Do three things this week: check the date of your last successful restore, not just your last backup; set an RTO and RPO for your site based on reality, not wishful thinking; and schedule one full restore test within the next 30 days.

— Ziga

A Recovery and Hosting Package at Moxy-web

Instead of piecing together backups, testing, and responsiveness from three different providers, Moxy-web bundles all of this into one agreement with fixed operating rules. The package includes secure hosting, automated and encrypted backups, regular restore testing, and technical support that responds when it's needed most, not just the next business day. Your RTO and RPO become documented numbers, not guesses made during an outage. If you'd like an assessment of these values for your site, or a consultation on your existing backups, check out the offering at Moxy-web and arrange a short conversation about where the gaps are in your current plan.

Sources

• What is the difference between recovery time objective (RTO) and recovery point objective (RPO)?
• Slovenia: information security under new information
• ENISA — European Union Agency for Cybersecurity
• What Is Website Backup and How Do You Automate It?

Frequently Asked Questions

What are RTO and RPO in website disaster recovery?

RTO is the acceptable amount of time a site can stay unavailable, and RPO is the amount of data between the last backup and the outage that's acceptable to lose. Both are set based on the business impact of downtime, as explained by Advisera.

How often should I test website recovery?

Online stores should run full tests a few times a year, less critical showcase sites should be tested once a year, and partial tests of individual files should happen monthly.

What is DRaaS, and when is it worth it?

DRaaS is a managed service that replicates data to the cloud in near real time and enables a fast failover during an outage. It's worth it for mid-sized and larger online stores, where every hour of downtime means a significant loss of revenue.

What's the difference between an incremental and a differential backup?

An incremental backup stores only the changes since the last backup of any kind, while a differential backup stores all changes since the last full backup. Incremental is faster; differential is simpler to restore.

How do I choose a website recovery provider?

Check references, the results of their most recent restore tests, and a response time written into the contract. Moxy-web, for example, includes regular testing and secure backups as part of its base hosting package.

Recommended

• A Guide to Website Backups for Businesses
• How to Set Up Secure Website Hosting