Website backups small business sites can restore from
A backup you have never restored is still only a claim. On 22 September 2026 we audited our own production server and found zero scheduled backups configured anywhere, so we ran the restore test most owners skip. This piece is the state of website backups small business sites actually run: what our audit showed, the routine the official guidance prescribes, and where our own setup still falls short.
What we found on our own server
We run our own infrastructure on Coolify, an open-source hosting panel, on one server. The control plane keeps its state in a PostgreSQL 15.19 database, so instead of trusting the panel’s screens we queried the database directly. The scheduled_database_backups table held zero rows. So did scheduled_tasks, scheduled_volume_backups and the backup execution log. The s3_storages table, where off-site destinations are registered, held zero rows. The /data/coolify/backups directory, where local copies would land, did not exist at all.
Five applications, one user, one server, and no copy of any of it on our side. CISA’s ransomware guidance tells organizations to “maintain offline, encrypted backups of critical data, and regularly test the availability and integrity of backups in a disaster recovery scenario” (CISA #StopRansomware Guide). Our integrity test count was zero, right next to our backup count. The panel had the feature. Nobody had switched it on.
What website backups small business sites actually need
CISA’s checklist for small businesses tells owners to start with an inventory and names the assets worth protecting: customer and client records, financial and payroll data, emails and critical communications, configuration files and software settings, and website and operational databases (CISA, Back Up Business Data). On a small-business website that maps to three things: the database behind your enquiry forms and orders, the uploads directory holding everything customers sent you, and the configuration files carrying domain settings, environment variables and encryption keys.
The database is the asset people assume is safe because the site is “in the cloud”. An enquiry form shows why that assumption breaks: every field a visitor fills in usually becomes a row in a database; when the database is gone, the enquiries are gone with it. We wrote separately about how few contact form fields a small site really needs; every one of those fields is data that exists only in the database.
The 3-2-1 rule, priced for a small business
Coolify’s backups documentation describes the shape a backup setup should have: scheduled dumps, a retention window, and an off-site copy in S3-compatible storage, following the 3-2-1 pattern of three copies on two kinds of media with one off-site (Coolify docs). The FTC’s business guidance puts the same idea in one sentence: back up your data regularly and make sure those backups are not connected to the network (FTC, Cybersecurity for Small Business).
The objection is always price. Cloudflare’s R2 pricing page, checked on 22 September 2026, lists a free tier of 10 GB-month of storage per month, charges nothing for egress to the internet, and prices standard storage at $0.015 per GB-month beyond the tier (Cloudflare R2 pricing). A database dump is compressed text, so whether a year of daily copies fits the free tier depends on data size; the constraint is setting the schedule up, not paying for storage.
The routine, step by step
The routine we wrote down after the audit, with our own status in the last column:
| Step | Frequency | Where the copy lands | Our status, 22 Sep 2026 |
|---|---|---|---|
| Database dump | nightly | server disk via Coolify scheduled backups | not configured yet |
| Off-site copy | weekly | S3-compatible object storage | not configured yet |
| Restore test | monthly | throwaway database, then deleted | ran 22 September 2026 |
Two of three lines are empty on the team that writes about backups. The honest reading: the restore test was the line we could complete first, and it decides whether the other two are worth automating; a schedule that produces untested archives is a slower way to lose data.
The restore test
PostgreSQL’s documentation describes what a dump is: a file of SQL commands that, fed back to a server, recreates the database in the same state as it was at the time of the dump, and that dump is an internally consistent snapshot which does not block normal operations while it runs (PostgreSQL docs, SQL Dump). That last property is why the test can run against a live server during working hours.
These are the commands we ran on 22 September 2026, inside our Coolify database container:
pg_dump -U coolify -d coolify -F c -f /tmp/coolify-cp.dump
createdb -U coolify restore_test
pg_restore -U coolify -d restore_test --no-owner --no-privileges /tmp/coolify-cp.dump
dropdb -U coolify restore_testThe dump produced a custom-format archive whose header listed 568 TOC entries. The restore line is the one that matters: pg_restore read the archive into a database named restore_test that nothing depends on, with —no-owner —no-privileges so ownership and permissions would not fight the import. We compared row counts against the live database: 5 applications and 1 user on both sides. The scratch database was dropped, and a final query confirmed the server held only its two original databases.
Minutes of work from “is our backup real” to “this dump restores, and the counts match”. Coolify’s own documentation says it flat out: “A backup is not a restore test” (Coolify docs). The same platform’s restore guide carries the warning that keeps the test safe, “A restore replaces existing data”, so stop application writes before any restore and keep the test away from the live database (Coolify restore docs). Their post-restore checklist is worth copying: confirm the restored database runs, read the logs for import errors, verify expected tables and records, then reconnect applications.
The monthly line in the table is not our invention either. CISA’s small-business page asks businesses to perform scheduled recovery tests to verify backup integrity and confirm they can roll data back at least seven days when needed (CISA, Back Up Business Data).
What the test does not cover
A passed restore test is not a finished backup setup.
It proves this dump restores, not that next month’s will exist. Our schedule is still unconfigured, so the tested dump was made by hand, and until the nightly schedule is in place the test is a proof of mechanism rather than a routine.
It covers the database only. Uploads, certificates, DNS and the panel’s own configuration are not inside a pg_dump, so a database restore alone does not bring a whole site back. The FTC’s ransomware guidance asks for a full backup of your environment, files, programs and the current operating system together (FTC, Cybersecurity for Small Business); a database dump is one file inside that set. Ready.gov’s recovery plan guidance, last updated 25 March 2026, makes backup frequency a decision that comes out of a business impact analysis and its recovery point objective: how much data you can afford to lose sets the schedule (Ready.gov). That decision is still ours; the test only removed the doubt.
The cost, stated plainly: disk space for the scratch database, someone who reads the restore output, and the discipline to delete it afterwards. Coolify’s restore guide asks you to confirm the target server has room for both the backup file and the restore operation, and to keep a separate copy of data that must not be lost before you restore anything.
The next step for your site
Open your hosting panel’s backup screen and answer two questions: is a schedule configured, and what is the date of the last restore you watched finish. If the second answer is never, run the throwaway-database test above before you invest another hour in schedules; it takes minutes, and it is the only step that produces proof. If the panel cannot hand you a downloadable backup file at all, that is the hosting problem to fix first.
Our maintenance and support page lists what we take over for small-business sites, and the contact page is where you book a free consultation if you want the routine and the restore test scheduled for you. If your site has deeper problems than backups, start with the web application security checklist and work from there.
Frequently asked questions
How often should a small business back up its website?
Often enough that the data you would hate to lose is never more than one interval old. Ready.gov’s recovery guidance says data should be backed up frequently and pushes the decision back to a recovery point objective from your business impact analysis. A site taking bookings every day wants a nightly database dump; a brochure site that changes twice a month can back up before each change. The interval is a statement about tolerable loss, not a number to copy from someone else.
What is the 3-2-1 backup rule?
Three copies of your data, on two different kinds of storage, with one copy off-site. CISA’s checklist spells it out for small businesses, and the Coolify backups documentation points to the same pattern as the target for scheduled database backups, with the off-site copy landing in S3-compatible storage (CISA, Back Up Business Data). The off-site copy exists for the day the server itself is the problem: ransomware that encrypts the server also reaches every backup living on it.
How do I test a backup without touching the live site?
Restore it into a throwaway database, never over the live one. On PostgreSQL that means pg_dump to a file, createdb for a scratch database, then pg_restore with —no-owner —no-privileges, followed by a row-count comparison against the live tables and a drop of the scratch database. Coolify’s restore guide warns that a restore replaces existing data, which is exactly why the test target must be a database nothing depends on.
My host has a one-click backup button. Is that enough?
Ask the button two questions: what file does it produce, and where can that file be restored. A backup kept on the same server fails with the server, and a file that has never been restored is an unverified claim. Download it, restore it into a scratch database or staging copy, and confirm the rows are there. If the panel cannot hand you the file, you have found the real problem.
Where should the off-site copy go on a zero budget?
An S3-compatible object store with a free tier. Cloudflare’s R2 lists 10 GB-month of storage free per month with no egress charges, and paid storage starts at $0.015 per GB-month (Cloudflare R2 pricing). Point the hosting panel’s scheduled backups at a bucket there, keep a retention window you have actually checked, and glance at the bucket’s file listing monthly so an empty bucket gets noticed while it is still cheap.