Backups and versions

The two things

Version history is built into most website tools. It keeps previous states of your pages so a bad edit can be reverted, usually within a limited window.

A backup is a copy held independently. It answers a different question: what if the account is lost, the provider fails, or something deletes far more than one page.

They cover different failures and one does not substitute for the other. Version history is used constantly and a backup is used almost never, which is exactly when it matters.

The confusion between them is not academic. A business that assumes its version history is a backup discovers otherwise at the only moment when discovering it is expensive.

What version history is for

The everyday case. You rewrote a page, it was worse, and you want yesterday back. That is the overwhelming majority of recoveries anybody ever performs.

Check how far back yours goes and whether it covers deletions as well as edits. Those limits differ between tools and are worth knowing before you need them.

Our page on maintenance covers the routine around this. Knowing your version window is a five-minute thing to establish once.

Version history also protects you from other people. Where more than one person edits the site, being able to see what changed and return to a previous state settles most disagreements without any argument.

What a backup is for

The rare case. An account problem, a provider ending a service, or a mistake that removes more than version history can return.

It should include your pages, your images and anything submitted through your forms that you have not stored elsewhere. Our page on form data covers that last part.

And it should live somewhere other than the site. A backup held only inside the thing being backed up does not cover the case it exists for.

How often depends on how often the site changes. For most small businesses a copy taken after any substantial edit, and otherwise a few times a year, is entirely proportionate.

What a real backup arrangement includes

The list below is what separates a backup from an intention. Most small businesses have the first two items and none of the rest.

• Version history inside the tool, with a known window
• A copy of the site held somewhere else
• Images and documents, not only page text
• Anything submitted through forms
• A known way to actually restore it
• One restore actually attempted, once
• A note of where it all lives

The only test that counts

Restore something. Not the whole site, but one page, once, from the backup rather than from version history, and confirm it comes back as expected.

A backup that has never been restored is an assumption. Most discovered failures are not missing files, they are a restore process nobody has ever run.

Do it once at launch and you have converted a hope into a fact, which is the entire value of the exercise.

Write down what you did while it is fresh. The steps are obvious on the day and completely forgotten by the time somebody needs them under pressure.

Keep the source material

Your original photographs, your logo files and your written copy should exist outside the website tool regardless of any backup arrangement.

That is the real insurance for a small business. A site can be rebuilt from its source material in a day; source material that exists only inside a platform cannot be rebuilt at all.

Our page on logos and brand marks covers the file formats worth keeping. The same applies to every photograph you paid for.

How much this deserves

An hour at launch and nothing thereafter. Confirm your version window, take one copy, restore one page, write down where things live, and stop.

Do not buy an elaborate backup service for a small site on a hosted platform. The provider already holds copies for their own reasons and your source material is the part they cannot replace.

The genuinely useful outcome is knowing what you would do, rather than owning a subscription that says backup on it.