"Is my website backed up?" is the wrong question for a Cascade site, or at least an incomplete one. Your content is already safe in Cascade, and you can regenerate the published site from it at any time. The questions that matter are what else the website depends on, how long you can afford to be down, and whether anyone has actually tested getting it back. This article walks through all three.
Cascade is the master copy
Because Cascade publishes finished files, the live website is a copy of what Cascade holds. If published files are lost or damaged, a republish rebuilds them. For published content, the amount of work you can lose is effectively zero. That is a real advantage over applications like WordPress or Drupal, where the live database is the only copy of recent changes.
What Cascade does not hold is everything around the published files, and that is what the hosting layer must be able to recover:
- Web server and CDN configuration, including redirects and rewrite rules
- Certificates and DNS configuration
- Files placed on the server by other systems, outside Cascade
- Form handlers, search indexes, and other dynamic services
- Protected-folder and sign-in configuration
- Logs you may need for an investigation
RTO and RPO in plain terms
Recovery Time Objective (RTO) is how long the site can be unavailable before it becomes a serious problem. Recovery Point Objective (RPO) is how much recent change you can afford to lose, measured in time. A marketing microsite might tolerate a day on both. An emergency-alerts page might tolerate minutes. The tighter the targets, the more the architecture costs to run, so they should be chosen deliberately for each site rather than set to "as fast as possible" for everything.
Four recovery patterns
| Pattern | How it works | Typical recovery time | Typical data loss |
|---|---|---|---|
| Backup and restore | Rebuild from backups after a failure | Hours to a day | Up to the last backup |
| Pilot light | Core pieces kept ready in a second location, scaled up when needed | Several hours | A few hours |
| Warm standby | A full second environment running at reduced size | Under a couple of hours | Under an hour |
| Active/active | Two regions serving traffic at once, with automatic failover | Near zero | Near zero |
For Cascade sites the data-loss column matters less than usual, because a republish restores content. The recovery-time column is where the choice really lies.
Matching failures to recovery
| What happened | How it is recovered |
|---|---|
| An editor unpublished or deleted the wrong folder | Restore the asset in Cascade and republish |
| A server configuration change broke redirects | Roll back the configuration from version control |
| A server or storage volume failed | Replaced automatically in a multi-AZ design, or rebuilt from backup and republished |
| An entire availability zone failed | Traffic continues on the other zones in a multi-AZ design |
| An entire region failed | Depends on the recovery pattern chosen: rebuild elsewhere, or fail over to a standby |
An untested backup is not a backup
Many environments have backups that have never been restored. Recovery targets written in a plan are only real once someone has met them in a test. Restores should be tested on a schedule, and a disaster recovery exercise should include the steps people forget: DNS, certificates, and a full republish from Cascade to the recovered environment.
Questions to answer for each site
- If this site were down for a day, who would be affected and how badly?
- Which parts of it live outside Cascade, and where are they backed up?
- When was a restore last tested, and how long did it take?
- Who decides to invoke disaster recovery, and how are they reached out of hours?
The answers usually show that a few sites deserve stronger recovery than the rest, which is a better use of budget than one level for everything.
How eWay protects Cascade sites
eWay takes automated daily backups of the hosting layer, keeps configuration in version control so it can be rebuilt consistently, and verifies that backups actually restore. Multi-AZ architecture is standard for sites where downtime matters, and warm standby or active/active patterns are available when the site's importance justifies them. Your RTO and RPO targets are defined in your service agreement and drive how the environment is built. If a restore is needed, eWay carries it out, coordinates timing with you, and finishes with a republish from Cascade so the recovered site is current.
What to include in a support ticket
- The severity you would assign, P1 to P4 (see severity levels and response times)
- What is missing or wrong, and when it was last known to be correct
- Whether the content still looks right inside Cascade
- For a recovery-planning review: which sites matter most and how long each could be down
eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time. See how to request support for all the options. Related reading: monitoring and uptime for Cascade sites and securing a Cascade site. More at Cascade Website Hosting.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article