Untested Backups and Growing Cloud Bills: Two Risks in a System That Works

Owners usually worry about the system that is broken. The one that deserves the worry is often the one that works: the store takes orders, the site sends leads, and nobody has opened the server in a year. Underneath, backups run every night without ever being restored, and the cloud bill climbs without anyone approving it. Here is how to check both and how often.

IN SHORT

Two risks you cannot see on the screen

A backup counts only after someone has restored it and checked what came back. A cloud bill stays under control only when every line on it has an owner and a reason. A system nobody has looked at for a year usually fails both tests, and neither failure shows on the site until the day it matters.

Both risks grow from the same root. When a system works, nobody has a reason to open the server: the backup job keeps reporting success, the hosting keeps charging, and the person who set it all up may have moved on long ago. The first restore often happens on the day the server fails, and the first careful reading of the bill when finance asks why it doubled.

The cost side has market data behind it. In its 2026 State of the Cloud report, released on March 18, 2026, Flexera put wasted cloud spend at 29%, the first increase in five years, based on a global survey of more than 750 cloud decision-makers and users; 85% of them named managing cloud spend as a top challenge. The waste figure is the respondents' own estimate, yet the direction is hard to ignore: by their own account, close to a third of cloud spending brings no value.

A backup nobody has restored is a hope with a schedule.

RESTORE TEST

A backup is proven by a restore

Ask whoever is responsible for a site whether it has backups, and the answer is almost always yes. Ask when a copy was last restored, how long it took and what was missing, and the conversation changes. A job that ends with "success" has proved that it wrote a file. Whether that file holds the whole database and the uploaded pictures, whether it opens on a clean server and whether anyone knows the steps to bring the site back from it are still open questions.

The ways a backup fails are ordinary. The job copies the database but not the folder with customers' uploads. The copy sits on the same server as the site, so a failed disk or a compromised hosting account takes both at once. The archive is encrypted, and the key exists only in the memory of a developer who has left.

A restore test answers these questions before they cost money. We take a recent copy, bring it up in a separate environment that has nothing to do with production, and check what came back: the site opens, the latest orders or leads are there, the uploaded files load, the admin panel signs in. Then we write down which copy was used, where it was restored and how long the recovery took. On the sites we support, backups run every day, are stored off the server and are restored to a separate environment, so the owner knows how long a recovery takes and what it brings back.

The US Cybersecurity and Infrastructure Security Agency asks for the same in its #StopRansomware Guide: maintain offline, encrypted backups of critical data and regularly test their availability and integrity in a disaster recovery scenario. Its reason is practical: many ransomware variants look for backups they can reach and delete or encrypt them.

The first restore should happen on a calm Tuesday, not during an outage.

WHAT TO COPY

Database, files, configuration and secrets

A backup that covers only the database brings back only part of the business. Four things need to be covered, and they are best handled separately, because they change at different speeds and need different protection.

• The database. Orders, customers, leads, products, prices and content in every language. On a busy store it changes every minute, so it is copied most often.
• Uploaded files. Product photos, customers' documents, generated invoices. They live outside the database and are the part most often forgotten.
• Configuration. Web server and PHP settings, the PHP extensions the code needs, scheduled tasks, environment variables and DNS records. Most of it is not in the repository, so a rebuilt server can run the same code and still behave differently.
• Secrets. Database passwords, API keys for payment and delivery services, mail credentials, encryption keys. They must be recoverable, but never in plain text next to the backups or inside the code: they belong in a password manager or a secret store such as Vault or the cloud provider's secret manager.

The code itself should live in a repository with its full history. If the only copy of the code is the one on the production server, fix that before anything else.

Where the copies live matters as much as what they contain. A copy on the same server protects against a mistaken deletion and very little else. The rule most often quoted here comes from a paper Carnegie Mellon University produced for US-CERT, now part of CISA: keep three copies of any important file, one primary and two backups; keep them on two different media types; store one copy offsite. For a website in 2026 that means the live data, a copy with a different provider or in a separate storage account, and a third copy that the production server's own credentials cannot delete. The CISA guide adds the modern half: offline and encrypted, so the copies survive an attacker who has already reached the server.

The storage accounts that hold the backups should be in the company's name, not a contractor's; the rest of that list is in What You Own vs What You're Renting.

RPO AND RTO

How much you can lose, how long you can wait

Two numbers decide how often backups run and how much the setup costs. NIST, in its contingency planning guide SP 800-34, defines the recovery point objective as the point in time to which data must be recovered after an outage, and the recovery time objective as the length of time a system can stay in recovery before the outage starts to harm the business.

In plain words, RPO answers "how much work can we afford to lose?" and RTO answers "how long can we afford to be down?" If the backup runs at 2 a.m. and the server fails at 6 p.m., sixteen hours of orders, leads and admin changes are gone. For a corporate site that changes once a week, that loss is small. For a store that takes orders all day, it means calling customers to ask what they bought.

Both numbers have a price: copies every fifteen minutes and a standby server pay only where an hour of downtime costs more than the setup. So we agree the two numbers with the owner first, starting from how the business earns, and choose the tools afterwards. The RTO also has to be proven: if the plan says four hours and the last restore test took nine, the real RTO is nine hours.

Daily copies stored off the server are the minimum we accept for any site that earns money, and they are what our support plans include. Busier systems add database copies during the day; configuration gets a fresh copy whenever it changes, which is easiest when the setup is written down as code.

RPO and RTO are business decisions that happen to be written in hours.

CLOUD BILL

Costs nobody decided

A cloud provider charges for what is running, whether anyone uses it or not. A server that handled a launch two years ago and now idles costs exactly the same every hour. That is why cloud bills grow faster than traffic: resources are easy to create, and removing them is nobody's job.

The usual sources of growth look the same on most bills:

• Idle and oversized servers. Instances sized for a peak that never came back. A database instance chosen "with room to grow" years ago is often the largest line on the bill.
• Forgotten staging and test environments. A full copy of production, built for one project and never switched off, often with real customer data on a server nobody updates.
• Logs and snapshots kept forever. In Amazon CloudWatch Logs, log data is stored indefinitely unless someone sets a retention period for each log group. AWS's own pricing examples use $0.05 per GB a month for standard EBS snapshot storage, and a snapshot policy that never deletes adds to that line every day.
• Small charges that multiply. Each public IPv4 address on AWS costs $0.005 an hour whether it is in use or idle, about $3.65 a month. A NAT gateway costs $0.045 an hour in US East (Ohio), about $33 a month, plus $0.045 for every gigabyte it processes.
• Egress. AWS gives 100 GB of data transfer out to the internet free each month across its services; beyond that every gigabyte leaving is billed, which matters for sites serving large files or copying backups to another provider. (AWS figures checked in October 2026.)

Not every company needs a big cloud. Many systems we look after run well on managed hosting or a few servers with fixed monthly prices, because the right setup is the simplest one that holds your load.

When the bill is already large, we review it line by line. Every resource gets a tag with its environment and its owner, then we look for test environments nobody switched off, servers sized for a launch peak, snapshots kept by default and pricing plans that no longer fit. Each change is shown to the owner first, its effect on the next bill is recorded, and we never promise a percentage before we have seen the bill.

Configuration often costs less than hardware. On the Laravel 7 project described below, the hosting plan already offered OPcache, the cache for compiled PHP code, and nobody had switched it on. Enabling it took the server response from about 55 to about 21 milliseconds, for a few dollars a month and without a larger server.

CHECKS

What to check, and how often

This is the routine we recommend for a site, store or web application that earns money; a busy store tightens some intervals.

The last row is easy to plan, because the dates are public. As of October 2026, PHP 8.2 receives security fixes until December 31, 2026, PHP 8.3 until December 31, 2027 and PHP 8.4 until December 31, 2028; Laravel 12 until February 24, 2027, and Laravel 13 until March 17, 2028.

The quarterly restore test is our recommendation rather than a standard: CISA asks for regular testing without fixing an interval, and a quarterly test that really happens beats a monthly one that exists only in a policy.

MONITORING

Alerts that come before customers

An uptime check, the ping that tells you the home page answers, misses most of the failures that cost money, because those show nothing on the screen. A contact form can show its thank-you message while the email never arrives. A move to new hosting can drop the SPF and DKIM records, and leads start landing in spam. On one recent project a new host blocked GPTBot and Meta's crawlers in robots.txt on its own.

So monitoring for a business system watches the flows that bring money as well as the server:

• Availability and response time of the main pages and the checkout, measured from outside your network.
• Business flows: an alert when no orders or leads have arrived for longer than usual, when a payment fails, or when a CRM or delivery integration stops answering.
• The server and background work: disk space, failed scheduled tasks, a stalled queue and the error log, where problems often appear days before customers notice.
• Backups and spending: an alert when a backup did not arrive, and a budget alert in the cloud account when spending passes the expected monthly level.

Tools range from Prometheus and Grafana or Datadog to a hosted uptime service for a small site, and routing matters more than the tool. Each alert goes to the person who can act on it, with a short note on what to do first, and an alert that fires every day without needing action is fixed or removed, because it teaches the team to ignore the next one.

Every upgrade or hosting change we make ends with a real test lead and three checks outside the code: mail authentication, robots.txt and which crawlers can reach the site. The full list for a move between hosts is in The Website Migration Checklist Most Agencies Skip.

SAFE UPDATES

Staging, deploy commands and a way back

A system nobody updates falls out of security support, and a system updated without a test copy, written deploy steps and a known way back turns every update into a bet. Our upgrade of one of our projects that was not a priority shows the safe version.

It was a trilingual corporate website with its own admin panel, a lead system and years of content, running on Laravel 7 and PHP 7.4, which had stopped receiving security fixes in November 2022. We moved it to Laravel 13 and PHP 8.4: six major versions, about three days of development, one day of acceptance testing and five minutes of planned downtime. The full account is in Six Laravel Versions in Three Days; these are the parts that apply to any update.

Before the first change. We created a separate branch and recorded the exact commit running in production. We set up a closed staging copy with the database and assets, restricted at the server level rather than simply marked noindex, and documented the PHP extensions, the settings, the deployment commands and the rollback procedure. Then every Laravel version went through as its own migration, and after each step we checked the public site, the admin panel, the forms and the error log.

What staging caught. Laravel 11 changed how mail encryption is configured, and with the old settings the form would have kept thanking visitors while lead emails stopped; we sent a real test lead and waited for the email before calling the step done. Route caching, a normal speed setting in Laravel, turned every page into a 404, because this site builds its language prefixes from the database. Undoing it took about a minute; on production it would have been an outage. The rule "never cache routes on this project" now lives in the project's instructions for developers and AI agents, the file described in Your Codebase Needs a Manual for AI.

The rollback point. The original plan pointed to a version tag created before several days of unrelated work, and rolling back to it would have undone that work too. It was changed to the exact production commit.

Release and acceptance. A backup, the merge, the new dependencies installed on PHP 8.4, the PHP version switched in the hosting panel and the caches cleared. The only downtime was the hosting applying the PHP switch, about five minutes in a quiet hour. Acceptance covered 15 public pages across three languages, 30 admin screens, a real test lead with a confirmed email, the error log and 987 internal links, with zero broken.

What makes this repeatable is that none of it lives in one person's head. Deploy commands are written down and run the same way every time, ideally from a pipeline, with a rollback that is a known command. Database changes are released so that the previous code still runs against the new schema, otherwise the code can go back and the data cannot. A staging copy with real customer data is removed once the work is accepted, so it never becomes the forgotten server on next year's bill.

WHO LOOKS AFTER IT

Support, DevOps or a takeover

Which format fits depends on where the system stands today, and we often recommend the smaller option.

Prices are as of October 2026 and are all on the pricing page. Cloud, hosting and paid tools are billed to you directly by the providers. The strategic session that opens an engagement costs $500 and is credited toward a project we build for you within 30 days.

The takeover row is more common than owners expect. One site we describe in Upgrading an Old Laravel or PHP Site in 2026 ran on PHP 5.6, with the hosting account controlled by someone outside the business and contact form emails rejected by the mail server; putting it right took two evenings.

For us, backups, servers and releases are part of the same system as the site, shaped around how your business earns rather than sold as a separate product. Everything runs in accounts you hold, and at any handover you get the code, the deployment commands, the server requirements, the rollback procedure and an AGENTS.md file, a plain description of the structure, the rules and the commands that your developers, another vendor or an AI coding agent can follow without guessing. When anyone leaves the project, us included, change the passwords and keys they used the same day; we explain why in Your Website Doesn't Fail When Your Developer Leaves.

FAQ

Sources

• Flexera: Flexera Finds Cloud Value is Rising While AI Waste Grows (2026 State of the Cloud report, March 18, 2026)
• US-CERT, Carnegie Mellon University: Data Backup Options (3-2-1 rule)
• CISA: #StopRansomware Guide
• NIST CSRC Glossary: Recovery point objective (SP 800-34 Rev. 1)
• NIST CSRC Glossary: Recovery time objective (SP 800-34 Rev. 1)
• AWS: Amazon VPC pricing (public IPv4 addresses, NAT gateway)
• AWS: Amazon EBS pricing (snapshot storage)
• AWS: Amazon EC2 On-Demand pricing (data transfer out)
• AWS: CloudWatch Logs, working with log groups and retention
• PHP: Supported versions
• Laravel: Release notes and support policy