How to create a data backup strategy for a small business

Start with an inventory of where your data lives

You cannot protect what you have not listed. The Canadian Centre for Cyber Security (CCCS) tells organizations to identify and prioritize their business-critical data, the data they need to keep the lights on, as part of their backup policy. Walk through five places, and for each system write down who owns the data and what would happen if it vanished today.

Laptops and desktops

A common way to protect laptops is to keep user files in a cloud-synced folder. Microsoft's known folder move redirects Desktop, Documents, Pictures, Screenshots and Camera Roll into OneDrive for work accounts, and on a personal Microsoft account Windows Backup syncs chosen folders to OneDrive, with 5 GB of storage included free. On a Mac, Time Machine backs up to an external drive, and Apple suggests one with at least twice the Mac's storage.

Sync solves a lost or dead laptop. It does not solve a deleted folder or an encrypted file, because the change syncs too. What saves you then is the service's own history, covered in the next section, or a separate backup.

File shares and NAS

A NAS is often where the shared drive lives, which makes it primary data, not a backup. Its RAID array keeps the volume running when one disk fails, but a deleted folder or an encrypted file is deleted or encrypted on every disk at once. CCCS also warns that ransomware can spread to a NAS on the same network. Treat the NAS as a system to back up, and as a good place for one local copy of your other systems.

Servers and databases

Databases need their own method. A copy of the files of a running database is usually unusable: PostgreSQL's documentation says the server must be shut down to get a usable file-system backup, and half-measures such as blocking connections do not work. Use the database's own tools: pg_dump, or a base backup plus the archived write-ahead log (WAL) for PostgreSQL; full, differential and log backups for SQL Server; the vendor's documented method for anything else. Whole servers and virtual machines usually get image-level backups, covered with the backup types below.

Check what Microsoft 365 and Google Workspace actually keep

Cloud suites are built so that their own hardware and datacenter failures rarely reach you. They are not built to undo your mistakes for as long as you might need, and both vendors say so in their documentation:

• Exchange Online keeps every mailbox database in at least three copies across datacenters, but Microsoft states that its lagged copy is not intended for individual mailbox or item recovery. What a user deletes stays recoverable for 14 days by default, which an admin can raise to a maximum of 30.
• SharePoint and OneDrive: SharePoint keeps deleted items in its recycle bins for 93 days, and Files Restore can roll a SharePoint library or a OneDrive back to any moment in the last 30 days, using file versions.
• Microsoft 365 Backup is Microsoft's separately billed backup product. As of September 2026 it costs $0.15 per GB per month, with a recovery window of 3 months to 2 years set per policy. Its copies never leave the Microsoft 365 boundary: quick to restore from, but still with one vendor.
• Google Workspace admins can recover a user's deleted Drive items within 25 days after the user empties the trash. The restore brings back everything removed in a date range rather than single files, and it can take several days. A deleted user's Drive files can be restored within 20 days of the account deletion.
• Google Vault retains nothing until you create retention rules, and Google says plainly that Vault isn't a data archive.

So retention is a window, and replication and sync copy whatever happens, a deletion included, to every copy the provider keeps. A backup is a separate copy with its own history that you can restore from after the window has closed, or after the account itself is gone. For most small businesses that means a third-party SaaS backup service or Microsoft 365 Backup, chosen per system in the inventory.

Set a recovery point objective and a recovery time objective

Two numbers turn "we back up" into a plan. NIST's contingency planning guide, SP 800-34 Rev. 1, defines them:

• Recovery point objective (RPO): the point in time to which data can be recovered after an outage, given the most recent backup. In practice, how much recent work you can afford to lose.
• Recovery time objective (RTO): the longest a system can stay unavailable before the impact on the business becomes unacceptable. In practice, how long until people can work again.

The same guide defines the maximum tolerable downtime (MTD), the total outage the business will accept, and says the RTO must normally be shorter than the MTD, because the lost work still has to be redone after the restore.

Set both objectives per system, with the person who owns the data, in hours rather than adjectives. Then check what your current setup actually delivers:

• An RPO worked example. A backup that runs every night at 23:00 gives an RPO of up to 24 hours. If the server fails at 16:00 the next day, 17 hours of work is gone, whatever the plan says.
• An RTO worked example. Restoring 500 GB from cloud storage over a 100 Mbit/s connection takes about 11 hours of transfer alone (500 GB is 4,000 gigabits; at 0.1 gigabits per second that is 40,000 seconds). If the RTO is four hours, you need a local copy to restore from, not a faster promise. The same logic applies to Google's Drive restore, which can take days.

For databases, the RPO decides the recovery model. Under SQL Server's simple recovery model, changes since the most recent backup are not protected; the full recovery model, with transaction log backups, supports point-in-time recovery to a specific moment, for example just before someone ran the wrong import. PostgreSQL does the same by replaying archived WAL on top of a base backup, and its documentation warns that replaying a long stretch of WAL takes time, which counts against the RTO.

Tighter objectives cost more: more frequent backups, more storage, faster links and more testing. The point of writing the numbers down is to spend where an hour of loss hurts, and nowhere else.

Choose the backup types: full, incremental, differential, file or image

CCCS describes three backup types, and suggests a periodic full backup (weekly or monthly) and one before any major system upgrade:

Each has a cost. Microsoft's SQL Server documentation notes that the longer you go without a new full, the bigger each differential gets, until it can approach the size of the full backup and lose its advantage. Incremental chains stay small, but a restore has to process every increment, which CCCS points out can be time-consuming. Business backup software such as Veeam can run a forever-incremental chain and build synthetic full backups from it, and consumer tools hide the choice altogether: Time Machine backs up only the files that changed since the previous backup. PostgreSQL's pg_basebackup can also take an incremental backup against the manifest of an earlier one.

File-level or image-level

A file-level backup copies chosen folders and files. It is small, restores a single file easily, and is what Windows Backup does. After a dead disk, though, you reinstall the operating system and applications before you can put the files back.

An image-level backup copies whole volumes, operating system included, so a machine can be restored onto new hardware, a bare metal recovery. On Windows Server, wbadmin start backup with the -allCritical parameter includes every volume that holds the operating system's state, which is what a bare metal recovery needs. The target must be a volume that is not itself being backed up:

wbadmin start backup -backupTarget:E: -allCritical -include:D: -quiet

Servers and virtual machines with a short RTO usually warrant image-level backups. Laptops whose files are synced often do not, because a device management platform can rebuild them from scratch. Databases need application-aware backups either way.

Apply the 3-2-1 rule to decide where copies live

The 3-2-1 rule is the placement rule that both CISA and CCCS publish: keep three copies of important data (the original and two backups), on two different types of media, with one copy off-site. Each number answers a different failure:

• Three copies: one backup failing when you need it (a bad disk, a job that silently stopped) is survivable.
• Two types of media: one kind of failure (a drive model, a storage system, an account) cannot take out both backups.
• One off-site: a fire, flood or burglary does not take every copy with the building.

What counts as off-site? For choosing an off-site location, NIST weighs the distance from your site and the chance that one disaster hits both, and how long it takes to get the data back. A USB drive in the manager's bag counts only if it actually leaves every night. A cloud copy counts, but one kept in the same account as the system it protects shares that account's fate.

CCCS adds two practical points: disconnect removable media once the backup finishes, so an attack on your network cannot reach it, and remember that your organization remains legally responsible for data it stores with a cloud provider, so check where the provider keeps it (data residency).

Vendors extend the rule under their own names. Veeam markets 3-2-1-1-0: one copy immutable or air-gapped, and zero errors when restores are verified. Treat such variants as vendor terms, not standards. The extra "1" is about securing backups against ransomware, which is a subject of its own; the "0" is restore testing, which every plan needs and which is covered below.

Set the schedule and the retention policy

How often. NIST's guide says backup frequency and scope should follow how critical the data is and how often new information comes in. The RPO turns that into a number: a 1-hour RPO needs something at least hourly, and a 24-hour RPO can be met with nightly backups. Schedule heavy jobs outside working hours, and run database log backups around the clock.

How long. Retention decides how far back you can go, and it has to be longer than the time it takes to notice a problem. A folder deleted by mistake is often missed until month-end or an audit, and CISA notes that rolling backups can silently carry corruption or malware from the original files into the backups. If every restore point is newer than the problem, you have no clean copy.

The common pattern is grandfather-father-son (GFS) rotation: daily backups (son) kept for a couple of weeks, weekly backups (father) for a couple of months, and monthly or yearly backups (grandfather) for a year or more. Veeam implements it by flagging full backups as weekly, monthly or yearly and keeping each for its own period. Time Machine does something similar on every Mac: it keeps hourly backups for the past 24 hours, daily backups for the past month and weekly backups for everything older, and deletes the oldest when the disk fills up.

That example gives 34 restore points reaching back a year, for far less storage than a year of dailies.

Test restores on a schedule

A backup job that reports success proves that data was copied, not that it can be restored. CCCS lists testing the recovery process on a routine basis as part of a backup policy, and NIST says backup media should be tested regularly to confirm that files can be retrieved without errors or lost data. Put tests on the calendar at three depths:

1. Monthly: restore a few files and one mailbox folder to a different location, and open them.
2. Quarterly: restore one whole system, such as the accounting server or a virtual machine image, into an isolated network. Start it, and check that the application works with recent data.
3. Yearly: assume the office is gone. Rebuild the critical systems from the off-site copy alone, following only the written plan.

For each drill, record the date, what was restored, from which copy, how long it took and what went wrong. Time it against the RTO: if the plan says four hours and the drill took nine, either the method changes or the business agrees to nine.

Write the plan down and give it an owner

CCCS recommends written policies and procedures that set how often backups run, how they are implemented and managed, and how recovery is performed, including roles and responsibilities. NIST adds where the data is stored, how files are named, how media are rotated and how copies get off-site. For a small business, all of that fits on one or two pages:

• the inventory, with a data owner for each system;
• the RPO, RTO and retention for each system;
• the backup jobs, tools and schedules;
• where each copy lives, and who can reach it;
• restore steps for the likely cases: one file, one mailbox, one server, the whole office;
• vendor and support contacts, and where the admin credentials are kept (never the credentials themselves);
• the test log.

Name one owner, often an operations manager or the outside IT provider, and a deputy. The owner reads the backup reports, runs or books the drills, and updates the plan when something changes: a new SaaS app, a new server, or a leaver whose account is about to be deleted. Keep a copy of the plan outside the systems it describes, printed or in a separate account, because the day you need it may be the day the file server is gone.

Example: a one-page backup plan for a small office

Here is a plan for an imaginary 15-person professional firm with Microsoft 365, a NAS for shared files, one on-premises accounting server and laptops. The numbers are examples to adapt, not recommendations for your business.

Plan owner: operations manager. Deputy: the IT provider. Reviewed: every quarter, after each drill, and whenever a system is added or retired.

The Microsoft 365 row holds two copies, not three: the tenant and one backup outside it. If that gap matters for your mail, choose a backup service that keeps a second copy in another region, or one that can export to storage you own.

If you would rather hand this work over, our IT support covers Microsoft 365 and Google Workspace administration, including backup of mailboxes and files, and starts with an assessment of your devices, accounts, email and backups. For websites and applications we host, hosting and maintenance applies the 3-2-1 rule with an immutable copy, writes down the RPO and RTO for each site, and proves them with scheduled restore drills.