Backups are the easiest thing in a business to believe in and the hardest to verify. A plugin reports success every night, an invoice says the host includes them, and nobody has opened one since the site launched. Growth Bully, a Malta performance marketing agency, only ever sees this tested at the worst moment, because the first real restore attempt is almost always the one that happens under pressure.
The distinction worth holding onto is simple. A backup is a copy. A recovery is a working business. Most teams have bought the first and assumed the second, and the gap between them is measured in days of lost leads.
What should a business actually back up?
Four things, not one. The website files, the database that holds your content and form entries, the configuration that routes leads to wherever they land, and the tracking setup that proves your advertising works. Most backup products cover the first two and quietly ignore the last two, which is where the expensive losses sit.
That fourth item surprises people. A restored site can come back looking perfect while the analytics property, the conversion tags and the audience definitions behind it have gone, which means a month of optimisation history is gone with them. The site is live, the reporting is blind, and nobody notices until a budget decision needs a number.
How often should a website be backed up?
As often as you would hate to redo the work. A brochure site that changes twice a year does not need hourly copies. A site taking enquiries all day needs at least daily copies, because every hour between the last backup and the failure is a batch of enquiries that no longer exists anywhere.
Decide it by writing two numbers down before you choose any product. How much data can the business afford to lose, expressed in hours, and how long can the site be down before the cost becomes serious. Those two answers set the frequency and the retention, and they are business decisions rather than technical ones.
What do you lose that a website backup does not cover?
The parts of the lead path that live outside the website. Form integrations, CRM field mappings, automation rules, ad platform conversion events, audience lists built from site visitors, and the records of anyone who enquired since the last copy was taken. None of that is inside a file archive.
Keep a separate written record of the things no archive restores:
- Where each form sends its submissions, including the destination address, the CRM pipeline and any automation it triggers.
- The conversion events each ad platform is optimising towards, and what counts as a conversion for each one.
- Tag and analytics configuration, exported rather than remembered, including the container and property identifiers.
- Audience and remarketing lists that depend on site traffic, which rebuild slowly and cannot be restored at all.
- Who holds the logins, for the host, the domain, the CRM and the ad accounts, because a recovery stalls on access long before it stalls on technology.
Lead records deserve their own line. If enquiries only exist in the website database, a restore to last night loses today, and those people will not fill the form twice. Routing every submission to a second destination the moment it arrives is the cheapest insurance available, and what breaks between your form and your CRM covers how that path fails silently.
Where should the copy be kept?
Somewhere the website cannot reach. A backup stored on the same server as the site shares its fate, so a server failure, a billing lapse or a compromise takes both at once. At least one copy belongs in separate storage under a separate login, and ideally in a location the website has no credentials for.
Access matters as much as location. If the publishing account can delete the backups, anything that gains that account can delete them too. Keep the copies in a place that only a named person can empty, and keep one copy that cannot be overwritten for a set number of days.
How do you test a restore properly?
By rebuilding the site somewhere harmless and then using it as a customer would. Downloading an archive proves the file exists. Restoring it to a staging environment, loading the pages, submitting a form and confirming it arrives is the only test that proves the business can come back.
A restore test that is worth the hour runs in this order:
- Restore the most recent backup to a staging environment, not to the live site.
- Load the pages your advertising points at and check images, content and layout.
- Submit a test enquiry through every form and confirm it reaches the CRM and the inbox.
- Confirm the analytics and conversion tags fire on the restored environment.
- Record how long the whole exercise took, because that is your real recovery time.
- Write down anything that needed a manual fix, and automate or document it before the next test.
Run that quarterly, and immediately after any change to the host, the forms or the tracking. Teams that test twice a year discover the same three manual fixes every time and never get round to removing them, which turns a one hour recovery into a one day recovery.
Who is responsible when a restore is needed?
One named person, decided now. An outage is not the moment to learn that the host blames the developer, the developer no longer holds the account and nobody can approve a spend. Write down who performs the restore, who they call, and who is allowed to make decisions without a meeting.
Marketing needs one standing instruction alongside it. If the site is down or badly broken and campaigns are live, pause the campaigns first, because clicks keep billing while the pages return errors. The same reasoning and the hosting side of it are in what cheap hosting costs you in ad spend, and ownership of the accounts themselves in who owns your ad accounts.
What should you avoid restoring?
The cause. If the failure came from a compromise or a bad update, a restore of the most recent copy puts the problem straight back, usually within days. Identify what broke, pick a copy from before it broke, and apply the fix on the restored version before you point traffic at it.
This is the argument for retention depth rather than one rolling nightly copy. Keep dailies for a fortnight and weeklies for a few months, so there is a clean point to return to when the problem turns out to be older than last night.
How do you keep this from decaying?
Attach it to events rather than good intentions. Review the arrangement whenever the host changes, the site is redesigned, a new form goes live, the advertising budget steps up, or the person who held the logins leaves. Each of those invalidates part of what you last tested, and none of them send a reminder.
Then keep the whole thing to one page: what is copied, how often, where it lives, who restores it, how long that takes, and the date of the last successful test. If that page does not exist, the honest position is that the business has copies and no recovery plan. Checks for the moment a new site or landing page goes live are in the launch checks that protect your leads, and the data protection obligations that attach to stored enquiry records in the privacy rules for lead data. If you want the whole path from click to CRM pressure tested in one pass, ask us for a pipeline review, or see how the wider programme is run on our digital marketing service.