How long would it take to get your website back if it disappeared tonight? For most owners the answer is a guess, and the guess is usually optimistic. The average downtime after a ransomware attack reached 24 days in 2025. A site that earns money loses it the whole time the page is dark, and the recovery clock starts when something breaks, well before anyone notices. Where the site is hosted shapes that timeline more than any other single factor, because the speed of a restore depends on how the backups were taken and where they are kept.
The Two Numbers Behind a Backup
Every backup plan answers two questions, and the answers have names. Recovery point objective, or RPO, is the amount of data a site can afford to lose, measured in time. A backup taken once a day means up to 24 hours of changes can vanish in a failure. Recovery time objective, or RTO, is how long the site can stay down before the loss turns serious. A shop that takes orders every minute needs both numbers low. The cost of a high RTO is concrete, since for an enterprise an hour of downtime can cost about $300,000, so cutting a recovery from days to hours changes the math entirely. The backup schedule and the restore method set these two figures, and most owners never choose them on purpose, which means the host chooses for them.
The Speed Advantage of Cloud Backups
Traditional backups copy entire files on a fixed schedule, often overnight, to a single drive. Cloud hosting changes the method in three ways. Snapshots capture the full state of a server, its database, files, and settings, in one operation, so a restore rebuilds the whole site at once rather than file by file. After the first full snapshot, each one records only the blocks that changed, which makes frequent backups cheap enough to run every few minutes. Recovery also pulls from storage spread across many machines and locations, so a single failed disk does not take the only copy with it. Because copies are kept in more than one data center, a regional outage that would erase a single-server backup leaves the cloud copies intact, and the restore starts from the nearest healthy location. Instant snapshots on modern platforms reach a recovery point of seconds and a recovery time in the tens of seconds, a range a nightly file copy cannot touch.
The Foundation Under a Backup
A backup is only as dependable as the system that stores and restores it. Fast snapshots mean little if the host loses copies, delays a restore, or goes offline during the recovery itself. This is why reliable web hosting matters as much as the backup software, since the infrastructure that serves the site every day is the same one that brings it back.
The gap shows up during a real failure. A provider with redundant storage and tested recovery can return a site in minutes, while a one-copy setup with no plan turns a small problem into a week offline. The backup stores the data. The host decides how fast it comes back.
The 3-2-1 Rule and the Offsite Copy
The standard backup advice is the 3-2-1 rule. Keep three copies of the data, on two kinds of storage, with one copy offsite. The offsite copy is the part cloud hosting handles well, since the provider can replicate data to a second region without manual work. A fire or a failed data center then takes only one copy. Newer guidance extends this to 3-2-1-1-0, adding one immutable copy that cannot be altered and zero errors confirmed by testing. The immutable copy matters most against ransomware, which now targets backups directly so a victim cannot simply restore. An immutable copy is written once and locked, so even an attacker with full access cannot edit or delete it for a set period, and that property is why immutable storage is at the core of modern recovery plans.
The Limits of Snapshots
Snapshots cover one job well and leave another exposed. A snapshot usually shares the same storage as the live site, so a disk failure or a ransomware infection can take the snapshot along with the original. Most platforms also keep snapshots only for a limited window, so a problem found late may already be older than the last saved snapshot. Their strength is speed. A snapshot rolls back an accidental deletion or a bad update in seconds, and it gives a clean point-in-time source for a full or incremental backup. The safe setup uses both, with frequent snapshots for quick fixes and offsite backups for the disasters that destroy the primary storage.
Testing the Restore
A backup that has never been restored is a guess. Plenty of sites discover a corrupt or incomplete backup at the worst moment, during an actual outage. Organizations that test their restores every quarter recover about 48% faster than those that test once a year or never. The test is simple. Restore to a spare location and confirm the site loads with current data before discarding the copy. Cloud platforms make this cheap, since spinning up a temporary copy costs little and takes minutes. In 2025, 54% of victims of a ransomware attack with encrypted data got it back from backups, the lowest rate in six years, mostly because the backups themselves had been compromised or left untested.
The Value of Recovery Speed
The money behind these numbers is large. More than 60% of enterprises reported at least one major data loss in the past 12 months, and recovery now costs over $4 million on average per event. Ransomware recovery alone averaged $1.53 million in 2025, down 44% from the year before as backup practices improved. The improvement is measurable, since immutable backups paired with automated recovery cut the average restore from 31 days to 14. For a small business the figures are smaller, but the shape is the same, because every hour offline is an hour of lost orders and lost trust.
The Answer to the First Question
Back to the question at the start. With cloud snapshots backed by offsite copies and a restore that has actually been tested, the time to bring a site back falls from the 24-day ransomware average toward minutes or hours. The technology to do this is standard on solid hosting plans and costs little to turn on. When a site stays dark for weeks, the cause is usually an owner who never set the two numbers and never tried the restore. The question at the top has a short answer, and a prepared owner already knows it.
