A record you cannot produce, when someone asks for it, is a record you do not have. That sentence sounds obvious and gets ignored constantly, because most farms treat backing up as a chore for a slow week rather than as part of what a record actually is. A treatment log that exists only on one laptop, or one phone, or in one barn, is not a durable record — it is a draft that happens to be complete today and may not exist tomorrow.
This page is about making the copy that turns a fragile draft into something that survives the specific accidents that end farm records: a fire, a theft, a dead drive, a service that shuts down.
A backup that shares a location with the original is not a backup
The test of a real backup is simple: name the single event that could destroy the original, and ask whether that same event would also destroy the backup. A second notebook on the same shelf fails this test against a fire. A second file on the same laptop fails it against theft or a failed drive. A cloud copy synced automatically from the same laptop, with no separate export, fails it against an account being deleted or a subscription lapsing. Only a copy that genuinely sits somewhere the original's specific threats cannot reach counts as a backup at all.
It is worth being specific about the accidents this is actually defending against, because naming them makes the backup rule concrete rather than abstract. A fire or a flood destroys whatever is physically on the property, original and any nearby copy alike. A stolen laptop or phone takes whatever lived only on that device. A failed hard drive, with no warning, takes whatever was never copied off it. A lapsed subscription or a shut-down service takes whatever existed only inside that one account. Four different accidents, four different things they can reach — and a genuine backup is one that sits outside the reach of whichever accident is most likely for a given record.
Off-site does not have to mean expensive
It also helps to be honest about which records are worth this effort and which are not. A record that can be reconstructed reasonably well from an outside source — see rebuilding lost farm records for what that actually looks like — does not need the same backup discipline as one that exists only in your own memory or your own handwriting. Prioritize backing up the records that, once lost, cannot be recovered from anywhere else.
A backup does not need a second data center. It needs physical or logical distance from the original. A photograph of a paper logbook's pages, stored on a phone that is not kept in the same building as the book, is a legitimate backup. A monthly export of a digital system, emailed to yourself or saved on a drive kept at a different address, is a legitimate backup. What matters is the separation, not the sophistication of the method.
This connects to the honest trade between paper and digital covered in paper versus digital farm records: paper's real weakness is that it usually exists in exactly one place, and the cheapest fix for that weakness is not switching formats — it is simply making sure a second copy of it exists somewhere else.
This is also why a backup stored with the same provider as the original, but in a different folder or a different plan tier, is weaker than it looks. It survives a mistake inside your own account, but not the provider itself having a bad day, changing terms, or discontinuing the product entirely. A backup is only as independent as its weakest shared dependency with the original, and a shared provider is a dependency worth noticing even when a shared building or a shared device is not involved at all.
The backup schedule should match how fast the records go stale
A farm that enters records daily and backs up once a season is exposed to losing most of a season's work in one accident. The right frequency is not a fixed number for every operation — it is however often it takes for the gap between "last backup" and "today" to exceed how much you are willing to reconstruct by hand if the original is lost. For most farms, that argues for automating the backup entirely rather than relying on a recurring reminder that competes with everything else on a busy week for attention.
It is worth naming who is supposed to notice if a backup routine quietly stops working — an automatic sync that silently fails, a scheduled export nobody checks the output of, a duplicate drive that was unplugged months ago and never reconnected. A backup system with no one assigned to notice its own failure will fail exactly the same way a paper record fails when nobody re-files it: not dramatically, but by quietly stopping, unnoticed, until the day it matters.
An untested backup is a hope, not a backup
The step almost everyone skips is opening the backup and confirming it actually works. A backup file can be corrupted, incomplete, or saved in a format nothing on hand can open anymore, and none of that becomes visible until someone tries to restore it — which means the worst possible day to discover a bad backup is the day the original is already gone. Testing a restore, at least once a season, on a copy you do not need yet, is the only way to convert a backup from a hope into something you can actually rely on.
An export is the backup, not just a convenience
Farm40 provides twelve one-click CSV exports covering every record type in the system, and the honest way to think about them is as your backup mechanism, not merely a reporting feature — a dated, portable copy of everything entered, that you hold independently of whether the application itself keeps running. The limit is worth stating plainly: an export only contains what was entered. It cannot back up a record that was never made in the first place, and it will not tell you, on its own, that a gap exists in what you hold — only a habit of actually opening the export and checking it against what you expect to see will do that.
Backing up records is unglamorous in exactly the way insurance is unglamorous — invisible right up until the day it is the only thing that mattered. Keep a copy somewhere the original's threats cannot reach, on a schedule that matches how fast your records change, and test the restore before you need it. For how this fits the rest of a working system, see farm recordkeeping.