How to Automate Business Backups Before You Lose Data

Automate your backups now, while nothing is wrong, because the failure you are insuring against never sends a warning first. A working setup has three properties: it runs by itself on a schedule, it writes to a place the original cannot reach (a different account, ideally a different provider), and somebody has recently restored a real file from it and opened the result. Miss the first and the backup depends on a human remembering. Miss the second and whatever destroys the original destroys the copy. Miss the third and you own a hope, not a backup. The expensive discovery is almost never "we had no backups." It is "we had backups, and they had been failing for months." Everything below is about making that sentence impossible to say about your business.

The short version

A backup is a tested restore, not a copy. Until someone has pulled a real file back out and opened it, the green checkmark is a feeling.
The dangerous period starts after setup. A full disk, an expired card, a rotated password or a moved folder stops the job silently, and nothing in the business changes until the day you need it.
Separate is the whole point. Copies in the same account, on the same machine, or inside the same sync folder die with the original.
Alert on silence, not on failure. A job that crashes may never get to send its error. Watch for the backup that did not arrive.
Put the restore drill on the calendar. Quarterly, one named person, one real file, a stopwatch. It takes under an hour and it is the only proof.
Most businesses do not need custom software for this. Managed databases and backup products cover the common case; build only when your data lives where no product reaches.

Why do backups fail exactly when you need them?

The most famous backup failure in software history happened at Pixar. In 1998, during the making of Toy Story 2, a delete command ran against the server that held the film, and the artists watched their characters, sets and animation vanish from the directory tree in real time. Pixar had a backup system. When they turned to it, they discovered it had been producing unusable copies for weeks. What saved the movie was an accident of circumstance: Galyn Susman, a supervising technical director who had recently had a baby, had been working from home and had a recent copy on a machine in her house. Pixar veterans have told the story publicly for years, and the film's production history records it.

The lesson is not "Pixar was sloppy." The lesson is that a backup system has two jobs, making copies and telling you the truth about whether it made them, and it is the second job that fails first. Almost every backup failure we have been called in after was silent for weeks or months before anyone noticed, and the mechanisms are boringly repetitive:

The destination filled up. The disk, the bucket quota or the plan limit was reached, the job started failing on write, and the failure email went to an address that stopped being read two employees ago.
The payment lapsed. The card on the storage account expired, the warnings went unread, and after a grace period the provider froze the account or deleted the data.
A credential rotated. Someone changed the database password or revoked an old API key during unrelated cleanup, and the backup job has been failing to log in ever since.
The data moved and the job did not. The site migrated to a new host, the shared folder was reorganized, the database was renamed. The job kept faithfully copying the old, empty location and reporting success.
The job ran and captured nothing. A zero-byte dump, an export that hit an error halfway and still exited cleanly, a snapshot of a disk that no longer holds the working data.

Notice what these have in common. Not one of them produces a visible change inside the business on the day it happens. Orders still come in, invoices still go out, the dashboard still says "last backup: today." That is why the dangerous period is not the years before you set up backups, when at least everybody knows they are exposed. It is the years after, when a green checkmark buys unearned calm.

What is the difference between a copy and a backup?

A copy is data that exists in a second place. A backup is a copy that is automatic, separate and restorable, and each word does real work. Automatic, because a copy that depends on a person remembering is a copy that stops the first busy week. Separate, because a copy that shares an account, a machine or a sync folder with the original shares its fate. Restorable, because a copy nobody can open, decrypt or find under pressure is indistinguishable from no copy at all.

Most of the things businesses call backups fail at least one test. A synced folder (Dropbox, Google Drive, OneDrive) is not a backup, because sync exists to make every device agree, and it will agree with a deletion or a ransomware encryption as loyally as with a new file. Version history in those tools is a genuine safety net, but it is bounded by a retention window measured in days or weeks depending on the plan, and it does nothing for the folder you never synced. A mirrored drive protects against one disk dying and nothing else. An export somebody ran last spring is a copy of last spring.

The SaaS assumption deserves its own paragraph, because it is the one that surprises owners most. Your CRM, your accounting platform and your store platform all run backups, and those backups exist so the vendor can survive a data-center failure. They are not there to hand you last Tuesday's version of your customer list after a staff member bulk-deleted it, and most terms of service say so plainly. If the record matters, you want a copy in storage you control, produced on a schedule, in a format you can open without the vendor's help.

The technical version of this argument, including the 3-2-1 rule, point-in-time recovery and how to set recovery objectives, is in our backups and disaster recovery guide. The rest of this article is the owner's version.

What should a small business actually back up?

Walk through a normal week and note every place where a record or a file gets created. The list is always longer than the owner expects, and the items at the bottom are the ones that hurt.

The systems of record. The database behind the store, the CRM, the accounting data, the scheduling tool. Where these are hosted products, the backup is a scheduled export through the vendor's API or export feature, landing in storage you own.
The files people upload. Product photos, signed contracts, quotes, PDFs. These frequently live outside the database, in an uploads folder or a storage bucket, and a database restored without them is a store with no pictures and a contract system with no contracts.
The spreadsheets that secretly run things. The pricing sheet, the staff rota, the inventory tracker with fifteen tabs. If the business would stall without it, it is a system of record whatever it is called; the wider risks of running on those files are covered in signs you have outgrown spreadsheets.
Configuration and secrets. DNS records, environment variables, API keys, payment gateway settings, the list of installed plugins and their settings. Rebuilding a server takes an hour; remembering the forty settings that made it work can take a week.
The code. It should already be in a git repository you have access to. If a freelancer holds the only copy, that is a backup problem wearing a different hat.
The instructions. A one-page runbook: where each copy lives, who can reach it, in what order things come back. This page should live somewhere other than the systems it describes.

How do you set up automatic backups, step by step?

Decide how much loss you can tolerate, per system. Losing an hour of orders is a bad afternoon; losing a week of them is a lawsuit. This one decision sets the frequency: nightly is fine for most things, and the order database deserves continuous, point-in-time protection, which most managed databases offer as a switch.
Choose a destination the original cannot reach. A different account with different credentials, ideally at a different provider, at minimum a different region. Ask one question of any destination: if the production admin login were stolen tonight, could the thief delete these copies? If yes, it is not separate.
Schedule the job and make it push. Use the database's built-in schedule, a reputable backup product, or a small scheduled job of your own that pushes the copy out with credentials that can write but not delete. The mechanics of running such a job reliably on modern hosting are in our guide to scheduled jobs on Vercel.
Record every run somewhere a human will see. After each run, post one line to a shared channel: the date, the size, the duration. A dump that shrank by ninety percent overnight is a finding, and a person glancing at a channel will catch it when no error handler would.
Alarm on silence, not on failure. A job that crashes may never get to send its own error. Set a monitor that expects the daily line and complains loudly when it does not arrive: a dead man's switch, in the language of observability for small apps. This single step closes the gap that caught Pixar.
Lock the copies. Turn on versioning and, where the storage offers it, immutability with a retention period, such as S3 Object Lock. A locked copy cannot be deleted by a compromised account, a ransomware script or a tired engineer. Set retention to outlast your detection time: corruption in a spreadsheet is often noticed weeks after it happened, so keep months, not days.
Put the restore drill on the calendar. Quarterly, one named person, a stopwatch. The drill itself is described next; the point of this step is that it exists as a recurring event with an owner, because "we should test that sometime" is the sentence every failed backup was preceded by.

What does a restore drill actually look like?

Pick something that matters and is inconvenient: an invoice PDF from three months ago, the customer table as it stood last Friday, the product images for one category. Restore it into a scratch location, never over production, then open it and check that it is complete and current. Time the whole thing from "we need this" to "here it is," including every password you had to hunt for and every person you had to message.

A pass has three parts: the data came back within the time you decided you could tolerate in step one, the content is what you expected rather than a stale or partial version, and the notes you took are good enough that a second person could repeat the exercise without you. Anything else is a fail, and a fail on a quiet Tuesday is a gift, because the same fail during a real incident would have been a disaster. The first drill nearly always turns up something: a passphrase in one person's head, a tool nobody has installed anymore, an uploads folder that was never in the job. Fix what you find and the next drill is faster.

When should you build a custom backup job instead of buying one?

Most businesses should not hire anyone for this, us included. If your data lives in a managed database, turn on its automatic backups and point-in-time recovery and confirm they land in a separate account. If it is a WordPress or WooCommerce site, use host-level backups plus a reputable plugin that ships copies offsite, and check the retention. That is an afternoon with settings pages, and paying a developer for it would be paying for the wrong thing.

Building something custom earns its keep in a few specific situations:

Your records live in tools that only offer an API. A CRM, a scheduling platform, a form builder, a support desk. A small scheduled job that pulls the records nightly and writes them to storage you own is the only way to hold a copy the vendor cannot take away.
The system of record is spread across five products. One job that gathers all of them into a single dated folder makes a coherent restore possible at all, instead of five vendors' exports in five formats.
A regulator or a contract sets retention. Years of invoices in a format you control, with proof of when each copy was taken, is a requirement that generic tools handle badly.
You want recovery rehearsed daily without anyone noticing. A script that rebuilds a staging environment from last night's copy every morning is also a restore drill that runs 365 times a year.

When we do build this, the first phase is deliberately small: a week or two to inventory the systems, write one job that covers the ones that matter, wire the heartbeat and the silence alarm, run one rehearsed restore with the owner watching, and leave behind a one-page runbook. It is priced as a fixed piece of work with a defined finish line, and whether to extend it to the long tail of systems is a decision you make afterwards, with the first phase already working. It is the rare automation whose entire payoff is invisible until the day it is everything, which is why it rarely makes the list in what to automate first and why we push it up that list anyway. The ongoing cost is real but modest: storage, and an hour a quarter for the drill, a line item that belongs in the maintenance budget rather than in the category of surprises.

Common pitfalls

The failures we see are rarely about missing technology. They are about a gap between what someone believed was protected and what was.

A case, details changed. A regional distributor ran quoting and inventory out of spreadsheets on a synced shared drive, and everyone understood the sync to be the backup: the files were, after all, on every laptop and in the cloud. One employee's machine picked up ransomware. The sync did exactly what sync does and delivered the encrypted versions to every other device within minutes. Version history would have saved most of it, but the seasonal pricing folder was not opened until six weeks later, by which time the retention window had long closed. Every tool had worked as designed. The problem was that a synchronized copy had been asked to do a job it was never built for.

Other patterns worth checking against your own setup:

The same-account backup. The copies sit in the same cloud account as production, so one stolen admin password takes both.
The database without its files. The job covers the tables and forgets the uploads folder, the contracts bucket, the attachments.
The restore that lives in one head. One person knows the encryption passphrase, the storage login and the order of operations, and that person is on vacation, or gone.
The host's "daily backups" line. It usually means a snapshot kept for a few days, restorable by support ticket, never tested with your data. Ask four things: retained how long, restorable by whom, in how many hours, and last tested when.

If you are not sure which of these describes your setup, tell us what you run and we will give you the honest read, including the common version where the right fix is a settings change and a calendar reminder rather than a project.

FAQ

How often should a small business back up its data?

Match the frequency to how much you could stand to lose in each system. Transactional data such as orders, bookings and payments deserves continuous protection, which managed databases offer as point-in-time recovery, so a mistake at 4pm can be undone to 3:59. Documents, spreadsheets and content are usually fine nightly. The frequency matters less than two other properties: the job runs without a person remembering, and someone finds out the same day if it stops.

Is Google Drive or Dropbox a backup?

No, though it is better than nothing. Sync tools exist to make every device hold the same files, so a deletion or a ransomware encryption on one machine is copied to all the others. Their version history softens this for a limited window, but it expires, it covers only what you chose to sync, and it cannot bring back a whole folder structure as of a chosen date the way a real backup can. Use sync for collaboration and add a separate, scheduled copy for protection.

How do I know my backups are actually working?

Two signals, and you need both. First, a positive record of each run somewhere a person looks, with the size and duration, so a sudden shrink or a missing day stands out. Second, a periodic restore of a real file into a scratch location, opened and checked, with the time it took written down. A dashboard status alone is not evidence, because the component that reports success is often the same one that broke.

What is the 3-2-1 backup rule?

Keep at least three copies of your data, on two different kinds of storage, with one copy somewhere else, meaning a different physical location or a different cloud account. The copy that matters most is the offsite one held under credentials the production systems do not have, because that is the copy that survives an account takeover or a deletion that propagates everywhere else.

How often should we test a restore?

Quarterly is a sensible default for a small business, and more often for anything that changes shape frequently, such as a store that adds plugins or a system whose hosting recently moved. The drill takes under an hour once the runbook exists, and it should have a named owner and a calendar entry, because a test that depends on someone remembering will follow the same fate as a backup that does.

Do I need a developer to set up automated backups?

Usually not. Managed databases, WordPress backup plugins, host-level snapshots and workstation backup products cover the common case through settings you can change yourself in an afternoon. A developer earns their fee when your records live inside SaaS tools that only expose an API, when the data is scattered across several products that need to be gathered into one coherent copy, or when a contract or regulator requires proof of retention over years.

Automate Your Backups Before You Lose Data: Why the Restore Is the Only Proof